[03:39] <bookpage> how to make $display be set on a virt?
[03:40] <RAOF> bookpage: export DISPLAY=:0 (or whatever)
[06:21] <didrocks> good morning
[07:12] <diwic> tjaalton, here we go again...the Nvidia kernel module refuses to load :-(
[07:12] <diwic> tjaalton, that is, according to Xorg.0.log
[07:13] <diwic> after latest days update
[07:13] <tjaalton> nouveau loaded?
[07:13] <diwic> tjaalton, seems not to, but I don't remember exactly how to check
[07:13] <tjaalton> lsmod
[07:13] <tjaalton> :)
[07:14] <tjaalton> there should be a blaclist file in /etc/modprobe.d
[07:14] <diwic> tjaalton, according to lsmod, "nvidida" is loaded
[07:14] <tjaalton> installed by nvidia-current
[07:14] <tjaalton> ok, so that's not it
[07:14] <tjaalton> pastebin the log
[07:14] <diwic> of xorg.0.log?
[07:14] <tjaalton> yes
[07:14] <diwic> hmm, how do I easiest do that without X
[07:14] <tjaalton> pastebinit foo
[07:15] <tjaalton> install it first if not
[07:16] <diwic> http://paste.ubuntu.com/701490
[07:16] <hrw> I am going to hate LP build failures. my packages (armel-cross-toolchain-base and armhf-cross-toolchain-base) both ftfbs on launchpad. but when I built them locally in pbuilder or in LP chroot they got built fine. arghhhhhh
[07:17] <tjaalton> diwic: so if you 'stop lightdm; start lightdm' it works ok?
[07:17] <diwic> let me try
[07:17] <tjaalton> the logfile complains about the kernel module, but you said it was loaded
[07:17] <tjaalton> maybe lightdm is too fast
[07:18] <tjaalton> though the x driver should do the loading
[07:18] <diwic> tjaalton, ah, that did it (had to do that in sudo though)
[07:18] <tjaalton> sure
[07:19] <diwic> maybe file a bug against lightdm? Or nvidia-current?
[07:19] <tjaalton> put dmesg on pastebin too, i'll check what it says there
[07:20] <hrw> any ideas how such build failure happens?
[07:21] <infinity> dpkg-source: error: syntax error in eglibc-2.13/debian/control at line 114: duplicate field Multi-Arch found ?
[07:21] <infinity> That's hardly buildd-specific.
[07:22] <diwic> tjaalton, paste.ubuntu.com/701496
[07:22] <hrw> infinity: yes
[07:22] <hrw> infinity: I do not have it in pbuilder or in chroot fetched from LP build farm
[07:23] <hrw> infinity: with exactly same dsc used
[07:24] <tjaalton> diwic: ok, so it start's loading the module at 3.9s, X barfs at 4.4s, and then at 5.1s the loading is complete
[07:24] <tjaalton> an interesting race condition.. maybe a bug in the xserver
[07:24] <infinity> hrw: There's nothing fancy about how we call sbuild in lp-buildd.  Are you sure you're using a clean copy of the chroot from launchpad, and nothing but the build-deps?
[07:25] <tjaalton> diwic: or in the nvidia driver ratherr
[07:25] <tjaalton> -r
[07:25] <infinity> hrw: (You can copy the list of installed packages that sbuild shows in the log, rather than using apt-get source, to be sure)
[07:25] <hrw> infinity: clean it was
[07:26] <hrw> infinity: anyway I will unpack this chroot again, do a step-by-step build and check at failed moment
[07:26] <infinity> hrw: To be honest, I'd rather not have an armhf cross-compiler in oneiric anyway, unless it includes the new loader location, which I'm assuming it doesn't.
[07:27] <hrw> infinity: armel cross fails same way
[07:28] <hrw> infinity: as they share source package source
[07:28] <diwic> tjaalton, ok, let me know if I should file a bug about it and if so against what component
[07:28] <infinity> hrw: Sure, I know.  I'm not saying it's failing on purpose because I don't want it in the archive, just saying I'm not sure I care if it gets fixed (and I'm not sure it should have even been accepted, but it wasn't me who did it).
[07:28] <tjaalton> diwic: ubuntu-bug nvidia-graphics-drivers
[07:29] <tjaalton> diwic: and mention that the x driver is too impatient waiting for the kernel module to load
[07:29] <hrw> infinity: it needs to be fixed cause cross toolchain is not installable now
[07:29] <hrw> infinity: so... ;(
[07:29] <infinity> They were new packages...
[07:29] <infinity> Like, 2 days ago.
[07:29] <infinity> It's just as easy to remove them as to fix them. :P
[07:34] <hrw> infinity: nope - gcc-*-armel-cross ones got built in meantime
[07:38] <diwic> tjaalton, bug 865111
[07:39] <infinity> hrw: Let me reproduce it here.
[07:39] <tjaalton> diwic: thanks, tseliot will take it from there
[07:39] <diwic> tjaalton, ok, thanks for the workaround in the mean time :-)
[07:41] <infinity> hrw: Still, I wish we hadn't accepted this whole lot.  It enabled biarch too, didn't it?  Which we'll probably have to turn off again. :P
[07:41] <infinity> hrw: Oh well.
[07:42] <hrw> infinity: I got multilib toolchain buildable - but need to fix issues while using it
[07:42] <infinity> "Issues" like "the loader for both arches is in the same filesystem location, and ABI-incompatible"?
[07:43] <hrw> infinity: report bug?
[07:43] <infinity> Or like "gcc on ARM is completely missing run-time biarch detection".
[07:44] <infinity> hrw: We have a fix for the former (the loader issue), as discussed and agreed upon at LPC, but it means disabling biarch builds until we fix the latter.
[07:45] <hrw> infinity: link to notes/bugs?
[07:45] <infinity> cross-distro for the LPC notes.
[07:45] <hrw> ok
[07:45] <infinity> I have no bug filed for the broken biarch business.
[07:46] <infinity> But if you'd like to make gcc on ARM work the same as it does on x86, be my guest.
[07:46] <infinity> Right now, while we can do "biarch builds", it's complete BS, cause they don't actually work, at all.
[07:47] <infinity> And I'm not even convinced we need them, but that's a different discussion.
[07:47] <infinity> Cross-compiling soft from hard and hard from soft sounds like an odd corner-case to me, rather than just treating them as completely seperate arches.
[07:48] <infinity> (Usually we want biarch to be able to cross-compile kernels when the kernel arch != host arch, but for ARM, that doesn't matter..)
[07:49] <hrw> so ubuntu/armel is not able to build ubuntu/armhf packages now?
[07:49] <hrw> natively? (I did not checked)
[07:49] <infinity> No.
[07:51] <infinity> Not with multilib, that is.  Obviously, a chroot that's fully-native armhf will work fine (though still has the wrong loader path).
[07:51] <infinity> But, like I said, to fix the loader path, it's either a rewrite of multilib for ARM (which is beyond broken), or disabling it.
[07:52] <infinity> Disabling it is the path of least resistance for now, if we want to actually have an hf port in the next 6 months.
[07:52] <infinity> Unless someone really wants to fix multilib this week.
[07:52] <infinity> (feel free to volunteer)
[07:53] <infinity> hrw: You should probably be in #linaro-armhf ...
[07:53] <hrw> infinity: shit. forgot to add this to autojoinlist
[07:54] <hrw> I am on 16 irc channels ;(
[07:54] <infinity> That's all?
[07:54] <hrw> on 5 networks
[07:55] <hrw> infinity: for 16 years of doing irc I used <10 for all years before canonical/linaro
[07:55] <infinity> Heh.
[07:55] <infinity> IRC channels are cheap, it's a nice way to keep topics focussed.
[07:55] <infinity> Especially in massive communities like Debian and Ubuntu.
[07:56] <infinity> Maemo had similar partioning, and the main channels were just completely silent.  It was a bit creepy.
[07:56] <infinity> partitioning*
[07:57] <infinity> I should probably sleep.  It's 2am.
[07:57] <infinity> hrw: Poke me about your build failure tomorrow if you haven't figured it out.  I'll throw some spare cycles at it.
[07:58] <hrw> infinity: I hope to get it solved today by myself but thanks for offer
[07:58] <infinity> hrw: But we should talk multilib more, if you're interested enough to consider looking at it, and have the resources to allocate.
[07:58] <hrw> infinity: would be nice if multilib bugs would be reported
[07:58] <infinity> hrw: In talking with doko, I thought the "multilib doesn't work on ARM" thing was well-known upstream.
[07:58] <hrw> infinity: arm multilib was done by doko and it's really fishy
[07:59] <infinity> hrw: Hence didn't report anything.
[07:59] <hrw> infinity: upstream did not had multilib for arm iirc
[07:59] <hrw> infinity: only CSL had
[07:59] <infinity> hrw: Well, upstream being Linaro, or whatever.  Not me. :P
[07:59] <hrw> ok
[08:00] <infinity> hrw: Either way, it's completely broken, and would love to actually discuss it sometime, rather than just file a bug and forget about it.  But we can file bugs while we discuss too. :)
[08:01] <infinity> To be fair, it would have "worked" if we'd gone with the crazy "loader auto-detecting HF binaries" route, but that way just looks like madness to me.
[08:01] <infinity> But for the seperate loaders case, it can't work, cause it doesn't select at compiler run-time like x86 does, it's all hardcoded.
[08:01] <infinity> Some serious cargo-culting of x86 multilib would probably work.
[08:43] <ubuntu-baltix> hi all
[08:43] <ubuntu-baltix> ev: hi, are you online?
[08:43] <ev> ubuntu-baltix: yes, hi
[08:44] <ubuntu-baltix> ev: it seems you forgot to update ubiquity-slideshow-ubuntu translations from launchpad after translation freeze :(
[08:45] <ev> I updated them on the 28th of September
[08:46] <ubuntu-baltix> ev: but translation freeze was on 29th :)
[08:47] <ev> ubuntu-baltix: I'll stick an upload in the queue, but it's up to the release team to decide if they want to accept it.
[08:48] <ubuntu-baltix> ev: please update ubiquity-slideshow-ubuntu, because at 28th september Lithuanian translation was half complete (about 50%), but at 29th - fully translated (100%) :)
[08:49] <ubuntu-baltix> I think it's very important to have fully translated slideshow in release candidate
[08:50] <ev> ubuntu-baltix: I just said I would put an upload of the translations in the queue, but it's not my call as to whether or not it goes in.
[08:51] <ubuntu-baltix> ev: thanks, could you tell me who should decide if accept or not? Maybe pitti ?
[08:52] <ev> ubuntu-baltix: I already did. The release team.
[08:52] <ubuntu-baltix> ev: Where I can talk with release team? ;)
[08:53] <ev>  #ubuntu-release
[08:54] <ubuntu-baltix> ev: thans again :)
[08:54] <ev> sure thing
[12:34] <soren> Did I miss it, or do we not know what 12.04 will be called yet?
[12:36]  * cjwatson has not yet seen a name
[12:36] <cjwatson> sabdfl: ^- getting kind of urgent :)
[12:36] <azeem_> I thought it was going to be the pink panther?
[12:37] <Laney> now that would make a good login sound
[12:37] <seb128> Laney, no login sound is a good login sound ;-)
[12:37] <azeem_> you could just have the first two notes, then the desktop should be there
[12:38] <azeem_> would also remove IP-issues
[12:58] <janimo> seb128, you mean broken pulseaudio :) ?
[13:01] <diwic> janimo, a broken login sound is hardly pulseaudio's fault
[13:01] <diwic> janimo, more likely to have to do with libcanberra or other upper layer
[13:01] <janimo> diwic, is not every sound going through pulse?
[13:01] <seb128> janimo, ;-)
[13:02] <diwic> janimo, usually, yes
[13:03] <diwic> janimo, but playing the login sound involves other components of the audio stack as well and my point is that PulseAudio is every now and then blamed for things incorrectly.
[13:04] <seb128> diwic, speaking of that do you know what would be the right way to have no login sound by default?
[13:04] <seb128> we want to do that next cycle
[13:04] <diwic> seb128, hmm, good question - I assume some kind of override to the gnome sound theme
[13:04] <diwic> seb128, who are "we", btw?
[13:05] <diwic> seb128, I haven't heard that request before.
[13:25] <artfwo> hi
[13:25] <artfwo> do I have to request an FFE in order to sync the package from debian at this stage of development?
[13:26] <sgnb> I hope so
[13:27] <tumbleweed> artfwo: if there are only RC bug fixes, no new features, and it's not seeded, then you can just upload it
[13:28] <artfwo> tumbleweed, i don't have upload rights, but a sync fixes uninstallable package in my case, take a look at bug 865334
[13:30] <om26er> patch pilot is missing :p
[13:31] <tumbleweed> artfwo: LGTM
[13:31] <seb128> om26er, bryceh and micahg are pilots today
[13:31] <seb128> om26er, chrisccoulson is on holidays this week
[13:31] <seb128> om26er, but it's a bit early for bryceh to be up still I guess
[13:31] <tumbleweed> meh, this marking bugs confirmed because they affect multiple uses messes with sync requests...
[13:32] <om26er> seb128, robert_ancell seems to be current thats an error?
[13:32] <seb128> om26er, he probably forgot to sign off
[13:32] <om26er> i'll wait for bryceh to get something re-SRUed
[13:32] <tumbleweed> artfwo: oh, you only mentioned the most recent changelog entry, not the intermediate ones. That would require an FFe
[13:33] <seb128> om26er, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
[13:33] <artfwo> tumbleweed, but the current version in oneiric isn't installable anyway, does that qualify for an FFE as well?
[13:34] <tumbleweed> artfwo: it means I'm very likely to give you a FFe. But you still need to apply for it
[13:34] <om26er> seb128, thx :)
[13:49] <om26er> I have a question related to uploads to archive.. if a release 3.8.16-0ubuntu1~natty3 is rejected for some reason after fixing my branch will the same version upload again work fine? or would it automatically get rejected?
[13:49] <artfwo> tumbleweed, could you take a look at bug 865334 - is there enough data for an exception?
[13:50] <geser> om26er: if the source got rejected you can keep the version number
[13:50] <gtec> hello everyone: I am unclear on the difference between a pxelinux.0 image and a nbi.img. Is it required that etherboot boots a pxelinux.0 image as oppose to a nbi.img?
[13:51] <tumbleweed> artfwo: yes, thanks
[15:41] <tgardner> does anyone know whats up with armel-cross-toolchain-base in Oneiric? You can't install gcc-4.6-arm-linux-gnueabi because of dependency issues. Launchpad thinks armel-cross-toolchain-base was published 2 hours ago.
[15:41] <hrw> tgardner: I know
[15:42] <hrw> tgardner: wait two more days ;(
[15:42] <tgardner> hrw, thats pretty inconvenient at this point in Oneiric development. 2 days ?
[15:43] <apw> hrw what is it doing which takes 2 days?
[15:43] <cjwatson> how long it'll take hrw's fix to build, presumably
[15:43] <cjwatson> "published 2 hours ago" means the source package
[15:43] <hrw> moment
[15:43] <tgardner> Launchpad appears to think the build is done
[15:44] <cjwatson> actually it says pending publication now, so maybe s/2 days/an hour/
[15:44] <hrw> one more source to build - armhf-cross-toolchain-base (got uploaded just moment ago, need to be accepted), then rebuild of gcc-4.[56]-armel-cross (ftfbs-ed because of armel-cross-toolchain-base failure)
[15:44] <cjwatson> oh, it's in NEW
[15:45] <hrw> I had some linaro tasks to do which had higher priority.
[15:47] <cjwatson> processed now, so next publisher run I suppose
[15:47] <hrw> thank you
[15:47] <tgardner> cjwatson, thanks, will give it a go in an hour or so
[15:48] <bdmurray> Could somebody look at bug 859188?  Its not clear to me what might be going on here.
[15:49] <hrw> for p-cycle I will move to 'publish to ppa first' method - as LP builds are not reproductible even with chroots from LP
[15:49] <slangasek> bdmurray: confusing error message; to apt-get install --reinstall a multiarch: same package that you have more than one version of installed, you have to do "apt-get install --reinstall $pkg $pkg:$otherarch", or else you get that error
[15:50] <hrw> or I am doing something wrong
[15:51] <bdmurray> slangasek: so they have installed for i386 and amd64?
[15:51] <slangasek> bdmurray: yes
[15:52] <cjwatson> hrw: well - I do have to say, most people with this problem are doing something wrong, or very few of us would ever get anything done!
[15:52] <cjwatson> mind you if your build is *that* sensitive to details of the chroot then there's probably something wrong there too
[15:53] <cjwatson> occasionally there's something that depends on the running kernel, which in the case of LP builds is rather older than the distribution it's building for
[15:53] <hrw> cjwatson: I fetched chroot from LP and got it built in it.
[15:53] <hrw> cjwatson: I will try to find time in p-cycle to check some issues
[15:54] <didrocks> can someone bump the unity build in the ubuntu-destkop ppa (to prepare some testing for an eventual tomorrow upload with those fixes + few additional ones): https://launchpad.net/~ubuntu-desktop/+archive/ppa
[16:13] <SpamapS> barry: is there any progress on porting dh_python2 to lucid?
[16:14] <didrocks> barry: thanks for the Quickly fix btw :)
[16:54] <barry> SpamapS: doko_ is working on that
[16:56] <SpamapS> barry: ahh cool thanks
[16:56] <SpamapS> doko_: and I ask you, how is the dh_python2 port to lucid coming along? :)
[16:59] <bdmurray> slangasek: Do you have any thoughts on bug 813065?
[18:20] <bryceh> !pilot in
[18:20] <bryceh> @pilot in
[18:20] <om26er> bryceh, can you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/unity/unity-fix-761409 :)
[18:21] <om26er> bryceh,  you sponsored it last time but seems there was an issue at your end last time so the upload got rejected :/
[18:23] <om26er> here is the changelog of the rejected upload http://launchpadlibrarian.net/79155358/unity_3.8.16-0ubuntu1~natty2_3.8.16-0ubuntu1~natty3.diff.gz
[18:30] <bryceh> om26er, what was the issue at my end?
[18:31] <om26er> bryceh, the changelog also have --- unity-3.8.16.orig/.bzrignore.THIS
[18:31] <om26er> +++ unity-3.8.16/.bzrignore.THIS
[18:31] <om26er> the one that was uploaded to the archives my branch did not have it
[18:31] <om26er> though i am not sure how things work
[18:34] <bryceh> ok
[18:36] <bryceh> om26er, done
[18:36] <om26er> bryceh, thank you :-)
[18:43] <infinity> jamespage: Your nova changelog doesn't even remotely match the diff.
[18:54] <jamespage> infinity: how so?
[18:55] <infinity> jamespage: http://launchpadlibrarian.net/81802657/nova_2011.3-0ubuntu4_2011.3-0ubuntu5.diff.gz
[18:55]  * jamespage re-reads his changelog entry
[18:55] <infinity> jamespage: I see the permission bits in postinst... And then a ton of other stuff.
[18:56] <jamespage> infinity: I see - looks like the packaging branch was probably not up-to-date
[18:58] <infinity> Right, well.  I'm going to reject this, if you'd like to re-upload with just the postinst fix. ;)
[18:58] <jamespage> infinity, absolutely
[19:21] <jamespage> infinity: somethings not right - it looks like older patches where included in the upload to the archive
[19:21] <jamespage> can't find zul at the moment but it needs verification/unpicking
[19:33] <infinity> jamespage: You can just make your postinst change to the archive version?
[19:38] <jamespage> infinity: well I could but I'm concerned that we have an incorrect backported patch - I'd like to get that resolved/verified as OK as well
[19:40] <infinity> jamespage: Fair enough.
[19:56] <dobey> is anyone else having booting/network issues with current oneiric?
[19:56] <dobey> because i have two laptops that are now pretty much entirely useless after updating them within the last 24 hours :(
[19:59] <dobey> SpamapS: did you break my laptops?
[20:05] <SpamapS> dobey: probably ;)
[20:06] <SpamapS> dobey: whats the issue?
[20:06] <SpamapS> dobey: do they say waiting for network configuration?
 in normal boot the splash works fine, it just says "Waiting for network..."
[20:08] <seb128> SpamapS, ^
[20:08] <seb128> SpamapS, he said that it never finishes waiting
[20:08] <bdmurray> @pilot in
[20:09] <SpamapS> I may have created a huge red herring with that message...
[20:09] <dobey> SpamapS: yes
[20:09] <SpamapS> the problem is I can't *hide* it when its completed.
[20:09] <dobey> SpamapS: my dell duo doesn't boot now
[20:10] <dobey> it stays waiting for network
[20:10] <SpamapS> dobey: can you boot with noquiet and --verbose ?
[20:10] <dobey> my u820 boots but has other issues
[20:10] <SpamapS> dobey: it never says Waiting at least 60 more seconds ?
[20:10] <dobey> SpamapS: i don't know. can you be more verbose about where to add them?
[20:10] <dobey> SpamapS: it does say that
[20:10] <dobey> SpamapS: it just doesn't ever finish waiting
[20:10] <SpamapS> dobey: does it ever say that its booting with an incomplete configuration?
[20:11] <SpamapS> dobey: the process that is used for those messages is really failsafe.. unless /bin/sleep segfaults or something.
[20:11] <dobey> SpamapS: i'll let you know in a couple minutes
[20:11] <SpamapS> dobey: so if you see the first two, but not the third, then something is breaking *after* those messages are long dead and gone.
[20:11] <dobey> oh ffs; now it's doing fsck
[20:12] <dobey> SpamapS: seems like it is breaking long before, since i shouldn't ever see those messages
[20:12]  * SpamapS ponders adding a post-start to clear the messages
[20:13] <SpamapS> dobey: you'll see them if your loopback adapter isn't up for some reason, or if you have interfaces configured in /etc/network/interfaces
[20:13] <dobey> waiting up to 60 moar now
[20:13] <dobey> SpamapS: and neither of those should be true unless an update broke something
[20:13] <dobey> and well, i think it's obvious an update broke something
[20:14] <SpamapS> dobey: as far as the noquiet/--verbose .. edit the grub kernel command line and remove 'quiet' , and add '--verbose'
[20:14] <dobey> booting without full config
[20:15] <dobey> except it is a message wrought with lies
[20:15] <dobey> as evidenced by the lack of actual booting
[20:15] <SpamapS> dobey: ok, so it should boot now.. unless lightdm or plymouth is broken
[20:17] <SpamapS> dobey: ctrl-alt-f1 should also get you a tty to login to
[20:17] <dobey> SpamapS: what should i see with noquiet --verbose ?
[20:17] <dobey> SpamapS: nope, it just had the textual output of the init scripts
[20:17] <SpamapS> dobey: kernel messages, services starting..
[20:18] <SpamapS> dobey: what was the last thing shown?
[20:18] <SpamapS> alt-f2 might actually be better, it starts on runlevel [23] ..
[20:18] <dobey> it's still waiting for the network
[20:19] <SpamapS> dobey: before those messages that you already saw in plymouth.. anything else?
[20:19] <dobey> stopping failsafe boot delay was the last thing
[20:20] <dobey> lo is the only thing in /etc/network/interfaces
[20:20] <SpamapS> Interesting
[20:20] <dobey> and i have no network connection
[20:21] <SpamapS> ls -l /run/network
[20:21] <SpamapS> should be a dir, 'static-network-up-emitted'
[20:21] <dobey> that exists
[20:22] <SpamapS> I'm most intrigued why your system hasn't "booted" at this point, because you are clearly in runlevel 2 if you have a login on tty2
[20:22] <SpamapS> can you look for clues in /var/log/syslog? Maybe the display manager failed to start
[20:22] <SpamapS> dobey: at the point that dir exists, and when your filesystems are up, thats when runlevel 2 should have started and the messages should have stopped.
[20:23] <SpamapS> hmm I wonder though.. /etc/network/if-up.d/upstart creates that dir, and then runs initctl emit
[20:25] <dobey> well running /etc/init.d/lightdm restart got me a login screen and i can log into unity now
[20:26] <dobey> but no network or bluetooth
[20:26] <SpamapS> btw, /etc/init.d/<anything> is deprecated in Ubuntu
[20:26] <SpamapS> use service
[20:26] <dobey> i did use service, and it didn't work
[20:26] <SpamapS> because?
[20:26] <kenvandine> restart lightdm
[20:26] <kenvandine> is all you need
[20:26] <SpamapS> kenvandine: and is very dangerous
[20:26] <kenvandine> oh?
[20:26] <dobey> it said "not found" or something like that
[20:26] <SpamapS> kenvandine: it doesn't reload the upstart job.. and does not properly run pre-stop's
[20:27] <bdmurray> SpamapS: speaking of service how do you know what services names are avaiable?  I get confused about samba vs smbd ...
[20:27] <SpamapS> use service. :)
[20:27] <kenvandine> oh... i thought it was an upstart command
[20:27] <dobey> SpamapS: the deprecated message says to use restart
[20:27] <dobey> not service
[20:27] <dobey> maybe you should fix that :)
[20:27] <seb128> sudo restart lightdm often fails there
[20:27] <seb128> it says there is no lightdm runnin
[20:27] <SpamapS> bdmurray: unfortunately, that one is still unresolved in a single tool. 'initctl list' for upstart jobs, find /etc/init.d -type f  works for sysvinit
[20:27] <seb128> where it's running ;-)
[20:28] <SpamapS> yeah the deprecated message should be fixed
[20:28] <dobey> anyway
[20:28] <dobey> my laptops are broken
[20:28] <bdmurray> SpamapS: thanks initctl was what I was missing
[20:28] <hallyn_> Daviey: jdstrand: bug 842845 , final debdiff pulls a bunch of patches from upstream git.  Pls take a look.  It appears to solve the issue, and I think it should go into oneiric.
[20:28] <hallyn_> running out, biack in a bit
[20:28] <SpamapS> dobey: indeed, trying to determine why lightdm didn't start
[20:29] <SpamapS> dobey: --verbose would give us a clue. can you boot with that?
[20:29] <dobey> "unknown instance"
[20:29] <dobey> i did boot with that
[20:29] <dobey> where is it supposed to give a clue at? i didn't see any
[20:29] <SpamapS> right, restart doesn't work when it was never started, thats another annoyance.
[20:30] <SpamapS> dobey: /var/log/syslog would have any errors about lightdm
[20:30] <SpamapS> its possible that it didn't exit with any "errors" it just decided not to start.
[20:30] <SpamapS> but that would be odd
[20:32] <dobey> i think i need to reboot
[20:32] <SpamapS> dobey: anything in /var/log/syslog ?
[20:32] <dobey> some stuff but i can't tell if it's from me doing restart or from booting
[20:33] <SpamapS> dobey: you can match up the timestamps with the switch to runlevel 2
[20:34] <dobey> SpamapS: it appears something is stopping it, and then killing it with SIGTERM
[20:35] <dobey> last lightdm related message is "lightdm state changed from post-stop to waiting"
[20:40] <slangasek> bdmurray: 813065> I think I'll try to reproduce that; it might be an easy win for release
[20:40] <bdmurray> slangasek: okay, I was able to see it in a virtual machine fwiw
[20:43] <SpamapS> dobey: brb, need to go move laundry from washer to dryer..
[20:43] <SpamapS> dobey: have you tried rebooting w/ --verbose yet?
[20:45] <slangasek> bdmurray: does "VT console" mean a login prompt, a blinking cursor, or a black screen?
[20:45] <slangasek> (just to be sure I know what I'm looking for)
[20:46] <bdmurray> slangasek: none of the above - I saw boot log messages
[20:46] <dobey> SpamapS: yes, but i can't see anything useful. something is telling lightdm to start, then stop, then it kills lightdm
[20:46] <slangasek> bdmurray: aha
[20:49] <slangasek> bdmurray: oh; this bug is for lucid, not for oneiric?
[20:50] <bdmurray> slangasek: its tagged oneiric too and thats what I tested
[20:50] <slangasek> ok
[21:04] <SpamapS> dobey: very intersting. I don't see any direct reasons that lightdm would be sent SIGTERM by upstart... it only stops on runlevel [016] .. none of those are happenign surely.
[21:05] <dobey> isn't that "poweroff" ?
[21:05] <SpamapS> 0 is halt/poweroff
[21:06] <SpamapS> 6 is reboot
[21:06] <SpamapS> dobey: something could be doing a 'stop lightdm' tho
[21:06] <SpamapS> it does a stop in its own script..but then exit 0 right after that.
[21:07] <SpamapS> dobey: does this return 0:
[21:07] <SpamapS> [ ! -f /etc/X11/default-display-manager -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/bin/lightdm" -o "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ]
[21:07] <dobey> right
[21:07] <dobey> wtf
[21:07] <SpamapS> actually hmmmmmmmmmm
[21:07] <dobey> that's a lot of typing :(
[21:07] <SpamapS> if [ "$RUNLEVEL" = S
[21:08] <SpamapS> I think that may be a misuse of the RUNLEVEL variable
[21:08] <dobey> in lightdm's init script?
[21:08] <SpamapS> yeah
[21:09] <SpamapS> the script was recently changed to simplify with less ()'s.. I wonder..
[21:09] <dobey> waoh
[21:09] <dobey> woah even
[21:09] <dobey> somehow i got network

[21:17] <SpamapS> dobey: I think this may be it.. if one of the other events comes *after* runlevel 2 ... RUNLEVEL is still "S"
[21:17] <dobey> meh, update/reconfigure didn't help
[21:17] <SpamapS> dobey: no I think you have found a bonified, majorly crap race condition
[21:17] <infinity> jamespage: Err, did you re-upload the same broken one again?
[21:17] <dobey> SpamapS: how can we fix?
[21:18] <SpamapS> we need to check with the actual runlevel command, I think
[21:18] <SpamapS> I have a working test case which shows the problem
[21:18] <SpamapS> dobey: if I give you a replacement lightdm.conf, can you try it out?
[21:19] <SpamapS> I'm trying it in a VM now
[21:19] <dobey> SpamapS: give me a diff
[21:19] <dobey> SpamapS: then i can just change it, since i can't easily just copy stuff over
[21:19] <slangasek> SpamapS: I don't understand where the race condition is, can you explain?
[21:20] <SpamapS> slangasek: sure, RUNLEVEL is set only when the 'runlevel' event arrives
[21:20] <SpamapS> slangasek: but it may have been set by some other event that arrived before 'runlevel'
[21:20] <slangasek> really?
[21:20] <slangasek> which event would set it?
[21:20] <SpamapS> slangasek: Yeah, thats my hypothesis
[21:20] <SpamapS> I'm testing it out now :-P
[21:20] <slangasek> ok :)
[21:20] <SpamapS> slangasek: no idea!
[21:21] <SpamapS> slangasek: nothing exports it except /etc/init/rc.conf
[21:21]  * slangasek nods
[21:21] <SpamapS> slangasek: one theory I also have is that there's a bug in upstart which copies it in even when it doesn't match
[21:22] <SpamapS> slangasek: either way, it seems the most likely cause for dobey's problems that RUNLEVEL is coming up as "S" instead of "2" during lightdm's script
[21:23] <SpamapS> tho.. there's another problem with that, which is that he's seeing the failsafe messages.. hrm
[21:24] <dobey> this is but one of the many problems i am currently facing with oneiric :-/
[21:25] <slangasek> SpamapS: seems strange that only dobey would be affected
[21:25] <dobey> that's what i said
[21:25] <slangasek> SpamapS, dobey: you've already ruled out /etc/X11/default-display-manager as the cause?
[21:26] <slangasek> oh
[21:26] <jamespage> infinity: no
[21:26] <dobey> i haven't ruled anything out as the cause. but i really have no idea what is going on at this point
[21:26] <slangasek> runlevel [!06]
[21:26] <slangasek> SpamapS: why is that not runlevel [!06S]?
[21:26] <slangasek> or even [!016S]
[21:27] <slangasek> apparently we're using lightdm to handle stopping of plymouth in runlevels 1,S ? that doesn't make sense...
[21:27] <slangasek> (what if you don't have lightdm installed, after all?)
[21:28] <SpamapS> slangasek: oo I didn't realize.. [!06] is *wrong*
[21:28] <infinity> jamespage: Well, it came back to the queue 28 minutes ago. :P
[21:28] <dobey> where is that?
[21:28] <SpamapS> slangasek: is 'runlevel S' emitted at bootup?
[21:28]  * infinity rejects harder.
[21:28]  * SpamapS tests that
[21:28] <jamespage> zul and I are like ships in the night this evening
[21:28] <slangasek> SpamapS: well, it's deliberate... I'm not sure that changing it in the obvious way is *right* either
[21:29] <slangasek> SpamapS: no, only 'telinit S' gets you runlevel S, by design
[21:29] <slangasek> otherwise /etc/init/rcS.conf would fire on every boot
[21:30] <slangasek> dobey: could you post the log from booting with --verbose?
[21:31] <dobey> i suspect not easily
[21:32] <SpamapS> slangasek: I thought rcS.d *was* executed every time the system booted. :-P
[21:33] <slangasek> SpamapS: running sulogin? :)
[21:34] <slangasek> dobey: if you have networking up, perhaps pastebinit is of use?
[21:35] <dobey> well i'm guessing the log doesn't rotate on every boot
[21:35] <dobey> what block would be most useful?
[21:36] <SpamapS> dobey: I'd be interested to compare the output of 'last' with 'grep init: /var/log/syslog'
[21:36] <slangasek> dobey: I'd want everything logged by init since boot
[21:37] <SpamapS> dobey: also the long line in /etc/init/lightdm.conf right after 'if [ -n "$UPSTART_EVENTS" ]'
[21:38] <SpamapS> dobey: actually just cat /etc/X11/default-display-manager would be helpful
[21:39]  * SpamapS goes afk again for 5 min
[21:39] <dobey> default-display-manager just says "lightdm"
[21:42] <slangasek> dobey: and just to be sure, what does 'debsums -s -e lightdm' show?
[21:42] <dobey> what provides debsums?
[21:42] <slangasek> the debsums package :)
[21:43] <dobey> good thing network decided to actually start working
[21:43] <dobey> too bad it doesn't on my other laptop
[21:44] <dobey> changed file /etc/lightdm/lightdm.conf
[21:44] <bigon> mmmh I hava valac (0.12) that segfault when building https://edge.launchpad.net/~gnome3-team/+archive/gnome3/+build/2820433
[21:44] <bigon> with debian version it build perfectly
[21:45] <slangasek> dobey: "changed file" - did you change it as part of the debugging, or was it already broken and that's what's causing your failures?
[21:45] <slangasek> dobey: you should have an /etc/init/lightdm.conf.dpkg-dist that you can compare with... and in theory replace with to get the system working again...
[21:46] <dobey> slangasek: that file was already changed, and doesn't seem like it would be related
[21:46] <dobey> slangasek: wrong lightdm.conf
[21:46] <slangasek> oh, right
[21:46] <slangasek> sorry
[21:46] <dobey> and i actually have no idea why it's different from the packaged version
[21:48] <slangasek> I think that one might get dynamically modified by lightdm itself
[21:49] <slangasek> (means conffiles are the wrong tool for it, but anyway - not relevant here)
[21:49] <dobey> right
[21:50] <dobey> where should i put this log?
[21:50] <slangasek> dobey: in a bug report / pastebin / people.c.c?
[21:52] <dobey> slangasek: https://chinstrap.canonical.com/~dobey/syslog.verbose

[21:55] <SpamapS> slangasek: it strikes me that calling 'stop' in the script section may not be a good idea
[21:55] <SpamapS> slangasek: exit 0 should suffice...
[21:56] <slangasek> SpamapS: 'stop' is preferred
[21:56] <SpamapS> slangasek: in this case, stop would cause upstart to send SIGTERM.. would it not?
[21:56] <slangasek> maybe it's triggering a bug here, but it's a bug to be fixed if so
[21:56] <dobey> well i need to go for now; thanks for helping debug
[21:56] <slangasek> SpamapS: SIGsomething, sure; but the event's already received and processed by that point, so it shouldn't hurt?
[21:57] <dobey> let me know if i need to test anything, my awaylog will catch it
[21:57] <SpamapS> slangasek: it shouldn't, no.
[21:58] <slangasek> dobey: does this system have hybrid graphics?
[21:58] <SpamapS> wait
[21:58] <SpamapS> 14:39 < dobey> default-display-manager just says "lightdm"
[21:59] <SpamapS> dobey: not /usr/bin/lightdm or /usr/sbin/lightdm ?
[21:59] <slangasek> ah, heh
[21:59] <SpamapS> that *would* do it
[22:03] <bdmurray> I'm looking at a pytrainer bug regarding communicating with gpsbabel and gpsbabel uses a 'usb:' parameter to communicate with the gps.  Anyway what device is 'usb:' so I can change permissions on it?
[22:04] <slangasek> bdmurray: probably something under /dev/bus/usb
[22:05] <bdmurray> slangasek: yes, a way to check occurred to me
[22:06] <slangasek> depending on how the device name is being constructed, there's probably something under /sys/bus/usb/devices that lets you query the mapping I guess
[22:09] <cjwatson> bdmurray: how do you know which services are available> 'service ' <tab> <tab>
[22:23] <SpamapS> slangasek: my laptop is affected too
[22:23] <SpamapS> lightdm is waiting for 'plymouth deactivate'
[22:24] <SpamapS> also the stop signal is being ignored in the pre-start for failsafe...
[22:24] <slangasek> SpamapS: "too"?  isn't that an entirely different issue?
[22:24] <SpamapS> slangasek: my symptoms are identical to dobey
[22:24] <SpamapS> I almost never reboot.. so when I did just now.. no lightdm
[22:24] <slangasek> SpamapS: stop signal> ah yes, did you not see the bug I reported about that/
[22:24] <SpamapS> slangasek: no I didn't see that bug.
[22:25] <SpamapS> slangasek: do we need to set some handler to die quicker?
[22:25] <slangasek> SpamapS: one sec, I'll assign it to you ;)
[22:25] <slangasek> SpamapS: bug #863864
[22:25] <SpamapS> anyway, lightdm is waiting on plymouth deactivate.. which is polling an "anon_inode"
[22:26] <slangasek> strange...
[22:27] <slangasek> I haven't seen this in any of my testing
[22:27] <slangasek> can you file a plymouth bug?
[22:27] <slangasek> also, please boot with plymouth:debug=file:/var/log/plymouth-debug.log and attach
[22:27] <SpamapS> slangasek: sure.. anything I can do to debug immediately?
[22:28] <slangasek> debug or unstick?
[22:28] <slangasek> debugging, I think you need to boot with plymouth debugging on
[22:28] <slangasek> unstick, I'd try stop lightdm ; plymouth quit; start lightdm
[22:28] <slangasek> (from tty2, say)
[22:29] <SpamapS> is it possible failsafe's plymouth tickling is causing plymouth deactivate to not work?
[22:29] <slangasek> I don't believe so
[22:29] <slangasek> ok - it's *possible*
[22:29] <slangasek> but that's a plymouth bug if so
[22:32] <SpamapS> hrm.. does stop not actually tell pre-start's to exit?
[22:32] <slangasek> correct
[22:32] <SpamapS> Garhhh.. ok.. poor assumption there.
[22:32] <slangasek> it changes the goal for the job, but does not kill a running process
[22:32] <slangasek> not a running pre-start, that is
[22:32] <slangasek> it waits for that to end on its own
[22:33] <SpamapS> ok, so does that mean I need to change it to a task and change the rc-sysinit to 'stopped failsafe' ? thats kind of the mechanics I was looking for, but its not as clear in rc-sysinit
[22:34] <SpamapS> that or I have to check runlevel before every plymouth message
[22:35] <SpamapS> oh wait I can check my status with status
[22:37] <slangasek> SpamapS: that's my suggestion in the bug report - completely untested though
[22:37] <slangasek> checking with status - yuck :)
[22:38] <SpamapS> I suppose I should switch back to X from console and read your suggestion
[22:56] <SpamapS> slangasek: so I think 'stopped failsafe' should be fine, rather than an explicit event... is this acceptible as a fix for 11.10 ?
[22:59] <slangasek> SpamapS: 'stopped failsafe' would cause /etc/init/rc-sysinit.conf to fire *twice*, unless you somehow made it a conditional 'stopped'
[23:00] <SpamapS> slangasek: twice?
[23:00] <SpamapS> slangasek: failsafe would only start at boot, no?
[23:01] <slangasek> SpamapS: the failsafe job is always going to stop, the question is whether it stops due to timeout or because it's killed.  so rc-sysinit is "start on (filesystem and static-network-up) or started failsafe"; if you change "started" to "stopped" at the same time you move the bulk of its functionality into 'script', on a successful startup you will *always* match both parts of that 'or'
[23:01] <SpamapS> slangasek: ahh right
[23:01] <slangasek> hence, needing an explicit event instead of 'stopped'
[23:09] <SpamapS> slangasek: ok, simple diff, and it fixes the problem with lightdm waiting on plymouth deactivate too
[23:10] <slangasek> wait, what?  how does it fix that?
[23:10] <SpamapS> ????
[23:10] <SpamapS> I had it happen 3 times in a row before this fix
[23:11] <SpamapS> slangasek: my guess.. plymouth waits for some socket to be closed which is held open by 'plymouth message' ?
[23:11] <slangasek> 'plymouth message' is one shot, should return immediately
[23:11] <slangasek> I mean, the execution of that script wouldn't work correctly if it didn't
[23:12] <SpamapS> slangasek: I think this is more important than "Medium" .. I noticed on my other more pure oneiric laptop that I saw Waiting for network configuration ... once just before lightdm popped up...
[23:12] <slangasek> yeah, I was going to raise the severity but hadn't gotten 'roundtuit yet
[23:12] <slangasek> (after realizing the implications on boot, not just shutdown)
[23:12] <SpamapS> ok, how about I raise it, and upload this diff which is relatively small, but probably needs serious scruitiny
[23:14] <slangasek> SpamapS: sounds good to me
[23:16] <bdmurray> What's the right status for a merge that shouldn't happen? A typo fix in the debian control file of a package we sync.
[23:16] <SpamapS> Needs Fixing in the comment, and Work in Progress for the MP
[23:17] <bdmurray> Work in Progress seems like a bad fit
[23:17] <slangasek> well, the right way is 'rejected'
[23:17] <slangasek> but I think there might still be a bug where only the TB can reject merge proposals for ubuntu-branches?
[23:17] <SpamapS> I always feel like if its fixable easily, then Work in Progress is appropriate.. it means its the owner's problem
[23:17] <slangasek> (whereas it should be "anyone who can upload")
[23:18] <slangasek> SpamapS: this is "this should not be merged because it should be done in Debian instead"
[23:18] <slangasek> so "rejected" is correct... if you can get to it
[23:18] <bdmurray> which I can't
[23:18] <SpamapS> Oh I misread the point of the question
[23:19] <TheMuso> 3~/c
[23:19] <hallyn_> Daviey: hey are you there?
[23:21] <hallyn_> Daviey: d'oh, you never pushed http://people.canonical.com/~serge/ipxe-bin.debdiff . (I forgot about it and forgot to check and prod :)
[23:21] <hallyn_> Daviey: it's needed in o
[23:28] <SpamapS> slangasek: uploaded
[23:28] <SpamapS> whoa and just as I hit enter on emit, one of my tests fails .. second upload pending.. damnit
[23:29]  * SpamapS vows to starve his fingers till they lose another ring size
[23:30] <SpamapS> slangasek: want to reject that upload?
[23:31] <SpamapS> actually I rejected it
[23:36] <slangasek> SpamapS: hum, as long as we're uploading upstart, I think I'd like to fix up the various manpage bugs at the same time
[23:36] <slangasek> (undocumented events)
[23:37] <SpamapS> slangasek: ok, I'll backout my debcommit --release..
[23:38] <SpamapS> slangasek: ok my change is in there as r1331
[23:38] <slangasek> SpamapS: cheers