[02:09] <silvertip257> I'm trying to customize a LiveCD, but I'm having trouble with the documentation I found
[02:37] <desrt> so
[02:37] <desrt> you can buy a laptop running ubuntu from dell for $100 cheaper than the model that comes with windows vista
[02:38] <desrt> (the base config for ubuntu is 512MB of ram whereas vista requires 1GB... but even if you upgrade the ubuntu machine to 1GB it's still $50 cheaper than windows)
[02:38] <Fujitsu> desrt: If you're in the US.
[02:39] <desrt> well
[02:39] <desrt> i wouldn't actually buy a dell laptop anyway
[02:39] <desrt> but it's really nice to see that they're actually taking this seriously this time around
[03:36] <jmg> guys i notice today dist-upgrading to gutsy breaks under vmware
[03:37] <jmg> initramfs cant find the disk
[03:37] <jmg> does anyone have a downloadable vmdk of gutsy?
[03:37] <jmg> i neeeeeeed to test a bug
[03:37] <persia> jmg: Download the feisty vmdk, and dist-upgrade.
[03:37] <jmg> persia: i tried that, it breaks 
[04:10] <Hobbsee> morning all
[07:24] <pitti> Good morning
[07:34] <LongPointyStick> morning pitti 
[07:36] <pitti> Hey Hobbsss... Stick
[07:37] <LongPointyStick> heh
[08:02] <LongPointyStick> pitti: did you have a good holiday?
[08:03] <pitti> LongPointyStick: yes, reasonably; lots of flat cleaning and general household things that were long overdue :)
[08:03] <LongPointyStick> hehe
[08:40] <LongPointyStick> Mithrandir: have you found it yet?  i should have it here somewhere
[08:41] <LongPointyStick> i assume its' technical-board@l.u.c anyway
[08:41] <Mithrandir> yes, I've found it now
[08:46] <LongPointyStick> cool
[09:50] <pitti> hi Keybuk 
[09:50] <Keybuk> morning pitti *hugs*
[09:51] <Mithrandir> good morning, Scott
[09:52] <Mithrandir> yay hugs
[10:08] <hunger> I reported a #117493 today on cryptsetup not working properly with udev anymore (gutsy). Shall I move that to udev instead?
[10:10] <Keybuk> hunger: unlikely to be a udev bug
[10:10] <Keybuk> it could be a devmapper problem
[10:10] <hunger> keybuk, so I'll leave it with cryptsetup.
[10:11] <Keybuk> failed to rendezvous with udev?  that sounds like you have a strange mix of packages
[10:11] <Keybuk> the gutsy devmapper doesn't have any code like that
[10:11] <hunger> Keybuk: That is a message by the cryptsetup executable afaikt.
[10:12] <Keybuk> it used to be a message from libdevmapper?
[10:12] <hunger> Keybuk: It seems to wait for /dev/mapper/temporary-something-PID.
[10:12] <hunger> Keybuk: possible. I just straced cryptsetup.
[10:12] <Keybuk> can you attach the strace
[10:12] <hunger> keybuk: I'll try...
[10:14] <Keybuk> keescook: ping
[10:14] <hunger> Keybuk: I can not reboot right now (takes about 45min to start up due to cryptsetup timeouts), so I'll need to find some free space to put a crypted partition on:-)
[10:15] <Fujitsu> hunger: Did some upgrade break that?
[10:15] <hunger> Fujitsu: It worked fine till tuesday.
[10:18] <hunger> Keybuk: Can't reproduce since cryptsetup luksFormat /dev/something fails without giving a reason.
[10:18] <siretart> Keybuk: are you aware that root on lvm is currently broken in gutsy? a small 'lvm vgchange -ay ; logout' makes the system boot again
[10:18] <Keybuk> right, but do you have the strace?
[10:18] <Keybuk> if so, is ioctl() returning -EINVAL?
[10:18] <Keybuk> siretart: no
[10:18] <siretart> I'll fetch the lp bugno
[10:19] <siretart> bug #87745
[10:19] <ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  https://launchpad.net/bugs/87745
[10:19] <Keybuk> siretart: mdadm hasn't been merged yet
[10:20] <hunger> Keybuk: strace of cryptsetup luksFormat contains only "write" statements after the read for "yes" to get this started.
[10:20] <siretart> Keybuk: this confuses me now. my md devices come up properly, just the lvm devices need a kick. how is the mdadm merge related here?
[10:20] <ompaul> hunger, attache it to lp 
[10:21] <Keybuk> siretart: your lvm devices are built on your md devices
[10:23] <crimsun> as a possibly interesting datum, I've got ext3 / on LVM in gutsy, and it seems to boot fine with no manual intervention (under 2.6.22-5-generic).
[10:23] <Fujitsu> crimsun: That's what I thought.
[10:23] <Fujitsu> I also use LUKS, and it works fine.
[10:24] <hunger> crimsun: I am still on 2.6.20-15-generic. Maybe that is part of the problem.
[10:24] <siretart> Fujitsu: root on luks?
[10:24] <Fujitsu> siretart: Not root, unfortunately.
[10:25] <hunger> keybuk: strace is on bug #117502 (about luksFormat failing).
[10:25] <ubotu> Launchpad bug 117502 in cryptsetup "[gutsy]  cryptsetup luksFormat fails." [Undecided,Unconfirmed]  https://launchpad.net/bugs/117502
[10:25] <Fujitsu> I never could get that working well, though I'll try again in a few weeks when school holidays occur.
[10:26] <Keybuk> hunger: how odd, doesn't look like it's doing anything, does it?
[10:27] <hunger> Keybuk: Yes, that is what I told you before:-)
[10:27] <hunger> Keybuk: Same thing happens when I give an invalid device...
[10:27] <Keybuk> almost certainly a cryptsetup bug then
[10:28] <hunger> Keybuk: I tried to use the /dev/dm-XY directly, but that did not help.
[10:31] <dholbach> hello
[10:31] <shawarma> Goodmorning, dholbach.
[10:31] <dholbach> heya shawarma
[10:31] <pitti> hi shawarma 
[10:31] <shawarma> hi, pitti
[10:34] <highvoltage> morning dholbach 
[10:35] <dholbach> heya highvoltage
[10:45] <siretart> did anyone else than me notice strange linewraps in po files of debconf translations?
[10:45] <siretart> any idea why .po files in ubuntu packages tend to be linewrapped, while the debian ones don't? shall we keep the ubuntu ones, or take the debian ones?
[10:46] <Keybuk> am I the only person who thinks that reCAPTCHA is a great way of getting users of your system to help you bypass other CAPTCHAs? :p
[10:46] <siretart> I mean for packages in main
[10:46] <Keybuk> siretart: msgmerge damage, usually
[10:47] <pitti> siretart: don't worry for .po files in main; we have Rosetta for that
[10:47] <pitti> siretart: IOW, there should not be any Ubuntu delta for .po files in Ubuntu main
[10:47] <siretart> pitti: so just revert to the debian .po files to minimize the diff. okayt
[10:47] <Riddell> pitti: could you look at bug 73384 sometime for SRU?
[10:47] <ubotu> Launchpad bug 73384 in kubuntu-docs "Localized Kubuntu documents missing" [High,Fix committed]  https://launchpad.net/bugs/73384
[10:49] <pitti> Riddell: hm, let's just hope that there will never be a .1 CD image for edgy and feisty
[10:52] <pitti> Riddell: diffs look ok, but I'm not sure whether you'd want to inflict this huge download to Kubuntu users
[10:52] <pitti> Riddell: right before Feisty release I changed ubuntu-docs to downsize the package a bit, btw (bzip2 compression and removing all translations with < 30% coverage)
[10:53] <pitti> well, s/a bit/9 MB -> 2 MB/
[10:57] <siretart> Keybuk: FYI, I've just prepared an mdadm merge, which I just uploaded to upload.dogfood.ubuntu.com's test ppa. I cannot easily build nor test it atm, since a) lvm snapshots are broken now, and b) I'm not at home atm
[10:57] <siretart> in case you're interested, I can publish my bzr branch for that
[10:58] <siretart> StevenK: yes, cprov asked my to stress test it. :) 
[10:58] <StevenK> Heh
[11:02] <sladen> ah, the wonders of Euro-time
[11:08] <Keybuk> siretart: it needs a patch applied as well to work
[11:08] <Keybuk> I already have a finished merge
[11:08] <siretart> oh. ok
[11:09] <Keybuk> I'm waiting until we've understood and fixed the issues with pure devmapper, and with LVM, before complicating the matter by throwing in mdadm
[11:09] <Keybuk> one step at a time, etc.
[11:57] <pitti> Mithrandir: can you please give-back gimp?
[11:59] <Mithrandir> pitti: given-back
[11:59] <pitti> Mithrandir: merci
[11:59] <Mithrandir> bitte sehr
[12:05] <geser> does anybody know why all merges on MoM are in red?
[12:07] <Keybuk> how odd
[12:07] <Keybuk> Priority missing from the source?
[12:08] <pitti> hardly, it changed over the weekend for merges that haven't been touched since then
[12:08] <Keybuk> hmm, Priority is missing from Sources for everything ?
[12:12] <Keybuk> today is Tuesday, no?
[12:13] <siretart> Keybuk: yep
[12:13] <Keybuk> LP roll-out last night, by any chance?
[12:13] <Keybuk> yup
[12:14] <Keybuk> Priority field has been lost from Sources.gz on LP
[12:14] <Fujitsu> They've all been red for at least two or three days.
[12:15] <Keybuk> dunno when the last roll-out was
[12:24] <elmo> err
[12:25] <Hobbsee> boo
[12:25] <Fujitsu> xyy
[12:27] <siretart> Keybuk: do you happen to develop devmapper in a bzr branch?
[12:28] <Keybuk> siretart: no
[12:29] <Keybuk> I haven't yet found a workflow of bzr-branch-for-package that I'm happy with
[12:30] <siretart> I personally like this mode: http://wiki.tauware.de/misc:vcs-packaging#importing_upstream_releases_only
[12:31] <Keybuk> yeah, that's a huge amount of work for no benefit though, no?
[12:33] <siretart> the benefit is that I can use 'bzr merge' for merging new upstream releases
[12:34] <seb128> siretart: you can also copy the debian directory to the new source
[12:34] <Keybuk> siretart: how is 'bzr merge' different to just applying the previous diff.gz to the new upstream release?
[12:35] <Keybuk> in both cases, some stuff applies, and some stuff rejects and needs manual fixing
[12:35] <pitti> siretart: I guess that only pays off if you manage patches directly rather than in debian/patches?
[12:35] <Keybuk> I fully agree with "*REPLACE* the source packages with a bzr archive"
[12:35] <siretart> pitti: yes, patch systems are really annoying for this. I'm currently looking for a way how to convert dpatches to inline and vice versa for that
[12:35] <Keybuk> but I don't agree that staging source packages through a bzr archive is useful
[12:36] <Keybuk> since the source package archive also has all of the properties of an RCS
[12:36] <seb128> having the source stored to bzr is extra work
[12:36] <siretart> seb128: this doesn't get me anything for merging new upstream versions when I have done changes to the upstream source
[12:36] <seb128> you have to keep them in sync
[12:36] <pitti> I still find it useful for several people working on a package (like hal), or merging with Debian's svn
[12:36] <pitti> but those are limited cases
[12:36] <seb128> siretart: you have to merge patches which don't apply by hand anyway
[12:36] <siretart> Keybuk: I'm more confident if I can track the changes while resolving conflicts
[12:36] <Keybuk> yeah, it does make some sense if you have a team working on each release
[12:36] <seb128> you can as well use dpatch-edit
[12:36] <Keybuk> or upstream/Debian use an RCS as well
[12:37] <Keybuk> siretart: emacs provides me that workflow
[12:37] <Keybuk> but for a drive-by patching affair like devmapper, it's minimal tweak changes, upload, round of testing, you or someone else tweaks again, upload, round of testing
[12:39] <siretart> Keybuk: It's hard for me to review your changes. I surely want to understand and learn the devmapper/mdadm/lvm chaos, and I wanted so see what steps you have done in the past
[12:39] <Keybuk> why is it hard?
[12:39] <Keybuk> you can look at the debdiffs, no?
[12:39] <siretart> I'm currently downloading all past devmapper uploads
[12:39] <siretart> a ready bzr branch and bzrk would have helped me here
[12:40] <seb128> that's lot of extra work for little win though
[12:40] <Keybuk> http://patches.ubuntu.com/by-release/ubuntu/d/devmapper/
[12:41] <siretart> oh. I didn't know that url. that's indeed helpful.
[12:41] <Keybuk> actually
[12:41] <siretart> thanks
[12:41] <Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/d/devmapper/
[12:41] <Keybuk> even more helpful
[12:42] <Keybuk> since if you look at the 1ubuntu4 patch, it's only the changes made from 1ubuntu3 -> 1ubuntu4
[12:42] <shawarma> Wow...
[12:42] <shawarma> that sure beats the crap out of extracting the old versions from launchpad and debdiff'ing them.
[12:43] <siretart> too bad that I missed the announcment of the by-release directory :/
[12:43] <Keybuk> *cough* err, it's one of Keybuk's secret little toys that he's not got around to documenting
[12:43] <Keybuk> just like the e-mail interface that lets you subscribe to uploads per-package/per-distro
[12:44] <Keybuk> e.g. subscribe to all Debian changes to a particular package
[12:44] <shawarma> Sounds shiny!
[12:44] <siretart> I'm looking forward to see that e-mail interface advertised :)
[12:45] <Keybuk> involves my CFT
[12:45] <siretart> CFT?
[12:46] <thom> copious free time
[12:48] <Hobbsee> now that's cool
[12:48] <Mithrandir> seb128: what do you think about https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000182.html ?
[12:50] <Lure> Mithrandir: can you give-back kdegraphics to pick up new poppler (and make kubuntu-desktop installable again)?
[12:52] <Mithrandir> Lure: no, it's not FTBFS
[12:52] <pitti> Lure: that requires a no-change upload
[12:52] <Lure> pitti: ok, did not know that. will talk with Riddell then
[12:53] <Lure> thanks
[12:54] <seb128> Mithrandir: I'm not sure of why it's useful. What do they change to the fileselector? the interface?
[12:56] <Mithrandir> seb128: they reimplement it, since the default one isn't too suited on a small screen
[12:57] <seb128> Mithrandir: patch looks fine, we can apply it only to the new arch anyway, no?
[12:57] <Mithrandir> seb128: we could, but I'd like people to be able to easily develop hildon-based apps natively on their desktop.
[12:58] <Mithrandir> so if you don't mind too much, I'd like us to apply it on all arches.
[12:58] <Mithrandir> it "only" exports some private headers into "semi-public", which means no ABI/API guarantees
[12:58] <seb128> I don't like much changing the public API over upstream but since it's prefixed correctly hildon_ that's ok
[12:59] <seb128> Mithrandir: well, it adds hildon_gtk_file_chooser_install_properties to the API no?
[12:59] <Mithrandir> it should go away eventually when we get gvfs and upstream is comfortable exporting the API
[01:00] <seb128> which means not this cycle
[01:00] <seb128> patch is fine with me, I'll try building GTK+ with it now
[01:00] <Mithrandir> seb128: true, it adds that function
[01:00] <Mithrandir> sorry I didn't see it before
[01:01] <Mithrandir> and it's guarded with defines so you have to tell the system "I know this might/will break".
[01:02] <seb128> right
[01:13] <carlos> seb128: Hi, is there any special reason that justifies libgtop2 removal from Gutsy?
[01:13] <carlos> seb128: we detected it while testing Gutsy translation opening and Danilo told me it's still a GNOME 2.19 dependency
[01:13] <mrsn0> ot: http://www.flickr.com/photos/thevoyagers/518750492/ google in 20 years ;] 
[01:28] <pitti> Hobbsee: eek
[01:28] <Hobbsee> pitti: were you going to look into https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/117388 and https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/114186?  I believe you did the last poppler upload
[01:28] <ubotu> Launchpad bug 117388 in poppler "missing header file in libpoppler-qt-dev" [Undecided,Unconfirmed]  
[01:29] <pitti> Hobbsee: can do, a bit later
[01:30] <iwj> Ah, that's better.
[01:30] <ubotu> Launchpad bug 117256 in Ubuntu "Thats What She Said!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117256
[01:31] <Hobbsee> pitti: thanks.  then i can fix koffice and such :)
[01:32] <iwj> Retrieving message nnn (of 357) from ....    oh dear.  And that's not including what's still queued up at my MX.
[01:34] <Hobbsee> iwj: introduce a data loss bug.  problem solved.
[01:50] <seb128> carlos: it has been renamed "libgtop"
[01:53] <carlos> seb128: oh, cool!
[01:53] <seb128> carlos: can translation be migrated?
[01:53] <seb128> cool
[01:54] <seb128> carlos: do you want to be pinged when a package is renamed? control-center has been renamed gnome-control-center
[01:55] <carlos> seb128: I will discover it while approving manually translations, but if you notify us, that's more easy
[02:05] <doko> Riddell: fyi, http://merges.ubuntu.com/main-manual.html has some outstanding kde merges, including new upstream versions
[02:06] <Riddell> doko: ack.  today it going through e-mail backlog day but I'll get to those soon
[02:12] <StevenK> Riddell: If you want to throw one to me, feel free.
[02:13] <Riddell> StevenK: take them all if you want :)
[02:13] <StevenK> Heh
[02:14] <StevenK> I dealt with kio-apt a few days ago, that was painful. :-)
[02:14] <Hobbsee> not knetworkmanager though
[02:18] <Hobbsee> what does one do with http://librarian.launchpad.net/7834592/buildlog_ubuntu-gutsy-i386.freemind_0.7.1-6_FAILEDTOBUILD.txt.gz ?  It's failing as j2re1.4 and j2sdk1.4 are build-deps, and the licence file isnt being accepted on the buildds.
[02:18] <Mithrandir> Hobbsee: it should have been preseeded on the buildds.
[02:19] <Mithrandir> I'll ask Adam to fix it.
[02:19] <Hobbsee> okay, thanks
[02:59] <dholbach> shawarma: thanks for getting in touch with charlie
[03:00] <shawarma> dholbach: No problem. I was a bit afraid to open the tarball I got, but it's looking really good, actually.
[03:00] <dholbach> nice :)
[03:02] <shawarma> the only major problem was copyright stuff that needs to be settled. The technical side of things were 92% done. :)
[03:02] <dholbach> rock and roll - maybe Charlie can help with documenting that
[03:05] <shawarma> Definitely.
[03:15] <mruiz> hi, anyone know why debootstrap is broken in Gusty?
[03:15] <pitti> mruiz: you mean debootstrapping gutsy doesn't work, or debootstrap itself is broken?
[03:16] <persia> pitti: debootstrapping feisty in gutsy doesn't work today.
[03:17] <mruiz> pitti: I was creating my gusty environment to process a merge, but I had this error: W: Failure trying to run: chroot /var/cache/pbuilder/build/16442/. mount -t proc proc /proc
[03:17] <mruiz> pbuilder: debootstrap failed
[03:32] <Keybuk> I actually quite like LVM
[03:32] <Keybuk> I must be unwell
[03:32] <StevenK> Bwahaha
[03:32] <kylem> Keybuk, heh, i like not having a gazillion partitions on disk...
[03:33] <Keybuk> ZFS FTW!
[03:34] <maswan> Yes, now if someone could just make a zfs for everyone without solaris love. ;)
[03:34] <kylem> Keybuk, rock on!
[03:34] <StevenK> Hopefully, ZFS doesn't need the pox of Sun disklabels.
[03:34] <Keybuk> we could call it the Filesystem That Works
[03:34] <kylem> StevenK, heh, it doesn't care about partitions
[03:34] <kylem> StevenK, you have to feed it whole disks.
[03:35] <StevenK> Ahh
[03:35] <Keybuk> then we could "mount -t ftw ..." :p
[03:35] <maswan> kylem: strictly speaking, I think you can feed it anything, it just prefers whole, single, disks
[03:35] <thom> aye
[03:35] <kylem> maswan, ah, i've only used disks.
[03:35] <StevenK> Keybuk: And then we get bug reports saying "File system name tells lies!"
[03:36] <maswan> StevenK: Easy to fix, just add a alias for Filesystem That Lies. :)
[03:36] <Hobbsee> Keybuk: i thought that was reiser?  :P
[03:36] <Hobbsee> racarr will tell you!
[03:36] <ion_> hobbsee: Haha
[03:36] <Fujitsu> Hahah
[03:36] <kylem> Hobbsee, aw, don't be mean.
[03:36] <Keybuk> the evmsishness of ZFS is really appealing
[03:37] <Hobbsee> kylem: but...but...
[03:37] <kylem> Keybuk, indeed.
[03:37] <Keybuk> "here are my disks; now give me a 4GB"
[03:37] <kylem> Keybuk, the temptation to NIH something better is strong.
[03:37] <Keybuk> it's like evms, but without the soul-crushing pain
[03:37] <ion_> Does its license prevent it from being used in Linux?
[03:38] <kylem> Keybuk, it's a pity you took off to the airport early, we met Jeff Bonwick that friday
[03:38] <Keybuk> yeah :-(
[03:38] <Fujitsu> ion_: CDDL is GPL-incompatible, unfortunately.
[03:38] <Keybuk> bit of luck I did too, by the time I'd got checked in and through customs, I didn't have long
[03:38] <kylem> yow.
[03:38] <Mithrandir> Fujitsu: but there's a gpl-ed port, I thought?
[03:38] <kylem> we had a good 2 hour wait at SFO
[03:38] <Keybuk> taxi took an age to arrive
[03:38] <Fujitsu> There's a FUSE port.
[03:38] <kylem> Mithrandir, no, it's FUSE based.
[03:38] <highvoltage> Sun said they mihgt license the whole of opensolaris as gpl in some point in the future. I hope that includes zfs.
[03:38] <Mithrandir> kylem: oh, ok.
[03:39] <StevenK> Speaking of evms, is it going to get it's comeuppance and get demoted to universe?
[03:39] <mjg59> There's a very basic GPLed read-only implementation for grub
[03:39] <maswan> kylem: Oh, you've met him too, he's quite interesting to talk to. Him and Bill Moore was at a storage workshop I went to a couple of months ago
[03:39] <mjg59> So someone /could/ go from there
[03:39] <Keybuk> StevenK: upstream refuse to support Linux 2.6 ... morgue could be a destination <g>
[03:39] <kylem> maswan, yeah, bill moore was there too.
[03:40] <StevenK> Keybuk: Oh, even better.
[03:40] <StevenK> Actually, wait a sec?
[03:40] <Fujitsu> What does EVMS have over LVM?
[03:40] <StevenK> evms has an upstream? I thought it sprang from hell, fully formed?!
[03:40] <desrt> Fujitsu; enterprise support
[03:41] <Mithrandir> Keybuk: eh?  It works just fine with 2.6.
[03:41] <thom> Keybuk: eh? 
[03:41] <Keybuk> Mithrandir: tried it on gutsy?
[03:41] <desrt> Fujitsu; lvm doesn't work on enterprises :)
[03:41] <ion_> fujitsu: From what ive heard you tell it e.g. please resize this to 10GiB and it does all the steps involved correctly, whereas with poking plain filesystems, LVM and md, you might have to do multiple steps and you might be able to break something along the way.
[03:41] <Mithrandir> Keybuk: my machines still boot.
[03:42] <maswan> kylem: oh, btw, did you send anything yesterday?
[03:42] <Keybuk> Mithrandir: do you have any non-evms block devices?
[03:42] <kylem> maswan, ah, shit, i forgot.
[03:42] <kylem> maswan, 1sec.
[03:42] <kylem> maswan, it's already uploaded, just need to untar & mv
[03:42] <Mithrandir> Keybuk: yes.
[03:42] <Keybuk> thom: evms attempts to make a devmapper device for every block device on the system, whether it intends to do anything with them or not
[03:42] <thom> ugh
[03:42] <Keybuk> thom: this fails if any of them are in use, e.g. mounted
[03:42] <thom> aye
[03:43] <Keybuk> upstream's approach to this is to patch out the kernel features that cause this
[03:43] <StevenK> Yowch!
[03:43] <Lure> StevenK: since you have done exiv2 sync, do you have any plans with digikam (note: 0.9.2 beta2 was just released, but not yet in debian)
[03:43] <StevenK> Lure: I didn't, I can.
[03:43] <Mithrandir> Keybuk: or rather, to tell you to not run evms and non-evms volumes on the same physical device.
[03:44] <Lure> StevenK: since allee (debian packager) is on vacation, we could to Beta2-0-ubuntu1 and then he can merge back in debian after he is back
[03:44] <StevenK> Lure: We could, yes.
[03:45] <Lure> StevenK: ok, I can prepare package, but will need core-dev for upload ;-)
[03:45] <StevenK> Lure: You can file a bug and subscribe u-m-s.
[03:45] <StevenK> Alternatively, you can pick on me, if you wish.
[03:45] <Hobbsee> Lure: why not get a DD to upload it to debian, if allee's fine with that, then sync it?
[03:46] <Keybuk> Mithrandir: it still fails because evms still tries to make the devices
[03:46] <StevenK> There's that, too.
[03:46] <Hobbsee> or can you not abuse NMU like that?
[03:46] <Keybuk> it's default configuration is to assume all volumes are for evms
[03:46] <StevenK> Hobbsee: You can, it's just frowned upon.
[03:46] <Hobbsee> StevenK: even if the maintainer says it's fine?  :P
[03:46] <Mithrandir> Keybuk: don't tell my machines, since they work fine. :-P
[03:46] <siretart> IIRC, it was strongly encouraged by evms upstream to not mix evms and non-evms managed devices on the same disk
[03:46] <Lure> Hobbsee: yep, we can try fabo or somebody to sponsor debian upload
[03:47] <StevenK> Ssshh!
[03:47] <Hobbsee> oh.  wait.  i didnt say that.
[03:47] <Lure> Hobbsee: oh, did not know he is DD too ;-)
[03:47] <Hobbsee> sorry steve :P
[03:47] <StevenK> digikam is maintained by "Debian KDE Extras Team" - this implies more than one person.
[03:47] <StevenK> Hobbsee: Hmph.
[03:48] <Hobbsee> Lure: might push pusling/ana to upload it, then.
[03:48] <Hobbsee> or their sponsors.  although i thougth ana was a DD
[03:50] <mdz> Keybuk: should we think about having evms be removed by the upgrader if it isn't in use?
[03:51] <Keybuk> mdz: we've never been able to define "in use" :-/
[03:51] <Hobbsee> Lure: #debian-qt-kde on oftc - just dont get them onto ubuntu policies.
[03:51] <Hobbsee> and they wont bite
[03:51] <Hobbsee> much
[03:51] <mdz> Keybuk: the existence of any evms volumes other than compatibility volumes
[03:51] <Keybuk> mdz: if there's a way to detect that, it would be a great idea
[03:52] <Keybuk> since this appears to bite the people who have evms installed because we once installed it by default
[03:52] <Keybuk> and the people who actually use it, seem completely happy and unaffected
[03:52] <Mithrandir> kinda a corner case, but that will break systems where people only have evms on hotplugged drives.
[03:53] <mdz> if they don't have any /dev/evms mount points in fstab, i think we can probably get away with removing it on upgrade
[03:53] <mdz> (it does still use /dev/evms, right?)
[03:55] <Mithrandir> mdz: no, you can't do that.  I use cryptsetup on evms, for instance.
[03:56] <Mithrandir> evand: do you know what the current state of the installer is?  Does it make sense to start building daily cds again?
[03:56] <mdz> Mithrandir: do you even use the release upgrader? :-P
[03:56] <Mithrandir> mdz: no, it refused to upgrade to gutsy two weeks ago.
[03:56] <Mithrandir> so yes, I tried, but it failed since it didn't know about gutsy yet.
[03:57] <evand> Mithrandir: Negative, I do not know the answer to that, unfortunately.
[03:57] <Mithrandir> evand: ok.
[03:57] <evand> I'll be happy to test it in a short while though, if you have not already.
[03:58] <Mithrandir> evand: I haven't, no.  Usually, we've hold off dailies until they make sense, but I haven't spoken with colin in a little while so I'm not sure about the status.
[03:59] <Hobbsee> Mithrandir: is there any point anyway until the desktop packages are actually installable?
[03:59] <Mithrandir> Hobbsee: we build server CDs, and it helps highlight the problems.
[03:59] <Hobbsee> ahhhh
[04:01] <Keybuk> the evms failure mode right now seems to be 1) install evms 2) reboot 3) computer fails to mount root filesystem because it's "in use"
[04:01] <Keybuk> or 1) being "have evms already installed"
[04:01] <Hobbsee> oh damn that poppler bug.
[04:02] <Mithrandir> Keybuk: we could switch evms into only claiming the devices it actually uses?
[04:02] <Mithrandir> or is that hard?
[04:03] <Keybuk> Mithrandir: that would be the ideal solution, however no idea how hard that is
[04:04] <pitti> Hobbsee: yeah, yeah, I'm still Mithrandir's slave ATM; but you are high on the list now :)
[04:05] <Hobbsee> pitti: hooray!
[04:07] <Hobbsee> pitti: just dont make me get out the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!!!  :P
[04:07] <pitti> Hobbsee: "Oh no, not again!"
[04:07] <Hobbsee> pitti: (all of the kde packages are failing due to this, it seems, so i'm kinda interested in it)
[04:07] <Hobbsee> hehe
[04:08] <pitti> Hobbsee: ready with NEW; so, it's only those two bugs?
[04:08] <Hobbsee> pitti: i think so.  i havent seen more.  check for poppler bugs in the package though, i guess
[04:10] <Hobbsee> pitti: maybe https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/74366 too.  Hobbseeparser is dying on that one
[04:10] <ubotu> Launchpad bug 74366 in poppler "Missing dependency" [Undecided,Unconfirmed]  
[04:11] <pitti> Hobbsee: I just dup'ed that to #114186
[04:12] <Hobbsee> pitti: even better.  i thought ti might be
[04:17] <tepsipakki> doko: do you wan't to look at the syslinux debdiff before I upload it?
[04:17] <tepsipakki> s/'//
[04:17] <doko> tepsipakki: did you test it?
[04:18] <tepsipakki> yes
[04:18] <tepsipakki> colins test suite worked fine
[04:18] <tepsipakki> with the new gfxboot-patch from suse
[04:18] <doko> then go ahead and upload
[04:19] <tepsipakki> ok, thanks
[04:19] <pitti> tepsipakki: out of interest, did it still need fixes for -fno-stack-protector?
[04:19] <tepsipakki> pitti: upstream has those
[04:19] <pitti> tepsipakki: sweet
[04:19] <tepsipakki> where needed
[04:19] <tepsipakki> so I dropped the patch
[04:22] <tepsipakki> ok, uploaded..
[04:24] <StevenK> I hate the TIL rule at work.
[04:25] <pitti> StevenK: well, it's still the one that makes most sense without introducing a lot of bureaucracy
[04:25] <StevenK> pitti: Yeah, that's true.
[04:26] <Hobbsee> pitti: were you doing binary NEW or source NEW?
[04:26] <pitti> Hobbsee: both (specifically for the Mobile project, since it's not my archive day)
[04:26] <Hobbsee> ah right.  no problem
[04:27] <pitti> anything that's urgent for you?
[04:28] <Hobbsee> pitti: there's kde-tweak, the guy's uploaded a new version on it.  so only urgent to kick another thing off revu.  poppler stuff is more important
[04:30] <Hobbsee> pitti: ie, no
[04:35] <StevenK> doko: Thanks for the offer, I've joined pythoneers.
[04:36] <pitti> Hobbsee: poppler uploaded
[04:36] <Hobbsee> pitti: yay, thankyou
[04:37] <StevenK> pitti: Will/Have parts of it cleared binary NEW?
[04:37] <pitti> StevenK: 'it'?
[04:37] <pitti> StevenK: https://launchpad.net/ubuntu/gutsy/+queue FYI
[04:38] <StevenK> Yeah, I just checked.
[04:38] <StevenK> It looks like libpoppler-glib1 graces there no more.
[04:38] <pitti> yep, I NEWed that on Friday
[04:39] <pitti> (for everyone not yet knowing the trick, https://launchpad.net/ubuntu/gutsy/+queue?batch=500 is much nicer)
[04:39] <Spads> cjwatson_: gutsy ppc is on ports now
[04:39] <StevenK> Oooh. /me files that one away.
[04:48] <glatzor> hello mpt, I would like to discuss the displayconfig-gtk interface with you.
[04:49] <mpt> glatzor, sure
[04:49] <glatzor> mpt: fine. Have you already used the current gutsy version?
[04:50] <mpt> No, I'm not smart enough to run pre-beta Ubuntu versions
[04:50] <mpt> :-)
[04:52] <Keybuk> keescook: ping (hopeful)
[04:53] <glatzor> mpt: No problem. I can make you a feisty package
[04:53] <glatzor> mpt: In the meantime here are some older screenshots https://wiki.ubuntu.com/DisplayConfigGTK
[04:55] <glatzor> mpt: are you familiar with bzr?
[04:55] <mpt> glatzor, I use it every day :-)
[04:56] <glatzor> mpt: fine. here is a different approach in the user interface design: http://glatzor.de/bzr/displayconfig-gtk/gfxbase/
[05:00] <glatzor> mpt: http://glatzor.de/filesink/displayconfig-gtk_0.2+20070523ubuntu2_i386.deb
[05:00] <glatzor> mpt: you have to install this package. afterwards also the bzr branch will work
[05:00] <afflux_> siretart: I'm having a problem with cryptsetup in gutsy, I'm not sure wether it's a bug.
[05:01] <glatzor> mpt: one of the main problems in the user interface is to represent the relation between graphics card and screens.
[05:01] <mpt> glatzor, I'll be on the phone for a while and not within reach of a copy of bzr, sorry
[05:01] <glatzor> mpt: hey, I could also discuss it via the ubuntu-desktop mailing list
[05:02] <glatzor> we could :)
[05:02] <afflux_> siretart: when using luksOpen it asks me for the password, after that it does nothing for about 3 minutes. Then it says "endezvous with udev timed out for 'temporary-cryptsetup-4684'; stat failed: No such file or directory". After that it maps the volume but this is far too long for booting.
[05:03] <mpt> glatzor, that would work
[05:03] <chand|> hi
[05:05] <chand|> anyone using encfs on gutsy, here is a bug with openssl 0.9.8e, you can't read data  encrypt with feisty
[05:05] <chand|> there is a bug in openssl 0.9.8e http://www.mail-archive.com/openssl-users@openssl.org/msg48671.html
[05:06] <chand|> i don't know if i add a bug or wait for an upstream openssl update
[05:07] <Keybuk> afflux_: dpkg -s libdevmapper1.02 ?
[05:11] <mpt> glatzor, one thing that jumps out at me from the wiki page illustrations is that it would be much easier to see how the screens related to each other if they were visually represented
[05:11] <siretart> afflux_: which version of cryptsetup do you have installed?
[05:11] <mpt> i.e. a picture of the screens
[05:11] <mpt> next to each other
[05:12] <afflux_> siretart: 2:1.0.4+svn29-1ubuntu1
[05:12] <afflux_> siretart: I just that you uploaded -1ubuntu3
[05:12] <afflux_> siretart: (i'm still a bit slow with console only :))
[05:13] <glatzor> mpt: we don't support many different screen relations. it is only allowed to configure one relation, that can be cloned or extended by
[05:14] <siretart> afflux_: yes. please try a newer version
[05:14] <glatzor> mpt: the larger problem is what happens if you have got two cards? currently it is quite hard to find which output belongs to which card
[05:15] <afflux_> siretart: I guess -1ubuntu3 won't be in the archives yet, would it?
[05:15] <mpt> glatzor, I mean the "Extend primary screen:" menu would be better as a picture of two screens that you can drag around
[05:15] <Keybuk> siretart: did you locate the problem?
[05:15] <glatzor> mpt: you would have got to the devices screen and hopefully choose different model names. but if both of them are e.g. 1280 LCDs you would have a problem
[05:15] <siretart> afflux_: the source has been already published, the build's didn't start yet. and I've just uploaded -1ubuntu4 a few minutes ago
[05:16] <glatzor> mpt: I think that this feature is overrated. all dialogs that implemented this do not fit on 640x480
[05:16] <siretart> Keybuk: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/117459
[05:16] <ubotu> Launchpad bug 117459 in cryptsetup "luksOpen takes ages" [Undecided,Fix released]  
[05:16] <Keybuk> siretart: ah, heh
[05:16] <Keybuk> of course, there was a SONAME bump
[05:16] <glatzor> mpt: and using dump numbers as screen identifiers is also not a good way (windows=
[05:16] <glatzor> )
[05:17] <siretart> Keybuk: can we do something to prevent such issues in the future?
[05:17] <afflux_> siretart: thank you for your help
[05:17] <glatzor> mpt: the ideal solution would be to have all options on one dialog. I don't like to have three notbook pages
[05:18] <Keybuk> siretart: the archive admins tend to notice such things pretty easily
[05:18] <Keybuk> obviously we're still early in the gutsy release process, so the eye isn't quite so sharp
[05:18] <glatzor> mpt: and furthermore you would have to provide a non drag and drop configuration option too. since I am not sure that all user would discover the fancy method.
[05:19] <Keybuk> siretart: it would be nice to work out a magic udev rule for cryptsetup, so any luks block device is automatically dealt with
[05:19] <glatzor> mpt: so more and more space would be required
[05:19] <glatzor> mpt: wait I will make a screenshot of the different approach
[05:19] <mpt> I don't know what a "dump number" is
[05:19] <glatzor> mpt: 1 and 2
[05:20] <mpt> oh
[05:20] <glatzor> mpt: a number without any further meaning :)
[05:20] <glatzor> mpt: Using the Monitor model name seems to be a better approach, but would also consume more space.
[05:21] <siretart> Keybuk: indeed. 
[05:21] <siretart> Keybuk: for keyfiles, we could perhaps work something out, so that the user has the possibility to place it on the harddriver or on some usbstick or something
[05:22] <glatzor> mpt: If you connect a different screen, you have got to tab 3 change the model, go back to tab 1 and change the resolution and if you haven't yet configured dual head go to tab 2
[05:22] <siretart> Keybuk: however for passwords entered via terminal I think we would perhaps need some external password-agent tool or something
[05:22] <Keybuk> yeah we'd need that
[05:22] <Keybuk> but it should be now possible to
[05:22] <Keybuk> 1) make sure vol_id can detect luks partitions
[05:22] <Keybuk> and thus
[05:22] <siretart> ideally, that would use usplash if running
[05:22] <siretart> vol_id is able to detect luks just fine
[05:22] <Keybuk> 2) have a udev rule that activates them (getting a password, excluded)
[05:23] <Keybuk> ok, cool
[05:23] <siretart> it doesn't work with 'plain' dm-crypt devices, since they lack an meta-information header. but luks is just fine
[05:23] <Keybuk> so SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="crypto_LUKS", RUN+="..." in an 85-*.rules would work
[05:24] <siretart> we can perhaps modify cryptsetup to spit out some warning if the user tries to create a non-luks device or something
[05:24] <glatzor> mpt: http://glatzor.de/filesink/dcg-gfxbase.png
[05:24] <Keybuk> don't dm-crypt devices show up as ENV{DM_TARGET_TYPES}=="crypt" ?
[05:24] <glatzor> mpt: I tired to combine the device chooser and the display mode selector on one tab
[05:24] <glatzor> mpt: every graphics card would be represented by a single tab
[05:25] <siretart> Keybuk: but how do you imagine this passphrase agent? It should be able to run in a) usplash, b) text/console, c) serial console (?), d) X11/Gnome/KDE session 
[05:25] <glatzor> mpt: so the screen/gfxcard relation would be clear
[05:25] <glatzor> mpt: if there is only one screen I can hide the left chooser
[05:25] <Keybuk> siretart: I think it makes sense to combine that with the "progress output" agent, which needs to send its output to a) usplash, b) text/console, c) serial console, d) X11/Gnome/KDE session, e) text-to-speech
[05:26] <Keybuk> ie. the "Starting Apache Web Server" thingy
[05:26] <siretart> Keybuk: http://paste.debian.net/29174 <- example output of what vol_id says about luks
[05:26] <glatzor> mpt: the dialog is resizable and the model chooser button uses ellipsis so that it does not force a wide window
[05:26] <Keybuk> siretart: don't suppose you have a dm-crypt fs around?  if so, what does dmsetup export NAME say on it?
[05:27] <siretart> Keybuk: my laptop is running debian/lenny atm, since feisty wasn't in too good shape for LVM/dm-crypt experiments :/
[05:27] <siretart> what does NAME stand for?
[05:27] <Keybuk> yeah, it wasn't great
[05:27] <siretart> hda6?
[05:27] <Keybuk> whatever the /dev/mapper thing is
[05:28] <Keybuk> the theoretical final step for all this is that the device-mapper ioctl() to make or change a device won't actually complete until the uevent has been processed by udev and the device node created
[05:28] <siretart> dmsetup export says 'Unknown command'
[05:28] <siretart> do you perhaps mean 'dmsetup info'?
[05:28] <Keybuk> siretart: ah, use "info" on Debian
[05:29] <siretart> Keybuk: http://paste.debian.net/29175
[05:29] <siretart> why is debian different here?
[05:29] <siretart> upstream change?
[05:29] <Keybuk> "export" is a patch from SuSE to output all of the info in a format udev can import
[05:30] <Keybuk> could you try "table" instead of info, I think that's the right one
[05:30] <siretart> ah, sounds useful
[05:30] <Keybuk> we have a similar patch for mdadm as well, so udev can grok the array states, etc.
[05:30] <shawarma> Where do core dumps end up these days?
[05:30] <siretart> Keybuk: http://paste.debian.net/29176
[05:31] <siretart> shawarma: in apport
[05:31] <mpt> glatzor, that's got very good padding and capitalization and everything, but I don't understand how to use it
[05:31] <shawarma> siretart: er... Not on the filesystem somewhere?
[05:31] <Keybuk> siretart: ok, cool
[05:32] <Keybuk> so we can match those with ENV{DM_TARGET_TYPES}=="*crypt*"
[05:33] <shawarma> There's not way to get a regular core dump?
[05:34] <siretart> shawarma: doesn't ulimit -c unlimited help?
[05:34] <shawarma> siretart: Well, it said "core dumped", but I couldn't find it anywhere. I expected it in my $CWD..
[05:34] <Mithrandir> shawarma: you need to echo "core" | sudo tee /proc/sys/kernel/core_pattern
[05:35] <mpt> glatzor, but that's not necessarily worse than the previous design :-) Anyway, I'll have a more thorough look in the morning
[05:35] <shawarma> Mithrandir: even though 'cat /proc/sys/kernel/core_pattern' already says core?
[05:35] <Mithrandir> shawarma: hm, then you should indeed have it in cwd.
[05:35] <shawarma> Mithrandir: Ah, there we go.
[05:36] <shawarma> Mithrandir: Odd. 
[05:36] <shawarma> Mithrandir: I did /etc/init.d/apport stop, but I triggered the core dump since then and it didn't work then.
[05:36] <shawarma> Mithrandir: But now it works. Yay!
[05:38] <siretart> Keybuk: tell me more about the "progress output" agent. is there a spec for it? who is working on that/
[05:38] <siretart> ?
[05:39] <Keybuk> siretart: no spec, nobody working on it
[05:39] <Keybuk> it's something we need though, obviously
[05:42] <afflux_> siretart: building of -1ubuntu3 on my own solved the issue. thank you!
[05:42] <siretart> Keybuk: well, anyway. if we want to integrate crypysetup with udev, we need to have some kind of user intervention. which is strange here, because cryptsetup generally expects to be run from the user context. with udev, it runs from a 'system' context
[05:43] <siretart> Keybuk: and getting from udev back in some user context is, well. interesting at least
[05:43] <siretart> afflux_: thanks for confirming
[05:43] <siretart> afflux_: does luksformat work for you?
[05:43] <Keybuk> I was looking at the initramfs-tools script you have, you see
[05:43] <Keybuk> which is, err, massively complex and overweight
[05:43] <Keybuk> and probably causes all sorts of problems
[05:43] <Keybuk> since it tries to run lvm, evms, etc.
[05:43] <siretart> afflux_: (it doesn't for me, I cannot open created devices)
[05:44] <siretart> yes, it sucks for obvious reasons
[05:44] <siretart> Keybuk: may udev scripts block and ask for passwords?
[05:45] <siretart> in that case we could get along with integrating cryptsetup with udev in initramfs only
[05:45] <siretart> this way we would leave out the X11 part, and only deal with console and usplash (which would cover the serial console use case as well)
[05:45] <siretart> for gnome, we have hal and gnome-vfs
[05:45] <Keybuk> they could, but after 3m wait, udev would assume they'd hung and kill them
[05:46] <siretart> that's a sane assumption
[05:46] <Keybuk> initramfs only would break for /home under cryptsetup, no?
[05:46] <afflux_> there is a problem for me too in the initramfs script. A minor one since I know how to fix it. I have my cryptroot partition on /dev/sda10, this is a s-ata drive. It seems to be enabled later than expected from the script, so it would be good to have some sort of loop that checks if the device gets listet in the next X seconds. Can provide a patch in about 10 minutes.
[05:46] <siretart> if the user doesn't manage to enter his password in less than 3 minutes, we can perhaps safely abort
[05:47] <siretart> Keybuk: why would it break?
[05:47] <Keybuk> siretart: those aren't mounted in initramfs
[05:47] <Keybuk> you'd need the same setup for pre-X boot 
[05:47] <siretart> good point
[05:48] <siretart> Keybuk: how would udev know which devices to open? - assuming we have 3: /, swap and /home, which one should get opened in initramfs?
[05:48] <Keybuk> it actually does them all
[05:48] <siretart> afflux_: Keybuk and I are basically discussing a solution for that problem. There are already at least 2 open bugs with proposed patches for that
[05:49] <Keybuk> restricted on which drivers are available
[05:49] <siretart> which would break semantics, wouldn't it?
[05:49] <Keybuk> you should certainly support someone plugging in a USB key halfway through the boot sequence
[05:49] <Keybuk> semantics?
[05:49] <siretart> well, ATM, we only mount /, and not /home in initramfs. with cryptsetup run from udev, all devices would get opened in initramfs, no?
[05:50] <afflux_> siretart: oh, didn't see the connection. have no idea about udev. ;)
[05:50] <Keybuk> siretart: what's wrong with that?
[05:51] <siretart> Keybuk: well, think about cases where you have keys on your /root partition, which is crypted by a keyfile on usb. udev won't be able to mount /home, and the user can't provide a password, since he has only a keyfile, which is on /
[05:51] <siretart> so udev would bug the user unnecessarily
[05:52] <Keybuk> the keyfile would fail to open, and cryptsetup would terminate unsuccessfully, surely?
[05:52] <Keybuk> I'm trying to eliminate all "Point Of No Return" from the boot sequence
[05:52] <siretart> from udev, you don't see if a device needs a password or a keyfile
[05:52] <Keybuk> "you must have your USB key plugged in by this point or it won't get mounted" is bad
[05:52] <siretart> it might work with both
[05:53] <siretart> or with just one of the two
[05:54] <siretart> Keybuk: I rather think it wouldn't be unreasonable to mandate using a /etc/crypttab, which explains the parameters for unlocking /
[05:54] <siretart> Keybuk: and udev would then only open that device in initramfs
[05:54] <siretart> Keybuk: later in the boot process, the other filesystems listed in /etc/crypttab are mounted (like /home, swap, etc)
[05:55] <Keybuk> that's certainly doable
[05:55] <Keybuk> of course, if / is mounted by UUID, how do you know which crypted filesystem is the one to unlock? :p
[05:56] <siretart> I know from /etc/crypttab?
[05:58] <siretart> udev would grep it and compare it's UUID/something to check if that's the root device
[05:59] <Keybuk> that kind of extra configuration makes me feel sad
[06:02] <glatzor> mpt: a tired usability engineer is perhaps a good indicator for if the dialogs work or not :)
[06:03] <Keybuk> glatzor: how will that interact with xrandr ?
[06:04] <glatzor> Keybuk: depending in which state XRandR will be at the Gutsy release.
[06:04] <siretart> Keybuk: indeed, I don't feel to happy about it as well; however I don't see really any other sane approach to manage it
[06:05] <bryce> morning
[06:05] <kylem> morning bryce
[06:05] <glatzor> Keybuk: The idea was to base the configuration on the traditional xorg.conf and only use xrandr to apply changes instantly
[06:05] <Hobbsee> Mithrandir: or another archive admin:  please give back kdegraphics and krita
[06:06] <desrt> Keybuk; going to school now
[06:07] <glatzor> Keybuk: mvo started hacking on xrandr 1.2 python bindings. would be nice if he would be given more time for this :)
[06:09] <glatzor> Keybuk: the problem is that there are still many cards that will not have got xrandr 1.2 support in the near future
[06:09] <glatzor> Keybuk: And we have got not idea about the AMD and NVIDIA plans. Also taking the legacy cards into account.
[06:10] <Keybuk> glatzor: but for those cards that do support xrandr properly, you don't really want to write them an xorg.conf "hard-coding" that layout
[06:10] <glatzor> Keybuk: If we would live in a better world I would like to base it only on XRandR too.
[06:10] <Keybuk> it'd be nicer to leave them conf-less, and instead restore their last layout and give them the option to change it on the fly
[06:10] <glatzor> Keybuk: that is not an exclusive approach.
[06:11] <siretart> can archive admins sync from any .dsc file or just from debian?
[06:11] <Keybuk> siretart: see, I'd kinda like to support somebody who wanted /, /home and /usr each as encrypted LVM LVs, combined from a MD RAID-5 selection of disks, with each underlying disk encrypted as well.
[06:11] <glatzor> Keybuk: but one problem is the assigned memory for the maximum resolution.
[06:11] <Keybuk> siretart: the passphrases for each of these elements obtained from a USB key, the filesystem of which is encrypted with my fingerprint as the passphrase
[06:12] <Keybuk> siretart: that's somewhat complex to express in crypttab? :p
[06:12] <siretart> Keybuk: where is the problem with that?
[06:12] <glatzor> Keybuk: X seems to be quite conservative. so you cannot access all available resolutions with xrandr
[06:12] <Keybuk> siretart: it requires a lot of elements, no?
[06:13] <siretart> Keybuk: the format could be "<devmappername> <blockdevice> <keytype> luks"
[06:14] <siretart> where keytype is either a pathname to a keyfile, 'none' for passphrase, or other magic think you want to support
[06:14] <glatzor> Keybuk: If I don't use any xorg.conf on my t60 with an intel card I am stuck to 1280x1280. which is really not enough for two desktops. 
[06:14] <Keybuk> siretart: s/devmappername/UUID/ no?
[06:14] <Keybuk> glatzor: have you tried the -intel driver in gutsy?
[06:14] <glatzor> Keybuk: no debian unstable.
[06:15] <siretart> Keybuk: you'll need a devmappername for practical reasons. cryptsetup works with the devicenames from /dev/mapper, not with uuids. but we can perhaps add the uuid as well
[06:15] <glatzor> Keybuk: I tried gutsy some days ago, but xrandr didn't work
[06:15] <glatzor> Keybuk: and I haven't tested it again since that time.
[06:15] <glatzor> hello bryce, by the way
[06:15] <bryce> heya glatzor
[06:16] <glatzor> bryce: I implemented the dump and read pci table function of the guidance backend in displayconfig
[06:17] <bryce> glatzor: cool
[06:17] <glatzor> bryce: this is a quite nice feature, since it allows us to reproduce errors very exactly
[06:18] <glatzor> bryce: have you been in contact with anyone from Intel, AMD or NVIDIA?
[06:19] <glatzor> bryce: would be nice if we could get some more information for the xorg.conf options of every card
[06:20] <bryce> yes to Intel; I know AMD's open source lead (but he hasn't interacted too much with ATI so far); from nvidia I've traded bug reports with a person from there but don't really know him
[06:20] <glatzor> bryce: I made some patches to support the intel i810 driver (or better said my laptop) better
[06:20] <bryce> agreed; however many cards simply have nvidia or whatever chipsets, but the actual hardware implementation is from other vendors
[06:21] <glatzor> bryce: I now use displayconfig-gtk on a daily basis :)
[06:21] <bryce> is it enough in every case to simply have the chipset's details? 
[06:22] <bryce> cool, yeah I was playing with it a bit friday.  I've been setting up new test hardware and using it to check that I can manipulate the drivers and rez on them
[06:22] <glatzor> bryce: For example I don't know which Intel cards require the MonitorLayout option. It is needed to get dual head working on my computer. but there seem to be other cases since this was not yet implemented in the backend. (or the backend made a bad show on Intel systems :)
[06:24] <bryce> hmm
[06:24] <glatzor> bryce: how was your overall experience with the proprietary drivers?
[06:24] <glatzor> bryce: I don't have got any NVida/ati systems to test here.
[06:25] <bryce> pretty seamless, although I didn't spend much time on them and didn't test beryl or anything nontrivial
[06:25] <bryce> no prob, I've got several nvidia/ati systems.  I'm actually short on intel
[06:25] <glatzor> bryce: Furthermore in my patch I made the perhaps most conservative assumption and set the MonitorLayout to internal screen and external vga.
[06:26] <glatzor> bryce: but I have got no idea what the impact on systems with a tv out are :/
[06:27] <glatzor> bryce: Oh, I am only interested in changing the resolution and extending and cloning desktops :) beryl is out of scope for me :)
[06:27] <bddebian> Heya
[06:27] <glatzor> bryce: if you want, you could send my some pci table dumps :)
[06:28] <glatzor> bryce: it would be nice to have a good feeling about getting nvidia systems detected correctly by displayconfig
[06:28] <glatzor> feeling
[06:29] <glatzor> bryce: do you plan to do a feature matrix for beryl?
[06:30] <glatzor> bryce: if so, we could also add works with displayconfig
[06:31] <glatzor> bryce: perhaps it would be a good idea to setup a wiki page and ask the users in a blog post and on the forums to add information about working dual head configurations there.
[06:32] <glatzor> bryce: steve harms seems to be interested in getting a working x configuration tool tool. I haven't meet him yet online, but I think that he is more next to your time zone :)
[06:33] <bryce> for the pci table dumps, just lspci -n ?
[06:34] <glatzor> no it's a dump of the internal pci table of displayconfig
[06:34] <bryce> I'll plan on playing around with displayconfig on nvidia.  I haven't seen problems on radeon so far
[06:34] <bryce> ah, how do I retrieve that?
[06:34] <glatzor> bryce: just update the ubuntu branch of displayconfig-gtk
[06:34] <glatzor> I merged it today
[06:35] <bryce> I think having an area where users can post working multi-screen configs would be excellent
[06:35] <bryce> ah cool, okay
[06:36] <glatzor> bryce: yesterday I started working on the actual user interface again, since I am not very happy with the current approach. it has got some problems in the workflow
[06:36] <glatzor> bryce: http://glatzor.de/filesink/dcg-gfxbase.png
[06:37] <glatzor> this is another approach. but it seems to be a bit messed up.
[06:37] <bryce> yeah
[06:37] <bryce> I've been thinking about the dual/multi monitor gui layout, and one thought I've had is it feels like there should be a tab per screen
[06:38] <bryce> so then adding a third or fourth monitor would involve simply creating another copy of the base panel in a new tab
[06:39] <bryce> however since cards often have multiple monitor outputs, that could make things a tad more complex
[06:40] <glatzor> bryce: each graphics card is represented by its own tab in this design approach
[06:40] <glatzor> bryce: so you only the outputs of the corresponding card on each tab
[06:41] <glatzor> but perhaps I have only to find better way for including the selector
[06:41] <glatzor> the thing on the left side
[06:41] <glatzor> http://glatzor.de/bzr/displayconfig-gtk/gfxbase/
[06:42] <glatzor> bryce: If you want to test here would be the branch
[06:42] <glatzor> just ./displayconfig-gtk --data-dir=data
[06:43] <bryce> yeah I've just wondered from a usability point of view, most non-technical people won't have much clue what a "video card" is, but they'll know what a monitor screen is
[06:43] <bryce> so tabs of video cards may appear to be geek to them
[06:43] <glatzor> bryce: yes. you are right.
[06:43] <glatzor> bryce: but most people only have got one card :)
[06:44] <glatzor> bryce: and the people that use two cards for their dual screen setup would know about the used cards
[06:44] <glatzor> since they perhaps had to add a second card.
[06:45] <glatzor> bryce: I agreed with mpt to take this issue to the ubuntu-desktop list and discuss it there
[06:46] <glatzor> bryce: but I can still point you to another problem I mentioned earlier with the workflow (as a daily user of displayconfig-gtk I got annoyed by this too :)
[06:47] <glatzor> if you for example connect a new monitor to your laptop, you go to the devices tab and select the monitor model, then you go to tab 2 and set e.g. extend my primary screen.
[06:48] <glatzor> mostly you will forget to also set the correct resolution on the first tab :)
[06:48] <glatzor> most times
[06:49] <bryce> yeah I ran into that too
[06:50] <bryce> having to shift between multiple tabs to do one activity (get a monitor/card set up), is probably not great usability
[06:50] <Keybuk> asac: firefox needs a "restart" option ;)
[06:51] <glatzor> bryce: and this will be perhaps the most needed task
[06:52] <glatzor> bryce: and the location chooser is really a must have 
[06:54] <Treenaks> argh.. I shouldn't have upgraded to gutsy
[06:55] <simira> :)
[06:55] <simira> hmm, maybe it's time soon...
[06:55] <Treenaks> simira: I miss my evince
[06:55] <asac> Keybuk: for what?
[06:59] <Mithrandir> Treenaks: you should have let it keep back poppler, then
[06:59] <Treenaks> Mithrandir: I know, I know
[07:00] <Treenaks> Mithrandir: oh well, I gues it'll be fixed before release ;)
[07:00] <Treenaks> +s
[07:00] <asac> Keybuk: https://addons.mozilla.org/en-US/firefox/addon/3458
[07:00] <seb128> Treenaks: what arch do you use?
[07:00] <Treenaks> seb128: i386
[07:00] <seb128> Treenaks: what is the problem with evince on i386?
[07:00] <Mithrandir> Treenaks: "not unlikely"
[07:01] <Treenaks> seb128:   libpoppler1-glib: Depends: libpoppler1 (= 0.5.4-0ubuntu8) but 0.5.4-4ubuntu2 is to be installed
[07:01] <asac> Keybuk: ... and there is even choice for that simple usecase ;) ... see https://addons.mozilla.org/en-US/firefox/search?q=restart&status=4
[07:02] <seb128> Treenaks: I've accepted the binaries (they were to NEW due to the new evince-gtk)
[07:02] <Treenaks> seb128: ah, great
[07:02] <seb128> Treenaks: the rebuild should be available next run
[07:03] <Treenaks> seb128: great, thanks :)
[07:03] <seb128> you're welcome
[07:04] <Keybuk> asac: for when I've updated an add-on, and it wants me to restart firefox to be able to use it
[07:04] <Keybuk> asac: right now I kill -9 it
[07:05] <Hobbsee> can someone tell me why it's 3am, and im still up?
[07:05] <Keybuk> (closing it normally doesn't prompt me to restore my session <g>)
[07:06] <seb128> Hobbsee: because you try to build KDE? ;)
[07:06] <seb128> Hobbsee: you should try GNOME, it builds faster and could be to bed already :p
[07:06] <Hobbsee> seb128: no.  i asked for a giveback on a couple of it, though.
[07:06] <Hobbsee> s/it/bits/
[07:06] <Hobbsee> seb128: that means i'd have to tolerate gnome.
[07:06] <Hobbsee> and no one did the giveback.  darn
[07:07] <Mithrandir> Hobbsee: you did?
[07:07] <Mithrandir> Keybuk: you can change that
[07:07] <Hobbsee> [02:05]  <Hobbsee> Mithrandir: or another archive admin:  please give back kdegraphics and krita
[07:08] <Mithrandir> Keybuk: edit - preferences - main page - start page - when firefox starts: "show windows and tabs as they were when I quit"
[07:08] <asac> Keybuk: ... and you are not offered the option to restart firefox after extension install/update ... sounds like its worth a bug. You do manual updates, right?
[07:08] <Hobbsee> Mithrandir: ie, yes.
[07:08] <Mithrandir> Hobbsee: seems I missed them, then
[07:08] <Hobbsee> seems so
[07:08] <Mithrandir> Hobbsee: anyway, krita isn't a source package.
[07:09] <Hobbsee> Mithrandir: oh, koffice sorry
[07:09] <Lure> Mithrandir: giveback kdegraphics too
[07:09] <Hobbsee> Lure: see first statement
[07:10] <Mithrandir> Hobbsee: btw, you need a buildd admin, not an archive admin.
[07:10] <Mithrandir> but, both given-back
[07:10] <Lure> Hobbsee: I am not sleepy, but still cannot properly read your paste ;-)
[07:10] <Keybuk> asac: the update turned up while I was running firefox; I clicked Find New Updates, and it said it had been updated and I needed to restart firefox, but never gave me the opportunity to do that
[07:10] <Hobbsee> Mithrandir: ahh.  i thought they were the same.
[07:10] <Keybuk> Mithrandir: I don't want it all the time ... since that's erm, likely to cause embarassment :p
[07:10] <Hobbsee> Lure: heh.  try again :)
[07:10] <Mithrandir> Keybuk: hehe, ok
[07:11] <Keybuk>  * Scott is looking at porn, and closes the browser quickly when his Mother pops round.  She runs Firefox to look at something.  Scott would prefer not to be embarassed.
[07:11] <Hobbsee> you let your mother access your computer?
[07:11] <Mithrandir> Hobbsee: s/your computer/your account/, you mean?
[07:11] <Hobbsee> either.
[07:11] <kylem> Keybuk, *HAH*
[07:11] <Hobbsee> but yes
[07:12] <seb128> Hobbsee: "archive admin" != "buildd admin" btw, you need a buildd admin to give a build retry
[07:12] <Hobbsee> when you have the only user account on your computer, these two are directly substituable.
[07:12] <Hobbsee> seb128: so Mithrandir said.  noted.
[07:12] <Hobbsee> thanks.
[07:12] <seb128> np ;)
[07:12] <Hobbsee> seb128: requires knowing who the buildd admins are though
[07:12] <seb128> Mithrandir
[07:12] <Mithrandir> Hobbsee: you clearly have too few personalities if you just have your own account on the machine.
[07:12] <Hobbsee> seb128: ah, so just Mithrandir?
[07:13] <seb128> infinity also
[07:13] <Hobbsee> Mithrandir: heh.
[07:13] <Hobbsee> point
[07:13] <Mithrandir> Hobbsee: doko and scott can give back packages too, but I'm fine with taking those requests.
[07:13] <Hobbsee> ah, gotcha
[07:13] <seb128> but usually Mithrandir is the one reading the chan I think
[07:13] <benkong2> hello all. How can I learn why a particular feature was chosen and how it was implemented in Ubuntu?
[07:13] <Hobbsee> now there's quadruple trouble from the girls from au!
[07:13] <benkong2> as an example using a modprobe.d/ instead of a modprobe.conf file
[07:14] <Keybuk> benkong2: that feature was neither chosen for or implemented for Ubuntu
[07:14] <Keybuk> rather that's the way it comes from upstream
[07:14] <Keybuk> (the general answer would be to look at https://blueprints.launchpad.net/ubuntu for the specifications; and read them)
[07:14] <benkong2> and upstream means what or who?
[07:15] <Hobbsee> gnome, kernel,...
[07:15] <Keybuk> module-init-tools upstream
[07:15] <benkong2> Keybuk, ok thanks
[07:15] <Keybuk> authors of modprobe
[07:15] <Keybuk> that's how it comes "out of the box"
[07:15] <benkong2> checking now
[07:15] <benkong2> I am building a LinuxFromScratch build and was just curious. Trying to understand the underbonnet stuff
[07:16] <Keybuk> generally a ".d" directory is preferred to a ".conf" file
[07:16] <Keybuk> since any package can place files in the directory, and modify them, or remove them
[07:16] <Keybuk> whereas the conf file requires manual editing, and dealing with user changes, etc.
[07:16] <Keybuk> Hobbsee: just me
[07:17] <Mithrandir> seb128: you just implied I don't have a life, but that's ok. :-P
[07:17] <Hobbsee> oh right
[07:17] <benkong2> I agree and I wanted to try and change that in the LFS build] 
[07:17] <Hobbsee> Mithrandir: we all knew that anyway.  :P
[07:17] <seb128> rofl
[07:18] <Hobbsee> it's fucking confusing when the only other employees in the store are called scott!
[07:18] <seb128> Mithrandir: no, that's just your are the one replying to most of the "could somebody give a retry to" on the chan ;)
[07:18] <Hobbsee> sure, i can put you thru to him...just WHICH ONE????  
[07:18] <bryce> pick at random?
[07:19] <Hobbsee> bryce: i tend to, yes.  "whichever one answers" is usually a good solution.
[07:38] <keescook> Keybuk: delayed pong
[07:47] <Hobbsee> sbalneav: apologies
[07:53] <Mithrandir> seb128: what was your decision on the gtk patch we talked about?
[07:55] <seb128> Mithrandir: I think we can use it, I didn't do much today (was on VAC) but I'll upload tomorrow morning if that's ok with you
[07:56] <Mithrandir> seb128: that sounds great with me.
[07:56] <seb128> good ;)
[07:56] <Mithrandir> I didn't realise you weren't really here, sorry about that.
[07:57] <seb128> no problem don't worry ;)
[08:15] <Keybuk> keescook: just having dinner, will get back to you later
[08:15] <keescook> Keybuk: okay.  what topic, btw?
[08:15] <Keybuk> devmapper, lvm, etc.
[08:15] <keescook> cool, ttyl
[08:19] <glatzor> mpt: bryce: I wrote a quite lengthy mail to ubuntu-desktop
[08:20] <bryce> glatzor: cool
[08:21] <bryce> glatzor, btw one thing we should think about is some unit tests for displayconfig-gtk
[08:27] <glatzor> bryce: when we have got collected some configs and pci table dumps this would be really a good idea.
[08:28] <glatzor> Changing something in the backend and perhaps breaking all nvidia cards is really scary :)
[08:28] <bryce> yup
[08:32] <glatzor> bryce: sometimes I ask myself what I have done picking up this project :)
[08:36] <bryce> glatzor: :-)
[08:36] <robertj> is there a way to run through dpkg-buildpackage without trying to patch again?
[08:42] <keescook> cjwatson: did you get a chance to double-check the final debdiff for bug 106887 ?  I'd like your ACK before I upload it.
[08:42] <ubotu> Launchpad bug 106887 in grub ""ALERT! does not exist" at boot with ICH7" [Undecided,Confirmed]  https://launchpad.net/bugs/106887
[08:49] <glatzor> bryce: oh, I've forgotten to push my local changes to the ubuntu branch
[08:49] <glatzor> bryce: the pci table feature should now be included
[08:51] <glatzor> bryce: furthermore I asked the guidance guys if they have already worked on an unit test yet.
[08:52] <bryce> good - have they?
[08:53] <Keybuk> keescook: I'm not sure, but I may have reverted your fix
[08:53] <Keybuk> I'm not sure whether it was the device node going missing you were worried about
[08:53] <Keybuk> or the vol_id issue
[08:55] <afflux> keescook: You wanted me to keep you informed on my progress in the wordpress CVE bug. I noticed that the debian version that fixed these bugs also fixed about 7 other security vulnerabilities and I think it gets quite complicated to fix them all. I'd suggest to update to 2.0.10 (or newer?).
[08:56] <keescook> afflux: doing a full-version update seems like a dangerous thing.  for that to happen, we should get sign-off from the motu council, likely.
[08:57] <keescook> Keybuk: I made two uploads over the weekend; one to udev to add missing documentation, and one to devmapper to fix an over-aggressive udev rule
[08:58] <keescook> I'll go check devmapper
[09:03] <keescook> Keybuk: hm. based on what I've seen, the "snapshot" and "snapshot-origin" DM_TARGET_TYPES are actually the _final_ state of the devices.  It seems sensible to run vol_id on those.
[09:04] <keescook> oh! no, wait, I understand
[09:04] <keescook> the issue is having the various snapshots fighting over the fs UUID.  I get it.  Cool.
[09:06] <keescook> one issue I see here is that as-is, the fs UUID map will vanish when I create a snapshot (since the "origin" device switches from "linear" to "snapshot-origin"), leaving _no_ device associated with the original fs UUID.  Is that desirable?  Perhaps not ignore "snapshot-origin" and just ignore "snapshot"?
[09:12] <Keybuk> keescook: actually that's not the issue
[09:12] <keescook> Keybuk: yeah, I wasn't able to reproduce my fear.  uuid link remains
[09:13] <Keybuk> there is indeed some confusion about how we identify the "exception clearing" node that LVM creates as part of lvcreate -s, that we absolutely do not want to run vol_id on
[09:13] <keescook> er, no, it moves
[09:13] <Keybuk> hmm, how do you mean the UUID map shifts?
[09:13] <keescook> pastebin coming..
[09:13] <Keybuk> better question
[09:13] <Keybuk> which one should the UUID point to?
[09:14] <Keybuk> which of the following would you ever attempt to mount, and which would you absolutely not?
[09:14] <Keybuk> vg-original
[09:14] <Keybuk> vg-snapshot
[09:14] <Keybuk> vg-snapshot-cow
[09:14] <Keybuk> vg-original-real
[09:14] <keescook> -cow and -real are not mountable ever
[09:14] <keescook> -original and -snapshot are both valid
[09:15] <Keybuk> heh, amusingly -cow and -real are the ones with the linear map
[09:15] <Keybuk> -original has snapshot-origin table type, and -snapshot has a snapshot table type
[09:15] <keescook> right, from what I can see, all the lv are initially created as "linear" and then lvm goes and tweaks their internal settings?  I'm not sure.
[09:15] <Keybuk> from tracing LVM, we don't think there's a problem running vol_id on any of the "final" nodes
[09:16] <keescook> right, but it changes during their creation lifetime
[09:16] <Keybuk> the problem comes of running vol_id on the -snapshot node when it's linear, and not snapshot
[09:16] <keescook> but there doesn't seem to be any information about it to detect that it will "become" a snapshot type.  :(
[09:16] <Keybuk> At the point (1) udev already run vol_id on vg-snapshot. This LV is only
[09:16] <Keybuk> created to delete the exception table of the snapshot to be created. So
[09:16] <Keybuk> lvcreate tries to remove the still open vg-snapshot.
[09:17] <Keybuk> (from Kay)
[09:17] <Keybuk> that's from a SuSE EL bug
[09:17] <keescook> hm
[09:18] <Keybuk> which is consistent with the bug we're seeing
[09:18] <keescook> here's the uuid moving, btw: http://paste.ubuntu-nl.org/23143/
[09:18] <Keybuk> we vol_id the first device node, and race lvm needing to change it
[09:19] <keescook> the fs uuid moves to -real (which is wrong).  It should either stay on the snapshot-origin, or it should follow the most recent snapshot (kind of insane)
[09:19] <Keybuk> ok
[09:19] <Keybuk> that follows
[09:19] <Keybuk> we'd need some way to match the -real and -cow devices to avoid them ever taking the UUID
[09:19] <Keybuk> are they hardcoded to those names?
[09:19] <keescook> they seem to be, yes.
[09:19] <`23meg> glatzor, regarding bug 117429, did update manager use to display total size of installed files for metapackages?
[09:19] <ubotu> Launchpad bug 117429 in update-manager "Does not show new dependencies of updates" [Undecided,Confirmed]  https://launchpad.net/bugs/117429
[09:19] <Keybuk> can I make a device of my own with those names?
[09:20] <Keybuk> actually
[09:20] <Keybuk> easier way
[09:20] <keescook> I haven't tried trying to intially collide with the reserved names.
[09:20] <Keybuk> just increase the link_priority of a device with table type snapshot or snapshot-origin <g>
[09:20] <Keybuk> can you try something for me
[09:20] <keescook> I know lvcreate won't let you use "snapshot" as a name, though
[09:20] <keescook> sure
[09:20] <Keybuk> edit /etc/udev/rules.d/65-dmsetup.rules
[09:21] <keescook> I think only snapshot-origin should get the bump; I don't think it's sensible to move the fs UUID to the "most recent snapshot"
[09:21] <Keybuk> remove the *snapshot*| bit
[09:21] <glatzor> `23meg: the total download size is not calculated by adding all sizes of the displayed updates but by apt in the background.
[09:21] <Keybuk> then at the bottom, you'll see it set the link_priority
[09:21] <Keybuk> that should read
[09:22] <glatzor> `23meg: apt only takes a look what needs to be changed to install all these updates.
[09:22] <Keybuk> ENV{DM_TARGET_TYPES}=="snapshot-origin", OPTIONS+="link_priority=-90"
[09:22] <Keybuk> ENV{DM_TARGET_TYPES}!="snapshot-origin", OPTIONS+="link_priority=-100"
[09:22] <glatzor> `23meg: meta packages as meta packages are only visible to humans. Apt treats them as normal packages.
[09:23] <`23meg> glatzor, I understand; I agree with displaying metapackage size in the current state of things, but it seems the bug ended up pointing to something other than what it intended :)
[09:23] <keescook> Keybuk: testing now
[09:24] <keescook> Keybuk: yup, that works.  the uuid stays mapped to the origin
[09:24] <glatzor> `23meg: that is what makes bug triage fun :) sometimes ...
[09:25] <`23meg> agreed, sometimes..
[09:27] <Keybuk> keescook: shiny
[09:28] <Keybuk> ok, have uploaded a devmapper to fix up the rules to behave that way
[09:28] <keescook> Keybuk: cool.  I'm glad I gave myself a crash-course in udev debugging this weekend.  I finally feel like I can help with this goo.
[09:28] <Keybuk> hopefully upstream will get back to me on the "ignore the first node" fix soon
[09:28] <keescook> instead of just opening bug reports.  ;)
[09:28] <Keybuk> when udev works, it actually does work really nicely
[09:28] <keescook> so, as I understand, we still have the vol_id race, right?
[09:29] <Keybuk> the udevmonitor output with all the dmsetup info in it is really nice
[09:29] <Keybuk> yeah, we still have the "in use: not deactivating" race
[09:29] <keescook> ironically, I haven't run into it since updating devmapper.  :P
[09:30] <Keybuk> that's because devmapper is a bit more likely to win the race atm
[09:30] <Keybuk> previously it span until dev made the device, which means it was likely to hit vol_id
[09:30] <keescook> cool.
[09:30] <Keybuk> now devmapper returns immediately having made the device node itself, and some time later, udev twiddles the permissions on the node
[09:31] <Keybuk> (actually, right now it replaces the node with a symlink, but that's for debugging)
[09:31] <keescook> I'm thinking about setting up a gdb breakpointer to be able to reproduce the race.
[09:31] <keescook> I've got a gdb bash script harness for doing this to things in general (for testing security races)
[09:31] <Keybuk> this is temporary though
[09:31] <Keybuk> upstream want the devmapper ioctl()s to not return until the udev event has finished processing
[09:32] <Keybuk> race: stop the devmapper library call as it returns; stop vol_id as it runs
[09:32] <keescook> yeah, that seems sane.  are there problems with that from a kernel perspective?
[09:32] <Keybuk> step through vol_id until the device is open
[09:32] <Keybuk> continue the proecss that calls devmapper
[09:32] <Keybuk> kernel currently doesn't have any notification from udev that it's done
[09:32] <keescook> ah
[10:08] <Adri2000> I wonder why my last upload appeared on LP exactly one hour after I actually did the upload, it used to be really faster
[10:13] <Keybuk> Adri2000: did you do the upload on the hour?
[10:14] <Keybuk> we've had hour-long days ever since we used LP
[10:15] <Adri2000> "on the hour" what do you mean?
[10:15] <Keybuk> uploads are processed once an hour
[10:15] <Keybuk> if you do the upload a second after it starts processing, it won't happen until the next hour
[10:16] <Adri2000> ahh ok, I thought it was something like 5 minutes
[10:16] <Adri2000> or at least we receive the accepted mail within 5 minutes, but then it's longer to show up on LP ?
[10:24] <Keybuk> exactly
[10:44] <robertj> can someone please mark #109250 as confirmed?
[10:45] <robertj> bug #109250 is a regression as well
[10:45] <ajmitch> robertj: you can change the status, just not importance
[10:45] <ubotu> Launchpad bug 109250 in apache2 "/etc/init.d/apache2 doesn't do "chown www-data /var/lock/apache2" after directory creation" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109250
[10:47] <ajmitch> if you're logged in, somehow I got logged out again
[10:47] <robertj> I'mlogged in, but don't see the option
[10:47] <ajmitch> under "Affects", click on apache2 (ubuntu)
[10:48] <robertj> ahh
[10:48] <ajmitch> not completely obvious
[11:16] <svu> what happened to alternate images of feisty? they are not there for ubuntu
[11:20] <ccm> svu: http://www.ubuntu.com/getubuntu/download
[11:20] <mrsn0> svu there are alternate images
[11:20] <ccm> svu: "Check here if you need the alternate desktop CD. This CD does not include the Live CD, instead it uses a text-based installer."
[11:20] <svu> ccm, thanks. for some reason I do not see it in cdimage.ubuntu.com...
[11:21] <ccm> svu: no problem
[11:21] <ccm> svu: you should better refer to www.ubuntu.com in the first place
[11:21] <mrsn0> svu its on cdimage, but a different date candidate was used than normal ubuntu livecd
[11:21] <Mithrandir> svu: they're on releases.ubuntu.com.
[11:21] <mrsn0> http://cdimage.ubuntu.com/daily/20070529/
[11:21] <svu> ccm, it seems you're right. thanks again
[11:22] <svu> mrsn0, oh please no daily stuff:)
[11:22] <Mithrandir> current dailies are, or should be, broken
[11:22] <svu> Mithrandir, I see now. What's the differernce between cdimages.u.c and releases.u.c?
[11:22] <elmo> could someone add some text to the top of cdimage.ubuntu.com pointing users at releases.u.c?
[11:23] <Mithrandir> elmo: yes, I can do so
[11:23] <svu> wise action
[11:23] <Mithrandir> svu: cdimage.u.c contains stuff which either changes rapidly (dailies) or which we don't believe will have a too big audience, like DVDs and ports.
[11:23] <ccm> svu: you could of course think about maintaing a jigdo copy for yourself, this is not "daily" stuff, but always a cd image an a very recent patch level
[11:23] <elmo> Mithrandir: bonus points if you can do it for every directory
[11:24] <svu> Mithrandir, I see... it was not clear from the names ...
[11:24] <elmo> Mithrandir: (which make require apache magic, so let me know, but I suspect/think y'all have .htaccess anyways)
[11:24] <svu> ccm, sure I won't :)
[11:24] <elmo> s/make/may/
[11:24] <ccm> svu: ;)
[11:25] <Mithrandir> elmo: yes, it'll probably require some magic.  I'll put it on my todo list for tomorrow since hacking apache configs close to midnight will make my wife angry when I crash at 0400.
[11:25] <svu> wifes always conflict with professional duties. that's desperate
[11:25] <elmo> Mithrandir: heh, ok - thanks.  I can file a bug instead if you'd prefer; it's not urgent, but it sounds like something obvious we should do at some stage
[11:26] <Mithrandir> svu: I prefer not to have professional duties around midnight. :-P
[11:26] <Mithrandir> elmo: yup, agreed.  I'm just tired so doing it now's not a good idea.
[11:27] <svu> Mithrandir, btw, would it be better to use x64 image for core2duo?
[11:27] <svu> (with the perspective to setup xen)
[11:29] <mrsn0> svu feisty images didnt change after release so they are the same images (md5 to confirm)
[11:29] <Mithrandir> svu: if you have gobs of ram, it would be, but in most cases it won't make much of a difference.  Some apps are a fair bit faster in 64 bit mode, some are a bit slower, but most will be slightly faster.
[11:30] <svu> mrsn0, ghm. 29.05 is not exactly feisty's release day, is it?
[11:30] <mrsn0> :)
[11:31] <svu> Mithrandir, 2G of RAM should be enough, I hope. Is xen ok with 64bit kernel?
[11:31] <Mithrandir> svu: it works for me, at least.
[11:31] <mrsn0> uh whoops that was gutsy
[11:31] <svu> good. I will give it a run too. I'll put vista inside if I manage to
[11:32] <svu> mrsn0, :)
[11:32] <mrsn0> 20070418/ was alternate image i think
[11:32] <mrsn0> in ports/daily/
[11:32] <mrsn0> but yes very  confusing to find the alternate, unless using ubuntu.com :p
[11:33] <Mithrandir> mrsn0: while in this particular case you happen to be correct, there's no guarantee of an image of a later date actually being the release image on cdimage.  For release images, please use releases.ubuntu.com (or a closer mirror)
[11:33] <svu> mrsn0, yes, that makes sense, 0418. anyway, it is already found...
[11:33] <dholbach> evince ftbfs on 64bit due to "relocation R_X86_64_32S against `kpse_format_info' can not be used when making a shared object; recompile with -fPIC"  (http://librarian.launchpad.net/7866732/buildlog_ubuntu-gutsy-amd64.evince_0.9.0-1ubuntu2_FAILEDTOBUILD.txt.gz)
[11:34] <mrsn0> Mithrandir indeed, for iso testing i used cdimage so thats why imentioned really while the finished images were on different dates they were all moved to the correct download site
[11:34] <Mithrandir> mrsn0: yes, I know.  It was I who did it. :-P
[11:34] <svu> anyway, thanks a lot to everybody for a lot of useful info
[11:34] <mrsn0> :-)
[11:34] <Mithrandir> dholbach: a library isn't compiled with -fPIC then
[11:34] <mrsn0> your welcome svu/ sorry for confusion
[11:35] <dholbach> mandriva builds tetex with -fPIC 
[11:35] <dholbach> should we do that with texlive-bin then?
[11:35] <Mithrandir> for any libs, yes.
[11:37] <dholbach> i'll take a look at it