[12:12] <superm1> like install firmware for your tuners, install necessary kernel modules (like ivtv), set up your initial database for you - take out some of the extra pain thats normally involved for new users getting into myth
[12:13] <superm1> but i really dont want to spin off a derivative distro, i'd like to be able to do these live disks side by side with the normal release disks
[12:13] <HumanPrototype> superm1, so basically you could use it to set up a mytv server or frontend?
[12:13] <superm1> either a primary server, a secondary, or a frontend or combination
[12:14] <superm1> i've got the metapackages in the works right now, and those should show up in feisty
[12:24] <bronson> superm1: I've been meaning to produce an Ubuntu-derived PVR setup too.  I registered ubuntv.org and then got stuck in a high-pressure contract and forgot all about TV.  :)
[12:24] <superm1> haha
[12:24] <bronson> I've been thinking about getting back into that.
[12:24] <superm1> bronson, are you still interested?
[12:25] <superm1> we do have a team started
[12:25] <bronson> Oh yeah.  Got anything for me to look at?
[12:25] <keescook> superm1: what's the team name?
[12:25] <superm1> well join #ubuntu-mythtv and we can chat htere
[12:25] <bronson> will do.
[12:31] <jdong_> Mithrandir / cjwatson: at your leisure can backports binary NEW be cleared?
[12:31] <jdong_> s/cleared/taken care of/
[12:32] <mariano> is edgy having issues with gconv? <http://bugzilla.gnome.org/show_bug.cgi?id=365646#stacktrace>... looks NOTGNOMish
[12:37] <jdong_> look at that! Azureus 3.0 is out! with more memory usage than ever!
[12:37] <jdong_> I am so thrilled my 10G of swap is going to something other than my tmpfs pbuilders
[12:37] <Burgwork> lets! install! it! by! default! cause! that! makes! baby! jesus! cry!
[12:38] <jdong_> :)
[12:38] <jdong_> Burgwork: it comes bundled with beryl and automatix :D
[12:38] <LaserJock> I want automatix-bleeder though :-)
[12:38] <bhale> oh jeez
[12:39] <jdong_> LaserJock: that's the ONLY automatix I recommend to all the forum members
[12:39] <Burgwork> I got an email, in response to my compiz post, claiming that beryl "fixes many of your issues"
[12:39] <rmjb> hey... I like Azureus... very configurable
[12:39] <jdong_> rmjb: yeah me too... at least 2.5 (I can't comment on 3.0 yet)
[12:39] <Hobbsee> Burgwork: hah.  
[12:39] <Hobbsee> Burgwork: have you done a review of beryl yet?
[12:39] <jdong_> rmjb: but for 99% of purposes the resource draw it asks for are ridiculous
[12:39] <Burgwork> Hobbsee: not yet in the repos
[12:39] <rmjb> deluge looks promising though
[12:39] <Hobbsee> i thought it was in hte process of being added
[12:39] <jdong_> rmjb: ktorrent ain't bad either
[12:39] <jdong_> especially svn
[12:40] <rmjb> yeah well that's a java app for you... a mono one too
[12:40] <jdong_> rmjb: well I don't know if it's java/mono's fault or the 10 billion pointless graphical visualizations of downloading :D
[12:40] <rmjb> sorry, meant to say a mono app may also be a resourse hog re: deskbar
[12:40] <jdong_> rmjb: older Beagle too
[12:41] <jdong_> but I don't think that can be blamed on the language stack
[12:41] <bhale> oh jeez
[12:41] <rmjb> jdong_: I like to watch the pointless graphical downloading... passes the time
[12:41] <Hobbsee> LaserJock: what's automatix-bleeder?
[12:41] <rmjb> the oh so long time
[12:41] <jdong_> rmjb: yeah, it does :)
[12:41] <bhale> deskbar is not mono
[12:42] <rmjb> bhale: it isn't? then that doesn't explain things
[12:42] <Burgwork> it is python
[12:42] <Burgwork> the issue is that it does lots of stuff
[12:42] <jdong_> oh sure let's blame it on python now
[12:42] <jdong_> :)
[12:42] <jdong_> lol
[12:42] <Burgwork> doing stuff requires memory
[12:42] <bhale> you dont have to explain things by saying "MONO, RUN FOR THE HILLS"
[12:42] <bhale> do real profiling
[12:42] <Burgwork> beagle does stuff, therefor it uses memory
[12:42] <Burgwork> so will tracker, once it starts actually doing stuff
[12:43] <jdong_> Burgwork: I didn't say that mono was to blame. I said the exact opposite
[12:43] <LaserJock> Hobbsee: it's supposed to be the latest-crack Automatix for Feisty, I think
[12:43] <Hobbsee> ooh great!
[12:43] <LaserJock> Hobbsee: Automatix and Automatix2 are the "stable" ones
[12:43] <Hobbsee> hah
[12:43] <rmjb> meh, I rather have my mem used 96% most of the time (as linux does) than 30%
[12:43] <jdong_> Hobbsee: it's like beta automatix :-/
[12:44] <jdong_> rmjb: and I'd rather not have my torrent client using 3.5GB of virtual memory
[12:44] <jdong_> ;-)
[12:44] <rmjb> point
[12:44] <rmjb> jdong_: care to recommend a good gnome/gtk one?
[12:45] <jdong_> rmjb: well.. there really isn't one at this point other than deluge
[12:45] <jdong_> which is still beta-ish
[12:45] <rmjb> yeah
[12:45] <jdong_> rmjb: I am a proud ktorrent-in-GNOME user
[12:45] <jdong_> it's still a better deal than Azureus
[12:45] <jdong_> and no comment on all you uTorrent-in-WINE fanatics
[12:45] <Hobbsee> jdong_: FUN!
[12:46] <jdong_> heck I use klipper in GNOME :D
[12:46] <rmjb> I tried a kde app in edgy gnome and it didn't start... kreetingcard... amaroK in dapper gnome worked though
[12:46] <jdong_> rmjb: it sometimes help to run kdeinit first before trying kde apps
[12:46] <sladen> rmjb: how did you install 'krieetcard'?
[12:46] <sladen> rmjb: if you did an  apt-get install for using Synaptic Package Manager, it should work fine
[12:46] <rmjb> download an rpm and use alien :D
[12:47] <rmjb> nah I did Synaptic
[12:47] <sladen> rmjb: I thought you said you used 'alien' from an RPM?
[12:47] <jdong_> rmjb: "well, there's yer problem..."
[12:47] <rmjb> maybe the kdeinit was missing then
[12:47] <ailean> what exactly *is* a ribbon?
[12:48] <jdong_> ailean: http://www.urbandictionary.com/define.php?term=ribbon
[12:48] <rmjb> something young girls use to tie up their hair
[12:48] <sladen> rmjb: Debian packages contain the information our resources/libraries and an application needs.  Installing from an incompatible RPM means that that extra information is available.  You'll probably need to install extra KDE applications...
[12:48] <jdong_> or not? :D
[12:48] <sladen> KDE libraries
[12:48] <ailean> ah yeah, there's always a wise guy :)
[12:48] <rmjb> I didn't use alien and an rpm... I was joking
[12:49] <rmjb> I'd rather compile from source than do that... and now I don't have to... I'll package it :D
[12:49] <rmjb> right LaserJock
[12:49] <jdong_> rmjb: that's what the <sarcasm> tag is for
[12:50] <LaserJock> rmjb: \o/
[12:50] <rmjb> jdong_: I'll remember that tag next time... tone doesn't flow well in text chat
[12:51] <LaserJock> you're kidding! ;-)
[12:51] <jdong_> wait but my GNOME 2.17.1 aliened RPMs from Rawhide are working just fine
[12:52] <LaserJock> well, we could always checkinstall just to be safe
[12:52] <jdong_> and cheerfully together we will..... never mind
[12:58] <lamont> anyone know how to sync evo to an ipaq?
[12:59] <Lathiat> lamont: your probably looking for opensync, no idea if it does ipaqs yet tho
[01:02] <lamont> Lathiat: ok
[01:02] <lamont> thanks
[01:15] <bronson> Is there any way to keep multiple pbuilder distros in flight at the same time?
[01:16] <bronson> I'd like to build packages for both Dapper and Edgy, but it doesn't look like pbuilder will allow that?
[01:16] <bronson> It must be one or the other...   Well, unless I use linux-vserver, UML or VMWare.
[01:16] <LaserJock> nah
[01:16] <ajmitch> use different pbuilder configs
[01:17] <bronson> Ah, just create a different config file and then specify it with --configfile?
[01:17] <ajmitch> yep
[01:18] <jdong_> bronson: just different --basetgz arguments works :)
[01:18] <bronson> Would that allow me to get around having to run it as root too?
[01:18] <LaserJock> or you can use the example script that comes from pbuilder
[01:18] <jdong_> no
[01:18] <jdong_> pbuilder needs root to chroot()
[01:18] <jdong_> you can set pbuilder suid root to work around that
[01:18] <jdong_> (kidding)
[01:18] <bronson> Oh, good point.
[01:19] <bronson> Looking forward to capabilities maybe fixing that.
[01:19] <jdong_> bronson: if you're really motivated I've seen some Debian docs on workarounds for pbuilder chrooting
[01:19] <bronson> jdong_: I'm not yet that motivated.  Got to get some real work done first.  :)
[01:20] <bronson> But I am interested.
[01:26] <Hobbsee> bronson: see !pbuilder - the last section
[01:27] <bronson> Hobbsee: !pbuilder?  Does the bang indicate an IRC /msg thing?
[01:27] <LaserJock> no
[01:27] <LaserJock> it's for our bot
[01:28] <bronson> !pbuilder
[01:44] <grexk> What do I need to modify if I'm going to downgrade amd64 to x86? Do I need to reinstall?
[01:50] <Hobbsee> bronson: in a channel that has ubotu in it.  try in #ubuntu-motu
[02:04] <vcef> hi
[02:04] <vcef> batch scheduling?
[02:10] <grexk> it's not possible,,,bye bye every1
 it's not possible,,,bye bye every1
[02:16] <jdong> nonsense
[02:16] <jdong> muahaha
[03:08] <cr3> when testing the latest netboot for feisty, I should be referring to archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386..., right? I'm not seeing an installer-i386 directory under feisty-updates
[05:31] <Mithrandir> Gloubiboulga: hi, is the xubuntu team planning on having a herd 1 as well or should I drop you for this milestone?
[05:32] <crimsun> it would be nice to have a herd 1
[05:33] <Mithrandir> crimsun: are any of you able to do testing of it?  I don't have the resources to do so.
[05:33] <crimsun> Mithrandir: I can test i386, and I'll ping for amd64 and ppc
[05:34] <Mithrandir> coolie
[05:34] <Mithrandir> alternate CDs are ready; I'll spin you live cds in a bit
[05:41] <crimsun> Mithrandir: great, thanks!
[05:43] <poningru> http://steelgryphon.com/blog/?p=96
[06:08] <bobsaget> DCC SCHAT isoiledmypantaloon
[06:09] <elkbuntu> ha
[06:20] <Dekkard> has anyone seen whiprush?
[06:20] <crimsun> he did a disappearing act in frustration, but I do not claim to know very much about the whole thing.
[06:21] <crimsun> argh
[06:30] <elkbuntu> crimsun, we can only hope he comes back, it's such a shame to lose someone like him
[06:35] <Amaranth> He was in my hotel at UDS, awesome guy
[06:46] <elkbuntu> yeah
[07:23] <crimsun> for Xubuntu's 20061204 i386 daily (alt.), automatic keyboard detection on a Dell 104-key US keyboard gives me 'jp' (but I can back out and choose US English), and the installer can't find any kernel modules, so d-i appears to hang
[07:24] <crimsun> md5sum appears correct, reproduced on three i386 machines
[07:24] <crimsun> burned new cd, reproduced again
[07:31] <Mithrandir> crimsun: thanks.
[08:07] <zwnj> is there something like kudzu for ubuntu?  what's the hardware detection application on install time?  can't i just rerun that program? [sorry for the noise, but it is not really an #ubuntu question] 
[08:11] <Mithrandir> zwnj: we use udev for device discovery
[08:13] <zwnj> yes, but i meant the configuration process.  that's a pity that i cannot tell ubuntu to re-discover my graphic card, and re-configure the xorg.conf
[08:13] <somian> Hauddhi ubuntoids
[08:13] <Mithrandir> zwnj: that's an #ubuntu question; dpkg-reconfigure xserver-xorg
[08:14] <somian> I got the I/O error on CDROM drive bug when trying to boot Drake in live cd mode, asking for "persistent" on the boot command line.
[08:15] <Mithrandir> somian: this is not a support channel.
[08:15] <_ion> zwnj: I guess the goal is that xorg.conf mostly doesn't need to exist. I don't know how long that is going to take, though. :-)
[08:15] <somian> Who is going to fix it, Mithrandir?
[08:16] <Mithrandir> somian: nobody; a) dapper is released; b) it's probably a dirty CD or CD-ROM drive.
[08:16] <somian> Dapper is LTS
[08:16] <somian> (2) No. It isn't.
[08:17] <Mithrandir> oh, have you tried with multiple CDs and a new drive?
[08:17] <somian> (1) it is a brand newly burned CD; (2) It boots fine without saying "persistent" on the commandline. (reproducable).
[08:18] <somian> My cds are not dirty. None of them.
[08:18] <Mithrandir> and you have prepared a device for persistency before you try booting with persistent?
[08:18] <somian> Yes, I did prepare a device, according to the instructions on the wiki.
[08:20] <somian> I'm using a ext3 filesystem image in the root of a hdd partition, named "casper-rw".
[08:26] <zwnj> thanks all :)
[08:27] <zwnj> another problem was that the dpkg-reconfigure xserver-xorg didn't detect my GC, but setting the driver to VESA just works well
[08:28] <pitti> Good morning
[08:29] <somian> morning pitti
[08:30] <pitti> Good morning
[09:02] <mdke> mdz, cjwatson: would bug 74481 justify an upload to edgy-updates? It's an easy fix, but I'm not sure of how the new SRU policy is applied - it doesn't seem to fall within any of the categories
[09:02] <Ubug2> Malone bug 74481 in ubuntu-docs "Many scrollkeeper cron.monthly errors." [Undecided,Unconfirmed]  http://launchpad.net/bugs/74481
[09:08] <lifeless> mdke: I'd say low impact to all our users
[09:09] <lifeless> I think its probably ok to treat this as something needing an SRU
[09:11] <mdke> lifeless: aha. Alright. I'm a bit put off by the process required (-proposed, notifying testers, etc) because the fix is so easy, but I'll try and go through the hoops 
[09:11] <lifeless> mdke: the consequences of a mistake are huge.
[09:11] <lifeless> mdke: Doing nothing is safer than doing the wrong thing, for stable updates.
[09:12] <mdke> more scrollkeeper errors?
[09:12] <mdke> but yeah, I see why the policy is there
[09:12] <lifeless> no, potentially broken systems across all our users, if the patch is faulty.
[09:16] <mdke> I'm curious how, but not curious enough to challenge you - I'll take your word for it, and do the procedure
[09:20] <mdke> infinity: should I wait to ask the sru team, or you think it'll be ok, and I can prepare a fix?
[09:21] <somerville32> mdke: If you prepare the fix and provide a debdiff and what not with your proposal, then it'll streamline things.
[09:23] <mdke> ok
[09:24] <infinity> mdke: Prepare a fix, attach a debdiff to the bug, notify the SRU folks.
[09:25] <infinity> mdke: Basically, follow the instructions in the wiki.
[09:25] <infinity> mdke: Don't upload to -proposed until you have approval.
[09:25] <mdke> that's fine, I haven't got a clue how to upload something
[09:28] <mdke> I'll ask dholbach to help
[09:28] <Mithrandir> cjwatson: do you have any idea about the error crimsun reported this morning?
[09:30] <somerville32> mdke: I have a log that'll help you
[09:31] <mdke> somerville32: aha?
[09:35] <somerville32> mdke: I can't find it right now. I'll get it later.
[09:37] <mdke> somerville32: ok
[09:57] <ogra> Mithrandir, any chance i can get a new live iso ?
[09:57] <ogra> install seems fine now (size wise)
[09:58] <Mithrandir> ogra: need new livefs-es too?
[09:58] <ogra> i think so
[09:58] <Mithrandir> can you check?  Look at the livefs build logs.
[10:02] <ogra> there are only 20061204 logs, so yes, i need a new one
[10:03] <Mithrandir> ok, livefs-es buildin
[10:03] <Mithrandir> +g
[10:11] <seb128> could anybody give a build retry to yelp?
[10:12] <dholbach> good morning
[10:12] <dholbach> hi seb128
[10:12] <seb128> hey dholbach
[10:14] <Gloubiboulga> Mithrandir: it'd be nice to have a Xubuntu herd 1. Could you build the isos?
[10:15] <Gloubiboulga> ah, they are up already
[10:15] <cjwatson> mdke: I'd at least consider that for an SRU
[10:16] <cjwatson> crimsun: the keyboard misdetection is known; I filed a bug on keymapper following an earlier report
[10:16] <crimsun> cjwatson: ok
[10:17] <twb> Howdy.  I'm trying to combine the functionality of the casper and nfs initramfs scripts, in order to mount a read-only NFS filesystem and merge it with a copy-on-write ramdisk.  Can anyone suggest documentation or other resources that I might find helpful?
[10:17] <cjwatson> crimsun: somebody needs to merge the Xubuntu seeds
[10:17] <cjwatson> that's the cause of the other problem
[10:17] <crimsun> Gloubiboulga: would you merge the seeds please?
[10:18] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/seeds/xubuntu-feisty>$ fgrep 2.6. *
[10:18] <cjwatson> installer: * Kernel-Version: 2.6.17-10-generic
[10:18] <cjwatson> etc.
[10:18] <Mithrandir> cjwatson: while annoying, do you think the keyboard detection problem is a showstopper?
[10:18] <cjwatson> Mithrandir: no, it's not; you can go back from the screen informing you of the misdetection and select it manually
[10:19] <Mithrandir> agreed
[10:19] <Mithrandir> cjwatson: can you test the ppc isos?
[10:20] <Gloubiboulga> crimsun: yep
[10:20] <crimsun> Gloubiboulga: great, thanks!
[10:21] <cjwatson> Mithrandir: if you give me a few hours for the download ...
[10:21] <Mithrandir> cjwatson: sure, or I can ask pitti
[10:22] <cjwatson>      5275648   0%   49.71kB/s    4:00:21
[10:22] <cjwatson> urgh
[10:22] <cjwatson> I'll leave it going, but evidently I need to go hunting through my local network for hogs
[10:23] <cjwatson> ah, no, it's down to 1:45 now
[10:23] <Mithrandir> amd64/desktop seems fine
[10:23] <Mithrandir> (in vmware)
[10:25] <pitti> Mithrandir: I started rsyncing the ppc image, but it'll take a while (my network sucks for rsync)
[10:25] <Mithrandir> pitti: ack
[10:26] <seb128> do we need to wait on ppc for herd1?
[10:26] <Mithrandir> desktop/i386 seems unhappy on amd64 vmware.
[10:26] <seb128> :(
[10:26] <Mithrandir> I'll try on real hardware.
[10:26] <Mithrandir> seb128: I'm fairly confident the images we have now are good.
[10:26] <seb128> rock
[10:27] <Mithrandir> hmm.
[10:27] <Mithrandir> it crashes on 32 bit too
[10:27] <Mithrandir> cjwatson: is current i386 desktop busted for you in vmware too?
[10:32] <cjwatson> Mithrandir: haven't got that far
[10:33] <Mithrandir> hmm, it only seems to manifest itself on smp machines
[10:33] <Mithrandir> I'll try it on real hardware
[10:35] <cjwatson> Mithrandir: it boots OK here, at least. What was the breakage?
[10:35] <Mithrandir> cjwatson: kernel oopsed.
[10:35] <Mithrandir> cjwatson: is your vmware instance SMP?
[10:36] <cjwatson> no
[10:36] <cjwatson> uniprocessor host
[10:36] <Mithrandir> it only manifests itself on smp here.
[10:36] <Mithrandir> UP seems fine.
[10:37] <cjwatson> has anyone tested ubiquity on i386, or do I need to?
[10:39] <Gloubiboulga> cjwatson: what kernel are we supposed to have? ubuntu seeds seem to use the same kernel (2.6.17-10)
[10:41] <cjwatson> DOH
[10:41] <cjwatson> ok, willfix
[10:41] <cjwatson> Mithrandir: we'll need to respin all alternates ...
[10:42] <Mithrandir> cjwatson: I did them after d-i built last night.
[10:42] <Mithrandir> cjwatson: do we still need to?
[10:42] <cjwatson> yes, out of date seeds
[10:42] <Mithrandir> gnr, ok.
[10:42] <Mithrandir> but -deskop is fine?
[10:42] <cjwatson> unaffected by this problem at least
[10:43] <cjwatson> Gloubiboulga: I'll merge everything - we need to do the lot anyway
[10:43] <cjwatson> sorry about that
[10:43] <Gloubiboulga> cjwatson: no problem
[10:44] <Mithrandir> cjwatson: that means we need a d-i upload too, or?
[10:44] <cjwatson> no
[10:49] <Mithrandir> hmm, possibly bad media, I'll try burning it again
[10:50] <pitti> Mithrandir: 'check' mode?
[10:52] <Mithrandir> pitti: not when it fails to show gfxboot. :-P
[10:52] <pitti> oh, heh
[10:54] <Mithrandir> argh, I don't seem to have any working dvd-rw media here.  I'll go find some new disks
[11:00] <winkle> su
[11:00] <winkle> ehm
[11:00] <pitti> winkle: yup, feel free to paste your su password here, too :-P
[11:00] <winkle> ;)
[11:01] <mnepton> pitti. it rhymes with kitty.
[11:02] <elkbuntu> pitti, run, before he tries to pet you
[11:03] <mnepton> slamdance cosmospolis. enlighten the populace. shot into eternity. methadone kitty.
[11:03] <mnepton> cjwatson: bogofilter?
[11:04] <cjwatson> :-)
[11:06] <ogra> Mithrandir, edubuntu livefs is done
[11:18] <cjwatson> - * linuxprinting.org-ppds # We want those in main, but not for desktop.
[11:18] <cjwatson> + * linuxprinting.org-ppds-exta          # Less common printer drivers we don't want in main
[11:18] <cjwatson> typo, right?
[11:18] <cjwatson> yeah, looks like it
[11:19] <mnepton> there's a linuxprinting.org-ppds-sextra ?
[11:19] <mnepton> wait, don't tell me. i'm safer not even knowing.
[11:20] <pitti> mnepton: simple answer: yes, there is :)
[11:20] <pitti> mnepton: well, an -extra at least
[11:29] <ogra> cjwatson, why did you merge avahi-autoipd ?
[11:29] <cjwatson> why not?
[11:29] <ogra> i dont think that goes well with a locally running dhcpd
[11:29] <cjwatson> if you don't want it merged, it's your choice to remove it
[11:29] <ogra> pitti excluded it ... i'll remove
[11:30] <cjwatson> pitti excluded it> how so?
[11:30] <cjwatson> I just did what bzr merge presented
[11:30] <ogra> well, he asked me if i would want avahi-autoipd and libnss-mdns merged
[11:31] <pitti> I didn't actively exclude it, I just didn't merge the seeds; ogra didn't want to have autoipd in edubuntu by default
[11:31] <cjwatson> then the correct thing to do would have been to merge that bzr changeset but remove the change
[11:31] <cjwatson> it is not everyone else's responsibility to keep track of your choices
[11:31] <ogra> pitti, oh, then i misunderstood, sorry for the fuzz
[11:31] <pitti> no problem, just a misunderstanding
[11:32] <cjwatson> libnss-mdns was already in edubuntu desktop before I got there
[11:32] <ogra> yep, thats fine
[11:33] <ogra> providing dns services is ok, but i want to inspect the behavior of the automatic interface configuration before blindly adding it
[11:34] <cjwatson> Mithrandir: go ahead and rebuild all alternates now; the seeds are up to date
[11:35] <cjwatson> Ubuntu i386 desktop (ubiquity) tests out successfully
[11:50] <Mithrandir> cjwatson: thanks, running.
[12:00] <Mithrandir> cjwatson: ok, i386 on real smp amd64 hardware works fine, so I'll write my problem down to vmware being silly
[12:01] <pitti> yay, 8 mins ETA for ppc/desktop download
[12:01] <Mithrandir> pitti: woo.
[12:01] <Mithrandir> ogra: edubuntu live images for you
[12:01] <cjwatson> Mithrandir: ok, good
[12:01] <cjwatson> pitti: you're ahead of me, then. :)
[12:02] <cjwatson> which is probably just as well - I'm trying to sort out the partman-auto merge into ubiquity, finally
[12:02] <pitti> alternate is jigdo'ed for ages, but I wait for the new images with fixed kernels
[12:02] <cjwatson> a.k.a. "big honkin' frontend rearrangement"
[12:03] <Mithrandir> pitti: fresh alternate should be up now.
[12:03] <pitti> ah
[12:03] <Riddell> Mithrandir: there still seems to be a problem with python-kde3, am investigating
[12:04] <Mithrandir> Riddell: ugh
[12:09] <pitti> cjwatson: I won't be able to test the ppc/alternate soon anyway, I have an appointment in 50 minutes
[12:09] <cjwatson> it'll take me another two hours to fetch that
[12:09] <pitti> I can test it when I return (in about three hours, I'd expect)
[12:11] <StevenK_> cjwatson: Got a sec? I've done an upload of aircrack-ng twice and I haven't heard a peep from Launchpad about it.
[12:12] <cjwatson> StevenK: version?
[12:13] <Mithrandir> StevenK: LP doesn't give any useful error message; I'll try to reprocess it.
[12:13] <StevenK> 0.6.2-5ubuntu1
[12:13] <Mithrandir> hmm, no, that's something else
[12:13] <cjwatson> StevenK: feisty is frozen; all uploads need manual approval
[12:13] <cjwatson>   139287 | S- | aircrack-ng          | 1:0.6.2-5ubuntu1     | 2 hours 20 minutes
[12:13] <cjwatson>          | * aircrack-ng/1:0.6.2-5ubuntu1 Component: universe Section: net
[12:13] <cjwatson> accepted now
[12:13] <StevenK> cjwatson: But I should get a message saying so
[12:13] <cjwatson> yes, you should
[12:14] <cjwatson> StevenK: LP thinks it mailed Steve Kowalik <stevenk@debian.org>
[12:15] <cjwatson> StevenK: your first upload failed due to a known LP bug where it sometimes fails to check the public key; in that case it's known (but hard to fix correctly) that you don't get told about it
[12:15] <StevenK> Ahh
[12:17] <cjwatson> hard to fix> because LP tries not to mail anyone before it's done the GPG check, as a spam backscatter prevention measure
[12:18] <StevenK> Which of course defeats this. :-)
[12:19] <cjwatson> Riddell: what's the cleanest way to indent a group of widgets by a bit in Qt? as in, I have a set of radio buttons each of which may have some subsidiary options; I'd like to indent them to indicate that they're subsidiary
[12:20] <Riddell> cjwatson: fixed width spacer
[12:20] <cjwatson> at the left-hand side of a QHBoxLayout?
[12:20] <Riddell> yes
[12:20] <cjwatson> ok, thanks
[12:22] <Riddell> Mithrandir: I've uploaded python-kde3 with tightened build-deps, could you let it through please
[12:23] <StevenK> Riddell: That fixes the initkdecore symbol thing?
[12:23] <Riddell> StevenK: I certainly hope so, I had it fixed yesterday, the only difference is the one I uploaded yesterday built against the old pyqt
[12:24] <StevenK> Ah.
[12:24] <Riddell> I would have thought the new qt build would have been enough to fix it, but seems not
[12:24] <Mithrandir> pitti: X starting, maybe?
[12:25] <pitti> Mithrandir: it doesn't start yet
[12:26] <pitti> Mithrandir: just cosmetics anyway; ppc live system starts up fine
[12:26] <Mithrandir> ok, goodie.
[12:27] <Mithrandir> hmm, amd64 alternate doesn't seem to like the SCSI vmware thingy?  I though we fixed that?
[12:29] <Mithrandir> ogra_: you have alternates ready now too.
[12:29] <Mithrandir> Riddell: same goes for you ; alternates ready to test.
[12:30] <cjwatson> Mithrandir: which SCSI vmware thingy? disk or C?
[12:30] <cjwatson> CD?
[12:31] <Mithrandir> cjwatson: disk
[12:31] <Mithrandir> Riddell: python-kde3 accepted, btw
[12:32] <pitti> Mithrandir: ppc/ubiquity install is running, but I have to run myself now for my 1300 appointment
[12:32] <pitti> Mithrandir: will continue when I return, sorry
[12:36] <cjwatson> Mithrandir: that should have been fixed by my initramfs-tools upload, yeah
[12:36] <ogra_> Mithrandir, thanks a lot
[12:37] <Mithrandir> so if I tell you there was no \*mpt\* in /lib/modules.
[12:37] <cjwatson> I blame the kernel then
[12:39] <Mithrandir> and xserver-xorg's postinst is looping with the resolution question.
[12:51] <ogra_> edubuntu live-i386 runs fine in qemu
[12:56] <Mithrandir> or rather, it asks once per driver.
[12:56] <Mithrandir> rodarvus: do you know anything about the thing I reported above?
[12:59] <rodarvus> Mithrandir: I joined #ubuntu-devel 20 minutes ago, I'm not sure I have the full backlog of your report
[12:59] <rodarvus> (but would be quite thankful if you could paste it to me in a privmsg)
[01:00] <sladen> pitti: is X starting and restoring the palette?
[01:00] <Mithrandir> rodarvus: basically, I get asked about X resolution about seven trillion times on alternate install.
[01:01] <Mithrandir> cjwatson: actually, initramfs doesn't matter, it's d-i which matters.  I blame the kernel for not having stuffed the right modules in scsi-modules or similar
[01:01] <ogra> oh, that wuld break ltsp ...
[01:01] <rodarvus> Mithrandir: oh
[01:01] <ogra> but i didnt see it when i built my last ltsp chroot on friday
[01:01] <Mithrandir> rodarvus: I haven't tried to reproduce on real hardware, this is amd64 vmware.
[01:01] <ogra> i dont think there were uploads of X 
[01:02] <rodarvus> ogra: indeed, there were no X uploads yet
[01:02] <rodarvus> which makes this failure kind of surprising
[01:11] <Mithrandir> rodarvus: trivially reproducible in vmware/amd64.
[01:15] <Mithrandir> cjwatson: does alternate work for you at all?
[01:17] <cjwatson> Mithrandir: oh, I didn't realise you meant d-i
[01:17] <cjwatson> need to rsync down the seed-fixed alternate image first
[01:17] <ogra> likewise here, but live seems ok to me
[01:19] <Mithrandir> yeah, live seems fine.  It's alternate which is bloody stubborn.
[01:43] <rohan> why is the ubuntu.com home page displaying chinese/japanese characters by default in the search box in the top right ? 
[01:43] <rohan> and, is there any place where i can file bugs for the main website ?
[01:44] <rohan> and in the "Welcome" page it displays "Suchen"
[01:45] <Treenaks> rohan: not for me..
[01:45] <Treenaks> rohan: what language is your browser set to?
[01:45] <minghua> yes, I believe you report to ubuntu-website: https://launchpad.net/products/ubuntu-website
[01:45] <rohan> Treenaks: english
[01:45] <rohan> minghua: aha, thanks
[01:45] <minghua> but then like Treenaks it doesn't happen for me here
[01:46] <rohan> strange .. here it happens in both firefox and konqueror
[01:46] <minghua> I suspect some browser setting problem as well
[01:47] <rohan> now its "Cerca" ;p
[01:47] <rohan> actually, it is changing with each of the tab i click on, in the top navigation pane
[01:47] <Mithrandir> probably some element which is cached and shouldn't be it
[01:47] <Treenaks> rohan: it's still not happening for me
[01:48] <rohan> Mithrandir: this the first time i opened that site in firefox
[01:48] <cjwatson> could be cached by your ISP, though
[01:48] <Mithrandir> rohan: stuff aren't only cached on your end
[01:48] <rohan> ah, i see
[01:48] <Mithrandir> cjwatson: I see it too
[01:48] <rohan> true enough, but it changes randomly
[01:48] <rohan> i.e. not always "Cerca" on support and so on
[01:48] <ogra> me too, it filps between "buscar" and "search" 
[01:48] <cjwatson> Mithrandir: alternate hangs for me while trying to modprobe i82365
[01:49] <cjwatson> booting with hw-detect/start_pcmcia=false may be a workaround; let's see
[01:49] <finalbeta> I'm getting "Keress"
[01:49] <Mithrandir> cjwatson: vmware or real hardware?
[01:49] <cjwatson> Mithrandir: vmware
[01:49] <rohan> finalbeta: yes, me too
[01:49] <rohan> but for me, it changes with each tab
[01:49] <cjwatson> I filed a kernel bug about an oops in i82365 a couple of days ago
[01:50] <rohan> well, do i go ahead and file the bug on the website ?
[01:50] <Mithrandir> cjwatson: yeah, it clearly oopses in vmware.
[01:50] <cjwatson> yeah, hw-detect/start_pcmcia=false works around that crash
[01:50] <cjwatson> release notes
[01:51] <minghua> rohan: I would say be bold to file bugs :-)
[01:51] <minghua> rohan: and maybe invite all these people who see the same thing to comment on your bug as well
[01:51] <cjwatson> yep, no disk detected here either
[01:51] <rohan> minghua: true, but i wouldnt want to file a bug if it is a known issue or so :)
[01:54] <cjwatson> Mithrandir: can you confirm bug 74122?
[01:54] <Ubugtu> Malone bug 74122 in linux-source-2.6.19 "oops loading i82365 in installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74122
[01:55] <elmo> Mithrandir: you're running lithium out of space ...
[01:55] <Mithrandir> cjwatson: done.
[01:56] <Mithrandir> elmo: I know, I'm going to do something about it RSN.
[01:56] <elmo> Mithrandir: k
[01:56] <Mithrandir> elmo: but thanks for the heads-up.
[01:58] <rohan> https://bugs.launchpad.net/products/ubuntu-website/+bug/74508
[01:58] <Ubugtu> Malone bug 74508 in ubuntu-website "Text in the search box changes randomly." [Undecided,Unconfirmed]  
[01:58] <rohan> there .. please comment to help :)
[02:00] <minghua> rohan: you might want to put the exact url in the report...  http://www.ubuntu.com/ I assume?
[02:10] <cjwatson> Mithrandir: I'm not seeing multiple xserver-xorg questions, but I am seeing bittorrent being uninstallable and pkgsel falling over as a result
[02:10] <Mithrandir> cjwatson: hmm, the start_pcmcia workaround is needed on real hw too.
[02:10] <cjwatson> Mithrandir: see also http://cdimage.ubuntu.com/daily/current/report.html
[02:10] <cjwatson> what about real hardware with pcmcia?
[02:11] <Mithrandir> I don't know, I don't have any such which boots cds.
[02:12] <Mithrandir> bah
[02:14] <cjwatson> bittorrent Depends: python (>= 2.5)
[02:15] <cjwatson> I propose commenting gnome-btdownload out of the desktop seed for now
[02:16] <Mithrandir> hmm, why haven't the livefs-es ftbfs-ed?
[02:16] <cjwatson> dunno, and it isn't listed as uninstallable by britney
[02:16] <Mithrandir> maybe it's just not on the cd for some reason.
[02:16] <Mithrandir> weird.
[02:17] <Mithrandir> oh well, can you change the desktop seed and upload?
[02:17] <cjwatson> hmm, what's going on
[02:17] <cjwatson> hang on a bit
[02:18] <cjwatson> I think something is not clever enough to include python2.5 on the CD for some reason ...
[02:18] <Mithrandir> well, python is version 2.4.3-11ubuntu3 in feisty
[02:19] <Mithrandir> (    python | 2.4.3-11ubuntu3 |        feisty | all
[02:19] <Mithrandir> )
[02:19] <cjwatson> the depends is python (>= 2.5) | python2.5
[02:20] <Mithrandir> ah
[02:20] <seb128> do we have access to the frozen packages somewhere?
[02:20] <cjwatson> I think updating germinate on lithium might help ... I'll test
[02:21] <cjwatson> seb128: afraid not
[02:21] <seb128> hum, k :/
[02:21] <seb128> I should not have deleted after upload
[02:21] <cjwatson> seb128: what do you ned?
[02:21] <Mithrandir> seb128: I can give you the sources for single packages, but we don't have binaries yet.
[02:21] <cjwatson> need
[02:21] <seb128> k, will do evolution-exchange later
[02:21] <seb128> no hurry I'll do it after freeze
[02:21] <Mithrandir> seb128: 'k
[02:22] <seb128> thanks Mithrandir, cjwatson
[02:23] <gicmo> seb128: !!!!
[02:23] <gicmo> ;-)
[02:23] <gicmo> ALTER
[02:23] <seb128> gicmo: Alter! :)
[02:23] <cjwatson> oh, I see, it's a germinate bug
[02:24] <gicmo> seb128: if you have time, could you look at the priv msg
[02:24] <Mithrandir> cjwatson: ok, so we just need to respin the alternate cds?
[02:24] <Mithrandir> cjwatson: can we disable pcmcia by default too?
[02:24] <seb128> gicmo: no private msg, you are probably not registred
[02:24] <seb128> gicmo: use gimpnet or register
[02:24] <StevenK> Riddell: -0ubuntu5 fixes the import bug.
[02:24] <Mithrandir> (it's better to piss of those who need pcmcia to install than everybody else who won't be able to install.  IMO)
[02:25] <gicmo> I am
[02:25] <gicmo> ahh not authenticated
[02:25] <cjwatson> bug 74514
[02:25] <Ubugtu> Malone bug 74514 in germinate "doesn't handle versioned dependencies" [Undecided,Unconfirmed]  http://launchpad.net/bugs/74514
[02:26] <Mithrandir> cjwatson: ouch.
[02:26] <Riddell> StevenK: hoorah!  thanks for testing
[02:26] <Mithrandir> cjwatson: is it a trivial fix in germinate or should we just work around it?
[02:27] <StevenK> Riddell: No problem. Shall I kill the bug, or do you want to?
[02:27] <Riddell> StevenK: you have the honour
[02:27] <Riddell> seems that removing the visibility patch gets rid of a couple of entirely unexpected qt bugs too
[02:27] <StevenK> Riddell: Do I have to do everything? :-P I reported it, as well.
[02:30] <Riddell> StevenK: well I can do it if you want, but lets not argue over it longer than it would take to press the button :)
[02:30] <Riddell> Mithrandir: I'll make new kubuntu desktop CDs 
[02:30] <Mithrandir> Riddell: you don't need new livefs-es?
[02:30] <Riddell> oh, yes, so I do
[02:30] <cjwatson> Mithrandir: we should work around it by either removing gnome-btdownload from desktop or adding python2.5 to desktop; your choice
[02:31] <Riddell> Mithrandir: I need your help then for that
[02:31] <Mithrandir> Riddell: kubuntu livefs-es building, then
[02:32] <Mithrandir> cjwatson: let's remove gnome-btdownload; I'd like not to end up with oversized CDs again.
[02:32] <cjwatson> I'll do that, then
[02:32] <Mithrandir> thanks.
[02:32] <Mithrandir> tell me when I can spin new CDs?
[02:33] <cjwatson> it'll need {ubuntu,edubuntu}-meta uploads
[02:36] <StevenK> Riddell: Indeed. I've closed it already anyway. :-)
[02:44] <Mithrandir> uh, we have an ubuntu-meta upload in unapproved?
[02:45] <ogra> Mithrandir, "<cjwatson> it'll need {ubuntu,edubuntu}-meta uploads"
[02:45] <ogra> cjwatson, i'm updateing edubuntu if you didnt do yet ...
[02:45] <ogra> -e
[02:45] <Mithrandir> ogra: this one is 22 hours old.  I didn't think cjwatson possessed a time travel device, though that'd explain how he gets so much done..
[02:45] <ogra> heh
[02:48] <HumanPrototype> cjwatson: Hi - I have been told you are the best person to talk to about ubiquity, is that correct?
[02:48] <cjwatson> ogra: go ahead, just make sure gnome-btdownload gets removed
[02:49] <cjwatson> Mithrandir: can I accept that ubuntu-meta upload first to reduce confusion?
[02:49] <cjwatson> HumanPrototype: yeah, that's me
[02:49] <cjwatson> ogra: make sure to s/edgy/feisty/g in update.cfg
[02:49] <cjwatson> (if not done already)
[02:49] <ogra> cjwatson, did that a week ago ;)
[02:50] <cjwatson> ok
[02:50] <HumanPrototype> cjwatson: I am trying to alter the xubuntu beta 1 cd to setup as a thin client distro and am trying to make ubiquity skip the user setup questions and just create a single user called "user"
[02:50] <cjwatson> HumanPrototype: unfortunately that can't be done in ubiquity at the moment without fairly sweeping code changes
[02:50] <cjwatson> you can set a default, but not skip it
[02:50] <cjwatson> https://blueprints.launchpad.net/distros/ubuntu/+spec/ubiquity-automation is a design for fixing that
[02:51] <ogra> HumanPrototype, there is no implementation to build the ltsp environment from a live CD yet, you need to use the alternate CD for now
[02:51] <cjwatson> now, in the alternate install CD, you can skip the user-setup questions fairly easily
[02:52] <Mithrandir> cjwatson: please do
[02:52] <HumanPrototype> cjwatson: ok, thanks - how about editing the text on that page to say it wont actually do anything and they changing the script to ignore those variables? is that possible?
[02:53] <cjwatson> that's probably more work :-)
[02:53] <cjwatson> HumanPrototype: are you talking about a thin client server, or the thin client itself?
[02:54] <cjwatson> I thought thin clients were typically booted by delivering an image, rather than by doing an installation as such
[02:54] <ogra> right
[02:54] <HumanPrototype> ogra: I must admit I know nothing about ltsp 
[02:54] <ogra> you either use pxe, etherboot or bootp (the latter is unsupported in ubuntu)
[02:55] <ogra> if your client sends out a PXE bradcast, the dhcp server answers it, gives it an IP and tells it where to find a tftp server (usually the same machine) to get the bootkernel from ...
[02:55] <cjwatson> HumanPrototype: hmm, I suppose you could skip a page in ubiquity by modifying the loop in run() in ubiquity/frontend/gtkui.py
[02:56] <HumanPrototype> cjwatson: my boss wanted a distro that would boot and let him login as a thin client similar to a hp thin client box he brought
[02:56] <Chipzz> ogra: I'm not sure, but I think you're mixing something up
[02:56] <ogra> if the kernel is booted the client mounts / via nfs from the ltsp server and boots it ...
[02:56] <Chipzz> ogra: the dhcp server actually also does bootp
[02:56] <cjwatson> change the stepUserInfo case to do self.set_current_page(self.current_page + 1); continue in that case
[02:56] <ogra> Chipzz, well, but not tested or supported in ubuntu
[02:56] <Chipzz> ogra: so pxe *does* use bootp as a matter of fact iirc
[02:56] <HumanPrototype> ogra: this is to connect to a windows terminal server
[02:56] <HumanPrototype> cjwatson: ok, thanks
[02:56] <ogra> HumanPrototype, hmm, then you would want to boot an ltsp client that starts up an rdesktop client
[02:57] <cjwatson> HumanPrototype: but, I think this is probably not the ideal option and you should talk with ogra about LTSP
[02:58] <HumanPrototype> ogra: I'm currently ripping all the guts out of xubuntu and replacing xfce with fluxbox and then install tsclient and rdesktop
[02:58] <ogra> Chipzz, we dont *officially* test bootp or *officially* support it, indeed dhcpd is capable of doing it ;)
[02:58] <cjwatson> HumanPrototype: the ltsp-build-client script defines what gets installed in the client chroot
[02:58] <ogra> (in combination with ltsp that is)
[02:59] <cjwatson> Mithrandir: publisher disabled while I get this done
[03:00] <HumanPrototype> ogra: I'm going to carry on with this for my boss but then I will look into ltsp and going down that route
[03:00] <ogra> HumanPrototype, you can do a standard ltsp install with ltsp-build-client and then install rdesktop in the client environment...
[03:01] <mvo> just to confirm, we do use alsas dmix by default, right?
[03:01] <ogra> HumanPrototype, feel free to ping me in #ltsp or #edubuntu where that discussion is more on topic
[03:01] <ogra> cjwatson, edubuntu-meta should be in the queue
[03:01] <HumanPrototype> ogra: my boss doesnt really know linux and basically wants something that runs on old machines and will boot to give him a gui to setup an rdesktop connection and can reconnect on startup in the future
[03:02] <ogra> mvo, we did in edgy at least
[03:02] <mvo> ogra: thanks
[03:02] <ogra> HumanPrototype, right, sounds like ltsp is the right option for you ..
[03:03] <ogra> but you will need a linux server to boot from ...
[03:04] <HumanPrototype> ogra: could I alter it reasonably easily to get it from a windows server?
[03:04] <ogra> nope
[03:04] <ogra> no nfs on windows ....
[03:04] <HumanPrototype> ogra: i was expecting that somehow
[03:05] <HumanPrototype> ogra: knowing very little would you be able to use samba instead of nfs?
[03:05] <ogra> you can tweak a windows dhcp server and you might even be able to server the kernel via tftp from it ... but for nfs i dotn know a free and easy solution
[03:05] <ogra> i'm not aware of anybody who tried CIFS/SMB for that :)
[03:06] <ogra> might be possible, who knows :)
[03:06] <HumanPrototype> ogra: sounds like an excuse for my boss to run a linux server
[03:06] <ukh> dumb newbie question: why isn't buildlogs for all packages on launchpad?  I'm trying to resolve a nagging little issue that depends on the build environment, but 1.4.2.2-1ubuntu2.1 doesn't expose - however, I find no build log for that one
[03:06] <ogra> heh, yeah
[03:06] <ukh> oups.  the package I'm battling with is gnupg
[03:10] <ogra> thats a security update ... not sure the logs are on launchpad ... 
[03:12] <ukh> well, that's ok, appears to be a regression in gnupg post-1.4.2...
[03:19] <pitti> Mithrandir: if it's not yet too late, ppc/live + ppc/ubiquity works fine
[03:19] <pitti> cjwatson, Mithrandir: shall I test ppc/alternate now?
[03:22] <Mithrandir> pitti: yay, good.
[03:22] <Mithrandir> pitti: please do sync ppc/alternate, but we'll need to respin yet another.
[03:23] <pitti> Mithrandir: oh, ok. I have 1205 already
[03:23] <pitti> Mithrandir: jigdo'ing a new one is super-fast
[03:23] <Mithrandir> pitti: yeah, it should be.
[03:23] <ogra> Mithrandir, seems colin is afk, could you approve the edubuntu-meta uplaod ? 
[03:23] <ogra> *upload
[03:24] <Mithrandir> ogra: I suspect he's byhanding the publisher.
[03:24] <Mithrandir> accepted, though
[03:24] <ogra> oh, ok
[03:24] <cjwatson> I was off writing documentation, actually
[03:24] <ogra> thanks :)
[03:25] <cjwatson> just accepted ubuntu-meta too
[03:25] <cjwatson> publisher running
[03:27] <doko_> cjwatson, adconrad: I uploaded sun-java5 yesterday; it got accepted, but it doesn't show up in the archive. anything I miss?
[03:28] <Mithrandir> Listing ubuntu/None (UNAPPROVED) 1/69
[03:28] <Mithrandir> ---------|----|----------------------|----------------------|---------------
[03:28] <Mithrandir>   139067 | S- | sun-java5            | 1.5.0-10-0ubuntu1    | 29 hours
[03:28] <Mithrandir>          | * sun-java5/1.5.0-10-0ubuntu1 Component: multiverse Section: devel
[03:28] <Mithrandir> so no, it wasn't accepted.
[03:28] <ogra> doko_, we're frozen since some days ;)
[03:28] <ogra> eek
[03:28] <Mithrandir> we've frozen for close to a week..
[03:29] <_ion> Now that the topic is updated, it might be changed from "Ubuntu Development" to "Development of Ubuntu"
[03:29] <_ion> OTOH, the people who should read it don't read it anyway. ;-)
[03:30] <doko_> Mithrandir, ogra: ok, but eclipse got accepted. strange. I thought the freeze was for main only
[03:30] <Mithrandir> doko_: it is, but I suspect nobody has gotten around to accepting your upload, then.
[03:34] <cjwatson> doko_: by policy it is for main and restricted only, but our only available way to implement it is by freezing the entire archive and manually accepting universe and multiverse from time to time.
[03:38] <HumanPrototype> cjwatson: In ubiquity/components/usersetup could i change the stuff in ok_handler to set username to "user" instead of self.frontend.get_username() to force a username?
[03:39] <ogra> our default kernels "are vulnerable to security issues and missing some hardware support." :(
[03:40] <cjwatson> HumanPrototype: that would work, but wouldn't be compatible with skipping the user page altogether
[03:40] <Mithrandir> ogra: no, that's not what it reads.
[03:40] <pitti> ogra: ?
[03:40] <cjwatson> HumanPrototype: if you skip the user page, that code won't be run
[03:40] <pitti> ogra: you mean the multimedia support introduces a security hole?
[03:40] <ogra> Mithrandir, oh, right, *their* homebrewed ones are
[03:40] <ogra> sorry
[03:41] <ogra> pitti, no, i just misread the rationale there 
[03:41] <zul> ogra: then they should do what we did with xen put a kernel in universe or something for their ubuntustudio
[03:42] <ogra> zul, thats the plan as i understood from BenC 
[03:42] <HumanPrototype> cjwatson: ok - i think I will try that as my knowledge of python isnt great enough to find out where to set the username if I do skip the user page
[03:42] <zul> ogra: ah neat..
[03:42] <ogra> there was a discussion on ubuntu-devel 
[03:42] <cjwatson> HumanPrototype: be aware that the UI will be weird if you do that; asking a question and then ignoring the answer, ugh
[03:42] <HumanPrototype> cjwatson: yeah - good point
[03:46] (cjwatson/#ubuntu-devel) HumanPrototype: and add preseed/file=/cdrom/preseed/filename-of-your-choice.seed to the kernel boot parameters on the append lines in /isolinux/isolinux.cfg
[03:59] <Riddell> pitti: http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates/ ?
[03:59] <pitti> Riddell: right
[03:59] <pitti> Riddell: and, if you have a dapper installation around, testing the dapper ones would be great, too
[03:59] <Mithrandir> Riddell: how does your desktop CDs look?
[03:59] <Mithrandir> Riddell: actully, ignore that since I'm in the middle of spinning you new ones. :-P
[04:00] <cjwatson> Mithrandir: I have to go out to order meat for Christmas dinner now; feel free to run the publisher by hand once all *-meta builds are in accepted, or just wait 'til I get back, whatever
[04:01] <Riddell> Mithrandir: what's new in the new ones?
[04:01] <ogra> gnome-btdownload was dropped :P
[04:01] <Mithrandir> Riddell: just the ones from the livefs build an hour or so ago.
[04:01] <Mithrandir> ogra: I hope that doesn't affect kubuntu CDs.
[04:01] <ogra> me too ;)
[04:01] <Riddell> me too!
[04:02] <Mithrandir> cjwatson: I was thinking of just crashing for a bit; I woke up at 0400 today and I'm going over to some friends later.
[04:02] <cjwatson> Mithrandir: ok
[04:03] <cjwatson> Mithrandir: will you be around at all later, if I can get these built? I'd really like to get out of freeze today
[04:03] <cjwatson> I don't think we necessarily need to rebuild livefses
[04:04] <Mithrandir> cjwatson: I'm happy with the ubuntu livecds.  Both amd64 and i386 seem to work for me, sans the small problem of i386 blowing up in SMP 64 bit vmware, but I think we can live with that.
[04:04] <twb> I'm having a lot of trouble booting them over NFS... :-(
[04:04] <Mithrandir> twb: booting the live cd over NFS?  That might be because it doesn't sound like a remotely supported configuration..
[04:04] <cjwatson> ok, so rebuild ubuntu/edubuntu alternates, test quickly, go?
[04:05] <twb> Mithrandir: I realize that.
[04:05] <cjwatson> twb: we're talking about for a milestone release
[04:05] <Mithrandir> cjwatson: yup
[04:05] <twb> I'm trying to implement support.
[04:05] <Mithrandir> twb: don't bother; the code is in casper in Debian, I just need to merge it in.
[04:05] <twb> A fuse bug is kicking me in the teeth.
[04:05] <Mithrandir> cjwatson: I'll byhand the publisher then
[04:05] <cjwatson> Mithrandir: not *quite* yet ...
[04:05] <twb> Mithrandir: oh?  I assumed that Debian's casper was older.
[04:06] <cjwatson> twb: we haven't merged everything since we got out of edgy release freeze yet, so a fair few of our packages are still older
[04:06] <cjwatson> Mithrandir: go ahead and byhand it now
[04:07] <Mithrandir> twb: it's forked and requires a fair bit of merging to get their changes back into our code.
[04:07] <twb> I see.
[04:07] <twb> Does casper actually have a homepage?  I couldn't find it.
[04:07] <Mithrandir> not that I know of, and I'm the primary maintainer. :-P
[04:08] <Mithrandir> Riddell: fresh kubuntu cds for ya.
[04:08] <Mithrandir> (desktop)
[04:08] <ogra> https://launchpad.net/distros/ubuntu/+source/casper
[04:08] <ogra> ;)
[04:13] <twb> Mithrandir: basically, what I do is mount a read-only NFS filesystem that contains the same data as filesystem.squashfs.  I then unionfs that with a tmpfs /cow and run the casper-bottom scripts.
[04:14] <twb> Unfortunately, this blows up because (for some reason) unionfs doesn't let anything append to files, although it allows the files to be deleted and created.
[04:14] <ogra> twb, its probably helpful to have  a look at ltsp (specifically the ltsp-client.ltsp-client-setup.init script) to see the tmpfs workarounds we use there 
[04:15] <Mithrandir> twb: it might very well be a unionfs bug.  We're run into quite a few of those.
[04:15] <twb> I also have this problem using unionfs of Knoppix 3.7 through 4.0
[04:16] <twb> Er, through to 5.0
[04:16] <ogra> thats why ltsp resorts to tmpfs bind mounts ;)
[04:16] <twb> I'm trying to avoid doing that.
[04:16] <Mithrandir> ogra: that doesn't allow you to install packages, for instance.
[04:16] <twb> (That's what Knoppix did historically)
[04:16] <Mithrandir> have you looked at how the support in the debian package is done?  Or you could look at some of the fuse unionfs alternatives.
[04:17] <ogra> well, i can install packages in my fat-client environment 
[04:17] <bddebian> Howdy
[04:17] <ogra> which is essentially a ltsp 
[04:17] <twb> Mithrandir: OK, so this is definitely supported already in Debian's casper?  When you said that before, I wasn't sure you understood what I was doing.
[04:17] <Mithrandir> ogra: how do you do that without having a writable layer on top of your filesystem?
[04:18] <Mithrandir> twb: I'm _fairly_ sure what you're trying to do is doable using their casper, yes.
[04:18] <ogra> Mithrandir, i add the writeable layer via a tmpfs bindmount
[04:18] <twb> Mithrandir: OK.
[04:18] <Mithrandir> I keep meaning to merge those bits, but ENOTIME.
[04:18] <Mithrandir> ogra: like, over /usr ?
[04:18] <ogra> like over specific dirs or files, yes
[04:18] <twb> Mithrandir: I am more than happy to help get this fixed; I can't get rid of Knoppix until I do.
[04:18] <ogra> i wouldnt pick the whole of 7usr though
[04:18] <ogra>  /usr
[04:18] <Mithrandir> ogra: so you don't support arbitrary package installations, then?
[04:19] <ogra> only via chroot on the server ... but you can do temporary installs on the fat client indeed
[04:19] <Mithrandir> ogra: of any package, and you do this without using unionfs?
[04:19] <twb> `temporary installs' being until you reboot?
[04:20] <ogra> twb, yes
[04:20] <Mithrandir> twb: package installations on a live cd tend to be until you reboot. :-)
[04:20] <ogra> i'm working on a "master workstation mode" that mounts / in rw mode to have a maintainer machine ...
[04:21] <ogra> Mithrandir, yes, i do it without unionfs ... but with a huge mtab
[04:21] <ogra> unionfs via nfs is still to buggy 
[04:21] <ogra> s/via/on top of/
[04:22] <ogra> it was like that when mdz started testing it for ltsp and didnt change until edgy ...
[04:23] <HumanPrototype> where can I get involved with ubuntu development?
[04:23] <gnomefreak> HumanPrototype: #ubuntu-motu is the best place to ask/start
[04:23] <ogra> HumanPrototype, https://wiki.ubuntu.com/MOTU
[04:24] <jdong> keescook: ping
[04:26] <Mithrandir> ogra: how do you do it when something wants to install a file in /usr/bin?  You copy all of it into a tmpfs?
[04:26] <iwj> Keybuk: If you have any comments on my discussion of the alleged lvm2 symlink creation race in UdevLvm, I'd be interested to hear them.  But I will press on in the meantime ...
[04:26] <ogra> Mithrandir, yes ... (i know its ugly) 
[04:27] <ogra> Mithrandir, usually you dotn do that at all, but its possible ...
[04:27] <pitti> mdz: can I upload new dapper and edgy -proposed langpacks? (I tested the German ones and checked that a recent major bug in the Kurdish ones was fixed); after they are in -proposed, I'd send out a call for testing to -translators@
[04:28] <twb> btw, casper-bottom/20xconfig seems to assume xserver-xorg is installed.
[04:29] <Mithrandir> twb: it does, but it shouldn't.  It should be guarded properly.  If it's not, please file a bug.
[04:30] <Mithrandir> ogra: so you end up consuming hilarious amounts of memory, then?
[04:30] <twb> Do bugs filed with reportbug(1) actually make it into launchpad?
[04:30] <Mithrandir> twb: no
[04:30] <twb> Bleh.
[04:30] <Mithrandir> they will, eventually, but not yet.
[04:31] <twb> What's the process for submitting bugs for people who can't stand web UIs, then?
[04:32] <Mithrandir> eat a painkiller and use the web UI? ;-)
[04:32] <HumanPrototype> cjwatson: in the preseed files that are there I notice they install ubuntu-base etc - Do I need to configure a package to depend on everything I want to be installed and call it in the same way?
[04:32] <Mithrandir> we're going to get an XML-RPC interface which we'll hook reportbug into, but it's not there yet.
[04:33] <twb> One of the bzr people I was talking to today said he did all his launchpad stuff via mail.
[04:34] <Mithrandir> oh, true, you can submit and manipulate bugs via mail
[04:34] <Mithrandir> https://help.launchpad.net/UsingMaloneEmail has some info on it
[04:34] <twb> Seems a bit silly to break reportbug, then.  I mean, reportbug under Debian basically just sends a mail message.
[04:34] <twb> Thanks.
[04:34] <HumanPrototype> gnomefreak and ogra thanks
[04:34] <Mithrandir> it requires the mails to be signed.
[04:35] <pitti> Mithrandir: oh, there's a new alternate image 20061205.1 -- is that the good one? or do we need .2?
[04:35] <Mithrandir> pitti: we need .2 which is building now.
[04:36] <pitti> ok, thanks
[04:37] <twb> Argh, that URL doesn't render in html2ps
[04:44] <\sh> BenC: one short question...do you want to include the EDAC stuff from vanilla kernel or the updated drivers from bluesmoke.sf.net?
[04:45] <Riddell> pitti: french kde language pack works on edgy
[04:45] <BenC> \sh: Stock
[04:45] <Riddell> pitti: I'll make a dapper chroot now
[04:45] <BenC> \sh: bluesmoke needs to sync up to mainline
[04:45] <pitti> Riddell: vmware image might be better; thanks for testing edgy
[04:45] <\sh> BenC: thx for the information :) 
[04:47] <Mithrandir> pitti: .2 is up; this one ought to work.
[04:53] <Mithrandir> ogra: you have ISOs
[04:53] <twb> Mithrandir: you're right; debian's casper does support ro uncompressed nfs roots.
[04:54] <iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle /dev/hda10
[04:54] <iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle -t /dev/hda10
[04:54] <iwj> LVM2_member
[04:54] <iwj> root@samual9:~# root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle /dev/hda10
[04:54] <iwj> root@samual9:~# /lib/udev/vol_id -t wergle -l wergle wergle -t /dev/hda10
[04:54] <iwj> LVM2_member
[04:54] <iwj> root@samual9:~# Oops.
[04:54] <iwj> Sorry.
[04:55] <looksaus> not entirely sure if the following question is appropriate here; please refer me to a more appropriate channel if you deem it necessary
[04:55] <looksaus> the Intel 3945 wifi driver for Linux requires a binary userspace daemon
[04:56] <looksaus> openbsd people have reverse engineered it (see http://kerneltrap.org/node/6650/print )
[04:56] <looksaus> I'm buying a new laptop, and I'm willing to spend the discount I get from dell on a machine without windows on porting this thing
[04:57] <twb> Also, -o dirs=/cow=rw:/rofs=nfsro instead of .../rofs=ro fixes the bug that has been plaguing me for months!
[04:57] <twb> Hurrah!
[04:57] <mjg59> looksaus: Intel are planning on fixing the issue in the next month or so
[04:57] <[A] ndy80> hi
[04:57] <Mithrandir> twb: yay.
[04:57] <[A] ndy80> is it possibile to avoid libiberty compilation when I compile gcc? because libiberty is distributed with binutils and gcc too, so one copy overwrite the other one... (I'm making a package with checkinstall and this causes a conflict)
[04:57] <looksaus> ah? mjg59, source?
[04:57] <Mithrandir> twb: does nfsro work well with normal volumes as well?  If so, I can change ro to nfsro by default.
[04:58] <twb> NFI.
[04:58] <looksaus> would certainly be good news!
[04:58] <mjg59> looksaus: Personal communication, sadly
[04:58] <twb> The Debian one uses nfsro ONLY for nfs mounts.
[04:58] <looksaus> hey, if _you_ say it, that is more than assuring enough
[04:58] <looksaus> thx mjg59 
[04:58] <Mithrandir> twb: hmm, ok.
[04:58] <twb> That suggests that nfsro doesn't work (or is slow) with non-nfs dirs.
[04:59] <cjwatson> HumanPrototype: is this dapper or edgy?
[05:01] <ogra> Mithrandir, well, yes, it consumes some memory :)
[05:02] <Mithrandir> ogra: you saw that you have fresh alternate ISOs, right?
[05:02] <ogra> yep, already rsyncing
[05:09] <Riddell> pitti: dapper language pack works too (Kurdish and French)
[05:09] <pitti> Riddell: great, thanks; German and English ones work here, too
[05:16] <malex> I'm looking for pbuilder scripts for Edgy, Dapper, and Breezy. Anyone can help?
[05:17] <pitti> malex: -> #ubuntu
[05:19] <mdz> pitti: yes
[05:19] <pitti> great
[05:20] <pitti> Keybuk: could I ask you to upload new dapper/edgy-proposed langpacks in silent mode for me?
[05:20] <pitti> Keybuk: (I'm supposed to ask u-archive now, and Colin and Tollef are still busy with herd-1)
[05:21] <Mithrandir> pitti: also, I have no idea how to make it quiet. :-P
[05:21] <pitti> there's an option to suppress *-changes@lists mails
[05:21] <Keybuk> Mithrandir: -M
[05:22] <desrt> hello :)
[05:25] <dade`> hi
[05:25] <desrt> goodday, dade
[05:28] <Keybuk> pitti: err, where do I find said language packs?
[05:28] <pitti> Keybuk: rookery:/srv/language-packs.ubuntu.com/edgy-updates-proposed-20061205/sources-update/*.changes
[05:29] <pitti> Keybuk: and rookery:/srv/language-packs.ubuntu.com/dapper-updates-proposed-20061205/sources-update/*.changes
[05:31] <Keybuk> pitti: what do you want me to do with them?
[05:32] <pitti> Keybuk: they need to be uploaded in a way that they don't generate -changes emails
[05:32] <Keybuk> pitti: I have no idea how to do that
[05:32] <Keybuk> it's the accept phase that generates changes mails anyway
[05:32] <pitti> Keybuk: I can't do that myself (although I have a long-standing wishlist item for soyuz to allow notification blacklists)
[05:32] <Keybuk> so if you upload them normally, I can block the mailing list ones
[05:32] <Keybuk> just not the ones to you
[05:33] <pitti> Keybuk: ah, ok; so far cprov or malcc did those uploads, but they asked me to delegate this to the archive team
[05:33] <pitti> so I don't know the magic behind it
[05:33] <pitti> Keybuk: alright, then I just dput them?
[05:34] <Keybuk> yup
[05:34] <Keybuk> afaik
[05:34] <cjwatson> don't
[05:34] <cjwatson> I know how to do them
[05:35] <HumanPrototype> am i correct in thinking that this guide (https://help.ubuntu.com/community/LiveCDCustomization/6.06) wont change the files installed by the ubiquty program?
[05:35] <cjwatson> HumanPrototype: ubiquity just copies the live filesystem onto the hard disk, then remooves anything that's listed in /casper/filesystem.manifest but not listed in /casper/filesystem.manifest-desktop
[05:36] <cjwatson> HumanPrototype: so no, if you change the contents of the live filesystem, that will probably change what's installed by ubiquity
[05:36] <Keybuk> cjwatson: how?
[05:37] <HumanPrototype> cjwatson: so if i regenerate the manifest as that guide says then copy it to manifest-desktop then remove certain things (like ubiquity) that you dont want installed on the end system would that work?
[05:37] <cjwatson> HumanPrototype: rigt
[05:37] <cjwatson> right
[05:37] <cjwatson> (damn keyboard, sorry)
[05:38] <HumanPrototype> cjwatson: thanks for all this help :D
[05:38] <hunger> When will herd1 get released? /me misses the thrill of updating packages in an unstable distribution right now;-)
[05:39] <cjwatson> Keybuk: let me just do it to refresh my memory, and then I'll tell you what I did ;-)
[05:39] <Keybuk> cjwatson: uploading should be ok though, it's just queue you have to pass -M ?
[05:39] <cjwatson> Keybuk: you can run process-upload with -M too
[05:40] <iwj> Uh.  I think this livecd is bust.  `Buffer I/O error ...'   `hdc: ide_intr: huh? expected NULL handler on exit' etc.
[05:40] <mconnor> pitti / iwj: in case no one's linked you to this, I dunno how much caillon has talked to you yet, http://steelgryphon.com/blog/?p=96
[05:41] <HumanPrototype> in the preseed file can i remove the line about the splash image to not install a splash image?
[05:41] <mconnor> and wow, you're both here, crazy
[05:41] <iwj> mconnor: Not at all yet.
[05:41] <pitti> mconnor: hi
[05:41] <mconnor> pitti: yo :)
[05:41] <pitti> mconnor: didn't get any mail so far
[05:42] <mconnor> guess he's just been talking to Debian-only people then
[05:42] <iwj> mconnor: Hi, btw :-).
[05:42] <mconnor> iwj: btw, for the record, that was the first time I've seen cops at a Mozilla event ;)
[05:43] <cjwatson> HumanPrototype: I gather you're using dapper, then. Could you clarify exactly what version?
[05:44] <HumanPrototype> cjwatson: actually the original cd i was working off is an xubuntu edgy beta 1 cd
[05:44] <cjwatson> HumanPrototype: why are you using a beta rather than the release?
[05:44] <cjwatson> there was no "beta 1" - I guess you mean either Knot 1 or the Beta, but I'm not sure
[05:45] <cjwatson> the final release has no such line in the preseed file, which is why I'm asking
[05:45] <HumanPrototype> cjwatson: erm... because it was in my cd wallet and a dapper one wasnt and i was at work?
[05:45] <iwj> mconnor: Right, I believe you :-).
[05:46] <HumanPrototype> cjwatson: well it claims to be xubuntu but it does have dapper listed in the sources.list file which i did think was odd
[05:46] <cjwatson> HumanPrototype: that suggests strongly that it's not edgy
[05:46] <cjwatson> I think you have either a mislabelled dapper CD or a very very early (probably broken) edgy CD. the .disk/info file on the CD would tell me for sure
[05:47] <cjwatson> HumanPrototype: anyway, have a look at /preseed/server.seed on the CD - there's a bit at the top of that to avoid installing usplash
[05:48] <iwj> mconnor: Just read that now.  That seems basically what we talked about a few weeks ago.  Nice to see it written down.
[05:49] <mconnor> iwj: it has all of the right buy-in too, so hopefully that goes a long way to making everyone's job easier
[05:49] <mconnor> next up is figuring out why we have binary bits in our tarballs :)
[05:50] <cjwatson> pitti: some of those uploads are older versions than in the archive - there's 6.10+20061019~prop1 in there. Should I just remove those?
[05:50] <HumanPrototype> cjwatson: thanks
[05:50] <iwj> mconnor: Have you had any conversations with any of the Debian guys ?  I tried to encourage them to talk to you but I think they're quite busy.
[05:50] <pitti> cjwatson: yes, please
[05:50] <mconnor> hey, maybe someone knows this here, someone was talking about an OSS project that distributes the trademarked/copyrighted bits in a second source tarball
[05:50] <pitti> cjwatson: I should sort those out myself next time, thanks for the reminder
[05:51] <mconnor> iwj: I have not, but caillon has had quite a few
[05:51] <iwj> Ah, good.
[05:51] <pitti> cjwatson: the scripts for handling -proposed uploads are far from being sophisticated and user-friendly yet :(
[05:52] <cjwatson> pitti: lp_queue@drescher:~/manual-queue/incoming/langpack-20061205$ ls | cut -d_ -f2 | cut -d. -f1,2 | sort -u | xargs
[05:52] <cjwatson> 6.06+20061130~prop1 6.06+20061201~prop1 6.06+20061202~prop1 6.06+20061203~prop1 6.06+20061204~prop1 6.06+20061205~prop1 6.10+20061019~prop1 6.10+20061025~prop1 6.10+20061130~prop1 6.10+20061201~prop1 6.10+20061202~prop1 6.10+20061203~prop1 6.10+20061204~prop1 6.10+20061205~prop1
[05:52] <cjwatson> which ones do you want? :)
[05:52] <mconnor> iwj: things are looking better wrt being able to base Debian/Ubuntu off our stock tarballs by Fx3, instead of you guys needing to do some crazy surgery
[05:53] <ogra> ARGH
[05:53] <pitti> cjwatson: packs are only rebuilt if there is new data for them, so versions are all different
[05:54] <pitti> cjwatson: 6.10+20061019~prop1 is an 'old' one, the rest should be fine
[05:54] <iwj> mconnor: That would be an improvement, certainly.
[05:54] <cjwatson> Keybuk: anyway, you make a directory in ~lp_queue/manual-queue/incoming/, punt everything in there, and do 'LPCONFIG=ftpmaster /srv/launchpad.net/codelines/current/scripts/process-upload.py -C insecure -v -v -v -M ~lp_queue/manual_queue/' (i.e. the thing in lp_queue's crontab but adding -M and changing the directory)
[05:55] <mconnor> iwj: so, uh, question about how you guys handle updates
[05:55] <HumanPrototype> cjwatson, ogra: thanks again for all the help, ill probably be back again soon
[05:55] <cjwatson> and when we're frozen you have to use queue -M too, so yes it's true that pitti could just have uploaded them at the moment 'cos they wouldn't have been directly accepted, but it's better not to get into that habit
[05:55] <ogra> edubuntu-install is broken ... apparently i have no inetd on the CD anymore
[05:56] <mconnor> if we collect all of the random patches that Debian/Red Hat/Ubuntu/Novell have been collecting and get them on the branch, how is that going to work out?
[05:56] <cjwatson> ogra: you need to seed an inetd (openbsd-inetd?) explicitly now - netbase doesn't depend on it any more
[05:56] <cjwatson> Keybuk: actually, I'm using -N 2>&1 first and grepping for Subject: to catch rejectiong
[05:57] <cjwatson> rejections
[05:57] <iwj> mconnor: Each time we take a new upstream, we do a merge, essentially.  Patches that have gone upstream turn into conflicts and we double-check that it's all gone right and throw away our diffs.
[05:57] <ogra> cjwatson, ouch, ok, i used to have netkit-inetd ....
[05:57] <ogra> hmm
[05:57] <iwj> Sometimes we do something equivalent which is a bit less painful.
[05:57] <cjwatson> ogra: what's it used for?
[05:57] <ogra> actually it is seeded it seems
[05:57] <iwj> mconnor: Here `upstream' refers both to you and to Debian.
[05:58] <ogra> ogra@edubuntu:~$ apt-cache show netkit-inetd|grep -i task
[05:58] <ogra> Task: edubuntu-server
[05:58] <ogra> cjwatson, tftp
[05:58] <mconnor> yeah, that complicates things, since their changes always seem opaque until I make Mike Hommey mad enough to explain...
[05:58] <iwj> mconnor: Anything that hasn't gone upstream, we keep.  Debian do the same.
[05:59] <Riddell> ubuntu seeds don't seem to have inetd in them except in server-ship
[05:59] <ogra> hmm, i wonder where it got that task entry from ... its not specifically seeded
[05:59] <mconnor> and if those aren't "security" patches, is that still ok?
[05:59] <iwj> mconnor: In theory all of the relevant info should be in the debian/changelog but perhaps not always in the kind of detail you're looking for.
[05:59] <cjwatson> ogra: ltsp-server depends on netkit-inetd
[05:59] <cjwatson> ogra: so your server installs should be fine ...
[05:59] <ogra> ah, right
[05:59] <ogra> well, it isnt, unless ... hmm, wait
[05:59] <mconnor> iwj: its hard to tell what's in the current patchset when a lot of the changelog talks about bugs we've fixed upstream
[06:00] <ogra> tftpd-hpa complains about missing update-inetd ...
[06:00] <cjwatson> that's in the update-inetd package now
[06:00] <ogra> argh, who makes such silly decisions ....
[06:00] <cjwatson> I'm not absolutely sure what's going on with that split; you may need to do some research into Debian changes
[06:00] <ogra> a package for a single script ?
[06:00] <cjwatson> don't assume it's silly until you've looked into it
[06:00] <cjwatson> it's separated because it should be used for multiple inetd
[06:00] <cjwatson> s
[06:00] <cjwatson> at least that's my understanding of it
[06:01] <ogra> indeed ... but still ... its not *that* big
[06:01] <cjwatson> please don't have such knee-jerk reactions
[06:01] <iwj> mconnor: Yes.  The changelog of the Debian version contains the complete history of the package as seen from Debian.
[06:01] <cjwatson> I very much doubt that it was split due to size
[06:01] <ogra> cjwatson, i'll try to hold back in the future ... 
[06:02] <iwj> mconnor: Our changelogs are a bit different - we have a new policy of recording all of the differences between us and Debian in one entry at the top of the changelog, although lots of stuff may still be duplicated below.
[06:03] <mconnor> iwj: this is why I like the set of patches approach, since that makes it easier to track and understand the changes (and also to throw stuff away once its no longer needed :))
[06:06] <keescook> jdong: pong
[06:06] <ogra> cjwatson, new ltsp in the queue, please approve ...
[06:07] <pitti> Mithrandir: \o/ ppc/alternate success
[06:07] <jdong> keescook: bug 71941 seems to imply dapper/universe's heartbeat-2 has an outstanding security vulnerability?
[06:07] <Ubugtu> Malone bug 71941 in heartbeat-2 "Request heartbeat-2 upgrade to recommended 2.0.7" [Undecided,Unconfirmed]  http://launchpad.net/bugs/71941
[06:08] <ogra> cjwatson, new ltsp in the queue, please approve ...
[06:08] <cjwatson> ogra: freeze exceptions -> Mithrandir
[06:08] <ogra> oki
[06:08] <Mithrandir> pitti: yay!
[06:08] <ogra> Mithrandir, ?? 
[06:08] <Mithrandir> ogra: so you need that + respin of install CDs?
[06:08] <ogra> yep
[06:09] <keescook> jdong: yeah, I saw that but hadn't investigated.  have you looked into it by any chance?
[06:09] <ogra> sorry for no spotting that split earlier ...
[06:09] <ogra> on the other hand live CDs are all fine
[06:09] <Mithrandir> ogra: ok; I'll accept it and turn the publisher back on auto since I'm going over to som friends's soonish
[06:09] <mconnor> iwj: so, backing up for a second, what about the patches from Red Hat to fix pango+mathML, are those going to be a problem?
[06:10] <ogra> Mithrandir, ok, i'll build the final iso myself then ... no prob
[06:10] <jdong> keescook: no, not yet, I was thinking you were the security expert :D
[06:11] <Mithrandir> ogra: anyway, ltsp accepted now.
[06:11] <ogra> thanks
[06:12] <keescook> jdong: hehe.  a quick look through their changelog or version announcements will usually say something.  Since it's in universe, it's not too high up on my todo list at the moment
[06:12] <cjwatson> doko: could you please edit the description of bug 68396 to include a short impact description (i.e. a one-sentence or so description of how each thing you've fixed affects users), and edit debian/changelog of your update to refer to bug 68396? Also mention the parallel build fix in debian/changelog
[06:12] <Ubugtu> Malone bug 68396 in openoffice.org "openoffice.org for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68396
[06:12] <pitti> oh, this update-inetd problem seems to affect ubuntu as well, I cannot configure postfix
[06:12] <cjwatson> doko: is sd.sal_uInt32_aslong.diff the fix for the amd64 crash?
[06:13] <Mithrandir> ogra: ogra ok, manual publisher run going now, you'll have one in a little less than an hour.
[06:13] <ogra> great, ta
[06:13] <jhasse> How do games edit the highscore files if the files belong to root and can't be edited by others???
[06:13] <cjwatson> doko: I think you probably only need to mention bug 62432 and not the other duplicates of it in debian/changelog
[06:13] <Ubugtu> Malone bug 62432 in openoffice.org "Crash when copying text from OpenOffice to other applications" [Unknown,Fix released]  http://launchpad.net/bugs/62432
[06:14] <cjwatson> doko: other than that, I'm happy with this; when you've corrected the above, attach an updated debdiff to the bug, and go ahead and upload
[06:14] <cjwatson> thanks
[06:14] <ogra> jhasse, the files are usually owned by the games group
[06:16] <iwj> mconnor: I haven't looked at them, I'm afraid, so I don't know.  It doesn't sound harmful offhand :-).
[06:16] <iwj> mconnor: Usually we take a fairly conservative approach to patches just because we don't want to diverge too much - so we only take a patch from another distro, or cross-ported from another branch, if we're pretty sure we really want it.
[06:19] <mconnor> iwj: hopefully this is one-time pain, at least, since we want to avoid having a bunch of subtle differences in how web content displays
[06:22] <cr3> just to make sure, I need to build my own boot image to preseed a netinstall, right?
[06:22] <cr3> oups, that question should've been asked in #ubuntu-installer. nevermind :)
[06:50] <spike> hi
[06:51] <lguerra> hi all, 
[06:51] <spike> using preseeding "d-ipartman-auto/diskstring /dev/discs/disc0/disc" works fine for most of our boxes
[06:51] <spike> but then we've got this HP servers, with a compaq smart array and for them it doesnt
[06:52] <seb128> hum
[06:52] <spike> on the installe dsystem disks show up as /dev/cciss/c0d0p1, where cciss is the compaq thingie
[06:52] <seb128> I've upload a new upstream version of a package
[06:52] <seb128> and then a new revision
[06:52] <spike> but I cant find what I'm supposed topass to preseed to get that working
[06:52] <seb128> and it did "Unable to find glade-3_3.1.2.orig.tar.gz in the distribution."
[06:52] <seb128> is that due to the freeze?
[06:53] <seb128> like the tarball is not published?
[06:53] <seb128> should I upload the tarball again? or wait for after the freeze to upload?
[06:54] <pitti> seb128: right, I got the same
[06:54] <pitti> seb128: I guess you should just wait for unfreeze and stack the uploads somewhere
[06:54] <seb128> grumpf
[06:54] <seb128> well, yeah
[06:54] <seb128> do we unfreeze soon? :p
[06:54] <pitti> seb128: stacking might be a good idea anyway; I have the feeling that if you upload the same version twice, the newer one overwrites the older upload instead of being rejected
[06:55] <seb128> it's start being tricky to get work done
[06:55] <pitti> so I won't know if any of my uploads have been killed by an upload from someone else
[06:55] <seb128> between sources not available to work on top from, things that can't be uploaded
[06:55] <seb128> arg
[06:55] <seb128> that would be bad
[06:56] <seb128> yeah, will do that
[06:57] <keescook> zul: have you seen bug 71789?  This sounds like a reasonable change to the package, but I haven't played too much with xen to know.
[06:57] <Ubugtu> Malone bug 71789 in xen-3.0 "xend has open port" [Undecided,Confirmed]  http://launchpad.net/bugs/71789
[06:59] <seb128> pitti: be careful, maybe doko already did and upload it ;)
[06:59] <zul> keescook: ill have a look
[06:59] <keescook> zul: cool, thanks.
[06:59] <pitti> seb128: hmm, maybe
[07:28] <cjwatson> spike: see what parted_devices prints
[07:29] <cjwatson> seb128: uploading the second one with -sa should work
[07:29] <seb128> cjwatson: ok, thank you
[07:29] <cjwatson> pitti: even if that soyuz bug still exists, at minimum you'll see both uploads in -changes, so you'll know
[07:29] <cjwatson> but I think now one will get rejected on accept
[07:29] <cjwatson> (not guaranteed)
[07:30] <seb128> do you think that herd-1 will be ready soon?
[07:31] <cjwatson> yes, Tollef said he was planning to do it tonight
[07:31] <cjwatson> always assuming there are no *more* unexpected roadblocks
[07:31] <seb128> does it make sense to keep the freeze that long? herd-2 is planned for soon, we should maybe drop on herd-1
[07:31] <seb128> ok
[07:31] <cjwatson> yes, it makes sense
[07:31] <cjwatson> we need to get a milestone out, desperately
[07:32] <seb128> well, that one is really early in the cycle
[07:32] <seb128> but right
[07:32] <cjwatson> yes, there's always one as soon as the installer is ready
[07:32] <cjwatson> we need that
[07:32] <cjwatson> you might not, but I do :)
[07:32] <seb128> right
[07:32] <seb128> we need to figure a way to not freeze for a week next time though
[07:33] <cjwatson> I don't hear about new installer problems until awkwardly late otherwise
[07:33] <cjwatson> I don't really think there's much to figure out - I think we just made a mistake in freezing before it had been basically confirmed to work
[07:33] <cjwatson> (to some degree)
[07:33] <seb128> ok
[07:34] <seb128> I'm trying to read what's going on the chan but it's not real clear to me why it's taking that long
[07:34] <LaserJock> cjwatson: do you have the script that produces http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html available somewhere?
[07:34] <cjwatson> seb128: none of the images worked? :P
[07:34] <seb128> I'll let you guys do your job and keep working where I'm not blocked by the freeze
[07:35] <cjwatson> also nobody who's off EU-ish timezones has been working on it, so we've only had 10 or so hours per day basically
[07:35] <cjwatson> having somebody in a different timezone would help
[07:35] <seb128> right
[07:37] <cjwatson> however, the desktop CDs are ready now, I believe - it's just a matter of fixing alternates
[07:38] <seb128> good to know :)
[07:38] <Riddell> cjwatson: what's wrong with alternates?
[07:38] <seb128> almost there then ;)
[07:39] <cjwatson> Riddell: we ran into a germinate bug that meant that bittorrent wasn't installable (it didn't understand "Depends: python (>= 2.5) | python2.5") and therefore gnome-btdownload wasn't uninstallable; didn't affect Kubuntu
[07:39] <Riddell> oh yes, not my worry
[07:39] <cjwatson> Tollef has already respun all affected images
[07:40] <cjwatson> so anyone who cares about the freeze being over and can easily do so, please test
[07:40] <ajmitch> morning
[07:42] <cjwatson> (we're not doing a full test matrix for the first milestone)
[07:49] <pitti> cjwatson: for the record, ppc/alternate worked fine
[07:49] <pitti> shall I do amd64, too?
[07:51] <cjwatson> pitti: if you have time, yes please
[07:51] <cjwatson> although you should enjoy your evening at some point
[07:52] <pitti> oh, girlfriend is at accordion concert rehearsal, that's fine :-p
[07:52] <pitti> I'll do amd64 then, but I can't do i386 (not enough bandwidth)
[07:53] <cjwatson> I'm doing i386 in vmware
[07:54] <cjwatson> only regression from edgy I've noticed so far is that the new automatic partitioner no longer skips the scary manual partitioning screen
[07:54] <pitti> hm, I did manual on ppc, so I didn't notice
[07:54] <cjwatson> which doesn't surprise me really, as that was a very complicated merge
[07:54] <pitti> I'm going to do automatic 'wipe all' for amd64
[07:54] <pitti> cjwatson: only major thing I noticed was the absence of update-inetd
[07:55] <pitti> but that only affects things post-install
[07:55] <ogra> well, it affected edubuntu and ltsp
[07:56] <ogra> and i really wonder why its not a dep of netkit-inetd ...
[07:56] <pitti> ogra: you fixed it in edubuntu?
[07:56] <pitti> added a dep to it somewhere, or just sticked it into -standard?
[07:56] <ogra> well, i made ltsp-server depend on it, since ltsp requires tftpd to be run by inetd in our setup
[07:57] <cjwatson> ogra: I think it not being a dependency of netkit-inetd is a bug
[07:57] <ogra> right
[07:58] <pitti> automatic keyboard detecting is screwed (considers my US layout as JP), but oh well...
[07:58] <pitti> IIRC that was already discussed with smurf, right?
[07:59] <cjwatson> mind you, netkit-inetd doesn't actually use update-inetd itself
[07:59] <ajmitch> doko: want me to upload ironpython 1.0.1 to experimental? I haven't started on it yet
[07:59] <cjwatson> so maybe it is not a bug
[07:59] <cjwatson> it depends on what's actually failing
[07:59] <ogra> cjwatson, thats why i choose to make ltsp-server depend on it
[08:00] <ogra> you cant make tftpd-hpa make depend on it either, since that can also run standalone
[08:00] <pitti> cjwatson: I noticed that postfix failed to install, so maybe postfix itself should depend on update-inetd
[08:00] <cjwatson> one alternative would be switching to openbsd-inetd, since that depends on update-inetd
[08:00] <cjwatson> and then netbase would pull it in
[08:01] <ogra> does it behave any different to netkit-inetd ? i never tried it 
[08:01] <cjwatson> we could also just make our netbase depend on update-inetd for a while
[08:01] <pitti> hmm, seems that vmware install of the alternate is busted, it doesn't detect a drive
[08:01] <cjwatson> pitti: yeah, you have to use an IDE disk, it's a kernel bug
[08:01] <cjwatson> scsi-modules is incomplete
[08:01] <cjwatson> ogra: it's supposed to be better ...
[08:01] <pitti> ok, maybe I better do this on real hw then
[08:01] <cjwatson> vmware IDE disk works ifne
[08:01] <cjwatson> fine
[08:02] <pitti> see you later, then, rebooting
[08:02] <ogra> then i'll try it for ltsp 
[08:02] <cjwatson> pitti: keyboard detection> yes, known, not a showstopper
[08:02] <pitti> argh, need to burn first :)
[08:02] <ogra> i think i read somewhere about netkit-inetd being abandoned by debian after etch, but i may be wrong
[08:03] <cjwatson> I believe that's right
[08:03] <cjwatson> openbsd-inetd is netbase's preferred alternative in Debian
[08:03] <ogra> so the best time to switch then :)
[08:03] <cjwatson> ok, I think I see the partman-auto bug, but I'll test that later
[08:04] <sfllaw> cjwatson: Is mvo's synaptic package sitting in NEW for edgy-proposed?
[08:04] <sfllaw> Bug 65553.
[08:04] <Ubugtu> Malone bug 65553 in synaptic "Synaptic Crashes when changing fonts" [Medium,In progress]  http://launchpad.net/bugs/65553
[08:06] <cjwatson> sfllaw: no, it's in unapproved
[08:06] <sfllaw> cjwatson: Thanks.
[08:07] <cjwatson> that bug should become fix committed when it's accepted
[08:07] <cjwatson>   113267 | S- | synaptic             | 0.57.11ubuntu12.1    | five weeks
[08:07] <cjwatson>          | * synaptic/0.57.11ubuntu12.1 Component: main Section: admin
[08:07] <cjwatson>   137106 | S- | synaptic             | 0.57.11ubuntu12.1    | seven days
[08:07] <cjwatson>          | * synaptic/0.57.11ubuntu12.1 Component: main Section: admin
[08:30] <Riddell> cjwatson: about setting the language for KDM during install (bug 35573), is that a ubiquity or a casper issue?
[08:30] <Ubugtu> Malone bug 35573 in kdebase "No localizations available" [Medium,Needs info]  http://launchpad.net/bugs/35573
[08:42] <pitti> hi zyga 
[08:43] <mdke> cjwatson: ok, thanks. I'll do a bug report
[08:50] <Riddell> Mithrandir: I need to go out now, but all Kubuntu CDs are good to release for Herd
[08:51] <dade`> desrt: are you busy ?
[08:58] <pitti> Mithrandir, cjwatson: amd64/alternate worked, by and large
[09:18] <ogra> Mithrandir, cjwatson, edubuntu live/install amd64 and ppc are good (i386 running)
[09:23] <cjwatson> Riddell: (a) localechooser (b) ubiquity
[09:23] <cjwatson> (i.e. two bug tasks)
[09:23] <cjwatson> Riddell: actually, no
[09:23] <cjwatson> Riddell: just localechooser
[09:23] <cjwatson> it's still annoying that that requires separate configuration rather than using /etc/default/locale or some such
[09:24] <cjwatson> Riddell: so actually if it's at all possible I would far rather that kdm be changed to use the existing places that the system locale is set
[09:25] <cjwatson> the same was suggested in https://launchpad.net/distros/ubuntu/+source/kdebase/+bug/35573/comments/8, although since then /etc/default/locale has become the preferred location for this stuff (it's still in /etc/environment too)
[09:25] <Ubugtu> Malone bug 35573 in kdebase "No localizations available" [Medium,Needs info]  
[09:26] <cjwatson> Mithrandir: Ubuntu i386 alternate looks OK
[09:26] <cjwatson> modulo previously-discussed bugs
[09:52] <ogra>  /dev/hda4 has gone 49710 days without being checked, check forced.
[09:52] <ogra> o_O
[09:53] <tsmithe> that's more than i've been alive!
[09:53] <tsmithe> by a lot!
[09:53] <Lure> ogra: nice uptime ;-)
[09:53] <ogra> heh
[09:53] <ogra> actually thats a fresh feisty install booting ...
[09:54] <jhasse> ogra, but i am not in the games group, how can they modify the file then?
[09:54] <pitti> jhasse: most games are setgid games
[09:55] <jhasse> pitti, how does that work?
[09:55] <pitti> jhasse: you don't know setuid/setgid file permission bits?
[09:55] <jhasse> pitti, no sry
[09:55] <pitti> jhasse: man chmod explains a bit
[10:00] <jhasse> pitti, ah! I always wondered what the 0 before 0777 stand for...
[10:00] <jhasse> pitti, How can i make visible the bits set of a certain file?
[10:01] <pitti> jhasse: do 'ls -l /usr/games' and watch for yourself :)
[10:01] <jhasse> pitti, okay thx
[10:01] <pitti> jhasse: ls -l /usr/bin/passwd for the suid root case
[10:02] <jhasse> pitti, is there a way to display it in number like 2755 ?
[10:02] <pitti> jhasse: stat works at least
[10:03] <jhasse> pitti, k thx
[10:08] <ogra> Mithrandir, cjwatson, from an edubuntu perspective the freeze can end, all arches in all flavours are fine here ...
[11:00] <jdub> fisty becomes awesome!
[11:00] <jdub> $ sudo apt-get upgrade -u
[11:00] <jdub> Segmentation fault (core dumped)
[11:01] <Robot101> closed fist? :)
[11:01] <Arador> those are the little things that make life fun
[11:02] <ajmitch> jdub: I believe mvo has a patch for it
[11:02] <ajmitch> not sure if it was uploaded, in unapproved, etc
[11:03] <fdoving> hmm.. as per https://wiki.ubuntu.com/StableReleaseUpdates step 5, 'Make sure to generate .changes against the base version in the relevant distribution and not against the version in -proposed or a previous version in -updates.' - does that mean 'edit the -proposed changelog entry' leaving the -proposed entry out, in the package that hits -updates?
[11:03] <ajmitch> bug 73062
[11:03] <Ubugtu> Malone bug 73062 in apt "[feisty]  apt and aptitude crashing" [High,Confirmed]  http://launchpad.net/bugs/73062
[11:06] <keescook> fdoving: I didn't interpret it that way, but I've only done one SRU (and it's waiting to be put into -updates)
[11:07] <fdoving> keescook: Did you add a new changelog entry with -updates info? In the example bug, cpio, that was done. -> https://launchpad.net/distros/ubuntu/+source/cpio/+bug/59228
[11:07] <Ubugtu> Malone bug 59228 in cpio "cpio build glitch breaks Unicode char handling" [Unknown,Fix released]  
[11:09] <keescook> fdoving: yeah, bumped the version and pocket, and I duplicated the prior changelog entry, and added a line about who tested it.
[11:09] <Mithrandir> cjwatson: yay!
[11:09] <Mithrandir> ogra: excellent.
[11:09] <Mithrandir> Riddell: are you happy with Kubuntu?
[11:09] <keescook> fdoving: but again, beware.  we could both be wrong.  :)
[11:10] <Lure> Mithrandir: [20:50]  <Riddell> Mithrandir: I need to go out now, but all Kubuntu CDs are good to release for Herd
[11:10] <Mithrandir> Lure: oh, thanks.
[11:10] <psusi> Keybuk: ping
[11:10] <Mithrandir> pitti: it'd be to write the announcement, post it, unfreeze, flush the queues, go partying.
[11:10] <Keybuk> psusi: hi
[11:11] <fdoving> keescook: I choose to blindly trust you. :)
[11:11] <keescook> fdoving: heh
[11:11] <psusi> Keybuk: hiya... are you actively working on the various specifictions for make udev play nice with xxxx?
[11:11] <pitti> fdoving: if in doubt, don't kill changelog entries; they can't hurt
[11:12] <Keybuk> psusi: no
[11:12] <Keybuk> not currently
[11:13] <psusi> is anyone else? ;)
[11:13] <Keybuk> not that I'm aware of
[11:13] <psusi> doh
[11:13] <Keybuk> I believe iwj may be looking at udev-lvm
[11:13] <psusi> well I might take a crack at it
[11:13] <Keybuk> it's still very early in the feisty cycle
[11:13] <psusi> oh it is?
[11:13] <psusi> good
[11:13] <jdong> psusi: I saw that you eventually did patch e2defrag
[11:13] <jdong> psusi: how confident are you that it works :)
[11:13] <psusi> jdong: hehe... yea ;)
[11:13] <fdoving> pitti: it's just that the step-by-step guide at https://wiki.ubuntu.com/StableReleaseUpdates (step 5.3) says I should generate the .changes against the base version in the distro. Is that point obsolete? is it easier for archive admins to review changes if i do this properly as described at that wiki? 
[11:14] <psusi> jdong: highly confidant... I stress tested it quite a bit
[11:14] <jdong> cool
[11:14] <jdong> I'll play with my external then
[11:14] <psusi> and fixed several bugs
[11:14] <pitti> fdoving: I guess this alludes to the usage of -v on debuild, i. e. include all relevant changelogs
[11:14] <psusi> I stressed it good on both ext2 and ext3
[11:15] <psusi> created under dapper and edgy ( they have different mkfs with different default options, the edgy one uncovered another bug or two )
[11:15] <psusi> Keybuk: I was wondering why you talk about having udev create the dm device in the spec wiki page?
[11:16] <fdoving> pitti: ok. keep all changelog entries and use debuild with -v, thanks :)
[11:16] <Keybuk> psusi: the spec outlines the reasons for that
[11:16] <Keybuk> if udev doesn't create it, then we have a race condition
[11:16] <Keybuk> we can't use udev rules and events to use that device
[11:16] <psusi> Keybuk: as far as I can see, we want udev to respond to the underlying physical devices by probing them and calling the correct utility to set up the device mapper... I see no reason to continue having that utility create the dev node
[11:16] <Keybuk> which means we won't be able to mount it
[11:17] <psusi> why do we want any udev rules at all for the virtual device?
[11:17] <Keybuk> to mount it
[11:17] <Keybuk> root=/dev/mapper/...
[11:17] <psusi> sorry, no reason NOT to coninue having the utility create the dev node
[11:17] <Keybuk> or /dev/mapper/... in fstab
[11:17] <Keybuk> that won't work unless udev can reliably hang on those
[11:18] <psusi> how so?  it's the init script that needs to wait for the /dev/mapper/* to be created
[11:18] <psusi> udev can make sure that happens by responding to the underlying physical device with a scan and dmsetup
[11:18] <Keybuk> psusi: BZZT
[11:18] <jdong> psusi: ooh, pretty :)
[11:18] <Keybuk> init script?
[11:18] <Keybuk> what's one of those?
[11:18] <psusi> the init script in the root of the inintramfs
[11:18] <Keybuk> do you mean an upstart task, which is run as a result of a udev event? :)
[11:19] <psusi> the one that processes the root= kernel command line parameter
[11:19] <Keybuk> dmsetup doesn't work
[11:19] <psusi> doesn't work?
[11:19] <Keybuk> not for this
[11:20] <psusi> substitute the correct utility that configures device mapper
[11:20] <psusi> such as dmraid, or vgchange
[11:20] <Keybuk> and how do we know when the /dev/mapper/... device is ready?
[11:20] <psusi> the important thing is that when the underlying device(s) are detected, udev configures the device mapper
[11:21] <psusi> it is ready when it has been created
[11:21] <Keybuk> *sigh*
[11:21] <Keybuk> you've completely missed the point of these specs
[11:21] <psusi> is the point not to get rid of the horrible local-top scripts and their race conditions?
[11:21] <Keybuk> no
[11:21] <Keybuk> the point is to get rid of ALL of the race conditions
[11:21] <jdong> psusi: if e2defrag is violently interrupted, it's not atomic right? (i.e. I'm gonna end up with a paperweight)
[11:21] <Keybuk> not just in the initramfs
[11:22] <psusi> well, yea
[11:22] <psusi> and to make the system fully plug and play
[11:22] <Keybuk> so in fstab we have /dev/mapper/wibble
[11:22] <psusi> i.e. you can plug in a pair of usb disks at run time with an lvm volume on them and it will be recognized and mounted
[11:22] <Keybuk> yes
[11:23] <Keybuk> and in those lvm volumes you could have a crypted filesystem that is decrypted and mounted, forming part of another lvm block
[11:23] <Keybuk> yada yada yada
[11:23] <psusi> right
[11:23] <psusi> ohhh
[11:23] <psusi> ok... I wasn't thinking of the nested case
[11:23] <psusi> although... still that could be handled in the event handers for the real hardware still
[11:23] <Keybuk> to be honest, you weren't thinking of the non-nested case either
[11:23] <Keybuk> to mount /dev/mapper/FOO you need to *know* when /dev/mapper/FOO has been created
[11:24] <Keybuk> which means you need something watching for it
[11:24] <Keybuk> this is inefficient
[11:24] <psusi> ohhhh... ok... I was just thinking about the device creation, not about also mounting it
[11:24] <Keybuk> udev gets uevents for device-mapper block devices anyway
[11:24] <Keybuk> so we may as well use those events to create the /dev/mapper/FOO device
[11:24] <Keybuk> and then we can use the same events to mount the device
[11:24] <Keybuk> etc.
[11:25] <psusi> right.... now I see a problem though
[11:25] <psusi> how do you know what to name it?  vgchange knows what it wants to name it, but when udev gets the event, it only knows it as dm-0
[11:27] <Keybuk> the spec answers that question
[11:27] <Keybuk> the kernel knows what name device-mapper has assigned to it
[11:27] <Keybuk> so udev can know too
[11:27] <Keybuk> and udev can pass *that* name on to things like HAL
[11:27] <psusi> wait a second... why can't udev just mount it while handling the underlying physical device insertion event?
[11:28] <psusi> afaik, the kernel only knows the name 'dm-0'
[11:28] <Mithrandir> psusi: dmsetup table lists the other name, doesn't it?
[11:29] <psusi> hrm....
[11:29] <psusi> maybe the kernel does know it... strange that it still uses the name dm-0 in sysfs
[11:30] <lexi_> hmm... just learned there is an initialramfs inside the ubuntu-kernel  (at least for 686). what is it for and could one use a copy of it as initrd in /boot ?
[11:30] <psusi> anyhow... here is how I see the chain of events:  disk1 is plugged in... udev scans this disk to see if it is lvm... if it is, but needs disk2, nothing is done yet
[11:31] <psusi> disk2 is plugged in... udev scans disk2, and finds that it now has both disks for the vg.... sets up the vg and configures the dm devices to access the volumes, then mounts them
[11:31] <Keybuk> yes...
[11:31] <Keybuk> actually, it's far easier
[11:31] <Keybuk> udev scans disk-1, sees its lvm, runs vmblah (which does nothing as its not complete)
[11:32] <Keybuk> udev scans disk-2, sees its lvm, runs vmblah (which constructs the map)
[11:32] <Keybuk> udev sees dm-0 being created, creates /dev/mapper/VG-LV
[11:32] <Keybuk> udev sees /dev/mapper/VG-LV being created, mounts it
[11:33] <Lure> Keybuk: s/vmblah/vgchange -a y/ ;-)
[11:33] <psusi> what's wrong with doing it all in response to the first event instead of splitting the mounting part off into the response to the dm device being created?
[11:33] <Keybuk> more complicated
[11:33] <Keybuk> you have to write the same code 10 times
[11:33] <psusi> 10 times?
[11:33] <Keybuk> once for normal disks, once for device maps, once for lvm, once for evms, once for raid, etc.
[11:34] <Keybuk> if you write them as little pieces that stack, you only need to do it once
[11:34] <psusi> hrm.... well, I guess it is conceptually a little nicer to let udev handle the recursion
[11:34] <psusi> driven by the dm events
[11:34] <psusi> instead of scripting it
[11:35] <Keybuk> much nicer
[11:35] <Keybuk> and a lot less error prone
[11:35] <Keybuk> the thing about scripts is that they're racey
[11:35] <Keybuk> oops, damn, that device wasn't actually *ready* yet, etc.
[11:35] <psusi> I'm thinking though that the kernel side needs patching to use the given name isntead of the default name
[11:36] <Keybuk> why?
[11:36] <psusi> I think the given name can be stored and retrieved via ioctls right now, but sysfs and thus udev are only told dm-0
[11:36] <Keybuk> the kernel names sysfs objects with an enumerated number
[11:36] <Keybuk> this is consistent
[11:36] <psusi> hrm... just seems odd to have it use a generic name when it knows the correct one
[11:36] <Keybuk> the object should contain a sysfs property with the name, yes
[11:36] <Keybuk> but it's easy enough to find out until it does
[11:37] <psusi> ok... I guess that's alright... then udev just needs to look up the proper name and use that to create the dev node
[11:39] <Keybuk> yes
[11:39] <Keybuk> just like the spec says
[11:41] <jdong> Keybuk: could we have that udev max_sectors rule that I need now?
[11:42] <Keybuk> jdong: maybe
[11:42] <Keybuk> (the rule's wrong, btw :P)
[11:42] <jdong> Keybuk: as you well know I know nothing about udev
[11:42] <jdong> I just did something that worked after 5 tries
[11:42] <Keybuk> for feisty, it should be:
[11:43] <psusi> hehe... also need to do the checks in response to md devices so you can support lvm over md ;)
[11:43] <Keybuk>   SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}=="RockChip", ATTR{max_sectors}="128"
[11:43] <Keybuk> or similar
[11:43] <lifeless> Keybuk: btw, look at pyrex for doing bindings
[11:43] <lifeless> its slick
[11:43] <Keybuk> psusi: that would be that udev-mdadm spec
[11:43] <Keybuk> lifeless: for landscape?
[11:43] <jdong> Keybuk: ok. does that work in Feisty?
[11:43] <Keybuk> jdong: never tested it, but it should
[11:43] <jdong> Keybuk: I tried something similar to that in Edgy and ATTR{max_sectors} did not actually set max_sectors
[11:44] <lifeless> or rctypes, but thats not as slick at the moment IMO
[11:44] <lifeless> Keybuk: for libupstart
[11:44] <psusi> well, I might just dig back into the libdevmapper code to take care of that part, then handle the dmraid case
[11:44] <lifeless> I'd like python bindings in and of themselves :)
[11:44] <Keybuk> lifeless: yeah, I have no clue at this point how to do bindings
[11:44] <jdong> ok, psusi, you're not on my hitlist. e2defrag worked
[11:44] <Keybuk> jdong: that behaviour is new in feisty
[11:45] <psusi> by the way.... these udev rules and their helper scripts should go in the dmraid/lvm/whatever package not the udev package right?
[11:45] <lifeless> I'll mail you a couple of files
[11:45] <jdong> Keybuk: ah, ok, cool
[11:45] <Keybuk> psusi: right
[11:45] <jdong> Keybuk: so can we have it? <g>
[11:45] <psusi> jdong: lol, yay ;)
[11:45] <Keybuk> jdong: if you test it
[11:45] <psusi> jdong: now if only I could get it to build on ia64, sparc, and ppc ;)
[11:45] <jdong> psusi: btw what's the verdict on what happens if e2defrag is interrupted?
[11:45] <jdong> psusi: I'm guessing bad idea
[11:45] <cjwatson> fdoving: pitti's interpretation is correct; I've edited the wiki page to clarify
[11:45] <psusi> jdong: yea... very bad idea
[11:45] <lifeless> Keybuk: are you familiar with setup.py for python programs ?
[11:46] <jdong> psusi:  :)
[11:46] <Keybuk> lifeless: yes
[11:46] <lifeless> ok
[11:46] <jdong> psusi: then I won't use it for any serious things\
[11:46] <jdong> psusi: hence why I still prefer my hackjob copy-move defragger :D
[11:46] <psusi> jdong: get a UPS ;)
[11:47] <jdong> psusi: a UPS isn't the catch-all answer ya know ;-)
[11:47] <fdoving> cjwatson: great. thanks :)
[11:47] <psusi> I'm also amayzed at how fast that little defragger is... it is very smart
[11:47] <jdong> psusi: unless it has a built in 9mm pistol for my cat
[11:47] <jdong> (kidding)
[11:48] <allee> Hi, I'm trying to hunt down a regression in dapper: usbsticks can be mounted via hal anymore.  hal --verbose showed that hal-system-storage-mount was not found. Copying the script from Edgy solved it.   Where I'm stuck is that all hal version in dapper did not contain this script and the fdi files in all dapper hal pkgs list the script.  But it did work before.  Any hint how to continue nailing down what's wrong?
[11:48] <pitti> allee: the storage scripts have been explicitly removed from Debian
[11:49] <pitti> allee: erk, s/debian/dapper/
[11:49] <pitti> allee: and we introduced them in edgy
[11:49] <pitti> allee: there were no such scripts in breezy
[11:49] <fdoving> cjwatson: your edit is also true for step 5 i presume? (i can edit that step, if you ack)
[11:49] <pitti> allee: that wasn't an accidental regression, but an explicit design decision
[11:49] <jdong> psusi: e2defrag's script is reasonably speedy
[11:50] <jdong> psusi: though that's a longer achilles heel than I ever want handling my important data
[11:50] <allee> pitti: interesting. And how did USB stick mounting work in dapper?  I know it worked today before I dist-upgraded a dapper system not updated since 24-Okt?
[11:50] <allee> s/?/!/
[11:50] <lifeless> Keybuk: mail sent
[11:51] <lifeless> Keybuk: it should be obvious enough to bootstrap you - its a binding to readdir()
[11:51] <psusi> well, it isn't a script, but yea... the algorithm is nice and quick
[11:54] <Keybuk> lifeless: converting C idioms into Python is the interesting bit for me
[11:54] <Keybuk> e.g. how do I make sure that when a python object is freed, I can free the C memory
[11:54] <jdong> Keybuk: object=None
[11:54] <lifeless> Keybuk: right. you implement __del__
[11:54] <jdong> actually, that only strongly hints that it should disappear
[11:55] <jdong> :)
[11:55] <Keybuk> upstart obviously uses a hierarchical allocator, which may make things more interesting
[11:55] <lifeless> Keybuk: thats the only hook you have to run code on object free. 
[11:55] <lifeless> Keybuk: talloc ?
[11:55] <Keybuk> no, nih_alloc
[11:55] <lifeless> !
[11:56] <allee> pitti: ah, clarification regession is not breezy -> dapper but dapper -> dapper dist-upgrade to get latest sec fixes
[11:56] <Keybuk> (which I originally wrote during tridge's talk <g>
[11:56] <lifeless> Keybuk: how does it differ to talloc, so I can make suggestions
[11:56] <pitti> allee: no, security updates definitively didn't disable storage scripts; they have been removed in dapper final
[11:56] <Keybuk> lifeless: much, much simpler
[11:56] <pitti> allee: they might have been present in dapper beta or so