[00:00] <tkamppeter> johanbr, then your manual call and the call by cupsfilter uses different command line options and the call out of the print queue even others.
[00:01] <tkamppeter> Try to find out which command line options get actually used and which ones make pdftopdf break. If the original PDF produced by evince is good then we probably have a pdftopdf bug.
[00:01] <calc> LaserJock: yea
[00:01] <calc> LaserJock: but poorly, so i have to determine how to fix it or disable it entirely and use fuse
[00:02] <calc> LaserJock: fuse was buggy as well so it wasn't working until the next release 1.1.8 will work with OOo
[00:02] <calc> LaserJock: it didn't support truncate at all but now does for trivial cases (0 or same size as file)
[00:03] <LaserJock> calc: bummer
[00:03] <ebroder> Has, uh, anybody run into weird issues with Jaunty's libc running under Lenny's kernel?
[00:04] <tkamppeter> johanbr, is the file already the evince output or the original file? If it is the original, give me also the evince output.
[00:06] <TheMuso> 8/c
[00:07] <calc> LaserJock: well gvfs fuse will work in time for jaunty, but i was trying to fix the OOo native support which takes learning how they actually work, heh
[00:08] <calc> i have to make a decision by beta though to make sure it works for everyone
[00:08] <johanbr> tkamppeter: that's the original
[00:08] <johanbr> just a sec
[00:25] <tkamppeter> johanbr, seems that your LaTeX PDF file makes evince turning all fonts to graphics when converting PDF to PDF (probably with Poppler).
[00:26] <tkamppeter> Great would be if one could let evince pass the input PDF directly through to the output to minimize the number of conversions (and losses caused by them).
[00:26] <johanbr> Oh, I see. Well, that explains the enormous file size.
[00:28] <johanbr> tkamppeter: If you pass the original pdf file through pdftopdf, you should also get a large file (~100 megs). Is that also because it turns fonts into graphics?
[00:29] <tkamppeter> pdftopdf should do page management only, not re-render the file. Please try passing the original PDF to pdftopdf. The size of the output should be in the order of the size of the input.
[00:31] <johanbr> tkamppeter: nope
[00:31] <johanbr> cat original_filename.pdf |/usr/lib/cups/filter/pdftopdf job1234 username test 1 jobname.pdf >copy.pdf
[00:32] <johanbr> gives a copy.pdf that's 92 megs large
[00:40] <tkamppeter> johanbr, strange. pdftopdf bug probably. pdftopdf is Poppler-based, evince probably too and the two Poppler treatments perhaps produce 5 * (92/5)^2 MB.
[00:43] <johanbr> could the problem be fixed directly in poppler?
[00:43] <johanbr> or does the library not have enough information to know that it can just return the pdf file unmodified?
[00:44] <johanbr> and evince does indeed use poppler
[00:47] <Hobbsee> asac: ping?
[00:50] <Mavericks> any way to find out whether gnome or openGL developer positions (work at home) for canonical are wide open at this point of time apart from looking at webapps.ubuntu.employment
[00:51] <Mavericks> *webapps.ubuntu.com/employment - surprisingly it has URL starts with webapps
[00:54] <Mavericks> ooh oops sorry if i  offended canonical staff here - any help will be appreciated
[00:55] <LaserJock> generally we don't know anymore than anybody else about Canonical's hiring
[00:56] <LaserJock> I suppose you could email Canonical's HR but I'm not sure if they'd tell you anything helpful regarding how "wide open" positions are
[01:00] <Mavericks> yes, there is a time frame of 21days about notification after applying for a position
[01:02] <Mavericks> couldn't find HR  and there seem to be lot of ideal or desirable work-at-home positions but recession only makes it tougher
[01:02] <ScottK> Mavericks: It's really OT here regardless.
[01:03] <Mavericks> ScottK: thank you , i know that
[01:03] <LaserJock> Mavericks: HR is simply hr@canonical.com
[01:08]  * calc read something interesting about intel ssd today, apparently they are limited to 20GB/day transfer to stay within warranty specs, and supposedly slow down so that you can't do more than that disk io
[01:09] <andersk> Hey, anyone want to look at an awesome libc bug?  bug 339743
[01:10] <Hobbsee> andersk: probably people on the other side of the world, who are asleep now.  Also, they get mailed about bugs that they care about
[01:12]  * ScottK wonders how it's even a bug.
[01:12] <ebroder> It's problematic if your Jaunty build chroots are running on a Lenny system
[01:12] <ScottK> "Hey, your libc doesn't work with some other distro's kernel"
[01:14] <andersk> Surely a statically compiled binary is supposed to work on other distro's kernels.
[01:14] <ArneGoetje> slangasek: the -base langpacks contain all translations which were exported from Rosetta at a given point in time. the other langpacks is a diff to what has changed since then.
[01:14] <andersk> It works in Intrepid.
[01:16] <ArneGoetje> slangasek: due to a bug the first -base langpacks didn't include any mozilla and kde translations. That's why I generated a new one. Mozilla diffs only work when the -base pack has mozilla xpis already, which was not the case.
[01:18] <ArneGoetje> slangasek: the duplicate xulrunner and firefox for bn_IN, es_ES, pt_PT and sv_SE are due to in import error into Rosetta and will hopefully be removed from the database soon. As soon as this happens I will generate new -base langpacks. Another -base generation will happen shortly before release. Please do expect them to grow in size!
[03:10] <calc> so 10.04 LTS will have gnome 3.0 ?
[03:14] <TheMuso> calc: IMO that would be too risky.
[03:15] <TheMuso> Or, we extend the cycle to fix bugs.
[03:24] <ScottK> TheMuso: So far it's seemed to me that the general view for LTS is better grab the latest so it'll be supported longer.
[03:24] <ScottK> Perhaps next time around it'll be the opposite.
[03:25] <TheMuso> ScottK: Yeah but GNOME 3.0 will have some pretty significant changes
[03:25]  * ScottK doesn't really know about it.
[03:25] <ScottK> From what I'd read in blogs it seemed likely to arrive with Perl 6.
[03:25] <TheMuso> heh right
[03:29] <ScottK> TheMuso: At the last release team meeting I brought up the Qt 4.5 ICE on PowerPC and there were some actions assigned to look into it.
[03:29] <TheMuso> ScottK: I didn't know about that ICE
[03:29] <ScottK> Since then I see that GCC FTBFS on powerpc in the last upload in the g++ tests.
[03:30] <calc> ScottK: well aiui gnome 2.30 == 3.0
[03:30] <ScottK> This one http://launchpadlibrarian.net/23244739/buildlog_ubuntu-jaunty-powerpc.kde-style-skulpture_0.2.2-0ubuntu1_FAILEDTOBUILD.txt.gz is a much smaller app, but it looks like the same/very similar failure.
[03:30] <ScottK> calc: KDE got a new version so we want one too?
[03:30] <calc> ScottK: something like that probably ;-)
[03:31] <calc> ScottK: they get to drop deprecated api's at 3.0 as well iirc
[03:31] <ScottK> Right.
[03:32] <calc> I'm going to try running a debug build with gio for OOo if it doesn't show anything obvious I'm going to drop gvfs/gio from OOo and go to gvfs fuse for jaunty :-\
[03:37] <LaserJock> calc: where did you hear that 2.30 == 3.0? I can't imagine that actually happening
[03:42] <calc> LaserJock: don't remember now
[03:42] <calc> LaserJock: may not have been a reliable source
[03:47] <calc> LaserJock: http://www.phoronix.com/scan.php?page=news_item&px=NjU4Mg
[03:47] <calc> LaserJock: it seems that 2.30 will really be 3.0 unless they change their mind in july
[03:58] <ScottK> So it sounds like the decision is not so much about what they'll add, but what they'll drop?
[03:58] <TheMuso> Corba for one
[03:58] <johanbr> I guess the gnome-shell thingie will be part of 3.0.
[03:59] <TheMuso> That will be interesting accessibility wise.
[04:02] <calc> wow i'm glad i got the gvfs truncate fix in when i did, next release is 2.26.0
[04:04] <LaserJock> so I wonder if they're going to branch or something
[04:05] <LaserJock> I can't imagine doing all the Gtk/Gnome 3.0 breakage in 1 release
[04:07] <johanbr> Well, there are already branches of some things. I know of the gnome shell and gtk with multi-pointer support. Probably other stuff too.
[04:08] <TheMuso> and gnome-speech may be going away, actually it will go away if I have anything to do with it.
[04:14] <LaserJock> johanbr: yeah, but if it's really supposed to be "revolutionary" the core stuff I'd think would need to be starting fairly soon
[04:17] <LaserJock> http://live.gnome.org/ThreePointZero seems a bit bare
[04:38] <calc> LaserJock: apparently they forgot to update the page after guadec
[06:05] <dholbach> good morning
[06:06] <IntuitiveNipple> morning :)
[06:07] <dholbach> hi IntuitiveNipple
[06:25] <crimsun> TheMuso: ok, latest /ubuntu is go for Alpha 6
[06:26] <ebroder> Anyone around who could do an upload for bug 339449? I'd like to make a6
[07:28] <slangasek> ArneGoetje: right, my question isn't really "why do we have -base langpacks" so much as "why, during the development cycle, do we ever have any translations in the normal langpacks instead of just updating the -base langpacks?"
[07:28] <slangasek> ArneGoetje: btw, please remember to turn off the upload cronjob, alpha 6 this week :)
[07:55] <pitti> Good morning
[07:55] <Hobbsee> heya pitti!
[07:56]  * pitti hugs Hobbsee
[07:56] <Mithrandir> yo, Hobbsee, pitti
[07:56] <Hobbsee> :)
[07:56]  * Hobbsee hugs pitti back, and waves to Mithrandir
[07:57] <pitti> hey Mithrandir, how's it going?
[07:57] <Mithrandir> pitti: good, good.  Was in CPH over the weekend, which was nice.
[07:58] <StevenK> Morning pitti
[07:58] <StevenK> pitti: So, you didn't accept syslinux.
[07:58] <pitti> StevenK: was I supposed to?
[07:58] <pitti> Mithrandir: nice, I've never been to Denmark yet
[07:59] <StevenK> pitti: I thought you said you'd look at it on Friday?
[07:59] <pitti> oh, SRU? sorry
[07:59] <Mithrandir> pitti: Isn't it weird not having visited a neighbouring country?
[07:59] <StevenK> pitti: Yeah, the SRU
[08:00] <pitti> Mithrandir: I visited all 8 others
[08:00] <StevenK> pitti: Fix it? :-)
[08:00] <pitti> StevenK: ok, seems I need to do SRUs today again
[08:00] <pitti> StevenK: got buried in meetings on Friday, I apologize
[08:18] <ebroder> I'm not entirely clear on the process here. Does bug #339618 require a freeze exception?
[08:21] <siretart> kirkland: do you have any plans to backport screen-profiles to hardy/intrepid and eventually debian?
[08:21] <Hobbsee> siretart: it's already in a ppa?
[08:22] <Hobbsee> at least for intrepid
[08:22] <siretart> Hobbsee: I have no problem recompiling it for me personally. Actually, I'm most interested in having it in lenny-backports :-)
[08:24] <Hobbsee> siretart: ahhh
[08:41] <tkamppeter> Hi, any Python experts here? It is about bug 153610. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed.
[08:45] <pitti> mvo, soren: could anyone test vm-builder in hardy-proposed, which rots there for 214 days already? If not, I'll just remove it from -proposed
[08:46] <mvo> pitti: I did the upload, but I can do the verification as well
[08:46] <pitti> mvo: much better than no feedback at all, and if you use the actual .deb from -proposed, and not a local build, and exercise a few standard cases, that would suffice
[08:46] <pitti> mvo: danke!
[08:47] <tkamppeter> Sorry, wrong bug. I mean the following: It is about bug 203808. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed.
[08:48] <tkamppeter> This only happens with Python programs which are not directly started by the user, like the system-config-printer applet which is auto-started on login or hal_lpadmin which is triggered by HAL.
[08:50] <pitti> tkamppeter: that bug is very old, and closed..
[08:50] <tkamppeter> pitti, I will look for other examples then ...
[08:51] <tkamppeter> pitti, bug 336707
[08:58] <asac> Hobbsee: hi. pong
[09:00] <Hobbsee> asac: greetings.  I presume you've been keeping tab on n-m bugs?  It seems there's a fair bit more tempramental (or plain broken) behaviour for multiple wifi cards, and I was wondering if you knew anything about it
[09:03] <pitti> tkamppeter: I think you can close them; I fixed s-c-p for python2.6 in 1.1.3+git20090218-0ubuntu4
[09:04] <asac> Hobbsee: hmm. depends. i know that there are still issues with some types WPA enterprise. Any particular wifi chipset you have issues with?
[09:05] <Hobbsee> asac: there was a broadcom mentioned earlier, and I was having temporary problems with my iwl3945 card
[09:05] <tkamppeter> pitti, the mentioned ones are on hal-cups-utils. Or is it because hal-cups-utils uses a lib of s-c-p?
[09:05] <pitti> aah
[09:06] <Hobbsee> asac: the broadcom got reported, I think i saw another couple in bugs, and I don't still have logs of my (now working) iwl3945
[09:07] <pitti> tkamppeter: yes, python-cupshelpers  is built by the s-c-p source (#336707)
[09:07] <pitti> tkamppeter: that should be good now
[09:07] <pitti> tkamppeter: the other two bugs fail on importing "usb"
[09:07] <pitti> thus they are different
[09:07] <pitti> tkamppeter: I don't have an usb.py on my box
[09:08] <asac> Hobbsee: yes, broadcom is one of the few drivers that is no in mainline kernel afaik ... which is bad as it cannot be fixed.
[09:08] <pitti> tkamppeter: so I think bug 291035 is real
[09:08] <Hobbsee> asac: ah, right
[09:08] <tkamppeter> pitti, so python-usb needs to be fixed, too? It is required by hal-cups-utils. Should I assign these bugs to python-usb then?
[09:08] <pitti> tkamppeter: maybe it's missing a dependency to python-usb?
[09:09] <pitti> oh, it's usb.so
[09:09] <pitti> $ python -c 'import usb'
[09:09] <pitti> works for me
[09:09] <pitti> tkamppeter: no, should be fine; doko rebuilt it on Sun, 22 Feb 2009
[09:10] <tkamppeter> pitti, I have checked and hal-cups-utils requires python-usb, it is the only package to keep python-usb in a standard installation.
[09:10] <pitti> tkamppeter: hm; no idea then, I'm afraid
[09:11] <pitti> tkamppeter: ah, look at Dependencies.txt in #291035
[09:11] <pitti> tkamppeter: he still has the old python-usb installed (not ubuntu1, which was the 2.6 rebuild)
[09:11]  * pitti hugs apport
[09:12] <pitti> tkamppeter: so, I'd reassign it to python-usb and close it with the last entry of /usr/share/doc/python-usb/changelog.Debian.gz
[09:18] <pitti> mvo: would you mind applying the intrepid SRU patch for compiz to jaunty, too? (bug 269805); it's an alpha-6 blocker
[09:19] <tkamppeter> pitti, I have simply closed this bug now with a comment added that the user should update.
[09:19] <pitti> tkamppeter: right
[09:20] <tkamppeter> pitti, I see another problem.
[09:21] <tkamppeter> I have kept s-c-p all the time identical to upstream and now there was a major patch done due to the notifications.
[09:21] <mvo> pitti: thanks, this is already in bzr
[09:22] <tkamppeter> What was the problem to have buttons in the notifications?
[09:22] <pitti> tkamppeter: right, please prod the dx team to forward the patch upstream
[09:22] <pitti> tkamppeter: notify-osd doesn't support actions in notifications
[09:22] <pitti> so they'd end up as dialogs
[09:22] <mvo> pitti: any word about the freeze exception for the compiz with protobuf support ? or should I wait for slangasek ?
[09:23] <tkamppeter> pitti, is this a Ubuntu policy or a GNOME policy?
[09:23] <pitti> tkamppeter: it's not a policy; by design, notify-osd doesn't support actions
[09:23] <pitti> tkamppeter: and libnotify doesn't promise that the implementation does
[09:23] <pitti> tkamppeter: s-c-p just assumed that it can; with the patch, it checks whether the notification daemon actually supports actions, and if not, it does something different
[09:24] <tkamppeter> pitti, and why is notifying system replaced by an inferior one only for eye-candy?
[09:24] <pitti> mvo: I didn't answer yet; a 0.5 MB impact on the CD for relatively little gain, after FF, and with new potential bugs due to new implementation doesn't exactly make me happy..
[09:24] <ion_> I don’t understand why notification-daemon couldn’t have been patched with the eyecandy.
[09:24] <pitti> mvo: but "pitti feels bad about it" might not be sufficient to say "no" :)
[09:25] <pitti> ion_: (1) the patch would exchange the entire code, and (2) we want the original n-d to be available, too
[09:25] <mvo> pitti: well, startup improvement gain of 20-30% is not "relatively little"
[09:25] <pitti> tkamppeter: it's not just eye candy, but a new usability design
[09:26] <mvo> pitti: but I certainly understand this
[09:26] <pitti> mvo: I'm actually more concerned about changing the entire underlying configuration parsing structure that late
[09:26] <pitti> if we can spare the space on the CDs, I'm fine with it, but I'd really like to have slangasek decide that
[09:27] <mvo> pitti: sure, I wait for him. if we do it, we should do it today IMO
[09:27] <pitti> yes, indeed
[09:27] <tkamppeter> piiti, would "if os.environ.get('GDMSESSION') == "gnome-stracciatella":" also work on non-Ubuntu distros to check whether the notify daemon is capable of actions?
[09:28] <tkamppeter> pitti: ^^^
[09:29] <pitti> tkamppeter: no, please don't ever use that outside of Ubuntu
[09:29] <pitti> tkamppeter: it's meant for something entirely different
[09:30] <pitti> tkamppeter: for checking action support, you need to call
[09:30] <pitti> GList *notify_get_server_caps(void);
[09:30] <pitti> (/usr/include/libnotify/notify.h)
[09:30] <tkamppeter> Is there a possibility for a Python program to check whether the notification daemon supports actions?
[09:30] <pitti> (this also exists in python-notify)
[09:31] <tkamppeter> pitti, then the patch should be changed to that.
[09:31] <pitti> tkamppeter: indeed it should
[09:31] <pitti> kenvandine_wk: ^
[09:32] <pitti> tkamppeter: thanks for pointing out
[09:33] <tkamppeter> pitti, kenvandine_wk: With this fixed I would commit the patch upstream.
[09:34] <pitti> tkamppeter: if it checks server caps, it absolutely makes sense to commit it to upstream, since this is a real bug (assuming that actions are supported without testing for them)
[09:34] <pitti> tkamppeter: the stracciatella test is an ubuntu specific hack and should remain Ubuntu patches
[09:54] <tkamppeter> pitti, I have reported bug 339847 on the s-c-p notification problem.
[09:55] <pitti> tkamppeter: thanks; please assign to ken-vandine
[09:56] <tkamppeter> pitti, I have already done so.
[09:58] <hayalci> Hi, any chance that flashplugin-nonfree gets some love ? :) https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/304969/
[10:16] <cjwatson> calc: GPT is the default when creating a new partition table on some (sub)architectures, of course (ia64 and Intel-based Macs), but without some way to detect whether the BIOS supports it we can't make it the default
[10:17] <cjwatson> calc: I hate the DOS partition table format as much as anyone else sensible does, but I don't much like the idea of either breaking support for anything that isn't incredibly new, or having to ask an unintelligible question
[10:17] <directhex> cjwatson, detecting EFI?
[10:18] <cjwatson> I guess looking for /sys/efi or whatever might work, but ...
[10:18] <cjwatson> we do already use gpt for disks larger than 2TB
[10:19] <directhex> except it gets more complex when using BIOS emulation
[10:19] <cjwatson> indeed
[10:19] <directhex> i.e. my mac has no /sys/firmware/efi
[10:19] <directhex> my altix does
[10:19] <cjwatson> isn't support for /sys/firmware/efi in a kernel module?
[10:19] <cjwatson> efivars or some such
[10:20] <cjwatson> but yes, BIOS emulation on Macs does throw a spanner in the works, and the installer has a special case for Intel-based Macs for that reason
[10:20] <cjwatson> I don't know whether the same goes for modern non-Mac x86 hardware
[10:21] <directhex> i think MSI are the ones beginning to put EFI on their motherboards
[10:21] <directhex> most don't
[10:22] <cjwatson> for Macs it's easy; we do the equivalent of dmidecode and see if it says Apple ...
[10:22] <cjwatson> but I'm not about to go hardcoding that for every BIOS manufacturer on the planet
[10:23] <directhex> i thought it might help to know who was at it :/
[10:23] <directhex> aren't MSI canonical partners? i thought their netbook was ubuntu based
[10:23] <directhex> you could try & get ahold of one of their boards to take a peek
[10:25] <directhex> elilo sucks, though. that's unfortunate
[10:26] <cjwatson> mm, I'm not exactly overflowing with space for more hardware
[10:27] <cjwatson> realistically I suspect EFI systems are an excuse to try out grub2
[10:27] <ion_> Incidentally, i installed grub2 recently. Seems to work fine. :-)
[10:27] <ion_> (jaunty)
[10:27] <cjwatson> we should have a wiki page with success/failure plus actual hardware details
[10:28] <ogra> cjwatson, just expense a new house :P
[10:28] <cjwatson> slangasek: were you going to set up something like that as part of the grub2 spec?
[10:28] <cjwatson> ogra: now there's an idea
[10:28] <ogra> :)
[10:29] <directhex> my shiny new muddleboard has no EFI... MSI warranties were inferior
[10:31] <davmor2> Guys testing 20090309 the sound is crackly but it only seems really bad on the login music.  I've had a quick look at https://wiki.ubuntu.com/DebuggingSoundProblems but I can't see anything for debugging the login sound.
[10:41] <ion_> keybuk: How soon will we get module-init-tools 3.7~, btw? :-)
[10:41] <seb128> slangasek: can we get freetype 2.3.8 in jaunty? ;-) it fixes evince rendering issues
[10:42] <pitti> seb128: bug fix only release?
[10:43] <seb128> pitti: "This is a bugfix release for the 2.3 series. All users should upgrade." is what is writting  on the website
[10:43] <pitti> seb128: if the changelog confirms this, then this doesn't need any exception; bug fixes are fine
[10:43] <seb128> pitti: I don't plan to do the update, slangasek is the debian maintainer for it, I was just suggesting that he should have a look at doing the update ;-)
[10:44] <pitti> ah, I see
[10:44] <seb128> just tried it to confirm it fixes evince displaying wrong chars on some documents
[10:48] <seb128> where is doko?
[10:48] <seb128> bug #339337
[10:48] <directhex> hiding
[10:48] <seb128> slangasek: ^  that's due to the python-numpy change
[11:00] <TheMuso> asac: I see why bug 278095 is appearing again, seems I clobbered your patch. :p uploading the re-introduced patch now
[11:03] <asac> TheMuso: yeah. you also clobbered the changelog ;) (not nice)
[11:03] <TheMuso> No I know. I'm putting it back in as well
[11:03] <asac> TheMuso: so upstream redid most of the code, but ignored our bug :(
[11:03] <asac> TheMuso: well. the patch doesnt apply anyway
[11:03] <asac> TheMuso: let me give you a new proposed patch
[11:03] <TheMuso> asac: ok, won't adjusting the current patch to the new code work, or will that only break things further?
[11:04] <asac> TheMuso: http://pastebin.com/f2fa4dd57
[11:04] <TheMuso> because if the former, I can do that here
[11:04] <TheMuso> oh ok thanks
[11:04] <asac> TheMuso: try that.
[11:04] <asac> TheMuso: i am not sure if it works, but i would think so ;)
[11:04] <TheMuso> ok
[11:04] <asac> TheMuso: can you read https://bugzilla.mozilla.org/show_bug.cgi?id=460926
[11:05] <TheMuso> ok I'll have a look
[11:05] <asac> TheMuso: and tell me if that means that we shouldnt use at-spi at all in firefox?
[11:05] <asac> TheMuso: i think their fix does just opt-out from at-spi
[11:05] <asac> TheMuso: so if we do that we might not even need the AT_SHUTDOWN patch
[11:05] <TheMuso> right, I don't know enough about that to coment whether we should be using at-=spi or not
[11:06] <asac> TheMuso: yeah. lets both read the mozilla bug and discuss later today or tomorrow what to do ;)
[11:06] <TheMuso> ok
[11:12] <TheMuso> asac: I am going to try your patch anyway, because I want to see if it corrects some other behiavior I am seeing in GNOME itself...
[11:13]  * ogra wonders, if i have a system with an empty modules.dep it seems module-init-tools still gives me a "no such file or directory"
[11:13] <asac> TheMuso: hmm are there crashes elsewhere?
[11:13] <TheMuso> asac: No crashes, but thigns not being accessible...
[11:14] <asac> TheMuso: i would think that this patch is really just for crahes at shutdown
[11:15]  * ogra wonders why that is, at least the error should be different
[11:15] <TheMuso> asac: that new patch of yours is already applied...
[11:16] <TheMuso> asac: ah ok. Anyway it seems the first 2 hunks are already present, but hunk 3 fails to apply, so I'll look over the bug more closely later and we can chat about it when I'm more awake. :)
[11:17] <asac> TheMuso: first two hunks? are you talking about the original patch we had?
[11:18] <TheMuso> asac: no, the one you pastebinned.
[11:19] <asac> TheMuso: i dont understand. i did an apt-get source like 1h ago
[11:19] <asac> TheMuso: how can it not apply?
[11:19] <TheMuso> ok i'll double check
[11:19] <TheMuso> yep it applies, I wasn't doing things properly.
[11:35] <seb128> hey doko
[11:58] <ogra> cjwatson, uboot-mkimage made it to main without MIR ? can we do the same for flash-kernel ?
[11:59] <Keybuk> ion_: as soon as I've cleared out everything that it depend son
[11:59] <ogra> (it fulfills a very special usecase only, so i would expect thats ok)
[12:01] <cjwatson> ogra: I'm fairly sure that somebody on the MIR team looked over it. Please don't ask me to work around that
[12:01] <ogra> ok
[12:01]  * ogra writes a MIR then
[12:02] <tkamppeter> pitti, I see that the notifications patch for s-c-p seems to be originally created by David Barth and not by Ken VanDine, Ken only packaged it (see bug 328604). Should I assign bug 339847 to David?
[12:03] <tjaalton> has falcon been removed from jaunty?
[12:05] <persia> tjaalton, bug #336389
[12:05] <tjaalton> pitti: sigh, ok
[12:05] <tjaalton> need to look for a replacement then
[12:06] <persia> Or just port the django :)
[12:06] <tjaalton> less likely ;(
[12:06] <tjaalton> oops, ;)
[12:07] <persia> For distribution, you might switch to a PPA.  For auto-source-building, you might look at deb-o-matic.
[12:07] <tjaalton> I can't dump matlab etc to a PPA :)
[12:08] <persia> Ah, no :)
[12:08] <tjaalton> well, hardy still has it, so it's not urgent
[12:14] <tkamppeter> kenvandine_wk: Can you have a look at bug 339847? I want to upstreamize the notification patch, but it needs a proper generic detection of the notification daemon type. Can you fix that? Thanks.
[12:14] <kenvandine_wk> tkamppeter: i agree, will work on that
[12:15] <tkamppeter> kenvandine_wk: Thanks in advance.
[12:15] <kenvandine_wk> :)
[12:15] <kenvandine_wk> tkamppeter: sorry i didn't catch it when we were pushing it through... seems pretty obviously wrong now
[12:53] <Keybuk> I noticed an interesting side effect of the "YOU HAVE UPDATES!" behaviour today
[12:54] <Keybuk> if you run apt-get update, and it's been a while, that triggers the window of death
[12:54] <Keybuk> which makes you more inclined to use it than running apt-get again ;)
[12:54] <directhex> the window of death can kiss my wookie
[12:54] <directhex> just because OSX does it, doesn't make it right
[12:56] <Keybuk> directhex: just use sreadahead instead of readahead-list
[12:56] <Keybuk> then it freaks out that you've manually broken ubuntu-desktop's deps and won't do anything <g>
[13:00] <wgrant> Is publisher broken?
[13:00] <wgrant> There are binaries 3.5 hours in ACCEPTED.
[13:00] <wgrant> s/hours/hours old/
[13:00] <wgrant> And sources approaching 2 hours old that I can see.
[13:06] <KaiL> already any plans how to get 3D accelleration for ATI GPUs in 9.04? I guess, "radeonhd" isn't really usable?
[13:12] <cjwatson> wgrant: something to do with ports.ubuntu.com mirroring freaking out, I think
[13:13] <wgrant> cjwatson: Ah, wonderful...
[13:13] <cjwatson> wgrant: I believe the root cause has been fixed, but some state cleanup is going to be needed as the publisher's crashing now
[13:13] <directhex> KaiL, the plan is "panic until april, then force people to use one of the slow Free drivers"
[13:13] <wgrant> cjwatson: Eww.
[13:13] <wgrant> Sounds lovely.
[13:14] <KaiL> directhex, so you guess, there might be hope to get ATI to do their work? ;)
[13:14] <directhex> KaiL, if they feel like it
[13:15] <tjaalton> they are going to drop support for anything older than r6xx
[13:15] <directhex> KaiL, superm1 is keeping on top of what's working and what isn't
[13:15] <cjwatson> it's trying to republish kde4libs 4.1.4-0ubuntu1~intrepid1.1
[13:15] <tjaalton> at least according to phoronix
[13:15] <KaiL> tjaalton, yes, and definitly not adding X-Server 1.6 this month
[13:16] <KaiL> (was just a news on heise.de)
[13:16] <directhex> sodding ATI
[13:17] <KaiL> so for R300-R500 the default can be changed to "radeon" today...
[13:17] <KaiL> which gives at least 2D acc and a rather slow 3D
[13:18] <Amaranth> KaiL: It's not that slow
[13:18] <KaiL> situation on GPUs is getting much worse these days; intels GMA 500 is another problem: last driver ran on 7.10
[13:18] <directhex> "older than r600" seems highly excessive - 2k-series radeons?
[13:19] <directhex> KaiL, yes, poulsbo is junk. blame powervr.
[13:19] <KaiL> 2k Serie will still be supported
[13:19] <directhex> yeah, but not 1k?
[13:19] <KaiL> no 1k, no Xxxx, no 9xxx
[13:20] <KaiL> or in very short: support droped for all non-DX10-chips
[13:22] <KaiL> Amaranth, afaik even fglrx is far behind Windows performance, so how much worse is the free one?
[13:22] <KaiL> power consumption will be another problem; esp. on Laptops
[13:23] <Amaranth> KaiL: fglrx should be close to the windows version, radeon should be about 70% of that, power usage is a little higher than fglrx but not much and will get better
[13:23] <Amaranth> I never did any benchmarks on my X1400 or whatever though, so that's all from phoronix :P
[13:24] <directhex> i'm planning on doing some benchmarking actually
[13:24] <directhex> i have a gtx260 and a radeon 4870 to test with
[13:24] <KaiL> I remember my old 9250, where page flip helped a lot ;)
[13:24] <directhex> i have a PPA with latest radeon/nvidia in it, for intrepid, which will help
[13:25] <KaiL> I guess, the radeon-driver from intrepid might differ quite a lot from the ones in jaunty ;)
[13:25] <KaiL> .o0(I hope, in the right direction ;)
[13:25] <directhex> well, fglrx anyway
[13:26] <directhex> i wish there were more engines to test with though. where's freaking UT3? o_o
[13:26] <KaiL> the "Unigine" test might be interesting ;)
[13:27] <KaiL> "Tropic" should land arround 13,5 with fglrx, so that's quite demanding
[13:30] <directhex> yes, ungine is one i've got
[13:30] <directhex> and there's etqw as the latest id tech engine one
[13:30] <directhex> but what else?
[13:30] <KaiL> Nexuiz?
[13:31] <KaiL> based on Q1, but much extended
[13:32] <ArneGoetje> slangasek: 1. a full export from Rosetta for the -base langpacks puts significant stress onto the Launchpad database. The last export took almost 3 days to complete. The resulting tarball is about 500MB in size. The converting into language packs on rookery takes about 3.5 hours then, plus the buildds take another 2 days or so to build all the -base packs.
[13:32] <ArneGoetje> slangasek: 2. the users will have to download the full set of translations every time, instead of just a few kB of diffs.
[13:33] <directhex> nah, no offense to the developers, but a nexuiz benchmark is worhtless. doesn't do anything in a remotely modern way, wouldn't stress a modern gpu in a sensible manner
[13:34] <KaiL> Prey is another id tech afaik, but maybe newer than etqw
[13:38] <KaiL> directhex, maybe UT2004? Better than no UT engine at all
[13:38] <directhex> hm, unigine is really spot on for this.
[13:39] <KaiL> hehe
[13:39] <KaiL> looks great, but eats TFlops for breakfast ;)
[13:40] <seb128> doko, slangasek: bug #339337 due to the pygtk, numpy change
[13:40] <directhex> KaiL, my benchmarking machine is a core i7 with 6 giggles of ram. should hopefully be gpu-limited
[13:40] <KaiL> I guess yes
[13:40] <KaiL> I know, that in a 4GHz C2Q eben Quad-SLI is GPU limited
[13:41] <KaiL> even
[13:41] <tjaalton> Riddell: hey, you aware of bug 337791?
[13:45] <tjaalton> Riddell: installing kde-devel fails, so cmake needs to depend on emacsen-common (a merge would do)
[13:53] <ScottK> tjaalton: Riddell is on travel at a conference AFAIK.
[13:53] <ScottK> tjaalton: If you haven't, would you please comment in the bug and I'll see if I can get someone to look at it.
[13:54] <doko> seb128: fgrep -r multiarray /usr/share/python-support/gnome-games-data/gnome_sudoku doesn't show anything
[13:54] <slangasek> mvo, pitti: enabling protobuf is almost certainly going to cost us a langpack on one or more CDs, unless we find something else to offset it.  Are there some help translations we can split?
[13:54] <tjaalton> ScottK: sure, thanks
[13:54] <kirkland> siretart: absolutely;  i was planning on doing that as soon as jaunty hit beta freeze
[13:55] <slangasek> cjwatson: wasn't planning to set up a wiki page for it, so much as figure out how to leverage the hardware DB
[13:55] <kirkland> siretart: it should be stable enough at that point to get it into backports
[13:55] <kirkland> siretart:  in the meantime, there is a ppa set aside for it: https://edge.launchpad.net/~screen-profiles/+archive/ppa
[13:56] <kirkland> siretart: as for debian, that would be really cool too, if there's a DD out there who wants to run with it, i'm happy to help
[13:56] <seb128> slangasek: what do they want to add to the CD?
[14:01] <slangasek> seb128: ah, all we need is freetype 2.3.8?  easy-peasy
[14:01] <slangasek> (IIRC 2.3.8 is /not/ the version they recalled due to ABI breakage :)
[14:02] <seb128> slangasek: "all" dunno, not sure if that fix the crasher from the other day but that fixes bug #330438
[14:02] <slangasek> seb128: aha, gotcha
[14:02] <seb128> I did try locally using a ./configure && make && LD_PRELOAD
[14:04] <slangasek> seb128: add to the CD> compiz wants protobuf, a huge C++ library to speed up startup
[14:04] <slangasek> seb128: (huge ~= 500KB)
[14:04] <seb128> ah ok
[14:04] <slangasek> seb128: is that something you could make room for?
[14:04] <calc> cjwatson: the post i read on tytso's blog indicated if grub was in the MBR that GPT would work regardless of if you have EFI or not, but only for linux, Vista can read GPT but only boot from it if you have EFI which was why it wouldn't work for dual boot situations
[14:05] <seb128> slangasek: we could make room, ie split gnome-games documentation for example, but how much speed win is that? ie is that worth the effort?
[14:05] <seb128> I would not want to drop translations for 0.5 second win
[14:05] <KaiL> calc, wasn't it, that Vista 64 requires GPT?
[14:06] <pitti> tkamppeter: I think kenvandine_wk can negotiate that with david
[14:06] <Keybuk> seb128: multiple seconds
[14:06] <Keybuk> I've benchmarks that say it cuts compiz startup from 9s to 3s
[14:06] <pitti> slangasek: splitting help translations is quite a lot of manual packaging work; I'd try my luck with lzma first
[14:06] <seb128> Keybuk: are you sure? the code mvo made me tried the other day was winning 0.5 seconds I think
[14:06] <Keybuk> seems to cut an average of 3-5s across the different bits of hardware I have
[14:06] <calc> KaiL: no from what i read vista can only boot from GPT if your system uses EFI which other than Macs is very rare
[14:06] <Keybuk> seb128: what hardware did you try it on?
[14:06] <mvo> seb128: well, 0,5s from a 1s startup :)
[14:06] <slangasek> pitti: well, do we have a current list of packages that benefit from lzma?
[14:07] <seb128> Keybuk: that was hot cache login though so not really revelant
[14:07] <mvo> seb128: it got me 1s (from 3s to 2s). but the mini9 takes a bit longer to start compiz
[14:07] <pitti> slangasek: not ATM
[14:07] <seb128> one CD limitation starts being *really* annoying
[14:07] <tkamppeter> pitti, according to what Ken told some hours ago here on IRC he will look into it.
[14:07] <calc> slangasek: doing the lzma bit shouldn't be too hard for someone who has an alternate disk
[14:07] <mvo> seb128: I can help with the split
[14:07] <Keybuk> seb128: which reminds me, I have some boot-performance related patches for nautilus and gnome-panel ;)
[14:07] <Keybuk> I'll send them upstream, obv.
[14:07] <pitti> slangasek: I'll look at the current alternate and check out the biggest ones for potential savings
[14:08]  * calc thinks we should just flip a switch on the buildds to default to using lzma :)
[14:08] <slangasek> pitti: and lzma doesn't help us for desktop CDs, of course, which is where we've been having trouble keeping langpacks on
[14:08] <tkamppeter> pitti, I have also passed through an Apport crash report on Jockey now, triggered by Plug'n'Print.
[14:08] <pitti> slangasek: oh, good point
[14:08] <seb128> Keybuk: what sort of changes?
[14:08] <Keybuk> seb128: removing nautilus's fade-in of the background image on initial startup
[14:08] <seb128> Keybuk: please give me the bug numbers when you do so I can track that and do some nagging ;-)
[14:08] <calc> pitti: iirc one of the gl libs was a big saving if it hasn't been converted yet
[14:08] <Keybuk> seb128: removing gnome-panel's slide-in of the panel on initial startup
[14:08] <Keybuk> because we are not 5 years old, and those two patches add 7s to the boot!
[14:08] <calc> pitti: but it has been 2 years since i looked at it so things will have changed since my test
[14:08] <Keybuk> (take off 7s, that is)
[14:09] <pitti> calc: I think we already did that
[14:09] <calc> pitti: ok
[14:09] <seb128> Keybuk: urg, 7 seconds seems a lot, my GNOME login time is around 20 seconds nowadays
[14:09] <wgrant> Keybuk: Thankyou! They always look crap unless everything's cached already anyway.
[14:09] <tkamppeter> slangasek, what about bug 335116
[14:10] <seb128> Keybuk: can you please open the nautilus bug now? alex is going to roll new tarballs today most likely, could be nice to get before those and the code freeze for 2.26
[14:10] <Keybuk> seb128: I'll open it today
[14:10] <seb128> thanks
[14:10] <Keybuk> likewise for gnome-panel
[14:10] <Keybuk> the nautilus patch is the cause of the compiz black screen on startup, btw ;)
[14:10] <tkamppeter> slangasek, anything still needed? I have tested and all GUI apps seem to still work correctly.
[14:11] <Keybuk> turns out that sending 100s of slightly different massive textures at compiz while it's starting is not a plan made entirely of win
[14:11] <Keybuk> nautilus feature, I should say
[14:11] <slangasek> tkamppeter: mmm, you didn't write to the bug that you'd tested, your last mail said "please test" :)
[14:11] <tkamppeter> I hoped to get Linus also to test, but he is probably not listening any more.
[14:12] <slangasek> tkamppeter: if it's tested, then that's fine for an FFe, yes
[14:12] <jcastro> Keybuk: sucks that that adds so much time, I was quite liking the way the panels looked when I logged in
[14:12] <Keybuk> jcastro: fwict, you're lucky to see any kind of animation at all
[14:13] <Keybuk> this kind of thing is far better done with KMS anyway
[14:13] <Keybuk> then you can have all sorts of snazzy "fade/skew/slide/bounce in the desktop when it's ready" effects
[14:13] <Keybuk> (ie. don't repaint from gdm to desktop)
[14:14] <siretart> kirkland: does that mean you're looking for a sponsor to upload it to unstable? - or for DD to take over maintenance in debian?
[14:14] <kirkland> siretart: both, i think
[14:14] <jcastro> Keybuk: ah so it's entirely feasable for this to come back at some point in the future?
[14:14] <kirkland> siretart: the package compiles and runs fine on debian
[14:15] <kirkland> siretart: a couple of lines of packaging would be needed to make the debian build do the debian profiles, and the ubuntu build do the ubuntu profiles
[14:15] <kirkland> siretart: but that's trivial, i'll do that
[14:15] <mvo> slangasek: if I get your ok, I would like to upload the compiz changes today so that it lands in time for alpha6 - its now officially released so it will not be 0.7.9+git but nice version numbers instead :)
[14:15] <kirkland> siretart: i don't really have time or interest though in maintaining the package in debian too
[14:15] <siretart> kirkland: well, how about keeping you as maintainer and me in uploaders for the package? do you perhaps even have an debian packaging branch ready?
[14:16] <kirkland> siretart: i don't ... let me add that bit of logic as to inserting the @ or the \o/ logo in the profile
[14:16] <kirkland> siretart: after that, the build should just 'work' in debian
[14:16] <kirkland> siretart: the build would just need to version it properly in dch for debian
[14:17] <kirkland> siretart: are you DD?
[14:17] <siretart> kirkland: ok, in that case, I'll file an ITP now and wait for you to tell me what bzr branch we will use for the debian package, OK?
[14:17] <siretart> kirkland: yes, I'm a DD
[14:17] <kirkland> siretart: excellent, that sounds perfect ;-)
[14:18] <seb128> siretart: hello, did you read my comment before?
[14:18] <siretart> seb128: I think I've skipped it, could you repeat, please?
[14:18] <seb128> slangasek: oh, the freetype update also fixes the crasher
[14:18] <slangasek> seb128, mvo, pitti: if nothing else changes in size, we *currently* have room for protobuf without dropping any langpacks; do you think it's reasonable to reclaim that space somewhere after alpha6?
[14:19] <seb128> siretart: I was asking if you know if anybody look at the ffmpeg-debian bugs in launchpad, the jaunty version seems to be crashland
[14:19] <slangasek> seb128: ah great, I'll make sure I get that packaged up today.  Do you have a bug number for the rendering issue?
[14:19] <seb128> slangasek: can we have an estimation of what language packs we have, which ones we could add by making some space and how much we need by language?
[14:20] <seb128> slangasek: bug #330438
[14:20] <siretart> seb128: I've noticed that a huge bunch of crashed were reassigned to ffmpeg, but I really suspect that most of them are actually caused by gstreamer0.10-ffmpeg
[14:20] <seb128> slangasek: bug #277294 is the crasher
[14:20] <siretart> seb128: every one I've seen so far miss an example file to demonstrate the crash
[14:20] <slangasek> seb128: on liveCD, we're currently down to en es xh on amd64 and en es xh pt de fr on i386
[14:20] <Keybuk> bryce_: around?
[14:20] <slangasek> seb128: pitti has a langpacksize script that says how much space each of those needs; I don't remember the original source for the script
[14:20] <pitti> slangasek: cd /usr/share/gconf/schemas; cat ekiga.schemas epiphany.schemas gnome-search-tool.schemas desktop_gnome_url_handlers.schemas | gzip -9 | wc -c
[14:20] <pitti> 608904
[14:21] <siretart> seb128: and since I have no idea about the gstreamer0.10-ffmpeg codebase (but a bit of ffmpeg), I fear there is not much I can do about them other than trying to reproduce them with ffplay
[14:21] <slangasek> seb128: but it's roughly 9MB for pt, 5MB for de, 6MB for fr
[14:21] <seb128> siretart: why do you think that's due to gst-ffmpeg?
[14:21] <pitti> slangasek: in other words, by rebuilding four packages, we should be able to claim back 600 KB
[14:21] <seb128> siretart: there is several bugs with example and valgrind logs which show libavcodec issues
[14:22] <siretart> seb128: because I know that gst-ffmpeg uses quite a bunch of ffmpeg internals that are not supposed to be used externally
[14:22] <pitti> seb128: langpacksize: http://people.ubuntu.com/~pitti/scripts/langpacksize
[14:22] <slangasek> pitti: if you think that's reasonable, then I'm ok to have mvo upload the protobuf change
[14:22] <pitti> seb128: orignal is in bzr get lp:langpack-o-matic
[14:22] <seb128> slangasek, pitti: thanks
[14:22] <siretart> seb128: and slomo regularily tells me about problems when I update ffmpeg
[14:22] <pitti> slangasek: yes, I want to rebuild those packages with large gconf translation trees anyway, to downsize them
[14:22] <seb128> siretart: seems we need better coordination there then
[14:22] <slangasek> mvo: ok, please go ahead with protobuf for alpha6
[14:22] <pitti> slangasek: ekiga alone will give us 270 KB
[14:22] <pitti> slangasek: I'll upload a rebuild
[14:23] <mvo> thanks slangasek and pitti \o/
[14:23] <siretart> seb128: of course valgrind reports problems in avcodec. But since avcodec is a *decoding* library, it's really a garbage in - garbage out problem
[14:23] <siretart> valgrind cannot possibly know if gst-ffmpeg is passing garbage to avcodec
[14:23] <slangasek> seb128: if we want to be able to get de or fr onto amd64 desktop, though, we still need to find more savings :(
[14:23] <seb128> siretart: ok, so you are not happy with stacktrace + valgrind + example, what else do you need?
[14:23] <slangasek> (just a little bit - less than 1MB)
[14:23] <siretart> and that's why I have to insist to have example files attached
[14:23] <seb128> slangasek: I will have a look to how much gnome-games split would give us
[14:23] <slangasek> (unless we want both, then we need 8MB :)
[14:23] <siretart> seb128: I need the bug to be reproducible with ffplay
[14:24] <pitti> slangasek: ah, on the desktop CDs, the savings of those rebuilds will be bigger, since it also affects /var/lib/gconf/defaults/
[14:24] <slangasek> pitti: great :)
[14:24] <siretart> then I can forward it upstream, but not earlier, unfurtunately
[14:24] <seb128> siretart: bug #339854 has a video available for download
[14:24] <seb128> siretart: it's a bit big for my download speed but if you can give it a try
[14:25] <siretart> seb128: yeah, such huge example files are really a PITA. in most case the first few MB are sufficient to expose the bug
[14:25] <siretart> another reason why I have to insist to have the example files *ATTACHED* to the launchpad report, not only linked
[14:26] <seb128> siretart: can you ask for that on this bug? using dd should do the trick?
[14:26] <seb128> siretart: bug #335595 has an example too
[14:26] <seb128> and bug #335595
[14:26] <siretart> seb128: see also http://ffmpeg.org/bugreports.html, section "Submitting Sample Media"
[14:27] <siretart> seb128: the video referenced from bug #339854 works just fine with ffplay.
[14:27] <slangasek> dendrobates: ubuntu-server ISOs are still 8MB oversized
[14:28] <slangasek> (well, 7 and change)
[14:29] <siretart> seb128: video from bug #335595 works fine for me as well
[14:29] <dendrobates> slangasek: I am checking it now.
[14:29] <seb128> siretart: ok, so basically totem and rhythmbox are crash land in ffmpeg code and that's nobody's problem, great
[14:29] <ogra> slangasek, you are ubuntu-mir as well, right ?
[14:29] <slangasek> ArneGoetje: thanks for clarifying wrt the -base problem.  That makes sense, even though it makes it harder to estimate for alphas
[14:29] <slangasek> ogra: nope
[14:29] <siretart> seb128: and that's a pretty common experience I have with these forwarded bugs. in the last weeks, I focused on getting ffmpeg updated to 0.5 and started to work on mplayer rc3
[14:30] <ogra> meh
[14:30] <siretart> seb128: no, that's not what I've said
[14:30] <calc> seb128: do you know when we will have 2.26.0, after alpha 6 correct?
[14:30] <siretart> seb128: I've said the problem is most likely in gst-ffmpeg having broken demultiplexers and feeding garbage to libavcodec
[14:30]  * ogra tries to fins a -mir person to approve bug 339947 before A6
[14:30] <seb128> siretart: yeah, let's focus on making a player which we ship with no ubuntu flavor be stable and don't bother about everything else
[14:30] <ogra> *find even
[14:30] <seb128> siretart: sorry I'm slightly frustrated, I should calm down before continuing this discussion
[14:31] <siretart> seb128: I see
[14:31] <ogra> oh, lool is -mir, i didnt know
[14:31] <seb128> the end result is the same, totem and rhythmbox are crash land and nobody bother
[14:31]  * ogra grins widely in lool's direction ... 
[14:31] <seb128> calc: yes
[14:31] <siretart> seb128: what would be really helpful would be someone knowledgable of gst-ffmpeg internals
[14:32] <jcastro> seb128: can you look at python-webkitgtk sometime? I think it's in NEW
[14:32] <seb128> jcastro: why is it in NEW?
[14:32] <jcastro> binary NEW?
[14:32] <calc> seb128: ok thanks :)
[14:33] <siretart> seb128: I could turn it the other way round: remove gst-ffmpeg from those systems, and the crashed would dissappear as well: most of the presented videos won't work in totem at all and all folks would be using vlc instead (the package I've been working on before mplayer and ffmpeg)
[14:34] <jcastro> seb128: I think it was renamed? https://edge.launchpad.net/ubuntu/jaunty/+source/pywebkitgtk/1.0.2-1ubuntu1
[14:35] <seb128> jcastro: sorry I've a zillion of things going on right now, any urgency there?
[14:35] <seb128> siretart: that would not be the other way round, that's still "let's screw users who run ubuntu softwares"
[14:35] <siretart> seb128: and as for 'frustration', I'm slightly frustrated as well about the load of unreproducable crashers that are beeing reassinged to ffmpeg as well
[14:35] <jcastro> seb128: we're blocking a gwibber upload but it's not critical, is there someone else I can ping?
[14:36] <pitti> slangasek: while we are at CD space hog confessions, I also need to work on bug 335888, i. e. add some more themes
[14:36] <seb128> jcastro: you can let archive admin do their work when they have a free slot, or try another member of the team, today is slangasek's day
[14:36] <pitti> slangasek: not necessarily for a6, though
[14:36] <jcastro> seb128: ah ok, I didn't know there was a rotation, thanks
[14:36] <dendrobates> cjwatson: open-iscsi-udeb depends on scsi-modules-2.6.28-2-386-di which pulls in the old kernel.  Can you fix?
[14:37] <siretart> seb128: uh, I think an incapable player that can be replaced with a capable one is slightly less frustrating than having to replace a crashing one with a capable one. but YMMV, of course
[14:37] <slangasek> pitti: what will that cost us (in MB or in bloodpressure)? :)
[14:37] <pitti> slangasek: don't worry, just about 10 MB
[14:37]  * pitti sees slangasek jump
[14:37] <pitti> slangasek: let me check
[14:37] <slangasek> pitti: I think you mean "lunge" :-)
[14:37] <geser> jcastro: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[14:37] <seb128> siretart: it would help if somebody would go through those bugs and write wiki instruction on how to triage specific cases
[14:38] <slangasek> dendrobates: I thought that open-iscsi-udeb dep was going to go away?
[14:38] <pitti> slangasek: oooh, F***
[14:38] <seb128> siretart: or are least triage some bugs as an example and give a pointer on the bugsquad list
[14:38] <pitti> slangasek: I shouldn't have said that; I expected some 300 KB
[14:38] <jcastro> geser: sweet, thanks for that
[14:38] <slangasek> (didn't I have a discussion with kirkland about this @ the sprint?)
[14:38] <seb128> siretart: right know bug triagers have no clue about what to do with those bugs and ffmpeg maintainers ignore most of those because they don't have the requested informations
[14:38] <pitti> slangasek: but Ken attached a 5.3 MB tarball
[14:38] <slangasek> haha
[14:38] <pitti> slangasek: oh, but hang on, not everything is needed by default
[14:39] <pitti> slangasek: okay, should be about 800 KB
[14:39]  * slangasek nods
[14:39] <pitti> slangasek: I'll work on adding the themes to gnome-themes-extra today, but I won't do the seed change for a6
[14:39] <siretart> seb128: oh, I remember having tried that before, with very little success :(
[14:39] <slangasek> pitti: ack, thanks
[14:39] <pitti> slangasek: after I did the packaging, I have a precise idea about the size
[14:40] <kirkland> slangasek: i remember discussing it;  don't remember the conclusion; do remember that we couldn't make any change at the moment due to the freeze :-)
[14:40] <seb128> siretart: trying what? triaging some? if you do email bugsquad to let them know what to use as example
[14:40] <seb128> siretart: or to point to the wiki guidelines
[14:40] <seb128> siretart: I don't think i've read any emails about this before
[14:40] <siretart> seb128: however that involved rather xine + ffmpeg. perhaps (if I find the triaging instructions of ffmpeg in the wiki) I can try to improve them again
[14:40] <seb128> siretart: I for one would be happy to use stock replies when reassigning
[14:40] <slangasek> kirkland: hrm, I don't remember that, I would've happily given the go-ahead for the open-isci change - but maybe we were waiting for a kernel change first
[14:41] <siretart> seb128: where would you expect the stock reply for an incomplete ffmpeg bug to be found?
[14:41] <seb128> siretart: https://wiki.ubuntu.com/Bugs/Responses
[14:42] <seb128> siretart: it has a "xine-lib and ffmpeg bugs" section already
[14:42] <seb128> siretart: should that be used for gstreamer crashers as well
[14:42] <siretart> aah, these are the notes I've been looking for as well
[14:43] <siretart> seb128: I'd suggest the xine part to be removed, and ahve it applied to *ALL* bugs being reassigned to ffmpeg
[14:43] <seb128> ok
[14:43] <seb128> pedro_: ^ can you get that done?
[14:44] <seb128> pedro_: not sure if bugsquad discuss changes for this page or directly edit
[14:44] <slangasek> kirkland, dendrobates: oh, but it's amd64 that's the oversized image, so scsi-modules-2.6.28-2-*386*-di isn't relevant there?
[14:44] <slangasek> (not that we shouldn't trim it anyway...)
[14:45] <tkamppeter> slangasek, HPLIP 3.9.2 uploaded.
[14:45] <pedro_> seb128: yes no problem, no need to discuss such changes if the person who take care of those bugs is requesting that, i'll do it
[14:45] <slangasek> tkamppeter: cheers
[14:45] <seb128> pedro_: thanks
[14:45] <kirkland> slangasek: so that dep just needs to be dropped from open-iscsi-udeb?   reasoning that the kernel provides it?
[14:47] <slangasek> kirkland: maybe.  actually, that may not really be the fix we want; scsi-modules should be in the initramfs, so germinate should be smart enough that we don't need to change open-iscsi further, hmm
[14:47] <slangasek> kirkland: so let me poke at that end
[14:47] <slangasek> anyway, amd64 is still oversized
[14:47] <dendrobates> slangasek: perhaps not, the mysteries of di are many, and it is a bug.
[14:48] <siretart> pedro_: if you don't mind, I will extend that part a bit later today, ok?
[14:48] <pedro_> siretart: no problem at all, feel free to do it
[14:49] <seb128> siretart: thanks, and sorry for the rant, but half of the crashers we get on multimedia apps right now are in libavcodec
[14:49] <slangasek> dendrobates: something pulls libc6-i386 into the server CD?
[14:50] <slangasek> yuck, why is samba-tools being pulled in?
[14:50] <siretart> seb128: sure, no problem. but as said, I think that more than 2/3 of those bugs don't actually belong there.
[14:50] <dendrobates> slangasek: samba-dbg is also there.
[14:50] <siretart> but rather gst-ffmpeg
[14:50] <slangasek> dendrobates: samba-tools is much less useful than samba-dbg :-)
[14:50] <seb128> siretart: perhaps we should really go back at making gst-ffmpeg use its ffmpeg copy and not the system one if that doesn't work
[14:51] <slangasek> apparently we're including "everything built from samba source" in server-ship, blargh
[14:52] <siretart> seb128: I was about to propose that as well. but we buy that with security maintenance nightmare. the "proper" solution would be to fix gst-ffmpeg, I'd think
[14:52] <slangasek> dendrobates, zul: I propose dropping swat, samba-tools, and samba-dbg from server-ship, does that sound reasonable?
[14:52] <seb128> siretart: nobody has a clue about gst-ffmpeg apparently so that's not really going to work
[14:52] <dendrobates> slangasek: yes, I have some other changes as well.  I'll get back to you in a bit.
[14:53] <siretart> seb128: I leave that discussion better to the gnome and security team, and prefer to focus on ffmpeg
[14:53] <seb128> siretart: ok thanks
[14:53] <slangasek> dendrobates: libsmbclient-dev, too
[14:55] <slangasek> dendrobates: so that saves you at least 43MB on the amd64 CD, we're probably good now :)
[14:56] <slangasek> btw, I see php5 is also seeded by source, and there's a php5-dbg in the archive now too
[14:56] <lool> ogra: So it's needed in main?
[14:56] <ogra> lool, right
[14:56] <slangasek> php5-dbg is a measly 8MB though
[14:56] <ogra> lool, to finish the slug install
[14:56] <lool> ogra: Why so? -- just curious
[14:57] <ogra> lool, d-i needs udebs it uses in main
[14:57] <ogra> lool, to enable d-i to have flash-kernel in the slug firmware flash-kernel (and its udeb) indeed needs to move
[14:58] <ogra> else the udeb wont be in the d-i firmware image and d-i automatically switches to a bootloader-less install
[14:58] <tkamppeter> Anyone is maintaining a package which is translated into 40 or more languages by upstream? Do you always get one spam mail per language from Rosetta when you upload it?
[14:59] <tkamppeter> This happened to me now with system-config-printer.
[14:59] <ScottK> tkamppeter: The last guy that uploaded KDE l10n got over 14,000 before he got #launchpad to kill it.
[14:59] <ogra> which leaves you with a fine installed userspcae on your USB disk but no kernel in the flash ... so it reboots into the d-i firmware again after install ... starting over
[14:59] <pitti> tkamppeter: yes, known bug
[14:59] <KaiL> slangasek, is dropping swat such a good idea?
[15:00] <slangasek> oh suck, lsb-core implies lib32z1 on amd64?
[15:00] <slangasek> KaiL: yes, it's a *very* good idea
[15:00] <slangasek> swat is terrible
[15:00] <slangasek> but I'll defer to the server team if they think they want it
[15:01] <cjwatson> calc: I have seen systems for which that doesn't hold, unfortunately. I definitely know of BIOSes that look at the partition table in more complicated ways than that
[15:01] <smb_tp> pitti, Hi Martin, I somewhat remember that at some sprint someone got the solution to my console-kit-daemon spews general protection messages on ubuntu-server. I can remember the solution was to install some package but I forgot even who came up with the solution. Was that you?
[15:01] <cjwatson> dendrobates: I'll see what I can do but it's a bit of a complicated mess
[15:02] <pitti> smb_tp: hm, it *might* be bug 275432
[15:03] <cjwatson> kirkland: please leave open-iscsi-udeb alone for now rather than perturbing the problem :-
[15:03] <cjwatson> )
[15:03] <kirkland> cjwatson: sure, no problem
[15:04] <smb_tp> pitti, Might be. Was not installed. Just installed it and will see. Thanks
[15:06] <slangasek> seb128: mmm, I think freetype 2.3.8 might've been the one with ABI breakage after all
[15:06] <slangasek> 2.3.9 is due out soon, though
[15:06] <seb128> slangasek: hum, ok
[15:06] <seb128> slangasek: any change you backport fixes for the issues I poined if those are not part of the ABI changes? ;-)
[15:07] <slangasek> (the mailing list archives are down so I'm having a hard time checking - but 2.3.8 is missing from some of the savannah mirrors, which is why I suspect)
[15:07] <slangasek> seb128: mm, I'll probably check on upstream's ETA for the new version first
[15:08] <seb128> slangasek: ok thanks
[15:08] <KaiL> just found a driver for the matrox M-Series - anybody interested in packaging it? ;)
[15:08] <cjwatson> there are some very subtle things that happen when you put udebs into seeds other than the installer seed. This open-iscsi-udeb thing is one of them. Unfortunately open-iscsi-udeb probably shouldn't go in the installer seed because that would add 170KB to all the other images.
[15:08] <lool> ogra: Ok; I thought d-i could be built from universe, thanks for letting me know
[15:09] <cjwatson> yes, ogra is correct
[15:09] <ogra> lool, not sure about that, cjwatson might have more info here
[15:09] <ogra> ah
[15:09] <cjwatson> d-i only uses bits from main
[15:09] <cjwatson> (and restricted)
[15:09] <lool> cjwatson: Thanks
[15:10] <slangasek> seb128: found a list archive that's up - 2.3.8 is the broken one - 2.3.9 is expected "within a week or so" of March 3
[15:10] <cjwatson> I wonder if the right answer is to make server-ship inherit from installer. IIRC that caused some subtle problem several years ago though ...
[15:10] <slangasek> seb128: if they don't deliver, I'll look at backporting
[15:11] <cjwatson> it would make some kind of logical sense though
[15:11] <lool> ogra: Note: XB-Subarchitecture might have to be extended in control for babbage and perhaps for marvell if we ever support the installer there -- I doubt it though
[15:11] <ogra> right, we also might need ubuntu patches for babbage
[15:11] <lool> Well basically flash-kernel will have to be porter including its udev parts
[15:12] <ogra> thats why i mentioned it in the MIR
[15:12] <lool> ogra: What's the MIR bug?
[15:12] <seb128> slangasek: thanks
[15:12] <ogra> lool, Bug 339947
[15:13] <lool> Erf the rules have this:
[15:13] <lool> pwd=$(shell pwd)
[15:13] <lool> TOPDIR := $(shell pwd)
[15:13] <lool> t=${TOPDIR}/debian/${PACKAGE}
[15:13] <lool> And none of these vars is ever used
[15:13] <ogra> heh
[15:13] <ogra> its as odd as all the other debian arm scripting
[15:13] <ogra> (like swapping kernels and d-i while thats not needed etc)
[15:14] <lool> ogra: approved
[15:15] <ogra> thanks
[15:15] <lool> ogra: well := $(shell pwd) should be $(CURDIR)
[15:15] <ogra> cjwatson, i assume flash-kernel will be pulled in automatically without any of us doing anything (prio should be correct for that) once its in main ?
[15:15] <lool> and defining pwd to not use it a line below is a bit weird, just like defining stuff you don't use
[15:16] <ogra> looks liek a leftover from some hacking or so
[15:16] <cjwatson> ogra: please add flash-kernel-installer to the installer seed
[15:16] <cjwatson> preferably in an appropriate section with [armel]
[15:17] <lool> ogra: I'm on it
[15:17] <dholbach> doko: geser told me that CDBS was patched to use  --install-layout=deb  - would it make sense to change that in a more central place?
[15:17] <ogra> lool, on what ? seed or fixing the vars ?
[15:17] <lool> seeds
[15:17] <ogra> thanks
[15:17] <cjwatson> lool: I've removed the unused cruft from debian/rules upstream
[15:18] <lool> cjwatson: thanks
[15:18] <ogra> well, that would have been my first seed change this cycle
[15:18]  * ogra cant belive he had nothing that touched the seeds in jaunty 
[15:18] <doko> dholbach: what is more central?
[15:18] <lool> (pushed)
[15:19] <ogra> thanks :)
[15:19] <dholbach> doko: or patch debhelper also?
[15:19] <geser> doko: dholbach found out that debhelper7 is missing that option
[15:20] <doko> dholbach: debhelper doesn't call python setup.py install, does it?
[15:20] <geser> doko: dh7 does it in dh_auto_install
[15:20] <doko> geser: sure, then please go ahead
[15:21] <dholbach> I think I missed some memo... why is this necessary atm? I'd just like to explain it properly when it comes up again :)
[15:22] <geser> dholbach: python2.6 transition
[15:23] <dholbach> that much I knew already...  :)
[15:23] <dholbach> I'll try to find out more info - nevermind :)
[15:25] <ScottK> dholbach: There was a mail where doko explained this.  I think it was ubuntu-devel.
[15:26] <geser> https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027439.html has some explanation about it
[15:26] <dholbach> ahhh!
[15:26] <dholbach> got it
[15:26] <dholbach> thanks a lot
[15:29] <Keybuk> we need a developer's knowledge base with such things
[15:30] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase links to https://wiki.ubuntu.com/UbuntuPackagingChanges - maybe a note about it should be on there?
[15:30] <geser> dholbach: apply http://www.bienia.de/tmp/debhelper.diff on debhelper and python-django-lint will build fine then
[15:30] <jdong> Dear World: Which xorg-video-intel freezes bug is the one that I am experiencing in Jaunty? :)
[15:30] <dholbach> geser: thanks a bunch
[15:31] <smb_tp> pitti, This seems to have been that issue. Looks like the libpolicy-kit-daemon messages are gone now
[15:32] <Keybuk> cjwatson: I'm -> <- this far away from writing ubuntuhelper
[15:32] <ogra> haha
[15:32] <Keybuk> which will contain one tool, uh_conffiles
[15:33] <Keybuk> that reads a file from the debian directory that contains things like:
[15:33] <Keybuk>   rm /some/file
[15:33] <ogra> great naming :)
[15:33] <Keybuk>   mv /another/file /somewhere/else
[15:33] <Keybuk> and generates all the preinst, postinst and postrm mumbo-jumbo
[15:34] <ogra> so you should call it ubuntugenerationhelper ... that would make it ugh_conffiles :)
[15:34] <pitti> Keybuk: I wouldn't mind doing that in debian/control instead, or debian/conffiles
[15:34] <dholbach> Keybuk: talk to mvo about it... I guess he'll add a     uh_maintainerscripts        :-)
[15:34] <pitti> declarative, not command-based
[15:35] <Keybuk> how would you do it declarative?
[15:35] <Keybuk> debian/conffiles is already an "owned" file
[15:36] <Keybuk> dholbach: why mvo?
[15:37] <dholbach> Keybuk: I think he has a strong opinion on where maintainer scripts should go :)
[15:37] <Keybuk> dholbach: in /var/lib/dpkg/info .. ?
[15:37] <pitti> debian/control-> ObsoleteConffile: /etc/foo\nRenamedConffile: /etc/foo /etc/bar
[15:37] <pitti> or so
[15:37] <Keybuk> dholbach: unless I'm missing something
[15:37] <mvo> Keybuk: I dislike maintainer script failures strongly during upgrades
[15:37] <Keybuk> pitti: why that way?
[15:37] <dholbach> Keybuk: I think "to hell" would be his answer
[15:37] <dholbach> ... maybe in a politer way
[15:37] <Keybuk> mvo: well, the kinda point here is to do the magic in one tested place ;)
[15:38] <Keybuk> instead of replicating it a billion times badly
[15:38] <Keybuk> even debhelper get sit wrong
[15:38] <doko> dholbach: sorry, currently in a meeting ...
[15:38] <pitti> Keybuk: with declarations we can provide one robust central implementation, and change it; replacing scripts with other scripts won't fix the problem that we currently have with it?
[15:38] <Keybuk> (fails to cope with the aborted upgrade case)
[15:38] <Keybuk> pitti: but then you hit a simple problem
[15:38] <dholbach> doko: sure, no worries
[15:38] <mvo> Keybuk: yeah, having a central place is already a great step forward
[15:38] <pitti> (which is largely that those scripts are often wrong, and incomplete)
[15:38] <Keybuk> what reads debian/control?
[15:38] <Keybuk> putting it in debian/control just seems wrong
[15:39] <cjwatson> I'd be happy to have a conffile management helper but (a) I don't think it should have rm and mv type syntax because that will encourage people to think they can do other shell-like things there (b) would it actually be hard to get it into debhelper? it sounds to me like the sort of thing that joeyh would accept even if he hasn't worked out the interface yet
[15:39] <Keybuk> after all you don't have the contents of debian/*.install, debian/*.manpages, etc. in there
[15:39] <pitti> Keybuk: the same mechanics that also reads Depends:?
[15:39] <pitti> Keybuk: anyway, I'm not fussed about control, but fussed about just saying what you mean, instead of telling dpkg how to do it
[15:39] <cjwatson> if this were to be done in dpkg proper, it probably shouldn't be in control, but in another file in the control area of the .deb
[15:40] <Keybuk> cjwatson: getting it in debhelper means writing in Perl
[15:40] <Keybuk> my Perl-fu is so rusty, I would rather not
[15:40] <cjwatson> Keybuk: let me dry your tears
[15:40] <cjwatson> it's not that hard :)
[15:40] <Keybuk> especially if it has to be reviewed by someone as ... careful as joeyh
[15:40] <calc> cjwatson: ah ok (wrt gpt issue)
[15:40] <cjwatson> you can run it through me first, I'll put it into joeyh-compatible form
[15:40] <siretart> pedro_: seb128: I've now enhanced https://wiki.ubuntu.com/Bugs/Responses#ffmpeg%20(mostly%20libavcodec%20and%20libavformat)%20bugs - it now contains instructions for both triagers and submitters. I hope that's okay like it is...
[15:41] <cjwatson> joeyh has historically liked my perl
[15:41] <Keybuk> maybe
[15:41] <Keybuk> will see
[15:42] <Keybuk> actually I'd want a third option in there
[15:42] <cjwatson> the other thing is that it should take care of the version guards too, so the syntax suggested above is a bit too simple
[15:42] <Keybuk> "move", "remove" and "rename or drop"
[15:43] <Keybuk> actually, joey when I talked about it was of the strong opinion that it shouldn't
[15:43] <Keybuk> and that you should instead treat the file simply as a list of changes you need to make to any installed package
[15:43] <seb128> siretart: there is some wiki formatting issue but otherwise that looks good, thanks!
[15:43] <cjwatson> hmm, ok, I was just going with modelling existing behaviour
[15:45] <davmor2> siretart: did you miss something it looks like there is some code visible there that shouldn't be
[15:47] <siretart> davmor2: possibly. The page uses more moin-FU that I know.
[15:47] <siretart> than I know.
[15:48] <davmor2> siretart: have a quick look and see if you have a trailing space after the table enclosure
[15:52] <pedro_> siretart: looks good, thanks you. btw I've fixed the wiki format
[15:53] <davmor2> pedro_: what was it?
[15:54] <pedro_> davmor2: the spaces were causing the issue
[15:54] <davmor2> :)
[16:23] <Keybuk> cjwatson: could you push your recent pcmciautils upload to the repository plz :p
[16:24] <calc> does anyone know what script keeps creating a '1' file in /root ?
[16:25] <calc> probably some incorrect redirection to /dev/null
[16:26] <ebroder> Anyone willing to do an upload for bug #339449? I'd like it to make alpha 6
[16:29] <cjwatson> kekey	
[16:29] <cjwatson> oops
[16:29] <cjwatson> Keybuk: uh, my branch is a checkout
[16:29] <cjwatson> Keybuk: http://people.ubuntu.com/~cjwatson/bzr/pcmciautils/ubuntu already up to date
[16:29] <Keybuk> cjwatson: lies
[16:30] <Keybuk> cjwatson: because I can quite clearly see an upload in the archive
[16:30] <Keybuk> made by you
[16:30] <Keybuk> that's not in this repo ;)
[16:30] <cjwatson> 'bzr revno sftp://rookery/home/cjwatson/public_html/bzr/pcmciautils/ubuntu/' is r74
[16:30] <cjwatson> $ bzr revno; head -n1 debian/changelog
[16:30] <cjwatson> 74
[16:30] <cjwatson> pcmciautils (014-4ubuntu3) UNRELEASED; urgency=low
[16:30] <Keybuk> ahh
[16:30] <Keybuk> doh
[16:30] <Keybuk> I'm reading this backwards ;)
[16:30] <Keybuk> you _haven't_ made an upload
[16:30] <cjwatson> that's correct
[16:30] <Keybuk> I assume it's ok to upload that?
[16:30] <cjwatson> sure
[16:31] <cjwatson> it just wasn't worth an upload just for that
[16:34] <Keybuk> cjwatson: lp:~scott/pcmciautils/ubuntu
[16:34] <Keybuk> (when it pushes ...)
[16:35] <Keybuk> pushed
[16:43] <primes2h> pitti: I tested  bug #211710 package from -proposed works nice!
[16:44] <primes2h> pitti: you can go on on that.
[16:44] <pitti> primes2h: thansk! can you please say so in the bug report?
[16:44] <doko> ubuntu-archive: please could you process openjdk-6/6b14-1.4.1-0ubuntu3 in NEW?
[16:45] <pitti> slangasek: okay, I shook a little more than 1 MB out of my sleeve
[16:45] <primes2h> pitti: already done! ;-)
[16:47] <slangasek> pitti: :-)
[16:48] <kirkland> what does a leading % mean in the seeds?
[16:48] <kirkland> eg, %exim4 ?
[16:49] <slangasek> kirkland: "all binaries from this source"
[16:50] <slangasek> i.e.: "this is wrong for any seed that's on a CD" :-)
[16:51] <kirkland> dendrobates: ^
[16:51] <kirkland> dendrobates: there's a number of those on server-ship
[16:52] <dendrobates> kirkland: fix them.
[16:52] <kirkland> dendrobates: yessir
[16:53] <slangasek> :-)
[17:02] <cjwatson> Keybuk: pulled, thanks
[17:04] <Keybuk> cjwatson: that should reduce the ubuntu diff even further, right?
[17:05] <liw> cjwatson, "the majority of problems people report with upgrades using apt-get or aptitude are in fact bugs in individual packages, and it's far simpler to fix them there than to fix them in individual packages" -- I assume you meant "in update-manager" at the end? or am I too tired to understand anything?
[17:07] <cjwatson> Keybuk: I think so, haven't checked yet
[17:07] <cjwatson> liw: yes, apparently I did
[17:08]  * cjwatson corrects himself on sounder@
[17:10] <slangasek> dendrobates, kirkland: ubuntu-server down to ~660MB :)
[17:10] <kirkland> slangasek: nice ;-)
[17:10] <kirkland> slangasek: i'm going to send you and dendrobates a diff in a moment, of the cleanups he requested, plus the "%" expansion (compression), before committing it
[17:11] <slangasek> kirkland: a diff or a mergeable branch?
[17:12] <kirkland> slangasek: whatever you would like
[17:12] <kirkland> slangasek: i was just going to attach a diff, but a branch would be just as well
[17:12] <slangasek> branch please :-)
[17:12] <kirkland> slangasek: sure thing
[17:30] <slangasek> seb128, doko: libgegl-0.0-0 depends on libavformat52 depends on libavcodec52, which is blacklisted from the CDs per the TB; are you aware of this, is this related to the ffmpeg-debian discussion above?
[17:30] <seb128> slangasek: I've no clue about libgegl and ffmpeg
[17:30] <slangasek> ok
[17:31]  * slangasek aims the nukes at gegl debian/control
[17:33] <slangasek> nice, the avformat b-d was added in an Ubuntu upload, with no mention in the changelog :/
[17:50] <Keybuk> slangasek: can I do #338825
[17:51] <Keybuk> doesn't affect CD size
[17:51] <seb128> bug #338825
[17:52] <cjwatson> Keybuk: FYI people are reporting that they still have problems with installer device handling races :-(
[17:52] <cjwatson> in case you haven't seen
[17:52] <cjwatson> I haven't got far enough to reproduce it myself yet
[17:52] <Keybuk> cjwatson: I saw timo reopen the bug
[17:52] <Keybuk> but then I also remember him saying it was fixed
[17:52] <cjwatson> well, races are like that ...
[17:53] <cjwatson> I thought he said "I think it's fixed but am not quite sure" but ...
[17:53] <kirkland> slangasek: dendrobates: https://code.edge.launchpad.net/~kirkland/+junk/ubuntu.jaunty
[17:53] <Keybuk> cjwatson: sure
[17:55] <slangasek> Keybuk: no new deps of a strange and furry nature?
[17:57] <Keybuk> slangasek: just python, cairo, etc.
[17:57] <Keybuk> drops all the strange java entanglements
[17:57] <slangasek> Keybuk: ok, cool
[18:02] <kirkland> slangasek: i'll await your review of those changes before committing
[18:03] <kirkland> slangasek: or you're welcome to merge/commit
[18:04] <cjwatson> Keybuk: davmor2 also said he encountered this, BTW
[18:04] <slangasek> kirkland: is exim4 binary package the right one to seed on DVD?
[18:04] <slangasek> I know exim4 has umpteen different binaries
[18:05] <slangasek> hmm, why do we still seed subversion, we should replace that with bzr-svn ;)
[18:05] <kirkland> slangasek: oh, good question
[18:05] <kirkland> slangasek: moving stuff to the dvd was the conservative decision by dendrobates
[18:06] <slangasek> yes, I'm just thinking aloud
[18:06] <kirkland> slangasek: ie, to keep it around, but get it out of the cd seed
[18:06] <kirkland> slangasek: ah, that was a joke, no?
[18:06] <slangasek> and trying to judge by the channel's reaction whether it's a good idea
[18:06] <ScottK> I know a number of people who have a real commitment to svn for $WORK and so I think we really do want it in Main.
[18:06] <ScottK> It may not be used so much here, but it's definitely used a lot out there ....
[18:06] <slangasek> kirkland: not a joke, just a thought
[18:07] <cjwatson> I don't think I'd want to use bzr-svn for e.g. upstream d-i commits
[18:07] <slangasek> true
[18:07] <slangasek> kirkland: seems unnecessary to seed mysql-common directly
[18:07] <slangasek> ditto postgresql-common
[18:08] <ScottK> Approximately everything I use a VCS for outside Ubuntu is svn plus a very little git.
[18:08] <kirkland> slangasek: that crossed my mind
[18:08] <slangasek> kirkland: should we seed apache2-mpm-prefork directly?  I think the only reason anyone cares about it is php5, which is also seeded
[18:08] <slangasek> "" apache2-common
[18:08] <slangasek> actually, apache2-common doesn't exist
[18:09] <kirkland> slangasek: dropped each of the -common
[18:09] <slangasek> (it's apache2.2-common, and yadda yadda)
[18:09] <slangasek> cool
[18:09] <kirkland> slangasek: -prefork ...  i suppose that's fine too
[18:09] <pitti> Keybuk: the aliases you added to the Ubuntu kernel, are they upstream as well?
[18:10] <kirkland> slangasek: ie, letting -prefork get pulled in by php
[18:10] <pitti> Keybuk: I'm a bit concerned about tailoring our userspace tools to the ubuntu kernel too much (or the other way round, deviating our kernel too much)
[18:11] <kirkland> slangasek: re: exim, your choices are: exim4-base, exim4-config, exim4-daemon-heavy, exim4-daemon-light-dbg, exim4-daemon-light, exim4-dbg, exim4-dev, eximon4
[18:11] <kirkland> slangasek: and just "exim4"
[18:12] <Keybuk> pitti: they will go upstream shortly
[18:12] <pitti> Keybuk: ah, nice
[18:12] <Keybuk> some of them already have
[18:12] <kirkland> slangasek: just "exim4" seemed to be the most direct
[18:12] <slangasek> kirkland: sounds good
[18:12] <pitti> Keybuk: I bought a 16 GB usb stick today, so that I can install jaunty on it and play around with sreadahead and compare how a flash disk feels like :)
[18:13] <Keybuk> pitti: you'll be massively slowed down by USB
[18:13] <slangasek> kirkland: dunno if that will cause /all/ of the -daemon- packages to be pulled onto the DVD, but I also don't know whether we want that
[18:14] <pitti> Keybuk: (I want it as a "portable workstation" anyway, so I won't install it in vain)
[18:14] <kirkland> slangasek: well, dendrobates and i sort of discussed that exim4 is not the preferred MTA of the server team, which is why we're moving it off of the cd
[18:15] <slangasek> yes
[18:15] <slangasek> it's not supposed to be the preferred MTA in Ubuntu; it kinda gets pulled in because it's the default in Debian
[18:15] <slangasek> (which we're trying to get decoupled in squeeze)
[18:15] <ScottK> AFAIK Canonicla uses it internally too.
[18:16] <ScottK> Canonicla/Canonical.
[18:16] <slangasek> ScottK: dunno; not for mail.c.c.
[18:17] <ScottK> slangasek: Just checked the most recent bugmail header I got from LP and it has Exim in the path.
[18:17] <ScottK> At least it claims to be Exim.
[18:18] <slangasek> heh, ok
[18:18] <RainCT> seb128: thanks for sponsoring scim :)
[18:19] <seb128> RainCT: you're welcome; did anybody sent the change to debian btw?
[18:20] <seb128> I've to run bbl
[18:42] <cjwatson> dendrobates,kirkland: I've committed a seed change to get rid of the -386-di stuff on server CDs that you mentioned
[18:43] <kirkland> cjwatson: cool, thanks.
[18:43] <kirkland> slangasek: are you still reviewing that branch I posted?  or are we just hung up on exim4?
[18:43] <slangasek> kirkland: oh - not hung up, I was done reviewing.  Do you want to commit or shall I?
[18:44] <kirkland> slangasek: i can
[18:44] <RainCT> err.. why did LP just spam me with something about "translation import"? :P
[18:44] <slangasek> kirkland: the +junk branch doesn't appear to reflect your -common changes, so I guess you should :)
[18:44] <kirkland> slangasek: haven't committed those yet
[18:44] <slangasek> ok
[18:44] <kirkland> slangasek: what's your thought on the exim4 bits?
[18:45] <slangasek> kirkland: I suppose it's important to have all of the exim4 -daemon- variants included on the DVD, at least if there's room
[18:45] <mvo> RainCT: a "feature" in LP - there is a bug open and it anoys a lot of people
[18:45] <mvo> I just got 300 mails from LP
[18:46] <RainCT> ouch
[18:46] <kirkland> slangasek: okay, sounds good
[18:47] <kirkland> slangasek: minus exim-daemon-light-dbg, of course
[18:51] <ScottK> RainCT: I know one guy got 14,000.
[18:59] <calc> pitti: ping
[19:01] <directhex> bleh, another patch needed for all current releases for pidgin
[19:03] <Laney> what died?
[19:04] <directhex> icq
[19:05] <directhex> it's "maybe" a server-side fault
[19:06] <Laney> huge bug with a million people commenting ahoy?
[19:06] <directhex> Bug #340075
[19:07] <elmo> wiki.ubuntu.com/SeedManagement could do with some love
[19:07] <elmo> lots of Gutsy references
[19:10] <emgent> hallo
[19:16] <kirkland> RainCT: hi, you were asking about the kill-window keybinding ....
[19:17] <kirkland> RainCT: i actually replaced F5 with "reload profile" right around UI-freeze
[19:17] <kirkland> RainCT: kill window is still <ctrl-a-k>
[19:18] <kirkland> RainCT: which was easier than "ctrl-a-: source $HOME/.screen-profiles/profile"
[19:18] <kirkland> RainCT: and F5 sort of has that "reload" mentality
[19:18] <kirkland> RainCT: sorry for the inconvenience
[19:18] <kirkland> Keybuk: question about "  * Bump debhelper version for updated udev rules path, add Breaks to ensure we use the right version of udev."
[19:19] <kirkland> Keybuk: i'm trying to get kvm-84 to build on hardy for a potential backport
[19:19] <kirkland> Keybuk: what's my best way to work around this issue?
[19:21] <RainCT> kirkland: ah, alright. thanks for the explanation
[19:22] <kirkland> RainCT: yup, thanks for the question ... i knew someone would ask :-)
[19:22] <kirkland> RainCT: the upshot is that it allows you to change your profile, keybindings, escape key, etc. on the fly
[19:22] <kirkland> RainCT: without exiting and restarting screen, or typing that really long command
[19:22] <kirkland> RainCT: it also reruns all of your status indicators
[19:23] <kirkland> RainCT: so, you'd freshen those as well :-)
[19:23] <RainCT> kirkland: ah, something more: I don't get the  \o/  in the status bar here
[19:23] <kirkland> RainCT: it's 1/3 of the ubuntu logo
[19:24] <RainCT> I know :)
[19:24] <RainCT> but I don't have it.. dunno why
[19:24] <kirkland> RainCT: debian's is easy, a red @ on a white background
[19:24] <kirkland> RainCT: ?
[19:24] <calc> pitti: emailed you a question
[19:25] <kirkland> RainCT: that's *really* strange
[19:25] <kirkland> RainCT: do you have any overrides in your .screenrc?
[19:25] <RainCT> kirkland: err yes, sorry :P
[19:26] <kirkland> RainCT: if you can pastebin your .screenrc and your .screen-profiles/profile, i'll have a look
[19:26] <kirkland> RainCT: also, what version of screen-profiles are you running?
[19:26] <RainCT> kirkland: nevermind, I had a "hardstatus string ..." in there, getting rid of it fixed it
[19:26] <kirkland> RainCT: ah, yeah, that'll do it ;-)
[19:26] <kirkland> RainCT: sweet
[19:27] <RainCT> kirkland: "jaunty" would look nicer capitalized :P
[19:27]  * calc wonders if bzr is going to be fixed in jaunty before release so it stops complaining about deprecated python
[19:27] <kirkland> RainCT: bug against base-files: /etc/lsb-release
[19:28] <kirkland> calc: i'm tired of those too :-)
[19:28] <RainCT> calc: are you sure it's not a plugin?
[19:28] <calc> RainCT: in bzr? if it is its a common one because i didn't do anything special
[19:28] <Keybuk> kirkland: change the build-depend for the backport
[19:28] <RainCT> here I had some plugins causing this.. but OTOH I'm running bzr from the PPA :P
[19:29] <calc> i have bzr, bzrtools installed only bzr related stuff afaik
[19:29] <calc> my bzr is 1.12-1build1
[19:29] <directhex> i've worked out why the "skip this track" case for notifications hasn't carried any weight!
[19:29] <kirkland> Keybuk: okay, that's all there is too it...  it only breaks a modern udev
[19:29] <RainCT> calc: I have the same, no warnings there
[19:29] <kirkland> Keybuk: cool, it's building in my ppa already, i was just checking on any other side effects ;-)
[19:30] <RainCT> calc: look into ~/.bazaar/plugins, perhaps you've got something there
[19:30] <directhex> media buttons on keyboards! http://www.pragmatik.org/blog/wp-content/uploads/import/keyboard0105.jpg
[19:30] <Adri2000> calc: about md5/sha and hashlib?
[19:30] <calc> Adri2000: yes
[19:31] <calc> RainCT: no ~/.bazaar/plugins on my system afaict
[19:31] <Adri2000> it's bzr-builddeb
[19:31] <Adri2000> and the fix is already committed
[19:31] <RainCT> directhex: err. that's pretty standards (well, not with buttons as weird as those :P)
[19:32] <calc> Adri2000: afaict i don't have that binary
[19:32] <directhex> RainCT, my last keyboard didn't have 'em :(
[19:32] <directhex> RainCT, hence relying on banshee's notification's "skip this track" button
[19:33] <RainCT> directhex: System -> Preferences -> Keyboard bindings
[19:33] <Adri2000> /usr/lib/python2.6/dist-packages/bzrlib/plugins/builddeb/import_dsc.py:33: DeprecationWarning: the md5 module is deprecated; use hashlib instead
[19:33] <Adri2000> /usr/lib/python2.6/dist-packages/bzrlib/plugins/builddeb/repack_tarball.py:26: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[19:33] <Adri2000> calc: that?
[19:33] <calc> Adri2000: let me see, i'll run it again
[19:33] <RainCT> directhex: and set Ctrl+<RightArrow> or something to move forward, etc.  How could you live without that? o.O
[19:33] <calc> it just shows this:
[19:33] <calc> usr/lib/python2.6/dist-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead from sha import *
[19:33] <calc> /usr/lib/python2.6/dist-packages/Crypto/Hash/MD5.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead from md5 import *
[19:34] <calc> is that python2.6 complaining about itself from inside bzr
[19:34] <calc> ?
[19:34] <calc> dpkg can't find the owner of that file
[19:35] <directhex> RainCT, how? by clicking the notification, duh!
[19:35] <RainCT> directhex: not on Jaunty ;)
[19:36] <Adri2000> calc: looks like bug #337073
[19:37] <calc> Adri2000: ok
[19:37] <Adri2000> DistroRelease: /usr/bin/lsb_release:81: DeprecationWarning: the sets module is deprecated import sets Ubuntu 9.04
[19:37] <Adri2000> ahah
[19:50] <Keybuk> can someone lend me a hand with python-support?
[19:50] <Keybuk> I just can't seem to get this module to show up
[20:10] <fta> who is managing packages.u.c? would be nice to have -security there..
[20:11] <jcastro> fta: I tried to mail the guy to get patches.u.c linked from there, but no answer. :-/
[20:28] <fta> jcastro, hm, he seems active, last commit in his git branch was 4 days ago
[20:29] <jcastro> fta: maybe he just hates me, if you get ahold of him let me know pls.
[20:29] <Daviey> i had a response from the chap around 18 months ago.. was pretty quick iirc
[20:30] <Daviey> jcastro: ^^
[20:35] <bdmurray> TheMuso: is bug 287862 fixed now?
[20:36] <TheMuso> slangasek: If you haven't let linux-rt through binary new yet, don't, since I need to upload anothre revision thats based against latest jaunty mainline, which has an ABI bump.
[20:36] <calc> TheMuso: do you have a powerpc running jaunty?
[20:37] <TheMuso> calc: Indeed.
[20:37] <calc> TheMuso: can you comment on bug 250825 when you have spare time, not high priority :)
[20:37] <calc> TheMuso: i think it may be fixed now as it builds with java support afaict
[20:39] <TheMuso> calc: ok will have a look at some point
[20:39] <calc> TheMuso: thanks :)
[20:46] <bdmurray> TheMuso: is bug 287862 fixed now?
[20:47] <TheMuso> bdmurray: I'll have to check, and I need to set up a studio install in a VM for that.
[20:48] <bdmurray> TheMuso: okay, it looks like ubuntustudio-desktop depended on ubuntu-sounds now
[20:48] <bdmurray> I wasn't sure if that was the issue or not
[20:49] <slangasek> TheMuso: alrighty :)
[20:49] <TheMuso> hrm I thought we got rid of that. I'll fix that up in my seed shuffle this morning.
[20:57] <Ampelbein> I just reported bug #340151 to get version 2.5.5 in jaunty. Can someone experienced look and see if the report is complete and i can subscribe ubuntu-release now? Thanks.
[21:34] <directhex> ta slangasek
[21:34] <slangasek> directhex: you're welcome for whatever it was :)
[21:35] <directhex> [Updating] cecil-flowanalysis (0.1~svn.68457-5 [Ubuntu] < 0.1~svn.68457-7 [Debian])
[21:35] <slangasek> right
[21:36] <directhex> five smerge bugs are all that remains of the transition. i'm pretty pleased that we got the thing done for jaunty
[22:27] <cjwatson> Keybuk: is there a way to change the udevd log level at run-time?
[22:27] <Keybuk> udevadm control --log_priority=info
[22:27] <cjwatson> I'd like to be able to get a debug log just across partitioning commit, rather than for EVERYTHING
[22:27] <cjwatson> aha
[22:27] <cjwatson> thanks
[22:30] <Keybuk> I tend to just kill udevd and start it again, mind you
[22:30] <Keybuk> since then I can redirect it useful places
[22:32] <cjwatson> Keybuk: that doesn't cause it to coldplug?
[22:32] <Keybuk> no
[22:32] <Keybuk> only udevadm trigger does that
[22:44] <cjwatson> Keybuk: I can't reproduce this apparent race between libparted telling the kernel to reread the partition table and udev myself; but would a udev debug log across the relevant time be useful to you anyway?
[22:44] <cjwatson> Keybuk: when removing an ordinary block device, does udev open the device being removed *at all*?
[22:46] <cjwatson> Keybuk: http://people.ubuntu.com/~cjwatson/tmp/udev.log - I inserted three blank lines before the point where I told it to commit partitioning changes
[22:47] <cjwatson> that said I'm slightly curious what the crap just before that is
[22:48] <cjwatson> I killed udevd and restarted it at (I think) the first guided partitioning prompt, and I believe the stuff from line 369 onwards was from the next couple of guided partitioning steps (which shouldn't actually have done much to the disk, unless I'm much mistaken)
[22:51] <cjwatson> Keybuk: hmm. libparted opens devices read-write if it can - could this be causing a problem?
[22:53] <cjwatson> Keybuk: although I don't *think* it opens anything read-write between removing and adding partitions, so I think this can only be responsible for some noise at most
[22:54] <cjwatson> maybe we should settle before committing, just to make sure everything is out of the way
[23:01] <bertolo>  i am portuguese, 20 years old, student and low level coder (mainly C). how can i contribute ?
[23:01] <directhex> first, try #ubuntu-motu
[23:02] <bertolo> sure :D
[23:05] <TheMuso> hrm looks like module-init-tools install is broken. Just got an FTBF sfor a build due to it not being able to be installed successfully.
[23:07] <TheMuso> hrm its because it can't find update-initramfs.
[23:07]  * TheMuso digs further.
[23:07] <tormod> can somebody please build a new ports/daily-live? Since all non-xrandr 1.2 drivers were broken in Jaunty until xorg-server 1.6 was included, it would be nice to have a new live CD for testing.
[23:10] <TheMuso> Keybuk: seems like module-init-tools should depend on initramfs-tools, since update-initramfs is called in its postinst.
[23:14] <tormod> slangasek: I was suggested to ask you nicely about the above ports/daily-live rebuild. Please :)
[23:18] <slangasek> tormod: mm, let me have a look
[23:19] <TheMuso> I would actuall think it would make more sense to wait till we have the latest ports kernel ready to be put onto the disks myself.
[23:19] <slangasek> right, there's that
[23:20] <tormod> ETA?
[23:21] <slangasek> 1.5h
[23:21] <tormod> oh that was fast! Thanks!
[23:22]  * TheMuso preps and uploads linux-ports-meta in preparation.
[23:23] <slangasek> TheMuso: linux-ports is just accepted, so yeah :)
[23:23] <TheMuso> slangasek: on its way up now
[23:30] <slangasek> well, livefs builds are going to fail anyway because compiz is uninstallable
[23:30] <TheMuso> hah
[23:30] <directhex> not guilty!
[23:33] <TheMuso> c
[23:34] <slangasek> Amaranth___: do you happen to know why compiz now depends on non-existent compiz-plugins-*, instead of compiz-fusion-plugins-*?