[12:31] <Adri2000> the source package tagcoll has been renamed to tagcoll2 in debian but https://launchpad.net/distros/ubuntu/+source/tagcoll is not up to date and https://launchpad.net/distros/ubuntu/+source/tagcoll2 doesn't exist
[12:33] <Adri2000> it has been renamed in september, could an archive admin look at that please?
[12:41] <Adri2000> Mithrandir ? mdz ?
[12:41] <LaserJock> Adri2000: generally it's best to file a bug for that kind of thing
[12:42] <sladen> Adri2000: can you file a bug at https://launchpad.net/distros/ubuntu/+source/tagcoll/+filebug  and then subscribe ubuntu-archive
[12:42] <Adri2000> ok
[12:49] <alex-weej> my usplash bootup is still the old orange bootup screen
[12:49] <alex-weej> bug?
[12:51] <sid> alex-weej: dpkg-reconfigure usplash
[12:52] <alex-weej> done
[12:52] <alex-weej> any idea why it wasn't done automatically?
[12:52] <sid> nope
[12:52] <alex-weej> hmm
[12:52] <alex-weej> ok ta
[12:52] <sid> I've gone from xubuntu-desktop to ubuntu-desktop, and usplash don't change automatically. You have to dpkg-reconfigure usplash
[12:59] <alex-weej> how does usplash know which theme to use
[12:59] <sladen> ...which causes the update-initramfs
[12:59] <sladen> update-alternatives selects between the themes
[12:59] <alex-weej> got it
[12:59] <alex-weej> ta
[01:00] <sladen> update-alternatives --display usplash-artwork.so
[01:27] <sid> "There are 347 languages with more than a million speakers. But even Ubuntu, which has amazing infrastructure for translation and a great community that actually does the work, is nowhere close to being fully translated in more than 10 or 15 languages."
[01:27] <sid> Where is the list of the 10 or 15 languages? Where can I see if my language is fully done yet or not.
[01:28] <LaserJock> sid: hmm, Rosseta would be a good place I guess
[01:28] <LaserJock> Rosetta rather
[01:29] <LaserJock> something like https://translations.launchpad.net/distros/ubuntu/edgy/+translations
[01:30] <sid> awesome, thanks LaserJock, I appreciate the help
[01:31] <sfllaw> cjwatson: How can I tell what date something was approved for -proposed?
[01:33] <LaserJock> sfllaw: we should have some sort of proposed.ubuntu.com where we can get a list of packages, status, etc.
[01:33] <sfllaw> LaserJock: Well, we can see what's in the Package.gz.
[01:34] <LaserJock> yeah, but perhaps a little more info for testers, etc.
[01:34] <sfllaw> Hmm.  Using Kubuntu is interesting.
[01:34] <sfllaw> LaserJock: True.
[01:35] <LaserJock> I was thinking about ways to make proposed in Universe work a little smoother
[01:35] <LaserJock> and that was something that came to mind
[01:36] <keescook> wtf... ran dpkg-genchanges with -sa and it didn't include the orig.tar.gz??
[01:39] <jdub> hrm
[01:40] <keescook> very weird... reran it... it's okay now.  I must have done something wrong, but I swear I was only ever using the merge-genchanges script.  *confused*
[01:47] <mdz> keescook: genchanges doesn't decide which files to include
[01:48] <mdz> oh, perhaps it does for source
[01:48] <keescook> mdz: still, I only ever ran the merge-genchanges script.  I'm looking at my bash history now, out of curriosity.
[01:50] <keescook> ah-ha! my build scripts created one source.changes (without orig), and when I first ran the script, I typo'd the redirection.  *whew*  entirely PBKAC.  :)
[02:01] <keescook> Mithrandir: I have a security update for evince in feisty/main.  I'm guessing I should hold off on the upload?  (There a public exploit, but it is caught by the stack-smashing detection.)
[02:25] <sladen> "uploads will be held until HERD 1.0 is released" ---that'll be sometime next decade then
[03:49] <jdong> whee! resizing ext3 online with --force flags is fun!
[03:49] <jdong> and it only took 2 fsck passes to make it sane again :)
[04:08] <_ion> jdong: :-)
[04:09] <jdong> I don't think I lost any data :)
[04:09] <jdong> ooh! let's write a howto!
[04:09] <jdong> HOWTO: live grow and shrink ext3 partitions
[04:09] <jdong> :)
[04:10] <_ion> Growing is probably much more reliable than shrinking.
[04:12] <jdong> _ion: nonesense. I'm --forcing it to be --reliable :D
[04:23] <uenyioha> anyone with working knowledge of awk?
[04:23] <infinity> To what extent?
[04:23] <uenyioha> find . -type d -name "peer[1-9] " | awk '{print "cp peer $0"}' | /bin/sh
[04:23] <uenyioha> why doesn't this copy a single file to multiple directories
[04:24] <infinity> Why would you do it that way anyway?
[04:24] <uenyioha> because im trying to automate it?
[04:25] <infinity> find . -type d -name "peer[1-9] " -exec cp peer \{\} \;
[04:25] <uenyioha> ooh!
[04:27] <uenyioha> thanks a lot infinity
[04:28] <keescook> uhm, doesn't infinity's cmdline copy peer to multiple files?
[04:28] <infinity> Copies it into the target directories.
[04:29] <infinity> It does what I think he was trying to do above.
[04:29] <keescook> ah! I can't read
[04:29] <infinity> Though I can't say for sure what he was trying to do. :)
[04:29] <keescook> I would use xargs because I like -0
[04:29] <infinity> xargs is also love, yes.
[04:29] <keescook> heh
[04:44] <fabbione> morning guys
[04:46] <_ion> Hola.
[05:07] <alex-weej> ok
[05:07] <alex-weej> so my hard disk just died
[05:07] <alex-weej> and everything started whinging that stuff was read-only
[05:08] <jdong> alex-weej: that sucks :-/
[05:08] <jdong> alex-weej: died, or just some corruption?
[05:08] <alex-weej> well i get inode lookup errors
[05:08] <alex-weej> i'm on windows now backing up as much stuff as i can find
[05:08] <alex-weej> lots of missing files and bad noises from disk
[05:08] <alex-weej> it just happened all at once :(
[05:09] <jdong> alex-weej: ouch
[05:09] <alex-weej> i haven't tried an fsck yet
[05:09] <jdong> alex-weej: if you have a spare drive or a network server... do a raw dd backup of the partition
[05:09] <jdong> that could be handy
[05:10] <alex-weej> will a dd work?
[05:10] <jdong> absolutely
[05:10] <jdong> that's what I was referring to
[05:10] <alex-weej> even with bad blocks?
[05:10] <jdong> alex-weej: use ddrescue or dd_rescue
[05:10] <fabbione> no it won't
[05:10] <fabbione> as jdong say
[05:10] <alex-weej> i don't have a spare disk yet
[05:10] <alex-weej> this one is full of windows guff
[05:11] <jdong> alex-weej: fileserver over ssh?
[05:11] <alex-weej> i'm at uni
[05:11] <alex-weej> all my boxen are at home :(
[05:11] <jdong> fabbione: I guess you can use dd with noerror :) but that might be a tad slow 
[05:11] <jdong> alex-weej: well, be selective with pulling off data and stop using the disk as soon as you can....
[05:12] <alex-weej> i've got pretty much everything important
[05:12] <jdong> you don't want it to croak prematurely due to your inefficiencies at extracting the data...
[05:12] <alex-weej> though i can't tell what i'm missing yet
[05:12] <alex-weej> sometimes when opening folders my hard disk makes a tick tick tick... tick tick tick... tick tick tick... tickticktickticktickticktick... noise
[05:12] <alex-weej> a few times
[05:12] <alex-weej> and it seems to be missing some/all of the files
[05:12] <jdong> alex-weej: seek failures....
[05:12] <alex-weej> hardware?
[05:12] <rmjb> www.spinrite.info ... it might work for you
[05:12] <jdong> right
[05:12] <alex-weej> (i know nothing...)
[05:13] <jdong> rmjb: dd_rescue can do everything that spinrite can
[05:13] <rmjb> cool
[05:13] <jdong> rmjb: spinrite is quite a marvel of marketing hype
[05:13] <jdong> just like most gibson things
[05:13] <alex-weej> lol
[05:13] <jdong> alex-weej: I highly recommend you to find a drive to do a dd to
[05:13] <alex-weej> ok
[05:14] <jdong> alex-weej: even if you have to use a generous return policy at your local tech store
[05:14] <alex-weej> i'm gonna buy a 320 GB seagate to
[05:14] <alex-weej> do that
[05:14] <jdong> use dd_rescue or dd_rhelp
[05:14] <jdong> dd_rhelp might be a better idea
[05:14] <jdong> it's a wrapper around dd_rescue
[05:14] <alex-weej> what's dd_rescue for that is different to dd?
[05:14] <jdong> alex-weej: it works around bad blocks intelligently
[05:14] <alex-weej> i see
[05:14] <alex-weej> ok here's my plan
[05:14] <jdong> alex-weej: dd just fails when it encounters a read error
[05:14] <alex-weej> i'm gonna get hold of a hard disk
[05:15] <alex-weej> install a fresh copy of ubuntu
[05:15] <alex-weej> use dd_rhelp to take an image of the disk
[05:15] <alex-weej> then what do i do with the image?
[05:15] <jdong> alex-weej: save it :)
[05:16] <alex-weej> how can i get files out of it?
[05:16] <jdong> make a copy of it, mount it loopback, or fsck it, etc
[05:16] <alex-weej> i see
[05:16] <jdong> always keep an archive of what dd_rhelp was able to pull off
[05:16] <alex-weej> ok
[05:16] <jdong> because a fsck could improve things, or it could just make things worse
[05:16] <alex-weej> it's going to be a looong week waiting for this new HDD
[05:17] <jdong> alex-weej: and if you can find an ext2/3 expert, he can probably get mroe data off of the image than a plain fsck
[05:17] <alex-weej> lol
[05:17] <jdong> alex-weej: as long as you have that image, you have lots and lots of options
[05:17] <alex-weej> ok
[05:17] <alex-weej> i will stop messing with my disk then
[05:17] <jdong> alex-weej: don't laugh -- read the filesystem mailing lists :)
[05:17] <jdong> it's filled with people with this kind of a situation :D
[05:17] <alex-weej> btw
[05:17] <alex-weej> i should tell the full story
[05:17] <alex-weej> for about a month and a half, kernel has been giving me buffer I/O errors
[05:18] <alex-weej> but on my SECOND disk
[05:18] <alex-weej> (i.e. my Windows disk)
[05:18] <alex-weej> on the same 32 sequential blocks
[05:18] <alex-weej> i had finally had it today
[05:18] <alex-weej> so i booted windows and told it to do a full disk check
[05:18] <alex-weej> an hour and a half later it comes back clean
[05:18] <alex-weej> so i boot ubuntu again
[05:18] <alex-weej> and then everything starts going wrong
[05:19] <jdong> ouch
[05:19] <jdong> yeah, at this point definitely don't power the drive more than you need to
[05:19] <jdong> you don't know how much life it has left before it completely stops reading :)
[05:19] <alex-weej> i ran a test with smartctl on both disks last week
[05:19] <alex-weej> this disk was absolutely clean
[05:20] <alex-weej> it's scary how fast the problem has come on
[05:20] <jdong> alex-weej: I am less than impressed with smart
[05:20] <jdong> alex-weej: a lot of times it warns me _after_ the filesystem is corrupted beyond easy repair
[05:21] <rmjb> smart just lets you know what the disk think is going wrong, if the disk isn't too smart, you wont see any problems
[05:21] <jdong> so far, seagates have the best success rate for me
[05:21] <jdong> maxtors are ticking time bombs
[05:21] <alex-weej> i'm on 2 seagate barracudas
[05:21] <alex-weej> 125 GB a piece
[05:21] <jdong> WD's are pretty good too... but when they fail they instantly die :)
[05:21] <alex-weej> i had a once-monthly backup policy at home
[05:22] <alex-weej> using ssh and rsync over the network
[05:22] <jdong> alex-weej: the barracudas (7200.9/7200.10) have been terrific for me
[05:22] <Lathiat> i had too many WDs fail
[05:22] <Lathiat> i gave up
[05:22] <Lathiat> so im on seagates now
[05:22] <Lathiat> no failures yet
[05:22] <jdong> seagates, unite!
[05:22] <Lathiat> and we use them extensively at work and have very little problem
[05:22] <jdong> Lathiat: I have two WD drives, and only one has failed on me....
[05:22] <HrdwrBoB> I had heaps of seagates fail
[05:22] <Lathiat> i have a stack of 5 120-200 WD drives on my desk
[05:22] <jdong> Maxtors have like a 80% failure rate at my house :)
[05:22] <Lathiat> i mean failures happen
[05:23] <Lathiat> but WD just seemed to fail more often than not for me :)
[05:23] <Lathiat> that said my WD raptors have been rock solid
[05:23] <Lathiat> i even sent one of my 200G ide WDs back
[05:23] <Lathiat> came back 'recertified' plugged it back in
[05:23] <Lathiat> click click kalick chunk chunk click click ;p
[05:23] <jdong> in fact... right now I have a 60G maxtor spitting out intermittent seek errors in dmesg
[05:23] <alex-weej> lol
[05:23] <alex-weej> oh man
[05:23] <jdong> it's storing very unimportant data right now
[05:24] <jdong> I'm just waiting for it to die
[05:24] <alex-weej> seriously - i was so annoyed with my errors
[05:24] <alex-weej> somehow even though it was on a disk not even used for bootup
[05:24] <alex-weej> it halted my boot by 2 minutes
[05:24] <jdong> alex-weej: is it an IDE disk?
[05:24] <alex-weej> to go through 32 buffer I/O errors 5 seconds apart
[05:24] <alex-weej> yes
[05:24] <jdong> alex-weej: a lot of IDE chipsets will choke even if only one drive is experiencing errors
[05:24] <alex-weej> mmh
[05:25] <jdong> I've seen an entire channel of my VIA's go down if one drive spits back errors
[05:25] <jdong> kinda defeats the RAID5 ;-)
[05:25] <Lathiat> heh
[05:25] <Lathiat> "entire channel" thats only 2 drives? ;)
[05:25] <jdong> Lathiat: ok, I don't have raid6. shoot me :)
[05:25] <HrdwrBoB> which is the problem with software raid5: it's not the software, it's the controllers+drivers
[05:25] <jdong> worst part, it took a hard reset to restore...
[05:25] <jdong> and it was a remote box
[05:25] <Lathiat> raid5 sucks enough for storage loss ;p
[05:26] <Lathiat> let alone raid6, sheesh :)
[05:26] <alex-weej> hmm i really don't wanna wait a week
[05:26] <alex-weej> does anyone know any good cheapish stores to buy a seagate disk from in London? 
[05:26] <Lathiat> plus that probably whacks the cpu a little more
[05:26] <jdong> HrdwrBoB: it's afforded me some protection nonetheless...
[05:26] <jdong> Lathiat: significantly more :)
[05:26] <jdong> Lathiat: look at your dmesg raid5/raid6 benchmarking output 
[05:27] <jdong> [17209423.008000]     pIII_sse  :  4351.000 MB/sec
[05:27] <jdong> [17209432.816000]  raid6: using algorithm sse2x2 (1998 MB/s)
[05:27] <HrdwrBoB> I think Lathiat was complaining about losing storage space
[05:27] <Lathiat> hrm here i get
[05:27] <HrdwrBoB> not speed
[05:27] <Lathiat> [17873752.540000]  raid6: sse2x2    2024 MB/s
[05:27] <Lathiat> [17873751.680000]     pIII_sse  :  2338.000 MB/sec
[05:28] <Lathiat> HrdwrBoB: i was complaining about both
[05:28] <jdong> Lathiat: what kind of CPU is that?
[05:28] <Lathiat> p4 1.8
[05:28] <jdong> interesting
[05:29] <jdong> [42957081.080000]     pIII_sse  :  2321.200 MB/sec
[05:29] <jdong> [42957084.670000]  raid6: using algorithm sse2x2 (1009 MB/s)
[05:29] <jdong> Lathiat: your CPU is a freak of nature
[05:32] <ajmitch> that seems rather slow
[05:33] <infinity> Gar, who merged fuse-utils?
[05:34] <infinity> ogra: fuse-utils fails to install in a chroot.
[05:34] <Lathiat> jdong: :P
[05:40] <alex-weej> question, guys
[05:40] <alex-weej> people have mentioned hdparm and smartctl to check disk health
[05:41] <alex-weej> are there any other tools i should know of?
[05:43] <alex-weej> reading about dd_rhelp makes me smile
[05:43] <_ion> dd_rhelp rules.
[05:44] <jdong> alex-weej: well.... hdparm really isn't that helpful... smartctl can be useful
[05:44] <jdong> alex-weej: but remember it's your drive trying to predict its own death...
[05:45] <alex-weej> yeah
[05:45] <jdong> alex-weej: and dd-rhelp really does rule
[05:45] <jdong> alex-weej: it's awesome for recovering scratched CD/DVD's,  too
[05:45] <alex-weej> i read there are actually 2 "dd rescues"
[05:45] <jdong> alex-weej: correct
[05:45] <jdong> alex-weej: dd_rhelp works with dd_rescue
[05:45] <alex-weej> is GNU dd rescue better than dd_rhelp?
[05:45] <jdong> alex-weej: no...
[05:46] <jdong> alex-weej: dd_rhelp makes multiple passes over your drive
[05:46] <alex-weej> ok i will just try dd_rhelp
[05:46] <jdong> alex-weej: it first tries to grab everything that reads without difficulty
[05:46] <jdong> then it goes back to the unreadable places and tries again and again
[05:46] <jdong> that should maximize your chances of pulling off all the readable data
[05:47] <alex-weej> i think i made a bit of a schoolboy error, btw
[05:47] <alex-weej> i had a folder with thousands of FLACs, Oggs and MP3s in it
[05:47] <alex-weej> it has been reduced to about 159 :(
[05:47] <alex-weej> is it bad to fill folders up with lots of files?
[05:48] <jdong> alex-weej: not necessarily
[05:48] <jdong> alex-weej: some of your filesystem structures are probably unreadable at the moment
[05:48] <jdong> which is why your files aren't showing up
[05:48] <jdong> having dd_rhelp pull off more readable data would definitely help
[05:48] <alex-weej> ok i'm hearing you
[05:48] <jdong> and an e2fsck pass over a COPY of the rescued image might help even more
[05:49] <alex-weej> got it
[05:49] <alex-weej> i've just ordered a 320 GB seagate
[05:49] <alex-weej> meaning i can pull off my 120GB partition as an image
[05:49] <jdong> cool
[05:49] <alex-weej> and make a copy of it
[05:49] <jdong> yep that'll give you plenty of room
[05:49] <alex-weej> and play with that
[05:49] <jdong> give that ailing drive a rest :)
[05:49] <alex-weej> i guess i should
[05:49] <alex-weej> i just don't wnat it to die in its sleep :(
[05:50] <_ion> When a HDD crashes and for some strange reason you don't have a backup of the important data: 0) Create images of the partitions using dd_rhelp. 1) Backup the images. 2) Only after doing that use whatever recovery tool on the images.
[05:50] <alex-weej> i was just saying today to a friend how well behaved this computer has been
[05:50] <jdong> alex-weej: in my experience the more you use the failing drive the faster it'll fail
[05:50] <jdong> having it die in its sleep probably won't happen
[05:50] <alex-weej> ok i've got the best i can
[05:50] <jdong> it's far more likely that keeping it spinning is worst for it
[05:51] <alex-weej> just sucks i'm gonna have to run windows for the next week :E
[05:51] <jdong> livecd's, buddy... livecd's
[05:51] <jdong> or colinux :)
[05:51] <alex-weej> can't burn a live cd
[05:51] <alex-weej> windows doesn't support ISO burning out of the box
[05:51] <jdong> alex-weej: no internet connection?
[05:51] <alex-weej> ... :P
[05:51] <jdong> alex-weej: there's a pretty small PowerToy for burning ISO's
[05:51] <alex-weej> suppose i could get a demo of Nero or somet
[05:52] <alex-weej> o rly?
[05:52] <jdong> yeah
[05:52] <alex-weej> hmm
[05:52] <jdong> and also, there's win32 ports of cdrecord
[05:52] <jdong> :)
[05:52] <ademan_> doko: i hear you're involved with eclipse in ubuntu, i have a huge problem, the version of the eclipse cdt in the repositories doesn't work with the version of eclipse in the repositories
[05:52] <jdong> the latter is more fun to play with :)
[05:52] <alex-weej> wonder if i could boot a live cd
[05:52] <alex-weej> and image my disk into RAM :D
[05:52] <jdong> lol give it a rest :)
[05:52] <jdong> now's not the time to experiment :)
[05:53] <alex-weej> jk :D
[05:54] <ademan_> doko: the people in #ubuntu-motu can vouch that i've been trying to package a newer version for about a week now, and i'm reaching wits end, any help you could provide would be wonderful
[05:54] <alex-weej> cheers for all your help everyone
[05:54] <alex-weej> specially jdong :wub:
[05:55] <alex-weej> now
[05:55] <alex-weej> if i'm going to get anything positive out of this
[05:55] <jdong> sure, np
[05:55] <jdong> best of luck
[05:58] <alex-weej> w00t burnt
[06:10] <alex-weej> \o/
[06:54] <towsonu2003> hi
[06:58] <Mithrandir> keescook: please just upload; we haven't cared about security problems for milestones traditionally, since people have to update for those later in the cycle anyway.
[07:53] <pitti> Good morning
[07:54] <orkid> good night :)
[07:54] <orkid> 2am
[07:54] <Mithrandir> morning, Martin
[07:54] <orkid> est
[08:00] <Hobbsee> hey pitti, Mithrandir 
[08:01] <Mithrandir> good morning, Sarah
[08:01] <Hobbsee> :)
[08:02] <Mithrandir> *bounce*
[08:03] <StevenK> Oh, wait, it's already broken.
[08:04] <Hobbsee> Mithrandir: why bounce?
[08:05] <Mithrandir> Hobbsee: because bouncing is good.  Just general happiness
[08:06] <Hobbsee> Mithrandir: ahh :)
[08:29] <Burgundavia> pitti: regarding testing: hwdb.mandriva.com
[08:29] <pitti> hi Burgundavia 
[08:30] <Burgundavia> found it today
[08:30] <pitti> Burgundavia: wow, they seem to do a lot
[08:31] <Burgundavia> no idea as to the age or veracity of the testing data
[08:41] <Burgundavia> Mithrandir: herd 1 today?
[08:41] <Burgundavia> your today, I mean
[08:42] <fabbione> Mithrandir: OMG.. AWTY?
[08:43] <Hobbsee> what's the status of herd 1?  are the latest daily images correct?
[08:44] <Mithrandir> Burgundavia: are you subscribed to ubuntu-devel-announce?
[08:44] <Hobbsee> er...where are daily images?
[08:45] <Mithrandir> Hobbsee: no, there are no images yet.
[08:45] <Burgundavia> Mithrandir: yes
[08:45] <Hobbsee> right
[08:47] <Mithrandir> Burgundavia: I guess you saw my email to the list at 12:28 UTC yesterday.  There's nothing which has changed from when that was sent.
[08:50] <Burgundavia> Mithrandir: thanks
[08:56] <dholbach> good morning
[08:57] <Hobbsee> hey dholbach 
[08:57] <_ion> Hi
[08:57] <ailean> lo
[08:57] <dholbach> heya Hobbsee, hey _ion, hey ailean
[08:59] <dholbach> cjwatson, mjg59, keybuk: it'd be nice if somebody of you could have a look at https://blueprints.launchpad.net/distros/ubuntu/+spec/motu and https://blueprints.launchpad.net/distros/ubuntu/+spec/code-review
[09:27] <seb128> morning
[09:32] <Hobbsee> Mithrandir: when does feisty unfreeze?  any eta on when it ends?  we've got a new koffice which has been released yesterday, but packages were made by Riddell last week.
[09:32] <Mithrandir> Hobbsee: when herd 1 is out
[09:33] <Hobbsee> well, duh, i meant the eta on when that is
[09:33] <Mithrandir> hopefully today.
[09:33] <Mithrandir> as announced on ubuntu-devel-announce.
[09:33] <Hobbsee> right
[09:37] <Mithrandir> Hobbsee: it'd just end up in unapproved which gets shoved into feisty when we unfreeze, so it doesn't really matter for me.
[09:37] <cjwatson> sfllaw: there should be a mail sent to dapper-changes@ when something's accepted into -proposed
[09:45] <sfllaw> cjwatson: Do people subscribe to dapper-changes?  And what about edgy?  And is this to keep a record because -changes@ is archived?
[09:48] <cjwatson> yes, people do
[09:48] <cjwatson> particularly those who were around when dapper was in development ;-)
[09:48] <cjwatson> edgy-changes@
[09:48] <cjwatson> all uploads go to the -changes lists, and yes, it's both to keep a record and for convenience of those following along
[09:52] <fabbione> sfllaw: still awake?
[09:53] <Burgundavia> sfllaw: -changes is very useful for the UWN and other marketing stuff, not to mention all the development work
[09:53] <Burgundavia> sfllaw: we should talk about getting greater visibility on -proposed
[10:04] <Tonio_> hi
[10:05] <Mithrandir> wow, none of the ubuntu live images were oversized.
[10:05] <ailean> why would they be oversized?
[10:06] <fabbione> Mithrandir: !
[10:07] <cjwatson> ailean: because we've been doing this for 2+ years and they usually are at first :-)
[10:10] <Hobbsee> Mithrandir: can you poke me for kubuntu images, and i'll try to find some testers in Riddell's absense?
[10:11] <ailean> cjwatson, fair enough :) I don't know enough about it obviously . . .
[10:11] <Mithrandir> Hobbsee: yeah, the ubuntu images just need to finish building first.
[10:12] <Hobbsee> Mithrandir: of course :)
[10:12] <ailean> are they building now?
[10:12] <ailean> i.e. is the installer fixed?
[10:13] <cjwatson> desktop should be there-ish, alternate not yet
[10:13] <cjwatson> still working on that; the d-i build system hates me
[10:13] <ailean> cool
[10:13] <gnomefreak> cjwatson: i was told to ask you about ndiswrapper making it into default install. i was told you were working on it?
[10:13] <Mithrandir> cjwatson: ok, so I should just cancel alternate, then?
[10:13] <cjwatson> gnomefreak: huh?
[10:13] <cjwatson> Mithrandir: correct
[10:13] <ailean> i'm dying to get my hands on a safe-ish feisty
[10:14] <cjwatson> gnomefreak: ndiswrapper in default install => crack as far as I'm concerned
[10:14] <Mithrandir> Hobbsee: kubuntu live images building.
[10:14] <cjwatson> it's in ship
[10:14] <gnomefreak> cjwatson: oh?
[10:14] <Hobbsee> Mithrandir: way cool :)
[10:14] <Hobbsee> ailean: feisty isnt safe :P
[10:14] <cjwatson> it's there if you want/need to install it. I don't think it should be there by default.
[10:14] <ailean> in ship?
[10:15] <Hobbsee> cjwatson: seems like there are a lot of people who dont understand that they can install it from the cd though.
[10:15] <Hobbsee> ailean: well, when it's released it will be
[10:15] <gnomefreak> cjwatson: ok the concern was alot of people i ran into the last few releases wanted it because its needed for net connection for some users
[10:15] <cjwatson> ailean: set of packages on the CD but not installed by default
[10:15] <cjwatson> gnomefreak: that's why it's on the CD.
[10:15] <cjwatson> Hobbsee: I am not convinced that the difficulty of installing a package off the CD exceeds that of setting up ndiswrapper
[10:15] <gnomefreak> i knew it was on alt. didnt know if desktop had same
[10:15] <Hobbsee> gnomefreak: you'd have the trouble that you cant support absolutely all cards, and distribute all the drivers on the cd.
[10:16] <Hobbsee> cjwatson: i know.  i've had to run ndiswrapper for ages in the past.  it seems to be a user misunderstanding problem
[10:16] <cjwatson> gnomefreak: it's in ship-live too, which serves the same function for desktop
[10:16] <gnomefreak> Hobbsee: oh i agree i had just asked sabdfl on behalf of alot of users the other day in "ask mark"
[10:17] <gnomefreak> ok ty i will let the users know they dont need to download it from p.u.c anylonger
[10:17] <cjwatson> sabdfl tends to punt that sort of thing to me :) but it's not accurate to say that I'm working on it, because I already consider the issue closed
[10:17] <gnomefreak> ok :)
[10:17] <Hobbsee> heh
[10:21] <Mithrandir> Hobbsee: the images built, but they're called edgy; I'm rebuilding ubuntu, then kubuntu images, but people should able to start rsyncing them already.
[10:22] <Hobbsee> Mithrandir: okay.  i dont think we're redoing edgy :P
[10:22] <ailean> http://cdimage.ubuntu.com/daily-live/current/?
[10:23] <Mithrandir> ailean: yes.
[10:23] <Mithrandir> Hobbsee: as long as people rename the images, the .2 ones should sync really quickly.
[10:24] <Hobbsee> ok
[10:28] <hunger> How do I shut up mdadm's warnings when running update-initramfs? I removed that CONF-UNCHECKED file, now it bitches about there being no entries in my config file.
[10:29] <gnomefreak> hunger: i was gonna try removing it but im scared to :)
[10:30] <hunger> I do not use it... I can not dpkg --purge mdadm either since something depends on it.
[10:31] <hunger> Damn... I'll have to use LP again:-(
[10:32] <_ion> I like it more than bugzilla.
[10:33] <gnomefreak> Lp is fun :)
[10:35] <ajmitch> evening
[10:38] <hunger> gnomefreak: Not really... I manage to write bugreports and respond to changes, but I can not add any new info since I won't find my old reports anymore.
[10:39] <gnomefreak> hunger: go to your Lp page click on bugs than click on either reported or subscribed you can search for rejected fix released or whatever once in there
[10:39] <cjwatson> hunger: https://launchpad.net/people/hunger/+reportedbugs
[10:40] <hunger> Ah, there they are! Sorry, I am too stupid for LP:-(
[10:40] <Hobbsee> Mithrandir: do you have a copy of the syntax used for rsync?  the stuff on the wiki doesnt seem to be working.  
[10:40] <cjwatson> Hobbsee: what wiki page?
[10:40] <Hobbsee> "rsync -Lvv --progress rsync://cdimage.ubuntu.com/kubuntu/daily-live/current/edgy-desktop-i386.iso" doesnt seem to work
[10:40] <Hobbsee> https://help.ubuntu.com/community/RsyncCdImage
[10:40] <cjwatson> KILL
[10:40] <cjwatson> I'll fix
[10:40] <Hobbsee> thanks :)
[10:41] <cjwatson> Hobbsee: er, no, the wiki's correct, but you broke it ;)
[10:41] <cjwatson> Hobbsee: the /cdimage after cdimage.ubuntu.com is important.
[10:41] <Hobbsee> cjwatson: ie: rsync -Lvv --progress rsync://cdimage.ubuntu.com/kubuntu/daily-live/current/edgy-desktop-i386.iso
[10:41] <Hobbsee> argh
[10:41] <cjwatson> no, rsync://cdimage.ubuntu.com/cdimage/kubuntu/...
[10:42] <cjwatson> rsync doesn't do virtual hosting in the protocol so it has to be done by hand
[10:42] <Hobbsee> rsync -Lvv --progress rsync://cdimage.ubuntu.com/cdimage/kubuntu/daily-live/current/edgy-desktop-i386.iso .
[10:42] <Hobbsee> *that* appears to work!
[10:43] <Hobbsee> thanks cjwatson :)
[10:43] <cjwatson> we can't build proper feisty CDs until d-i works, unfortunately
[10:43] <Hobbsee> cjwatson: ahhh, hence hte lack of alternate.  
[10:44] <Hobbsee> fabbione: it wont find fisty :P
[10:44] <fabbione> Hobbsee: really? :P
[10:45] <Hobbsee> fabbione: well, unless you've changed it so it does :P
[10:45] <cjwatson> Hobbsee: also the lack of feisty desktop; there are bits of the build process that require files delivered by d-i even for desktop builds
[10:45] <Hobbsee> cjwatson: what are the plans for herd 1 then?  release without a d-i?
[10:46] <cjwatson> Hobbsee: no, we can't do herd 1 until d-i is available
[10:46] <Hobbsee> ah
[10:46] <cjwatson> at all
[10:46] <cjwatson> the edgy-desktop-* builds only worked because they were built as edgy by accident
[10:46] <Hobbsee> ahhhh
[11:18] <cjwatson> Mithrandir: I'd like to upload zlib to remove zlib1g's conflicts/replaces with zlib1g-udeb, since they're unnecessary and make it hard to convince d-i to build locally. Any objections?
[11:18] <Mithrandir> cjwatson: go ahead.
[11:19] <Mithrandir> cjwatson: feel free to accept it yourself too
[11:20] <cjwatson> it would probably have got past that on the buildds anyway, but I need to be able to test this locally since I'm sure it will fail somewhere else if I just upload d-i
[11:25] <apossebom> anybody know if lvm can work equals raid0 ?
[11:28] <Seveas> apossebom, #ubuntu for support
[11:29] <apossebom> Seveas, thx
[11:34] <fernando> moin all
[12:08] <sivang> morning
[12:23] <seb128> where should bugs like "wake from hibernate with broken xorg rendering" be assigned?
[12:23] <seb128> bug #73781
[12:23] <Ubugtu> Malone bug 73781 in gnome-session "unable to get out of "hibernate"-mode" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73781
[12:23] <seb128> by example
[12:34] <cjwatson> woo, that zlib change helped a lot
[12:40] <ogra> edubuntu-desktop seems installable as well :) 
[12:41] <vernes> I made an XWindow App. If I kill it and start too soon, I get A Segmentation fault (core dumped) message. I run the app on Ubuntu 6.10 on a 64-bit system. Where should I start looking for the cause?
[12:43] <fabbione> vernes: is your app threaded?
[12:43] <dholbach> it'd be nice if somebody with approval powers could have a look at https://blueprints.launchpad.net/distros/ubuntu/+spec/motu and https://blueprints.launchpad.net/distros/ubuntu/+spec/code-review
[12:44] <vernes> fabbione: Just the one program, I disabled any processes that run their own thread.
[12:44] <fabbione> vernes: install a few tons of debugging libs and run it in gdb
[12:46] <vernes> fabbione: And gdb is? one of the tons of debugging libs?
[12:46] <Hobbsee> yes
[12:46] <fabbione> vernes: well if you want to develop software you need to know your tools.. apt-get install gdb and look at the manpage
[12:46] <fabbione> vernes: and look for libx*-dbg packages
[12:46] <cjwatson> BenC: can I have nic-firmware udebs back, please?
[12:47] <fabbione> vernes: other than that.. the rest is off-topic here
[12:51] <cjwatson> vernes: also consider valgrind
[01:13] <cjwatson> Mithrandir: d-i uploading in a moment. works on powerpc (fakeroot make -C build all_build, anyway), but no idea about other architectures.
[01:14] <cjwatson> and by "works" I mean "builds"
[01:14] <StevenK> cjwatson: We call that "lightly tested" at work. :-)
[01:14] <cjwatson> heh
[01:14] <infinity> "production-ready"
[01:15] <cjwatson> once d-i builds, the hardest bit is over ...
[01:15] <infinity> Any bugs thereafter can be addressed with updates.
[01:36] <Mithrandir> cjwatson: any reason you didn't accept d-i yourself?  (I can do it now, sure)
[01:41] <Mithrandir> (or rather, you beat me to it, I think)
[01:43] <ailean> ISO working now with installer then?
[01:47] <Mithrandir> no, the binaries need to be built and published, then I can build ISOs
[01:47] <sivang> hmm, when are we going to have the moderated devel list?
[01:49] <Hobbsee> sivang: the sooner the better.
[01:49] <Hobbsee> but then again, people can then whine about "but we couldnt participate on the list"
[01:49] <sivang> Hobbsee: yes, but I just wanted to see how more will I have to suffer this terrible offtopic spam look alikes threads.
[01:49] <Hobbsee> heh
[01:49] <Hobbsee> and asking for donations.
[01:50] <sivang> and reading about local ubuntu conspiracies ;)
[01:50] <_ion> sivang: :-)
[01:52] <sivang> hi pitti 
[01:52] <pitti> hi sivang 
[01:52] <Hobbsee> heh, that too
[01:52] <Hobbsee> hey pitti 
[01:52] <\sh> local ubuntu conspiracies?
[01:54] <caccolangrifata> hi all
[01:54] <ailean> hey pitti, thanks for getting my Scots bug sorted
[01:54] <pitti> ailean: I didn't add the package yet, but it's easy, will happen soon
[01:55] <pitti> ailean: today is spec juggling day, sorry :)
[01:55] <ailean> pitti, i know, but you're the first person to recognise it. i don't care as long as it happens at some point :)
[01:55] <ailean> pitti, i thought it was being ignored
[01:56] <ailean> pitti, the other one I put in was to change "Scots Gaelic" to "Scottish Gaelic".  I don't know how trivial that is since it affects many packages...
[01:56] <cjwatson> Mithrandir: I did beat you to it, yes
[02:11] <_ion> I began writing a https://wiki.ubuntu.com/XInputHotplug spec by producing some use cases. If anyone (especially someone who knows more about the internal workings of the implementation) wants to help writing the spec, it would be appreciated.
[02:35] <tepsipakki> d-i failed to build
[02:35] <tepsipakki> :)
[02:36] <tepsipakki> on i386 and sparc
[02:36] <tepsipakki> E: Couldn't find package cdrom-modules-2.6.19-7-386-di
[02:37] <Hobbsee> cjwatson: will be very pleased, i'm sure
[02:37] <tepsipakki> E: Couldn't find package nfs-modules-2.6.19-7-sparc64-di
[02:42] <Mithrandir> tepsipakki: we're quite able to read log files ourselves, thankyouverymuch.
[02:43] <cjwatson> tepsipakki: Mithrandir already pointed that out to me
[02:43] <cjwatson> d-i failing to build does not surprise me
[02:44] <cjwatson> nor does it particularly distress me at this point
[02:44] <Nafallo> hmm, netboot on usb stick sounds nice :-)
[02:49] <cjwatson> tepsipakki: note, by the way, that I get mailed about this already
[02:49] <cjwatson> Nafallo: it's been there since, um, hoary or something
[02:50] <Nafallo> ah, haven't noticed :-)
[02:52] <Mithrandir> _ion: regarding XInputHotplug: while keyboards _can_ tell their layout, they don't in practice.
[02:53] <cjwatson> and even if they did it's not useful
[02:53] <cjwatson> the USB keyboard detection spec is hopeless
[02:55] <cjwatson> the number of registered keyboard codes is pathetically fewer than the actual number of keyboard types we support, and the keycode description stuff is dire. Markus Kuhn has a short rant about it somewhere
[02:58] <gicmo> seb128: hey hey
[02:58] <gicmo> dholbach: ALTER
[02:59] <dholbach> gicmo: ALTER :-)
[02:59] <gicmo> ;-D
[03:08] <_ion> mithrandir: That's just an example. If a keyboard doesn't support it, its layout can be configured. AFAIK with the input hotplug implementation, keyboard-specific layouts are or will become possible.
[03:09] <zul> hey
[03:10] <_ion> mithrandir: The generic point is that the events from input devices aren't aggregated to a single device such as /dev/input/mice anymore, but X receives the events from each device separately. That allows X to support everything they're capable of with minimal configuration.
[03:10] <Mithrandir> _ion: it's an useless usecase given that no keyboards support it.
[03:10] <Mithrandir> _ion: I know what the respecleration stuff is; no need to tell me
[03:11] <seb128> dholbach: hey :)
[03:12] <dholbach> heya seb128
[03:12] <seb128> ups
[03:12] <seb128> gicmo: hey :)
[03:13] <cjwatson> _ion: it's too expensive for keyboard manufacturers to actually bother using that field in the HID spec.
[03:13] <cjwatson> _ion: http://lists.freedesktop.org/archives/xorg/2004-August/002472.html
[03:17] <_ion> mithrandir: I updated the use case, thanks.
[03:32] <seb128> go go go gicmo ;)
[03:32] <gicmo> ;-D
[03:32] <dholbach> can somebody of the TB approve  https://blueprints.launchpad.net/distros/ubuntu/+spec/motu  and  https://blueprints.launchpad.net/distros/ubuntu/+spec/code-review ?
[03:33] <seb128> grumpf
[03:34] <dholbach> seb128: hm, what's wrong?
[03:34] <seb128> is the wiki doing highlight when clicking on a search result actually useful to somebody?
[03:34] <seb128> I hate it doing that
[03:34] <dholbach> not that often
[03:34] <seb128> can I change it somewhere? ;)
[03:34] <seb128> I'm not good are remembering pages so I use the search entry all the time
[03:34] <seb128> and I get things I don't care highlighted every time :p
[03:34] <seb128> like "patch" for https://wiki.ubuntu.com/MOTU/School/PatchingSources?highlight=%28patch%29
[03:42] <seb128> dholbach: do you know if there is an user preference or something to change that?
[03:43] <dholbach> seb128: no, not really
[03:44] <seb128> ok, thanks anyway ;)
[03:44] <seb128> where would be the place to discuss changing that option for the wiki?
[03:46] <dholbach> seb128: asking newz2000?
[03:46] <seb128> ok
[03:51] <LarstiQ> seb128: I really really want that too.
[03:53] <Nafallo> seb128: ACK. I want that to :-).
[03:53] <LarstiQ> seb128: there doesn't seem to be a user preference for it though. Wiki-wide it should be doable, but then people who actually want the highlighting might miss it.
[03:53] <seb128> do anybody want that?
[03:54] <seb128> you usually look for a page
[03:54] <seb128> not for all the words in that page
[03:54] <seb128> like when I look for compiz that's to get a page on getting compiz running
[03:54] <seb128> I don't want to highlight every instance of the word
[03:54] <LarstiQ> with google I sometimes like that behaviour, but on the wiki, I never do.
[03:57] <BenC> cjwatson: Yeah
[04:08] <pitti> hi sbalneav
[04:09] <sbalneav_> Hey pitti!
[04:09] <sbalneav> How's it going?
[04:09] <pitti> sbalneav_: pretty well, and you?
[04:09] <sbalneav_> How'd I get in twice?
[04:09] <sbalneav_> Hmm, an imposter appears
[04:09] <cjwatson> Mithrandir: do you care about sparc for herd 1?
[04:10] <sbalneav> That Balneaves, always *such* a troublemaker.
[04:11] <seb128> pitti: about your mail, ENOPATCHATTACHED
[04:11] <pitti> seb128: ugh
[04:13] <pitti> seb128: sent, sorry
[04:13] <seb128> pitti: np ;)
[04:13] <seb128> pitti: I'm considering enabling apport for GNOME for feisty now, any objection?
[04:14] <seb128> pitti: I might turn it off again in 1 week if we get too many bugs, but I would like to make a round of "get good debug backtraces for upstream" ;)
[04:14] <pitti> seb128: of course not, but we might not get the db for feisty
[04:14] <pitti> seb128: I'm honoured :)
[04:15] <pitti> seb128: yesterday I worked on the CrashReporting spec again, but it's not finished yet
[04:19] <ogra_> Mithrandir, what about an edubutu build so i can see how it looks like ? seems the ubuntu alternate build is good
[04:19] <ogra_> (good from a log POV)
[04:35] <cjwatson> ogra_: no, it's really not
[04:35] <cjwatson> ogra_: we were only actually ready as of the publisher run that just finished
[04:37] <ogra_> oh, well, the build logs look fine and report.html was also ampty
[04:37] <ogra_> *empty
[04:38] <dholbach> Keybuk: do you think you'll have some time to take a look at the code-review or motu spec?
[04:42] <iwj> mvo: Would you care to read and hopefully approve https://blueprints.launchpad.net/distros/ubuntu/+spec/gnome-app-install-codecs ?
[04:43] <iwj> seb128: Thanks.
[04:43] <bddebian> Howdy
[04:43] <mvo> iwj: certainly
[04:44] <seb128> iwj: np!
[04:44] <cjwatson> ogra_: note how the log is under a directory called "edgy" ;-)
[04:45] <cjwatson> ogra_: all feisty builds failed until about twenty minutes ago
[04:45] <cjwatson> Mithrandir: Ubuntu desktop and alternate building now
[04:45] <cjwatson> with any luck ...
[04:47] <iwj> cjwatson: Were you in the udev-lvm bof ?  Do you fancy approving https://launchpad.net/distros/ubuntu/+spec/udev-lvm which mdz doesn't seem to have had time to get around to ?
[04:47] <iwj> (Or doesn't it tell you when a spec you're approver for goes to pending approval?)
[04:53] <vdepizzol> where is disks-admin in edgy???
[04:54] <thom> this is not a support channel
[04:55] <Nafallo> #ubuntu are though
[04:56] <vdepizzol> I know... I just want to know why there isn't anymore disks-admin in edgy... Ubuntu Edgy can mount everything automatically?
[04:57] <vdepizzol> thank's
[05:05] <Keybuk> dholbach: motu, I'd prefer it if it made clear that while the MOTU Council will attempt to resolve things within the MOTU, avoiding referral to the TB and CC, that is still an option and the people involved may choose to go directly to the higher boards
[05:05] <Keybuk> ie. their powers aren't delegated, and greyskull's role is informal (or at least formally lesser)
[05:05] <Keybuk> in particular that anything involving those outside of the MOTU needs to go to the TB or CC directly
[05:09] <Keybuk> code-review is ok, find another TB member for final approval
[05:12] <dholbach> Keybuk: thanks
[05:13] <mvo> iwj: the GnomeAppInstallCodecs looks fine, you may want to add yourself to the contributors though :)
[05:13] <mvo> iwj: and the creation date looks wrong, but those are really minor points, I will approve it
[05:23] <cjwatson> iwj: yeah, it does tell you. I'll take it over
[05:23] <iwj> cjwatson: Thanks.
[05:24] <iwj> mvo: Thanks.  I've deleted those bits.  I never did like people's habit of putting all that metajunk at the top.  Dates and contributors and status and what-have-you can be found in the wiki history and in LP.
[05:24] <cjwatson> just need to inhale replacement-initscripts first
[05:24] <iwj> Hah.  (Should I be reading that?)
[05:25] <cjwatson> more readers wouldn't hurt
[05:25] <cjwatson> though it's basically a giant graph
[05:27] <cjwatson> Keybuk: you've reversed udev and mountdevsubfs in your graph; was that intentional?
[05:27] <cjwatson> Keybuk: oh, that's in the rationale, never mind
[05:28] <cjwatson> Keybuk: why does that make maintenance easier?
[05:31] <cjwatson> Keybuk: is it possible that people are relying on the way procps currently comes after module-init-tools? e.g. adding sysctls that are provided by modules?
[05:32] <cjwatson> hmm, that's probably a bug in pcmciautils - it uses something in /usr as a fallback
[05:32] <Keybuk> cjwatson: principally because we mount /dev in two places, and that reduces it to one
[05:33] <cjwatson> Keybuk: where should brltty go?
[05:33] <Keybuk> under udev, I omitted that because it's all in heno's spec
[05:33] <Keybuk> and is disabled in the boot sequence
[05:34] <cjwatson> Keybuk: I'm not sure this really captures updating mtab for the stuff that's mounted before the root filesystem is mountable; at the moment that's done in S22mtab.sh
[05:34] <cjwatson> s/mountable/writable/
[05:34] <cjwatson> maybe worth mentioning that
[05:35] <cjwatson> brltty> ok
[05:35] <cjwatson> well, actually, no
[05:35] <cjwatson> it can't always be started by udev
[05:35] <cjwatson> not all braille terminals are detectable
[05:36] <cjwatson> anyway, that's minor WRT this spec
[05:36] <Keybuk> I stress to point out that the graph is just intended to be a "here's what I'm going to try first"
[05:36] <Keybuk> does the spec not make that clear?
[05:36] <Keybuk> it'll take about 6 months to figure out all the problems and get the graph right :)
[05:36] <cjwatson> it does say it's a draft, but I feel free to nitpick drafts in specs :)
[05:36] <Keybuk> heh
[05:37] <cjwatson> there's no mention of md/lvm/etc. there which seems vaguely important
[05:37] <cjwatson> or is that in the udev-* specs? I haven't got to those yet
[05:37] <Keybuk> that's all in the udev-* specs
[05:38] <iwj> The use of `started' and `stopped' in those boxes is very confusing.  I can see the intent but it would be nice if you would clarify it.
[05:38] <cjwatson> the emergency console at present is only fatal if it's the root filesystem that failed its check. Will it be possible to return to the boot sequence if it's a non-root filesystem?
[05:38] <iwj> Also, I'm worried that you might be missing some dependencies which were previously expressed implicitly by the initscript ordering.
[05:38] <Keybuk> cjwatson: I'd argue the loss of /usr is fatal :)
[05:39] <iwj> For example, in theory your system could attempt to start various multiuser daemons with the hostname unset and no lo interface.
[05:39] <iwj> (Although in practice that doesn't seem likely, it is a race.)
[05:39] <cjwatson> it seems to me that there could do with being an explicit separation of the root filesystem in there
[05:39] <cjwatson> because a writable root is needed for various other rcSish things
[05:40] <cjwatson> Keybuk: without /usr, you can still use the stuff on / to recover /usr in a slightly more comfortable environment (e.g. multiple VTs)
[05:40] <Keybuk> cjwatson: we don't make any distinction between root and /usr in the current rcS
[05:40] <cjwatson> Keybuk: checkroot vs. checkfs?
[05:40] <Keybuk> cjwatson: they're immediately after each other
[05:41] <cjwatson> lrwxrwxrwx 1 root root  22 2006-05-25 15:33 S20checkroot.sh -> ../init.d/checkroot.sh
[05:41] <cjwatson> lrwxrwxrwx 1 root root  17 2006-07-16 09:08 S22mtab.sh -> ../init.d/mtab.sh
[05:41] <cjwatson> lrwxrwxrwx 1 root root  16 2006-05-25 15:51 S25brltty -> ../init.d/brltty
[05:41] <cjwatson> lrwxrwxrwx 1 root root  20 2006-05-25 15:46 S25mdadm-raid -> ../init.d/mdadm-raid
[05:41] <cjwatson> lrwxrwxrwx 1 root root  13 2006-05-25 15:46 S26lvm -> ../init.d/lvm
[05:41] <cjwatson> lrwxrwxrwx 1 root root  14 2006-05-25 15:48 S27evms -> ../init.d/evms
[05:41] <Keybuk> brltty is a long-standing bug
[05:41] <cjwatson> lrwxrwxrwx 1 root root  20 2006-05-25 15:33 S30checkfs.sh -> ../init.d/checkfs.sh
[05:41] <Keybuk> mdadm, lvm, evms are going into udev rules
[05:41] <cjwatson> also, the handling of failures *is* different in checkroot and checkfs
[05:42] <jdong> kinda related but OT question... but does evms need to start on systems without evms volumes?
[05:42] <jdong> it's a bit time consuming...
[05:42] <cjwatson> jdong: guess why evms isn't in standard any more ..
[05:42] <jdong> oh it isn't?
[05:42] <jdong> must not have noticed :)
[05:43] <cjwatson> Keybuk: also we do need to wait for just / to be writable in order to write /etc/mtab for the other filesystems
[05:43] <Keybuk> cjwatson: would the spec be easier to approve if I just removed the draft graph entirely, and left it as "here's how I intend to figure all this out" ?
[05:43] <cjwatson> but I guess that's too fine detail for the graph
[05:43] <Keybuk> otherwise we're getting into bikeshed territory, where every draft will have some error for the next 6 months
[05:43] <cjwatson> Keybuk: no, I wasn't intending to block on the graph being perfect, and I do think it's useful for it to be in there
[05:43] <cjwatson> Keybuk: at the same time I think it's valid to try to correct errors early on
[05:44] <Keybuk> cjwatson: checkroot vs. checkfs ... both start sulogin with the same mssage if fsck fails ... ?
[05:45] <cjwatson>                 log_warning_msg "A maintenance shell will now be started.
[05:45] <cjwatson> CONTROL-D will terminate this shell and restart the system."
[05:45] <cjwatson> log_warning_msg "A maintenance shell will now be started.
[05:45] <cjwatson> CONTROL-D will terminate this shell and resume system boot."
[05:45] <Keybuk> oh
[05:45] <Keybuk> that message is wrong <g>
[05:45] <Keybuk> the reboot doesn't work in edgy
[05:45] <cjwatson> it matches the code
[05:45] <Keybuk> it just gets ignored
[05:45] <cjwatson> ah, that's the bug, not the message :)
[05:45] <Keybuk> never really worked out why it needed to reboot, tbh
[05:46] <cjwatson> Keybuk: so I think it would be useful if you mentioned in the spec that md/lvm/evms are handled by the corresponding udev specs, since that's a fairly obvious difference
[05:46] <Keybuk> ok
[05:46] <Keybuk> could you add a list of comments that need to be addressed to the bottom of the spec
[05:46] <cjwatson> not so worried about the rest
[05:46] <cjwatson> sure
[05:46] <Keybuk> as I won't have any time until tuesday to do it
[05:46] <Keybuk> and will have forgotten this conversation by then :)
[05:47] <cjwatson> in the "known bugs" section?
[05:47] <Keybuk> sure
[05:47] <ailean> is it a big deal that the cd images are oversized?
[05:47] <Keybuk> do you have any comments about the non-graph part of the spec?
[05:48] <Keybuk> if not, perhaps it is worth splitting them -- otherwise I'm in a situation where I have no approved spec this evening for the bulk of my feisty time
[05:53] <cjwatson> ailean: we have reports on that and will work on it
[05:53] <cjwatson> Keybuk: one sec
[05:53] <Mithrandir> cjwatson: sparc?  No, not very.
[05:54] <cjwatson> Keybuk: is there a spec for the upstart job syntax?
[05:55] <iwj> Keybuk: Did you see my comment about lurking undocumented dependencies ?
[05:55] <Keybuk> iwj: yes, noted
[05:55] <iwj> Err, OK.  What are you going to do about it ? :-)
[05:55] <Keybuk> cjwatson: no, tbh, I don't expect it to change much
[05:55] <Keybuk> iwj: will note it in the non-normative portion of the spec on tuesday
[05:56] <cjwatson> iwj: I noted your comment under "known bugs"
[05:56] <cjwatson> Keybuk: are you happy that the existing syntax is capable of expressing the sorts of dependencies iwj mentions?
[05:57] <Keybuk> I believe so
[05:58] <Keybuk> ian and I discussed more complicated arrangements which we don't need for feisty
[05:58] <cjwatson> ah yes, I see
[06:00] <iwj> cjwatson: Right. :-)
[06:04] <bluefoxicy> hmm
[06:04] <bluefoxicy> That happens all the time
[06:07] <jdong> bluefoxicy: set up a script to hammer archive.ubuntu.com :)
[06:09] <elmo> sure, and why don't you just send an email to the admins saying "blacklist my IP" while you're at it
[06:09] <highvoltage> heh
[06:09] <hunger> Is fglrx known to be broken on feisty?
[06:09] <jdong> ha! is fglrx broken... how can that happen?
[06:10] <hunger> jdong: Well, more broken then intended by ati.
[06:10] <jdong> hunger: idn, I booted a feisty kernel on edgy yesterday and it worked....
[06:10] <jdong> but that doesn't say much :D
[06:10] <bluefoxicy> jdong:  I'm more thinking
[06:10] <bluefoxicy> updates every 24 hours
[06:10] <bluefoxicy> nothing happens
[06:10] <bluefoxicy> One day, you actually get an update.
[06:10] <jdong> bluefoxicy: hmm, there is a built-in cronjob for 24 hour updates...
[06:10] <hunger> jdong: I can not even load the fglrx kernel module.
[06:10] <jdong> hunger: oh
[06:11] <bluefoxicy> So, an hour later, it checks again; if it doesn't get any security updates in both checks it sleeps.
[06:12] <bluefoxicy> When the user opens update manager, it recommends checking again (or can be configured to just do it, though this asks for a password)
[06:12] <hunger> jdong: Any idea how to get rid of:"insmod: error inserting '/.../fglrx.ko': -1 Operation not permitted"?
[06:14] <bluefoxicy> If it gets a new update, it starts a cycle where it checks in 1, then 2, then 4, then 8 hours, then goes back to regular cycle; if at any point it actually gets an update from the checks, the cycle resets
[06:14] <bluefoxicy> jdong:  useful on patch tuesday?  Or annoying on we-found-one-security-issue thursday?
[06:15] <bluefoxicy> (you could also randomize the checks so they time-shift by 50% to avoid sudden server anal rape)
[06:27] <cjwatson> Mithrandir: I've dropped a big pile of languages from live, if you want to regenerate the livefs and rebuild at some point
[06:47] <mdz> iwj: I sent an email to distro-team last week explaining about approvals
[06:47] <mdz> iwj: one of the points therein was that approvals currently assigned to me need to be done by someone else
[06:53] <iwj> mdz: Oh, sorry, I missed that.
[06:53] <iwj> Anyway, it's done now.  Thanks.
[06:56] <dholbach> Keybuk: who would you suggest to ask for TB approval of motu and code-review?
[06:57] <Keybuk> dholbach: either mjg59, mdz or sabdfl would do -- any two members, basically (I count as one)
[06:58] <dholbach> mjg59, sabdfl: If you have a moment and could check (and hopefully approve)  https://blueprints.launchpad.net/distros/ubuntu/+spec/motu  and  https://blueprints.launchpad.net/distros/ubuntu/+spec/code-review  that'd be great.
[07:04] <mdz> dholbach: I reviewed it and made a comment
[07:06] <dholbach> mdz: good point - i'll change that
[07:06] <mdz> dholbach: I suggest getting review from someone on the LP team as well
[07:06] <mdz> talk to steve or kiko
[07:07] <dholbach> Ok
[07:15] <mdz> cjwatson: the new console-setup clobbered my screen state during postinst; I had to switch VTs to get X usable again
[07:15] <Keybuk> likewise
[07:17] <mdz> Keybuk: filed bug 73955
[07:17] <Ubugtu> Malone bug 73955 in console-setup "Clobbered X screen state during installation" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73955
[07:29] <Ng> erk, mine just did that too
[07:32] <_ion> I posted a comment about "setupcon --force" being used a few minutes ago, but now i noticed setup-console.postinst in edgy also has --force and it doesn't break.
[07:32] <Keybuk> shouldn't setupcon be skipping graphical vts now?
[07:36] <_ion> Running 'consolechars -v --tty=/dev/tty1 -f /etc/console-setup/Lat15-VGA16.psf.gz' makes X break.
[07:37] <_ion> (The tty number doesn't matter)
[07:43] <lemsx1> is anybody working on ecryptfs for Ubuntu?
[08:57] <amnesia> so, hi :)
[08:58] <ailean> who are you again?
[08:58] <amnesia> someone who wants to make irda work in feisty out of the box ( seb128 already knows )
[08:59] <ailean> yeah, i'm sorry :) it's my wee joke
[08:59] <amnesia> doing some first steps now, will then need someone to do something with my packaged ircp-tray app
[09:00] <amnesia> and move it all to ubunto-desktop :)
[09:00] <amnesia> ubuntu*
[09:00] <amnesia> ailean: errm, okay :)
[09:00] <amnesia> haha then, I guess :)
[09:00] <ailean> amnesia? get it?
[09:00] <ailean> i make myself laugh, that's all that is important
[09:00] <amnesia> yeah, don't panic
[09:00] <ailean> hehe
[09:00] <bhale> guys
[09:01] <amnesia> bhale: sure, got it
[09:01] <bhale> amnesia: #ubuntu-motu for new universe packaging.
[09:01] <bhale> !revu
[09:01] <bhale> sigh
[09:01] <amnesia> :) it's okay
[09:01] <bhale> https://wiki.ubuntu.com/MOTU/Packages/REVU?action=show&redirect=REVU
[09:01] <bhale> new packages are uploaded here.
[09:12] <shawn_work> Question: does Edgy+ kernel built with CONFIG_KEXEC on the DVD/CD vmlinuz?
[09:20] <geser> fabbione: is it ok if I merge xchat (universe)?
[09:22] <fabbione> geser: uh why do you ask me?
[09:22] <geser> MoM lists you as the last uploader
[09:22] <fabbione> geser: it's universe.. just do it.. and make sure it will keep working or some MOTU's heads will be chopped off :P
[09:25] <keescook> so... when is the next TB meeting?  I need someone to sponsor my main upload of evince... http://people.ubuntu.com/~kees/feisty-uploads/
[09:39] <cjwatson> mdz: meh
[09:39] <cjwatson> mdz: that was supposed to not break now
[09:42] <shreeve> how do I find the name of the person packaging ipw3945 wireless drivers for xen on edgy???
[09:45] <zul> whats wrong?
[09:47] <shreeve> edgy's xen kernel module for ipw3945 wireless driver doesn't work
[09:47] <shreeve> spent a LONG time working on it...
[09:48] <zul> its probably not xen enabled
[09:48] <shreeve> the non-xen version (ie - "normal" edgy) works fine
[09:48] <shreeve> okay... is there a way to check?
[09:48] <zul> dont think so
[09:49] <shreeve> well... it *is* part of the xen package for edgy... seems like pretty bad form to get confused, no>?
[09:49] <shreeve> what's the 'dpkg' or 'apt-blah' command to see the package info?
[09:50] <zul> shreeve: no its apart of universe and we ran out of time to get it working sorry..
[09:50] <shreeve> whoa!
[09:50] <shreeve> you're the right guy to ask then, right?
[09:50] <shreeve> and that is the official answer?
[09:51] <shreeve> not good or bad, just wanna how i can work to resolve it
[09:51] <shreeve> that's awesome information to know if your the right person to ask tho'
[09:52] <Rumo_> 'apt-cache showpkg' is the command you're looking for
[09:52] <shreeve> thanks Rumo_
[09:53] <cjwatson> shreeve: dpkg -p or apt-cache show
[09:53] <cjwatson> (showpkg is more detailed, often not what you want)
[09:55] <shreeve> gotcha... looks like "apt-cache show" is also a superset of "dpkg -p"
[09:55] <shreeve> so... i'll use "apt-cache show" and "apt-cache showpkg"
[09:57] <cjwatson> right, apt-cache show looks in slightly different places but they wind up being more or less equivalent
[09:57] <cjwatson> (oh, dpkg -p prints what's available for installation, dpkg -s prints what's actually installed. apt-cache show prints both if they're different)
[10:09] <shreeve> zul - you mentioned that a xen-enabled ipw3945 (from universe) wasn't quite ready... any direction you could point me to learn about how to actually get it to run?
[10:10] <robertj> is canonical still sending out laptops for the laptop testing program as new hardware is released?
[10:10] <ajmitch> not afaik
[10:10] <ajmitch> sending out laptops was a one-off thing, I don't know if they intend to repeat it
[10:12] <zul> shreeve: unfortunately no
[10:12] <jdong> shreeve / zul: ipw3945 works fine in edgy xen
[10:12] <jdong> minus bridging
[10:12] <shreeve> jdong ???
[10:12] <shreeve> really?
[10:12] <jdong> symlink the daemon
[10:12] <shreeve> wha?
[10:12] <shreeve> how do i do that? what file?
[10:12] <jdong> /sbin/ipw3945d-2.6.17-10-generic to /sbin/ipw3945d-`uname -r`
[10:13] <jdong> when under your xen kernel
[10:13] <shreeve> f-ing kidding me!?
[10:13] <shreeve> really... that easy?
[10:13] <jdong> then rmmod and modprobe ipw3945
[10:13] <jdong> shreeve: yea that's what I did :D
[10:13] <jdong> it doesn't bridge though
[10:13] <shreeve> is this a known resolution? or is this jdong at 4:00am fixing it with some mountain dew and a keyboard?
[10:13] <jdong> shreeve: this is jdong being crazy at 4am ,yes
[10:13] <jdong> but it does work
[10:13] <shreeve> hahaha
[10:13] <jdong> minus bridging, as I've said
[10:13] <jdong> shreeve: if you get bridging working tell me :D
[10:14] <jdong> I suspect the regulatory daemon is not thrilled about packets going out with an unknown source MAC
[10:14] <shreeve> jdong - so, if it doesn't bridge... how do you access it... since doesn't even dom0 use the bridge??
[10:14] <jdong> shreeve: the card works fine in dom0
[10:14] <jdong> but as soon as you try to bring up a bridge you'll lose all networking
[10:15] <jdong> shreeve: looking at the xen mailing list it seems like it's a general issue with wifi and xen, not restricted to just the ip3945
[10:15] <shreeve> jdong - what about this, though:
[10:15] <shreeve> # To bridge network traffic, like this: 
[10:15] <shreeve> # 
[10:15] <shreeve> # dom0: fake eth0 -> vif0.0 -+ 
[10:15] <shreeve> #                            |
[10:15] <shreeve> #                          bridge -> real eth0 -> the network
[10:15] <shreeve> #                            |
[10:15] <shreeve> # domU: fake eth0 -> vifN.0 -+
[10:15] <shreeve> doesn't dom0 have to "go through" the bridge anyway?
[10:16] <jdong> shreeve: I've always attached dom0 directly to the real eth1
[10:16] <shreeve> can you show me what you do for that?
[10:16] <jdong> as soon as you throw in a fake adaptor you'll lose networking
[10:16] <jdong> shreeve: unfortunately, don't specify any bridging or vif scripts :-/
[10:16] <shreeve> so... do your domU's ever even get networking?
[10:16] <jdong> not currently
[10:16] <jdong> I'm still working on that part :D
[10:16] <shreeve> ah... okay.
[10:17] <zul> do you guys mind taking this to #ubuntu-xen
[10:17] <sladen> win 255
[10:17] <jdong> zul: will do, sorry
[10:17] <shreeve> zul: sorry, man
[10:19] <seb128> BenC: directfb is on your merge list, have you planned to work on it soon? I would like to ask for a sync of the new libcairo from Debian but it requires the new directfb version
[10:36] <uenyioha> hi guys!
[10:37] <uenyioha> is anyone aware of an irc channel for darwin
[10:37] <uenyioha> i know this is an ubuntu channel...i just seem to get the best answers to most of my questions from here
[10:37] <jdong> uenyioha: erm, that's a totally completely off topic question for here
[10:38] <uenyioha> yeah i know....i was just hoping someone knew an answer to it
[10:38] <uenyioha> thanks anyway
[10:40] <gnomefreak> uenyioha: ask in #ubuntu-offtopic
[10:40] <uenyioha> thanks
[10:47] <tepsipakki> Mithrandir, cjwatson: I hear you..
[10:48] <tepsipakki> for some reason i've been waiting for d-i like christmas
[10:48] <tepsipakki> d-i for feisty, that is ;)
[10:52] <cjwatson> it's not like it's guaranteed (or even all that likely) to work yet anyway ;)
[10:53] <tepsipakki> who cares, I'm happy just to boot it :)
[10:53] <tepsipakki> but that's left for next monday, anyway
[10:53] <tepsipakki> long weekend ahead
[10:54] <tepsipakki> ..away from work
[10:59] <BenC> seb128: I can, I didn't know it was on my list
[11:00] <seb128> BenC: http://merges.ubuntu.com/main.html
[11:00] <seb128> BenC: would be nice, thank you ;)
[11:18] <cjwatson> I wonder why the alternate build failed
[11:18] <cjwatson> Missing debootstrap-required tcpd
[11:18] <cjwatson> I didn't think that was possible ...
[11:19] <bluefoxicy> Downloading:  50 of 75
[11:20] <bluefoxicy> ........ apt-get update == net thrash
[11:20] <ogra> hmm i bootstrapped my fat-cient chroot ths morning, seemed ok there. or is that a different debootstrap ?
[11:20] <bluefoxicy> (that's all official edgy)
[11:20] <sfllaw> keescook, pitti: I presume you guys already know about the GPG buffer overflow.  CVE-2006-6169.
[11:20] <sfllaw> Bug 73985 is probably a duplicate of something in your system.
[11:20] <Ubugtu> Bug 73985 on http://launchpad.net/bugs/73985 is private
[11:21] <keescook> sfllaw: the security update went out yesterday.  :)
[11:21] <sfllaw> Well, I was certainly paying attention.
[11:21] <pitti> yeah, we suck at closing bugs for security stuff
[11:21] <pitti> since we don't really use Malone for security tracking yet
[11:21] <sfllaw> Ah.
[11:22] <sfllaw> Do you guys have anything formal for security testing?
[11:22] <pitti> sfllaw: not more formal, but more automatic :)
[11:22] <sfllaw> Shiny.
[11:22] <pitti> sfllaw: http://people.ubuntu.com/~pitti/ubuntu-cve/
[11:22] <pitti> sfllaw: ugly, but working
[11:22] <pitti> tracks stuff fully automatically from changelogs, archive information, and CVE db import
[11:23] <sfllaw> Do you ever need help testing fixes?
[11:23] <sfllaw> Or is the workload OK?
[11:23] <pitti> well, 'fully' -> with a manual override db, of course
[11:23] <cjwatson> ogra: er - useful data point but unlikely to be entirely indicative. the only way to work out what's going on is debugging directly on cdimage really
[11:23] <pitti> sfllaw: from my POV the trouble was mainly not knowing a package, less not having time to test it
[11:24] <pitti> sfllaw: i. e. I always have difficulties testing an openldap or a quagga security update
[11:24] <pitti> sfllaw: but these are excellent candidates for test suites, too
[11:24] <keescook> I pulled my hair out on the openldap update.
[11:24] <sfllaw> We actually have an openldap installation here in Montreal.
[11:24] <keescook> Next time I'll have the tests automated.
[11:24] <sfllaw> Fair enough.
[11:24] <ogra> cjwatson, thats what i suspected ... 
[11:24] <pitti> yeah, it's a pain to write the tests, but it decentralizes knowledge and in the end provides better testing, I hope
[11:25] <sfllaw> Do you guys also do general regression testing?
[11:25] <cjwatson> ogra: ah, it's just some incorrect priorities
[11:25] <sfllaw> To make sure you changes didn't break the package?
[11:25] <cjwatson> I'll fix those in the archive
[11:25] <cjwatson> (http://people.ubuntu.com/~cjwatson/jessica.txt)
[11:26] <pitti> sfllaw: not sure what you mean; we test exploits (when available) and we test for potential regressions that can be introduced by a patch
[11:26] <cjwatson> or, er, something went weird. tcpd *should* be in standard I think
[11:26] <pitti> sfllaw: but we do not test for regressions from dapper to edgy, or sth. like that
[11:26] <keescook> sfllaw: I try to test general (common) functionality, and then I try to test the code paths impacted by the update
[11:26] <ogra> cjwatson, pitti, the sshd cipher=none change isnt in ltsp-local-apps, but i know sbalneav and jammcq would very much appreciate it to be enabled in feisty so ltsp could drop xdmcp completely
[11:26] <sfllaw> pitti, keescook: OK, good enough.
[11:27] <tkamppeter> A big thank you to all laptop stuff developers at Ubuntu: I installed Edgy on the HP Compaq nc4200 and everything simply works: Suspend, Hibernate, battery level, even the help button and the volume buttons. Mandriva 2OO7 was a fight on this laptop. ACPI pulled all CPU, no Suspend no Hibernate, but nice #D Desktop (Compiz).
[11:27] <Ubugtu> Mandriva bug 2 in program "Warning messages appeared while loading xemacs" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2
[11:27] <pitti> tkamppeter: wow, great
[11:27] <cjwatson> ogra: yeah, I've already talked with them about it; it is a dubious change from my POV, and upstream has always refused it, so I need to investigate again
[11:27] <sfllaw> Yeha, you guys rock.
[11:28] <sfllaw> If only my T60p worked right.  :)
[11:28] <pitti> tkamppeter: the 'help' button really surprises me (although it's certainly the least important bit)
[11:28] <ogra> cjwatson, jammcq seemed to have the impression from a talk wih mdz that it would be trivial ...
[11:28] <cjwatson> ogra: he's wrong
[11:28] <ogra> i know
[11:28] <cjwatson> at least I'm pretty convinced about that
[11:28] <ogra> but thats how he took it to me
[11:28] <mdz> the change is trivial, it's just controversial
[11:28] <cjwatson> but, like I say, I need to read up on it again; it's been a while
[11:29] <cjwatson> I'm pretty sure it's not as trivial as it looks in SSH2
[11:29] <keescook> cjwatson: do you know when the next TB meeting is likely to be?  I want to make sure I'm there.  :)
[11:29] <mdz> in fact my understanding is that the code is there #ifdef'd out
[11:29] <cjwatson> keescook: /me <- not TB
[11:29] <cjwatson> mdz: (IIRC) because it's disallowed by the protocol
[11:30] <cjwatson> my memory is that "none" means "nothing selected" rather than "the null cipher selected"
[11:30] <cjwatson> but, as I say, need to check
[11:30] <sfllaw> mdz, pitti: Got a minute?
[11:30] <mdz> sfllaw: yes
[11:30] <pitti> sfllaw: yes
[11:30] <sfllaw> Let's hash out scalable-installation-testing.
[11:30] <mdz> I can survive on body fat and muscle tissue for that long before lunch
[11:30] <sfllaw> I'm going to agree to anything that fits in the feisty timeline.
[11:30] <keescook> cjwatson: ah, sorry.  you're on CC.  I need to bug mdz, it seems.  :)
[11:31] <sfllaw> So if you have a solution, mdz, to your concerns.  I'd be happy to write it in.
[11:31] <cjwatson> hmm, I think Scott bodged up the netbase merge
[11:31] <mdz> what I need is for it to be completely open participation, without a prerequisite of reading up on our processes before installation
[11:31] <pitti> sfllaw: the solution is pretty clear, it just involves some work
[11:31] <mdz> it should be feedback-driven, not test-driven
[11:31] <mdz> i.e., the user installs and then tells us what worked
[11:32] <mdz> rather than selecting a profile in advance and testing that
[11:32] <tkamppeter> pitti, one of the Ubuntu laptop developers seems to have exactly this notebook ..
[11:32] <pitti> sfllaw: i. e. we need to teach ubiquity to do a cdebconf-like logging, and then feed the d-i/ubiquity log to the web frontend, which can then categorize it and save the data
[11:32] <pitti> mdz: ^ that's what I understood from our previous discussion
[11:32] <mdz> it doesn't need to be the log, just a summary
[11:32] <mdz> which can be in a simple parseable format
[11:32] <pitti> mdz: well, just like cdebconf
[11:33] <mdz> pitti: more like the ubiquity summary screen data
[11:33] <cjwatson> full database-like output is not really all that trivial, but we can do like mdz says
[11:33] <pitti> mdz: i. e answers to all questions, in whatever format
[11:33] <cjwatson> pitti: the full database will give you a huge load of crap from the livefs
[11:33] <cjwatson> and not everything ubiquity does is asked via debconf
[11:33] <mdz> right, we're only interested in ubiquity's own parameters
[11:33] <cjwatson> so you kind of lose
[11:33] <pitti> I see
[11:33] <sfllaw> Does this extend to d-i as well?  And update-manager?
[11:33] <cjwatson> but we can do something similar if you don't require a debconf database as output
[11:33] <sfllaw> Do we care about this being automated?
[11:33] <mdz> given that, we should be able to easily run queries on the data to assess test coverage
[11:34] <sfllaw> Or can we just describe properties?
[11:34] <cjwatson> sfllaw: everything d-i does is via debconf
[11:34] <pitti> sfllaw: for upgrades it becomes tricky, I guess
[11:34] <cjwatson> sfllaw: update-manager not so
[11:34] <mdz> much more efficiently than the wiki page
[11:34] <sfllaw> Like "Paritioning hard disks"
[11:34] <sfllaw> Or "Installing boot loader"
[11:34] <mdz> and we'll benefit from all the coverage from informal testers
[11:34] <cjwatson> sfllaw: I don't understand; what about those?
[11:34] <mdz> sfllaw: extending it to update-manager is a great idea
[11:34] <mdz> sfllaw: though mvo is pretty busy for feisty
[11:35] <sfllaw> My concern is that we get something for Feisty.
[11:35] <sfllaw> And we need to be able to test upgrades and record them.
[11:35] <sfllaw> Can we use something that doesn't have to be driven automatically?
[11:35] <sfllaw> So instead of test cases that people follow...
[11:35] <pitti> it would rock if we could grab the dpkg --get-selection (or similar) before and after the upgrade
[11:35] <mdz> I think we'll get more out of the automated upgrade testing than automated user feedback for upgrades
[11:35] <sfllaw> We instead have properties that your automated tools can report succeeded?
[11:36] <mdz> but automated user feedback for installs will be a huge win, because we don't get enough from automation there and it's harder to automate
[11:36] <mdz> pitti: the status file
[11:36] <mdz> pitti: this is already how mvo's testing will work so we can try to replicate it
[11:36] <pitti> mdz: yeah, with some filtering to make it smaller
[11:36] <mdz> sfllaw: I don't follow
[11:36] <sfllaw> I don't see my proposal as being in contention with yours.
[11:37] <sfllaw> We define a series of properties that constitute a successful install.
[11:37] <sfllaw> Booted into the LiveCD.
[11:37] <sfllaw> Run ubiquity.
[11:37] <sfllaw> Pick a timezone.
[11:37] <sfllaw> Etc.
[11:37] <sfllaw> And we _could_ extract success from logs.
[11:37] <sfllaw> Or we could have people check off whether it worked or not.
[11:37] <mdz> that's precisely what I suggested
[11:37] <sfllaw> And if it didn't work, provide a bug number.
[11:38] <mdz> my other mumbling was about upgrade testing, which is a separate matter
[11:38] <pitti> sfllaw: yeah, just the spec currently says that the user has to select a predefined test case in the webui?
[11:38] <sfllaw> Well, upgrade testing is similar, if we can just have people run by hand.
[11:38] <sfllaw> And submit results bases on whether upgrade-manager worked properly or not.
[11:38] <mdz> it's similar, but it needs to be added to update-manager rather than ubiquity
[11:38] <mdz> it's additional development
[11:38] <sfllaw> What I'm saying is that you don't actually need to edit ubiquity or update-manager.
[11:39] <sfllaw> That's just a bonus if we have time.
[11:39] <mdz> and I fully support doing it, but installation is more important and so if we can only do one for feisty, it should be that
[11:39] <pitti> sfllaw: how else do you want to get the user's answers from ubiquity? parsing it's current log file is certainly not fun
[11:39] <mdz> making this a one-click operation in ubiquity will get us orders of magnitude more feedback than any manual approach
[11:39] <pitti> not to mention, subject to change
[11:40] <sfllaw> mdz: Sure.  But the manual approach is stil an order of magnitude better than the current one.
[11:40] <pitti> mdz: 'this an one-click thing' -> reporting install success? that's too early IMHO
[11:40] <sfllaw> And we need some manual override for passes.
[11:40] <sfllaw> Like the timezone dialog selector in GNOME Ubiquity is broken.
[11:40] <sfllaw> But Ubiquity could never tell us that.
[11:40] <mdz> the goal of this is to take advantage of "passive" testing by the community at large, and lower the barrier to entry for active testing
[11:40] <cjwatson> pitti: that can be fixed
[11:40] <cjwatson> pitti: and should be, I think
[11:41] <pitti> cjwatson: what do you mean?
[11:41] <mdz> pitti: right, not in ubiquity itself but integrated with it
[11:41] <mdz> ubiquity should arrange for the user to be notified when they login to report their installation success to us
[11:41] <pitti> cjwatson: I mean that giving feedback when ubiquity is still running is too early
[11:41] <sfllaw> mdz: I'm not against passive testing at all.  I just want to concentrate on getting the easy (web part) done first.
[11:41] <mdz> likewise for update-manager after the reboot
[11:41] <cjwatson> pitti: I'm disagreeing with sfllaw; while I suppose strictly you don't have to edit ubiquity to do this, it would be massively better if we did.
[11:41] <pitti> we cannot decide whether the isntall was a success before we actually booted the system
[11:41] <cjwatson> pitti: yes, I know
[11:41] <mdz> sfllaw: I think it's a similar amount of work either way
[11:41] <cjwatson> pitti: I mean improving ubiquity's logging to be more parseable
[11:41] <pitti> cjwatson: ah, ok; sorry, that was a misunderstanding
[11:42] <mdz> and we get much better price/performance from the integrated approach than the web form
[11:42] <sfllaw> mdz: I'm more concerned with user-visible problems, which we will throw away if we can't track them.
[11:42] <cjwatson> sfllaw: (not disagreeing with your point about the timezone dialog thing, although note that we're probably going to remove the set time... button for feisty; it's not worth the hassle it causes)
[11:43] <sfllaw> Unless cjwatson writes a huge test suite for Ubiquity.
[11:43] <cjwatson> (I mean not disagreeing with your general point about manual overrides for passes
[11:43] <cjwatson> )
[11:43] <mdz> sfllaw: user-visible problems should be filed in launchpad
[11:43] <cjwatson> well, I'd love to, and lifeless would love me to :)
[11:43] <sfllaw> But they need to be tracked by the release managers.
[11:43] <cjwatson> but time, as usual. will probably get done incrementally
[11:44] <cjwatson> ok, I think tcpd and libwrap0 have in fact legitimately fallen out of minimal. nat
[11:44] <sfllaw> Isn't the point of this spec to replace Testing/Current with something more useful?
[11:44] <cjwatson> neat
[11:44] <mdz> sfllaw: yes
[11:44] <sfllaw> mdz: I'd hate to see a regression from Testing/Current, which is super primitive.
[11:44] <cjwatson> now, what about x11-common ...
[11:44] <mdz> not to replace the milestone bug list
[11:45] <pedr0> hi!i need information for changed in GRUB loader the O.S.
[11:45] <sfllaw> mdz: So who puts stuff into the milestone bug list?
[11:45] <mdz> sfllaw: the same folks who do now
[11:45] <cjwatson> oh, cool, the x11-common pre-dep in xkb-data was just transitional in breezy
[11:45] <pedr0> what is the metod for setting the GRUB loader,i want change the priority of Operativ System
[11:46] <pedr0> ?
[11:46] <sfllaw> Am I misunderstanding the process by which a bug gets into the milestone bug list?
[11:46] <cjwatson> so I guess we can lose it now that dapper is officially the line in the sand
[11:46] <cjwatson> pedr0: #ubuntu for support, please
[11:46] <HrdwrBoB> pedr0: you want #ubuntu
[11:46] <mdz> sfllaw: I think we're talking about complementary parts of the problem
[11:46] <mdz> I'm talking about success reports, and you're talking about failure reports
[11:46] <sfllaw> Yes.
[11:47] <sfllaw> I don't care very much about successes.  I only care about failures.  When no failures occur, we're good.
[11:47] <sfllaw> False reports of success do us harm.
[11:47] <pitti> well, but successes are important
[11:47] <pitti> to see coverage
[11:47] <mdz> exactly
[11:47] <pitti> i. e. success reports, of course
[11:47] <mdz> currently our test coverage is limited
[11:47] <mdz> this lets us expand it
[11:48] <mdz> the process for reporting failures is pretty straightforward at present (bug reports)
[11:48] <mdz> reporting successes is a wiki-intensive operation in which practically no one outside of Canonical participates
[11:49] <cjwatson> Mithrandir: alternates should build better following the next publisher run
[11:49] <sfllaw> mdz: I am skeptical that providing success reports culled by a naive program is useful in determining proper coverage.
[11:49] <sfllaw> But I no longer want to argue this point.
[11:49] <mdz> a failure could be anything from a ubiquity crash to the system failing to boot entirely; I don't see how a web form to report failures does better than bug-reporting-tool for that
[11:50] <sfllaw> Because it lets us correlate where the failures are, from a limited scope, for installations and upgrades.
[11:50] <sfllaw> I.e. some comprehensible domain.
[11:50] <mdz> please explain
[11:50] <pitti> I agree with mdz that reporting bugs in particular apps should be kept out of installation reports
[11:51] <pitti> but things like 'ubiquity installed a system that failed too boot' is definitively an installer thing
[11:51] <pitti> and thus should be covered by the report
[11:52] <sfllaw> Just giving an overview of where installation bugs are.  Across architecture, installation media, etc.
[11:52] <sfllaw> Is Malone good enough for you guys?
[11:52] <mdz> if installation bug reports don't have enough data for installation bugs, we should address that
[11:53] <mdz> bug-reporting-tool provides the infrastructure to add detail to them
[11:53] <sfllaw> All right.  Then I have no further objections.
[11:54] <mdz> I understand your position now
[11:54] <pitti> so we replace the installation-feedback package with some bits that ubiquity puts into the user's session?
[11:54] <mdz> I think we can do both
[11:55] <pitti> what would cover upgrade testing then? integration into u-manager?
[11:55] <mdz> and in the case of upgrades, we can have failure reports filed automatically in many cases, but I don't think we have time to do that for feisty
[11:55] <pitti> mdz: u-m doesn't cover upgrades with apt-get/aptitude, though
[11:55] <mdz> pitti: it's not meant to
[11:56] <mdz> if a user upgrades manually, they have to report it manually too.  nothing we can do about that
[11:56] <lifeless> and its not our encouraged means of upgrade either
[11:56] <pitti> mdz: current spec solves that
[11:56] <lifeless> only a small fraction of our 4M users will not use u-m
[11:56] <pedr0> your fucking mothers suck my very big dick.fuckoff idiots!
[11:56] <pitti> lifeless: right, but I would find it very sad if we don't care for it
[11:57] <sfllaw> pedr0: That language is unacceptable here.  Please stop.
[11:58] <lifeless> pitti: I agree that not caring is bad. I care, but we should optimise the reporting for the bulk of cases.
[11:58] <pitti> agreed
[11:58] <sfllaw> mdz: If we encourage more people to file reports, is there any reliable channel for triagers to hint that a bug is an RC installation bug?
[11:58] <sfllaw> mdz: Even if it isn't a ubiquity of d-i one?
[11:58] <sfllaw> And should be targetted for Feisty?
[11:58] <mdz> sfllaw: yes, the milestone field
[11:58] <sfllaw> Can triagers set that?
[11:58] <mdz> the fact that it's an installation bug is incidental; it's either release targeted or not
[11:58] <mdz> yes
[11:59] <sfllaw> OK.  I thought that was just me.
[11:59] <sfllaw> Thanks.
[11:59] <sfllaw> That will be documented.
[11:59] <mdz> ubuntu-qa should be able to set that
[11:59] <pitti> ok, so if we don't want to automatically report apt-get/aptitude dist-upgrades, then we don't need the new package
[11:59] <pitti> installation-feedback was specifically introduced to the spec to cover this case
[11:59] <sfllaw> pitti: Doesn't xubuntu not use update-manager?
[12:00] <sfllaw> pitti: Or is that something we will consider later?
[12:00] <pitti> so something more lightweight placed by ubiquity/d-i would work as well
[12:00] <pitti> sfllaw: I'm not sure TBH
[12:00] <lifeless> sfllaw: whats the mail-volume of being in ubuntu-qa ?
[12:00] <sfllaw> pitti: Also, what about ubuntu-server?
[12:00] <pitti> sfllaw: ESCREWED
[12:00] <sfllaw> lifeless: There is none.
[12:00] <sfllaw> pitti: That sounds sub-optimal.
[12:00] <sfllaw> pitti: Especially when we want people to be running it on servers.
[12:01] <pitti> sfllaw: ISTR that mvo talked about providing a CLI tool for upgrading servers
[12:01] <cjwatson> https://blueprints.launchpad.net/distros/ubuntu/+spec/server-upgrade-tool
[12:01] <sfllaw> pitti: Let's put that down as an unresolved issue.
[12:01] <sfllaw> cjwatson: Thanks.
[12:01] <pitti> but in neither the current spec nor the current discussion outcome we can automatically report install success
[12:01] <lifeless> sfllaw: I've applied
[12:01] <pitti> sfllaw: agreed, it's pretty orthogonal AFAICS
[12:02] <pitti> ok, seems I can finally care for my RL for a bit (I'm starving and falling asleep)
[12:02] <pitti> sfllaw, mdz: thanks for the discussion, interesting one
[12:03] <sfllaw> pitti: Shall I revise?  Or shall you?  You seem to have a better grasp of what mdz wants.
[12:03] <sfllaw> pitti: But perhaps your revising it would be weird.
[12:03] <pitti> being drafter and approver at the same time would be wrong
[12:04] <pitti> sfllaw: I'll look into the spec tomorrow morning and mail you feedback
[12:04] <sfllaw> pitti: Please do so.
[12:04] <pitti> 'k, thanks
[12:04] <sfllaw> pitti: Enjoy dinner.
[12:04] <pitti> good night everyone!
[12:05] <keescook> 'night pitti
[12:10] <geser> keescook: wasn't I specific enough in bug 73985 that is for the version of gnupg2 in feisty?
[12:10] <Ubugtu> Malone bug 73985 in gnupg2 "[Feisty]  GnuPG 2.0 buffer overflow (CVE-2006-6169)" [Unknown,Unknown]  http://launchpad.net/bugs/73985
[12:10] <keescook> geser: oh!  whoops, sorry.  Let me see if I can fix that up a little.