[00:16] <Hillshum> Can I ask for help with packaging here?
[00:16] <directhex> Hillshum, #ubuntu-motu
[00:16] <Hillshum> ok
[00:22] <chrisccoulson> kirkland - regarding bug 390504 (you were wondering when the fix was going to be released)
[00:22] <chrisccoulson> we're probably not going to bother waiting for the tarball now
[00:23] <kirkland> chrisccoulson: yeah?
[00:23] <kirkland> chrisccoulson: so sooner rather than later?
[00:23] <chrisccoulson> so the answer is "probably straight after A3"
[00:23] <chrisccoulson> hopefully;)
[00:23] <chrisccoulson> the current behaviour is quite annoying
[05:09] <ccheney> slangasek: ping
[05:26] <slangasek> ccheney: hi
[05:27] <ccheney> slangasek: did you buy your train ticket yourself or some other way?
[05:27] <ccheney> slangasek: i just got an email apparently yesterday mentioning for me to get it done since the travel agency couldn't do it
[05:27]  * ccheney was out of town until tonight
[05:28] <slangasek> ccheney: I bought mine myself on-line, through much toil
[05:28] <slangasek> ccheney: the problem is that when you search for tickets, their website shows all kinds of tickets for trains that are sold out :P
[05:29] <ccheney> how do you determine they are sold out?
[05:29] <slangasek> by trying to buy it, and getting an error message
[05:39] <kirkland> cjwatson: any chance you're around yet?
[06:07]  * liw notices that the gnome audio volume control widget's mute doesn't actually mute headphones
[06:09] <pitti> Godo morning
[06:09] <pitti> superm1: did you just do it?
[06:10] <superm1> pitti, no as it turns out it wasn't just a single commit that needed backporting
[06:10] <superm1> pitti, so once i realized it would be multiple i opted to just wait until after a3 when we can merge the new snapshot from debian
[06:13] <spotter> btw, whats up with the google plugin in firefox 3.5?
[06:13] <spotter> the search/sherlock plugin
[06:14] <spotter> it takes me to a google custom search page that is horrible
[06:14] <pitti> meh, no firefox for me this morning?
[06:14] <pitti> Starting program: /usr/lib/firefox-3.0.12/firefox
[06:14] <pitti> [Thread debugging using libthread_db enabled]
[06:14] <pitti> Program exited with code 01.
[06:14] <pitti> asac: ^ any idea?
[06:14] <pitti> it still worked last night
[06:16] <pitti> asac: ah, nevermind, it's a kirkland bug
[06:16] <kirkland> pitti: howdy
[06:16] <pitti> kirkland: since yesterday's karmic, my ~/Private isn't automounted on login any more; did anything change in ecryptfs recently?
[06:16] <pitti> kirkland: good morning
[06:16] <kirkland> pitti: yes, and i uploaded a fix for that about 5 minutes ago
[06:17] <pitti> kirkland: retroactive fixing, splendid!
[06:17] <kirkland> pitti: upgrade to 77-0ubuntu1 and you should be fixed again
[06:17] <kirkland> pitti: in the mean time, run ecryptfs-mount-private by hand
[06:17] <pitti> right, that's what I was doing
[06:17] <pitti> I just don't immediately realize it
[06:17] <pitti> and thus ssh hangs, firefox doesn't start, etc.
[06:17] <pitti> kirkland: thanks!
[06:17] <kirkland> pitti: you bet, thanks for your alpha-patience :-)
[06:31] <billybigrigger> is there a known issue with lost sound today?
[06:37] <pitti> superm1: are you in ~ubuntu-installer?
[06:37] <pitti> I just uploaded ubiquity, and then noticed that I cannot push the branch
[06:38] <slangasek> ubiquity needed Yet Another Upload?
[06:38] <superm1> pitti, yeah i am
[06:38] <superm1> point me at a branch and i'll mege it
[06:38] <superm1> merge even
[06:39] <pitti> pushing right now
[06:41] <slangasek> oh, perhaps I failed to upload after building it here, sigh
[06:41] <slangasek> pitti: sorry
[06:41] <slangasek> I think I got sidetracked in the middle, trying to figure out why gnome-keyring-daemon wasn't acting as a gpg agent
[06:43] <pitti> slangasek: no prob, uploaded now
[06:44] <pitti> I think it's the first time I uploaded ubiquity
[06:44] <pitti> slangasek: it's not supposed to, that's seahorse
[06:44] <pitti> slangasek: but gpg was fixed with last Friday's gdm, I think, it still fails for you?
[06:44] <pitti> hm, what's the point of "Using default stacking branch" if bzr push uploads the entire 46 MB again?
[06:45] <slangasek> pitti: I may not have upgraded gdm prior to my unplanned reboot
[06:45] <superm1> i heard seahorse was split up and you needed seahorse-plugins installed to get gpg-foo too
[06:45] <slangasek> I have seahorse-plugins
[06:45] <slangasek> anyway, it's probably the bug pitti says
[06:46] <pitti> slangasek: with yesterday's gdm upload, both ssh and gpg should work again
[06:46] <pitti> if not, please let me know
[06:47] <slangasek> ok
[06:51] <pitti> superm1: can you please bzr pull lp:~pitti/ubiquity/fix-402707 ?
[06:51] <pitti> superm1: (pull -> cleaner history than merge)
[06:53] <superm1> pitti, okay done
[06:53] <pitti> superm1: thanks!
[06:53] <superm1> no prob. good call on the pull rather than merge, makes sense
[07:02] <StevenK> pitti: Am I okay to upload ekiga, or shall I wait? It's only on the DVD, and it allows me to pull out about 8 NBS packages
[07:02] <pitti> StevenK: go ahead
[07:11] <johnny_> hi, nvidia quadro 160m is supporte in jaunty?
[07:11] <johnny_> supported
[07:27] <pitti> hah; apport's test suite fails now
[07:27] <pitti> AssertionError: 'eglibc' != 'glibc'
[07:28] <pitti> yay me for assuming too much :)
[08:57] <asac> pitti: ok ;)
[09:14] <dfaure> since ugprading to jaunty breaks every machine with fglrx (due to xorg-1.6), why did you upgrade to xorg-1.6? Or, why not provide 1.5 for the poor souls with an ATI card?
[09:15] <seb128> dfaure, try #ubuntu-x maybe but I expect the choices are not made based on closed source driver users
[09:15] <seb128> dfaure, especially if they consider the ati opensource driver to be good enough for most users nowadays
[09:15] <dfaure> it is? when I tried it on the other machine nothing worked. But let me try again, then.
[09:16] <dfaure> I don't really care if it's open source or closed source, but I'd like something else than red dots on my display ;)
[09:16] <seb128> well you might have no luck and have a card not working fine with ati
[09:16] <seb128> but it's not an issue for any ati user
[09:17] <hyperair> are packages supposed to install scripts into /etc/pm/sleep.d? isn't the right place /usr/share/pm-utils/sleep.d?
[09:18] <dfaure> seb128: at least the jaunty upgrade should have made xorg use ati, then. It's the job of the distro to make upgrades painless....
[09:18] <seb128> dfaure, well I don't know about specifics but I though they got a working fglrx version before jaunty
[09:18] <dfaure> ?
[09:18] <seb128> dfaure, do you use the fglrx ubuntu package or an upstream version you got somewhere?
[09:19] <dfaure> ubuntu package
[09:19] <seb128> dunno then, ask in #ubuntu-x they will know better
[09:20] <directhex> seb128, ATI dropped support for most of their hardware
[09:20] <seb128> directhex, well that's not an xserver 1.6 issue then but a fglrx ati one
[09:20] <directhex> seb128, so even though a driver with support for modern xorg was released, it only supports current & last gen (and maybe the one before too)
[09:20] <dfaure> seb128: well it's related, since the older fglrx for xorg-1.5 obviously still works
[09:20] <directhex> seb128, well, the point is the previous driver can't be included in parallel due to xserver 1.6. i assume
[09:21] <seb128> dfaure, I expect the issue there is that we can't make package depends be dynamic according to the hardware
[09:21] <seb128> dfaure, but agreed that's an issue, xorg should at least try to fallback on ati in such cases
[09:22] <dfaure> yes
[09:22] <Ng> dfaure: didn't the upgrade tell you that your graphics driver didn't exist in jaunty? update-managet warned my sister on her dell laptop with ATi that she'd have a worse experience
[09:22] <seb128> the issue is as often in opensource lack of manpower to get everything changed
[09:22] <dfaure> Ng: ok, I used apt-get dist-upgrade, no warnings.
[09:23] <Ng> dfaure: don't do that ;)
[09:23] <directhex> dfaure, if you're going to stand outside the safety barrier (update-manager), then that happens
[09:23] <dfaure> ok, point taken there.
[09:23] <Ng> dfaure: do-release-upgrade works for shell upgrades if you don't want to use the graphical tool (although I haven't checked if it displays such warnings)
[09:24]  * dfaure wishes the debian package stuff didn't have so many layers on top of each other, but that's another discussion
[09:24] <seb128> dfaure, ubuntu doesn't real has, users should use update-manager in a consistent way
[09:24] <seb128> real -> really
[09:24] <dfaure> X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
[09:24] <mvo_> Ng: do-release-upgrade will perform the same kind of checks as update-manager (including the warning about fglrx)
[09:25] <Ng> mvo_: I figured it might, ta :)
[09:25] <mvo_> :)
[09:26] <dfaure> any idea about the undef symbol? X won't start...
[09:26] <mvo_> dfaure: is fglrx still installed? IIRC it diverts libdri so that might be the problem
[09:26] <ogra> looks like the lib is incompatible with something (the server ?)
[09:27] <dfaure> mvo_: thanks, works now
[09:28] <mvo_> np
[09:29] <dfaure> well, sort of. X starts, kde starts, but no mouse and no keyboard...
[09:30] <dfaure> sigh
[09:48] <pitti> cking: do you still have the oem install from bug 402918 to collect logs and files?
[09:48] <pitti> (just followed up)
[09:49] <cking> pitti, nope, but I can re-install and let you know within the hour
[09:49] <pitti> cking: thanks
[09:52] <cking> installing again... :-)
[09:57] <pitti> cking: btw, I'm currently building new desktop images, which have a new ubiquity; I see some oem related fixes in the changelog
[09:57]  * pitti crosses fingers
[10:00] <gaspa> any archive-admin around that could please take a look at bug #402710 ?
[10:06] <pitti> gaspa: added sponsor ack and followup
[10:08] <gaspa> pitti: thanks ;) I wasn't sure about the right procedure.
[10:13] <directhex> presumably contributions to launchpad require copyright assignment?
[10:14] <pitti> yes
[10:18] <directhex> and it's pretty explicit on the dev wiki's page on submitting a patch that the assignment paperwork needs to be done. okay, just checking
[10:24] <pitti> for small patches as well?
[10:24] <pitti> for my own projects I just chase this if someone adds completely new files with a (C) line for himself
[10:24] <pitti> I'm not worried about patches which don't add a copyright line
[10:24] <pitti> but that's for my own projects, LP's policy might be different
[10:30] <nikolam> Hi. Anyone knows why packages is not working so often
[10:30] <liw> nikolam, people make mistakes
[10:30] <nikolam> liw, :)
[10:31] <nikolam> Nevermind, Just to see it online again
[10:31] <nikolam> I ment packages.ubuntu.com Btw
[10:36] <liw> nikolam, ah, then I have no idea
[10:39] <Omahn> nikolam: Seems to have been offline for a while now.
[10:40] <nikolam> Omahn, `for a while` is less then 1 day
[10:40] <nikolam> it worked yesterday
[10:40] <nikolam> and not working the day before
[10:40] <Omahn> True
[10:41] <cking> pitti, log files attached to bug report.
[10:42] <pitti> cking: splendid, thanks
[10:42] <cking> shall I keep this OEM version installed for a while if you need anything else?
[10:50] <pitti> cking: no, the logs should do fine; also, we have new CDs with a new ubiquity now
[10:50] <cking> shall I stop further ISO testing then and wait for the new ISOs?
[10:50] <pitti> cking: they are already there
[10:51] <pitti> cking: and on the tracker
[10:51] <cking> doh
[10:51] <pitti> I'm done with wrestling with xubuntu CDs, looking at bug now
[10:52] <pitti> cking: hang on
[10:52] <pitti> cking: can you please attach /etc/gdm/custom.conf ?
[10:52] <cking> OK.. gimme 5
[10:53] <pitti> gdm-simple-greeter[2852]: DEBUG(+): GdmGreeterClient: Received TimedLoginRequested (ubuntu 0)
[10:54] <pitti> gdm-simple-greeter[2852]: DEBUG(+): GdmGreeterLoginWindow: requested automatic login for user 'ubuntu' in 0 seconds
[10:54] <pitti> so it tries to auto-login as "ubuntu", which doesn't exist
[10:54]  * pitti follows up in bug report
[10:55] <cking> pitti, yep, log attached, indeed, logging in as ubuntu
[10:55] <pitti> cking: thanks; you can kill the install now
[10:55] <cking> cool
[10:56] <pitti> cking: I'm pretty sure it's already fixed on the current isos
[10:56] <cking> I'll find out in 20 mins
[11:48] <glatzor> hello mvo_, do you know why in softwareproperties.AptAuth gpg is used instead of apt-key?
[11:53] <mvo_> glatzor: probably a oversight, let me have a look
[11:53] <mvo_> glatzor: good to see you btw :)
[12:38] <doko> mbiebl: which criteria did you use for syncing/merging the zopepackages? which ones and which ones not?
[12:39] <mbiebl> doko: wrong person ;-)
[12:40] <doko> ahh, same initials ...
[12:40] <doko> geser: ^^^
[12:43] <pitti> mdz: so, we found out why the apport retracers produce useless results; some fakechroot regression in karmic
[12:43] <geser> doko: I'm trying to get a complete turbogears2 stack synced to karmic. So I just look at the packages needed for it (depends and recommends)
[12:43] <pitti> mdz: I applied a workaround now
[12:43] <pitti> and we'll re-tag recent crash reports
[12:43] <mdz> pitti, oh, great, thanks
[12:43] <mdz> pitti, is there a bug filed for the regression?
[12:43] <pitti> mdz: not yet, I haven't really pinpointed it yet
[12:44] <pitti> mdz: "file /usr/bin/gnome-volume-control" -> no such file
[12:44] <pitti> cd /; gdb ... ; file usr/bin/gnome-volume-control" -> works
[12:44] <pitti> but only in gdb
[12:44] <doko> geser: yes, and breaking zope3 ... anyway, will now try to do the complete zope3 split. although it's not yet completely in unstable :-/
[12:44] <mdz> pitti, very weird
[12:45] <seb128> "works"
[12:45] <geser> doko: oh, sorry, missed it
[12:45] <seb128> but next it fails to load the debug file
[12:45] <pitti> mdz: I strace'd it, and for e. g. open('/usr/bin/gnome-mount') it works, and for open('/usr/bin/gnome-volume-control') it fails
[12:45] <pitti> very ominous
[12:45] <pitti> seb128: oh, that too?
[12:45] <pitti> meh
[12:45] <pitti> seb128: if so, let's shut down them again
[12:45] <seb128> pitti, I was not speaking about your workaround sorry for the confusion
[12:46] <pitti> ah
[12:46] <seb128> rather about the " /usr/bin/../lib/debug//usr/bin/gnome-volume-control: No such file or directory." this morning
[12:46] <geser> doko: zope3 is main, and the zope.* package are in universe. How did they manage to break zope3?
[12:48] <doko> geser: they'll replace zope3, and currently are incomplete to replace it
[12:52] <cjwatson> eek, sudo is segfaulting here
[12:53] <ogra> use root :P
[12:53] <mdz> cjwatson, in a normal environment?
[12:53] <cjwatson> yes
[12:53] <cjwatson> Jul 22 12:08:55 sarantium kernel: [ 6924.741810] <6>sudo[16106]: segfault at 48 ip 001616a6 sp bfc0d288 error 4 in libc-2.9.so[110000+15a000]
[12:53] <mdz> I had a run of segfaults and panics and suchlike when I first updated my laptop to 2.6.31, but they went away after updates
[12:53] <mdz> cjwatson, reproducible?
[12:53] <cjwatson> I just upgraded, which included a libc6 upgrade
[12:53] <cjwatson> yes, every time
[12:53] <ogra> ouch
[12:54] <cjwatson> no crash report and I'd probably need root to get at it anyway :)
[12:54] <doko> running current karmic, not seeing sudo segfaults
[12:54] <pitti> here as well (amd64)
[12:55] <pitti> so hopefully not an alpha-3 release breaker?
[12:55] <ogra> same here (i386)
[12:55] <doko> I'm on i386
[12:55] <liw> . o O (easy rollbacks with dead-man's-handles would be really cool)
[12:55] <pitti> cking: *phew*, thanks for testing again
[12:56] <cjwatson> sorry, I tell a lie, no libc6 upgrade involved
[12:56] <cjwatson> I was confused by the trigproc stuff in dpkg.log
[12:56] <cjwatson> http://people.ubuntu.com/~cjwatson/tmp/dpkg.log
[12:57] <ogra> apparmor ?
[12:58] <pitti> sudo strace sudo ... erm, fail
[12:58] <cjwatson> apparmor was installed in this upgrade, yes
[12:58] <cjwatson> but I don't know why that would cause a segfault
[12:59] <cjwatson> libpam-ck-connector maybe?
[12:59] <pitti> hang on
[12:59] <pitti> $ sudo true
[12:59] <pitti> works
[12:59] <pitti> $ sudo aa-status
[12:59] <pitti> Segmentation fault
[12:59] <pitti> $ sudo true
[12:59] <pitti> Segmentation fault
[12:59] <pitti> WTF?
[13:00] <pitti> nothing in dmesg, though, except the crash itself
[13:01] <pitti> sudo -K
[13:01] <pitti> still works
[13:02] <james_w> libpam-ck-connector shouldn't have broken
[13:02] <james_w> there were no code changes
[13:02] <james_w> ah
[13:02] <james_w> there were two uploads yesterday :-)
[13:03] <james_w> nothing jumps out from the changelog though
[13:03] <pitti> it happened after just this dist-upgrade
[13:03] <pitti> upstart and ecryptfs are the two likely candidates
[13:03] <pitti> and ecryptfs is PAMish, too
[13:04] <pitti> the rest was gstreamer, ekiga, and a gdm postinst fix, none of which even come near sudo
[13:04] <cking>  pitti, the system now gives me a blank screen at step uoi-003 in the test case: http://testcases.qa.ubuntu.com/Install/DesktopOem
[13:05] <doko> libgcc1 was updated as well
[13:05] <pitti> not in my run 5 minutes ago
[13:05] <pitti> and before that I was working with sudo all the time
[13:05] <pitti> I'll downgrade ecryptfs after lunch, when I can reboot the box into rescue mode
[13:06] <pitti> arghl
[13:06] <pitti> I can't even log in any more
[13:06] <pitti> [25302.085252] <6>login[31054]: segfault at 88 ip 00007f92286fec11 sp 00007fff23fa6e40 error 4 in libc-2.9.so[7f92286a6000+166000]
[13:06] <pitti> [25231.246453] <6>mount.ecryptfs_[31021]: segfault at 88 ip 00007f59a3bbcc11 sp 00007ffff66b0a70 error 4 in libc-2.9.so[7f59a3b64000+166000]
[13:07] <pitti> I'm up for a bet that it's today's ecryptfs upload
[13:08] <seb128> should we get the deb blocked from download?
[13:08] <james_w> plenty of PAM stuff in the changelog
[13:08] <james_w> lpsp
[13:09] <pitti> I'll reboot into rescue mode, downgrade, and check
[13:09] <seb128> mdz, pitti: should we get the deb blocked from download?
[13:09] <pitti> yes, after confirming that it's ecryptfs
[13:09] <seb128> ok
[13:09] <seb128> need some help?
[13:09] <seb128> I didn't upgrade yet, I can upgrade just it and try sudo or something
[13:10] <mdz> I don't have any *ecryptfs* installed
[13:12] <ogra> mdz, well, do you currently see segfaults ?
[13:12] <mdz> ogra, no, I have no troubles right now
[13:12] <mdz> with my Ubuntu system anyway
[13:12] <mdz> I just installed the latest updates, which included:   gdm groff-base offlineimap pbuilder upstart
[13:12] <ogra> same here
[13:14] <mdz> I have libpam-ck-connector 0.3.0-2ubuntu7
[13:15] <apw> apparmor should be disabled, so i'd not expect it to be that
[13:15] <james_w> free(f);
[13:15] <james_w> asprintf(&f,
[13:15] <james_w> is that legal?
[13:15] <apw> doesn't look like the best plan to me
[13:16] <apw> hrm, actually i don't know what asprintf does ... so ignore me
[13:16] <apw> oh they allocate, so that does seem appropriate
[13:17] <mdz> cjwatson, are you using ecryptfs as well?
[13:21] <pitti> confirmed
[13:22] <pitti> I downgraded ecryptfs-utils, and it works again
[13:23] <pitti> elmo: can you please chmod 0 ecryptfs-utils_77-0ubuntu1_*.deb on the mirrors?
[13:24] <pitti> Ng: ^ or you?
[13:26]  * pitti apports _bin_login.0.crash
[13:28] <pitti> cjwatson: bug 403011 FYI
[13:28] <pitti> kirkland: ^ halp
[13:30] <dupondje> pitti: private bug ? :)
[13:31] <seb128> dupondje, bugs are private until being retraced
[13:31] <pitti> hang on
[13:32] <pitti> public now, and attached local stack trace
[13:33] <james_w> I see it I think
[13:33] <pitti> meh, and of course this crept into the xubuntu builds
[13:33] <pitti> which _just_ finally built, after oh-so many attempts :/
[13:33] <pitti> I really need to grab some food, I'm falling off my chair
[13:34] <pitti> can someone please followup with IS to disable the package?
[13:34] <ogra> but you wont get fat :=
[13:34] <ogra> :)
[13:34] <pitti> flockfile(NULL) really seems unhappy
[13:35] <seb128> pitti, ok
[13:36] <seb128> pitti, enjoy your lunch
[13:36] <pitti> asked #is
[13:36] <james_w> http://paste.ubuntu.com/224351/
[13:36] <pitti> seb128: thanks
[13:36] <pitti> james_w: that makes a lot of sense
[13:37] <james_w> look good to upload?
[13:37] <pitti> james_w: you already tested it, etc.?
[13:37] <pitti> if so, please go ahead
[13:38] <james_w> still building
[13:38] <james_w> what's the test case
[13:38] <james_w> install and run sudo?
[13:38] <pitti> james_w: install it, and try to login and sudo
[13:38] <pitti> if that fixes it, don't hesitate
[13:38] <pitti> it can't get _any_ worse
[13:39]  * james_w opens a root terminal
[13:39]  * pitti hands seb128 the baton for looking in #is and coordinating, in case followup questions turn up
[13:39] <pitti> james_w: you better do :)
[13:39] <seb128> pitti, ok, no worry
[13:41] <pitti> seems I need to wait for another 15 minutes
[13:41] <pitti> so I'll spend the time to weed out the alpha-3 images where the new ecryptfs slipped in
[13:42] <james_w> I can't make the problematic package segfault
[13:43]  * mvo_ hugs james_w
[13:43] <pitti> james_w: you can't reproduce the original crash, you mean?
[13:43] <james_w> yeah
[13:43] <pitti> let me try your patch then
[13:43] <james_w> don't want to test the fix until I have a broken system
[13:43] <james_w> do I need to restart all my sessions?
[13:44] <pitti> james_w: no, it just happens
[13:44] <pitti> install new ecryptfs-utils, and suddenly login and sudo go boom
[13:44] <pitti> I actually use ecryptfs, though
[13:45] <pitti> james_w: building your fixed package now
[13:47] <james_w> ah
[13:47] <james_w> you need libecryptfs0 as well
[13:47] <james_w> otherwise you get a symbol lookup error
[13:47] <pitti> james_w: confirmed, that fixed the problem
[13:47] <james_w> presumably the dependencies need to be tightened
[13:47] <james_w> kirkland: ^
[13:48] <james_w> pitti: shall I upload?
[13:48] <pitti> james_w: can you upload this, or shall I?
[13:48] <pitti> please do
[13:48] <pitti> I'll bump build score
[13:48] <james_w> 403 on the broken package to test now :-)
[13:48] <pitti> I hope we can make the :03 publisher run
[13:48] <james_w> uploaded
[13:50] <pitti> building everywhere
[13:50] <pitti> ok, finally food
[13:50] <pitti> bbl
[13:50] <pitti> james_w: thanks!
[13:51] <james_w> thanks Pici
[13:51] <james_w> and pitti :-)
[13:51] <Pici> :)
[13:55]  * ogra wonders why makedev got so slow 
[13:56] <ogra> (the package stalls debootstrap for quite a while)
[13:56] <james_w> all ACCEPTED except for armel, which should make it
[13:56] <james_w> and there it is
[13:57] <james_w> pitti: should be in the next publisher run for you
[13:57]  * james_w -> food as well
[13:57] <cjwatson> mdz: ecryptfs> yes
[13:57] <cjwatson> I wonder if I can move .ecryptfs aside or something to get sudo back ...
[13:58] <cjwatson> aha! yes
[13:58] <cjwatson> thanks guys :)
[13:59] <james_w> cjwatson: is that just "mv /home/username/.ecryptfs /home/username/.ecryptfs.save" ?
[14:00] <mdz> james_w, sorry, I may have just clobbered your wiki edit.  I clicked save before I noticed, and I canceled, but I think it was too late
[14:00] <cjwatson> james_w: yeah
[14:01] <james_w> mdz: np
[14:02] <ogra> meh
[14:02] <ogra> could someone promote udhcpc to main ?
[14:02] <ogra> it has an approved MIR and stgraber made ltsp-client-core depend on it
[14:03] <ogra> which means ltsp installs currently break due to udhcpc missing on the CD
[14:04] <ogra> (the MIR is bug 383177)
[14:06] <james_w> should we have instructions for escaping the problem posted somewhere?
[14:10] <cjwatson> james_w: ubuntu-devel-announce maybe?
[14:28] <Unggnu> hi all
[14:28] <Unggnu> Is there a reason why firefox-3.0 comes without all the gnome dependencies but firefox-3.5 not?
[14:29] <Unggnu> So it is possible without the whole mess to use Firefox 3.0 with KDE but not with 3.5 while it works fine if I download and install it locally without any further dependencies.
[14:56] <taavikko> question about *buntu-restricted-extras, why it is needed to have xubuntu and ubuntu in separate metapackages, since their content is roughly the same. This can create confusion?
[14:57] <taavikko> for KDE I understand the need for it's own, but the other two are making me wonder..
[14:57]  * ScottK would find ubuntu-restricted-extras for Xubuntu confusing.
[14:58] <taavikko> I thought about the naming convention, since it would be easier to understand what package to install, vbased on what enviroment is running
[15:02] <kirkland> pitti: i'm here now
[15:02] <pitti> hey kirkland
[15:02] <pitti> kirkland: you missed all the action :)
[15:02] <kirkland> pitti: should i read the backlog?
[15:02] <kirkland> pitti: yeah, sorry :-)
[15:02] <pitti> but I guess james_w didn't spend much time on forwarding bug/patch upstream, etc.
[15:03] <james_w> oops, forgot about that
[15:03] <pitti> james_w: no worries; you rocked!
[15:03] <pitti> kirkland: so could you please take a look at the bug, perhaps clean up the fix, and sort out the upstream comimt, etc.?
[15:04] <pitti> it was pretty much a shot from the hip to unbreak karmic
[15:04] <kirkland> pitti: sure thing
[15:07] <kirkland> pitti: james_w: whoa boy
[15:07] <pitti> cjwatson found a much better workaround, I actually dived into init=/bin/bash, etc. :)
[15:07] <kirkland> james_w: good find
[15:08] <james_w> twas an easy spot once pitti had the stacktrace
[15:08] <kirkland> pitti: what was cjwatson's workaround?
[15:08] <pitti> temporarily move aside ~/.ecryptfs
[15:08] <kirkland> james_w: yeah, i did make that change late yesterday :-/
[15:08]  * pitti rebuilds alpha 3 images which had the broken version, since we offer it in the installer
[15:08] <kirkland> pitti: sorry man
[15:08] <pitti> kirkland: no problem
[15:09] <kirkland> james_w: i'll commit this upstream now
[15:09] <james_w> thanks
[15:09] <james_w> kirkland: did you also see my comment on the dependencies?
[15:09] <kirkland> pitti: what was the "better" workaround that cjwatson had?
[15:09] <kirkland> james_w: hmm, no, what's that?
[15:09] <pitti> temporarily move aside ~/.ecryptfs
[15:10] <pitti> kirkland: e-utils doesn't depend on libecryptfs0
[15:10] <james_w> I was able to install the new ecryptfs-utils without the new libecryptfs0
[15:10] <pitti> kirkland: missing dh_shlibdeps, or missing ${shlibs:Depends}?
[15:11] <james_w> which broke umount-private, because it couldn't find ecryptfs_find_private_mount or whatever that symbol is called
[15:11] <james_w> perhaps just a missing/outdated -V ?
[15:12] <kirkland> pitti: oh, hmm, yeah, ecryptfs-utils should depend on libecryptfs0
[15:12] <pitti> kirkland: usually that should just happen automatically
[15:13] <kirkland> pitti: both Depend on ${shlibs:Depends}
[15:13] <pitti> weird
[15:14] <kirkland> pitti: james_w: ecryptfs-utils was missing libecryptfs0
[15:14] <james_w> Package: ecryptfs-utils
[15:14] <james_w> Depends: ..., libecryptfs0 (>= 48)
[15:14] <james_w> Version: 77-0ubuntu1
[15:14] <james_w> are you seeing something else?
[15:15] <pitti> oh, right
[15:15] <kirkland> james_w: oh, i was looking at the source debian/control
[15:15] <kirkland> Depends: ${shlibs:Depends}, ${misc:Depends}, keyutils, libnss3-1d, libpam-runtime (>= 1.0.1-6), libecryptfs0
[15:15] <pitti> sorry, I misread
[15:15] <kirkland> (i just added libecryptfs0)
[15:15] <pitti> dependency is here as well
[15:15] <pitti> kirkland: no, please don't
[15:15] <james_w> probably want a "dh_makeshlibs -V77-0ubuntu1"
[15:15] <kirkland> pitti: okay
[15:15] <pitti> kirkland: it should be picked up by dh_shlibdeps
[15:16] <pitti> (and is)
[15:16] <pitti> kirkland: I was just confused, sorry
[15:16] <james_w> as symbols were added in that version?
[15:16] <pitti> james_w ++
[15:16] <kirkland> ah, it's coming together now!
[15:16] <james_w> score!
[15:16] <kirkland> i added a couple of symbols to libecryptfs0 in this last upload
[15:17] <kirkland> the build in the archive is building against (potentially) an older one in the chroot?
[15:17] <james_w> kirkland: if it's in the same source then that shouldn't happen
[15:18] <pitti> kirkland: no, it just says it's possible to have a newer version of ecryptfs-utils installed with an older version of libecryptfs0
[15:18] <james_w> the build will write out a shilbs file from dh_makeshlibs
[15:18] <pitti> which must not happen, due to the new symbols (which might be used by ecryptfs-utils)
[15:18] <james_w> then for dh_shlibsdeps for ecryptfs-utils will find the symbol, look it up and add the dependency
[15:18] <james_w> however, it's picked an old version
[15:19] <pitti> well, it doesn't really "pick"
[15:19] <pitti> it reads libecryptfs0's .shlibs
[15:19] <james_w> so you need to tell it that there are new symbols in the new version, and that anything built against this new version should use this version as a minimum
[15:19] <james_w> or you could add a symbols file so that the dependency is only bumped if it actually uses a new symbol
[15:20] <james_w> pitti: dh_makeshlibs is currently called without a version, why is it (>= 48) that is used?
[15:20] <pitti> $ cat /var/lib/dpkg/info/libecryptfs0.shlibs
[15:20] <pitti> libecryptfs 0 libecryptfs0 (>= 48)
[15:20] <pitti> apparently some older package did specify a version
[15:21] <pitti> $ cat debian/libecryptfs0.shlibs
[15:21] <pitti> libecryptfs 0 libecryptfs0 (>= 48)
[15:21] <pitti> ^ there
[15:21] <kirkland> yeah
[15:21] <pitti> please bump
[15:21] <james_w> kirkland: the syntax I gave you was wrong
[15:22] <kirkland> james_w: okay, so now i don't need the dh_makeshlibs
[15:22] <james_w> why not?
[15:22] <kirkland> i just need to adjust debian/libecryptfs0.shlibs
[15:22] <kirkland> right?
[15:22] <kirkland> sorry
[15:22] <kirkland> i need dh_makeshlibs
[15:22] <kirkland> i don't need the explicit -V
[15:22] <james_w> man dh_makeshlibs
[15:22] <kirkland> since the debian/libecryptfs0.shlibs file specifies it
[15:22] <james_w> ah
[15:23] <james_w> I don't think that's a normal way to do it though is it?
[15:23] <kirkland> james_w: pitti: i don't know;  this is all new magic to me
[15:24] <pitti> well, both are valid really
[15:24] <kirkland> pitti: james_w: seems to me bumping in that file is the nicest way to go
[15:25] <pitti> the most modern form is to use dpkg-gensymbols (man deb-symbols)
[15:25] <james_w> if it works
[15:25] <pitti> but out of that, using explicit .shlibs files or using -V amounts to the same
[15:25] <pitti> it's a matter of preference AFAICS
[15:25] <james_w> kirkland: so, the rule is, symbols removed of changed -> soname bump -> package name changed -> NBS dance
[15:26] <james_w> symbols added -> shlibs bump
[15:26] <james_w> or a symbols file, but that's a bit more work
[15:26] <james_w> and won't make too much of a difference if there are only a couple of packages depending on the lib
[15:27] <kirkland> gotcha
[15:28] <james_w> symbols files do help you catch missed soname changes though
[15:29] <kirkland> james_w: pitti: http://pastebin.ubuntu.com/224392/
[15:29] <kirkland> james_w: pitti: that's what i have so far
[15:30] <pitti> kirkland: looks good
[15:30] <james_w> I think that's right
[15:30] <james_w> though I didn't change shlibs :-)
[15:30]  * pitti walks over to wife's computer to try live system, bbl
[15:32] <kirkland> pitti: james_w: should I push another upload with the shlibs change?
[15:33] <james_w> might as well, as long as pitti is fine with the timing for alpha
[15:35] <kirkland> james_w: i'll await pitti on that one ...
[15:37] <ogra> pitti, i assume you didnt process my former request of moving udhcpc to main between the two alternate rebuilds, right ?
[15:37] <ogra> (so i dont need to test the ltsp install again)
[15:39] <pitti> ogra: no, didn't see that? why would it affect CDs?
[15:39] <ogra> ltsp-client-core depends on it
[15:40] <pitti> ogra: out of interest, why doesn't it use dhcp3-client?
[15:40] <ogra> stgraber assumed the fix committed status on bug 383177 would mean it was moved
[15:40] <pitti> no, that would be 'released'
[15:40] <ogra> pitti, to big i guess, not my decision
[15:41] <ogra> pitti, *i* know :)
[15:41] <ogra> he didnt
[15:41] <kirkland> pitti: did you want me wait, or push an upload now with that shlibs change?
[15:41] <pitti> kirkland: seems harmless now, so go ahead
[15:41] <kirkland> pitti: okay, thanks.
[15:42] <ogra> pitti, they install udhcpc in the initramfs, i think dhclient was to clunky for what they tried to achieve
[15:42] <ogra> (essentially trying to compensate for the many missing features if klibc/ipconfig)
[15:43] <ogra> s/if/of/
[16:20] <LaserJock> is FUSA not installed by default in karmic?
[16:20] <ogra> currently not ... only the one that comes with gdm
[16:20] <ogra> waiting for an update from the DX team afaik
[16:22] <seb128> LaserJock, it is but it's part of gdm now
[16:22] <seb128> LaserJock, the ubuntu changes are being ported by ted too
[16:23] <LaserJock> seb128, ogra: ah, ok, thanks
[16:23] <cjwatson> james_w: confirmed that your fix works with .ecryptfs moved back into place - thanks!
[16:23] <james_w> thanks cjwatson
[16:24] <ogra> seb128, did you btw ever try to logout from a jaunty system that has no mouse and no powerbutton ? :)
[16:24]  * ogra just found out thats impossible since you cant reach FUSA with the keybopard at all
[16:25] <seb128> ogra, there is a bug open about that since before jaunty
[16:26] <ogra> ah, i didnt know
[16:26] <ogra> just found it funny
[16:36] <hdon> question for ubuntu hackers: i want to report a bug that has to do with editing source code, and i want to provide comprehensive list of instructions to reproduce the problem. if an ubuntu hacker could recommend a good source code package for a medium-large software project (firefox would work, since i already have that code downloaded) to download as part of those instructions, i would be much obliged
[16:36] <hdon> also, it's worth noting that this happened to me:
[16:36] <hdon> * #ubuntu-hackers #ubuntu :Forwarding to another channel
[16:37] <hdon> should probably be forwarded to #ubuntu-devel?
[16:48] <hdon> whatever, i'll just use firefox
[17:17] <seb128> mathiaz, hey
[17:17] <mathiaz> seb128: hey
[17:17] <seb128> mathiaz, who is looking after samba4 in ubuntu?
[17:17] <mathiaz> seb128: hm - jelmer?
[17:17] <mathiaz> seb128: kind of.
[17:17] <mathiaz> seb128: why?
[17:17] <seb128> mathiaz, dunno, I'm the one who asked ;-)
[17:18] <seb128> mathiaz, openchange build breaks on   samba4-dev: Depends: libldb-samba4-dev but it is not going to be installed
[17:18] <seb128> mathiaz, I was wondering if that's a known issue and if somebody is going to sort that
[17:20] <mathiaz> seb128: it should be sorted out once we merge samba4 from debian experimental
[17:21] <seb128> mathiaz, is anybody in the server team going to make sure that happens before karmic?
[17:21] <mathiaz> seb128: I'll have a look at it
[17:21] <seb128> mathiaz, thanks!
[17:27] <jelmer> seb128:, mathiaz: libldb-samba4-dev has been removed
[17:28] <seb128> jelmer, well samba4-dev depends on it
[17:28] <jelmer> instead the upstream libldb-dev should now work
[17:28] <mathiaz> jelmer: right - however the current version in karmic is still alpha6
[17:28] <mathiaz> jelmer: alpha8 should be merged to fix the problem
[17:28] <jelmer> Ah, oops. I'll request syncs
[17:28] <mathiaz> jelmer: or may be synced
[17:29] <mathiaz> jelmer: samba4 has a 1ubuntu1 version
[17:29] <mathiaz> jelmer: I haven't looked at the changes made in ubuntu.
[17:31] <jelmer> mathiaz: Ah, hadn't seen that. I'll merge those into the Debian package for the next upload and then request a sync.
[17:43] <Viper550> Xournal...think it should be in the default install?
[17:44] <seb128> Viper550, no
[17:44] <Viper550> why not? they added Windows Journal to base installs for Viata
[17:45] <seb128> because we are out of CD space and that doesn't seem something which will benefit most users
[17:56] <Viper550> yeah, so much for not removing gimp
[17:57] <ogra> what would you do with xournal anyway without tablet or touchscreen to use it for its purpose
[17:57] <ogra> its easy enough to install it later
[18:11] <rtg_> after updating this morning, sudo stopped working (segmentation fault), and I cannot login to my account through GDM. sshd works, but still cannot sudo.
[18:11] <rtg_> I can login to another account, but its not in /etc/sudoers
[18:15] <liw> rtg_, it seems to be a problem with ecryptfs, downgrading that or temporarily renaming the .ecryptfs(or something) directory should fix things
[18:15] <liw> rtg, or, alternatively, upgrading to the newer version of ecryptfs uploaded today
[18:18] <rtg_> liw, just read the incident report. https://wiki.canonical.com/IncidentReports/2009-07-22-ecryptfs
[18:53] <davmor2> bryce: ping
[18:54] <bryce> davmor2, http://err.no/personal/blog/tech/2006-10-10-12-05_contentless_pings.html
[18:54] <davmor2> bryce: ah okay :)   You have a box with an ati card correct?
[18:56] <bryce> Yes I do.
[18:58] <davmor2> bryce: do you run/or can you install karmic on it.  If so can you see what happens on reboot after enabling fglrx
[18:58] <davmor2> I currently get a white screen where gdm should be and can't switch to console
[19:01] <bryce> davmor2, kinda busy, but it worked for me last time I tried it
[19:01] <bryce> davmor2, see http://wiki.ubuntu.com/X/Troubleshooting for directions on how to collect debug info for white screen issues
[19:05] <davmor2> bryce: thanks for the info.
[19:35] <mathiaz> james_w: hey - could you import libvirt in the package branches?
[19:36] <pitti> @all: please help out testing CD images for alpha-3, time is getting a bit tight (http://iso.qa.ubuntu.com)
[19:47] <wubbbi> is it normal that I need root previlegs to eject my cd-drive? oO using karmic up to date
[19:57] <infinity> wubbbi: It's normal if someone other than you has the filesystem mounted.
[19:59] <wubbbi> infinity: but Im the only user of this PC ... this cant be possible
[20:01] <infinity> wubbbi: I meant "someone other than your user" (like, say, root), not "someone walking into your house".
[20:01] <infinity> wubbbi: But this belongs on #ubuntu (or #ubuntu+1, if it's karmic), not in -devel.
[20:06] <james_w> mathiaz: queued
[20:06] <mathiaz> james_w: \o/ - thank ya
[20:17] <kees> Keybuk: why is /dev/net/tun 0666?
[20:20] <pitti> mathiaz, kirkland, zul: can you guys give the server alpha-3 CDs a spin?
[20:20] <pitti> (or who can I ping about that?)
[20:20] <pitti> we probably don't need a full test coverage, but the thing should at least instlal
[20:21] <mathiaz> pitti: I've started to test them. However I ran into a kernel regresion when doing kvm testing
[20:21] <mathiaz> pitti: kirkland is currently debugging it
[20:21] <pitti> ah, nice
[20:22] <mathiaz> pitti: I'm gonna have to workaround the regression in order to be able to go through an install
[20:22] <mathiaz> pitti: currently the install stops while trying to mount vda1 as an ext4 partition :/
[20:22] <pitti> weird, I was using kvm all day
[20:23] <mathiaz> pitti: are you using qcow2 files as the base for block devices?
[20:23] <mathiaz> pitti: or raw or lvm devices?
[20:23] <pitti> mathiaz: in the host or guest?
[20:23] <mathiaz> pitti: host
[20:23] <pitti> on the host I just have a 6 GB dd'ed raw file
[20:23] <mathiaz> pitti: right - so you're using a raw file
[20:23] <mathiaz> kirkland: ^^
[20:24] <mathiaz> kirkland: pitti doesn't see an issue with raw files with alpha3
[20:24] <kirkland> the work around is "don't use virtio"
[20:24] <kirkland> pitti: are you using virtio disks?
[20:24] <pitti> I never had anything else, TBH
[20:24] <pitti> kirkland: what's that?
[20:24] <pitti> kvm -m 768 -cdrom download/ubuntu/karmic-desktop-i386.iso -hda download/kvm-images/testdesktop.img -boot d
[20:24] <pitti> and that was generated with dd if=/dev/zero of=testdesktop.img bs=1M count=6000
[20:25] <pitti> I'm afraid I don't use the fancy stuff
[20:25] <kirkland> pitti: right, okay, you're not using virtio disk, and so you're not affected by the issue mathiaz raised
[20:25] <kirkland> pitti: -drive if=virtio,index=0,boot=on,file=testdesktop.img
[20:26] <kirkland> pitti: that would get you virtio disks, roughly a 10x performance improvement on disk reads/writes
[20:26] <mathiaz> kirkland: from an alpha3 perspective, does it mean that alpha3 will not work on virtio guests?
[20:26] <pitti> kirkland: wow
[20:27] <pitti> I guess it's a little late now, but since it can be fixed in an update, I don't see it as a release blocker
[20:27] <kirkland> pitti: i don't think it's a blocker
[20:27] <kirkland> pitti: the workaround is 'disable virtio in the guest'
[20:28] <pitti> kirkland: that -drive replaces -hda test.img ?
[20:28] <mathiaz> should it be added in the release notes?
[20:28] <kirkland> pitti: right
[20:28] <kirkland> mathiaz: yes, definiteyl
[20:28] <pitti> mathiaz: please go ahead; https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#Known%20issues
[20:28] <kirkland> definitely, even
[20:29] <mathiaz> pitti: could you confirm that the install breaks for desktop on virtio drives?
[20:29] <mathiaz> kirkland: or have you confirmed it ^^?
[20:29] <pitti> mathiaz: I currently have a kvm running, but I'll try with a second instance with the alternate
[20:30] <kirkland> mathiaz: i confirmed it
[20:30] <pitti> ah, /me just trashes it, it didn't get very far
[20:31] <pitti> $ kvm -m 768 -drive if=virtio,index=0,boot=on,file=download/kvm-images/testdesktop.img
[20:31] <pitti> looks right?
[20:31] <pitti> this boots the previous install
[20:31] <pitti> wow, unlike with the default -hda that puts almost no load on my box
[20:32] <pitti> awesome
[20:32] <pitti> and it's indeed much faster
[20:32] <pitti> kirkland, mathiaz: anyway, previous desktop install is booted now with above command
[20:32] <pitti> nothing in dmesg
[20:33] <kirkland> pitti: uname -a?
[20:33] <pitti> $ cat /proc/version_signature
[20:33] <pitti> Ubuntu 2.6.31-3.19-generic
[20:33] <pitti> Linux tick 2.6.31-3-generic #19-Ubuntu SMP Tue Jul 14 16:07:02 UTC 2009 x86_64 GNU/Linux
[20:33] <seb128> pitti, what kvm command is that?
[20:33] <pitti> seb128: I just learned about "virtio" kvm drives, which are apparenlty go-faster stripes
[20:34] <kirkland> pitti: when they work :-)
[20:34] <pitti> kirkland, mathiaz: anyway, a normal boot from a raw image seems to work fine
[20:34] <seb128> pitti, <- want to learn about those too, share? ;-)
[20:34] <kirkland> pitti: okay, that's good
[20:34] <kirkland> seb128: <pitti> $ kvm -m 768 -drive if=virtio,index=0,boot=on,file=download/kvm-images/testdesktop.img
[20:34] <pitti> when does that happen, when I actually do an install?
[20:34] <seb128> oh, ok
[20:34] <seb128> thanks
[20:34] <kirkland> seb128: the magic is "virtio"
[20:34] <pitti> seb128: I just got that command verbatim from mathiaz :)
[20:34] <kirkland> pitti: the partition bombed out for me
[20:34] <seb128> dd takes ages here
[20:34] <seb128> I'm happy to try something faster ;-)
[20:35] <pitti> kirkland: "the partition"?
[20:35] <pitti> seb128: oh, it's a dd'ed image
[20:35] <kirkland> seb128: oh, well there's also qcow2
[20:35] <pitti> seb128: that's using an existing image
[20:35] <seb128> ah ok
[20:35] <pitti> I always keep that around
[20:35] <kirkland> seb128: kvm-img create -f qcow2 8G
[20:35] <pitti> since I constantly do install tests anyway
[20:35] <kirkland> seb128: will create a sparse file
[20:35] <seb128> kirkland, thanks
[20:35] <kirkland> seb128: won't dd the full 8G
[20:35] <seb128> pitti, keep an empty image and cp it around?
[20:35] <pitti> seb128: no, I only do one test at a time, so having one image is enough
[20:36] <seb128> ah right
[20:37] <pitti> kirkland, mathiaz: doing a desktop install now with virtio
[20:37] <kirkland> apw: we're discussing the issue here now
[20:37] <kirkland> apw: i've narrowed the introduction to 2.6.30 vs. 2.6.31
[20:37] <kirkland> apw: 2.6.30 does not throw /dev/vda errors in the guest
[20:38] <kirkland> apw: all of the 2.6.31 kernels i've tried from http://kernel.ubuntu.com/~kernel-ppa/mainline/ does
[20:38] <pitti> kirkland: but sparse files give you worse performance during runtime, won't they?
[20:38] <pitti> kirkland: or is ext4 etc. clever enough about those?
[20:38] <kirkland> pitti: i'm not sure about ext4
[20:38] <kirkland> pitti: but you do generally pay either a space or performance penalty
[20:39] <kirkland> pitti: i have dozens of vm's around, so i need sparse files :-)
[20:39] <pitti> now, if vmmouse would work the way it did in hardy (broken since intrepid or jaunty), this thing would be perfect
[20:40] <kirkland> pitti: ah, where the mouse exits the vnc window?
[20:40] <kirkland> pitti: i should ask upstream why that regressed
[20:40] <kirkland> pitti: i think they had a reason for it :-/
[20:42] <pitti> mathiaz, kirkland: anyway, it's well past the formatting stage, and 25% into installing files
[20:43] <pitti> no errors in dmesg in either guest or host
[20:43] <kirkland> pitti: what type of image?
[20:43] <pitti> all on amd64/2.6.31-3
[20:43] <kirkland> pitti: raw?
[20:43] <pitti> yes, raw
[20:43] <mathiaz> pitti: right - that means qcow2 files are also involved
[20:43] <kirkland> pitti: okay, i'm trying that now
[20:43] <pitti> so perhaps it's just qcow + new kernel?
[20:43] <mathiaz> kirkland: I saw something similar when testing a raid installation
[20:43] <pitti> I can test with a qcow file later on, too
[20:43] <mathiaz> kirkland: I had to use raw files instead of qcow2 files
[20:44] <mathiaz> kirkland: otherwise the RAID install would fail.
[20:44] <pitti> [21:35]  kirkland| seb128: kvm-img create -f qcow2 8G
[20:44] <pitti> erm, where does the output file name go there?
[20:44] <kirkland> pitti: oops
[20:44] <kirkland> pitti: between qcow2 and 8G :-)
[20:44] <pitti> oh, just after it
[20:44] <pitti> wow, that takes like no time
[20:44] <pitti> -rw-r--r-- 1 martin martin      45056 2009-07-22 21:44 testalt.img
[20:44] <pitti> sholdn't that show 8 GB?
[20:45] <kirkland> pitti: nope
[20:45] <kirkland> pitti: that's the sparse part of it
[20:46] <pitti> I'm afraid I need to wait until the current test intall finishes
[20:47] <pitti> I can't start two VMs, my slooow disk and little RAM will go nuts
[20:48] <kirkland> pitti: so if you want your vmmouse back....
[20:49] <kirkland> pitti: add -usb -usbdevice tablet to your kvm line ;-)
[20:49] <pitti> oh, uh :)
[20:49] <pitti> I thought that was a matter of using a vm-aware mouse X.org driver in the guest
[20:49] <kirkland> pitti: evidently we switched from vmmouse to evdev
[20:50] <kirkland> pitti: fwiw, my i have a kvm alias in my bashrc that adds all sorts of fun magic :-)
[21:05] <pitti> kirkland, mathiaz: so the desktop install and booting that install completed without a hitch (that was on raw); trying qcow now
[21:06] <kirkland> pitti: confirmed, i saw the same thing with raw
[21:08] <pitti> kirkland: nice, the tablet trick works; thanks!
[21:08] <kirkland> pitti: :-)
[21:10] <pitti> kirkland, mathiaz: hah, reproduced
[21:10] <kirkland> pitti: qcow, or qcow2?
[21:10] <pitti> kvm-img create -f qcow2 testalt.img 8G
[21:11] <pitti> so is it just qcow2? or qcow2+virtio?
[21:11] <kirkland> pitti: yup, that'll do it
[21:11] <pitti> shall I try qcow2 without virtio?
[21:11] <kirkland> pitti: qcow2 + virtio
[21:11] <kirkland> pitti: you can, that should work just fine
[21:11] <kirkland> albeit slower
[21:11] <pitti> ok, I think I rather go back to raw+virtio then :)
[21:13] <superm1> pitti, ping.  i wanted to ask if devkit-disks had plans to be able to pull this kind of information that I used to get from HAL: http://paste.ubuntu.com/224865/
[21:14] <superm1> (at least in python)
[21:14] <pitti> superm1: that's all there already? (label/fstype, etc.)
[21:14] <superm1> pitti, do you know of any examples of how it's queried though in python then?
[21:15] <superm1> or is it all listed on some dbus object then?
[21:16] <pitti> superm1: it is
[21:16] <pitti> org.freedesktop.DeviceKit.Disks
[21:16] <superm1> pitti, oh silly me :)
[21:16] <pitti> superm1: the main object has an Enumerate() thing, and each partition is an object
[21:17] <pitti> and label etc. are properties of that
[21:17] <superm1> okay quite easy to switch to then.  thanks!
[21:17] <pitti> superm1: you could also just use udevadm info for the easy cases
[21:17] <pitti> udevadm info --query=all --name=/dev/sda1
[21:18] <pitti> ID_FS_LABEL=ubuntu
[21:18] <pitti> etc.
[21:18] <superm1> i was hoping to avoid using subprocess for such things, but if it proves easier that's definitely an option
[21:18] <pitti> right, if you prefer dbus, calling dk-disks is defintively what you want to do
[21:21] <pitti> kirkland: alias kvm='kvm -m 768 -usb -usbdevice tablet -drive if=virtio,index=0,boot=on,file=~/download/kvm-images/testdesktop.img'
[21:21] <pitti> kirkland: any other secret goodness which I should have there?
[21:21] <pitti> :)
[21:22] <kirkland> pitti: i use:
[21:22] <kirkland> alias kvm='kvm -m 512 -net nic,model=virtio -net user -usb -usbdevice tablet'
[21:22] <kirkland> virtio for network will speed up your network by 10x too
[21:22] <kirkland> pitti: note that soren disagrees with -net user, but I have forgotten why
[21:23] <pitti> ok, I'm not much fussed about network performance, but good to know
[21:23] <pitti> kirkland: will these eventually become the default?
[21:23] <kirkland> pitti: also, if you're ever testing server images, -curses is a lot of fun too
[21:23] <pitti> they seem like --yes-i-always-want-that options
[21:23] <kirkland> pitti: virtio requires support in the guest
[21:23] <kirkland> pitti: for us, that means guests >= hardy
[21:23] <pitti> ah
[21:23] <kirkland> pitti: but we don't know what kind of guest the user might run
[21:23] <kirkland> pitti: windows, solaris, bsd
[21:24] <pitti> makes sense; I thought it'd be some internal kvm implementation detail
[21:24] <pitti> like, more efficient access to the .img
[21:24] <kirkland> pitti: i'd like to push the -m up to 256 by default
[21:24] <kirkland> pitti: currently, it's 128
[21:24] <kirkland> pitti: the -usb -usbdevice is debatable, i'll need to understand more about why we switched from vmmouse to evdev
[21:25] <kirkland> pitti: and the virtio stuff is just too guest specific
[21:26] <kirkland> pitti: also, note that if you use something like virt-manager, it soups up your kvm line for you
[21:26] <pitti> tkamppeter: thanks so much for the udevification of s-c-p
[21:26] <kirkland> pitti: and if you're like mathiaz, you write your own xml machine descriptions by hand, and run them in virsh
[21:26] <pitti> lol
[21:26] <kirkland> pitti: alternatively, something like virt-install and vm-builder will spit out xml for you
[21:26] <pitti> I guess the alias is just fine then, I understand that they can't become defaults just yet
[21:27] <kirkland> pitti: i rarely have time to fuss too much with that stuff, and like you, just run kvm from the command line
[21:27] <pitti> my use case for VMs is pretty much "install testing" anyway
[21:27] <kirkland> pitti: righto
[21:27] <pitti> kirkland: so, thanks for passing the 1337 stuff :)
[21:27] <kirkland> pitti: give -curses a try next time you test a server img
[21:27] <kirkland> :-)
[21:27] <kirkland> pitti: though, it doesn't work with our server/alternate iso
[21:28] <pitti> kirkland: will that speed up the hideously slow text interface?
[21:28] <kirkland> pitti: runs the vm entirely in your term
[21:28] <pitti> kirkland: in d-i, I can see every single block character being painted
[21:28] <pitti> oh, nice
[21:28] <kirkland> pitti: http://www.youtube.com/watch?v=4rBF8byfyvo&eurl=http%3A%2F%2Fblog.dustinkirkland.com%2F2009%2F06%2Fkvms-inside-of-byobu.html&feature=player_embedded
[21:28] <kirkland> pitti: http://www.youtube.com/watch?v=4rBF8byfyvo
[21:28] <kirkland> pitti: that's a screencast
[21:29] <kirkland> pitti: kvm -curses inside of byobu
[21:29] <kirkland> pitti: one vm per screen window :-)
[21:30] <pitti> kirkland: I wonder why "michael jackson thriller" is at the top of "similar videos" :-P
[21:30] <kirkland> pitti: LoL :-)
[21:30] <kirkland> pitti: i'm going to take that as a compliment :-)
[21:31] <pitti> awesome
[21:31] <kirkland> pitti: grub2 kinda breaks it though
[21:31] <kirkland> pitti: the grub menu is no longer text
[21:31] <kirkland> pitti: so you can't select your kernel
[21:31] <kirkland> pitti: but after that, it's back to text
[21:31] <pgraner> pitti: help!
[21:31] <pitti> pgraner: hello?
[21:32] <pgraner> pitti: just updated and gnome-term & nautilus won't run for starters
[21:32] <pgraner> pitti: on karmic
[21:32] <pgraner> pitti: you seen this one?
[21:32] <pitti> pgraner: not so far
[21:32] <pitti> pgraner: gnome itself starts, though?
[21:32] <pgraner> pitti: sweet
[21:32] <pitti> panel, etc.?
[21:32] <pgraner> pitti: yep, I have xchat up
[21:33] <pitti> pgraner: can you switch to vt1 and check ~/.xsession-errors ?
[21:33]  * pitti invokes seb128 to listen as well
[21:33] <pitti> pgraner: does alt+f2 xterm work?
[21:33] <seb128> pitti, reading, I'm trying to figure why gvfs-ssh crashes
[21:33] <pitti> then you could start gnome-terminal from there and watch the output
[21:33] <pitti> seb128: don't worry, I'll do the triage
[21:34] <pgraner> pitti: tons of errors in the .xsession-errors  and the xterm did not start
[21:34] <seb128> can you put the .xsession-errors online?
[21:34] <pedro_> btw someone reported a similar issue a few minutes ago on bug 403186
[21:34] <pitti> paste.ubuntu.com (if firefox works) or scp it to rookery?
[21:36] <pgraner> seb128, pitti: http://pastebin.ubuntu.com/224918/
[21:38] <seb128> pgraner, lot of non standard softwares there, banshee, skype, etc
[21:38] <pitti> Key file does not have key 'Exec'
[21:38] <pitti> WTH
[21:38] <pgraner> seb128: standard stuff. I was testing banshee, and use skype for work
[21:39] <seb128> pitti, I bet they have a buggy desktop somewhere
[21:39] <seb128> pgraner, do you have the issue with a stock user?
[21:39] <pitti> pedro_: seems unrelated to pgraner's problem
[21:39] <seb128> pgraner, try moving .config/autostart away
[21:39] <seb128> seems you have buggy desktops there
[21:40] <pedro_> pitti, yep agreed
[21:40] <pgraner> seb128: I don't have one set up let me try
[21:40] <pitti> pgraner: alternatively, you could temporarily move ~/.config/autostart to ~/.config/autostart-disabled and try to log in again?
[21:40] <pitti> oops, seb128 already said
[21:40] <pgraner> seb128: I tried going to System/Admin/Users and got You are not allowed to access the system config
[21:41] <pitti> pgraner: if that helps, could you please tar the folder and put it somewhere?
[21:41] <pitti> g-session certainly could behave a  bit better with broken .desktops, the tar file would be a good reproducer
[21:42] <pgraner> pitti: logging out brb
[21:42] <pitti> hm, users-admin works for me
[21:44] <chrisccoulson> pgraner - what version of gnome-session are you running?
[21:45] <chrisccoulson> your xsession-errors shows it crashing, and that particular crash was fixed some days ago
[21:45] <pitti> the gnome-session backtrace isn't that helpful, that probalby needs apport love
[21:45] <chrisccoulson> pitti - that's the one that was exposed after correcting the consolekit policy
[21:45] <chrisccoulson> it looks pretty similar from the information there anyway
[21:46] <seb128> chrisccoulson: the crash was not about exec= though
[21:46] <chrisccoulson> no, the exec things are just warnings. it looks like gnome-session crashes later on though, when doing a dbus call
[21:46] <pgraner> seb128, pitti: no change
[21:47] <pitti> pgraner: dpkg -l gnome-session -> which version do you have?
[21:47] <pitti> dpkg -l gnome-session|cat  (meh)
[21:47] <pgraner> pitti: 2.26.1-1ubuntu
[21:47] <pitti> ah
[21:47] <pitti> pgraner: that would be it then
[21:48] <seb128> pgraner, weird, that one is outdated by several days, when did you upgrade?
[21:48] <pgraner> seb128: 30 min ago
[21:48] <pgraner> seb128: from us.archive.ubuntu.com
[21:48] <pitti> pgraner: "dpkg -l gnome-session |cat "
[21:48] <chrisccoulson> yeah, that will be why it's crashing, your gnome-session is out of date
[21:48] <pitti> pgraner: 1ubuntu3 had the crash fix
[21:48] <chrisccoulson> and we're on 2.27.4 now anyway
[21:48] <pitti> unfortunately dpkg -l itself checks the terminal size and cuts it off
[21:49] <pitti> yeah, seems the us mirror is lagging?
[21:49] <chrisccoulson> heh. that's why i never use the mirrors
[21:50] <pgraner> pitti: dpkg -l gnome-session |cat  reports: 2.26.1-1ubuntu2
[21:50] <pitti> pgraner: ok, thanks; that was known-broken indeed
[21:50] <pgraner> pitti: whats the best archive to use then?
[21:50] <pitti> pgraner: so it seems your mirror has the consolekit version which broke it (which was uploaded 8 hours _after_ the gnome-session fix)
[21:50] <pitti> wierd
[21:50] <pitti> pgraner: well, ideally us.archive would just work
[21:50] <chrisccoulson> yeah, i was just thinking that
[21:52] <pitti> pgraner: you can try archive.u.c., but that'll be slow
[21:52] <pgraner> pitti: I just ran  "apt-get update && apt-get upgrade" and it told me that it held 14 packages back including gnome-session
[21:52] <pitti> oh
[21:52] <pitti> pgraner: you need dist-upgrade
[21:52] <pitti> "upgrade" is fairly useless in a development release, I'm afraid
[21:53] <pitti> since we update library APIs, new packages, etc. all the time
[21:53] <pitti> new gnome-session pulls in a new libxklavier package
[21:53] <pgraner> pitti: ok, good to know. However I got into this state with update-manager
[21:53] <pitti> I guess that was it
[21:54] <chrisccoulson> i'd definately move ~/.config/autostart aside if you haven't done already though. it seems it's full of broken desktop files
[21:54] <pgraner> chrisccoulson: done
[22:01] <pgraner> pitti, seb128: that did the trick
[22:01] <seb128> pgraner, good
[22:01] <pgraner> all is back to normal
[22:01] <pgraner> Thanks for the assistance
[22:04] <brettalton1> Is it possible for me to get mentored to packaged both Code Igniter and Kohana, both php frameworks?
[22:04] <pitti> pgraner: phew :)
[22:05] <brettalton1> I've been very interested in doing so for both projects, especially because they will have very little dependencies, so I figured they'd be good projects to learn how to package with.
[22:07] <spotter> I can't imagine many people are happy with multisearch
[22:45] <mathiaz> kirkland: I've switched my install test vms to use ide rather than virtio and it fixes the issue
[22:45] <mathiaz> kirkland: so it seems that there is a regression on qcow2+virtio guests
[22:46] <kirkland> mathiaz: or, you can use raw+virtio
[22:46] <kirkland> mathiaz: that works too
[22:46] <mathiaz> kirkland: true
[22:46] <kirkland> mathiaz: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/403215
[22:46] <kirkland> mathiaz: feel free to add to that bug your findings
[22:47] <mathiaz> kirkland: except that in my use case I don't have space to generate all of the test install guests if I use raw images :/
[22:47] <mathiaz> kirkland: so I'll use qcow2+ide instead
[22:47] <mathiaz> kirkland: did you update the release notes?
[22:47] <kirkland> mathiaz: no, i'm still debugging the problem
[22:52] <tkamppeter> directhex, you can plug your new Kyocera printer now, the PPDs on OpenPrinting are updated, so system-config-printer should pull the new Kyocera PPD package for you.
[22:57] <directhex> tkamppeter, awesome!
[23:29] <Keybuk> kees: kernel already checks for CAP_NET_ADMIN when you talk to it
[23:30] <Keybuk> and there are thus valid apps that start as root, and drop everything but CAP_NET_ADMIN for their children
[23:33] <kees> Keybuk: context loss...
[23:34] <kees> Keybuk: ah, tun.  right
[23:35] <kees> Keybuk: new issue for you, you said you were going to make sure the debugfs was readable only by root, but that doesn't seem to be.
[23:35] <Keybuk> I asked kernel people and they said they didn't recommend it
[23:35] <Keybuk> and that again, any secure info should already be checked for
[23:35] <kees> Keybuk: and on a 3rd issue, what do you think of this: http://paste.ubuntu.com/225114/
[23:36] <kees> Keybuk: but does anything non-root need it?  it'd be nice to have a stricter default.
[23:36] <Keybuk> things in debugfs include the replacement for "/proc/bus/usb/devices" => /sys/debug/usb/devices
[23:36] <Keybuk> yes, ^
[23:36] <kees> eww
[23:36] <kees> not very _debug_ if it's used for production things. :P  ah well
[23:36] <Keybuk> it's more "things that used to be in /proc but don't belong in /sys"
[23:36]  * kees nods
[23:37] <Keybuk> kees: that kind of config belongs in gnome-power-manager
[23:37] <kees> Keybuk: my server isn't using gnome-power-manager.
[23:38] <Keybuk> your server is a beautiful and unique snowflake ;)
[23:38] <kees> *sigh*
[23:39] <kees> Keybuk: but gpm has nothing that allows for this configuration yet, correct?
[23:39] <Keybuk> every config option like that costs boot time
[23:40] <kees> it's after boot -- 60 seconds after boot...
[23:40] <Keybuk> that script is broken
[23:40] <kees> heh
[23:40] <Keybuk> and will be probably be just replaced by devicekit-power or something
[23:40] <Keybuk> and in the process, your config would be dropped
[23:40] <Keybuk> anyway, bed
[23:41] <kees> I would normally add stuff like this to rc.local, but since ondemand is 60s delayed, it's less useful.   okay, g'night