[00:14] <slangasek> mathiaz: it looks like there haven't been any ISO tests of the server CDs yet for 8.04.4; can you help with that?
[00:14] <mathiaz> slangasek: yes - I plan to schedule some iso testing tomorrow
[00:14] <mathiaz> slangasek: does this work into your schedule?
[00:14] <slangasek> that works, thanks
[00:17] <mathiaz> slangasek: 20100121.3 is the one to be tested?
[00:17] <slangasek> mathiaz: yes
[01:35] <persia> lamont: If you happen to find some time, could you look at bug #67544
[02:06] <mathiaz> cjwatson: hi - are you still planning on fixing bug 218965?
[02:26] <lamont> persia: gar
[02:26] <lamont> how soon do we care enough about that for me to care?
[02:27] <persia> lamont: I just noticed it was broken, and did the bootstrap, discovering it was not so hard.  Sometime prior to release would be nice, preferably prior to beta.
[02:28] <persia> I have some debs, but I don't expect you to trust mine, even if I sign them :)
[02:28] <lamont> ok.  I have a todo item to document this process and train one of the admins - so I think I'll document the pain and turn them loose - prolly 2-3 weeks. failing that, it'll be before the end of feb
[02:29] <lamont> persia: the process is simple - I grab the tarball, unpack it on a spare ppc box, install the needed extra cruft in it, build the package, take _those_ debs, lob them in the again freshly unpacked tarball (installed), put all the ppc buildds on   manual, upload the hacked over tarball, build what needs to be built, and then restore the pristine tarball.
[02:29] <lamont> trivia
[02:29] <lamont> l
[02:30] <lamont> and yeah, using the sid binaries
[02:31] <persia> lamont: Yeah, because it doesn't work with the squeeze binaries (or didn't yesterday) :)
[02:31] <persia> But training someone else does sound like the best plan :)
[02:33] <lamont> so... ticket in RT, depends on my ticket to document things, due 1 march.  that should work out properly
[02:34] <persia> Thanks.
[02:34] <lamont> and since it's in universe, it's a perfect testcase
[02:35] <lamont> gcc-snapshot/armel will be my testcase to make sure I like the wiki
[02:35] <persia> I didn't see any bootstrap issues in main this weekend, so, fingers-crossed, it should be a while before that becomes a concern.
[02:35] <lamont> gcc-snapshot/armel (for ada) is on my radar for this week
[02:36] <persia> Does gcc-snapshot really need bootstrapping as binary?  Wouldn't it be easier to build it for all arches with gcc, and then rebuild with itself with source changes?
[02:36] <lamont> fwiw, I took the bug
[02:36] <lamont> no.  snapshot is turning on ada on armel...  so it has to bootstrap somewhere... bootstrapping it in snapshot is less of a pain, since it allows for testing before it goes 100% live
[02:36] <persia> Aha.
[02:37] <lamont> or some feature, at any rate... I'll admit to being a tad but fuzzy on it, having not read the ticket today
[02:38] <persia> Hrm.  it seems in happier shape than I remembered.  I thought it failed on more arches.  But looking again, yeah, bootstrap for armel seems easiest.
[02:52] <ScottK> slangasek: Did you finish your archive admin duties for today?  I was sort of hoping unbound would get out of binary New so I could transition it's reverse-build-depends tonight.
[02:52] <slangasek> ScottK: still working on it; unbound is next up
[02:52] <ScottK> Kewl.  Thanks.
[02:53] <ScottK> I just did took care of quantlib's reverse-build-depends.
[03:59]  * ccheney is trying to boot his old computer up on karmic disk to reinstall for his son and its not working for some reason, passes memtest and cd check but never gets into X
[03:59] <ccheney> whats funny was it was running jaunty before, heh
[04:03] <micahg> ccheney: upstart?
[04:08] <ccheney> micahg: not sure what is wrong
[04:08] <ccheney> micahg: i'm going to see if it will boot into direct install mode
[04:10] <ccheney> i think i should try booting a jaunty disk to see if that still works
[04:10] <ccheney> ah its still doing something for install mode, disk is just slow
[04:12] <ccheney> yea karmic isn't working for me even in install only mode
[04:13] <ccheney> probably some video driver issue
[04:15] <ccheney> omg its just hideously slow
[04:15] <ccheney> like what i would imagine it would take to run on a 486
[04:27] <ccheney> ok so jaunty boots just fine, this is weird
[04:27] <ccheney> is there a way to spin a new karmic cd with the kernel updates on it?
[04:30] <ccheney> unfortunately i don't have a jaunty 64bit cd :-\
[04:30] <slangasek> I wasn't aware that we had any video issues in karmic that were fixed by kernel updates?
[04:30] <ccheney> ok
[04:31] <slangasek> (non-trivial to respin a karmic liveCD, anyway)
[04:31] <ccheney> well it doesn't seem like a video issue really, it just runs very slowly off the cd, many times slower than the jaunty disc
[04:31] <ccheney> to the point i didn't wait for the actual installer to display once X finally came up
[04:31] <slangasek> ah
[04:31] <ccheney> same system running jaunty booted cd fine
[04:32] <ccheney> i thought video wasn't working at first since it took so long for even X to start
[04:32] <superm1> slangasek, there are tons of issues with intel arrandale with the karmic live media unfortunately
[04:32] <superm1> much more stable after kernel updates
[04:32] <slangasek> ok
[04:32] <superm1> yay kms
[04:34] <ccheney> i guess i could download the netinst image and install via my local mirror from ncurses :)
[04:34] <ccheney> then determine what is wrong with my boot speed
[04:35] <superm1> why not just throw it on a usb key instead?
[04:35] <superm1> if it's CD problems
[04:36] <ccheney> it seems to not like booting off usb
[04:36] <ccheney> i'll have to look in the bios again to see if i can make it work
[04:37] <ccheney> its an older machine athlon 64 from 2004
[04:37] <ccheney> though maybe my front ports are just broken
[04:38] <ccheney> i don't think its a cd issue since the cd check passed
[04:38] <ccheney> hmm yea it seems to not want to boot off USB says CBIOSBoot error
[04:40] <ccheney> google claims its a problem with the bios booting off usb
[04:49]  * ccheney wonders why you can't burn a cd iso to a dvd
[05:08] <ccheney> hmm seems to be a limit of the software i tried to use
[05:19] <jmarsden> ccheney: growisofs -dvd-compat -Z /dev/dvd=image.iso    # should work for doing that.
[05:22] <ccheney> jmarsden: ok
[05:34] <ccheney> karmic worked fine once i installed it via mini.iso
[07:19] <emgent> Riddell: ping
[07:22] <persia> emgent !  Hey, do you still run your Ubuntu Developer Statistics site?
[07:26] <emgent> ola persia
[07:26] <emgent> no :°
[07:26] <emgent> persia: can i pm you ?
[07:26] <persia> Always :)
[07:26] <emgent> danke ;)
[07:34] <al-maisan> Good morning!
[07:38] <dholbach> good morning
[07:38] <pitti> Good morning
[07:55] <siretart`> sebner: I guess it can be synced from unstable now. the actual breakage seems to be in libsdl1.2-dev, though
[08:00] <persia> If that's about gstreamer-plugins-bad, SevenMachines has been working on the merge, and just did a rebuild of slv2 to keep LV2 support.
[08:08] <siretart`> persia: ah, thanks
[08:53] <pitti> asac: a firefox update (3.6) and a crash (accidentally hit the power button) later my firefox profile seems to be broken -- calling "firefox" just returns after a second and doesn't do anything (no error messages); another profile works; is there any hope?
[08:55] <directhex> pitti, copy your bookmarks.html and erase the old profile? or do you have other stuff you want to save?
[08:56] <pitti> there are plugins, history, and most of all, my keyring
[08:56] <pitti> if I lose my keyring, I'm pretty much busted
[08:56] <pitti> I guess I can just copy over all of that
[08:56] <pitti> but I was more wondering if there's a method to add more verbosity, to find out what it's complaining about
[08:58] <persia> pitti: Something like that happened to me in gutsy or hardy (I forget).  The solution was to extract stuff, and then add it back bit-by-bit.
[08:58] <persia> Ended up being my custom js with my session page information, but I suspect there are lots of different causes.
[08:59] <persia> Of course, if you're feeling bored, you can get a stacktrace and find the specific bit that causes it to choke, but ... :)
[08:59] <pitti> well, it doesn't crash
[08:59] <pitti> it cleanly exits
[08:59]  * pitti already stared at strace
[09:00] <persia> Oh my.
[09:43] <tseliot> slangasek: are you around?
[09:44] <slangasek> tseliot: regrettably :)
[09:44] <tseliot> heh
[09:44] <tkamppeter> pitti, hi
[09:45] <slangasek> tseliot: btw, in response to your earlier inquiry - we *shouldn't* include plymouth in the initramfs by default, but the package in the archive still does; the bzr branch has changes that should remove the need for it in the initramfs by default (I hope)
[09:45] <ogra> slangasek, oh, hey ... thanks for the explanation above ... what i dont get is why plymouth seems to default to ubuntu-logo on the dove subarch but not on imx51, i didnt see any arch or HW specific tests or anything that could cause this
[09:46] <tseliot> slangasek: right. I was surprised to see what the package does
[09:46] <slangasek> tseliot: and I added the details and text plugins to the initramfs because they're used as built-in fallbacks by plymouth, so we should always have them - except in the case of ubuntu-logo, the script plugin in the archive is broken; this is fixed in bzr
[09:47] <slangasek> ogra: are you not booting with the 'splash' option on imx51?
[09:47] <ogra> i do
[09:47] <slangasek> are you actually seeing text, or are you just /not/ seeing a logo?
[09:47] <tseliot> slangasek: what do you mean by broken?
[09:47]  * tseliot is willing to bug upstream about it
[09:48] <ogra> i'm seeing text and dont see a logo, the text seems to be the plymouth plugin though (i.e. fsck output is bold and the fonts slightly change on startup)
[09:49] <slangasek> tseliot: see bzr for the fix :)  I hadn't gotten around to figuring out how to submit it upstream yet; if you're on speaking terms w/ upstream, feel free to pushit
[09:49] <ogra> running plymouth-set-default-theme ubuntu-logo and rebuilding the initramfs gets me the logo then
[09:49] <slangasek> or feel free to point me at hem
[09:49] <slangasek> them
[09:51] <ogra> iso it all seems fine apart from that step, i just dont get where the difference is regarding dove vs imx, they should behave the same unless there is any arch or HW specific check that prevents it
[09:51] <ogra> *so
[09:51] <ogra> butu the code doesnt indicate that there is
[09:52] <ogra> *but
[09:53] <slangasek> but if running 'plymouth-set-default-theme ubuntu-logo' fixed it, this must be the fault of whatever set your theme to something else originally
[09:53] <slangasek> which doesn't seem to be the plymouth package itself
[09:54] <ogra> well, what *does* set the theme ? we dont have any imx specific code here :)
[09:54] <slangasek> no package is *supposed* to set the theme except for plymouth, and plymouth sets it right
[09:54] <ogra> we always only went with the seeded packages in case of usplash
[09:54] <slangasek> to ubuntu-logo, not to text
[09:55] <ogra> so dont have any hacks or anything that could get in the way
[09:56]  * ogra goes and checks debian-cd
[09:57] <ogra> hmm
[09:57] <ogra> CMDLINE="\"console=ttymxc0,115200 console=tty0 file=/cdrom/preseed/ubuntu.seed $EXTRA_ARGS\""
[09:57] <ogra> does plymouth care for console= ?
[09:57] <slangasek> no
[09:57] <ogra> (thats only there for debugging during alpha)
[09:58] <slangasek> ogra: when was this imx51 system installed?  Is it reproducible with alpha-2?
[09:59] <ogra> yes, it was installed from an A2 image and dist upgraded
[10:00] <ogra> i was noticing the difference with the plymouth errors going away and the bold fsck output after the upgrade that pulled in plymouth
[10:00] <ogra> i just didnt get a logo
[10:00] <slangasek> ogra: well, then the fault for the wrong theme isn't with the plymouth package, whose code has worked correctly and consistently since 7 Dec
[10:01] <ogra> sadly i missed to check the actual link for /lib/plymouth/themes/default.plymouth but when i ran plymouth-set-default-theme for the first time it spit out "text"
[10:01] <slangasek> errr, what do you mean, "the upgrade that pulled in plymouth"? plymouth was already included in A2
[10:01] <ogra> slangasek, well, since last week for armel (it was ftbfs until i sponsored a fix)
[10:02] <ogra> well, not plymouth but libdrm
[10:02] <ogra> so it wasnt installed
[10:03] <slangasek> I'm looking at the manifest - plymouth was in the imx51 A2 image
[10:03] <ogra> bug #507765
[10:04] <ogra> surely a wrong version
[10:05] <slangasek> yes, the version on imx51 for A2 had bugs, but not a bug in its theme handling
[10:06] <ogra> weird
[10:06] <ogra> well, there was a noticeable visual difference during boot before and after the upgrade
[10:06] <ogra> and the "could not connect to plymouth" error vanished
[10:07] <slangasek> can you check what the default.plymouth points to inside the A2 squashfs?
[10:08] <ogra> one sec
[10:09] <ogra> ogra@osiris:~$ ls -l /mnt/lib/plymouth/themes/default.plymouth
[10:09] <ogra> lrwxrwxrwx 1 root root 18 2010-01-13 13:21 /mnt/lib/plymouth/themes/default.plymouth -> text/text.plymouth
[10:10] <ogra> i'm pretty sure its still this way on newer images (i tested staurdays image and had no logo either, but dont have the image around anymore)
[10:11] <ogra> *saturdays
[10:14] <asac> pitti: odd
[10:14] <pitti> asac: I removed the extensions now, it works again
[10:14] <asac> pitti: usually if it just returns it means that firefox can see a firefox window somewhere ... so it just sends a remote command and exits
[10:14] <asac> ok
[10:15] <asac> pitti: could you narrow down what extension caused this?
[10:21] <ttx> superm1: around ? I just hit bug 512661, I think it was uncovered by recent fix to bug 480055
[10:21] <slangasek> ogra: ok, got it
[10:22] <slangasek> ogra: if update-initramfs is called while plymouth is unpacked but not yet configured, the initramfs hook, which calls plymouth-set-default-theme to /query/ the theme will end up doing a --reset to /set/ the theme since it hasn't been set yet
[10:22] <ogra> slangasek, you mean you understood what i said or do you mean you got an idea why it is that way ?
[10:22] <ogra> ah
[10:22] <slangasek> so there's a race condition wrt package configure order in the livefs build
[10:23] <ogra> funny that it only shows up on imx51 ... the buildd for dove and imx is identical
[10:23] <persia> Well, except that they are different runs through livecd-rootfs.
[10:23] <ogra> doesnt matter
[10:24] <persia> (or at least I get separate reports of success/failure)
[10:24] <ogra> the initramfs is created at the same point for both
[10:24] <slangasek> no, it's created whenever update-initramfs happens to trigger
[10:24] <persia> No.  It's created at the same relative point.  Race conditions tend to depend on actual points, rather than relative points.
[10:24] <ogra> yes, relative point indeed
[10:25] <pitti> asac: I should still have it in my backup; I'll try again later
[10:26] <asac> k
[10:26] <slangasek> ogra: ok, fix committed
[10:26]  * ogra hugs slangasek 
[10:26] <ogra> thanks a lot for listening to my babbling :)
[10:27] <slangasek> :)
[10:37] <ttx> pitti: Please see https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/418836/comments/6 -- I'm trying to dump the ubuntu-only jetty6 package and replace it by the now-updated jetty package -- let me know if I need to duplicate the MIR of if the old one is enough (same code).
[10:39] <tkamppeter> pitti, hi
[10:39] <pitti> ttx: that sounds fine; just ping the MIR bug, so that we have a reminder to do the actual promotion/demotion
[10:39] <pitti> hi tkamppeter
[10:40] <ttx> pitti: I opened a "jetty" task and subscribed ubuntu-mir to it... that should make it appear on your radar
[10:40] <pitti> right, thanks
[10:41] <tkamppeter> pitti, it is about an SRU for CUPS, intended fixes are for the following bugs: https://bugs.edge.launchpad.net/ubuntu/karmic/+source/cups
[10:42] <tkamppeter> pitti: bug 407344, bug 487902, and bug 508731.
[10:44] <tkamppeter> The first two are already fixed in the CUPS package of Lucid, the last one is already fixed on the BZR, there I want to ask you to upload the CUPS package into Debian and Lucid to make the start for the SRU.
[10:44] <tkamppeter> pitti ^^
[10:45] <pitti> tkamppeter: you can prepare the SRU independently; if the change is in bzr, that's good enough for a -proposed upload
[10:45] <pitti> tkamppeter: but yes, I'll upload it to Debian soon, too; thanks!
[10:47] <tkamppeter> pitti, is the a BZR repo with already queues changes for a CUPS SRU, or should I simply make a debdiff based on the l;ast update, cups 1.4.1-5ubuntu2.1?
[10:47] <pitti> tkamppeter: there is no karmic bzr branch right now; if you prefer having one, feel free to create one; otherwise, just prepare the package and upload
[10:48] <pitti> asac: hm, firefox 3.6 has non-antialiased fonts; is that just me?
[10:49] <tkamppeter> OK, so I will simply prepare the package and upload it.
[10:51] <asac> pitti: https://bugzilla.mozilla.org/show_bug.cgi?id=541319
[10:51] <asac> regression when using in-source cairo rather than system-cairo
[10:52] <pitti> asac: ah, thanks
[10:53] <tkamppeter> pitti, were debdiffs between releases removed from Launchpad?
[10:53] <asac> tkamppeter: you have to go to the +changelog page
[10:53] <pitti> tkamppeter: perhaps; but you can just use bzr diff -c revno to extract the patches
[10:53] <asac> like https://edge.launchpad.net/ubuntu/+source/uboot-imx/+changelog
[10:54] <asac> (not sure if that was the question)
[10:54] <tkamppeter> Thanks, asac and pitti
[11:07] <slangasek> tseliot: do you have a contact address handy for plymouth upstream, then?
[11:08] <slangasek> tseliot: btw, if you want a fun plymouth bug to work on, bug #509487 is nice
[11:08] <tseliot> slangasek: usually I bug them in #plymouth
[11:08] <slangasek> ok
[11:09] <tseliot> slangasek: I will have to implement plymouth's new look therefore I guess I'll be pretty busy
[11:09] <slangasek> alrighty :)
[11:09] <tseliot> well, not only because of that ;)
[11:10] <tseliot> and hopefully I will deal with the 16 colours problem
[11:11] <slangasek> eep, good luck
[11:20] <tseliot> :-)
[11:28] <ogra> does anyone have an idea why i see the "$n packages can be upgraded" message twice in my motd ? http://paste.ubuntu.com/363175/ the second value is right though
[11:41] <ogra> pitti, is there any flag i can set on a partition to prevent it from getting automounted ?
[11:44] <pitti> ogra: on a removable device? not right now
[11:44] <ogra> hmm, sad
[11:44] <pitti> ogra: you could install an udev rule to disable that, of course
[11:44] <pitti> but not as normal user
[11:45] <ogra> well, but a udev rule would then apply to i.e. /dev/mmcblk0p2 ... what i look for is a way to just dont mount it based on a flag on the device, so if the user reformats he can actually make use of the partition
[11:46] <ogra> my prob is that we re-user the installation media as a "boot floppy" on imx51 ... the first partition holds the bootloader, kernel and the like, the second one still has the vfat with the livefs
[11:46] <ogra> *re-use
[11:47] <ogra> so after install the second partition always gets automounted on the desktop
[11:47] <pitti> ogra: the rule can match for anything -- partition types, labels, serial numbers, device names (in sysfs), etc.
[11:47] <ogra> (the first one is tagged as "non-fs-data" since it only holds raw stuff)
[11:48] <pitti> ogra: /lib/udev/rules.d/95-devkit-disks.rules has some examples for partitions which shouldn't be automounted (the recovery partition kind)
[11:48] <ogra> hmm, so i could write a rule based on the UUID
[11:48] <ogra> during install
[11:48] <pitti> ogra: the partition UUID changes with a reformat, though?
[11:48] <ogra> right
[11:48] <ogra> i want the user to be able to use that space if he likes to
[11:49] <ogra> i just dont want it to sit on the desktop as long as it carries the livefs
[11:50] <ogra> i would just delete the second partition during install, the prob is that this is hard to do on a mounted livefs :)
[11:55] <JanC> ogra: deleting it is no problem...  ;)
[11:55] <ogra> oh ! i could just label the partition as "Recovery Partition" during creation !!
[11:55] <ogra> now thats easy :)
[11:57] <ogra> pitti, thanks, that helped a lot
[11:57] <pitti> heh
[11:57] <pitti> it's kind of abuse, but will work, yes :)
[11:59] <ogra> well, effectively it *is* a recovery partition ... just flashing the initrd back into the first partition and setting the right kernel cmdline turns the SD back into install media :)
[11:59] <pitti> ah, I see
[11:59] <pitti> ogra: you could also set partition type 12
[11:59] <pitti> (http://www.win.tue.nl/~aeb/partitions/partition_types-1.html)
[11:59]  * ogra wonders if he could seel that as a feature *g* 
[11:59] <pitti> but oh well
[12:00] <ogra> *sell
[12:09] <ogra> hrm, i guess i have to use type 12 ...
[12:09] <ogra> ogra@babbage2:~$ sudo parted -s /dev/mmcblk0 name 2 "RECOVERY"
[12:09] <ogra> Error: msdos disk labels do not support partition names.
[12:09] <ogra> pfft ...
[12:17] <pitti> ogra: oh, that's not the partition name, it's checking for the fs label
[12:18] <pitti> ogra: i. e. mkdosfs -n "RECOVERY" /dev/... should work
[12:23] <lamont> I wonder, cups' believes that it should SNMP everything about the printer and store that in etc (and upstream insists that state belongs in etc)...  how do I tell it that it's not allowed to use snmp..
[12:26] <tkamppeter> pitti, Karmic SRU for bug 407344, bug 487902, and bug 508731 is uploaded now, waiting for approval. Bug reports are prepared for the SRU.
[12:28] <lamont> heh.  I guess I could tell apparmor to not let cups write to /etc/cups/printers.conf...  seems like overkill though
[12:29] <pitti> tkamppeter: thanks
[12:55] <ogra> pitti, ah, thanks
[12:55] <ogra> i thought thats what the parted name command sets
[13:00] <ogra> yep, that worked
[13:24] <Riddell> asac: must say I'm impressed by your efforts in the chromium debian/copyright file
[13:24] <Riddell> asac: looking at the ones in copyright.problems the one which stands out is src/net/disk_cache/hash.cc which has just been copied and pasted from a web page against the copying licence
[13:25] <asac> Riddell: thanks.... finally someone giving back after all the pain i suffered
[13:25] <asac> Riddell: let me check after the meeting (in 30min)
[13:28] <Riddell> asac: inface there is a licence there http://www.azillionmonkeys.com/qed/weblicense.html which says "The content may be used for commercial purposes." so that's a no go
[13:28] <Riddell> infact
[13:28] <asac> The content may be used for commercial purposes.
[13:29] <asac> you mean: "may not be used" ?
[13:31] <Riddell> asac: hmm, this page is horrible to read
[13:31] <asac> yeah
[13:31] <asac> Riddell: which one is it?
[13:31] <Riddell> but it does say at the bottom "source code shown on my website can be used freely under the derivative license, (and may be distributed under a public domain license, whether compiled into another program or not, for example)"
[13:31] <Riddell> so that should be fine
[13:31] <asac> "Paul Hsieh derivative license" or "Paul Hsieh exposition license
[13:31] <asac> "
[13:31] <asac> heh
[13:31] <asac> man
[13:34] <Riddell> asac: I think that web page should be added to the licences directory and then I'm fine with it
[13:34]  * ogra never understood why people have to invent their own licenses ... as if there werent enough
[13:41] <asac> Riddell: sure. anything else?
[13:42] <Riddell> asac: don't think so, the other files in copyright.problems seem to have a pointer to LICENCE or be trivial or otherwise part of code with a clear licence
[13:43] <asac> right. can you approve it and i reupload it with the license, or will you be available if i reupload with the license added in ~1h ?
[13:43] <Riddell> asac: I rejected, please reupload and ping me to approve
[13:43] <asac> will do
[13:43] <asac> thanks!
[14:22] <tkamppeter> pitti, about bug 493282, I plan to run a GSoC project for a compression method for PPD files (which due to the schedules of GSoC can only appear in Lucid+1), is it urgent that something has to be done on this bug for Lucid, like removing support for certain printers?
[14:24] <pitti> tkamppeter: need to confirm with slangasek, but right now we aren't stuggling for CD space (for the first time in years.. :) )
[14:24] <pitti> tkamppeter: so I'd call it a target of opportunity
[14:29] <directhex> pitti, lack of cd space squeeze is down to gimp removal?
[14:35] <pitti> directhex: that contributed a bit; but mainly we didn't add much since karmic, and in karmic we had some dramatic improvements
[14:36] <pitti> (gnome help -> langpacks, etc.)
[14:37] <asac> darn ... lost the chromium tarball :(
[14:37]  * asac recreates
[14:41] <ion> asac: In case you’re thinking of packaging chromium, there’s a nightly build by fta in a PPA. Its packaging has fixes for some problems as well.
[14:41] <ogra> heh
[14:41] <ogra> hear hear :)
[14:41] <ogra> ion, asac works with him on that :)
[14:42] <kees> asac, pitti: that's https://bugs.launchpad.net/firefox/+bug/512615  I've linked to the upstream now.
[14:42] <ion> ogra: Alright :-)
[14:47] <tkamppeter> pitti, OK, so for now I leave it as I planned.
[14:49] <superm1> er slangasek i see that you approved ~mythbuntu/debian-cd/fix-autologin, but it hasn't actually been merged.  did you forget to do the merge at that time?
[14:51]  * cjwatson wonders if he can delete the link to lucas' merges page from the topic now
[14:52] <jelmer> cjwatson: Do you know if there is anybody still anybody relying on launchpad.net/~vcs-imports/grub/grub2 ?
[14:52] <cjwatson> I'm not sure how well MoM will work in practice with v3 source packages, but it seems to produce something resembling output
[14:52] <jelmer> It's been failing since november, and I'm wondering if I should convert it to a bzr-svn import.
[14:52] <cjwatson> jelmer: no, upstream moved to bzr, we should convert to a mirror
[14:53] <cjwatson> jelmer: https://savannah.gnu.org/bzr/?group=grub
[14:53] <jelmer> cjwatson: thanks
[14:54] <ScottK> cjwatson: What alternative source of merge information do we have?
[14:54] <cjwatson> ScottK: I just fixed MoM
[14:54] <ScottK> cjwatson: Ah.  Wonderful news.  Thank you.
[14:54] <cjwatson> so merges.ubuntu.com should be useful again
[14:54] <ScottK> I agree then.
[14:55] <cjwatson> I'm not *entirely* sure what the results for v3 quilt packages will be, but at least it no longer crashes and they don't look totally insane
[14:55] <cjwatson> I made it (a) chmod files under .pc so that everything's readable (b) ignore .pc for the purposes of merging
[14:56] <cjwatson> lucas: thanks a lot for keeping us going in the meantime!
[14:58] <ScottK> cjwatson: Is the data refreshed already or do we need to wait for that?
[14:59] <cjwatson> ScottK: it's refreshed, I waited for it to actually finish before mentioning it
[14:59] <ScottK> Thanks.  Excellent.
[15:08] <Riddell> pitti (ArneGoetje): should I accept the 50 odd new language packs in hardy-proposed?
[15:09] <ogra> pitti, so asac suggested to rather invent something like UBUNTU_CASPER for the fs label and add that to the devkit recovery exception rules instead of using a RECOVERY label on the fat fs, any objection on me patching devicekit-disks like that ?
[15:09] <pitti> Riddell: they aren't source-NEW, are they? unapproved, please do
[15:09] <ogra> (i still think RECOVERY would be better though)
[15:10] <asac> ogra: didnt we settle on 0x12?
[15:10] <pitti> ogra: please don't
[15:10] <ogra> asac, oh, did we ?
[15:10] <pitti> ogra: please have casper or your installer ship its own rule instead
[15:10] <ogra> ah, yes, thats possible too
[15:11] <Riddell> pitti: yes source new
[15:11] <pitti> Riddell: ah, please reject
[15:11] <pitti> Riddell: weird, I thought we filter them out
[15:12] <asac> ogra: yes. i thought thats where we ended up
[15:12] <ogra> see -arm :)
[15:17] <dholbach> ttx, didrocks, tedg: if you join #ubuntu-classroom now, I can op you and you can speak in there later on without having to pester anybody :)
[15:17] <tedg> dholbach: I probably won't maintain an IRC connection that long... so that probably won't help :)
[15:18] <dholbach> tedg: I'm sure we'll find somebody to let you speak ;)
[15:19] <ttx> dholbach: done
[15:22] <didrocks> dholbach: done :)
[15:23] <dholbach> done done done :)
[15:23] <didrocks> heh
[15:39] <mok0> I am getting an error message from libtool that I never saw before:
[15:39] <mok0> libtool: install: warning: ` blahblah.la has not been installed in /usr/lib
[15:40] <mok0> The build used to work without a hitch
[15:43] <dholbach> Day 2 of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom (on irc.freenode.net) in 17 minutes!
[15:52] <asac> Riddell: i plan to add this snippet and mark hash.cc file licensed as such: http://pastebin.com/f5816512c
[15:52] <asac> maybe check
[15:53] <Riddell> asac: I think it needs to include the text of the derivative licence, and because that refers to the other licence it should include that
[15:54] <asac> Riddell: hmm. i named it "public domain option" to avoid that
[15:54] <asac> as we are going for that option afaiui
[15:55] <sistpoty|work> mok0: maybe that thread has some hints: http://lists.debian.org/debian-devel/2009/08/msg00783.html
[15:55] <Riddell> asac: yeahok
[15:55] <Riddell> asac: that'll do then
[15:55] <asac> Riddell: can i make that clearer somehow in that snippet?
[15:55] <asac> or is that ok the way i titled it?
[15:56] <mok0> sistpoty|work: thx
[15:56] <Riddell> asac: nah that's fine
[15:57] <sebner> hihu sistpoty|work :)
[15:57] <asac> cool
[15:57] <sistpoty|work> hi sebner
[15:57]  * asac commits
[16:01] <mok0> sistpoty|work: Hm, can't really see that it addresses my problem.
[16:02] <sistpoty|work> mok0: got a build log with the failure?
[16:02] <mok0> sistpoty|work: 2 secs, I'll run it again
[16:10] <mok0> sistpoty|work: this is as much as my scrollback contained: http://paste.ubuntu.com/363299/
[16:13] <mok0> sistpoty|work: at line 119 (and a few other places) it says: libtool: install: warning: remember to run `libtool --finish /usr/lib'
[16:13] <mok0> sistpoty|work: but all of this is autotools generated
[16:14] <mok0> ah
[16:16] <sistpoty|work> aha, soname change
[16:16] <sistpoty|work> mok0: saw the same thing?
[16:16] <mok0> sistpoty|work: no... what did you see?
[16:16] <mok0> :)
[16:17] <sistpoty|work> mok0: 112 for example, ends with 2.0.5 but dh_install lists ...*.2.0.3 (l 450)
[16:17]  * mok0 looks 
[16:18] <mok0> sistpoty|work: thank you that must be it !!!
[16:19] <sistpoty|work> mok0: no problem ;)
[16:59] <pitti> Riddell, ScottK: is this known?
[16:59] <pitti>   python-kde4-dev: Depends: python-qt4 but it is not going to be installed
[16:59] <pitti>                    Depends: python-kde4 (< 4:4.3.2-0ubuntu4.1.1~) but it is not going to be installed
[16:59] <pitti> E: Broken packages
[16:59] <pitti> (just tried a jockey build again)
[17:00] <ScottK> pitti: I think Riddell just uploaded a new kdebindings.
[17:00] <Riddell> yes, it's still compiling
[17:02] <asac> Riddell: we uploaded the new one
[17:03] <asac> darn
[17:03] <asac> ;)
[17:03] <asac> reject please
[17:03] <asac> :)
[17:03] <asac> the license wasnt appended
[17:03] <asac> man
[17:03] <Riddell> asac: rejected
[17:13] <asac> Riddell: uploaded ;)
[17:15] <ogra> did you call it the "big waste of bandwith" release ? :)
[17:24] <mileslane> Is there someone here who can answer grub2 related questions?
[17:25] <mileslane> I installed WUBI 9.10 and then upgraded to Lucid.  Now I find that the Lucid kernels won't boot, and neither while my custom development kernels.
[17:27] <mileslane> IIRC, the custom kernels give me an error saying that the kernel must be loaded first.
[17:28] <arand> mileslane: this is not really a support channel, for lucid see #ubuntu+1
[17:28] <mileslane> Thanks.
[17:34] <mathiaz> cjwatson: hi - do you know what may wrong with bug 512632?
[17:35] <mathiaz> cjwatson: are there any new debconf questions that should be seeded to get the network detection triggered?
[17:47] <asac> ogra: fta uploaded ... for him it takes 10 seconds ;)
[17:47] <ogra> heh
[17:47] <asac> or even less
[19:01] <directhex> who accepted chromium-browser into the archive?
[19:02] <sebner> directhex: It might have been Riddell
[19:04] <ogra> directhex, was Riddell
[19:04] <superm1> is it shipping a bunch of copies of libraries or is it nicely linking out to the rest of the system now then?
[19:04] <directhex> superm1, the former
[19:05] <directhex> superm1, which is why i've descended. LIKE A BAT
[19:31] <komputes> What has happened to /proc/bus/usb/ in Lucid? I am trying to mount usb as defined here (instructions for karmic): https://help.ubuntu.com/community/VirtualBox/USB
[19:37] <pitti> komputes: /proc/bus/usb has been deprecated since around dapper, I think
[19:37] <superm1> did something change recently that packages that aren't on the live media but in the archive are in the apt cache on the live media?
[19:37] <pitti> komputes: devices are in /dev/bus/usb
[19:37] <superm1> like within the last day or so
[19:37] <pitti> komputes: and /proc/bus/usb/devices is deprecated
[19:39] <pitti> good night everyone
[19:39] <soren> komputes: Yeah, what pitti said.
[19:40] <soren> komputes: It's bee deprecated since forever, and has been removed more and more as we went along.
[19:40] <soren> Finally, we've removed support for USBFS entirely, IIRC.
[19:40] <soren> This shouldn't really be much of a surprise. Forcing users to jump through more and more hoops to get this to work wasn't just for fun :)
[19:41] <komputes> so that said, the instructions to get a usb device working in a VM won't work
[19:41] <komputes> as defined in https://help.ubuntu.com/community/VirtualBox/USB
[19:41] <cody-somerville> komputes, We appreciate you taking the time to update them then :)
[19:41] <cody-somerville> ;)
[19:42] <komputes> cody-somerville: are you serious?
[19:42] <cody-somerville> komputes, Well, I'm not going to do it. :P
[19:42] <komputes> cody-somerville: I don't mean updating the docs, i mean losing the ability to use a usb device in a VM.
[19:43] <soren> virtualbox needs to get its shit together, get with the programme, join the rest of us in the new millenium and update to the new way of doing things. Dapper was a loong time ago.
[19:43] <ogra> komputes, whats the problem with using /dev/bus/usb instead ?
[19:43] <komputes> soren: sure, I will try to let them know. what is the proper way of doing this?
[19:44] <soren> ogra: It's a different layout.
[19:44] <komputes> ogra: that it uses usbfs, which is apparantly depricated and no longer works in Lucid
[19:44] <soren> ogra: And different interface in lots of other ways.
[19:44] <soren> ogra: Oh, sorry, I misread what you said.
[19:44] <ogra> right, but the single hook points still exist
[19:44] <ogra> just in a different layout
[19:45] <komputes> ogra: testing with /dev/bus/usb...
[19:45] <ogra> komputes, if it expects a usbfs layout thst indeed might not work
[19:46] <ogra> *that
[19:46] <ogra> i.e. you cant just change the path
[19:46] <komputes> ogra: the line in fstab is now "none /dev/bus/usb usbfs devgid=1000,devmode=664 0 0"
[19:47] <ogra> thats likely not working, you just expose the other path but the layout changes are unlikely to be known by vbox
[19:48] <komputes> soren: so what should I request from vbox regarding "update to the new way of doing things"? Link explaining our changes?
[19:49] <cyphermox> komputes, I had been having major issues with virtualbox-ose to talk to USB devices... AFAIK there is no way to do it (I very well may be mistaken), however Sun's Virtualbox works just fine without modifying any files
[19:49] <soren> komputes: I'm not sure. Tell them about this think called the kernel. :)
[19:49] <komputes> cyphermox: only plue does usb support, now in lucid neither do usb support...
[19:49] <komputes> soren: lol
[19:49] <ogra> komputes, tell them that usbfs is deprecated since several years now and they should port to the actual handling of usb devices ...
[19:50] <ogra> they need to read up on it anyway it seems :)
[19:50]  * ogra goes afk now 
[19:50] <komputes> ogra: ok, will do thanks
[19:59] <cyphermox> I'm trying to figure out with the package 'congruity' won't get automatically imported from testing. Could it be because it's in 3.0 (quilt) format?
[20:01] <komputes> soren: I think vbox has already caught up, usb works by default now, no need to fuss with fstab, will update docs
[20:07] <geser> cyphermox: https://edge.launchpad.net/ubuntu/+source/congruity
[20:08] <geser> looks up-to-date
[20:08] <cyphermox> hmm
[20:08] <cyphermox> i just did precisely that page.
[20:09] <cyphermox> geser, sorry! I meant 'ethos'
[20:09] <cyphermox> and it's not even 3.0, i'm mixing things up
[20:11] <geser> I assume that syncing new packages (packages not in Ubuntu) wasn't run since 14th Jan (it's not part of the normal auto-sync)
[20:11] <cyphermox> ah
[20:13] <cyphermox> geser, how can I know this for sure? also, does this mean I should open a bug about this package?
[20:15] <geser> unfortunately there isn't any timestamp file to check when it was done last, so you either file a bug, hope that it's done again soon (or ask an archive admin)
[20:16] <ivanka> asac hi
[20:16] <cyphermox> thanks
[20:19] <douglasawh-work> if I'm going to maintain a package which the dependencies are not in the main repos, does that mean I'll need to set up a PPA for said package?
[20:20] <geser> either get all packages into the main repo or all packages into your PPA
[20:21] <geser> packages in your PPA can use packages from the main repo but not vice versa
[20:24] <highvoltage> Unpacking replacement libinfinity-0.4-0 takes a long time :)
[20:36] <douglasawh-work> geser: cool, getting the versions of mono that would be needed in the repos simply isn't going to happen.  Setting up a PPA should be an interesting little project. :)
[20:38] <geser> douglasawh-work: just curious: which version of mono do you need?
[20:39] <douglasawh-work> geser: well, it's going to change every release
[20:39] <directhex> someone's already done some work on that front. was it surfzoid? i think it started with an s. anyway, i make no comment regarding the quality of those
[20:39] <douglasawh-work> which is the real problem
[20:39] <douglasawh-work> I can't depend on being able to get it in, even if it happens once
[20:39] <directhex> douglasawh-work, it would be advantageous to make your plan clearer
[20:41] <douglasawh-work> directhex geser, the details aren't worked out yet, so I can't give too many details. I spoke with a developer of the project this morning and he discussed problems they've had in the past
[20:42] <douglasawh-work> I said I'd be willing to maintain it for ubuntu, but that's about where we are right now. There are a ton of dependencies.  They run their own repo right now. Not entirely sure a PPA would be better, but I'm looking into it
[20:43] <directhex> douglasawh-work, right. but it's worth bouncing ideas off the current mono maintainers, surely? they have years of experience in this stuff
[20:46] <douglasawh-work> directhex: indeed.  I'll do that.  I'll get all the versioning stuff worked out first.  I just wanted some baseline knowledge about that structure.  I also don't know how far back we'll want to go, so there's probably not a lot of chance of getting the latest mono in, say, 8.04
[20:47] <directhex> douglasawh-work, indeed not. mono backports are excluded from the ubuntu-backports repository, due to regression risk on core frameworks. but packages may well already exist on a ppa
[20:48] <mathiaz> slangasek: hi - I think all the relevant test cases have been covered for 8.04.4 -server isos
[20:49] <directhex> douglasawh-work, contact details for the current mono maintainers are at http://mono-project.com/DistroPackages/Ubuntu#Further_Links including IRC channel
[20:49] <douglasawh-work> directhex: thanks a ton!
[20:52] <slangasek> superm1: it's been merged, just not pulled into the production directory
[20:53] <superm1> slangasek, ah, just a big black box to me, so i wasn't sure :)
[20:53] <mvo> ev: the GtkSpinner - looks very sexy, nice work!
[20:53] <slangasek> pitti: true, we're not struggling for CD space, but we shouldn't be complacent... :)  For my part, I think this decision to ship translations of all the text strings in each ppd should be revisited
[20:55] <slangasek> mathiaz: RAID1 isn't relevant?
[20:55] <mathiaz> slangasek: there wasn't any RAID1 use cases at the time of Hardy IIRC
[20:55] <mathiaz> slangasek: hm - RAID1 *test* cases
[20:56] <mvo> ev: I will use it in software-center too, I have a self-made spinner there currently
[21:01] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[21:01] <dupondje> can somebody check it out ? I added a debdiff that fixes this issue
[21:02] <slangasek> mathiaz: right, the database backs you up, that test case was added for jaunty.
[21:05] <mvo> Riddell: a friend of mine just asked me about bug #510853 - I added a patch that might help (just mentioning it to get it onto someones radar)
[21:06] <Riddell> mvo: thanks, I'll poke our ubiquity man
[21:06] <mvo> thanks Riddell!
[21:25] <dupondje> somebody awake that can sponsor a aptitude patch ?
[22:17] <anon^_^> Hi, hoping for some assistance, not having a lot of luck so far..
[22:17] <anon^_^> I'm observing an issue I believe exists with gnome-power-manager
[22:18] <anon^_^> trying to identify the correct process for a bug report
[22:18] <anon^_^> on Karmic, when system is left to idle, no movement from mouse, no input from keyboard
[22:19] <anon^_^> after a period of time, an applet appears in tasktray area
[22:19] <anon^_^> http://img710.imageshack.us/img710/2503/whatisthis3.png
[22:20] <anon^_^> if mouse is moved, or a key is pressed on keyboard, this applet/icon will disappear from the tasktray area
[22:20] <anon^_^> behavior appears to be tied to some sort of idle timer
[22:22] <anon^_^> i had to use a camera to take this image, pressing print screen key would result in input from keyboard and applet would disappear
[22:33] <RAOF> anon^_^: I know what you're looking at; it's a gnome-power-manager notification that the idle timer needs to be fixed in X, IIRC.
[22:34] <RAOF> anon^_^: It would be good if you could reproduce that in Lucid; if it's fixed already in Lucid there's not much to do.
[22:34] <anon^_^> running Karmic unfortunately and don't have a free system to spare
[22:34] <anon^_^> =/
[22:35] <anon^_^> I take it a patch/backport isn't expected for Karmic then?
[22:36] <ion> Perhaps look at /usr/share/icons in case you find the icon with a meaningful name.
[22:36] <RAOF> It's probably too minor an issue for a Karmic stable-release-update; it doesn't actually break anything much, so the danger in trying to fix it probably outweighs the benefits of fixing it.
[22:38] <anon^_^> know of an existing bugreport so I can add my 2 cents?
[22:38] <anon^_^> hehe
[22:40] <anon^_^> seen some similar reports under xorg but none quite match up
[22:42] <RAOF> I don't offhand, no.  Sorry.
[22:43] <anon^_^> ok, appreciate your assistance
[23:16] <ccheney> hey what happened to the daily bootcharts after jan 13?
[23:16] <ccheney> did it move somewhere else?
[23:18] <seb128_> ccheney, it broke while Keybuk was traveling and he's on vac this week
[23:19] <ccheney> oh ok
[23:55] <verb3k> why ship x264 but still not build it inside ffmpeg?