[04:41] <TheMuso> c
[04:41] <TheMuso> argh wrong tab
[04:42] <RAOF> Heh
[06:24] <jdong> just ran past the /lib/linux-restricted-modules/.nvidia_new_installed snafu....
[06:24] <jdong> tha'ts a bit ridiculous, isn't it? shouldn't postrm of nvidia-glx-new delete that file?
[06:24] <jdong> otherwise after install n-g-n and trying to revert to any other n-g will fail
[07:09] <pitti> Good morning
[07:11] <ajmitch> hey pitti
[07:11] <ajmitch> how's it going?
[07:11] <LucidFox> Would it make sense to request a freeze exception for Theora at this stage?
[07:12] <pitti> hi ajmitch! pretty well
[07:12] <jdong> hasn't that been answered a day or two ago?
[07:12] <jdong> as a no, ABI/API breakage, ffmpeg stack affected, too risky?
[07:12] <pitti> I only said that there is no chance if it does break abi/api
[07:12] <pitti> but at this point I don't think that it is a good idea for beta at least
[07:13] <jdong> LucidFox: what does the new theora provide?
[07:20] <LucidFox> jdong> a new decoder implementing the complete specification
[07:21] <LucidFox> given how the Debian package name is still libtheora0, it probably doesn't break ABI - but it could have been Debian's oversight
[07:36] <tepsipakki> pitti: hey, there are two X driver updates that the X-SWAT would love to see in beta;
[07:37] <tepsipakki> nv 2.1.5: hasn't changed that much, but LVDS fix for G80 chips on some laptops, also adds support for a number of new chips (only added the pciid's so the driver would load)
[07:38] <pitti> tepsipakki: that sounds reasonable (I'd like to see a diff, though)
[07:38] <pitti> tepsipakki: can you please file FF exception bugs, attach diffs, and I'll review them there?
[07:38] <tepsipakki> ati 6.7.194: upstream says that 6.8 is close. This fixes, for instance, a crasher when you use Xv and change the desktop in compiz
[07:38] <tepsipakki> pitti: sure, this was just a heads up notice :)
[07:38] <pitti> oh, yay for more crash fixes :)
[07:39] <tepsipakki> also, it fixes more blank screen issues
[07:39] <pitti> tepsipakki: heads-up appreciated (for CD building planning, etc.)
[07:40] <tepsipakki> pitti: thanks, I'll do those when I get to work
[07:40] <StevenK> Morning pitti!
[07:40] <StevenK> pitti: There's a new gnome-build, do you want to rescue it from NEW?
[07:42] <pitti> StevenK: will do a bit later, when I'm back at my desktop (can't get to the DC from here)
[07:44] <fabbione> oh interesting bug
[07:48] <StevenK> pitti: Sounds fine. I'm just looking at the one and only rebuild for it.
[07:49] <fabbione> pitti: wanna have some fun? bug #144363
[07:49] <ubotu> Launchpad bug 144363 in sysvinit "/lib/init/mount-functions.sh: domount does not check if a mountpoint is already in use" [Undecided,New]  https://launchpad.net/bugs/144363
[07:50] <StevenK> Hrm. lamont touched sysvinit last. :-P
[07:50] <fabbione> StevenK: no change upload.. and this is a very old bug
[07:50] <fabbione> i just found enough motivation to look at it today
[07:51] <fabbione> need to understand why NFS mounts are not mounted at boot anylonger
[07:51] <lamont> StevenK: yeah - I just touched it lightly. :-)
[07:51] <lamont> pitti: I just filed the sync request for expect
[07:52] <lamont> (thought I did that earlier... maybe I did.... )
[07:53] <pitti> fabbione: eek, so many mounts on top of each other? strange, why does that happen only to you?
[07:53] <fabbione> pitti: i wonder if this is because this machine is a sid install upgraded to warty/hoary/breezy/dapper/edgy/feisty/gutsy?
[07:54] <fabbione> pitti: it might also be because i have stuff installed that i am sure you don't
[07:54] <pitti> fabbione: either sounds reasonable
[07:54] <fabbione> grep domount * -l
[07:54] <fabbione> mountdevsubfs.sh
[07:54] <fabbione> mountkernfs.sh
[07:54] <pitti> fabbione: I reinstall my machines twenty times with every release
[07:55] <fabbione> lamont: way different. yes i noticed too
[07:55] <lamont> pitti: long range upgrade testing is a _GOOD_ thing... we should do more of it..
[07:55] <lamont> then we'd find things like interactions between the current stuff and evms, for example...
[07:55] <lamont> which was stock on dapper? and not stock on gutsy
[07:55] <lamont> anyway, time for this one to sleep.
[07:56] <fabbione> pitti: i checked and indeed domount is invoked a bunch of times
[07:56] <fabbione> pitti: could you show me your fstab?
[07:56] <fabbione> pitti: that looks like the only tihng that might be deeply different
[07:58] <pitti> lamont: I agree
[07:58] <pitti> fabbione: there's nothing particularly worth mentioning about it, except that my 'post-ubuntu-install' setup script overwrites the uuid ones with my ancient /dev/xxx names
[07:59] <fabbione> pitti: do you have /var/run and /var/lock entries in there?
[07:59] <fabbione> because mine doesn't
[08:06] <pitti> fabbione: but I do have uuids on my desktop, and it doesn't happen there either
[08:06] <pitti> fabbione: nope, and it's not supposed to
[08:08] <fabbione> pitti: a grep for domount in /etc/init.d.. how many scripts have it and how many are really triggered? for instance I have nfs mounts and mountkernfs.sh is executed
[08:08] <fabbione> pitti: so perhaps it's conditional
[08:08] <pitti> fabbione: mountdevsubfs.sh and mountkernfs.sh
[08:09] <fabbione> same here
[08:09] <pitti> fabbione: 3 hits in devsub, and 5 in kernfs
[08:09] <fabbione> yeps
[08:26] <pitti> StevenK: gnome-build NEWed
[08:31] <StevenK> pitti: Thanks!
[08:37] <MacSlow> good morning funky bunch
[08:51] <pitti> infinity: meh, the previous mbr package built fine in the DC, and I cannot reproduce the current test suite failure locally either; give-back didn't help, hmm
[09:07] <dholbach> good morning
[09:07] <pitti> hey dholbach
[09:07] <dholbach> hey pitti
[09:11] <StevenK> pitti: anjuta uploaded - 3 libgdf packages should be ready to NBS out soonish
[09:11] <pitti> StevenK: cool!
[09:14] <pitti> StevenK: accepted
[09:16] <pitti> aah, fresh Ubuntu lives
[09:16] <Fujitsu> We have partman-crypto by default now?
[09:16] <pitti> Fujitsu: in alternates
[09:16] <Fujitsu> Yay!
[09:17] <Fujitsu> Is Ubiquity getting LVM/crypto and the like in the next couple of releases?
[09:17] <pitti> I hope so
[09:17] <StevenK> pitti: Ah, thanks
[09:17] <Fujitsu> Still, it'll be nice to not have to set it up manually, even if you do still have to use the alternate.
[09:18] <StevenK> pitti: I'd forgotten the archive is in lockdown mode. :-)
[09:18] <pitti> Fujitsu: in expert mode this has worked for quite a while already
[09:20] <RAOF> pitti: I'll be blowing away my laptop's install to set up LVM/crypto sometime soon, obviously.  Would you prefer testing asap, or with a beta disc? :)
[09:21] <pitti> https://iso.qa.stgraber.org updated; go wild
[09:21] <pitti> RAOF: testing ASAP is appreciated, if you can afford it
[09:21] <Fujitsu> pitti: Wasn't it only promoted a few days ago?
[09:21] <pitti> Fujitsu: yes
[09:21] <pitti> Fujitsu: well, not promoted, but enabled in d-i
[09:25] <RAOF> Hm.  I guess I can do that tomorrow sometime.
[09:30] <maikmerten> (xiph.org news: Theora beta1 is out - and no, I don't expect that to go into 7.10 ;) )
[09:30] <TheMuso> pitti, slangasek, I don't see anything on the schedule for Gutsy, so I am wondering if there will be a hard freeze for universe? If so, when might that be?
[09:31] <pitti> hi maikmerten, thanks for the heads-up
[09:31] <pitti> hello mvo
[09:31] <Tonio_> pitti: I uploaded a new knetwork-manager yesterday including a fix for dbus connection
[09:31] <pitti> mvo: can you start a new round of upgrade testing?
[09:31] <maikmerten> pitti: you're welcome
[09:31] <mvo> hello
[09:31] <mvo> pitti: yes
[09:31] <pitti> Tonio_: I saw, but it didn't have any bug # in the changelog, so I didn't accept it yet
[09:31] <pitti> mvo: thank you
[09:32] <Tonio_> pitti: because there is no bug reported for this, and I decided to fix it before reporting and closing myself, lack of time, sorry for this....
[09:32] <Tonio_> pitti: should I report the bug, then close it and reupload ?
[09:32] <pitti> Tonio_: if you give me a rationale here, it's good enough for me
[09:33] <Tonio_> pitti: okay, so the packaging was changed by riddell recently, and the dbus system.d configuration file misses in the package
[09:33] <pitti> Tonio_: the changelog does not document the code removal in Makefile.in
[09:33] <Tonio_> pitti: therefore the software is unable to  connect to dbus...
[09:33] <pitti> Tonio_: agreed to the .install fix, that's fine
[09:34] <Tonio_> pitti: I just rebuild the makefiles using buildprep, there is no specific change in the makefiles
[09:34] <Tonio_> pitti: thanks
[09:34] <pitti> Tonio_: hmkay; you tested this properly, I take it?
[09:41] <Mirv> maikmerten: it'd be nice to have Theora's beta 1 in gutsy-backports, maybe even feisty-backports, though as soon as possible, even though gutsy main exception is probably not so probable :)
[09:42] <maikmerten> oh, gutsy backports would certainly be nice
[09:42] <pitti> and absolutely appropriate, too
[09:43] <cjwatson> pitti: did partman-auto-crypto work for you? pkern reported problems at boot
[09:44] <pitti> maikmerten: that's indeed great; it's very helpful for distros (avoid rebuilding the dozens of reverse dependencies) and backportability, etc.
[09:44] <pitti> cjwatson: it's still at the 'erasing data on partition' stage, that takes ages...
[09:44] <pitti> ah, done now
[09:44] <maikmerten> pitti: the original plan was to ship beta with a new API, but looking back at like 3 years of productive Theora use it seemed to be unappropriate to suddenly break everything
[09:49] <Tonio_> pitti: yep I tested widelly on a daily-build install, and I can confirm knetworkmanager won't work at all without the fixing upload, then it works like a charm :)
[09:49] <pitti> hi doko
[09:49] <pitti> Tonio_: ok, sounds beta-worthy
[09:52] <doko> good morning
[09:53] <ion_> ing
[09:55] <Tonio_> pitti: great, thanks :)
[09:59] <MacSlow> mvo, I am strongly considering having "normal effects" and "extra effects" being a fixed set of pluings and only allow a custom list of effects... well on the "custom effects" setting (when ccsm is installed)
[09:59] <MacSlow> mvo, I am surprised that this isn't in place already
[09:59] <mvo> MacSlow: this is done with the patch I send you
[10:20] <AnAnt> Hello, I have opened a couple of bugs on LP that got solved (or turned out not to be bugs), how do I get them closed ?
[10:22] <seb128> AnAnt: change the status to invalid or fix released
[10:22] <AnAnt> seb128: how ?
[10:23] <seb128> AnAnt: click on the dropdown box and pick the option you want
[10:23] <AnAnt> seb128: oh ok, thanks
[10:23] <seb128> AnAnt: in the table at the top of the bug, you can click on the expander displayed to have the bug settings
[10:24] <pitti> hm, when I unplug the power cable from my laptop, trackerd does *not* stop grinding
[10:24] <pitti> I thought that was be fixed?
[10:24] <seb128> pitti: to svn, no new version has been rolled since
[10:31] <dholbach> calc: bug 135086?
[10:31] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed]  https://launchpad.net/bugs/135086
[10:31] <dholbach> Riddell: bug 136425?
[10:31] <ubotu> Launchpad bug 136425 in qt4-x11 "qtconfig-qt4 in Accessories?" [Undecided,Confirmed]  https://launchpad.net/bugs/136425
[10:38] <dholbach> Riddell: also bug 121984
[10:38] <ubotu> Launchpad bug 121984 in kdepim "kandy: no icon in kubuntu feisty's kde menu" [Wishlist,Confirmed]  https://launchpad.net/bugs/121984
[10:40] <dholbach> doko: bug 103929?
[10:40] <ubotu> Launchpad bug 103929 in bash "Bash prompt string looks for xterm-color, gnome terminal identifies as xterm" [Wishlist,In progress]  https://launchpad.net/bugs/103929
[10:40] <dholbach> Tonio_: do you think you can take a look at bug 73859?
[10:40] <ubotu> Launchpad bug 73859 in kleansweep "Installation of Kleansweep on Ubuntu (Gnome) fails to install kdesu" [Undecided,Confirmed]  https://launchpad.net/bugs/73859
[10:41] <doko> dholbach: for beta? maybe not
[10:41] <dholbach> doko: I'll mark it as 'later' and unsubscribe ubuntu-main-sponsors
[10:42] <Tonio_> dholbach: will look today, indeed
[10:42] <Tonio_> dholbach: should use kdesudo btw
[10:42] <dholbach> it'd be nice if you could all check out and http://daniel.holba.ch/sponsoring
[10:42] <dholbach> Tonio_: best to mention that in the bug report
[10:43] <dholbach> Tonio_: gracias :)
[10:43] <asac> pitti: ola :) .... network-manager 0.6.5-0ubuntu14 waits
[10:43] <dholbach> so does gnome-user-docs and ubuntu-dev-tools :)
[10:44] <pitti> asac: hey
[10:44] <pitti> asac: how did the wpasupplicant testing go?
[10:44] <asac> pitti: not as much replies as hoped for ... http://ubuntuforums.org/showthread.php?t=556488
[10:44] <Tonio_> dholbach: will test \sh_away debdiff, should work
[10:45] <asac> pitti: if you don't want this on beta cds i am fine ... we have to do it after beta then
[10:45] <dholbach> Tonio_: rock on :)
[10:46] <pitti> cjwatson: my lvm/crypto install finished, and indeed it's just stuck at boot; I'll reboot without usplash and quiet
[10:49] <pitti> cjwatson: hm, that's inconclusive; kernel boots fine, but there's no userspace kicking in, it's just stuck
[10:49] <cjwatson> pitti: ok, I'd be interested to know if it can be made to boot for beta
[10:50] <pitti> cjwatson: http://people.ubuntu.com/~pitti/tmp/lvmcrypto.png FYI; no VTs yet, etc.
[10:51] <pitti> ah, I finally get an initramfs shell
[10:52] <pitti> cjwatson: /dev/mapper/ only has control, and 'lvm -> vgdisplay' says 'no VGs found'
[10:53] <soren> pitti: It's LVM on top a crypted block device, right?
[10:54] <pitti> soren: no, it shouldn't be; it should be an encrypted LV (root) and an unencrpyted LV (/boot) in a VG
[10:54] <pitti> soren: and an encrypted swap, of course
[10:54] <pitti> but the installer didn't show me the final partitioning, so I'll need a rescue CD, etc.
[10:55] <soren> pitti: Oh, I see.
[10:56] <sladen> pitti: /usr is on / ?
[10:56] <pitti> sladen: I guess so
[10:56] <pitti> the 'lvm' tool does not work at all, so I'm not sure
[10:56] <pitti> vgscan/pvscan doesn't detect anything, etc.
[10:57] <cjwatson> sladen: AFAIK partman-auto-crypto uses the atomic scheme by default, which doesn't have a separate /usr
[10:58] <cjwatson> pitti: it does have a separate /boot, though, right?
[10:58] <pitti> so, for some reason the lvm is not detected at boot
[10:58] <pitti> cjwatson: it needs to, right
[10:58] <cjwatson> I assume so otherwise you wouldn't have got that far :)
[10:59] <pitti> cjwatson: I'm still poking in the initramfs shell, but it doesn't seem to get me very far
[10:59] <pitti> cjwatson: classical /boot, swap, root-for-everything schema would make most sense
[11:00] <cjwatson> indeed
[11:01] <pitti> dm-crypt module wasn't loaded; that's a bug, but not the primary one
[11:03] <dholbach> pitti: glom rebuild uploaded
[11:06] <pitti> dholbach: *hug*
[11:13] <pitti> soren, cjwatson: ah, got it: in this mode, /boot is not on the lvm itself, but a normal separate partition; and indeed my sda5 is a LVM on top of a luks device
[11:18] <pitti> hm, ubiquity hangs at downloading langpacks, and 'skip' does not work
[11:18] <soren> pitti: That makes sense.
[11:31] <pitti> cjwatson: I created bug 144390 with the symptoms and what to do to make it boot
[11:31] <ubotu> Launchpad bug 144390 in debian-installer "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,New]  https://launchpad.net/bugs/144390
[11:34] <\sh> hmm...somehow I won't get my dual screen setup back to work...after last updates...:(
[11:34] <tepsipakki> \sh: ati?
[11:35] <\sh> neither mergedFB nor xinerama is working (ati radeon RV100)
[11:35] <\sh> tepsipakki, yepp
[11:35] <tepsipakki> they are obsoleted, use xrandr
[11:35] <tepsipakki> it'll be mentioned on the release notes
[11:36] <\sh> tepsipakki, but you don't mean that I have to setup tghis dual screen via this strange UI on gnome?
[11:36] <tepsipakki> it should work OOTB for most
[11:36] <MacSlow> http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-5.png but please comment on the ubuntu-devel ml
[11:36] <\sh> tepsipakki, not for this machine...
[11:37] <\sh> tepsipakki, it comes up with the failsafe 640x480 vesa mode :(
[11:37] <tepsipakki> \sh: generate a new config
[11:37] <\sh> tepsipakki, dpkg-reconfigure xserver-xorg?
[11:37] <tepsipakki> right
[11:37] <tepsipakki> make a backup first if you like
[11:37] <tepsipakki> of the file..
[11:38] <\sh> tepsipakki, oh I have a backup since dapper of my xorg.conf ,-)
[11:38] <tepsipakki> you could also try without
[11:38] <tepsipakki> and see what happens
[11:38] <\sh> tepsipakki, doesn't work...I have two tfts one analog and one digital...
[11:38] <\sh> tepsipakki, it comes up with the right solution but in twinview mode
[11:39] <tepsipakki> cloned?
[11:39] <\sh> so screen analog and screen digital are showing the same
[11:39] <tepsipakki> right
[11:39] <\sh> tepsipakki, and using the screen and graphics ui....he sees the screens and I set the screen digital to "left of bla" and then failsafe mode after restart ,)
[11:41] <tepsipakki> \sh: maybe that should be made to work with ranrd-1.2...
[11:41] <tepsipakki> \sh: anyway, check this out: http://www.intellinuxgraphics.org/dualhead.html
[11:42] <pitti> siretart: you use crypted lvm, right? any idea about bug 144390? how does your initramfs behave?
[11:42] <ubotu> Launchpad bug 144390 in cryptsetup "use entire disk with lvm/encrypted partitioning fails to boot" [Undecided,New]  https://launchpad.net/bugs/144390
[11:43] <tepsipakki> \sh: I haven't tried the randr-1.2 based multihead at all, but that doc should cover it, both static and dynamic
[11:57] <pitti> cjwatson: on the bright side, hibernate and wakeup does work properly (except for manually calling cryptsetup again, of course)
[11:58] <cjwatson> pitti: I'm not quite following the bug - what changes need to be made to debian-installer here?
[11:58] <pitti> cjwatson: I moved it to cryptsetup; I guess something in its initramfs-tools scripts doesn't work (I did not yet debug it)
[12:03] <cjwatson> pitti: what has HTTP got to do with any filesystem?
[12:03] <cjwatson> mvo: sorry to preempt you with that apt bug, but I thought it was a good idea to get it fixed sooner rather than later at this point
[12:04] <mvo> cjwatson: what apt bug is that?
[12:04] <pitti> cjwatson: if I'd only knew that...
[12:05] <pitti> cjwatson: I attached everything to bug 144395
[12:05] <ubotu> Launchpad bug 144395 in linux-ubuntu-modules-2.6.22 "unionfs oopses for http processes" [Undecided,New]  https://launchpad.net/bugs/144395
[12:05] <cjwatson> mvo: bug 144001
[12:05] <ubotu> Launchpad bug 144001 in apt "crashes with SystemError: E:Unable to write mmap - msync" [Critical,Fix released]  https://launchpad.net/bugs/144001
[12:05] <mvo> urgh
[12:05] <pitti> cjwatson: thanks for fixing that (144001)
[12:05] <cjwatson> pitti: so you mean apt's http method, at a guess
[12:06] <mvo> cjwatson: thanks for fixing it!
[12:06] <pitti> cjwatson: ah, right, that spawns a process with that name
[12:16] <siretart> pitti: uuh, this looks bad. from the first look, it seems that the udev rules in the cryptsetup-udeb are broken
[12:16] <pitti> siretart: why the udev?
[12:16] <pitti> siretart: erm, udeb
[12:17] <siretart> oh, I missed the part that installation went fine
[12:17] <siretart> I have to admit that I never installed with crypted / - I need to test that
[12:17] <stgraber> dholbach: Got my mail (ekiga) ?
[12:17] <siretart> will do soonisch
[12:18] <dholbach> stgraber: yes, I'll forward it to fernando though (he's working on the update to the new usptream version) (maybe also to seb128 to let him know about it)
[12:18] <pitti> siretart: oh, I see; you just use encrypted /home and swap, or so?
[12:18] <pitti> siretart: ok, nevermind; I just thought you would use that setup
[12:19] <cjwatson> siretart: broken> how so?
[12:19] <seb128> dholbach: Debian did update, maybe we can sync?
[12:20] <siretart> cjwatson: I didn't read the bug carefully enough. the bug seems valid, I need to look more closely into it
[12:20] <dholbach> seb128: great - I'll ask fernando to check it out (we have some changes in ekiga, for example different icons and LPI)
[12:20] <dholbach> seb128: also I guess Debian has different compatibility symlinks
[12:20] <siretart> let me install a current gutsy via pxe and let me try
[12:20] <dholbach> seb128: maybe siti can help with that also
[12:23] <pitti> Riddell: hm, did you self-accept your kdebase feisty-proposed upload, or is there a soyuz glitch?
[12:26] <fabbione> pitti: according to mvo #127849 the verification has been already done about a month ago. we can move that to -updates
[12:26] <pitti> fabbione: cool
[12:27] <fabbione> pitti: #133822 feisty is ok. I am testing edgy and dapper now
[12:27] <Riddell> pitti: I did, is that problematic?
[12:27] <dholbach> stgraber: I forward it and CCed you in the mail
[12:27] <pitti> Riddell: no, that's fine; I was just concerned that it wasn't held in unapproved for some reason
[12:28] <pitti> Riddell: did you mangle the bug accordingly? (fixcommitted/verification-needed)
[12:28] <pitti> fabbione: hm, over a month ago that bug/upload didn't even exist :)
[12:29] <fabbione> pitti: the comment from mvo is from the 27th of Oct....
[12:29] <fabbione> almost a month ago
[12:29] <fabbione> :)
[12:29] <fabbione> it's exactly a month old :
[12:29] <fabbione> :P
[12:30] <fabbione> (i am talking about 127849...)
[12:30] <pitti> fabbione: (done)
[12:30] <fabbione> pitti: thanks
[12:33] <Riddell> pitti: I have now
[12:33] <pitti> Riddell: thanks
[12:37] <mvo> cjwatson: thanks for the patch for apt, I merged it back into the devel line too (so that debian gets it too)
[12:40] <cjwatson> ok, cool
[12:40] <fabbione> pitti: #133822 edgy is ok. missing only dapper
[12:50] <asac> pitti: my final beta bugs are waiting in: network-manager 0.6.5-0ubuntu14, thunderbird 2.0.0.6-0ubuntu4, gnash 0.8.1-0ubuntu1
[12:54] <fabbione> pitti: #133822 is all good.. it can move to -updates
[12:57] <pitti> fabbione: grazie; done
[12:58] <fabbione> pitti: thanks a lot
[12:58] <pitti> asac: cheers, all done
[01:04] <siretart> cjwatson: the installer is taking ages to install on crypted LVM because of '/bin/blockdev-wipe'. Is there some easy way to circumwent that for testing purposes?
[01:04] <siretart> I'm testing on a 120GB disk :/
[01:04] <Fujitsu> siretart: VT switch and replace it with a shell script that does nothing?
[01:05] <siretart> hm
[01:06] <cjwatson> siretart: I don't know partman-crypto all that well I'm afraid
[01:07] <pitti> siretart: here, too; I guess the reason is to fill it with random bits to make sure that you cannot reconstruct the previous contents
[01:08] <siretart> pitti: yes, it makes perfectly sense to do that on a production system
[01:08] <cjwatson> siretart: there's an "Erase data:" toggle in the manual partitioning UI
[01:08] <cjwatson> siretart: so just go back to the manual UI from the confirmation screen and flip that
[01:08] <pitti> siretart: thus it would not be required at all, but for people who care about data confidentiality it might be important
[01:08] <siretart> pitti: for debugging purposes its just annoying
[01:08] <pitti> siretart: ack
[01:08] <siretart> cjwatson: aah, thanks. will do
[01:08] <pitti> siretart: a 4 GB virtual disk does fine :)
[01:13] <siretart> it seems that the automatic partitioner for crypto lvm doesn't setup any swap space
[01:13] <siretart> this might or might not be intended
[01:28] <cjwatson> apparently because it offers a UI for resolving conflicting service changes
[01:30] <ogra> hrm
[01:30] <ogra> it breaks my ltsp-update-image it seems
[01:31] <ivoks> cjwatson: i've discovered root of the bug 93077, and patch for xkeyboard-config is provided, tested it and it works fine
[01:31] <ubotu> Launchpad bug 93077 in xkeyboard-config "Non-exsisting layouts" [High,Confirmed]  https://launchpad.net/bugs/93077
[01:31] <ogra> if i force noninteractive from ltsp-update-image likelyness that the udeb breaks again is big :/
[01:33] <cjwatson> ivoks: do you know what the "any" symbols were originally supposed to do?
[01:34] <ivoks> cjwatson: if layout included some other layout (latin(level3)), then, if there's 'any', that key should be taken from latin
[01:34] <ivoks> cjwatson: that works in X
[01:35] <ivoks> but, since nobody uses 'any' these days, i figured out that it is obsolete or a bad thing to do
[01:36] <ivoks> and in ckbcomp, any is replaced with VoidSymbol
[01:37] <cjwatson> ivoks: OK - it's not easy to see from the patch but I take it that changing "any" to the corresponding real symbols is the only change?
[01:37] <ivoks> right
[01:38] <ivoks> cjwatson: i'll send a patch to upstream also, so, hopefully, this is one-time fix
[01:39] <cjwatson> ivoks: OK, applying now
[01:39] <cjwatson> thanks
[01:40] <ivoks> thank you
[01:45] <pitti> siretart: it did for me
[01:46] <pitti> siretart: I even tried suspend to disk, and that worked fine (modulo that initramfs bug, of course)
[01:46] <pitti> siretart: the lvm contains ubuntu-{root,swap_1}
[01:49] <siretart> pitti: I found out why the cryptroot hook is broken
[01:49] <siretart> pitti: its the UUID mangling in /etc/fstab
[01:49] <pitti> siretart: ooh, crypted partitions don't have that, I take it
[01:49] <siretart> pitti: the cryptsetup initramfs hook is comparing /etc/cryptab and /etc/fstab entries. with the UUID mangling, it fails to detect the root device. that's why it doesn't mount root by default
[01:50] <pitti> siretart: darn, I don't have that installed system any more; how does fstab look like?
[01:51] <siretart> sorry?
[01:51] <pitti> siretart: I wonder how the uuid writing code can do that in the first place, since the encrypted partition should not have any uuid...
[01:51] <siretart> pitti: both the ext2 filesystem in the crypted container and the container itself have a UUID
[01:51] <siretart> that's the point of LUKS
[01:52] <siretart> the question is how to proceed from here
[01:52] <pitti> ah, right
[01:53] <pitti> siretart: I mixed that up with the pure dm-crypt install I did a while ago (no luks)
[01:53] <siretart> since we need to redesign/rewrite the whole cryptsetup/udev integration, I think it might not be that unreasonable to just disable the UUID mangling for cryptoroot installations
[01:53] <pitti> siretart: so which UUIDs are in crypttab and which are in fstab?
[01:54] <siretart> pitti: of the inner ext3 fs.
[01:55] <siretart> pitti: the crypttab file (which we want to get rid of) doesn't know about UUIDs
[01:55] <pitti> siretart: hm; well, the inner ext3 one does make sense for fstab...
[01:58] <pitti> siretart: however, would disabling help at all? it seems to me that fstab is the wrong place to denote the 'outer' device (with either /dev/ or UUID)
[01:58] <pitti> siretart: after all, if UUID were replaced by /dev/mapper/ubuntu-root, the initramfs still cannot find that without actually unlocking the encrypted device
[01:58] <siretart> pitti: well, that's the way the debian crypt-root hook works
[01:59] <siretart> it does special magic in the initramfs to detect and open the root volume
[01:59] <siretart> hmm. I think we'd need to fix the add_device() function in cryptroot-hook
[02:00] <siretart> pitti: http://paste.debian.net/37868
[02:00] <siretart> that part horribly breaks with UUID
[02:00] <pitti> siretart: back in five minutes (need to do some queue review)
[02:01] <siretart> it is given the first entry of /etc/fstab
[02:01] <cjwatson> I'm surprised we use UUIDs for crypted devices
[02:02] <siretart> cjwatson: why?
[02:03] <cjwatson> hmm, I forgot that udev had been changed to use UUIDs for LVM devices
[02:03] <cjwatson> ok, in that case I would be inclined to say that it would be easiest to fix cryptsetup to handle UUIDs
[02:03] <cjwatson> (I was going to say that we could turn them off in the installer, but we'd have to change the volumeid postinst too and it would be fiddly to distinguish them from LVM LVs)
[02:04] <siretart> needless to say that on my laptop, I don't use UUIDs for my crypted volumes either
[02:10] <siretart> cjwatson: if we do that, we'd need to change cryptsetup-udeb to create UUIDs in /etc/crypttab as well, I think
[02:12] <siretart> otherwise things become terrilbly hackish :/
[02:15] <ogra> ogra@laptop:~$ LANG=C sudo adduser testuser
[02:15] <ogra> adduser: The group `testuser' already exists.
[02:15] <ogra> ....
[02:15] <ogra> seems users-admin doesnt like that case
[02:16] <ogra> seb128, ^^^ it shows the user being crteated in the gui .... but its not being created
[02:16] <ogra> no error message or something
[02:16] <seb128> ogra: known already
[02:16] <ogra> ah, k
[02:18] <seb128> ogra: bug #99276
[02:18] <ubotu> Launchpad bug 99276 in gnome-system-tools ""User and Groups" does not inform user that manual UID already exists and create user groups." [Medium,New]  https://launchpad.net/bugs/99276
[02:19] <ogra> right, thanks :)
[02:25] <cjwatson> siretart: makes sense. fortunately it would be only one upload to do both
[02:26] <pitti> siretart: back, reading scrollback
[02:27] <pitti> siretart: add_device()> right, I see the problem
[02:27] <ogra> hrm, compiz stopped working in ltsp :/
[02:28] <ogra> sad
[02:28] <pitti> cjwatson: I don't think that we can fix this sensibly for beta; how easy is it to hide that option in d-i? (if it takes too long, we can release-note it, but it'll certainly generate some attraction and complaining)
[02:30] <siretart> Honestly, I think we should disable cryptsetup-udeb for beta, but enable it again shortly after that again.
[02:31] <pitti> siretart: I'd only enable it again when this is fixed
[02:32] <pitti> siretart: it was a feature we hoped to sneak into the beta because it seemed cheap to get, but apparently it isn't :/
[02:32] <siretart> pitti: good option, however since I don't know (yet) how to build d-i, this would be unconvenient for me ;)
[02:33] <siretart> well, debian doesn't seem to believe in UUIDs
[02:33] <pitti> siretart: well, there's still plain dm-crypt in the expert mode
[02:33] <siretart> something that should change
[02:33] <siretart> pitti: no, if we disable cryptsetup-udeb. not even that is available
[02:34] <siretart> pitti: so perhaps we can just disable cryptoroot for now?
[02:34] <pitti> siretart: hm, and just fixing add_device to check /dev/disk/by-uuid/ wouldn't work?
[02:37] <siretart> pitti: I'd expect it to work, if you can fix the node_is_in_crypttab() function as well
[02:53] <ogra> mjg59, is there any way to get working panning on a virtual desktop with the intek driver ? seems i can only get that working with i810 and 915resolution
[02:53] <ogra> *intel
[02:56] <cjwatson> pitti: shove partman-auto-crypto to universe and the automatic option will disappear
[02:57] <cjwatson> pitti: the manual option is partman-crypto
[02:57] <pitti> cjwatson: ah, great; d-i is about to be rebuilt anyway, that should pick it up, right?
[02:57] <cjwatson> it's outside the initrd, doesn't need a d-i rebuild
[02:57] <pitti> cjwatson: I think disabling it for now is the way to go, WDYT?
[02:57] <pitti> ah
[02:57] <cjwatson> your call, I'm not clear enough on the difficulty of fixing cryptsetup
[02:58] <mjg59> ogra: I believe so, but I've never tried
[02:58] <ogra> well, it ignores the "Virtual" stanza on the classmate with the intel driver
[02:58] <pitti> cjwatson: I don't think it's too hard to fix the initramfs script, but I don't have time for it right now, and time is getting tight
[02:59] <ogra> i810 works fine but needs 915resolution (i'm on the classmate atm)
[03:05] <ccm> hi there, what is the best way to track "could enable desktop effects" issues. I cannot find any log files or verbose output
[03:07] <StevenK> Poor amd64
[03:08] <Fujitsu> StevenK: What's wrong with it now?
[03:08] <StevenK> Fujitsu: One of the buildds is down
[03:08] <Fujitsu> Ah, as usual.
[03:08] <StevenK> Fujitsu: Hrm? I haven't noticed that amd64 lost any buildds
[03:09] <StevenK> Previously, I mean
[03:09] <Fujitsu> StevenK: I'm sure I saw one down for more than a day a few days back, but it might just have been sparc.
[03:09] <StevenK> Ah, now sparc on the other hand. :-)
[03:12] <pitti> StevenK: FYI, it's currently being discussed
[03:12] <StevenK> pitti: Ah ha
[03:16] <StevenK> pitti: libgbf NBS'ing is waiting on the amd64 build.
[03:17] <StevenK> pitti: Increase the priority of the anjuta amd64 build, but I don't mind either way.
[03:26] <StevenK> Whoa. You're not done yet!
[03:26] <pitti> ogra: hm? I merged them on Friday or so; can't be that bad?
[03:26] <ogra> well, i forgot to pulll before making my changes
[03:27] <pitti> ogra: oh; you should maybe consider using a checkout (bzr bind), so that commit will warn you
[03:27] <gutsy> Hi, do you know which package provides GL/glxint.h
[03:27] <pitti> ogra: uncommit FTW :)
[03:28] <StevenK> gutsy: #ubuntu in future, but the package is x11proto-gl-dev
[03:29] <gutsy> thanks
[03:29] <ogra> pitti, hmm, noice, i didnt need to uncommit, it moaned my change but accepted the commit
[03:29] <ogra> *moaned about
[03:34] <cjwatson> ogra: you'll need to uncommit in order to pull the master seeds though
[03:34] <cjwatson> you should never merge *from* the master seeds and then push
[03:34] <ogra> hmm
[03:34] <cjwatson> (because that will make revision numbers go backward and generally be confusing)
[03:35] <cjwatson> I second pitti's recommendation to use 'bzr bind'
[03:35] <ogra> to late now
[03:35] <ogra> but https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.gutsy seems to be happy
[03:35] <cjwatson> please set up a checkout now rather than later so that that doesn't happen again
[03:35] <pitti> yeah, and 'bzr log' will be strange
[03:35] <ogra> will do
[03:36] <cjwatson> ogra: it *works*, it's just horribly confusing
[03:36] <ogra> yeah
[03:36] <ogra> understood
[03:38] <StevenK> pitti: In a fun twist of fate, -11 and -12 kernel stuff has landed in NBS
[03:38] <cjwatson> StevenK: -11 should go away for beta, leave -12 alone since it's probably just unseeded stuff
[03:39] <cjwatson> I don't see any -12 stuff in /~ubuntu-archive/NBS/
[03:40] <pitti> StevenK: probably it's just NEEDSBUILD
[03:40] <cjwatson> I've seeded the *-cell-di udebs
[03:40] <pitti> StevenK: and I cleaned up all -11 yesterday AFAIK
[03:40] <cjwatson> pitti: there's linux-ubuntu-modules -11 stuff
[03:41] <pitti> ah
[03:41] <pitti> I'll clean up later
[03:41] <StevenK> pitti: It seems you missed updates-modules-2.6.22-11-*-di
[03:41] <cjwatson> StevenK: it's from a different source
[03:41] <StevenK> cjwatson: Yeah, I should learn to hit refresh before poking people about NBS, just in case
[03:41] <cjwatson> pitti: BTW (just in case) could you please leave palo-installer and partman-palo in main? hppa should be back in shape soon so we can turn it back on properly in anastacia
[03:42] <ogra> W: http://archive.ubuntu.com/ubuntu/dists/gutsy/main/binary-amd64/Packages.bz2 was corrupt
[03:42] <ogra> hrm, whats that ?
[03:43] <cjwatson> usually transient, wait 'til next push
[03:44] <pitti> cjwatson: right, I was ignoring it anyway for the moment
[03:44] <ogra> well, does ./update retry in the background ? seems its going on fine
[03:45] <cjwatson> ogra: no, it ignores the errors and trundles on regardless
[03:45] <ogra> ah, k
[03:45] <cjwatson> ogra: you should nuke your tree, re-unpack, and try again later
[03:45] <ogra> yes, thats what i usually do anyway with wsuch warnings
[03:45] <cjwatson> it's a germinate bug mind you, it should stop on that sort of thing
[03:46] <cjwatson> and not bugger up the tree
[03:46] <ogra> yup
[03:47] <siretart> asac: heh, you're foisting me the wpasupplicant downgrade?
[03:47] <siretart> (the changes-file says Changed-By: siretart, but I didn't sign that upload)
[03:47] <asac> siretart: no ... not that i know of
[03:48] <pitti> siretart: no, we just asked for your opinion
[03:48] <pitti> siretart: erm, what??
[03:48] <asac> siretart: oh ... sorry if that wasn't the idea ... i took your package
[03:48] <asac> siretart: and didn't change a thing except the version
[03:48] <siretart> right
[03:48] <asac> or did i?
[03:48] <siretart> but this way it looks like a sponsored upload
[03:48] <cjwatson> Changed-By is taken from the top of debian/changelog, not the signer
[03:48] <pitti> StevenK: NBS cleaned (kernel -11 stuff, libwine, and libgbf-1-0-dbg)
[03:49] <siretart> there isn't a problem here, it just looks strange
[03:49] <asac> siretart: in the end the uploader is responsible i guess ... not the changelog owner (imo)
[03:49] <StevenK> pitti: Yay, thanks.
[03:49] <siretart> asac: well, in this particular case, we are both respsonsible anyways. it just looks funny ;)
[03:49] <cjwatson> could somebody fix the usplash-theme-ubuntu misalignment for beta?
[03:49] <StevenK> pitti: libgbf-1-0 can go whenever the amd64 build of anjuta sorts itself out
[03:49] <cjwatson> I think it only affects one of the (widescreen, non-widescreen) versions
[03:49] <asac> siretart: yeah sorry for the confusion ;)
[04:03] <pitti> sladen: computers are so bad at maths...
[04:05] <sladen> pitti: yeah, much worse than the programmers that think 352+380+352=1024
[04:06] <cjwatson> heh
[04:06] <pitti> for a very small value of '380' :)
[04:06] <Hobbsee> sladen: they've redefined the maths system since you went to school.  didnt you get the memo?
[04:09] <lamont> mvo: you around?
[04:09] <lamont> mount (current gutsy) Breaks: nfs-common (<<1:1.1.0-7).
[04:09] <lamont> does that mean that apt will just do the right thing?
[04:10] <lamont> (and we can therefore close the update-manager bug and not bother with the releasenotes entry?)
[04:10] <Amaranth> lamont: apt will refuse to install the new mount
[04:11] <lamont> dist-upgrade should cause it to upgrade nfs-mount if present though, yes?
[04:11] <Amaranth> not sure
[04:12] <geser> doesn't breaks mean than nfs-common gets unconfigured?
[04:12] <pitti> but if a higher version is available, apt should certainly prefer that?
[04:13] <sladen> cjwatson: who's got an affected laptop?
[04:13] <pitti> sladen: I notice the wrong progress bar on the live CD, but in installed system it is ok
[04:13] <sladen> pitti: oh, joy.
[04:15] <StevenK> pitti: lmms hasn't been fixed for s/libwine-dev/wine-dev/, I'm doing so now.
[04:15] <pitti> StevenK: right, but I'm not worried killing build-dependencies, since on next upload people notice anyway and it doesn't break installability
[04:15] <ogra> pitti, if e-meta shows up in the queue, please approve ...
[04:15] <pitti> ogra: noted
[04:15] <StevenK> pitti: Shrug, it gives me something to do. :-)
[04:15] <pitti> ogra: s/if/when/, I take it? :)
[04:16] <cjwatson> sladen: any vmware installation shows it when booting the live CD
[04:16] <pitti> sladen: ^ confirmed
[04:16] <cjwatson> well, I say any, at least mine does
[04:16] <ogra> pitti, actually it should be there already :) ....
[04:16] <ogra> anyway, coffeebreak :)
[04:16] <lamont> bug #141559
[04:16] <ubotu> Launchpad bug 141559 in update-manager "update-manager needs to handle mount/nfs-common transition for gutsy" [High,Confirmed]  https://launchpad.net/bugs/141559
[04:17] <cjwatson> sladen: hence my widescreen vs. non-widescreen thought
[04:18] <sladen> cjwatson: the (2*a + b != c) was only off for the widescreen. 0.16 uploaded, one line change only on the widescreen theme, shouldn't make the situation any worse
[04:19] <cjwatson> cool, thanks
[04:20] <sladen> cjwatson: re: vmware;  640x400 could be selected as "widescreen"
[04:21] <mjg59> The livecd will never use the widescreen themes
[04:21] <mjg59> usplash doesn't do its own resolution probing, and nothing has given it a widescreen resolution at that point
[04:21] <sladen> arse
[04:21] <mjg59> Also, we don't have a 640x400
[04:21] <sladen> pitti: you said the error was /only/ on the livecd and not on normal boot?
[04:21] <mjg59> (Or do we? If we do, it should be shot)
[04:22] <cjwatson> sladen: that's what I'm seeing, which suggests it's on 640x480 not 1024x768
[04:23] <cjwatson> (the resolutions in my case)
[04:26] <Riddell> sladen: when editing usplash themes please mind and tell me and ogra and whoever does xubuntu to sync up
[04:26] <bddebian> Heya
[04:27] <Riddell> or for extra points fix it somehow so the code isn't duplicated
[04:27] <sladen> Riddell: does this progress bar misalignment show up on kubuntu aswell?
[04:30] <Riddell> sladen: yes
[04:30] <Riddell> which isn't surprising since its the same code
[04:31] <StevenK> pitti: lmms builds, would you prefer I left it until after beta?
[04:34] <sladen> Riddell: nod, I'll do it once somebody confirms whether it's a fix or not
[04:35] <Riddell> sladen: you uploaded without knowing if it fixes or not?
[04:37] <pitti> StevenK: no, I'm fine; it's universe
[04:37] <MacSlow> seb128, .svg don't need to be uuencoded in order to be put in the debian-directory, right?
[04:38] <StevenK> pitti: Aye, uploading now
[04:38] <seb128> MacSlow: no they don't
[04:38] <sladen> Riddell: yes, see note above.
[04:39] <StevenK> pitti: lmms uploaded, accept at your leisure.
[04:41] <sladen> Seveas: did you, or mjg59 originally write this usplash theme?
[04:53] <seb128> pitti: I'm sometimes wondering if apport works correctly nowadays, we don't get lot of crash bugs
[04:53] <pitti> seb128: the crash was caught, but update-notifier didn't report it on the live CD
[04:53] <seb128> right
[04:53] <seb128> my gutsy does the same
[04:54] <seb128> it collects crashes but that's about it
[04:54] <seb128> I'm not sure if I changed the config at some points so I didn't bother
[04:54] <seb128> but that's weird
[04:54] <pitti> hm, bash -c 'kill -SEGV $$' still works
[04:55] <seb128> well it collects crashes as written
[04:55] <seb128> it just doesn't add an icon in the notification area nor run
[04:56] <pitti> seb128: hm, it does for me
[04:56] <seb128> k, so I probably changed something
[04:56] <pitti> seb128: if you do above bash command, what happens?
[04:57] <seb128> I just dunno where
[04:57] <seb128> it adds a crash to /var/crash
[04:57] <seb128> and that's all
[04:57] <pitti> python crashes are reported here, too
[04:58] <pitti> seb128: gconftool -g /apps/update-notifier/show_apport_crashes
[04:58] <seb128> No value set for `/apps/update-notifier/show_apport_crashes'
[04:58] <pochu> It doesn't notify here, and I don't think I changed the config...
[04:58] <pitti> seb128: a-haa
[04:58] <pochu> same here, btw ^ :)
[04:59] <pitti> do you have /usr/share/gconf/schemas/update-notifier.schemas ?
[04:59] <seb128> yes
[04:59] <seb128> pitti: /var/lib/dpkg/info/update-notifier.postinst doesn't register it though
[04:59] <pitti> seb128: hm, shouldn't gconf use the default from there?
[04:59] <seb128> so it's not used
[04:59] <pitti> hehe
[04:59] <seb128> pitti: no, the package has to use dh_gconf
[05:00] <pitti> mvo: you broke my shiny update-notifier gconf key :/
[05:00] <seb128> pitti: schemas are templates used to file the gconf database at installation time
[05:00] <pitti> mvo: want me to fix it again?
[05:00] <pitti> seb128: right, and I'm fairly sure I added dh_gconf back then
[05:00] <seb128> pitti: anyway that would explain why we don't get lot of crash bugs for some time
[05:01] <pitti> and also why they are not reported on the live CD
[05:01] <pitti> apt-get source update-notifier doesn't warn me about bzr either
[05:01] <pitti> seb128: I'll take a look; we should definitively have this for beta
[05:02] <seb128> pitti: weird, it has a dh_gconf
[05:03] <pitti> evand: bug 144460 should be a straightforward fix; I'm not sure how exotic the crash is, though
[05:03] <pitti> evand: (or, rather, the circumstances when it happens)
[05:04] <ubotu> Launchpad bug 144460 in ubiquity "ubiquity crashed with NameError in _realpath_root_recurse()" [Undecided,New]  https://launchpad.net/bugs/144460
[05:05] <seb128> pitti: ah, you added the dh_gconf before dh_install which doesn't work since the schemas is not installed yet
[05:07] <iwj> kylem: You don't fancy looking into the sl-modem-daemon regression, do you ?  (bug 144468)
[05:07] <ubotu> Launchpad bug 144468 in linux-source-2.6.22 "sl-modem-daemon does not work on some hardware" [Undecided,New]  https://launchpad.net/bugs/144468
[05:07] <evand> pitti: thanks, I'll take a look
[05:07] <seb128> pitti: do you want me to upload a fixed update-notifier?
[05:08] <evand> ugh, why can't firefox handle gzip like less.  I shouldn't have to open a single compressed file in file-roller.
[05:08] <pitti> seb128: ah, that was due to Riddell's recent changes for the package split
[05:08] <pitti> seb128: sure, if you have some minutes to actually test it, that'd be appreciated
[05:08] <cjwatson> evand: looks like I got the mutual recursion syntax wrong
[05:08] <seb128> pitti: ok, looking at that
[05:09] <cjwatson> I'm not actually sure how to fix that, so good luck :)
[05:09] <evand> haha, oh thanks!
[05:09] <pitti> oh, hmm, just looked like a wrong name
[05:10] <cjwatson> oh
[05:10] <cjwatson> yes, you're right
[05:10] <pitti> evand: it actually installs fine, so the only things that are wrong are the missing 'reboot now' message, and the apport crash report
[05:14] <kylem> iwj, there's no change that would effect that.
[05:15] <cjwatson> evand: ignoring my misunderstanding, can you go ahead and commit the obvious fix?
[05:16] <iwj> kylem: Not even the reversion of snd-intel-hda ?
[05:16] <iwj> kylem: If you think it's probably not a kernel bug I can try to do binary chop on upgrades.
[05:16] <evand> cjwatson: will do
[05:17] <pitti> iwj, kylem: just chiming in, bigjools was complaining about his intel sound card not working any more in gutsy; might that be related?
[05:17] <evand> pitti: missing reboot now message?  That's been coming up fine for me.  Is there a specific test case for this?
[05:18] <cjwatson> reboot> ditto
[05:18] <pitti> evand: well, ubiquity crashed, so it could not display it any more
[05:18] <pitti> evand: that was just the reasoning for not making it a blocker for beta
[05:18] <kylem> hmm.
[05:18] <pitti> installation works by and large, but with a few glitches
[05:18] <kylem> try reverting the kernel to -11 and seeing if it fixes things.
[05:24] <evand> pitti: I'm sorry, I don't follow.  How would ubiquity crashing make the 'would you like to reboot now?' message disappear, unless you're saying that such a message should appear despite the install failing?
[05:24] <cjwatson> pitti: I think we should disable tracker in the live session to save memory. Does that make sense to you?
[05:25] <pitti> cjwatson: ooh, please
[05:25] <cjwatson> I'll just check that the world doesn't break if I do that
[05:25] <pitti> evand: well, because ubiquity crashed before it came to the point when it considered the installation fully finished and thus would display the 'installation done. reboot/continue' dialog
[05:26] <pitti> cjwatson: that would be a casper change?
[05:27] <cjwatson> yes
[05:34] <highvoltage> 5C
[05:34] <pitti> hi mdz
[05:36] <cjwatson> pitti: I think the installation not completing is a blocker for beta; there are important things done after the crash you describe beyond just displaying the reboot dialog
[05:36] <cjwatson> pitti: for example, a system that crashes at that point will still have ubiquity installed in the target, and won't have the installation logs copied to it
[05:36] <mdz> pitti: hello
[05:37] <pitti> cjwatson: if we get a fix soon, I'm all for it; right now I'm not sure how corner-case this crash is
[05:37] <cjwatson> pitti: evand's committed it, and there's something else in bzr that needs an upload anyway
[05:37] <pitti> ah, great
[05:37] <cjwatson> but I was waiting for a translation update from Launchpad before uploading, ideally
[05:37] <wasabi> So... when my kernel dies... the keyboard's caps lock and scroll lock keys blink... and X remains unmoving.
[05:38] <pitti> cjwatson: heh, I'm waiting for a new gutsy tarball since Saturday :)
[05:38] <wasabi> Is there an appropiate way to get something useful for submitting in a bug report?
[05:38] <pitti> cjwatson: we'll still need a new wpasupplicant (most probably), so I think we won't get new images until tomorrow morning
[05:38] <pitti> wb seb128
[05:38] <pitti> seb128: btw, I think you didn't commit the update-notifier fix to bzr
[05:38] <seb128> pitti: re, update-notifier fix confirmed and uploaded
[05:39] <seb128> where is the bzr?
[05:39] <pitti> seb128: thanks
[05:39] <pitti> http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/
[05:39] <seb128> I tried http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu
[05:39] <pitti> seb128: apt-get source didn't warn me either, but debian/control has it
[05:39] <seb128> but this one doesn't have the current version
[05:39] <pitti> hmm
[05:39] <seb128> it's outdated
[05:39] <seb128> and mvo didn't reply to my query
[05:39] <seb128> so I just uploaded for now
[05:40] <pitti> seb128: ok, *shrug*, something to be cleaned up later
[05:40] <seb128> right
[05:41] <cjwatson> seb128: 16:24 <cjwatson> pitti: I think we should disable tracker in the live session to save memory. Does that make sense to you?
[05:42] <cjwatson> seb128: sound reasonable? it's not like it will be indexing much interesting
[05:42] <jdong> I think we should disable tracker to not break my hard drive :)
[05:42] <pitti> ah, that might also explain why it is to painfully slow
[05:42] <mjg59> That makes sense
[05:42] <jamiemcc> yeah - cant see the point on a live cd
[05:43] <pitti> hi jamiemcc
[05:43] <jamiemcc> hi pitti
[05:43] <pitti> jamiemcc: just noticed that trackerd doesn't stop when pulling out AC, but seb said you already fixed it in svn?
[05:43] <pitti> jamiemcc: does this happen to be a relatively small patch which we could apply easily?
[05:43] <jamiemcc> yes we hope to have a release later tonight or tomorrow at latest
[05:44] <jamiemcc> the patch would be difficult to isolate from release
[05:44] <pitti> jamiemcc: for the beta I'd prefer a single patch if it is reasonably consistent, and new upstream microrelease later
[05:44] <pitti> jamiemcc: oh, I see
[05:44] <pitti> jamiemcc: well, it was worth a try :)
[05:44] <jamiemcc> pitti: I can do ti for you if you like if its not possible to put a new version in time for beta
[05:45] <pitti> jamiemcc: well, it's not a beta blocker IMHO; but I consider it very important to fix immediately after that
[05:45] <pitti> jamiemcc: does your new release tonight have any new features, or is it just bug fixes?
[05:46] <jamiemcc> bug fixes on the whole - new features like experimental thunderbird extension are configure disable
[05:46] <pitti> (am I the only one who envisions a sleep medicine when saying "beta blocker"?)
[05:46] <jamiemcc> the new index merging improves disk io and index speed considerably
[05:47] <jamiemcc> so would be nice to get it into gutsy asap
[05:47] <pitti> jamiemcc: hm, sounds like we want that, too, if it has been tested properly?
[05:47] <jamiemcc> its been tested over the weekend on the tracker ML
[05:47] <jamiemcc> only major issue is memory leaks atm
[05:47] <seb128> cjwatson: makes sense
[05:47] <pitti> with the new indexing or the current one?
[05:48] <jamiemcc> the new indexing merging
[05:49] <pitti> jamiemcc: do you have a websvn where I could see the commit to fix 'stop on battery'? (just to have a fallback)
[05:49] <jamiemcc> http://svn.gnome.org/viewcvs/tracker/trunk/src/trackerd/
[05:50] <jamiemcc> changes to trackerd.c and tracker-utils.c and tracker-utils.h
[05:51] <pitti> jamiemcc: ah, revs 846 and 861?
[05:52] <jamiemcc> yes sounds right
[05:52] <jamiemcc> would have to fish them out amongst the other changes though
[05:52] <pitti> hm, those commits seem to amalgate several unrelated changes
[05:52] <pitti> ah, right
[06:17] <pitti> Keybuk: now that unionfs works again, by and large, would it make sense to do that mystical ReadaheadListUpdate?
[06:21] <pitti> doko: expat NEWed, FYI (64 bit libs)
[06:23] <pitti> bryce: radeonhd binary-NEWed, FYI
[06:24] <Keybuk> pitti: yeah
[06:25] <TomaszD> hello, quick question, is the bluez-gnome package installed by default regardless of bluetooth hardware presence?
[06:26] <TomaszD> I need this for an Ubuntu article, for a real... paper newspaper.
[06:26] <cjwatson> TomaszD: generally we try not to install packages on a hardware-specific basis, because it makes it less convenient to switch hardware around
[06:26] <cjwatson> sort of the opposite of Windows activation :-)
[06:26] <TomaszD> hah, good thinking
[06:27] <mvo> seb128: let me check it
[06:27] <TomaszD> so I take it as a yes, it's installed regardless
[06:27] <cjwatson> TomaszD: yes, in the forthcoming Ubuntu 7.10 (but not in 7.04), bluez-gnome is installed by default across the board. It's only a Recommends of ubuntu-desktop, though, so you can remove it again without problems
[06:27] <TomaszD> cjwatson, thank you!
[06:27] <TomaszD> I want to be as accurate as possible
[06:28] <mjg59> TomaszD: In the absence of bluetooth hardware, it should just sit there and do nothing until a bluetooth device is plugged in
[06:28] <mjg59> We install it by default because there's no way of knowing whether the user has a bluetooth dongle that isn't connected at install time
[06:28] <TomaszD> that's my fifth and last article for a special Ubuntu edition of a certain Linux magazine, I'm dead tired and I don't want to make a mistake
[06:28] <doko> pitti: thanks
[06:29] <sladen> TomaszD: imagine if you had a bluetooth USB dongle;  wandered up to a machine and plugged it in;  it should "just work".
[06:29] <TomaszD> indeed, this is a real advantage over the earlier ubuntu editions
[06:30] <TomaszD> but to be fair, XP SP2 also handles this well
[06:30] <TomaszD> alright, thanks guys, back to writing
[06:30] <mjg59> No problem
[06:30] <pitti> TomaszD: yeah, the BT applet activates itself when I plug in my bluetooth dongle
[06:30] <sladen> TomaszD: (nb, the the plugging in bit is actually what "happens" with Fn-F5 style toggling of bluetooth radios on laptops)
[06:41] <mathiaz> keescook: I've pushed a new version of apparmor in my bzr branch.
[06:42] <keescook> mathiaz: okay, do we have a freeze exception for it?  (i.e. should I merge and publish?)
[06:42] <mathiaz> keescook: it should fix the audit messages in syslog not being parsed correctly.
[06:42] <mathiaz> keescook: I don't think we need an UVFe as it's 0ubuntu2.
[06:42] <mathiaz> keescook: but I think we need to ask pitti about it.
[06:43] <keescook> mathiaz: beta freeze means no uploads to main (of any kind) unless we get approval.
[06:43] <keescook> (i.e. not a UVFe, a BFe)
[06:43] <mathiaz> keescook: ok. So no, I don't have freeze exception.
[06:44] <keescook> mathiaz: okay, I'll merge and ask
[06:45] <TomaszD> one more question guys, since the installation of language packs during system installation is broken atm (known and reported bug, don't know about current status), the xdg-user-dirs are now in English in my Polish session (after installing language packs after system installation). I was informed that the folders are created upon user account creation and there is no way to change their names to my locale automatically, because they're created
[06:45] <TomaszD> just once, is there a workaround for this? Can I now change the names manually without breaking anything?
[06:46] <evand> TomaszD: lang packs should be installed in the latest daily live CDs
[06:47] <pitti> evand: thanks for fixing this; it worked in today's test install of mien
[06:47] <pitti> s/mien/mine/
[06:48] <TomaszD> evand, I'm subscribed to a bug about this and I haven't received anything about this, but nevermind. What about a scenario in which the network connection cannot be estabilished during installation (problematic drivers, etc), is there a workaround, I mean when I change default locale to Polish afterwards and download all the language packs, is there any way to handle locale changes with xdg-user-dirs?
[06:49] <TomaszD> I think there isn't anything I can do besides creating another user account :]  but if the langpacks are installed during installation then the problem is more or less covered
[06:49] <evand> TomaszD: I'm not sure, tbh I'm not as up on i18n as I should be.
[06:49] <evand> pitti: glad to hear it!
[06:49] <TomaszD> alright, np
[07:04] <iwj> ogra: What's the problem with autopkgtest and ltsp-client ?
[07:04] <MacSlow> although I replace the four icons with lapo's I still see kwwii
[07:04] <MacSlow>  's icons
[07:04] <MacSlow> I even did a restart
[07:05] <MacSlow> also wiping ~/.thumbnails didn't help
[07:05] <MacSlow> where else does gnome store icons?
[07:06] <pitti> MacSlow: try gtk-update-icon-cache?
[07:06] <cjwatson> iwj: re bug 144497, console-setup was deliberately uploaded before xkb-data binaries were ready (in the knowledge that the buildds would wait until that happened) in order to speed up the publication process
[07:06] <ubotu> Launchpad bug 144497 in console-setup "autopkgtest gutsy console-setup: erroneous package!" [High,New]  https://launchpad.net/bugs/144497
[07:06] <cjwatson> iwj: perhaps you should have your test harness wait a bit before filing build-depends bugs?
[07:06] <MacSlow> pitti, yep
[07:06] <MacSlow> pitti, no change
[07:07] <iwj> cjwatson: Err, it's difficult to know what "wait a bit" would mean.  That's not really how it works - it picks a package to test and then files a bug if it failed.
[07:07] <iwj> cjwatson: I could have it put the package to one side with a note to retest soon and file a bug if still broken I suppose.
[07:08] <iwj> cjwatson: But really the rate of these failures is quite low.  You only get a bug like this if autopkgtest happens to pick your package at a time when it's broken.
[07:08] <cjwatson> I don't know exactly how it would be implemented
[07:08] <cjwatson> fair enough
[07:08] <cjwatson> I've just closed it now
[07:12] <ogra> [   ]  gutsy-server-i386.OVERSIZED         24-Sep-2007 18:05    0
[07:12] <ogra> [   ]  gutsy-server-i386.iso               24-Sep-2007 18:02  700M
[07:14] <IntuitiveNipple> Is alternate CD x86 i386 install supposed to be offering x86_64 kernel image updates when Update Manager first runs after booting the installed system?
[07:14] <pitti> ogra: ugh
[07:14] <pitti> IntuitiveNipple: erm, no
[07:15] <jdong> is that even possible?
[07:15] <IntuitiveNipple> pitti: hmmm!
[07:15] <ogra> pitti, well, a pngcrush on the new wallpaper and it should be fine i guess
[07:15] <IntuitiveNipple> I can give you a screenshot if you like lol
[07:15] <ogra> cant be mush thats over now
[07:15] <ogra> *much
[07:16] <ogra> oh, wait, ubuntu is still 4M over i should inherit something of that :)
[07:17] <ogra> iwj, do you have a blacklist for packages in autopkgtest ? ltsp-client/-core should be excluded
[07:17] <iwj> ogra: Sorry, I'm afraid my bot has filed another dupe of that bug.
[07:17] <ogra> ah, thats fine, i can ignore that
[07:17] <iwj> I was using ltsp-client as a test case and the dupe suppression arrangements didn't work properly.
[07:17] <iwj> With luck you won't get another dupe.
[07:17] <ogra> ah, k
[07:18] <iwj> I don't have a blacklist in the sense that there's a manual blacklist.  But it's supposed to ignore source packages which have open autopkgtest bugs.
[07:18] <ogra> as i said, i can ignore that, just be aware that its supposed to fail in non ltsp chroots :)
[07:18] <iwj> I'm afraid I don't have time right now to discuss it in detail.
[07:18] <iwj> How about we chat tomorrow some time ?
[07:18] <ogra> sure
[07:18] <iwj> Thanks.
[07:18] <iwj> And sorry for the noise.
[07:19] <ogra> np
[07:35] <sladen> mjg59: something weird, fan started spinning fast, 20 wake-ups per seconds (libata and firefox), 65% in C0, nothing in top, turned the wireless/BT off and it's still the same.
[07:36] <sladen> mjg59: oh wait, no:  Wakeups-from-idle per second : 33200.1    and yet the top two items in powertop show only 10 each
[07:50] <LongPointyStick> evand: ping?
[07:50] <evand> LongPointyStick: pong
[07:53] <mvo> lamont: re #141559: having the breaks is good, but it seems like it is not sufficient as it seems to be possible to mount nfs in feisty without nfs-common so a transtion that checks for nfs mounts and adds nfs-common is required
[07:53] <lamont> ok
[07:54] <mvo> lamont: I should have the required code in update-manager now, I do a test and then commit
[07:56] <lamont> mvo: fwiw, I think we waved our hands and said that if you didn't care about locking, then it was OK that you couldn't mount your nfs partitions. :-)  So yeah, forcing the install on nfs-mount-existance is a good thing
[07:57] <mvo> lamont: haha, ok :) for debian  a debconf note might be appropriate if no nfs-common is installed and nfs-mounts are in used
[07:57] <sladen> mjg59: puzzling, nothing in /proc/interrupts is catching those 32k interupts, so timers I guess.  utterly puzzled
[07:57] <lamont> probably
[07:58] <lamont> then again, I have until lenny freezy to worry about that... :)
[08:00] <psusi> how should I go about getting corrections made to https://help.ubuntu.com/7.04/installation-guide/i386/apcs03.html ?
[08:00] <cjwatson> psusi: file a bug on installation-guide
[08:00] <cjwatson> (it can then be corrected for 7.10, probably not for 7.04)
[08:00] <psusi> that's a package name?  installation-guide?
[08:01] <psusi> ok.... it suggests making separate /usr, /var, and /tmp partitions for multi user systems... /tmp definately should not have its own partition since it is mounted as a tmpfs
[08:02] <cjwatson> psusi: yes, it is a package name
[08:03] <psusi> k
[08:03] <cjwatson> and I didn't say to make your bug report here :)
[08:08] <KaiL> just saw, that gutsy still has fglrx 8.37.6, any plans to add 8.41.7, which supports Radeon HD 2xxx?
[08:10] <Kopfgeldjaeger> how can i replace one 2 newlines (if they are "together") in a text file? \n\n\n should become \n, and \n\n should become \n
[08:11] <psusi> what's the difference between confirmed and triaged again?
[08:12] <psusi> I still don't quite have the hang of the new system
[08:12] <Kmos> psusi: https://wiki.ubuntu.com/Bugs/Status
[08:12] <cjwatson> I don't find the distinction particularly valuable, but perhaps others do
[08:14] <pitti> psusi: confirmed> another user besides the reporter also gets this bug; triaged> a developer looked at it and thinks that the bug has enough information to start working on a fix
[08:15] <psusi> they both mention having enough information to start working on a fix
[08:15] <pitti> psusi: that's why only ubuntu-qa people can use 'triaged'
[08:16] <psusi> hrm... I set this bug to triaged because I confirmed someone else's diagnosis of the problem as being that the documentation just needs updated, is that wrong?
[08:19] <pitti> psusi: sounds good to me, and I'm with cjwatson here: I wouldn't rely on the precise semantics of those two states anyway
[08:20] <psusi> so normal users can only set it to confirmed, and because I'm in the right group I am allowed to move it to triaged, which really then should get dev attention?  at least, is that the ideal?
[08:21] <pitti> psusi: it's more useful as a way to organize your personal bug list, but yes
[08:25] <pkern> Does Ubuntu Firefox have some kind of ligature support?
[08:28] <pkern> (They are drawed incorrectly on my Gutsy machine. The following char is painted over the ligature.)
[08:32] <pitti> pkern: apparently; 'ffl' renders badly
[08:34] <pkern> pitti: So I should file a bug against mozilla-firefox? It makes text badly readable, especially because they are even displayed in wrong font weights on some sites (i.e. I observed it on LP where "ff" in a word was rendered differently).
[08:34] <pitti> pkern: sure (against 'firefox', though)
[08:36] <pkern> Hm it is already reported and fairly old (LP: #37828).
[08:37] <pkern> Bah, the workaround is to take a font which does not support ligatures.
[08:38] <sladen> pkern: freetype, lower level than that
[08:39] <pkern> It's a firefox bug.
[08:39] <pkern> Gtk renders them fine, only firefox takes the wrong ligature width.
[08:40] <pwnguin> is that why they went with a fixed-width font system for lp's comments?
[08:50] <gnomefreak> pkern: on feisty or gutsy?
[08:51] <pkern> gnomefreak: gutsy
[08:51] <pkern> gnomefreak: Pretty fresh install.
[08:52] <gnomefreak> pkern: ty talking with asac about it atm
[08:52] <asac> pkern: do you have a testcase for that?
[08:52] <asac> e.g. some page i can open to see the issue?
[08:54] <gnomefreak> asac: how many pages do you want? theres a ton on that bug report ;)
[08:55] <gnomefreak> ton == >=5
[08:55] <pkern> asac: http://antigrain.com/research/font_rasterization/index.html :-P
[08:55] <asac> i have visited too many bugs in the last few days ;)
[08:55] <pkern> Search for "offset"
[08:55] <asac> looks good here
[08:55] <asac> lets see what font i have
[08:56] <pkern> I have "serif", "sans-serif" and "monospace" in Firefox's font settings.
[08:56] <asac> ah ok its different in epiphany
[08:56] <Riddell> mvo: ping
[08:56] <pkern> So it probably matches to the (Gnome?) default fonts.
[08:56] <Riddell> mvo: I think I need to upload a revert to distUpgrader
[08:56] <pkern> asac: It's *fixed* in Epiphany? Then I would switch back. :-P
[08:56] <Riddell> mvo: can I just commit and you'll do that for me?
[08:57] <asac> pkern: yeah its fixed in there ... most likely because epiphany chooses a different set of fonts for gecko?
[08:57] <pkern> asac: So that means you have no ligatures at all in epiphany?
[08:58] <asac> yes maybe epiphany doesn't use pango?
[08:58] <pkern> Phew.
[08:58] <pkern> Argh. Could somebody please kill `epiphany'.
[08:59] <asac> pkern: yes if i start firefox with MOZ_DISABLE_PANGO=1 its /fixed/ ?
[08:59] <asac> :)
[08:59] <lamont> pkern: they don't allow guns at my office.
[08:59] <gnomefreak> asac: i dont htink it "did" atleast in edgy because that is where most of the firefox bugs about pango slowing fox down people used epiphany to speed it up or they would turn pango off
[08:59] <asac> pkern: in the same way fixed as in epiphany
[08:59] <mvo> Riddell: sure, what do you need ?
[09:00] <Riddell> mvo: remove the killall and go back to using the dcop code to kill adept
[09:00] <Riddell> mvo: although I'm not sure the best way to test it
[09:00] <mvo> Riddell: I take that this is urgent and should go in before beta?
[09:00] <Riddell> mvo: yes
[09:00] <mvo> Riddell: consider it done
[09:01] <Riddell> mvo: I've not committed yet
[09:01] <mvo> Riddell: sure, commit
[09:01] <Riddell> well, I should test it first, and I don't know how to do that
[09:01] <Riddell> it needs adept to download a copy and validate the signature etc but I can't sign it
[09:02] <Riddell> spose I can hack adept not to validate
[09:02] <lamont> slangasek: would you be annoyed if I marked bug #144364 for beta milestone?
[09:02] <ubotu> Launchpad bug 144364 in expect "Please sync expect (main) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/144364
[09:02] <mvo> Riddell: or just run "./build-tarball" in the DistUpgrade dir and copy the tarball into your testsystem and unpack it
[09:02] <pkern> asac: Yep, no ligatures in epiphany. \:
[09:04] <pkern> asac: OTOH if the choice is between ligatures and invalid rendering... ;)
[09:04] <pkern> But this firefox issue should really be fixed in some way or another before the release.
[09:04] <slangasek> lamont: I think I might be confused
[09:04] <asac> pkern: yes
[09:05] <asac> pkern: remind me after beta
[09:05] <asac> :)
[09:05] <lamont> slangasek: it's a question of whether or not ia64 counts for beta... that's all. :-)
[09:05] <pkern> asac: The problem is that we don't have milestones for >beta?
[09:05] <lamont> and if I mark it for beta, then it shows up on your reports...
[09:05] <asac> pkern: most likely we would need to go back to xft then for normal locales ... which i don't like
[09:06] <asac> pkern: well you can target it for gutsy
[09:06] <pkern> It's "Nominated for Gutsy".
[09:06] <slangasek> lamont: well, it doesn't "count" for beta, but if the fix is straightforward and localized I'm happy to accept the fix
[09:06] <slangasek> which is not to say it should be milestoned, but eh
[09:07] <pkern> asac: Does that mean that it still needs to be accepted by a RM to be of use?
[09:08] <asac> pkern: i must admit that i am confused that there is no final milestone as well
[09:08] <asac> pkern: so what i did when i pushe back was 'just' schedule for gutsy
[09:14] <mdz> mjg59: who's responsible for turning the backlight back on during resume?  (it doesn't get done on my T61)
[09:15] <mdz> acpi-support?  X?  something else?
[09:15] <ion_> Sorry, i forgot to turn it on. Ill do better the next time.
[09:15] <rohan> jdong: ping, are you around ?
[09:15] <mjg59> mdz: Are you running 32-bit or 64-bit?
[09:15] <mjg59> The answer is vbetool, regardless, but the bug is in libx86
[09:16] <mjg59> I've fixed it for 64-bit, 32-bit is harder
[09:16] <mdz> mjg59: 32
[09:16] <rohan> is it too late in the release timeline now to fix a bug in sound drivers which has been fixed upstream ?
[09:16] <mjg59> rohan: For beta, yes. For final, probably not
[09:16] <mjg59> mdz: The issue is that the IBM BIOSes try to read from an address just under 4GB
[09:17] <mjg59> mdz: This doesn't work so well. We need a segfault handler to grab the previous instruction, disassemble it, read the memory, hand it back to the vm86 context and then reenter vm86 mode
[09:17] <mdz> ick
[09:17] <mdz> so I should reinstall as 64-bit if that's feasible for me
[09:18] <rohan> mjg59: ok. i was referring to https://bugs.launchpad.net/bugs/109882 ... would you know what can i do further to help out with this bug ?
[09:18] <mjg59> In 64-bit mode, we use x86emu and so can just catch the reads directly
[09:18] <ubotu> Launchpad bug 109882 in fedora "Headphone automute not working" [Unknown,Confirmed] 
[09:18] <mdz> mjg59: is there a bug open about this, and if not, should I file one?
[09:18] <mjg59> rohan: If it's fixed upstream, find out which commit fixed it and mention that in the bug
[09:18] <mjg59> mdz: There is, yes
[09:18] <mdz> I looked and don't see one which is obviously a match
[09:19] <mjg59> I suspect that many of the bugs that involve vbetool segfaulting are related to this
[09:19] <mjg59> But it took me a while to realise what was going on - I didn't know that x86 could directly access >1MB from real mode...
[09:20] <rohan> mjg59: problem is, it's a kernel bug, but i don't know how to find which commit specifically in alsa fixed it
[09:20] <mvo> Riddell: I have a update-manager fix pending too, so please let me know when you are ready and I will upload
[09:20] <rohan> how do i relate the two ?
[09:20] <mjg59> rohan: Look at the kernel revision history at git.kernel.org
[09:21] <mdz> mjg59: which vbetool command would it be which is failing?  i can try to confirm it here
[09:21] <rohan> mjg59: err i mean, i'm not sure if the changes are in kernle yet. it might just be fixed in the alsa's code tree ?
[09:21] <mjg59> mdz: vbetool post
[09:22] <mjg59> rohan: Then find the commit in the alsa tree and link to it
[09:22] <mdz> mjg59: yep, that triggers it
[09:22] <mdz> Error: something went wrong performing real mode call
[09:22] <mdz> and no backlight
[09:22] <mdz> spawning a new X server fixes it
[09:22] <rohan> mjg59: ah i see.
[09:23] <mjg59> mdz: Hm. Just "Something went wrong", and no segfault?
[09:23] <mdz> mjg59: correct
[09:23] <mjg59> Odd.
[09:24] <mjg59> Maybe lrmi already catches the segfault.
[09:24] <mdz> exit(1)
[09:24] <mdz> mjg59: is it worth trying POST_VIDEO=false?
[09:24] <Amaranth> That reminds me, is there some guide to debugging resume issues?
[09:25] <mjg59> mdz: No, that's not adequate
[09:25] <mjg59> mdz: You can work around it for now by booting with acpi_video=s3_bios
[09:25] <Amaranth> As far as I can tell my resume fails as soon as it starts, I don't even get a working num lock key
[09:25] <mjg59> mdz: That runs the code in kernel mode, which means the VM limitations are somewhat less, well, limited
[09:25] <Amaranth> Actually this sounds like the problems I was having with ata_piix awhile back, I should try changing my controller to legacy
[09:27] <rohan> mjg59: well unfortunately i can't find the specific change in patch_realtek.c but i'm sure it's been fixed :-/ any more pointers ?
[09:27] <mjg59> rohan: It definitely works with upstream alsa?
[09:28] <rohan> mjg59: yes, i've tried
[09:28] <mjg59> Ok, then I think you've done all you can for now
[09:28] <mdz> mjg59: thanks.  is there anything else I can do to help define the problem, or do you know everything you need to know already?
[09:29] <rohan> mjg59: because it's working perfectly on arch linux, and on driver i compiled in feisty using code checked out from the alsa hg repo
[09:29] <mjg59> mdz: I've got the BIOS disassembly and function trace, so I think I'm set :)
[09:31] <rohan> mjg59: the problem is, arch uses newer alsa than the one in kernel 2.6.22 or 2.6.23-rcX .. so it seems that none of the soon-to-be-released distros have this bug fixed. so there's nothing i can do, atleast for gutsy, before this change of alsa is merged in upstream kernel ?
[09:32] <mjg59> rohan: It depends whether we pull upstream alsa into our tree or not
[09:33] <Chipzz> sladen: I'm not sure I agree with the "should just work" assertion
[09:33] <rohan> mjg59: ok, what if i attach a patch to that bug against kernel 2.6.22.6 which fixes the bug ?
[09:34] <Chipzz> sladen: a very real concern is companies with confidential data; mounting of USB sticks there is not allowed, and you could circumvent that with plugging in your USB dongle and using your phone as a storage device
[09:34] <mjg59> rohan: If it does, and if it's not just the entire file backported, sure
[09:34] <mjg59> Chipzz: Then individual companies can set appropriate policies
[09:35] <rohan> wow i think i already found the commit which fixes it. but i've got no way to check if my "hunch" is right or no
[09:35] <rohan> http://hg.alsa-project.org/alsa-kernel/diff/3a300e020eca/pci/hda/patch_realtek.c --> this is what fixed it, i think
[09:36] <mjg59> rohan: If you make that change to the Ubuntu kernel, does it work?
[09:37] <rohan> mjg59: you mean, the gutsy kernel 2.6.22.x ?
[09:37] <mjg59> Yes
[09:37] <rohan> i have not tried.
[09:37] <rohan> is there a way to try it without rebuilding the complete kernel /
[09:37] <mjg59> No
[09:38] <rohan> then ?
[09:38] <rohan> oh, sorry. .
[09:38] <rohan> that means i'll need to install gutsy
[09:41] <rohan> mjg59: the file patch_realtek.c has changed so much since 2.6.22 that it's not possible to apply it over single diffs of alsa hg repo
[09:42] <mjg59> rohan: If you can supply a working patch, then that would be helpful - but if not, then we'll still look into backporting the code
[09:43] <rohan> mjg59: well i've attached a patch but basically it's just a backport of alsa-kernel as on 20070818 to 2.6.22.6
[09:50] <pitti> new ubuntu alternates up for testing
[09:53] <Lure_> pitti: btw, was crypt-auto removed or fixed for beta?
[09:53] <pitti> Lure_: demoted to universe for now (i. e. removed from installer)
[09:53] <pitti> Lure_: I'd rather not offer a broken feature when it sounds that sexy :)
[09:53] <Lure_> pitti: ok, so it is planned to be done post-beta or gutsy+1?
[09:54] <pitti> Lure_: depends; when we can fix the cryptsetup initramfs hook soon, we can add it again for final (since it's not the default option anyway)
[09:56] <sladen> Chipzz: policy issue, vs. technical issue.
[09:57] <sladen> Chipzz: technically, things should just work.  If somebody makes a choice ("sets a policy") that is different
[09:59] <evand> pitti: were you planning on building daily lives anytime soon?  I have to in order to pull in the latest Wubi, and there's no sense in having two CDs separated by a few minutes.
[10:01] <pitti> evand: hm, I'm currently building new ones
[10:01] <evand> pitti: when did you start?
[10:01] <pitti> evand: however, cjwatson mentioned that we'll need another ubiquity anyway? it's not in the queue yet
[10:01] <pitti> evand: 10 minutes ago or so
[10:02] <evand> ah, right
[10:02] <evand> I had forgotten about that bit :)
[10:02] <pitti> evand: I have no problem with triggering new ones in two hours or so
[10:02] <evand> I'll wait then
[10:02] <evand> ok, thanks
[10:02] <evand> I'll take care of it in 2 hours if ubiquity is built
[10:02] <pitti> evand: for my planning, do you plan a new ubiquity?
[10:02] <pitti> evand: ah, you have cd building powers now? great
[10:03] <pitti> evand: then I don't need to stay awake that long *and* get up early
[10:03] <evand> pitti: indeed, for quite some time -- I just don't need to use it all that often
[10:03] <evand> haha, apparently I do :)
[10:03] <evand> yeah, if you ever need CDs built and want to go to bed, just let me know
[10:03] <pitti> evand: last time I did a "sleep 7200 && cron.daily.. :)
[10:04] <evand> haha
[10:04] <evand> that works as well
[10:07] <Riddell> mvo: do you know why dist updater needs to start a new X app?
[10:08] <evand> pitti: re new ubiquity> there's 1.5.18 which is probably what Colin mentioned that has the fix for the OEM issue you mentioned earlier.  That hasn't been released yet, I'll take care of it now.  After that, it's quite hard to say if there will be any/many more ubiquity releases.  We're trying to work around the unionfs issues and get the windows installer work stable enough to be included in the beta.
[10:12] <rohan> mjg59: as i've commented on the bug, i've found the specific commit upstream and listed it. nothing more i can do, right ?
[10:12] <MacSlow> http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-6.2.png http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-5.png
[10:12] <mvo> Riddell: sometimes it does that for the debconf questions
[10:13] <MacSlow> what icon-set would you prefer?
[10:13] <mjg59> rohan: I think that's it, yes
[10:13] <heno> evand: what was fixed in the new wubi upload? I tried a few hours ago and it crashed at the partman step
[10:13] <rohan> MacSlow: the first one. 6.2
[10:14] <MacSlow> rohan, yeah me too
[10:14] <MacSlow> but I better put that on the ml for more people to see
[10:14] <rohan> MacSlow: assuming that even in the first one Custom appears only if ccsm is installed
[10:14] <evand> heno: I *think* the partman bit is actually weird unionfs issues, but there might be more there.
[10:14] <MacSlow> rohan, yes... that is always the case
[10:14] <evand> heno: the new wubi is to fix the transition from alpha to beta, I believe
[10:15] <rohan> though i must say compiz looks real strange on the latest live cd. there were 2 cm thick white borders around each menu .. which was not there in the earlier live cds
[10:15] <heno> evand: ok. any suggestion on how to help debug the unionfs issue, or work around it to test the rest?
[10:16] <rohan> and the wallpaper is strange, so is the new resolution problem which affects atleast me and jdong
[10:18] <evand> heno: not entirely sure as Colin wrote the partman loopmounted fs code and I'm not too familiar with it yet.  If the bug you're hitting is in fact a unionfs issue, then unfortunately there's not much we can do at the moment.
[10:18] <Ng> rohan: I think the white borders thing is known, it has to do with the radius of the shadow or something
[10:18] <rohan> Ng: ah, i see
[10:21] <slangasek> the known white border issue is already supposed to be fixed, I'd have thought it would be in the latest live CD by now
[10:21] <slangasek> but maybe I have my timeline wrong
[10:21] <rohan> well i was using 22nd september's cd
[10:28] <evand> pitti or anyone else who can: can you upload and let ubiquity 1.5.18 through, it is a very small diff: http://people.ubuntu.com/~evand/upload/ubiquity_1.5.18.dsc
[10:30] <Keybuk> I can upload
[10:30] <evand> thanks Keybuk
[10:30] <Keybuk> though I wouldn't want to override an ftpmaster to get it through
[10:30] <evand> ok
[10:31] <Keybuk> they bite
[10:32] <evand> hahaha
[10:32] <Keybuk> my Soyuz powers are for emergencies, like when I upload something foolish and need to delete it out of the queue so nobody knows about it

[10:33] <evand> so often, basically
[10:33] <Keybuk> :-O
[10:35] <heno> same reason I always just edit wiki.u.c pages right on the web server, no logs
[10:36] <heno> (joke)
[10:37] <bddebian> pitti: Got a sec for a quick, probably dumb, .desktop file question?
[10:38] <jdstrand> mdz: are you still seeing bug #99288? If not, what did you do to fix/workaround it?
[10:38] <ubotu> Launchpad bug 99288 in xserver-xorg-video-ati "Screen corruption on Radeon Mobility M7 LW [Radeon Mobility 7500] " [Medium,Confirmed]  https://launchpad.net/bugs/99288
[10:39] <rohan> i think the reply of ubotu for "hi" needs to be changed.. it says "hi, welcome to ubotu" .. err, ubotu ? :P
[11:10] <pitti> evand: looking at ubiquity now
[11:11] <evand> thanks pitti
[11:15] <Amaranth> arg, how do i get myself added to the list of people allowed to post to ubuntu-devel?
[11:17] <_MMA_> Amaranth: If I remember correctly Colin admins it. He should be able to add you to the white list.
[11:17] <ScottK> Amaranth: Wasn't it automatic?
[11:17] <Amaranth> apparently not
[11:18] <elmo> it is automatic, but there's a days lag or so
[11:18] <elmo> and it only whitelists your addresses in launchpad
[11:18] <Amaranth> Hrm, alright.
[11:18] <Amaranth> elmo: Is your problem with switching multiple viewports fixed now?
[11:19] <elmo> Amaranth: I have to admit I haven't had a chance, I'll boot back into compiz tomorrow when I'm @ the office and check
[11:19] <Amaranth> elmo: Ah, alright. It should now take the same amount of time to do the animation no matter how many viewports you're changing between
[11:20] <elmo> Amaranth: ah, hmm, ok
[11:20] <elmo> Amaranth: seb was suggesting disabling the animation entirely if invoked by a keybinding, you guys didn't want to go with that?
[11:20] <Amaranth> elmo: the problem is it's a different plugin
[11:21] <Amaranth> elmo: the one that supports "go to viewport 8" cannot tell the wall plugin that it is the one requesting the change
[11:22] <elmo> Amaranth: ah, ok
[11:22] <elmo> Amaranth: well, I'll give it a go - I'd like to stick with compiz if I can :)
[11:22] <Amaranth> :)
[11:22] <Amaranth> elmo: I don't get your problem with increasing the text size in gnome-terminal. It does the right thing for me
[11:23] <elmo> Amaranth: yeah, I think someone fixed that
[11:23] <elmo> it was broken, I promise ;)
[11:23] <Amaranth> elmo: ah, good news
[11:23] <Amaranth> i saw :)
[11:26] <elmo> Amaranth: ok, yeah, the workspace switching is much better
[11:26] <Amaranth> woohoo
[11:27] <Amaranth> mvo: bug 141543 is fixed, right?
[11:27] <ubotu> Launchpad bug 141543 in compiz "Gutsy regression - compiz no longer starts with a failed 3d texture size check" [High,Incomplete]  https://launchpad.net/bugs/141543
[11:28] <mvo> Amaranth: yes
[11:29] <Amaranth> mvo: did we ever decide what to do with bug 116807?
[11:29] <ubotu> Launchpad bug 116807 in compiz "Number of rows of desktops forgotten if no switcher on panel" [Critical,Confirmed]  https://launchpad.net/bugs/116807
[11:29] <Amaranth> mvo: it doesn't work with metacity either...
[11:29] <mvo> Amaranth: yeah, lets move it down from critical to medium and add a task for metacity/libwnck-applet
[11:31] <Amaranth> mvo: ok, 5 'High' bugs now and i think we can fix all but one of them
[11:31] <mvo> Amaranth: which one is the one we can't fix?
[11:32] <Amaranth> the one where alt-tab doesn't "talk"
[11:32] <Amaranth> well, maybe
[11:32] <Amaranth> but since orca kills my computer i haven't been too motivated
[11:36] <Amaranth> brb
[11:41] <mvo> Riddell: anything new about the u-m thing?
[11:41] <mvo> Amaranth: ok
[11:41] <Riddell> mvo: yes, think I have it sorted now
[11:43] <Riddell> mvo: committed, ready to upload
[11:46] <Riddell> mvo: err
[11:47] <Riddell> the upgrade just asked me via debconf what PAM services to restart, the options included kdm, and it just killed X
[11:47] <bryce_> I ran into that too
[11:47] <bryce_> the dialog does suggest removing gdm and kdm, which I did and the install continued
[11:48] <bryce_> I'm not sure why it would want to restart gdm/kdm in the middle of an upgrade
[11:48] <Riddell> that really needs fixing before beta
[11:48] <Riddell> is there a bug number?
[11:48] <bryce_> don't know
[11:48] <Riddell> I wish I'd payed some attention to it, don't even know what package it was
[11:50] <bryce_> hmm, it was one of the daemons iirc
[11:52] <Riddell> libpam0g/restart-services maybe?
[11:52] <ScottK> Riddell: I'm pretty sure it's kees PAM update https://lists.ubuntu.com/archives/ubuntu-devel/2007-September/024213.html
[11:52] <Riddell> keescook: could it be?
[11:53] <keescook> the PAM thing is killing gdm/kdm yeah.  We should blacklist those services
[11:54] <Riddell> keescook: that really needs fixed toot sweet
[11:54] <mvo> Riddell: yeah, I reported that already
[11:54] <keescook> sure, can you make a bug for it?  I'll go fix it up right now (waiting for kernel publications atm)
[11:54] <keescook> mvo: ah, do you have a #?
[11:55] <mvo> keescook: it should be on the beta list already :)
[11:55] <tepsipakki> isn't there just a reload option for kdm too?
[11:56] <mvo> keescook: bug #141309
[11:56] <ubotu> Launchpad bug 141309 in pam "asks debconf question during upload" [Undecided,New]  https://launchpad.net/bugs/141309
[11:56] <mvo> keescook: its not milestoned, but I think it should be
[11:56] <Riddell> bug 139065 got there first
[11:56] <ubotu> Launchpad bug 139065 in pam "pam upgrade restarts kdm without warning" [Undecided,Confirmed]  https://launchpad.net/bugs/139065
[11:57] <keescook> mvo: your bug is slightly different (it's shouldn't ask at all) vs the kdm killer
[11:57] <mvo> keescook: it definitely should not ask a end user
[11:57] <keescook> mvo: right, agreed.  but how do maintainer scripts now a feisty->gutsy upgrade is happening?
[11:58] <keescook> (rather than "just" a gutsy devel upgrade)
[11:59] <mvo> keescook: you could check against the version you are upgrade from I guess. the dist-upgrader also sets a special environment (testing against that would be a bit messy)
[11:59] <tepsipakki> seriously, isn't a reload enough.. then it could do that without asking
[12:00] <keescook> tepsipakki: well, the other services need to be restarted too
[12:00] <tepsipakki> keescook: hmm, right
[12:01] <keescook> mvo: how did you handle this when openssl was upgraded (it did the same thing)
[12:02] <mvo> keescook: I don't remember off-hand, maybe by lowering the debconf question priority (default during the upgrade is high)
[12:02] <tepsipakki> keescook: there is an exception for gdm in the libpam0g.postinst, which makes it to use reload instead
[12:02] <keescook> tepsipakki: yeah, using |kdm there will fix it, (building that now)
[12:03] <tepsipakki> keescook: ah :)
[12:03] <keescook> mvo: ah, I can drop the question priority then.  that should do it.
[12:04] <Riddell> keescook: surely it needs an exception for all login managers?
[12:04] <keescook> Riddell: it does -- what is xfce's?
[12:04] <Riddell> oh, xubuntu just uses gdm, I didn't know that
[12:04] <keescook> ah, okay
[12:05] <keescook> are there any others?
[12:05] <Riddell> keescook: ldm
[12:05] <Riddell> wdm
[12:05] <Riddell> xdm
[12:05] <Riddell> and maybe sdm
[12:06] <Riddell> slim too
[12:06] <keescook> should I just add all of those too, or maybe strengthen the warning?
[12:07] <Riddell> both?
[12:07] <Riddell> can't just strengthen the warning, else kdm etc will always reboot
[12:07] <Riddell> and it doesn't seem like a very interesting question to desktop users
[12:09] <keescook> is ltsp's ldm's init script called "ldm"?
[12:09] <nixternal> keescook: thanks for the uploads today
[12:09] <Riddell> it would seem to follow the pattern :)
[12:09] <mvo> Riddell: do you want to do the u-m upload or should I do it?
[12:10] <keescook> nixternal: you bet -- sorry it took me a few days, I wanted to test the builds (I'm paranoid), but it got bumped by high-priority kernel updates.
[12:10] <nixternal> keescook: paranoia with kdebase is a good thing :)
[12:10] <nixternal> you weren't the only one
[12:10] <keescook> nixternal: heh
[12:10] <Riddell> keescook: it doesn't seem to have one http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=ldm&version=gutsy&arch=i386
[12:10] <bryce_> Riddell: where are the release notes maintained?  I have a note I need to add to it about Xinerama incompatibilities with xrandr
[12:11] <Riddell> mvo: probably best if you do it
[12:11] <Riddell> bryce_: I'm not sure any exist yet
[12:12] <mvo> I unmarked #141309 as duplicate
[12:12] <mvo> Riddell: ok, I do that now
[12:13] <bryce_> slangasek: do you know if anyone has begun compiling release notes for gutsy?
[12:14] <Riddell> mvo: why isn't it a duplicate?
[12:14] <mvo> Riddell: your is about killing kdm, mine is about question the question at all
[12:14] <mvo> Riddell: I don't think that it should be seen at all (the question)
[12:15] <mvo> it should just do the right thing(tm)
[12:15] <keescook> e.g. even if we fix mvo's bug, we'd still have the kdm bug.
[12:15] <Riddell> seems like a strongly related problem since one causes the other as it stands
[12:15] <Riddell> keescook: I was hoping you'd fix both :)
[12:15] <keescook> Riddell: I will be.  :)
[12:15] <mvo> Riddell: right
[12:15] <Riddell> bryce_: https://wiki.kubuntu.org/GutsyGibbon/Beta would be a place for them
[12:17] <keescook> mvo: what is the env variable?  I think it's correct to leave it at "critical" if someone is crazy enough to do an "apt-get dist-upgrade"
[12:18] <bryce_> aha, https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
[12:19] <Riddell> hmm, someone should probably have told the release team about that
[12:20] <cjwatson> Riddell: pam should use '/etc/init.d/* reload' for *dm and (if it doesn't already) kdm should support the same thing that gdm does in that reload should only take effect after all current sessions have ended
[12:21] <cjwatson> IMO
[12:21] <cjwatson> ah, I see that some of the discussion above covered that
[12:21] <slangasek> keescook: if you give me another day, I can have a revised PAM in Debian available for merge that only restarts kdm when it's not in use (and unstable already has a version that doesn't need to kill gdm)
[12:21] <keescook> cjwatson: since the list of services pam restarts is fixed, I've just added the exception for kdm, wdm, and xdm as well now.
[12:22] <slangasek> ("restarts kdm without warning", har)
[12:22] <keescook> slangasek: cool.  are there other changes in there too?
[12:22] <cirkit> ?
[12:22] <Riddell> slangasek: I'd rather have this working as soon as possible, upgrades need testing
[12:22] <mvo> keescook: RELEASE_UPGRADE_IN_PROGRESS
[12:23] <slangasek> keescook: and kdm reload doesn't do anything useful afaik, so is a wrong fix
[12:23] <slangasek> bryce_: ah, don't know yet, no
[12:24] <keescook> slangasek: well, the init script thinks it does something (though it may not re-exec -- i.e. wrong fix), but it certainly shouldn't just kill it :)
[12:24] <bryce_> slangasek: I found one someone started at https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
[12:24] <bryce_> s/someone/Fabio/
[12:25] <elmo> gah, abiword for the lose
[12:25] <slangasek> mvo: I'm not sure "cause service interruptions for all PAM-based services without warning" is "dtrt"?
[12:25] <elmo> helpfully exports to text, complete with deleted parts of a word document under ""revision control""
[12:26] <slangasek> keescook: there are other PAM changes pending, but I don't think I'll have them all ready so soon (ari wants me to add some auto-twiddling for xscreensaver, but that needs some further debconf template rewrites)
[12:27] <keescook> mvo: perhaps if there are "non-default" services running, we can set the question priority at critical?
[12:27] <keescook> i.e. restarting cron, cupsys, and gdm automatically isn't a problem... but other things might be surprising.
[12:28] <slangasek> (and ssh)
[12:28] <mvo> ok, fair enough
[12:28] <mathiaz> keescook: did you get a BFe for apparmor ?
[12:28] <keescook> slangasek: right, though ssh isn't install by default.
[12:28] <mvo> I really do not want it in a upgrade from a desktop system as it does not mean anything to the user
[12:28] <keescook> mathiaz: haven't asked yet, sorry, my morning was eaten by kernel updates.
[12:28] <mathiaz> keescook: did you merge my branch ?
[12:28] <slangasek> keescook: yes, but I exclude ssh explicitly from the list to be confirmed because ssh can be safely restarted without interrupting current sessions :)
[12:28] <mathiaz> keescook: I'm going to push more changes related to profiles.
[12:29] <keescook> slangasek: ah, good point.
[12:29] <mathiaz> keescook: it may not qualify for BFe.
[12:29] <keescook> mathiaz: the new changes may not, you mean?
[12:29] <slangasek> hmm, maybe I exclude it;  now I don't remember
[12:29] <mathiaz> keescook: yes. The changes to the profiles.
[12:29] <keescook> mathiaz: let me make sure I'm up to date ...
[12:30] <keescook> mathiaz: okay, go ahead
[12:30] <keescook> slangasek: I don't even see ssh in your list?
[12:31] <slangasek> keescook: oh, that's right; ssh doesn't even need a restart because it seems to magically reexec itself on every connection
[12:31] <keescook> hunh.