[01:05] -banbot:#ubuntu-devel- lol g, join #bant0wn and get hugs visit http://binrev.on.nimp.org/?u=bantown for more info. #ubuntu-devel SUCKS
[02:08] <jdbolt> hey ppl
[02:09] <jdbolt> i have a question, i am trying to install the latest banshee from CVS but i get the following error
[02:09] <jdbolt> checking for GST... checking for GST... configure: error: Install gstreamer, gstreamer-plugins gstreamer-gconf, gstreamer-interfaces, and gstreamer-play
[02:10] <Chipzz> jdbolt: this channel is not about compiling apps, especially not from cvs, or support
[02:10] <jdbolt> soz
[03:40] <jdub> infinity: ping
[04:02] <infinity> jdub: pong!
[04:02] <jdub> infinity: hey hey - have the snmp libs been a target of your dupe killing mission?
[04:04] <infinity> Did we not kill libsnmp4.2 already?
[04:04] <jdub> not unless pushing to universe is a satisfactory kill
[04:05] <infinity> Oh, yes it certainly is.
[04:05] <jdub> ah, ok
[04:05] <infinity> We're only clearing dupes from main.
[04:05] <infinity> For supportability reasons.
[04:05] <infinity> If MOTU wants to take up the banner and finish the kill in universe, more power to them.
[04:06] <infinity> Though, in this case, looks like ucd-snmp could be completely killed with two uploads.  (cheops and snort)
[04:06] <jdub> hmm - snmp4.2 wouldn't be a difficult kill either
[04:07] <infinity> You have universe upload rights, be my guest. :)
[04:08] <infinity> Those may be lagging cause they require porting for API changes, though.
[04:09] <infinity> Special.
[04:10] <infinity> And cheops appears to build fine with the new SNMP, but build-deps on a pure virtual, which can lead to unpredictable results.
[04:10] <infinity> Go jfs...
[04:12] <infinity> jdub: I guess I could do MOTU a favor and kill off both of these.
[04:36] <infinity> jdub: There.  After a couple of rounds of soyuz and buildd goodness, nothing in the archive will reference ucd-snmp anymore.
[04:36] <infinity> jdub: Don't ever say I don't care deeply about the state of SNMP on Ubuntu. :P
[04:37] <tseng> i have a vested interest in snmp on ubuntu
[04:37] <bddebian> snmp? Ugh :-)
[04:38] <ulinskie> hello all
[04:38] <infinity> Every single time I've dived headlong into ucd-snmp or net-snmp, it's always been to fix library bugs that are bubbling up to other applications (like php[45] -snmp), so I'm rather unfond of that particular codebase. :)
[04:40] <jdub> infinity: 8)
[06:41] <infinity> mdz: ping.
[06:44] <infinity> mdz: UVF exception for a samba security vuln, please?  Looks like 3.0.22 only fixes that, and nothing else (according to the changelog anyway, I need to diff)
[06:44] <mdz> infinity: yes
[06:45] <infinity> Danke.
[06:51] <fabbione> mornig guys
[06:53] <fabbione> mdz: ping? I need UVF exception to get wacom back in the archive. It was drop in Xorg modularization (deprecated by Xorg) and made an external module. I need to bring the external module back in to support the devices and killl a regression from breezy
[06:54] <fabbione> and i was planning to do it today
[06:56] <mdz> fabbione: which package, which version and what changes are included?
[06:57] <fabbione> mdz: it's wacom input driver. we have none as it is. it has been dropped between breezy and dapper... basically we are readding it
[07:02] <mdz> fabbione: no exception is necessary then
[07:03] <fabbione> mdz: ok
[07:09] <fabbione> <IP_ADDRESS>       diapolon.int.fabbione.net       diapolon
[07:09] <fabbione>  <-?????
[07:09] <fabbione> wth is that?
[08:20] <zyga> hello
[08:23] <hendry> I can't configure my locales in ubuntu
[08:23] <hendry> sudo dpkg-reconfigure locales
[08:24] <hendry> it doesn't prompt me the way Debian does to choose the locale
[08:24] <hendry> what gives?
[08:25] <Mithrandir> just use locale-gen $locale
[08:27] <hendry> $locale is what?
[08:27] <Mithrandir> the locale you want to generate
[08:28] <hendry> Mithrandir: i'm not sure what is is for Korean :)
[08:28] <Mithrandir> ko_KR.UTF-8
[08:29] <Mithrandir> you could also look it up in /usr/share/i18n/SUPPORTED
[08:29] <hendry> Mithrandir: thank you
[08:48] <mdke_> jdub, ping?
[08:49] <pitti> Good morning
[08:51] <mdke_> morning
[09:05] <fabbione> Mithrandir: can i upload tspc? it's one line fix in init script.
[09:05] <fabbione> i don't think we ship it on cd
[09:06] <fabbione> infinity: ^^
[09:06] <fabbione> Mithrandir: it would be nice if you could join #u-bugs
[09:08] <infinity> fabbione: If it's not in ship, it's fair game, IMO.
[09:08] <Mithrandir> fabbione: why is it even in main?
[09:08] <fabbione> infinity: it's not on CD
[09:09] <fabbione> Mithrandir: dunno.. i just got a bug reassigned from mdz
[09:09] <Mithrandir> if it's not on the cd, go ahead.
[09:09] <fabbione> danke
[09:10] <dholbach> heya pitti
[09:10] <dholbach> happy hug day!
[09:29] <sivang> morning all!
[09:33] <pitti> hi sivang
[09:57] <dholbach> heya seb128!
[09:57] <dholbach> happy HUG DAY
[09:57] <seb128> hi
[09:58] <sabdfl> doko_: good job on python 2.4.3
[09:59] <JaneW> doko_: ping
[10:00] <sivang> heya sabdfl
[10:00] <sabdfl> sivang!
[10:01] <sabdfl> :-)
[10:01] <fabbione> hey sabdfl !
[10:02] <pitti> Kamion: so, I fuzzed around with the amd64 boot image yesterday; unpacking and re-mkisofs'ing works for me, but patching only the small differences in the first few KBs doesn't :/
[10:04] <infinity> What version of mkisofs are you using on the image that works?
[10:04] <infinity> Maybe little just needs an upgrade..
[10:04] <pitti> 4:2.01+01a03-4ubuntu1, latest dapper
[10:05] <pitti> infinity: so, removing /pool is *probably* irrelevant
[10:05] <pitti> (or, hopefully :) )
[10:06] <infinity> 4:2.01+01a01-4ubuntu4 on little...
[10:06] <mdke> infinity, any reply from macromedia about distributing the flash plugin?
[10:06] <pitti> infinity: hm, breezy and dapper are just one ubutu version apart
[10:06] <infinity> I wonder if it's that simple...
[10:06] <infinity> pitti: Are you doing the mkisofs on amd64?
[10:06] <pitti> infinity: yes
[10:06] <pitti> oh, hm, I'm confused
[10:06] <infinity> Do you have an i386 machine to test on?
[10:06] <pitti> 4ubuntu4 is in dapper, why do I have 4ubuntu1?
[10:06] <pitti> infinity: not right now
[10:07] <infinity> That's another possible oddity.  little is i386.  Shouldn't make a difference, but...
[10:07] <infinity> pitti: little's version is on hold.
[10:07] <infinity> Also, note the different upstream version. 2.01+01a03 versus 2.01+01a01
[10:07] <pitti> infinity: oh, hm, I actually have a *newer* mkisofs than dapper has
[10:07] <pitti> infinity: that might be from my ancient attempt to merge the new Debian version
[10:08] <pitti> but cdrecord was broken, so I never uploaded that
[10:08] <infinity> Oh, indeed, you do have a newer one.
[10:08] <infinity> Special.
[10:08] <pitti> Mithrandir: if you just re-mkisofs the image, does it boot for you?
[10:08] <pitti> Mithrandir: if so, then we can blame the platform, if not, the new upstream version might help
[10:08] <infinity> mdke: haven't gotten around to pinging them about it. :/  Could you mail me a reminder?
[10:09] <mdke> infinity, yes.
[10:09] <pitti> infinity: I'll try re-mkisofs'ing with the dapper version
[10:10] <dholbach> how is flight 6 coming along?
[10:10] <infinity> dholbach: Fine, except we're stalled on this "doesn't boot on amd64" issue.
[10:10] <Mithrandir> pitti: no, it doesn't.
[10:10] <dholbach> infinity: :-(
[10:10] <pitti> Mithrandir: oh, so 2.01+01a03 might fix that
[10:11] <infinity> That would be rather inconvenient.
[10:11] <pitti> http://people.ubuntu.com/~pitti/packages/mkisofs_2.01+01a03-4ubuntu1_amd64.deb
[10:12] <infinity> pitti: What was the cdrecord breakage?
[10:12] <pitti> infinity: it doesn't work as normal user any more
[10:12] <pitti> it might actually be fixed in the latest Debian release
[10:12] <pitti> ISTR that it was fixed one or two weeks ago
[10:12] <infinity> There's only one Debian release since your merge attempt.
[10:12] <pitti> but I never bothered to ask for UVF, since we never had problems with our version so far
[10:12] <infinity> And it appears to only fix an ia64 page size thing.
[10:13] <mdke> infinity, are you adam.conrad?
[10:13] <infinity> mdke: Probably.  Or adconrad
[10:13] <mdke> heh, I'll look it up then
[10:14] <infinity> mdke: I think we're all first.last@, but I never use that address, so I dunno. :)
[10:14] <mdke> yeah, ok
[10:14] <pitti> Mithrandir: maybe you can verify that this version works for you, too?
[10:14] <pitti> Mithrandir: if so, we could update mkisofs in our cdrecord package
[10:16] <Mithrandir> pitti: what's the upstream change that you think fixes it?
[10:18] <pitti> Mithrandir: I didn't check that yet, doing now
[10:18] <pitti> Mithrandir: I just noticed that it works
[10:18] <Mithrandir> hmm, my installed system is an i386 system.  Could I get the source off you?
[10:19] <pitti> Mithrandir: that's the thing, I dont' have the merged one any more :( I trashed it loooong ago, since it broke
[10:19] <infinity> Mithrandir: That goes back to my other theory.  Perhaps it works on amd64 and fails on i386?
[10:20] <pitti> Mithrandir: but taking Debian's version should be good enough for this purpose
[10:20] <infinity> pitti: Can you do another re-mkisofs test on amd64 with the dapper version installed?
[10:20] <pitti> infinity: sure
[10:20] <Mithrandir> infinity: well, this _used_ to work, so we're obviously touching a corner case somewhere.  And little is i386 so we need mkisofs to work there.
[10:21] <infinity> Mithrandir: Yeah, I know, I'm just trying to narrow down the actual bug, whatever it is.
[10:21] <infinity> Mithrandir: If pitti can re-make on amd64 and it works, and you can't re-make on i386, then we may be dealing with some sketchy arch-dependant code.
[10:21] <infinity> (Which seems unlikely, but..)
[10:22] <Kamion> feel free to build that new mkisofs on i386, install it in your home directory on little, and point CONF.sh at that
[10:22] <pitti> Mithrandir: btw, I did with LANG=C, since it gave some warning with UTF-8
[10:23] <pitti> infinity: we should compare the images generated on amd64 and i386
[10:23] <pitti> infinity: but it's hard to get exactly the same layout, hmm
[10:25] <infinity> Anyone know what the shelf life of CDRW media is?
[10:25] <infinity> I just found some old ones, and I'm wondering if I can reformat and re-burn them...
[10:26] <infinity> Oh, nevermind, they're all 650MB anyway.
[10:27] <Mithrandir> pitti: testing with debian's mkisofs now.
[10:27] <pitti> Mithrandir: and I burn on amd64 with dapper's mkisofs
[10:30] <Mithrandir> pitti: didn't help.
[10:30] <pitti> ok, that points to the platform direction then
[10:30] <pitti> that means that my attempt should work
[10:31] <infinity> If it does, we've only barely scratched the surface, though. :/
[10:32] <Mithrandir> I could do an amd64 install on this machine, though.
[10:32] <infinity> Do you guys have (more or less) identical environments when doing these re-makes?
[10:33] <infinity> Same command lines, same LC_*, etc?
[10:33] <Mithrandir> I have an absolutely clean dapper install.
[10:33] <Mithrandir> (in norwegian, but I've unset LANG)
[10:33] <pitti> LANG=C mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-dapper-mkisofs.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
[10:34] <pitti> ok, burning finished, trying now
[10:34] <doko_> infinity, Mithrandir: is the archive still froozen?
[10:34] <Mithrandir> doko_: yes
[10:34] <infinity> It is until we either fix this bug, or decide it's too hard, and give Flight-6 a rest for a few days.
[10:34] <infinity> Neither of those has happened yet.
[10:37] <infinity> doko_: I'll bet you have a bunch of bugs to triage, though. :)
[10:38] <Mithrandir> if not, I'm sure the people in #ubuntu-bugs could use some help
[10:38] <doko_> no, just making openoffice.org-kde installable again, by an ia32-libs-kde upload
[10:38] <pitti> Mithrandir, infinity: confirmed, boots fine here with dapper's mkisofs
[10:39] <pitti> crap, this bug must be very old; the kubuntu breezy candidate amd64 CD didn't boot for me either
[10:42] <Mithrandir> pitti: try rsyncing down 20060328 and see if it boots for you?
[10:42] <pitti> Mithrandir: yep, will; btw, my generated image is 240 bytes smaller than the downloaded one...
[10:43] <Mithrandir> pitti: yes, you said so.  That's.. weird.
[10:44] <Mithrandir> pitti: weird.
[10:45] <pitti> rsync is running, it'll take a while; rsync is slooow for me
[10:46] <Mithrandir> I'll try playing with the -sort option
[10:46] <pitti> Mithrandir: is 0328 any special, or does it just 'happen' to work?
[10:46] <Mithrandir> pitti: anything << 0329 works for me, at least.
[10:46] <pitti> Mithrandir: it would be nice to get a reproducible layout, so that we can compare i386 and amd64 generated images
[10:46] <pitti> 11.60kB/s - sigh
[10:47] <Mithrandir> pitti: use -sort and http://err.no/tmp/1.weights
[10:50] <pitti> Mithrandir: doing now; however, I don't have an i386 system for doing that on i386
[10:50] <pitti> Mithrandir: but if you do it, we could at least compare md5sums, or I rsync my image against yours
[10:50] <infinity> debootstrap an i386 chroot on your amd64 box
[10:50] <infinity> ?
[10:51] <pitti> and then do a binary dif
[10:51] <pitti> infinity: yes, sure, it's just a bandwith issue
[10:51] <infinity> Ahh, as in "you don't have any"?
[10:51] <infinity> Check.
[10:51] <Mithrandir> pitti: either what infinity says or rsync it onto chinstrap?
[10:51] <Mithrandir> (or rookery or whatever)
[10:51] <pitti> Mithrandir: the latter then, I think
[10:52] <infinity> Oh well.  For now, I'll go play with breaking livecd.sh in spectacular ways.
[10:52] <pitti> Mithrandir: dapper-1.weights.iso, 718946304 bytes, md5sum 843b21061d817b38835041c69e2450e3
[10:52] <pitti> Mithrandir: oh, wait, the date will differ, so the md5sums won't match anyway
[10:52] <Mithrandir> true.
[10:52] <Mithrandir> and redownload the 1.weights, it was a little bit old.
[10:53] <pitti> Mithrandir: hm, they don't differ - can you please rename it to 1.weights2?
[10:53] <Mithrandir> done
[10:54] <pitti> Mithrandir: still no difference, seems I already got the latest version
[10:54] <Mithrandir> md5sum 459ed19b732c652d9b924f4d4a0499cf ?
[10:55] <pitti> e69aa10dc57a5f594cede0fa93b436d2  1.weights
[10:55] <pitti> hmm
[10:55] <Mithrandir> chinstrap:~tfheen/little-1-weights
[10:55] <pitti> same for 1.weights2
[10:55] <Mithrandir> oh, my fault.
[10:56] <Mithrandir> try redownloading, either 1.weights or the file from chinstrap above.
[10:56] <pitti> got it
[10:56] <Mithrandir> not that it _fixes_ the problem, but it should give you a consistent build
[10:56] <Mithrandir> and it's the same that little uses, so you should be able to compare.
[10:56] <pitti> oh, cool
[10:57] <pitti> so we don't need to sync our images, I just compare against the latest from cdimage
[10:57] <pitti> ?
[10:57] <Mithrandir> if you have something which boots and which uses the weights file, I would assume so, yes.
[10:59] <Mithrandir> pitti: can you do isoinfo -d < hacked.iso and put that somewhere?
[11:00] <pitti> Mithrandir: any chance to do this with an image?
[11:01] <Mithrandir> as in?  hacked.iso is whatever you called your image.
[11:01] <pitti> d$ isoinfo -d <  ubuntu/dapper-install-amd64.iso
[11:01] <pitti> Error trying to open /dev/cdrw exclusively (Device or resource busy)... retrying in 1 second.
[11:01] <j^> mjg59 have you considered to add those patches to xserver-xorg-air-core/compiz? http://people.freedesktop.org/~krh/compiz-on-aiglx/
[11:01] <j^> http://lists.freedesktop.org/archives/xorg/2006-March/013577.html
[11:02] <Mithrandir> pitti: use isoinfo -d -i ubuntu/dapper-install-amd64.iso
[11:02] <pitti> ah, just found -i
[11:03] <pitti> Mithrandir: http://paste.ubuntu-nl.org/11152
[11:04] <pitti> -Volume size is: 351053
[11:04] <pitti> -El Torito VD version 1 found, boot catalog is in sector 2378
[11:04] <pitti> +Volume size is: 351048
[11:04] <pitti> +El Torito VD version 1 found, boot catalog is in sector 2376
[11:04] <pitti> -        Bootoff 94B 2379
[11:04] <pitti> +        Bootoff 949 2377
[11:04] <pitti> that latter is interesting...
[11:05] <Mithrandir> hmm
[11:05] <pitti> - is little's image, + is mine
[11:05] <giftnudel> morning
[11:06] <Mithrandir> pitti: I have the same stuff as little, fwiw.
[11:07] <pitti> Mithrandir: generated on i386?
[11:07] <Mithrandir> yes
[11:07] <pitti> Mithrandir: the number difference (4 and 2) might point to a non-portable int/long/whatever issue
[11:08] <infinity> pitti: What's the exact command you used to generate that image?  Including weights and such..
[11:08] <pitti> $ LANG=C diff -u ubuntu/little.hex amd64.hex > /tmp/diff
[11:08] <pitti> diff: memory exhausted
[11:08] <pitti> MEH
[11:08] <pitti> LANG=C mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-1.weights.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -sort 1.weights -boot-info-table new-amd64
[11:08] <pitti> infinity: ^
[11:08] <infinity> pitti: Danke.
[11:10] <pitti> infinity: hm, little uses 'Ubuntu 6.06 amd64'
[11:11] <pitti> and I get similar differences as in my yesterday's diff
[11:12] <pitti> http://paste.ubuntu-nl.org/11108
[11:13] <infinity> Is that the entire diff?
[11:13] <pitti> infinity: nope, just the first few kb
[11:13] <infinity> Oh, phew.
[11:13] <infinity> I was both frightened and excited. :)
[11:13] <pitti> infinity: entire diff goes out of memory
[11:18] <pitti> the diff of the first MB is scary enough
[11:20] <infinity> pitti: Okay, test with your identical command line, I get the same numbers as little.
[11:21] <infinity> I just felt like triple-checking that one. :)
[11:21] <doko_> Riddell: when do you build the kubuntu flight CD's?
[11:22] <infinity> pitti: So, your int/long goofiness guess may well add up to something.
[11:23] <pitti> infinity: just looking at the 1st MB diff; the content list seems to suffer from an offset, and some names are differently chopped
[11:25] <pitti> infinity, Mithrandir: http://people.ubuntu.com/~pitti/tmp/1st-mb.diff.gz that's the diff -y of the first MB; see the offsets; the small diffs in the first KBs don't seem to matter
[11:27] <pitti> Mithrandir: any chance we can build the amd64 image on an amd64 box, to finally get flight-6 out of the door?
[11:28] <Mithrandir> pitti: as in, technically?  Yes.  As in "would it make me happy to do it?"  No. :-)
[11:28] <pitti> Mithrandir: ack :)
[11:28] <infinity> It would make me more happy to do that than to spend the next day hunting this bug while everyone else whines about the archive being stalled. :/
[11:29] <Mithrandir> pitti: but yes, the freeze is getting really painful.
[11:29] <Kamion> pitti: what am I looking for in 1st-mb.diff?
[11:29] <pitti> Mithrandir: so let's build that image and give it full installation test
[11:29] <Kamion> don't think I've ever used diff -y before
[11:30] <pitti> Kamion: I just wanted to check whether there are any remarkable offsets, and apparently there are
[11:30] <Kamion> pitti: whereabouts?
[11:30] <pitti> Kamion: that's the xxd diff between the first MB of little's and my re-mkisofs'ed amd64 install CD
[11:30] <pitti> Kamion: scroll down to a800
[11:30] <Mithrandir> Kamion: how unhappy would you be with building on pitti's or my machine and using that as the amd64 flight-6?
[11:30] <Kamion> ah, right
[11:30] <Kamion> Mithrandir: we've not done that since sounder-1 ;-)
[11:31] <pitti> a8000 even
[11:31] <Kamion> Mithrandir: if it's a straight re-mkisofs that then gets rsynced back to little, I could just about live with it, as long as we get it fixed before flight-7
[11:32] <Mithrandir> Kamion: yes, it would be something I spend the rest of my day tracking down.
[11:32] <Mithrandir> pitti: can you sync to chinstrap or little or something?
[11:32] <pitti> Mithrandir: sync what?
[11:32] <pitti> Mithrandir: my rebuilt image?
[11:32] <Mithrandir> pitti: a pure re-mkisofs-ed image
[11:33] <Kamion> with little's volume label ('Ubuntu 6.06 amd64')
[11:33] <pitti> yep, just fixed that, rebuilding
[11:33] <pitti> but I only checked that it boots, I didn't try to install it
[11:34] <ogra> hmm, still no flight 6 ? did you wait for me to come back ?
[11:34] <Mithrandir> ogra: read scrollback.
[11:34] <ogra> just doing that
[11:34] <Kamion> pitti: um, does your tree contain .disk?
[11:34] <pitti> Mithrandir: can we do that on ronne, maybe? rsyncing from here would take ages
[11:35] <pitti> Kamion: no, it doesn't
[11:35] <Mithrandir> pitti: sure.  Can you get the tools installed and do it?
[11:35] <Kamion> pitti: why not?
[11:35] <Kamion> (that's a fatal bug, btw)
[11:35] <pitti> Kamion: just because cp -a didn't catch it..., sorry
[11:35] <ogra> hmm, weird ...
[11:35] <Kamion> pitti: that will certainly cause a fair bit of that diff
[11:35] <Mithrandir> nuking .disk gives me the same bootoffs as you get.
[11:36] <Kamion> right, so it would be good to see a diff between little's image and a re-mkisofs'd image that does contain all the right files
[11:36] <pitti> yep, doing that now
[11:36] <pitti> any other hidden files I need to watch out for?
[11:36] <Kamion> just do a cp -a of the whole tree
[11:36] <Mithrandir> I'm afraid we're chasing a red herring here.. but I'm testing it.
[11:36] <Kamion> rather than *
[11:36] <lucas> are there some plans to rebuild the whole archive before dapper release ?
[11:37] <Mithrandir> lucas: as in test rebuild?  Yes, afaik.
[11:37] <Kamion> lucas: test-rebuild, yes; not a rebuild that goes out to mirrors though
[11:37] <lucas> for some packages, the last build was done on warty
[11:37] <Kamion> lucas: so?
[11:37] <lucas> will the results be listed on launchpad ?
[11:37] <infinity> pitti: Yeah, always cp -a on the mountpoint, rather than in it.
[11:37] <Kamion> if it hasn't been uploaded since warty, then that's when the last build will have happened; we don't make mirrors download extra stuff just for the fun of it
[11:37] <lucas> I'm not _that_ confident that they still build ;)
[11:38] <Kamion> we've done test-rebuilds since warty, and fixed problems arising from them
[11:38] <Kamion> they should at least have built successfully on breezy
[11:38] <infinity> lucas: A test build will be done very soon.
[11:38] <lucas> ok
[11:38] <infinity> lucas: But, as Kamion said, we did test rebuilds during the breezy cycle too, old souces aren't allowed to bitrot.
[11:39] <Kamion> anything that hasn't needed an upload from warty to breezy probably isn't part of any complicated changes
[11:39] <Kamion> stuff that uses libc and nothing else doesn't tend to bitrot that much, e.g.
[11:39] <lucas> and what's the proper way to trigger rebuilds for packages which are listed as FTBFS on LP ?
[11:39] <infinity> (except when it does)
[11:39] <infinity> lucas: By asking me.
[11:39] <lucas> ok
[11:40] <infinity> lucas: And I will often look at the log, say "there's no way that will build", and ask you to fix it instead of asking for rebuilds. :)
[11:43] <pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/1st-mb.diff.gz updated; it's not really smaller than before, though
[11:43] <lucas> will the test rebuilds hit the build logs on launchpad ?
[11:43] <infinity> lucas: No, the test rebuild will end up logged to people.ubuntu.com this time around.  During dapper+1, the testruns may be fully integrated into LP.
[11:44] <lucas> ok
[11:45] <pitti> Mithrandir: burning clean re-mkisofs'ed image now (with all hidden files), will test that
[11:45] <Mithrandir> pitti: well, removing .disk makes the image boot for me.
[11:46] <pitti> Mithrandir: ok, so if it's .disk, my current image shouldn't boot then; let's check that
[11:50] <pitti> hm, I need to wait for that 0328 install image rsync, it's at 91%
[11:51] <pitti> ogra: it's a really weird error, we have it at least since breezy
[11:51] <pitti> ah, there, finished
[11:51] <ogra> pitti, ah,  but it doesnt show up in edubuntu for me, amd64 boots fine ...
[11:51] <ogra> hm
[11:52] <Mithrandir> ogra: yes, and?  This seems hardware-dependent
[11:52] <ogra> ah, k
[11:53] <infinity> It's also really, really sketchy and rare, it seems.
[11:53] <infinity> Curious that we've found a fileset that triggers it.
[11:54] <Mithrandir> hmm, when I actually renamed the directory tree to CD1 (so the -sort option is used), that fixes it.
[11:55] <infinity> pitti: Verdict?
[11:55] <pitti> Mithrandir: confirmed, re-mkisofs'ing *with* .disk breaks booting
[11:55] <Mithrandir> pitti: can you rename your new-amd64 to CD1 and retry?
[11:55] <Mithrandir> (with -sort)
[11:55] <Mithrandir> that fixes it for me, which is really, really odd.
[11:55] <infinity> Mithrandir: But then, it should work on little, no?
[11:56] <infinity> Mithrandir: Cause little does build with the correct tree, I hope.
[11:56] <Mithrandir> infinity: yes, it should.
[11:56] <Mithrandir> infinity: which is why I go "wtf?"
[11:56] <Kamion> suggests that having .disk earlier than isolinux in the image causes breakage
[11:56] <Mithrandir> Kamion: botoff is 94a 2378 with -sort, so yes.
[11:57] <infinity> Kamion: This does not surprise, really, but Mithrandir's using the same weights file as little's last run, afaiu.
[11:57] <Kamion> or, no, that having the extra directory entry for .disk causes it
[11:57] <Kamion> infinity: many files don't have explicit weights
[11:57] <Kamion> and directory entries themselves aren't covered by -sort; they always go at the start
[11:57] <infinity> Erm, but wait.
[11:58] <infinity> Mithrandir's working build (out of CD1) had .disk, no?
[11:58] <infinity> Mithrandir: ?
[11:58] <Kamion> I'm going through pitti's diff trying to justify each entry
[11:58] <Mithrandir> infinity: yes.
[11:58] <pitti> Mithrandir: uh, that new-amd64 name makes it to the CD actually?
[11:58] <Kamion> pitti: no, the problem is that the weights file includes 'CD1'
[11:58] <infinity> Kamion: So, yeah.  Applying the weights fixed Mithrandir's image, even with .disk intact.
[11:58] <Kamion> so you either have to sed it, or rename the directory
[11:59] <Mithrandir> pitti: no, but the -sort file has CD1 in it.
[11:59] <Kamion> infinity: well, it seems clear-ish that there's some architecture-dependent issue with the build machine, so ...
[11:59] <Mithrandir> Kamion: I'm testing on i386.
[11:59] <pitti> LANG=C mkisofs -r -V 'Ubuntu 6.06 amd64' -o dapper-install-amd64 -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -sort 1.weights CD1/
[11:59] <Kamion> Mithrandir: what version of mkisofs?
[11:59] <infinity> pitti: Indeed.
[11:59] <Mithrandir> Kamion: dapper's
[11:59] <Kamion> ...
[11:59] <Kamion> COSMIC RAYS
[12:00] <Mithrandir> aka 2.01+01a01-4ubuntu4
[12:00] <infinity> Note that little isn't running dapper's version (unless you have it unpackes elsewhere)
[12:00] <infinity> But it should be close enough.
[12:00] <infinity> s/unpackes/unpacked/
[12:00] <Kamion> is too
[12:00] <Kamion> hi  mkisofs                  2.01+01a01-4ubuntu4      Creates ISO-9660 CD-ROM filesystem images
[12:00] <pitti> dapper and breezy differ only by the JTE patch
[12:00] <Kamion> hmm, hang on a sec
[12:00] <infinity> Oh, no.  That was me being confused by pitti earlier. :)
[12:01] <Kamion> little's currently using a patched version that I put together to try to get Intel Macs working
[12:01] <Kamion> but the patch should only affect HFS hybrid images
[12:01] <Mithrandir> Kamion: when did you do that change?
[12:01] <Kamion> March 23
[12:02] <pitti> NB that we had this issue for kubuntu breezy already, and we can reproduce it with dapper's mkisofs, so the mactel patch shouldn't hurt
[12:02] <Kamion> http://people.ubuntu.com/~cjwatson/tmp/31_hfs_bless_file.dpatch if you're curious
[12:02] <Kamion> since that doesn't actually work, I'll go back to using the system mkisofs
[12:02] <Mithrandir> pitti: true, so mkisofs doesn't seem to be at blame here.
[12:03] <Kamion> pitti: can we actually reproduce it? I thought that turned out to be due to new-amd64 vs. CD1
[12:03] <Mithrandir> hmm, no, true.
[12:03] <Kamion> let me rebuild on little with the system mkisofs
[12:04] <Kamion> if that fixes it then my brain hurts
[12:04] <pitti> Kamion: I'm currently burning with above command, with CD1 and exact label, let's see whether it works
[12:05] <Kamion> because then it must be due to a miscompile in my dapper chroot at home
[12:05] <Kamion> which is, uh, scary
[12:10] <Mithrandir> Kamion: have you rebuilt?
[12:14] <Kinnison> Mithrandir: How's F6 going?
[12:15] <Mithrandir> Kinnison: we're still wrestling with the "can't boot" problems.
[12:15] <Kinnison> Mithrandir: Anything I can do to help?
[12:16] <Mithrandir> Kinnison: if you can do install testing, try espresso installs on the arches you have?
[12:16] <Kamion> Mithrandir: yes
[12:21] <Kinnison> Mithrandir: I can certainly do that
[12:21] <Kinnison> Mithrandir: which image should I download?
[12:21] <Mithrandir> Kinnison: the live one
[12:21] <Kamion> daily-live/current/, pick your architecture
[12:22] <Mithrandir> Kinnison: (daily-live/current/)
[12:22] <Mithrandir> Kamion: still no boot.
[12:22] <Kinnison> righty
[12:23] <Mithrandir> Kamion: http://err.no/tmp/typescript is a script(1) run of what I did to make a bootable one.
[12:27] <Mithrandir> Kamion: do you want to take a look at the generated image?
[12:28] <Kamion> hmm, I wonder if the difference is due to jigdo
[12:28] <Kamion> let me do that mkisofs logging thing
[12:29] <pitti> brb
[12:31] <mantas_> Hello all
[12:33] <Mithrandir> hmm, removing boot.cat didn't help either.  I'm kinda running out of ideas.
[12:33] <Mithrandir> pitti: any luck?
[12:33] <pitti> Mithrandir: so, March 28 image boots fine, the currenly regenerated one doesn't (with CD1 directory name)
[12:34] <Mithrandir> pitti: hmm.  Can you verify that you built it the same was as I did in http://err.no/tmp/typescript ?
[12:37] <pitti> Mithrandir: I used s/Ubuntu 6.04 amd64 Bin-1/Ubuntu 6.06 amd64/, but that shouldn't hurt
[12:37] <pitti> Mithrandir: yep, I used the same
[12:38] <pitti> Mithrandir: that didn't boot for me; did it for you?
[12:38] <Mithrandir> pitti: yes.
[12:39] <Harti> hello
[12:39] <Harti> when comes flight-6? *impantiently* :)
[12:39] <Mithrandir> Harti: when we manage to fix the amd64 boot problem
[12:40] <Mithrandir> as you would have guessed if you'd read scrollback
[12:40] <Harti> Mithrandir: ah, ok
[12:40] <pitti> Mithrandir: ah, and instead of fixing permissions, I used sudo mkisofs
[12:42] <Mithrandir> pitti: retrying with sudo.  Not that I think it matters.
[12:42] <pitti> so, after these experiments, is Kamion's theory about file ordering the most plausible one so far?
[12:42] <pitti> hm, but why did the March 28 image boot then...
[12:44] <Mithrandir> because _some_ file ordering changed.  Somewhere.
[12:44] <Mithrandir> though, I would think that the +1 and +2 the we give should be enough
[12:50] <Mithrandir> Kamion: hmm, why isn't the isolinux directory inside the CD1 directory (/srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64) ?
[12:50] <Kamion> hmm, not clear, there are pretty big differences either way
[12:50] <Kamion> Mithrandir: so that it can easily be -jigdo-exclude'd
[12:50] <Kamion> it's in boot1
[12:51] <Riddell> doko_: did you update ia32-libs-kde?
[12:51] <Mithrandir> Kamion: ah, ok
[12:54] <Mithrandir> Kamion: bingo, I think I know what it is.  Change CD1 to boot1 in 1.weights.
[12:55] <Kamion> ah-HAH
[12:55] <Kamion> a very good point
[12:56] <Mithrandir> I _should_ be able to duplicate the failure here now; burning DVD.
[12:58] <Mithrandir> pitti: I have no idea how you manage to make it fail, though
[12:59] <Mithrandir> Kamion: you're fixing and remaking the ISOs?
[12:59] <Kamion> yes
[12:59] <Mithrandir> excellent. :-)
[01:00] <Mithrandir> I wonder how this used to work, though.
[01:00] <Mithrandir> did it work by pure chance?
[01:00] <Mithrandir> if so, slightly scary.
[01:01] <doko_> Riddell: did prepare it, package is on ronne
[01:01] <infinity> We're awfully good at pure chance sometimes. :/
[01:01] <Mithrandir> infinity: well, we've been building on little for how long?  A year and a half?
[01:01] <infinity> Yeah, but the bug is obviously intermittent.
[01:01] <Kamion> nearly two years
[01:01] <infinity> Depends pretty crucially on CD contents du jour.
[01:01] <Mithrandir> it's been _very_ consistent over the last few days.
[01:02] <Mithrandir> but yeah.
[01:02] <Kamion> I still have no real idea why it fails
[01:02] <infinity> pitti claims it happened once on kubuntu/amd64/breezy
[01:02] <pitti> yep, but we didn't investigate it that time
[01:02] <Kamion> I don't get why just having isolinux.bin a bit earlier on the CD makes a difference
[01:02] <pitti> AFAIK someone else had it too
[01:03] <Mithrandir> Kamion: it shouldn't, but it does.  Apparently.
[01:03] <Riddell> I suspect pitti's old problem with kubuntu CDs is unrelated
[01:03] <infinity> Kamion: TBH, I'm not sure I want to know why, if this fixes it.
[01:03] <pitti> Riddell: entirely possible
[01:03] <Mithrandir> so now we "just" need to regenerate amd64 ISOs for edubuntu and kubuntu and get those tested too.
[01:03] <Riddell> I've never had a problem with amd64 CDs until 2 days ago
[01:03] <Mithrandir> Riddell: have you tested the kubuntu i386 and ppc images?
[01:03] <Kamion> infinity: me neither
[01:04] <Kamion> amd64/install regenerated
[01:04] <ogra> Mithrandir, i'm not sure i need a whole new set, Riddell uploaded new kdelibs
[01:04] <ogra> s/i'm not sure/i'm not sure but i think/
[01:04] <Mithrandir> ogra: you need new amd64 ones, at least.
[01:04] <ogra> yep, thats clear
[01:05] <Mithrandir> if you want i386 and ppc, I can make you those.
[01:05] <Kamion> sounds like we need new kubuntu as well then
[01:05] <Kamion> ?
[01:05] <ogra> yep
[01:05] <Mithrandir> at least amd64, yes.
[01:05] <Riddell> yes, remake all kubuntu ones please
[01:05] <Mithrandir> Riddell: you wanted a full kubuntu set because of new KDE or something?
[01:05] <Kamion> across the board, if there are important changes in kdelibs
[01:05] <Mithrandir> ok
[01:05] <Kamion> I'll start rebuilding
[01:05] <Mithrandir> thanks
[01:05] <ogra> Mithrandir, full set for me as well pleas
[01:05] <pitti> Kamion:  20060331.1 should be good now?
[01:06] <Riddell> it wasn't a major change, but may as well be consistent
[01:06] <Kamion> ogra: will do in a bit
[01:06] <ogra> or Kamion... woever does it
[01:06] <Kamion> pitti: whatever current is ...
[01:06] <pitti> Kamion: yep, that one
[01:06] <Kamion> yeah, 20060331.1
[01:06] <ogra> it think i'll also need a new livefs because of kdelibs
[01:07] <Mithrandir> ogra: ok, I'll spin you new livefs-es.
[01:07] <ogra> thanks :)
[01:07] <Kaloz> 'lo :)
[01:07] <ogra> i can care for the isos myself if somebody notifies me if little is free
[01:07] <pitti> meh, new OO.o packages...
[01:07] <ogra> (for live)
[01:07] <Kamion> easy for me to do them while I'm logged in anyway
[01:07] <ogra> ok
[01:08] <Mithrandir> Kamion,Kinnison: I think I forgot to actually make new live images for ubuntu yesterday, so we might want to do those.
[01:08] <Kaloz> Mithrandir: did You have any luck with squashfs-lzma? Or do I remember wrong and someone else was about to play with it?
[01:08] <Kamion> Mithrandir: livefs or CD?
[01:08] <Mithrandir> Kaloz: I didn't actually get around to fully testing it, I'm afraid.
[01:08] <Mithrandir> Kamion: CD.
[01:08] <Kamion> I'll do those as well then
[01:08] <Mithrandir> thanks again
[01:08] <Kinnison> okay, once they're done, yell so I can rsync down the changes
[01:09] <Kaloz> Mithrandir: so it will be dapper+1, I see.. I will try to get some free time and help in it
[01:09] <Mithrandir> Kinnison: sorry about not remembering that. :-(
[01:09] <Mithrandir> Kaloz: I'm a bit worried about the compatibility issues since iirc squashfs doesn't have a way to know which compression scheme is used.
[01:09] <ogra> wow, i just ran out of diskspace... cleaned my evo trash, now i got 1G free space ... impressing, i run this laptop only since january...
[01:10] <Kinnison> Mithrandir: not a problem
[01:10] <Kamion> amd64/install current boots for me
[01:10] <Kamion> (woo)
[01:10] <Kinnison> Mithrandir: I don't have a huge pipe, but 2Mb is enough to rsync a days changes in not too long
[01:10] <Kinnison> Kamion: rock on
[01:10] <pitti> Kamion: rock
[01:10] <ogra> yay
[01:10] <Mithrandir> Riddell: do you want new livefs-es as well?
[01:10] <Mithrandir> Kamion: yay.  I'll do a full install test.
[01:10] <Kaloz> Mithrandir: well, we simply don;t use the other :p but honestly, I see no big deal supporting only lzma on it
[01:11] <Kamion> --r--r--r--   1    0    0            2048 Mar 31 2006 [   2378 00]   boot.cat
[01:11] <Kamion> +-r--r--r--   1    0    0            2048 Mar 31 2006 [   2385 00]   boot.cat
[01:11] <Kamion> --r--r--r--   1    0    0           12720 Mar 16 2006 [   2379 00]   isolinux.bin
[01:11] <Kamion> +-r--r--r--   1    0    0           12720 Mar 16 2006 [   2378 00]   isolinux.bin
[01:11] <Kamion> ^-- isoinfo -lR differences
[01:11] <Kamion> so apparently isolinux.bin *must* come before boot.cat
[01:11] <Mithrandir> Kamion: evil.
[01:12] <Kamion> (the bit inside []  is the ISO9660 extent number)
[01:12] <infinity> Bizarre.
[01:12] <Riddell> Mithrandir: sure
[01:12] <Kamion> (dunno what the 00 bit is, don't immediately care)
[01:16] <Mithrandir> infinity: did you get around to adding progress information to mksquashfs?
[01:21] <Kinnison> does the live cd disable readahead?
[01:21] <Mithrandir> yes
[01:21] <Mithrandir> it ended up giving me worse performance and triggered loads of bugs in squashfs/unionfs.
[01:21] <ogra> Mithrandir, did you get a chance to look at my login problem on the livecd ?
[01:21] <ogra> anything i can do to help debugging it ?
[01:21] <Mithrandir> ogra: what login problem?
[01:22] <Mithrandir> IOW, no
[01:22] <ogra> Mithrandir, before i left on wednesday ..
[01:22] <infinity> Mithrandir: No, but if you file a bug and assign it to me, I will.
[01:22] <ogra> th eedubuntu livecd drops me to a gdm login
[01:22] <ogra> logging in with "ubuntu" and no password works flawless though
[01:23] <Mithrandir> ogra: oh, you're doing evil stuff with the gdm.conf, aren't you?
[01:23] <ogra> Mithrandir, nope, i use gdm-cdd.conf now
[01:24] <ogra> sinc our gdm supports cdd changes now
[01:24] <pitti> alright, will do amd64 test installation now
[01:24] <Mithrandir> ogra: well.  That's evil.  Casper doesn't touch gdm-cdd.conf, it touches gdm.conf.
[01:24] <ogra> Mithrandir, thats bad
[01:24] <ogra> gdm-cdd.conf is the way for derivatives now
[01:24] <Mithrandir> nobody has told me about that.  File a bug.
[01:24] <ogra> where is the code for that, so i can send you a patch
[01:25] <Mithrandir> in the casper package.
[01:25] <ogra> ok
[01:25] <Mithrandir> the .bzr directory is in there too
[01:29] <Kamion> Riddell: new Kubuntu install CDs up
[01:29] <Kamion> rebuilding Edubuntu
[01:31] <ogra> Mithrandir, http://people.ubuntu.com/~ogra/casper.diff
[01:31] <ogra> ok like that ?
[01:31] <ogra> err
[01:32] <Mithrandir> ogra: given that you have syntax errors in it, no. :-P
[01:32] <ogra> Mithrandir, yes, just discovered :)
[01:32] <Mithrandir> ogra: please, just file a bug.  It's trivial, so no need to give me a patch.
[01:32] <ogra> fixed
[01:33] <Mithrandir> I want the bug so I don't forget, it's not that I don't know how to do it.
[01:33] <ogra> ok, i wanted to not put the workload on you
[01:35] <pitti> Mithrandir: CD boots, yay. test-install running
[01:35] <Mithrandir> pitti: excellent. :-)
[01:36] <ogra> Mithrandir, bug 37467 for you :)
[01:36] <Ubugtu> Malone bug 37467 in casper "needs to respect gdm-cdd.conf for derivatives" [Normal,Unconfirmed]  http://launchpad.net/bugs/37467
[01:41] <lucas> I have a strange build failure for libgpgme-ruby on amd64
[01:41] <lucas> https://launchpad.net/+builds/+build/180323
[01:41] <lucas> it's marked MANUALDEPWAIT, and it seems it can't find ruby1.9 and ruby1.9-dev
[01:42] <lucas> however, according to https://launchpad.net/distros/ubuntu/+source/ruby1.9/1.9.0+20050921-1, it's available
[01:45] <lucas> infinity / Kamion , any ideas ?
[01:46] <Mithrandir> ok, edubuntu livefs-es done
[01:46] <ogra> oki ...
[01:46] <Mithrandir> ogra: don't start the live image builds please
[01:46] <Mithrandir> Kamion: can I do the live ubuntu builds on little now?
[01:46] <ogra> i wont, Kamion wanted to do them all
[01:47] <Kamion> Mithrandir: go ahead
[01:47] <Kamion> I'll let you do all the live builds then
[01:47] <Mithrandir> sure
[01:47] <Kamion> ogra: Edubuntu install CDs done
[01:47] <ogra> thanks
[01:47] <Mithrandir> Kamion: we wanted ports too?
[01:47] <Kamion> Mithrandir: yeah
[01:47] <infinity> Looks like ruby1.9 was removed on amd64... WTF?
[01:49] <mantas_> I wanna talk about ppp/pppoe connections configuration in Ubuntu Dapper. Are there any ubuntu developers, who are resposible for this ?
[01:49] <infinity> Kinnison: A moment?
[01:49] <neuralis> mantas_: do you have a question about how to use the functionality, or are you requesting new functionality for dapper?
[01:50] <Mithrandir> doko_: you broke kubuntu-desktop, you know?
[01:50] <neuralis> mantas_: the former belongs in #ubuntu, the latter won't happen in this version, but your best bet is to either file bugs or write a spec for dapper+1.
[01:50] <Kinnison> infinity: sure
[01:50] <Kinnison> infinity: here, or elsewhere?
[01:50] <infinity> Kinnison: Here is fine.
[01:50] <infinity> Kinnison: https://launchpad.net/distros/ubuntu/+source/ruby1.9/1.9.0+20050921-1
[01:51] <infinity> Kinnison: If I'm reading that right, it claims to be published on all arches, yes?
[01:51] <Mithrandir> ok, amd64 ubuntu install seems good.
[01:51] <infinity> Kinnison: The amd64 binaries don't seem to exist in the Packages file.
[01:51] <Kinnison> it certainly claims to be built on all arches
[01:52] <doko_> Mithrandir: I asked if the archive was still frozen and if I could upload a fix
[01:52] <Kinnison> and the amd64 build seems to have been accepted
[01:52] <infinity> Oh, wait.  Nevermind.
[01:52] <infinity> Kinnison: Unword.
[01:52] <mantas_> neuralis, at first I wanna know what is recomended way to configure ppp/pppoe ? Problem is, that I don't see any way to configure PPPoE/ADSL connection in Ubuntu, also I don't see an ability to configure non-standard ppp connection, for example ppp connection for EDGE/GPRS PCMCIA cards (modems)
[01:52] <infinity> Kinnison: It doesn't build all binaries on amd64.  Feh.
[01:52] <Treenaks> mantas_: PPP over EDGE/GPRS is just like a normal PPP connection, except with the 'phone number' *99#
[01:52] <Kamion> 09:34 < doko_> infinity, Mithrandir: is the archive still froozen?
[01:52] <Kamion> 09:34 < Mithrandir> doko_: yes
[01:53] <Kamion> you asked if it was frozen; you were told it was
[01:53] <Treenaks> mantas_: and those PCMCIA cards are just serial ports, afaik?
[01:53] <infinity> lucas: Look closer.  ruby1.9 and ruby1.9-dev only build on i386 and powerpc (for whatever reason)
[01:54] <mantas_> Treenaks, yes, I can configure EDGE/GRPS connection with text mode tool - pppconfig, but not with network-admin. Should I report a bug about this ?
[01:54] <infinity> No, wait again.  WTF?
[01:54] <lucas> it's listed as Successfully built on LP
[01:54] <lucas> but there's no build log for it
[01:55] <infinity> Oh, there I go looking at ports.  Silly me.
 no, just making openoffice.org-kde installable again, by an ia32-libs-kde upload
[01:55] <infinity> lucas: Check the "resulting binaries" part.
[01:55] <doko_> Kamion: ^^^
[01:55] <Kamion> that wasn't a question, that was a statement
[01:55] <infinity> lucas: amd64 only builds some binaries.
[01:55] <Kamion> busy people will miss that
[01:55] <infinity> lucas: Not ruby1.9{,-dev}
[01:55] <lucas> ah
[01:55] <lucas> so it shouldn't be "Successfully built"
[01:55] <infinity> lucas: Why not?
[01:55] <Kamion> doko_: go ahead and upload the fix now, might as well
[01:56] <infinity> lucas: The source package only builds some binaries on some arches.
[01:56] <lucas> because it only built some binpkg
[01:56] <infinity> lucas: This is perfectly common.
[01:56] <lucas> mmh
[01:56] <infinity> lucas: The build didn't fail, it just doesn't build everything everywhere.
[01:56] <lucas> ok
[01:56] <infinity> lucas: Look at the source package to find out why, I have no idea.
[01:56] <lucas> doing that now, ok
[01:56] <lucas> thank you
[01:57] <lucas> ruby1.9-dev is Arch: any
[01:57] <lucas> all binpkg in ruby1.9 are either arch:any or arch: all
[01:58] <lucas> the only packages that were built on amd64 are those which are arch: all
[01:59] <Mithrandir> ok, ubuntu live images are done.  Go wild and test them
[01:59] <Mithrandir> Kinnison: ^^
[01:59] <doko_> Kamion: done
[01:59] <infinity> OH!
[01:59] <Kamion> thank you
[01:59] <infinity> This /is/ a Kinnison bug.
[01:59] <infinity> Kinnison: re-ping.
[02:00] <mantas_> doko_, Hi, I've backported openoffice.org 2.0.2 to Ubuntu Breezy ;) do you wanna my changes ?
[02:00] <Kinnison> infinity: yes?
[02:00] <infinity> Kinnison: gins eats kittens.  God unimpressed.
[02:00] <infinity> s/gins/gina/
[02:01] <Kinnison> gina has had nothing to do with ubuntu in months
[02:01] <infinity> Kinnison: Source packages that general arch:all and arch:any binaries that were out of date when gina ran appear to be "successfully built" in soyuz.
[02:01] <doko_> mantas_: did you rename the packages back using the *2 suffix?
[02:01] <infinity> s/general/generate/
[02:01] <infinity> Kinnison: Yes, this is from ages ago.  Never caught until now.
[02:01] <infinity> Kinnison: https://launchpad.net/+builds/+build/125937
[02:02] <infinity> Kinnison: Those are all "arch:all" packages listed there...
[02:02] <infinity> Kinnison: So, why is that "successful" on amd64?
[02:02] <Kinnison> infinity: urgh
[02:03] <Kinnison> infinity: at this point, a -2 with the changelog "Gina eats kittens, God unimpressed" may be necessary
[02:03] <infinity> Kinnison: That does seem likely, yes.  I'm just wondering how many other kittens may have been lost.  Oh well.
[02:04] <infinity> Anyhow, a new uplod will make the current state more obvious, but of course won't fix the fact that ruby1.9 is FTBFS on amd64. :)
[02:04] <infinity> lucas: Either way, you're screwed. :)
[02:04] <mantas_> doko_, no, just patched debian/rules, debian/control and some other files to get working with gcc/gcj 4.0 and older version of some libraries
[02:04] <Kamion> infinity: this should show up in a quinn-diff run, shouldn't it?
[02:04] <infinity> lucas: But if you could do a no-change upload of ruby1.9, so launchpad starts reporting on it correctly, that would be nice.
[02:04] <infinity> Kamion: Yeah, it should.  I haven't yet done one for universe.
[02:05] <lucas> infinity: wouldn't just re-triggering a build be enough ?
[02:05] <infinity> lucas: Due to some LP hilarity, you can't retrigger a build if it thinks the package has already been successfully built.
[02:05] <lucas> oh ok
[02:05] <lucas> I'll first see if the ftbfs is not fixed in debian
[02:06] <infinity> Kamion: I got so far as copying a quinn-diff binary to ~adconrad on drescher, then found something shinier to play with, I think. :)
[02:06] <infinity> lucas: It doesn't look fixed.  Debian's amd64 packages are lagging.
[02:06] <Mithrandir> infinity: aka "food"? :-P
[02:06] <infinity> No, food is about to happen now.
[02:06] <mantas_> neuralis, Treenaks: so, what about PPP/PPPoE configuration in Dapper ? Should I report a bug agains network admin or there are some other tools in Ubuntu main for PPP/PPPoE configuration ?
[02:06] <infinity> Finally.
[02:07] <lucas> infinity: there was a similar problem with ruby1.8 I think
[02:07] <Mithrandir> yeah, ruby in debian is 1.9.0+20050623-2 for the amd64 build.
[02:08] <infinity> mantas_: The recommended way to configure PPPoE is (currently) the "pppoeconf" tool from the command line.  Works well.
[02:08] <doko_> mantas_: yes, please email, started the backport as well, but it's low priority for me
[02:12] <mantas_> infinity, there are no way to call pppoe configuration tool without typing pppoeconf command in terminal ? I think this is big usability bug
[02:12] <ogra> i think there are seveal open bugs about it since warty
[02:12] <infinity> mantas_: Yes, but we're not about to fix it now.
[02:13] <infinity> mantas_: If you'd like to hack on NetworkManager to support PPP and PPPoE in a Debian context, we'll happily take patches for dapper+1
[02:13] <Mithrandir> pitti: any chance you could test ppc live?
[02:14] <pitti> Mithrandir: sure, I will; as soon as my amd64 install finished (sorry, it hang at the X resolution question while I was at lunch)
[02:14] <pitti> Mithrandir: yesterday's was good, any particular changes I should watch out for? or just general test?
[02:15] <Mithrandir> pitti: espresso testing is needed too, which I don't think was ok?
[02:15] <Mithrandir> ogra: edubuntu live images done
[02:15] <pitti> Mithrandir: yep, will test
[02:16] <mantas_> infinity, maybe there are some plans/specifications about this ? What are future Ubuntu plans about PPP/PPPoE configuration in Dapper +1 ? Maybe I could help :)
[02:16] <Mithrandir> Kamion: we don't do edubuntu/kubuntu ports too, do we?
[02:16] <ogra> Mithrandir, thanks ... i'm not sure if i want them for a flight on this state though
[02:16] <Kamion> Mithrandir: no
[02:16] <ogra> s/on/in/
[02:16] <Mithrandir> Kamion: so just bin/cron.ports_daily{,-live} with no for-project or anything?
[02:16] <Kamion> pitti: if you didn't see, your espresso bugs appeared to be due to libparted not liking one of your partitions
[02:16] <Mithrandir> ogra: that's your call.
[02:16] <Kamion> Mithrandir: 'for-project ubuntu' is a no-op, otherwise yes
[02:17] <Mithrandir> ogra: I would advise you to take them and document the login problem in the errata, but again, your call
[02:17] <pitti> Kamion: no, I didn't read my bug mail yet today; nice that it's fixed now (and funny that it affected both of my boxes and nobody else's)
[02:17] <ogra> Mithrandir, yes, i'm still pondering that
[02:17] <Mithrandir> ogra: you can still get useful testing out of it.
[02:18] <ogra> given that the new NM doesnt work on *any* card over here...
[02:18] <ogra> so no networking and no autologin ...
[02:18] <pitti> ogra: NM-> not even for wired?
[02:18] <ogra> pitti, didnt try with wired
[02:18] <ogra> will do in this test run
[02:19] <pitti> ogra: it works well here with both the AE (modulo the initial dhcp timeout) and with ethernet
[02:19] <ogra> pitti, the current 0.6.X ?
[02:19] <infinity> ogra: When did you last test it?
[02:20] <ogra> infinity, wednesday afternoon
[02:20] <infinity> ogra: You may have been suffering from "no wpasupplicant available" issues, if it was an old livefs.
[02:20] <pitti> ogra: I think I tested it with 0.6, too, will do again to check it
[02:20] <infinity> ogra: Your new livefs should have wpasupplicant installed, so it should work.
[02:20] <ogra> infinity, i think it had thw wpasupplicant already
[02:21] <ogra> it was the second build on wednesday that was specifically waiting for wpasupplicantr
[02:21] <ogra> -r
[02:21] <ogra> so that should have been there ...
[02:23] <mantas_> btw, it seems Ubuntu dapper has outdated network-manager version, bugfix version 0.6.2 was released some time ago, in lauchpad there are bug about this in network-manager section
[02:24] <Kamion> pitti: it's not fixed
[02:24] <infinity> mantas_: We know.
[02:24] <Kamion> merely diagnosed
[02:24] <mantas_> are there any plans to include network-manager 0.6.2 in Dapper or not ? I'm asking, because I don't know which version would be better to backport for Breezy
[02:25] <Kamion> mantas_: yes, it will probably be upgraded.
[02:26] <j^> mantas_ currently no version is in a state that it could/should be backported
[02:26] <ogra> backporting it will likely also require new dbus, hal etc ...
[02:26] <ogra> (or a lot of hacking)
[02:27] <ogra> hmm
[02:27] <ogra> edubuntu-daily-live-20060329.log  has a +wpasupplicant
[02:27] <ogra> edubuntu-daily-live-20060329.1.log  has a -wpasupplicant
[02:27] <giftnudel> hehe
[02:27] <ogra> thats strange
[02:28] <ogra> hmm, and i see no log for edubuntu-daily-live-20060331
[02:28] <j^> ogra possible that you run into bug 37396 or bug 37419 if wireless does not work
[02:28] <Ubugtu> Malone bug 37396 in network-manager "orinoco/prism54 cannot connect to WEP networks" [Critical,Confirmed]  http://launchpad.net/bugs/37396
[02:28] <Ubugtu> Malone bug 37419 in network-manager "ndiswrapper. cannot connect to unencrypted networks" [Critical,Confirmed]  http://launchpad.net/bugs/37419
[02:29] <ogra> j^, what about the other cards then (2x broadcom 1x iwp2200)
[02:29] <ogra> i dont use ndiswrapper btw
[02:30] <ogra> i think the cd buildlog indicates that wpasupplicant was removed in 20060329.1, i just dont understand why
[02:31] <j^> ogra without wpasupplicant it will not work
[02:31] <ogra> j^, i know ... the 20060329.1 build was specifically done to *add* wpasupplicant, thats what bothers me
[02:33] <mantas_> j^, network-manager is very buggy now ?
[02:33] <thesaltydog> How can I add an override to this lintian warning: W: bum: menu-command-not-in-package /usr/share/menu/bum:4 /usr/bin/gksu
[02:33] <j^> mantas_ right now its broken
[02:33] <mantas_> ogra, network manager 0.6.x will not work with breezy dbus and hal ?
[02:33] <ogra> hmm, network-manager depends on wpasupplicant now it seems ...
[02:34] <ogra> why was it removed from that build ... strange strange
[02:34] <giftnudel> ah, when I scroll in firefox and someone says something in this channel, it will get focus
[02:34] <ogra> mantas_, no idea, but its very likely that you need a newer version
[02:34] <j^> is madwifi or madwifi-ng in dapper?
[02:36] <mantas_> j^, very broken ? which bugs ?
[02:38] <j^> mantas_ https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
[02:40] <mantas_> j^, thanks, yesterday I looked there, but didn't noticed critical bug ;)
[02:43] <pitti> Mithrandir: amd64 install works fine here, I tested some desktop stuff, too
[02:43] <Mithrandir> pitti: nice, thanks.
[02:48] <Kamion> ogra: it's weird, but I'd ignore it if I were you, tasks aren't really relevant for live builds any more
[02:49] <Kamion> thesaltydog: there's documentation on lintian overrides in the manual in /usr/share/doc/lintian/
[02:49] <Kamion> section 2.4
[02:49] <thesaltydog> Kamion, yes, tnx. While waiting for a reply, I found it!
[02:50] <Kamion> thesaltydog: but I wouldn't override that warning
[02:50] <thesaltydog> Kamion, ??? it is complaining for gksu...
[02:50] <Kamion> thesaltydog: I think it's probably a lintian bug, since gksu's used all over the place; it should recognise gksu and check (a) for a dependency and (b) that the thing after gksu is in your package
[02:50] <Kamion> thesaltydog: so please don't override it
[02:51] <thesaltydog> Kamion, ok. I won't override it. gksu is in package's dependecies...
[02:51] <Kamion> sure, but lintian should still check for that
[02:51] <Kamion> I'll file a bug
[02:51] <thesaltydog> Kamion, I could post a bug on lintian...
[02:51] <Kamion> I'll do it, I'm one of the lintian developers (although kinda retired)
[02:52] <thesaltydog> Kamion, ok. Thank you very much!
[02:52] <sabdfl> phwoar. just used the volume buttons on my thinkpad. and got on-screen display. phwoar.
[02:52] <sabdfl> mjg59: ^^^
[02:52] <sabdfl> :-D
[02:52] <thesaltydog> sabdfl, very nice the new hotkeys-setup..
[02:52] <thesaltydog> sabdfl, I finally ended my troubles with tpb on my ThinkPad
[02:54] <Kamion> bug filed
[02:54] <thesaltydog> Kamion, great.
[02:56] <thesaltydog> Kamion, by the way... the thing after gksu is bum, the package itself.
[02:59] <seb128> GNOME stuff didn't change recently
[02:59] <seb128> so go blame something else :p
[03:00] <torkel> mvo: I miss tpb too...
[03:01] <Kamion> thesaltydog: right, as I'd expect
[03:01] <Kamion> thesaltydog: so lintian should check to make sure that the command you give after gksu is in the package it's checking
[03:01] <thesaltydog> right
[03:02] <torkel> mvo: especially that I can't change the hw volume of my T40p without changing the "alsa" volume
[03:03] <Mithrandir> yay, amd64 espresso and live works.
[03:04] <Mithrandir> pitti: you're testing ppc espresso?
[03:05] <pitti> Mithrandir: rsync is at 83%
[03:05] <Mithrandir> pitti: 'k
[03:05] <pitti> Mithrandir: but since that libgparted bug is not yet fixed, I doubt that espresso will work
[03:07] <Kamion> libparted
[03:08] <Kamion> and it's at least possible that it's a bug in your partitions :-)
[03:09] <mvo> seb128: I blame hotkey-setup
[03:10] <pitti> Kamion: hm, I don't even have any ext2 partition (on neither computer)
[03:10] <pitti> Kamion: I have reiserfs and xfs, and hfsplus on the Apple
[03:11] <pitti> Kamion: I think I created an ext3 partition for the to-be-installed system (since that happens to be the default and I can't change it anyway)
[03:11] <pitti> so this is still strange...
[03:17] <Kamion> pitti: odd, yes
[03:18] <Kamion> I haven't had time to really dig yet :(
[03:18] <pitti> Kamion: no problem; if I knew a way to work around that, I'd happily take it
[03:19] <pitti> Kamion: so the reason for the early exit is that partman exits with 10 instead of 0?
[03:19] <pitti> Kamion: since I didn't see any exception or so
[03:19] <mantas_> Kamion, ~3 monts ago you added ttf-dejavu font to ubuntu-desktop metapackage, but it seems forgot to remove ttf-bitstream-vera (ttf-dejavu are the same bitstream-vera fonts, just extended with more unicode characters, look at http://dejavu.sf.net ). Should I report a bug about this ?
[03:21] <jdub> mantas_: the inclusion of vera is intentional
[03:21] <Kamion> mantas_: I just did an auto-refresh, I did not particularly care about why ttf-dejavu was added and have no idea about anything related to your question
[03:22] <mantas_> Kamion ;)
[03:22] <Kamion> if you want to know who added it, look at bzr log of the seeds
[03:22] <Kamion> which was in fact me, but teleoperated by jdub
[03:23] <Kamion> ('cos he hadn't got a seed commit setup)
[03:23] <mantas_> Kamion, it's not important who added ttf-dejavu, it's important do not have duplicate fonts in ubuntu-desktop ;)
[03:23] <Kamion> it's not important to me :)
[03:23] <jdub> mantas_: it's important to have the vera font name available
[03:23] <Treenaks> Kamion: duplicate = double disk space ;)
[03:23] <jdub> mantas_: and the metrics to go with it
[03:24] <mantas_> jdub, ttf-dejavu fonts could provide ttf-bitstream-vera
[03:24] <jdub> mantas_: they have different names and metrics
[03:25] <Mithrandir> ok, i386 live and espresso seems to work for me
[03:25] <Riddell> Mithrandir: did you remake the kubuntu livefs?
[03:26] <mantas_> jdub, we can make some aliases and gnome will see vera fonts after ttf-dejavu are installed ;)
[03:26] <Mithrandir> Riddell: yes, but it broke since doko uploaded some ooo stuff yesterday, so the AMD64 livefs is broken.
[03:26] <Mithrandir> Riddell: I need to check out if the new ia32-libs-kde is through yet
[03:26] <jdub> mantas_: a) the fonts are different, whether you alias the name or not, b) the metrics are different
[03:27] <jdub> mantas_: you can't just swap fonts around, call them different names, and hope for the best
[03:27] <mantas_> jdub, about metrics - I don't know why ttf-dejavu metrics should be different from ttf-bistream-vera, because ttf-dejavu are made from ttf-bistream-vera
[03:28] <jdub> mantas_: well, they are
[03:29] <mantas_> jdub, in any case users now have usability problems, because identifically looking fonts have different names and ttf-bistream-vera fonts has too little characters to use them in Europe
[03:29] <jdub> mantas_: that's precisely why we're using dejavu as the primary selection for all of the generic aliases
[03:30] <Riddell> Mithrandir: looks like ia32-libs-kde-5 is in the archive
[03:30] <mantas_> jdub, so, ttf-dejavu is primary font for Ubuntu Dapper and ttf-bitstream-vera are deprecated, right ?
[03:30] <jdub> mantas_: i wouldn't describe it as deprecated, but it is included.
[03:31] <mantas_> ;)
[03:32] <Kamion> jdub: (see doko's mail today about dejavu problems)
[03:32] <jdub> Kamion: u-d?
[03:32] <mantas_> jdub, I understand, that vera fonts are included now, but I think, that this is an usability problem when there are 2 identifically looking (from users view) fonts in the system as default
[03:32] <Mithrandir> Riddell: indeed.
[03:33] <Kamion> jdub: think so, just skim-read it
[03:33] <Mithrandir> Riddell: I'll kick off livefs builds for kubuntu, then
[03:33] <jdub> mantas_: the way fontconfig works, there are a lot of identical-looking fonts on the system by default (because the empty glyphs fall back to the generic aliases)
[03:34] <mantas_> jdub, Yes, and this is nor user-friendly, nor professional, so, I think it would be wise to report a bug about removing ttf-bitstream-vera fonts from ubuntu-desktop in future :)
[03:35] <jdub> mantas_: it happens across *all* the fonts, not just between those two
[03:35] <mantas_> jdub, you allow me to report a bug ;)
[03:35] <jdub> mantas_: it is important to keep vera there for metric-compatibility and name-compatibility
[03:35] <mantas_> jdub, who needs this metric-compatibility ?
[03:36] <Treenaks> jdub: only for the metric compatibility. names can be mapped.
[03:36] <Treenaks> mantas_: People who write documents and expect them to be the same across machines/platforms
[03:36] <jdub> Treenaks: they impact each other
[03:37] <mantas_> Treenaks, hehe, AFAIK you are talking about msttcorefonts :-P
[03:37] <pitti> yay sound on ppc live
[03:38] <Mithrandir> pitti: nice.
[03:38] <jdub> mantas_: this is important for *every* font a user chooses. most of my presentations would have to be double-checked if the metrics of 'Bistream Vera Sans Bold' changed behind my back.
[03:38] <Mithrandir> I was wondering for a second why that suddenly worked until I realised I uploaded a fix for it a few days ago.
[03:39] <pitti> Mithrandir: yep, that manual snd-powermac module loading
[03:39] <Mithrandir> pitti: yeah, I'm just very, very tired now.
[03:39] <mantas_> jdub, so, you think ttf-bitsteam-vera fonts should remain in Ubuntu for ages ?
[03:39] <jdub> mantas_: yes
[03:40] <mantas_> Even when majority will use other fonts ?
[03:40] <jdub> yes
[03:41] <mantas_> ok, I understand your point of view ;)
[03:44] <Mithrandir> pitti: ok, no I'm just waiting for ppc to be confirmed working before doing the release and mailing u-a
[03:45] <Mithrandir> maswan: around?
[03:46] <Mithrandir> Riddell: have you had a chance to do installation testing of flight-6 yet?  I suspect it's broken due to the ia32-libs-kde stuff
[03:47] <maswan> Mithrandir: yes
[03:47] <Mithrandir> maswan: ravel seems to be unhappy.
[03:47] <Mithrandir> as in, ssh times out
[03:47] <Mithrandir> ogra: are you happy with the current edubuntu images?
[03:47] <maswan> indeed.
[03:48] <maswan> I'll go down and poke it, I guess
[03:48] <Mithrandir> thanks.
[03:49] <pitti> Mithrandir: ppc/live boot, OO.o, FFox, USB hotplug, sound, help, video, and n-m with ethernet are good
[03:49] <pitti> Mithrandir: so I'd declare this as good enough
[03:49] <Riddell> Mithrandir: both amd64 and ppc broke on package install, 386 was fine
[03:49] <Riddell> probably scratched cds at fault on the ppc at least
[03:50] <Mithrandir> pitti: excellent.
[03:50] <pitti> amd64/install chokes on my second ethernet
[03:50] <pitti> $ sudo ifup eth1
[03:50] <pitti> run-parts: /etc/network/if-pre-up.d/0_wpasupplicant exited with return code 1
[03:50] <pitti> but oh well...
[03:50] <Mithrandir> pitti: hmm.
[03:50] <Mithrandir> Riddell: ok, so you want new installation images rolled?
[03:50] <pitti> Mithrandir: it's just for my second ethernet card, actual install and apps are fine
[03:50] <Riddell> Mithrandir: yeah, please
[03:50] <siretart> pitti: I have a fix for that ready, I'm just waiting for main to reopen again
[03:50] <pitti> siretart: cool
[03:51] <Mithrandir> pitti: ok, I'll just let that pass, then
[03:51] <siretart> pitti: I just have that package uploaded to unstable. it just needs to be synced
[03:52] <pitti> Mithrandir: it still hangs after ejecting the CD (pressing enter helps, as usual), but that's no showstopper, I'd say
[03:54] <infinity> pitti: That should be fixed next week, I suspect.
[03:55] <fabbione> Mithrandir, infinity: any objection if i upload wacom-tools? it's not on CD atm, and i will wait after F6 to create the proper X depends:
[03:55] <infinity> fabbione: Go nuts.
[03:56] <fabbione> i need it to fix a couple of regressions from breezy
[03:56] <fabbione> infinity: cheers mate...
[03:56] <infinity> fabbione: If it turns out it IS on a CD, I'll let Mithrandir deal with you. :)
[03:57] <sladen> Kamion: I don't have Mactel to test it with, is creating an iso and seeing if it will mount as HFS+ in Linux a good enough way to test it
[03:57] <fabbione> infinity: it's not :)
[03:57] <Kamion> sladen: yes
[03:58] <Kamion> sladen: has to not mount as HFS though
[03:58] <Mithrandir> ogra: prod?
[03:58] <sladen> Kamion: funky.  Any idea how mactel-linux built their images?  Or do they just have a raw HFS+ filesystem written to a CD?
[03:59] <Kamion> sladen: they used OS X to help
[03:59] <ogra> Mithrandir, only did i386 install so far, seems fine
[03:59] <Kamion> and yeah, raw HFS+
[03:59] <Mithrandir> ogra: ok, do you want me to wait for you?
[03:59] <Kamion> sladen: to my knowledge (I looked last week) there is no GNU/Linux code capable of writing to HFS+ usefully
[03:59] <Kamion> sladen: except for the kernel, which of course requires root access
[04:00] <ogra> Mithrandir, it will still take 1-2h i guess
[04:00] <Mithrandir> ogra: that wasn't my question. :-P
[04:00] <Kamion> sladen: the stuff in the hfsplus package can't do formatting or anything much in the way of writing except for removing files
[04:00] <Kamion> sladen: mkisofs is where we really need it, so it's probably easiest to do it there
[04:00] <ogra> Mithrandir, yes please, if it doesnt cause trouble
[04:01] <Mithrandir> Kamion: do you have any known bugs about espresso you want to get into the announcement?
[04:01] <sladen> Mithrandir: when are you actually building the images?
[04:01] <Mithrandir> sladen: they are already built.  Unless something really nasty pops up.
[04:01] <sladen> Mithrandir: I have a small fix for LenovoPads that I'd like on them
[04:01] <Kamion> sladen: also, we need a "bless boot file" option; I tried http://people.ubuntu.com/~cjwatson/tmp/31_hfs_bless_file.dpatch, but turns out that doesn't really work properly with HFS
[04:01] <sladen> Mithrandir: okay, no problem
[04:02] <Kamion> it would look somewhat different on HFS+
[04:02] <Mithrandir> sladen: flights are snapshots, not releases.
[04:02] <Kamion> Mithrandir: might be worth noting that the manual partitioner still assumes ext3 (will be fixed in Flight 7)
[04:02] <sladen> Kamion: blessing is an EFI thing rather than a HFS+ thing?  Since the boot file now points at a file, rather than a folder (IIRC)
[04:02] <Mithrandir> sladen: so while I appreciate the "I'd really like to get this in", if it wasn't there on Wednesday morning, you were too late.
[04:02] <Kamion> sladen: right
[04:03] <Mithrandir> Kamion: ok
[04:03] <Kamion> sladen: well, sort of
[04:03] <Kamion> sladen: it *is* an HFS+ thing
[04:03] <Kamion> HFS only really supported blessing a system folder; HFS+ allows blessing a boot file as well
[04:03] <Kamion> EFI's the first Apple thing to interpret that though
[04:03] <sladen> Mithrandir: nah, it's not an issue, the X stuff should work out of the box now which is a much bigger issue for people testing them for resale.
[04:04] <Mithrandir> Kamion: are you aware that when pressing "reboot" after espresso doesn't cause splashdown, etc to happen?
[04:04] <dholbach> ogra: did you plan to do a gcompris upload anywhere in the not-too-distant future?
[04:04] <dholbach> ogra: pitti complains that it doesn't have a .pot-file :-)
[04:05] <Kamion> Mithrandir: yes
[04:05] <ogra> oh ?
[04:05] <Kamion> it's on the to-do list :)
[04:05] <Mithrandir> Kamion: ok. :-)
[04:05] <ogra> dholbach, i didnt plan changes to gcompris ...
[04:06] <dholbach> ogra: it's usually just running   cd po/; intltool-update -p   in debian/rules somewhere
[04:06] <ogra> dholbach, pitti i'm not sure there is a pot file, the ranslations are in separate packages
[04:07] <pitti> ogra: oh, in which? I just see -sound-lang files
[04:07] <ogra> yes, they also have text translations ...
[04:08] <pitti> ogra: oh, I see; but the source package builds/has .mo files, so there are certainly po files around?
[04:09] <pitti> ogra: yep, lots of them
[04:09] <dholbach> gcompris-sound-de doesnht have translations
[04:09] <pitti> ogra: so it should be reasonable to build a pot
[04:09] <pitti> dholbach: pkgstriptranslations
[04:09] <dholbach> arg.... bitten by the old assumption again :-)
[04:10] <Mithrandir> Riddell: new dailies up
[04:11] <stewart> can anyone tell me where dapper picks up its list of available modes for the system > preferences > screen resolution app?
[04:11] <Mithrandir> stewart: from the X configuration
[04:12] <stewart> as in /etc/X11/xorg.conf? odd as I have modes available not listed in my conf
[04:12] <Mithrandir> stewart: sure the colour depth matches?
[04:12] <stewart> and it ignores the 1900x1080 hdtv mode I just added
[04:12] <stewart> yep
[04:12] <Mithrandir> check the log and see if it got removed for some reason or another?
[04:13] <infinity> Mithrandir: Actually, I don't think it does come from the "X config", per se, but rather from X's detected valid resolutions.
[04:13] <infinity> Mithrandir: Since my RandR applet has WAY more resolutions listed than my xorg.conf has.
[04:13] <Mithrandir> infinity: probably, yes.
[04:13] <stewart> so how would you add new modes?
[04:14] <infinity> stewart: A mode that X considers invalid shouldn't show in there.  So you should see in you X log that X has decided your custom mode was no good for one reason or another (not enough video RAM to render it, broken video firmware, who knows)
[04:14] <stewart> colour depth is not available to be set through gnome, its set to 24 by default via my xorg.conf I assume
[04:15] <sladen> stewart: also, the video BIOS may not know how to setup the mode... eg. 915resolution
[04:15] <infinity> stewart: If this is an Intel chipset, you may want to try installing 915resolution
[04:15] <infinity> sladen: Jinx.
[04:16] <stewart> its an nforce chipset
[04:16] <Mithrandir> infinity: I have a trivial patch to mksquashfs to print progress information, but it's a tad overzealous for now.
[04:16] <stewart> with integrated gfmx4 NV18 I believe
[04:16] <infinity> Mithrandir: One dot for every block? :)
[04:17] <Mithrandir> infinity: no, for every file.  I was actually writing out the current position
[04:17] <infinity> Heh.
[04:17] <infinity> Just make it less granular, and you win.
[04:17] <Mithrandir> yeah.
[04:17] <infinity> No one's lookin for an accurate timeline, just ANYTHING VISUAL, ARGH.
[04:17] <Mithrandir> Every megabyte or so should be fine.
[04:18] <stewart> thats annoying my log says it drop the mode (no mode of this name)
[04:18] <stewart> but my monitor and card are good for it and its the new hidef tv format
[04:21] <sladen> Mithrandir: making output each file name would make sense, much the same as  tar v
[04:21] <sladen> Mithrandir: and preferably not by default (unix utilties by default should be quiet
[04:21] <maswan> Mithrandir: fixed. it seemed to just have lost it's network devices. an ifdown -a; ifup -a later and all is great.
[04:22] <Mithrandir> Riddell: live images published too.
[04:22] <Mithrandir> maswan: excellent, thanks
[04:23] <Riddell> thanks Mithrandir
[04:25] <janimo> Mithrandir, so with flight 6 done today you think starting xubuntu install images could begin on Monday?
[04:25] <Mithrandir> janimo: ask Kamion about that, but yes, I presume so.
[04:25] <Mithrandir> or assume
[04:25] <janimo> thanks
[04:35] <mgalvin> Mithrandir: flight 6 about ready? i just wanted to know when to move the review to the main site... i didn't want to move it over there to early
[04:36] <Mithrandir> mgalvin: it's about ready, yes.    Waiting for edubuntu to report back at least.
[04:37] <Mithrandir> seb128: maybe also kubuntu, but I think those'll be released a bit later.
[04:38] <seb128> k
[04:38] <Mithrandir> seb128: if Riddell is fine with us opening the gates, we can do it once edubuntu is confirmed good.
[04:39] <dholbach> infinity: that is universe
[04:39] <Riddell> I'm still testing
[04:40] <infinity> dholbach: Oh, so it is.  I just assumed it wasn't.
[04:40] <dholbach> i thought so first too :)
[04:40] <Mithrandir> ogra: any ETA?
[04:40] <Mithrandir> Riddell: any ETA?
[04:40] <Riddell> Mithrandir: couple of hours at least
[04:41] <bddebian> Can we please get Malone to require a Distro and maybe get it to tell universe from main?  Or does it already exist and I just don't see it?
[04:41] <dholbach> bddebian: the main/universe distinction is planned
[04:41] <dholbach> and what do you mean by "require a distro"?
[04:41] <seb128> dholbach: it's already implemented
[04:42] <bddebian> Make the submitter specify dapper/breezy/etc
[04:42] <seb128> the query form has a "Component"
[04:42] <seb128> main, universe, multiverse, etc
[04:42] <dholbach> Ubuntu should be enough for "current development" release
[04:42] <dholbach> ah ok
[04:42] <bddebian> dholbach: ?
[04:42] <dholbach> bddebian: hm?
[04:43] <seb128> bddebian: bugs apply to dapper
[04:43] <bddebian> Why?
[04:43] <seb128> bddebian: if they don't apply to dapper you can use the "Backport Fix to Releases" on the right frame
[04:43] <Mithrandir> Riddell: which means we could wait for you to complete testing.  Do you want us to?
[04:43] <seb128> bddebian: because that how the tracke is designed?
[04:43] <seb128> tracker
[04:43] <bddebian> seb128: But how do I know if the user submitted it against Breezy or Dapper?
[04:44] <dholbach> bddebian: because the current development release is what we work on, so it makes sense to call that "Ubuntu"
[04:44] <dholbach> for everything else you have to ask
[04:44] <seb128> atm it should describe that with his comment
[04:44] <dholbach> if they don't specify it already
[04:44] <Kamion> it would be exceedingly useful to at least have a way for submitters to specify the version number of the package they're using in a way we can automatically parse (i.e. not free text)
[04:44] <Riddell> Mithrandir: if you're ready to go then don't wait on me, it might all fail yet and there's enough interesting things in this for a separate announcement
[04:44] <Kamion> *that* is how Malone was *originally* designed
[04:44] <Mithrandir> Riddell: I'm waiting for ogra, but ok.
[04:44] <bddebian> Kamion: Aye, even that would help
[04:45] <Kamion> bddebian: that's better than specifying a release because you can tell transient bugs in development releases
[04:45] <bddebian> True
[04:45] <herzi_x41> fabbione: ping
[04:48] <fabbione> herzi_x41: pong
[04:48] <Mithrandir> if somebody wants to proofread http://err.no/tmp/flight-6.txt , I'd be grateful
[04:48] <doko> jdub, seb128: I see that opensuse uses DejaVu for the gnome UI although they list the Nimbus fonts as preferred. Do yo know why?
[04:48] <seb128> no
[04:48] <herzi_x41> fabbione: wacom tablets won't work with the new wacom-tools package
[04:49] <herzi_x41> see my comment to one of the bugs
[04:49] <fabbione> herzi_x41: how so?
[04:49] <fabbione> what bug?
[04:49] <Keybuk> Mithrandir: reads ok
[04:49] <herzi_x41> it broken with linux-source2.5.15-16
[04:49] <herzi_x41> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/35101
[04:49] <Kamion> Mithrandir: "obiviously"
[04:49] <Ubugtu> Malone bug 35101 in linux-source-2.6.15 "Wacom support completely broken now" [Normal,Unconfirmed]
[04:49] <fabbione> herzi_x41: so that's a kernel bug
[04:49] <herzi_x41> yes
[04:49] <Mithrandir> Kamion: fixed, thanks.
[04:49] <fabbione> herzi_x41: we will get there...
[04:49] <fabbione> herzi_x41: the wacom-tools userland was missing completely the X driver
[04:49] <Kamion> Mithrandir: let's say "should now work on PowerPC" - I haven't actually had confirmation that the yaboot support works
[04:49] <fabbione> so there was nothing working
[04:50] <Mithrandir> Kamion: fixed.
[04:50] <fabbione> herzi_x41: so i see no problem..
[04:50] <Kamion> Mithrandir: "When rebooting after installing using espresso" ... you forgot to finish the sentence
[04:51] <herzi_x41> fabbione: i just wanted to tell you that there will be "no wacom support even with the new wacom-tools"
[04:51] <bddebian> yaboot hasn't been replaced yet? Ugh :-)
[04:51] <Mithrandir> Kamion: true.  Fixed.
[04:51] <fabbione> herzi_x41: if i was going to fix the kernel, somebody would have come here complaining about userland.. we need to start somewhere :)
[04:52] <schlurchz> Mithrandir: flight-6.txt: 's/Flight 5 cd/Flight 6 cd/'
[04:52] <fabbione> herzi_x41: and the pnpacpi regression is already fixed in our git tree
[04:52] <Mithrandir> schlurchz: indeed.  Fixed.
[04:52] <fabbione> herzi_x41: with kernel 2.6.15-20 it will be ok
[04:52] <herzi_x41> great news
[04:52] <Kamion> (I'd also say CD rather than cd)
[04:53] <fabbione> herzi_x41: the serial ports (generally) are just broken.. so don't worry too much
[04:53] <fabbione> well it was broken at least
[04:53] <fabbione> herzi_x41: does this make you more happy?
[04:53] <herzi_x41> yes
[04:53] <herzi_x41> so i can use the tablet in class the next semester
[04:54] <fabbione> probably from next week...
[04:54] <fabbione> :)
[04:57] <schlurchz> Uhm, the listed bugs in fligth 6 look pretty tough :-/
[04:58] <Mithrandir> well, it's a snapshot.
[04:58] <_mvo_> Kamion: where does the installer sets a global proxy configuration (does it support this)?
[04:59] <stewart> OK gnome is running like a dog
[04:59] <Keybuk> schlurchz: it's a "this is where we're at today" release, not a polished one
[04:59] <pitti> Riddell: ping
[04:59] <seb128> stewart: how does a dog run?
[04:59] <stewart> Im running the nvidia-glx from synaptic
[04:59] <stewart> haha seb in my case its a fat dog
[04:59] <schlurchz> well, I understood that the flight releases _are_, to some degree, polished. Okay, they're clearly labelled alpha.
[04:59] <siretart> Keybuk: wpasupplicant 0.4.8-1 got uploaded to sid earlier today. it is ready to be synced to dapper.
[04:59] <pitti> Riddell: http://www.cups.org/str.php?L1527 -> "The final CUPS 1.2 release includes (temporary) compatibility functions with the old names, but they will be removed in a future 1.2.x patch release."
[05:00] <stewart> on a fresh install on a decent spec machine and still its dogish
[05:00] <pitti> Riddell: so there's hope :)
[05:00] <Keybuk> siretart: were there any further changes from what we discussed yesterday?
[05:00] <Mithrandir> schlurchz: very coarse sand grinder, I suspect.
[05:00] <pitti> Riddell: assuming that we can upgrade to the final version
[05:00] <siretart> Keybuk: no. only a one line bugfix: don't remove the /etc/network/if-up.d/wpasupplicant symlink in postinst :/
[05:01] <stewart> after using synaptic to download nvidia-glx I had to update my xorg.conf from driver "nv" to "nvidia" is that still the case?
[05:01] <siretart> but no further functional/semantic/docu changes at all
[05:01] <Riddell> pitti: ooh :)
[05:02] <Riddell> pitti: any idea when that final version will be out?  or can we upgrade to an SVN version?
[05:02] <_mvo_> stewart: that sound be enough
[05:02] <Keybuk> siretart: ok, looks good; you happy to upload to dapper once the freeze is over?
[05:02] <stewart> _mvo_ dot sure what you mean?
[05:02] <schlurchz> Mithrandir: mind to put in other words? I'm not native english?
[05:02] <pitti> Riddell: RC1 is current, I need to check whether it breaks anything before I ask for UVF
[05:02] <stewart> not
[05:02] <Kamion> _mvo_: it doesn't - the proxy question's just for the benefit of the installer AFAIK
[05:02] <pitti> Riddell: no idea about the date for the final
[05:02] <siretart> Keybuk: I'm just waiting for the freeze to end. the upload is prepared and signed and waiting for green light :)
[05:02] <pitti> Riddell: should be RSN
[05:03] <Keybuk> siretart: cool, thanks
[05:03] <Mithrandir> schlurchz: not polished.  Cut into rough shapes rather than being a nice surface you can use as a mirror.
[05:03] <Kamion> _mvo_: although it does write it into apt.conf
[05:03] <Kamion> ./generators/50mirror.ubuntu:55:                        echo "Acquire::$protocol::Proxy \"$proxy\";" >> $ROOT/etc/apt/apt.conf.new
[05:03] <schlurchz> Mithrandir: ah, okay thx
[05:03] <_mvo_> Kamion: right, thanks.
[05:03] <Keybuk> siretart: which version did you use?  0.4.8-1build1 ?
[05:04] <stewart> simple question - after apt-get nvidia-glx are users still expected to update xorg.conf settings from "nv" to "nvidia"?
[05:04] <Mithrandir> stewart: yes
[05:04] <Mithrandir> stewart: or nvidia-glx enable
[05:04] <stewart> OK thnx
[05:04] <Riddell> pitti: yeah, that's what they said in december
[05:04] <pitti> :/
[05:05] <pitti> but now they have an RC, so chances are higher :)
[05:05] <Chipzz> Mithrandir: actually that nvidia-glx enable is nasty and should probably happen automagically or be a debconf question
[05:05] <stewart> any reports of the nvidia-glx running poorly (Im using an nvidia nv18 nforce2 integrated)?
[05:06] <pitti> stewart: nv34 integrated works fine here
[05:06] <Kamion> Chipzz: (debconf questions are not a panacea, and we won't add extra questions to the installer so in fact adding a debconf question would be just as much work for users)
[05:06] <siretart> Keybuk: yes, thats what I intend to upload
[05:06] <stewart> well it works nv18 but dragging a window about quickly is right jerky
[05:07] <stewart> something I didnt notice earlier with flight3
[05:09] <Chipzz> Kamion: we could also let every xserver-xorg-driver (and the nvidia package) add themselves to a debconf list of available x server drivers
[05:09] <Chipzz> and let every package do custom config itself
[05:09] <Chipzz> but whatever :)
[05:10] <Chipzz> pipedream or something ;)
[05:11] <Kamion> Chipzz: pipenightmare
[05:27] <Mithrandir> ogra: AWTY?
[05:27] <ogra> Mithrandir, ppc missing, the rest is fine (apart from NM not working with my wireless cards and the gdm prob)
[05:34] <Riddell> ppc users: is there a way to tell it to eject the CD on boot?
[05:35] <Lathiat> JaneW: FYI, i updated my testing team info
[05:36] <Lathiat> ergh
[05:37] <Lathiat> and i just broke the page
[05:37] <pitti> Riddell: press enter
[05:37] <mdz> fabbione: I didn't realize tspc was in main until I saw that bug.  perhaps we should investigate and possibly reconsider?
[05:37] <pitti> Riddell: if you mean the live CD shutdown
[05:37] <pitti> Riddell: oh, wait, it does automatically for me
[05:38] <Kamion> Riddell: many mac keyboards have an eject button; hold that down during boot
[05:39] <Kamion> Riddell: failing that, hold down cmd+opt+o+f during boot and type 'eject cd' at the OF prompt
[05:39] <fabbione> mdz: reconsider to move it to universe?
[05:39] <fabbione> mdz: i don't even recall why it was moved ot main in the first place..
[05:39] <mdz> fabbione: right
[05:40] <fabbione> mdz: i will need to check tho, but the bug is fixed
[05:40] <fabbione> linux-2.6$ time make -j
[05:40] <fabbione> real    1m35.013s
[05:40] <fabbione> not too bad, is it?
[05:41] <Lathiat> what machines that?
[05:41] <Mithrandir> Riddell: traditionally, hold down the mouse button while booting.
[05:41] <Mithrandir> Riddell: or what Colin says.
[05:41] <_mvo_> what should we do with the fade-effect of gksu? should it be removed?
[05:42] <fabbione> mdz: the point is a delicate one
[05:42] <fabbione> mdz: if we start moving the tunnel broker outside main, we need to remove them all or none
[05:42] <fabbione> mdz: iirc we have 2 or 3, because they cover 99.9% of internet
[05:42] <fabbione> mdz: and the clients are tiny
[05:45] <fabbione> anyway i don't have a strong opinion on it
[05:46] <Mithrandir> (which should probably be in main, given it's usefulness and being quite common)
[05:46] <fabbione> bbl
[05:47] <Riddell> thanks, kamion's method worked after mapping mac keys to this pc keyboard
[05:59] <infinito> does anyone know why gnomeapplet has disappeared from python2.4-gnome-extras ???
[06:00] <dholbach> infinito: pythone-gnome-extras was split up into pythone-gnome-extras and python-gnome-desktop
[06:01] <infinito> umm, packages.ubuntu.com shows bad info about files inside pkgs...
[06:01] <infinito> dholbach: thanks
[06:02] <doko> carlos, pitti: is #4452 still an issue?
[06:03] <pitti> bug 4452
[06:03] <Ubugtu> Malone bug 4452 in firefox "translation tools - request oo2po --multifile option be abstracted to moz2po" [Unknown,Unknown]  http://launchpad.net/bugs/4452
[06:03] <pitti> doko: carlos wanted to start looking into ffox po generation soon
[06:03] <carlos> right
[06:04] <infinito> dholbach: what are the exact names of the packages? i cant find them on ftp.ubuntu.com pool
[06:04] <pitti> doko: the request sounds useful, I just don't know the status of the current translation tools - carlos, do you?
[06:05] <mdke> Diziet, ping?
[06:05] <carlos> pitti: hadn't time yet to look into it
[06:05] <dholbach> infinito: python2.4-gnome2-desktop, python-gnome2-desktop-doc, python-gnome2-desktop-dev, python-gnome2-desktop
[06:05] <Kamion> mdke: he's on holiday this week
[06:05] <dholbach> infinito: apt-cache search knows :)
[06:05] <mdke> Kamion, ah thanks. I'll mail.
[06:06] <infinito> dholbach: sorry ;)
[06:37] <ogra> Mithrandir, edubuntu is fine apart from the known errors with the livecd ...
[06:50] <jcole> is this what ubuntu dapper uses for gui installation? -> http://wiki.debian.org/DebianInstaller/GUI
[06:51] <seb128> jcole: no
[06:51] <pitti> jcole: no, we have our own GUI installer which works in an entirely different way
[06:51] <jcole> hmm
[06:52] <pitti> jcole: https://wiki.ubuntu.com/UbuntuExpress
[06:52] <phanatic> hi people
[06:52] <phanatic> Kamion: ping
[06:53] <jcole> pitti: thanks
[06:54] <Kamion> phanatic: hi
[06:56] <phanatic> Kamion: i'd like to ask about the @ubuntu.com addresses. are they created automatically? i became a member on 7th march, but i don't know if i have my address or not :)
[06:56] <Kamion> phanatic: they're supposed to be, yes
[06:56] <Kamion> phanatic: try it with your launchpad id in the local-part and see :)
[06:56] <Kamion> could be it's broken though, I don't have access to that part of the system
[06:57] <phanatic> Kamion: i tried it, but didn't get the mail to my registered mail address (or there's a huge delay)
[06:57] <phanatic> Kamion: then sorry, i was told, that maybe you can help with this
[07:00] <jcole> we use the debian installer to net-install various distros (nicluding ubuntu) and i wanted to attempt a gui makeover... looks like http://wiki.debian.org/DebianInstaller/GUI is my easiest option
[07:00] <jcole> hey TomB_ !
[07:01] <ogra> phanatic, did you try #launchpad ?
[07:01] <siretart> jcole: I cannot image a net-install use case which would require a gui. could you please give me an example one?
[07:02] <ogra> thats the proper channel for this question rather
[07:02] <phanatic> ogra: not yet, but i'll do it :)
[07:02] <ogra> :)
[07:02] <jcole> siretart: partitioning?
[07:04] <jcole> siretart: we use this to create our images -> http://linuxcoe.sourceforge.net/
[07:04] <Pygi> ogra is alive ;) joy :-P
[07:04] <gouchi> Hi
[07:04] <gouchi> sorry to bother you
[07:04] <gouchi> just to report some news
[07:05] <gouchi> Ulteo will use Kubuntu for making test
[07:05] <Riddell> gouchi: what's Ulteo?
[07:05] <gouchi> according to GD : http://ulteo.org/forum/viewtopic.php?id=23
[07:05] <Kamion> phanatic: sorry, you were directed to the wrong person; elmo would be a better bed
[07:05] <Kamion> er, bet
[07:05] <gouchi> Riddell : www.ulteo.com
[07:05] <phanatic> Kamion: thanks :)
[07:05] <gouchi> I think maybe some of you, maybe will be interested in the project
[07:06] <phanatic> elmo: are you here? :)
[07:06] <gouchi> GD asks for some help, advice
[07:06] <Riddell> aah, gduval's new crack.  excellent
[07:06] <Riddell> gouchi: sure, I'm happy to advise however I can, find me in #kubuntu-devel for development chat
[07:07] <gouchi> Ridell : yep that's it and I think there is an #ulteo and GD approved
[07:16] <Kamion> pitti: for bug 8048, what do you think about using the owner option in fstab, and setting the ownership of the device nodes with udev rules or something?
[07:16] <Ubugtu> Malone bug 8048 in partman "Mounted vfat partition is not writeable for non-root users" [Normal,Confirmed]  http://launchpad.net/bugs/8048
[07:16] <Kamion> somebody in the bug log said that Fedora does that, although they seemed confused about its meaning
[07:17] <trappist> Kamion: tjere
[07:17] <pitti> Kamion: hm, but whom to assign it to?
[07:17] <Kamion> pitti: or, actually, the group option, and make the device node group plugdev
[07:17] <trappist> oops... there's a similar bug for ntfs where it's suggested we mount as the plugdev
[07:17] <pitti> Kamion: just assume uid=1000? that sounds hackish
[07:17] <Kamion> pitti: group option
[07:18] <Kamion>               group  Allow an ordinary (i.e., non-root) user to  mount
[07:18] <Kamion>                      the  file system if one of his groups matches the
[07:18] <Kamion>                      group of the device.   This  option  implies  the
[07:18] <Kamion>                      options  nosuid  and  nodev (unless overridden by
[07:18] <Kamion>                      subsequent  options,  as  in  the   option   line
[07:18] <pitti> Kamion: right, that's why I proposed in the third-last comment
[07:18] <Kamion>                      group,dev,suid).
[07:18] <Kamion> pitti: oh, will pmount let you mount a device if you share its group?
[07:18] <pitti> Kamion: I'd be fine with umask=077,group=<plugdev gid>
[07:18] <Kamion> no, you're confusing options
[07:18] <Kamion> you're thinking of gid=
[07:18] <Kamion> group= is the mount option above
[07:19] <Kamion> not group= actually, just group, it's a flag
[07:19] <Kamion> gid= sets the group ownership of the files once mounted
[07:19] <pitti> ah, that one, right
[07:19] <Riddell> Mithrandir: kubuntu amd64 install had a corrupt apt package, presumably a bad CD burn but I'll need another 90 minutes to download again and check
[07:19] <pitti> Kamion: yes, once the partition is in fstab, pmount will use mount
[07:19] <Riddell> all others fine
[07:19] <pitti> Kamion: so that'll work
[07:19] <Kamion> hmm, I guess that might not set uid= and gid= though
[07:20] <pitti> Kamion: that's why you need gid=<plugdev gid>
[07:20] <trappist> should this and bug 25071 duplicate each other?
[07:20] <Ubugtu> Malone bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [Major,Unconfirmed]  http://launchpad.net/bugs/25071
[07:20] <pitti> Kamion: so that group will allow plugdev users to mount it
[07:20] <pitti> Kamion: argh, bs
[07:20] <Kamion> oh, plugdev is a static group, that helps
[07:20] <pitti> Kamion: I mean, udev needs to put them into plugdev
[07:20] <Kamion> (I thought I was going to have a problem with getting the gid at that stage in the installer
[07:20] <pitti> Kamion: not sure how to achieve that, though
[07:20] <Kamion> )
[07:21] <Kamion> trappist: I'm deliberately keeping the vfat bug and the ntfs bug separate, although chances are I'll fix them both at the same time
[07:21] <pitti> Kamion: TBH, I think that the user option might be easier
[07:21] <Kamion> Keybuk: any ideas?
[07:21] <pitti> Kamion: or, don't do user/group at all, and just set it to 'auto'
[07:21] <pitti> Kamion: or do you prefer to dynamically mount those partitions instead?
[07:22] <pitti> Kamion: so far the partitioner set up an fstab in a way that they are just moutned at boot
[07:22] <Kamion> pitti: auto still means the can of worms of which uid to assign them to
[07:22] <pitti> which is fine for me
[07:22] <pitti> Kamion: root/plugdev
[07:22] <Kamion> oh, hmm, and umask=007?
[07:22] <pitti> yep
[07:22] <jcole> don't get enough sun working indoors all day? here's your solution! http://www.thinkgeek.com/stuff/41/usbtanner.shtml
[07:22] <Kamion> ok, good point, that works
[07:23] <pitti> Kamion: back in 5 minutes, door bell
[07:27] <doko> seb128: does gnome-panel have an option to show hidden menu files?
[07:27] <seb128> doko: no
[07:27] <dholbach> doko: you can enable them with alacarte or by editing the menus, but that's it
[07:27] <seb128> "menu files", you mean "menu items", no?
[07:28] <Amaranth> items with Hidden=true can't be shown with alacarte
[07:28] <Amaranth> NoDisplay=true is a different story
[07:31] <seb128> doko: how do you flush your clipboard selection?
[07:31] <doko> yes, I think we should have a policy to add Hidden=true instead of remving the desktop file
[07:31] <doko> seb128: by closing OOo :-)
[07:32] <seb128> - gedit has the Paste menu entry enabled
[07:32] <seb128> that's not true
[07:32] <seb128> oh, you use the top menu, not the context one
[07:32] <LaserJock> doko: do you have any idea if vnc4 is going to be able to be fixed for Dapper?
[07:33] <j^> how comes pam is so outdated and highly patched?
[07:33] <ogra> seb128, did you note that i said edubuntu is ready for flight-6 ? since only kubuntu is missing now, i think gnome uploads should be fine again ...
[07:33] <seb128> doko: you are not bored enough that you file details like that? :)
[07:33] <ogra> (you asked for uploads before)
[07:33] <seb128> ogra: right, I didn't notice, thank you
[07:34] <KaiL> libpythonize0 depends on python2.4-dev? Bug or feature? ;)
[07:34] <doko> seb128: just checking the OOo copy&paste thing ...
[07:35] <seb128> doko: yeah, and the not coherent is not limited to gedit and g-t, evo behaves differently too
[07:35] <seb128> dunno which one is right
[07:35] <seb128> so dunno what half of the apps to bug
[07:38] <Kamion> Riddell: since ogra mentioned it ... how goes the Kubuntu testing?
[07:39] <doko> seb128: dunno as well, just noticed
[07:41] <Riddell> Kamion: I had a problem on the amd64 CD, apt .deb was corrupt, probably a bad CD burn but it'll take another  couple of hours to download and check
[07:41] <Riddell> otherwise all fine
[07:42] <Kamion> Mithrandir: ^--
[07:42] <Kamion> Riddell: mm, right, corrupt .debs usually are
[07:45] <Mithrandir> Riddell: thanks.
[07:45] <Kamion> Mithrandir: worth just going for it?
[07:45] <Mithrandir> Riddell: can't you rsync -c ?
[07:46] <Fjodor> Please excuse if this is the wrong channel, but it seems the libstdc++5-3.3 is having trouble getting malloc declared:
[07:46] <Fjodor> /usr/include/c++/3.3/cstdlib:103: error: `malloc' not declared
[07:46] <Riddell> Mithrandir: alas the ISOs were on the amd64 which now has a broken install
[07:47] <Mithrandir> Riddell: hmm..  We could just wait if you prefer that.  I'm fairly sure it's not a problem, but your call.
[07:48] <Riddell> Mithrandir: if you don't mind waiting a couple of hours that would be good
[07:49] <Mithrandir> Riddell: sure, that's doable.
[07:50] <Riddell> I'll try and rescue the ISO using a live CD
[07:50] <dholbach> Mithrandir: was the assumption right, that gnome uploads should be ok now?
[07:51] <Mithrandir> dholbach: no, please not yet.
[07:51] <dholbach> ok
[07:51] <dholbach> thanks
[07:52] <Mithrandir> dholbach: not until http://cdimage.ubuntu.com/releases/dapper/flight-6 200 and not 404
[07:52] <Kamion> Riddell: is that both install and live images, or is the amd64 live CD OK?
[07:52] <dholbach> hehe
[07:52] <ogra> Mithrandir, but the gnome distros are both gold ...
[07:52] <ogra> Mithrandir, i think you couild allow it for gnome only stuff :)
[07:53] <Mithrandir> ogra: true, but I prefer to be conservative.
[07:53] <ogra> heh
[07:53] <ogra> ok
[07:53] <Riddell> Kamion: live is fine
[07:53] <Kamion> pitti: hmm, how come hda1 isn't showing up on my desktop or in Places?
[07:54] <Kamion> oh, it's not mounted
[07:54] <Kamion> pitti: think I should make it automount (pass 1 in fstab)?
[07:56] <Keybuk> Kamion: sorry, phased out there :)  ideas about?
[07:57] <Kamion> Keybuk: it's OK, superseded :)
[07:58] <Kamion> Keybuk: was thinking of making some hard disk device nodes be group plugdev (but not writable by that group)
[07:58] <Kamion> but I think we'll go with a different solution
[07:58] <Keybuk> any particular reason?
[07:58] <Kamion> vfat and ntfs
[07:59] <Riddell> Kamion: would you be able to get knetworkmanager past NEW so we could include it in the flight announcement?
[07:59] <Kamion> so that people can mount their Windows filesystems
[07:59] <Keybuk> why would you need to read directly from the device node for those?
[07:59] <pitti> Kamion: we agreed to only show volumes in /media
[07:59] <Kamion> Keybuk: sorry, I should have said not readable by that group. I had been thinking of using the 'group' mount option
[07:59] <Keybuk> it'd somewhat default the object of people who try to make their home directories not read-only though :)
[07:59] <Kamion> pitti: it is in /media
[07:59] <Keybuk> ohh
[07:59] <pitti> Kamion: and then it must have been mounted before gnome start
[08:00] <Keybuk> group mount option is a metric light year away from changing the group of the device nodes, which is what you were sounding like implying ;)
[08:00] <pitti> Kamion: that's sort of a gnome-vfs bug
[08:01] <Kamion> Keybuk: group mount option requires changing the group of the device nodes in order to be useful
[08:01] <pitti> Kamion: I think 'auto' is fine
[08:01] <Kamion> Keybuk: it's the option that says "allow the user to mount this device if they're a member of the owning group"
[08:01] <Kamion> I don't think it requires read access to the device node
[08:02] <Kamion> pitti: restarted GNOME, still doesn't appear
[08:02] <Keybuk> Kamion: so you'd make the devices 0600 root/plugdev ?
[08:03] <Kamion> Keybuk: that was my original thought before pitti suggested an alternative, yes
[08:03] <Keybuk> *nods*
[08:04] <Keybuk> it's not necessarily evil, though I don't know whether anything truly cares about the "disk" group -- might break those things
[08:04] <pitti> Kamion: hmm, odd, can you please file a bug with the lshal output?
[08:04] <pitti> I think dynamically setting the device node group according to fstab parsion is pretty evil
[08:05] <Kamion> pitti: it appears after reboot, FWIW
[08:05] <KaiL> Riddell, displayconfig (from kde-guidance) is far away from being usable, or?
[08:05] <Riddell> KaiL: sound be fairly usable
[08:06] <KaiL> how many bug reports do you want? 20? 40? 100? ;)
[08:06] <KaiL> here it makes arround everything wrong, it could :(
[08:07] <Lure> KaiL: ping Sime in #kubuntu-devel when online
[08:08] <KaiL> ok
[08:12] <pitti> Kamion: I nead to leave soon, are there still any things to be discussed?
[08:12] <Kamion> pitti: nope, I think I can do this now
[08:13] <pitti> Kamion: cool; so after all the udev/group alternatives, we end up with the simple gid=plugdev/umask=077/auto way?
[08:14] <Kamion> pitti: umask=007, but yeah
[08:14] <pitti> erm, yes, tpyo :)
[08:14] <pitti> alright, then good night everyone!
[08:14] <Kamion> I'll sort you out with the lshal stuff in a bit
[08:15] <Kamion> or possibly Monday
[08:15] <pitti> Kamion: yep, thanks
[08:17] <KaiL> 7 bugs on intel i810
[08:17] <KaiL> let's see, how many are on the ATi radeon driver too...
[08:20] <Lure> Kamion: [19:59]  <Riddell> Kamion: would you be able to get knetworkmanager past NEW so we could include it in the flight announcement?
[08:20] <Kamion> oh, yeah, give me a second
[08:22] <Lure> Kamion: thanks
[08:23] <Kamion> Riddell: source NEWed, sorry for the delay; unfortunately I'll probably be away for a fair chunk of the evening so I can't promise quick binary NEWing
[08:23] <Kamion> but I'll try to do it at some point tonight
[08:23] <Kamion> so you can say "will be available within the next 24 hours" or something if need be
[08:29] <G0SUB> will Xen 3.0 be available off the shelf with Dapper?
[08:31] <neuralis> G0SUB: no.
[08:32] <G0SUB> neuralis: dapper+1 ?
[08:32] <neuralis> G0SUB: possibly, but i don't think i'd support it. there's significant value in waiting for upstream to merge xen into kernel proper, and providing unofficial packages until then.
[08:32] <Riddell> Kamion: thanks
[08:33] <neuralis> G0SUB: it's a security/maintenance nightmare to provide it out of the box.
[08:33] <G0SUB> neuralis: I agree ... but if Fedora can do it ....
[08:33] <neuralis> G0SUB: that's not really a strong argument.
[08:34] <G0SUB> neuralis: yes, but Xen could have been a big USP for us ... wrt Bigirons
[08:35] <neuralis> G0SUB: we all want it, but given present developer resources, we can't do it. have you looked at how invasive xen patches are? we need to support our releases for at least 18 months.
[08:35] <G0SUB> neuralis: I understand ... *sigh*
[08:37] <neuralis> G0SUB: we had nice unofficial xen packages for breezy. if you wanted to win a few beers, make us some for dapper!
[08:38] <G0SUB> neuralis: where are those?
[08:38] <G0SUB> neuralis: in Universe?
[08:40] <neuralis> G0SUB: no, they were produced by some of the COSI guys at Clarkson University. the website seems down at the moment, but is xen.cosi.clarkson.edu
[08:43] <G0SUB> oh, btw, ESR has accepted Mark's offer of joining Ubuntu Technical Board
[08:44] <G0SUB> I have no idea sabdfl invited him here ...
[08:44] <Burgwork> G0SUB, this is an april fools joke, right?
[08:44] <sladen> G0SUB: is this the latest ELER
[08:44] <G0SUB> sladen: no
[08:44] <sladen> matthew and eric will get along SO NICELY together
[08:45] <neuralis> :-D
[08:45] <G0SUB> sladen: the latest was on Monty Python
[08:45] <G0SUB> Burgwork: it was a april fools' joke ... and I was the one who was fooled
[08:45] <sladen> buuu, buuuut, it's not April 1st for another 4hours
[08:46] <ogra> sladen, in other TZs it is :)
[08:46] <G0SUB> sladen: I am in +0530
[08:47] <Burgwork> G0SUB, got a linky?
[08:47] <neuralis> G0SUB: the key to a good april fool's joke is the hint of believability. ESR joining the TB doesn't have it, in my book ;)
[08:47] <G0SUB> Burgwork: heh, no links ... somebody told me on IRC
[08:47] <sladen> neuralis: oh, it does...
[08:48] <G0SUB> neuralis: IMO, it's quite possible
[08:48] <sivang> Burgwork: me burfing at you is soon now :)
[08:48] <sladen> Ian Murdock would be even better
[08:48] <G0SUB> heh, yeah
[08:48] <neuralis> sladen: nah. esr has no contribution history to the project. and he's crazy in the coconut. :)
[08:48] <zul> heh daniel robbins would be funny..
[08:49] <sladen> lalallalalala
[08:50] <jpatrick> sladen: evening to you too
[08:50] <soumyadip> zul, Daniel Robbins ? we'd have Ubuntu from Scratch then
[08:50] <G0SUB> soumyadip: Dapper from stage 1 debs
[08:50] <sladen> sabdfl: superb timing, G0SUB was just giving us the low-down on your pending annoucement for tomorrow that ESR had been appointed to the Technical Board
[08:51] <G0SUB> sladen: we better wait for the official announcement
[08:51] <Keybuk> I thought ESR was joining the Community Council
[08:52] <G0SUB> Keybuk: possibly ... it's just a speculation
[08:59] <LaserJock> is there a policy about where a browser plugin should be linked to to get it recognized?
[09:00] <G0SUB> sivang: ``Everybody Loves Eric Raymond''
[09:00] <Keybuk> "Everybody Loves Matthew Garrett"
[09:04] <sivang> ROTFL
[09:05] <Keybuk> I've been trying to persuade jono to name Matthew's talk at LRL to be "Matthew's Angry Hour"
[09:06] <sivang> Keybuk: what's LRL ?
[09:06] <neuralis> Keybuk: dude. awesome.
[09:06] <neuralis> sivang: lug radio live.
[09:06] <Keybuk> http://www.lugradio.org/live/2006/index.php/Image:Basicposter.png
[09:07] <Keybuk> ooh, Simon Phipps
[09:08] <Keybuk> time to get those "If Sun Truly Believed In Free Software, They'd Open Source Java!" t-shirts made up
[09:08] <sivang> Keybuk: hehe
[09:08] <sivang> Keybuk: I thoguht java is an open standard no?
[09:08] <sivang> (and thus anybody can implement it and release the source)
[09:09] <Keybuk> that's still rather missing the point
[09:09] <neuralis> sivang: sun's vm is closed.
[09:10] <sivang> neuralis: who cares? we can make our own :)
[09:10] <neuralis> sivang: what keybuk said, about missing the point? that.
[09:10] <Keybuk> sivang: people have been trying for years, and are still nowhere near completion
[09:10] <jcole> why don't they open source it? do they make money from it? if so, how?
[09:11] <sivang> Keybuk: I see, maybe they're holding details from the spec that they have put into the implementaion?
[09:11] <Keybuk> jcole: because they don't Truly Believe In Free Software
[09:11] <neuralis> sivang: no. it's just enormous.
[09:12] <sivang> neuralis: I see
[09:12] <sivang> neuralis: what's the state of qjc ?
[09:12] <sivang> err, gjc
[09:12] <neuralis> sivang: gcj?
[09:13] <sivang> yes, mind my dyslexia :)
[09:13] <neuralis> sivang: classpath implements a good majority of the classes from j2se 5 and 1.4
[09:14] <neuralis> sivang: so it's decent, but it's a bloody shame people had to expend the man years of work to reinvent that whell.
[09:14] <neuralis> s/ell/eel/
[09:14] <sivang> neuralis: indeed :-(
[09:14] <sivang> just for the sake of that they should have open sourced it
[09:14] <sivang> they would probably still earn from support and integration
[09:14] <jcole> Keybuk: ya, but why are they holding back java? they open sourced suff people pay for already - openoffice, solaris, etc... why not java?
[09:17] <jcole> Keybuk: i can't figure it out... do they make money from java? is there copyrighted code in it?
[09:19] <jcole> it's like microsoft open sourcing windows and office, but not activex
[09:19] <neuralis> jcole: there's probably concern about things like the hotspot server vm optimization routines becoming open and getting studied and copied in competing platforms (.net, e.g.).
[09:19] <neuralis> jcole: anyway, it's off-topic here, so let's call it eod.
[09:19] <jcole> neuralis: heh
[09:20] <Keybuk> jcole: I have no idea why; I tend to ask Simon every chance I get and he runs away from me
[09:21] <jcole> Keybuk: :)
[09:24] <Pygi> Keybuk: I really doubt we want that kind of project integrated into Dapper :-P
[09:25] <_ion> There's plenty of time. ;-)
[09:28] <Keybuk> Pygi: wpasupplicant udeb?  Why not, would be cute
[09:28] <Keybuk> netcfg already does WEP
[09:28] <Keybuk> just a matter of detecting a WPA network, and then prompting for the key phrase, etc. and seeing /e/n/i
[09:28] <Pygi> yes, but we are still not on "ok" with wpasupplicant ;)
[09:28] <Keybuk> what's up with wpasupplicant?
[09:29] <Pygi> well, nothing actually.... but bugs, issues, thingies...
[09:29] <Keybuk> such as?
[09:29] <Keybuk> excluding anything touching NM, which isn't in the scope of what I suggested
[09:29] <Pygi> yes, yes, I know
[09:30] <Pygi> so, find someone to do it then? :-P
[09:30] <Keybuk> and I thought you were volunteering :p
[09:31] <Pygi> bah, so much work to do
[09:31] <Pygi> perhaps for dapper+1, sure  ;)
[09:31] <Keybuk> Kamion: ok, earlier conversation looks possible ... might even have it done by Monday depending what time David turns up (and I get up) tomorrow :p
[09:31] <Keybuk> though not promising anything
[09:33] <Riddell> Mithrandir: kubuntu is good to go
[09:33] <siretart> Keybuk: how about wpa initramfs integration, so that you can boot via nfs on wpa secured networks ;)
[09:33] <Pygi> siretart: bah :-P
[09:34] <Keybuk> siretart: first we'd need to put the wireless chipset firmware in the initramfs ;)
[09:34] <Keybuk> the principal problem with that though is that anything started in the initramfs needs to be killed before the main system is started
[09:34] <Keybuk> the wpa suppository started in the initramfs couldn't continue to run while the main system booted
[09:35] <siretart> Keybuk: err, this doesn't include udev, does it?
[09:35] <Keybuk> siretart: yes, it includes udev;  check /usr/share/initramfs/scripts/init-bottom/udev
[09:35] <Keybuk> uh, stick -tools in there :p
[09:35] <Pygi> Keybuk, siretart: and I assume you have people to do that? ^_^
[09:36] <siretart> interesting
[09:36] <Keybuk> the police found my dungeon and took my slaves away :'(
[09:36] <Pygi> Keybuk: joy, buy a new ones? ;)
[09:36] <Keybuk> siretart: so I guess you could say the very (AND OH SO CRACKFUL) design of WPA prevents you from remote-mounting a root filesystem across a WPA-secured network
[09:36] <siretart> Keybuk: well, I think a few seconds without connection to the server wouldn't hurt too bad.
[09:36] <Keybuk> unless you did WPA in a kernel module or something
[09:37] <Keybuk> siretart: the trouble with those few seconds, is how do you start WPA supplicant again, which is on the NFS server? :)
[09:38] <Keybuk> it's not actually that bad in reality
[09:38] <Keybuk> it doesn't matter too much if the suppository runs during boot, provided it's killed eventually
[09:38] <Keybuk> usplash runs through boot, for example
[09:38] <Keybuk> so you'd have a hand-over point where you killed the running one after starting a new one
[09:39] <siretart> yes. this sounds like it could work..
[09:39] <Keybuk> it'd be easy
[09:39] <Keybuk> just create /usr/share/initramfs-tools/scripts/nfs-premount/wpasupplicant
[09:39] <Keybuk> make it run wpasupplicant with the right options
[09:39] <Keybuk> and create /usr/share/initramfs-tools/hooks/wpasupplicant
[09:39] <Keybuk> that made sure wpasupplicant was copied over
[09:40] <siretart> I think it is more likely that someone wants to use wpa on his wired network than netbooting on wpa secured wireless..
[09:40] <siretart> yay! \o/
[09:40] <Keybuk> and also probably copied /lib/firmware, /etc/udev/rules.d/80-programs.rules, /lib/udev/firmware_helper so you can actually start the cards <g>
[09:40] <Keybuk> you can't use wpa on a wired network, no? :)
[09:40] <Keybuk> wired network cards don't tend to understand WEP
[09:41] <siretart> Keybuk: you can. you use then -D wired on wpasupplicant
[09:41] <siretart> wpa has nothing to do with WEP
[09:41] <Keybuk> I thought WPA was a "magically change the WEP keys every few seconds" thing?
[09:41] <siretart> though, the use of xsupplicant is more common for wired networks
[09:41] <siretart> Keybuk: wpa has very litte to do with wep. what you describe is sometimes called 'dynamic wep'
[09:42] <Pygi> aka 802.1x
[09:42] <siretart> which wpasupplicant supports as well
[09:42] <j^> which was added to network-manager in 0.6.2
[09:42] <siretart> xsupplicant, too, I think. but I never used that
[09:43] <siretart> Pygi: you can use 802.1x authentication without encryption as well
[09:43] <Pygi> siretart: yes, yes...
[09:46] <Keybuk> j^: I think it still does
[09:47] <Hwyvar> buh
[09:52] <Riddell> maswan: please mirror /kubuntu/releases/dapper/flight-6/
[09:56] <Mithrandir> Riddell: excellent, thanks.
[09:56] <Mithrandir> maswan: ravel:/org/tmp/*-flight-6 has the images.
[09:57] <bddebian> Bah, I should be looking at bugs again.. :-(
[10:41] <Kamion> Mithrandir: we good to unfreeze the archive, then?
[10:42] <Mithrandir> Kamion: yup
[10:43] <Kamion> rah
[10:43] <Mithrandir> Kamion: I guess few enough people will pick up the image before tomorrow morning, so I'll just hold off the announcement until it's automagically mirrored.  Unless maswan shows up
[10:45] <lamont> Mithrandir: does that mean that the torrents are up?
[10:45] <Kamion> Riddell: network-manager-kde binaries newed
[10:45] <bddebian> newed? :-)
[10:45] <Mithrandir> lamont: I'm actually doing the release stuff on little now.
[10:45] <Kamion> processed through the new queue
[10:46] <bddebian> No definitions found for "newed"
[10:46] <bddebian> ;-P
[10:46] <lamont> Mithrandir: ah, ok
[10:46] <lamont> because release/dapper/flight-6 doesn't exist yet... :-(
[10:46] <lamont> just say when
[10:47] <lamont> Mithrandir: they're really close to the current daily, yes
[10:47] <lamont> ?
[10:47] <Mithrandir> lamont: they are the current dailies
[10:49] <Kamion> bddebian: *shrug* niche jargon ...
[10:49] <bddebian> Kamion: I know, sorry, I'm just being a nudge
[10:57] <lamont>  /dev/hda                631962    631962         0 100% /media/cdrom0
[10:57] <lamont> /dev/hdd                642554    642554         0 100% /media/cdrom-1
[10:57] <lamont> \
[10:58] <lamont> neat naming convention.....
[10:58] <sivang> heh
[10:58] <lamont> cdrom0 vs cdrom-1
[10:58] <lamont> the hdd instead of hdc thing is all me.
[10:59] <mgalvin> Mithrandir: review is up on ubuntu.com
[10:59] <Mithrandir> mgalvin: thanks
[10:59] <mgalvin> np
[11:07] <debugger> hi
[11:15] <Mithrandir> lamont: when
[11:16] <ajmitch> morning
[11:18] <lamont> Mithrandir: lying
[11:20] <lamont> Mithrandir: ENO ports/releases/dapper/
[11:32] <Mithrandir> lamont: true dat.
[11:32] <Mithrandir> Kamion: how do I release ports?  for-project ports?
[11:39] <sladen> Mithrandir: I love your -*- zone -*- response to the Vim leets
[11:40] <Mithrandir> I doubt they'll catch it, though
[11:41] <sivang> who do I email for admin request proposals?
[11:58] <sivang> hmm, is there no more plain CD only DVD to download for breezy release?
[12:00] <mdke> sivang, what sort of request?
[12:01] <mdke><EMAIL_ADDRESS>if it's a Znarl/elmo job
[12:01] <mdke> -> bed
[12:01] <_mvo_> sivang: on releases.ubuntu.com ?