[00:43] <cjwatson> jamespage: you're touched-it-last on r-base - mind if I merge it?  no desperate rush but I have a change to make to it and might as well bring it up to date at the same time
[01:30] <ikepanhc> @pilot in
[02:29] <jdstrand> bdmurray, Riddell: hey, so I am rejecting 2.5.1-0ubuntu5 because bdmurray's 2.5.1-0ubuntu6 includes it and I am rejecting 2.5.1-0ubuntu6 because my 2.5.1-0ubuntu7 will include both 2.5.1-0ubuntu5 and 2.5.1-0ubuntu6
[03:36] <pitti> Good morning
[03:38] <RAOF> Hey pitti!
[03:40] <ajmitch> morning pitti
[03:41] <pitti> Riddell: it's not that bad -- lp:apport for trunk, and Vcs-Bzr: for packaging
[03:42] <pitti> RAOF, ajmitch: hello to downunder!
[03:44] <pitti> Riddell: applied your patch to trunk, thanks!
[03:47] <cc11rocks> Hello guys. My first Debian patch went through :D >> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libxml-csv-perl.git;a=commitdiff;h=c934802
[03:51] <jk-> ^5
[03:52] <cc11rocks> ?
[03:52] <RAOF> (High five)
[03:53] <jk-> yep
[03:53] <pitti> bdmurray, jdstrand: can you please commit your apport changes in http://launchpadlibrarian.net/114828232/apport_2.5.1-0ubuntu7_source.changes to the Vcs-Bzr: branch?
[03:53] <jk-> I guess you could XOR with 5 instead, but not sure that really conveys the same sense of congratulations.
[03:53] <cc11rocks> Thank you :)
[07:07] <dholbach> good morning
[07:14] <didrocks> hey dholbach :)
[07:14] <dholbach> salut didrocks
[07:34] <sivang> anbyody knows florian's email? the guy who does qml ?
[07:39] <pitti> sivang: https://launchpad.net/~fboucault :)
[07:42] <sivang> pitti: yep, thanks :)
[07:42] <sivang> pitti: how are things , long time ..
[07:43] <pitti> sivang: quite well, thanks! and yourself?
[07:43] <sivang> pitti: doing quite well as well, following with interest Ubuntu / Linaro and Canonical's use of Qt.
[08:05] <jamespage> cjwatson, merge away!
[08:06] <cjwatson> jamespage: thanks
[08:10] <cjwatson> hm - actually, it might be a sync
[08:11] <cjwatson> I'll do some test-builds to check
[08:11] <cjwatson> Or I would if porter-armhf weren't apparently down.  Is there a usable armhf porter box somewhere?
[08:15] <cjwatson> Oh, but Adam's argument in the Debian bug that it's daft to use a substring match to detect if you're on an architecture where substring matching is broken is kind of compelling
[08:17] <pitti> cjwatson: I can do a test build of something on my Panda board, if you need me (or give you ssh on it)
[08:19] <cjwatson> I've decided against for now, but thanks
[08:21]  * sivang has a Pi
[08:29]  * tsdgeos is confused his public bug was marked as duplicate of a private one 
[08:30] <tsdgeos> how am i supposed to verify the duplicate status is correct? :D
[08:30] <cjwatson> Sounds unintentional.  Contact whoever duplicated it and ask them.
[08:30] <tsdgeos> i can't :D
[08:30] <tsdgeos> it's a bot ;)
[08:30] <tjaalton> tsdgeos: what was your bug
[08:31] <tjaalton> bug #
[08:31] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1046187
[08:32] <tsdgeos> see ubottu agrees with me this shouldn't happen :D
[08:33] <tjaalton> don't see why the other bug should be privat
[08:33] <tjaalton> e
[08:34] <iulian> That's a bit strange. I guess the bot needs to be taught not to do this again.
[08:37] <tsdgeos> tjaalton: thanks for making it public
[09:00] <tsdgeos> anyone else getting bzr qdiff on an dir without changes corrupting unity/compiz ?
[09:36] <pitti> tseliot: hey Alberto, how are you?
[09:44] <tseliot> pitti: hey Martin, I'm fine, thanks. You?
[09:47] <pitti> tseliot: I'm fine, thanks!
[09:47] <pitti> tseliot: I wondered if you knew whether ubuntu-drivers-common needs any change/fix for bug 1026518?
[09:48] <pitti> AFAICS this should be a matter of packaging the driver only, but I'd rather get your confirmation before I invalidate it
[09:56] <tseliot> pitti: I don't think we'll ever have that package in Quantal or higher
[09:56] <pitti> tseliot: ah, ok; so it's moot either way; thanks!
[09:57] <tseliot> pitti: ;)
[10:27] <dholbach> can somebody please reject https://code.launchpad.net/~bmanojkumar/ubuntu/quantal/bygfoot/typo-fix/+merge/122384?
[10:28] <pitti> <jedi wave> gone!
[10:28] <pitti> dholbach: ^
[10:29] <dholbach> thanks
[10:31] <iulian> Hah. Nice move.
[10:41] <ikepanhc> @pilot out
[11:28] <cjwatson> Ooh ooh they added a GDB stub to GRUB
[11:29] <cjwatson> Fantastic, that might make serial debugging moderately fun
[11:39] <BenC__> Laney: I've kicked off all the rebuilds pre-depending on cryptocipher. What's the deal with haskell-{gtk,webkit,pango}? Are you doing rebuilds of those?
[11:39] <Laney> BenC__: what's the problem there?
[11:39] <Laney> I don't see them on the tracker page
[11:40] <BenC> Laney: things like hbro, the builds logs show it can't install those packages (bad deps)
[11:40] <Laney> oh, so they were probably bad when that build was tried
[11:40] <Laney> should be OK now if the tracker doesn't show them as being bad
[11:41] <Laney> (in other words, please do a test build and if it works then give-back)
[11:41] <BenC> Ok
[11:41] <Laney> we should remove the OODs on armel/hf
[11:44] <mpt_> dpm, have you seen <http://www.reddit.com/r/Ubuntu/comments/zdyrh/i_want_to_add_marathi_language_translations_to/>?
[11:45] <dpm> hi mpt, I hadn't seen it, but the poster has just sent me an e-mail. Thanks for the heads up!
[11:58] <mdeslaur> @pilot in
[12:01] <BenC> Laney: haskell-haddock looks like it needs an actual rebuild…want me to upload?
[12:03] <Laney> BenC: sure, feel free
[12:03] <Laney> -dpkg needs looking at too
[12:05] <Laney> BenC: and likely haskell-hint can have its arch restrictions relaxed (could you test build that on ppc?)
[12:05] <BenC> Sure thing
[12:09] <sabdfl> hi folks, who's the best person to speak with about apparmor config for bind?
[12:10] <BenC> sabdfl: Hey
[12:10] <BenC> Laney: Looks like ghc-mtl needs rebuild too, is that safe?
[12:11] <sabdfl> hi benc
[12:11] <mdeslaur> sabdfl: jdstrand or jjohansen
[12:11] <Laney> BenC: no choice, if it's uninstallable it must be done
[12:11] <Laney> i'm looking at silently and ghc-syb-utils right now
[12:12] <Laney> woe is ghc's random changing of ABI hashes; at least it's relatively small
[12:13] <BenC> Laney: ok, so I've uploaded haddock, gtk-mtl and haskell-dpkg
[12:13] <Laney> BenC: great. My only concern is that haskell-dpkg possibly should have been re-merged from Debian instead
[12:13] <BenC> Laney: Going to do a local build of ghc-mtl (*ghc-mtl above) to test hint build on ppc
[12:14] <Laney> to be updated to cope with the interface changes that were introduced vs. our early dpkg with MA
[12:14] <BenC> Laney: Ah, well, on that one I didn't do a *buildX, I left it *ubuntuX
[12:14] <Laney> probably it can just be synced
[12:16] <Laney> BenC: iulian is looking at that one, so no worries
[12:16] <sabdfl> ah, found what i was looking for, thank you guys
[12:22] <BenC> Laney: I did a give-back for clientsession on ppc that should kick all of the yesod related dep-waits
[12:22] <BenC> That should clear out most of the ppc stuff
[12:26] <bdrung> dholbach: should packaging-dev recommend ubuntu-packaging-guide or ubuntu-packaging-guide-html?
[12:27] <BenC> Laney: any idea why haskell-type-level is only built on x86 and the control file says arch-any? is there a build override for it?
[12:28] <cjwatson> BenC: Yep, it's in Packages-arch-specific
[12:28] <cjwatson> Ah, but not in Debian
[12:29] <cjwatson> Let me merge that ...
[12:29] <cjwatson> Oh, Laney already did
[12:29] <cjwatson> BenC: Should sort itself out next time it's uploaded
[12:29] <BenC> Same with haskell-syb-with-class
[12:29] <BenC> cjwatson: So if I do a build-only upload, it will get built now?
[12:30] <cjwatson> Yeah
[12:30] <BenC> Thanks
[12:30] <cjwatson> And likewise for haskell-syb-with-class
[12:30] <cjwatson> And haskell-debian (if that's in that state too)
[12:30] <BenC> cjwatson: Any quick way to check haskell-* in general on that list?
[12:30] <cjwatson> lp:~ubuntu-core-dev/packages-arch-specific/ubuntu
[12:30] <BenC> I'm not sure if it's annotated for anything related to ghci, but powerpc at least has ghci now
[12:31] <cjwatson> Laney removed haskell-* from it in r155
[12:31] <BenC> Ah, thanks
[12:33] <BenC> Laney: I did uploads of syb-with-class and type-level to get non-x86 builds going
[12:33] <BenC> That should kick in a few more dep-waits
[12:34] <BenC> I'll let things settle till tomorrow
[12:39] <iulian> BenC: I've rejected -dpkg and sync'd it instead.
[12:39] <BenC> iulian: I saw, thanks
[12:42] <jdstrand> pitti: done
[12:42] <jdstrand> bdmurray: I committed your change to apport too
[12:43] <pitti> jdstrand: thanks; I'll commit that to trunk, too
[12:43] <jdstrand> cool, thanks
[12:43] <pitti> jdstrand: hm, shouldn't it export the newly set PATH as well?
[12:44] <jdstrand> that is a good question
[12:44]  * jdstrand checks
[12:49] <jdstrand> pitti: it doesn't seem so, but I am reading. I think I may want an additional change anyway
[13:19] <dholbach> bdrung, ubuntu-packaging-guide should be good enough
[13:19]  * dholbach hugs mdeslaur
[13:20]  * mdeslaur hugs dholbach back
[13:27] <iulian> dholbach,bdrung: What about Suggests instead of Recommends? Do we really want to pull in the tex* packages when we install packaging-dev?
[13:27] <dholbach> iulian, tex* packages are build-depends, not depends
[13:28] <iulian> Oh, right.
[13:30] <dholbach> :)
[13:31] <iulian> dholbach: Yea, you'd have to ignore me from time to time, especially when I say stupid things like this. :)
[13:31] <dholbach> not going to happen :)
[13:31]  * dholbach hugs iulian
[13:32]  * iulian hugs dholbach back.
[13:44] <mterry> slangasek, do you know the answer to tedg's question about selinux at the end of bug 1039636?
[13:51] <bdrung> dholbach: ok, done. packaging-dev 0.5 is uploading.
[13:51] <dholbach> perfect!
[13:51] <dholbach> thanks a bunch
[13:52] <bdrung> dholbach: yw. now to the plan of having the packaging guide in Debian. who should be the maintainer and where will the source branch be?
[13:53] <dholbach> lp:ubuntu-packaging-guide - up until now it was just "Ubuntu Developers <ubuntu-devel-discuss@...>"
[13:53] <jdstrand> pitti: ok, updated. I am using export just to be sure, and also unsetting ENV and CDPATH, also to be sure
[13:55] <bdrung> dholbach: how about using http://qa.debian.org/developer.php?login=ubuntu-dev-team@lists.alioth.debian.org as maintainer?
[13:55] <dholbach> bdrung, that'd be perfect
[13:55] <bdrung> this is more specific than just ubuntu-devel-discuss
[14:08] <bdrung> dholbach: http://paste.ubuntu.com/1187298/
[14:09] <dholbach> perfect
[14:11] <bdrung> dholbach: http://paste.ubuntu.com/1187303/
[14:11] <bdrung> i should save the changed file.
[14:11] <bdrung> dholbach: http://paste.ubuntu.com/1187304/
[14:12] <dholbach> great, all Is dotted and Ts crossed :)
[14:15] <bdrung> dholbach: committed. should i upload the current revision to debian as version 0.2.3?
[14:15] <dholbach> bdrung, it'd be nice if we could get in the 'bug fixing example' article still
[14:16] <dholbach> I made the changes you asked for in the MP
[14:16] <bdrung> dholbach: okay. just ping me once it is ready for upload.
[14:17] <bdrung> dholbach: i will look at the MP later.
[14:17]  * dholbach hugs bdrung
[14:17] <dholbach> thanks a bunch
[14:38] <slangasek> mterry, supporting selinux for this service is definitely a "should" rather than a "must"
[15:07] <mterry> slangasek, OK, so you're fine with it is as in terms of MIR?
[15:08] <slangasek> mterry: yes.  would you mind filing a bug about the missing selinux handling?
[15:08] <mterry> slangasek, sure
[15:21] <Quintasan> mhall119: ping
[15:22] <mhall119> Quintasan: pong
[15:23] <Quintasan> mhall119: Do you happen to know if all sponsorship requests have been answered already?
[15:24] <mhall119> Quintasan: they've been mailed, but it seems a lot of them have been flagged as spam
[15:25] <mhall119> some going into spam folders, some never reaching their destination
[15:25] <Quintasan> mhall119: I think I belong to the latter, nothing in spam and nothing in inbox either.
[15:41] <Quintasan> mhall119: Should I wait for it to get sorted out or email Marianne?
[15:42] <mhall119> Quintasan: I'd wait, she's working on sorting it out
[15:42] <Quintasan> Okay
[15:42]  * Quintasan stocks on patience
[15:50] <tsdgeos> seb128: should https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1018896 be marked as Fix Released in "nautilus (Ubuntu)" too?
[15:51] <seb128> tsdgeos, likely set to invalid for nautilus
[15:51] <seb128> since it was a gtk issue
[15:52] <tsdgeos> seb128: ok, want me to do it?
[16:30] <mdeslaur> @pilot out
[16:52] <herton> @pilot in
[16:57] <smoser> i'm interested in hearing ideas on https://bugs.launchpad.net/ubuntu/+source/hostname/+bug/1046405
[17:03] <tkamppeter> slangasek, hi
[17:08] <achiang> herton: hi, was wondering if you could take a look at #1046102
[17:09] <herton> achiang, sorry, I can only look into kernel bugs
[17:09] <achiang> herton: oh, ok. thanks.
[17:11] <micahg> achiang: looking
[17:11] <achiang> micahg: thanks
[17:23] <micahg> achiang: is it critical for beta 1?
[17:24] <achiang> micahg: upstream would like very much to see it in quantal as it fixes quite a bunch of bugs and enables new hardware. i don't know how that matches up with "critical for beta1" though... if we miss beta1, can it go in later?
[17:24] <smoser> cjwatson, or slangasek would you have comments on my 'hostname' suggestion above?
[17:24] <micahg> achiang: yeah, just not sure if it needs an FFe or not and would prefer not to bother the release team with it until after beta 1
[17:25] <achiang> micahg: as long as it gets into the final release, i'm ok with it. :)
[17:26] <slangasek> smoser: adds complexity, will slow down the boot for all users, and I don't understand why you would have a shared read-only filesystem for multiple netbooted systems?
[17:26] <achiang> micahg: i can fill out more paperwork if needed, but unsure what my required next steps are
[17:26] <smoser> its readonly iscsi root.
[17:26] <slangasek> ok, but I don't understand why
[17:26] <slangasek> why would someone do that?
[17:26] <slangasek> tkamppeter: hi
[17:27] <smoser> its an "ephemeral boot environment" .  a way to deliver a working environment to a node without modifying disk content (or making assumption of the contents).
[17:27] <smoser> it uses overlayfs to write delta elsewhere (we're just wrigint to tmpfs)
[17:27] <smoser> and i disagree with "slow down boot".
[17:28] <slangasek> er
[17:28] <slangasek> it does slow down boot
[17:28] <slangasek> you're adding an extra shell invocation
[17:28] <smoser> for the cost of my 'read < /proc/cmdline' i will go find you 6 different forks that will take 1000s of times longer.
[17:28] <slangasek> every one of which contributes to slowing down the boot; this is part of why boot speed has been regressing over time
[17:29] <slangasek> no, the fork you've added here *is* the cost
[17:29] <slangasek> I don't think this belongs in the stock system
[17:29] <smoser> this is fair. it does add a fork.
[17:30] <smoser> i really dont think boot speed alone is reason to nak it.
[17:30] <smoser> honestly, i assure you i can probably remove 5 forks in the next 30 minutes if you want me to.
[17:31] <slangasek> When you're proposing a change to the base system, it is.  There should be other ways to implement this without modifying the common path - a separate package installed only in the ephemeral environment?
[17:32] <smoser> well, yes. and we could just write another job that runs on stopped hostname (or stopping or something).
[17:32] <slangasek> that would IMHO be better
[17:40] <tkamppeter> slangasek, it is about your invitation. Do I need a Google+ account for it? And who at Canonical is supposed to have a Panda board, I do not have one.
[17:42] <slangasek> tkamppeter: you need a G+ account to participate in the live hangout, but your attendance is certainly not required (and the video will be posted afterwards on youtube for all to see).  A number of Pandas have been distributed to the Desktop team, I don't know exactly who has one or doesn't so I just invited a bunch of people
[17:44] <smoser> thanks for the input, slangasek . i dont disagree, but i really, *really* dont think boot speed alone is reason.
[17:45] <smoser> as a gesture of good will http://paste.ubuntu.com/1187592/
[17:45] <smoser> theres 1 removal of a fork.
[17:45] <tkamppeter> slangasek, I did not get one, probably they got distributed in the short time when I got moved to Product Strategy.
[17:46] <smoser> http://paste.ubuntu.com/1187594/ and theres a benchmark showing my path is significantly faster.
[17:49] <smoser> thanks.
[17:50] <slangasek> smoser: I appreciate the help with optimizing some of the other cruft, I'll see about getting that one into quantal.  But we are sufficiently far off the mark on boot speed that I am still going to push back on changes that slow down the common path
[17:50] <smoser> no worries.
[17:51] <smoser> i agree, i can sufficiently do it outside of 'core' so it makes sense to do it there.
[17:52] <smoser> slangasek, fwiw, if you're wanting to save forks, the initramfs is chock FULL of them.
[17:52] <slangasek> smoser: well, I want us to be able to eliminate the initramfs entirely for the common path ;)
[17:53] <slangasek> but the kernel team has not been accomodating!
[17:53] <smoser> i thought you said quantal
[17:53] <smoser> :)
[17:53] <smoser> and yeah, i knew that was a goal.
[18:16] <smoser> slangasek, so, i'd appreciate your thoughts on another issue i have.
[18:16] <smoser> its related to bug 1031065 (or at least related to our 'start networking' hack that was added).
[18:18] <smoser> rbasak is hitting (consistently) a condition where cloud-init-nonet never gets stopped. as if it blocking (start on mounted MOUNTPOINT=/) is stopping the interface from coming up.
[18:19] <slangasek> smoser: so wrt that bug, I asked you a couple weeks back for some verbose upstart syslog output, which you said you were going to get me "in a bit" :)
[18:19] <smoser> i can get that to you now if you'd like. but i was confused by "syslog" comment.
[18:19] <smoser> what did you mean by syslog
[18:19] <slangasek> smoser: upstart logs to kmsg, which is supposed to wind up in syslog
[18:20] <slangasek> (in practice, this seems to be broken in quantal for reasons I don't yet understand)
[18:20] <smoser> ok. well i'll get that to you reall y quick.
[18:20] <slangasek> /var/log/kern.log, if it works; dmesg output, if it doesn't
[18:20] <smoser> hm..
[18:20] <smoser> well, dmesg wont have init output
[18:20] <smoser> which is what you really need and kern.log wont have it either (since htis is lxc)
[18:21] <slangasek> why won't dmesg have init output?
[18:21] <smoser> https://pastebin.canonical.com/73830/ is rbasak's collection on his arm system.
[18:21] <smoser> the lxc containe'rs init output would find its way into dmesg?
[18:21] <slangasek> I would hope that it would go somewhere :)
[18:22] <slangasek> it's supposed to be logged with kmsg
[18:22] <smoser> i ran into an issue when trying to collect init output on lxc that i raised with hallyn.  ideally it'd go to stdout and i could just log it.
[18:22] <smoser> but it seems to not.
[18:22] <smoser> anyway. i'll see what i can get.
[18:22] <slangasek> smoser: what is /dev/kmsg within the lxc container?
[18:22] <smoser> and rbasak's data there is unfortunately slightly confusing as its intermixed output.
[18:23] <smoser> i'll see what i can find slangasek
[18:23] <slangasek> if it isn't already, you can set it up to be a link to the controlling tty the same way that /dev/console is
[18:24] <slangasek> smoser: the other consideration is that I was assuming lxc init worked the same way as a chrooted init, which sounds like it's not actually the case
[18:24] <slangasek> smoser: so you probably need to pass --verbose when starting init
[18:24] <smoser> yeah, i hoped it did. it did not.
[18:24] <slangasek> smoser: oh - in any case, that pastebin looks like exactly the kind of info I was looking for (the init: lines)
[18:24] <smoser> but chrooted init ?
[18:25] <slangasek> in a chroot you don't actually run a separate init, and jobs just talk to pid 1
[18:25] <slangasek> and pid 1 keeps track of whether a job is in a chroot or not
[18:26] <stgraber> slangasek: lxc containers work like "regular" Ubuntu systems, so they have /sbin/init running as the pid 1 of their PID namespace
[18:29] <slangasek> yep
[18:29] <slangasek> stgraber: I understand that once I thought it through :)
[18:29] <smoser> so yeah, i tried passing --verbose. but i only get output to my console that goes explicitly to /dev/console (ie, task output from cloud-init getst there).
[18:29] <slangasek> stgraber: and does /dev/kmsg get pointed somewhere useful?
[18:29] <slangasek> smoser: well, the pastebin from rbasak shows exactly the kind of information I'm looking for
[18:29] <slangasek> so... do whatever he did? :)
[18:31] <smoser> well, he got console output from a real system.
[18:31] <smoser> ie, serial console output
[18:31] <smoser> i dont havaccess to that.
[18:34] <slangasek> ok
[18:36] <slangasek> smoser: so, fixing /dev/kmsg within the container should do the trick
[18:37] <smoser> how would i fix? youhave a solution for that?
[18:37] <slangasek> smoser: "make it match /dev/console"
[18:38] <slangasek> I know /dev/console is magically pointed at the controlling tty from the host; I don't know how this is done.  But the same should be done for /dev/kmsg
[18:41] <smoser> slangsek. that was impressive.
[18:41] <smoser> ln -sf console kmsg
[18:41] <smoser> and poof! data!
[18:41] <stgraber> apparently /dev/kmsg doesn't actually exist at boot time, I seem to have containers where it's a simple text file (instead of char device), probably because something tried to directly write to it without checking whether it existed first...
[18:42] <slangasek> smoser: right, I was going to suggest that ;)
[18:42] <stgraber> hallyn: ^
[18:43] <slangasek> stgraber: current upstart calls mknod first if it doesn't exist, fwiw
[18:43] <stgraber> slangasek: how current? I checked in 12.04 containers here
[18:44] <stgraber> (though maybe something created /dev/kmsg as a file before upstart had a chance to mknod it)
[18:44] <slangasek> stgraber: upstart 1.5-0ubuntu8 - this is a fix that jodh is planning to SRU to precise soon-ish
[18:44] <smoser> http://paste.ubuntu.com/1187658/
[18:44] <stgraber> ah, ok, well once that lands, and if /dev/kmsg is allowed in the container, it's going to get in the kernel log buffer
[18:45] <stgraber> problem is that at this point it's shared between the host and containers (until we have a syslog namespace)
[18:46] <slangasek> smoser: great :) so is this one with the original cloud-init-nonet job, or the one modified to not call networking start?
[18:47] <hallyn> stgraber: still waiting for syslog ns to be bumped in priority :)
[18:48] <smoser> that is a precise container (from latest daily build) with 'start networking' commented out
[18:48] <smoser> (showing the hang)
[18:48] <slangasek> smoser: ok, great
[18:50] <smoser> slangasek, http://paste.ubuntu.com/1187672/ is with mountall --verbose
[18:52] <smoser> yeah, and that shows the issue there i think
[18:52] <smoser>  /run gets mounted after cloud-init-nonet starts
[18:53] <smoser> meaning virtual-filesystems can't be emitted
[18:53] <smoser> meaning udev cant start
[18:53] <smoser> this is a different problem then rbasak saw. as he does get virtual-filesystems emitted before cloud-init
[18:53] <smoser> so maybe there goes my hopes of it being the same root cause.
[18:54] <bryce> slangasek, ogasawara, hey question came up from NVIDIA...  if a user grabs the 12.04.3 ISO and installs it, is there any option or text in the installer that mentions they have the option of installing the 12.04.0 iso as an alternative?  IOW how are we messaging the existence of 12.04.0 to end users?
[18:55] <slangasek> bryce: I would expect this to only be messaged via the web page documentation, not on the image itself; and why does it make me nervous that nvidia cares about this? :)
[18:58] <bryce> slangasek, web page documentation == release notes?  or the cdimage site? or...?
[18:58] <ogasawara> bryce: there were discussions about providing an option on the DVD's to install with the original 12.04 stack, but we did not reach a decision there yet.  otherwise I assumed it was as slangasek noted above.
[18:58] <slangasek> bryce: release notes + help.u.c, I think
[18:59] <bryce> ok
[19:02] <bryce> hmm, not seeing mention of it on help.u.c.  http://www.ubuntu.com/download/desktop looks like it ought to link to it but not finding mention or link there either
[19:03] <slangasek> bryce: right, I don't think there's anything there *currently*; we also don't have a point release out yet that includes a backported stack so there's no actual need
[19:03] <slangasek> bryce: also, I imagine we should be messaging 12.04.1 rather than 12.04.0
[19:03] <bryce> ok
[19:03] <bryce> slangasek, ok, so it's in the plans for including those links and/or messaging?  That should suffice for this.
[19:04] <slangasek> ogasawara: can that go in the plan then? :)
[19:06] <bryce> ogasawara, thanks.  Might be worth stimulating that discussion again.
[19:07] <ogasawara> bryce, slangasek: I post this to the thread I sent to ubuntu-devel
[19:09] <bryce> ogasawara, thanks
[19:51] <smoser> slangasek, so i'm remembering more and more bits and pieces of this.
[19:52] <smoser> the issue i ran into when using overlayfs was that i wasn't mounting / as 'ro'.
[19:52] <smoser> which cauased the 'mounted MOUNTPOINT=/' to occur before /run was mounted
[19:52] <smoser> which is the same scenario as my lxc i think
[19:56] <smoser> but this is very much not the case that rbasak was running into (from ihis log output).
[19:57] <slangasek> smoser: hmm, I'm puzzled as to the stated cause of / being mounted before /run; I'll have to look at the mountall code
[19:58] <smoser> slangasek, well, that is admittedly "my fault"
[19:58] <smoser> here.
[19:59] <smoser> see cloud-init upstart jobs
[19:59] <smoser> /usr/share/lxc/hooks/mountcgroups
[19:59] <smoser> err...
[19:59] <smoser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/cloud-init/quantal/files/head:/upstart/
[19:59] <slangasek> smoser: ah, it's because mountall first scans for all filesystems that don't require further processing and reports them mounted
[20:00] <smoser> cloud-init-nonet runs on 'mounted MOUNTPOINT=/ and stopped cloud-init-local' and mounted MOUNTPOINT=/ blocks
[20:00] <smoser> which stops the /run from ever being ounted, so udev cant start
[20:00] <slangasek> ah
[20:00] <smoser> so networking can't come up
[20:01] <slangasek> so, why do you want mounted MOUNTPOINT=/ there?
[20:01] <smoser> because i want to block boot
[20:01] <slangasek> ah right
[20:01] <smoser> in order to allow people the earliest entry point into the boot
[20:01] <smoser> in "normal boot", /run gets mounted before / gets mounted RW
[20:02] <slangasek> and if mounted MOUNTPOINT=/ happened after /run was mounted, would that solve your problem?
[20:02] <slangasek> (and remove the need for manually starting networking?)
[20:02] <smoser> i think so. i was trying to just see if i could get lxc to do that, but didn't see how.
[20:02] <smoser> i would still have rbasaks' problem, which i think is not the same.
[20:03] <smoser> because his log shows 'virtual-filesystems' running before cloud-init (which would mean /run was mounted)
[20:03] <slangasek> if / were mounted ro initially, that would trigger the correct ordering
[20:04] <smoser> it *does* trigger that, but that might just be happenstance.
[20:04] <slangasek> no, it's not
[20:04] <smoser> yeah, with what you ssaid above.
[20:04] <slangasek> I'm suggesting that as a solution for the lxc case - are you saying you can't get it to be mounted ro for lxc?
[20:04] <smoser> hallyn, ^
[20:04] <smoser> that is what i was asking him.
[20:05] <slangasek> ok
[20:05] <smoser> honestly, it seems to me like if you're invoking /sbin/init its a bug to by default mount rw
[20:05] <smoser> at least possibly
[20:08] <hallyn> smoser: i wouldn't want to count on initramfs always leaving / ro
[20:08] <hallyn> especially in fancy raid situations
[20:08] <hallyn> but if jodh says it's so, i'll accept it as a bug (in ubuntu, probably not in upstream lxc)
[20:08] <slangasek> hallyn: it darn well better leave it ro
[20:08] <slangasek> (the initramfs)
[20:08] <slangasek> because fsck is only run post-pivot
[20:09] <slangasek> so yes, this is something we rely on
[20:09] <hallyn> hm
[20:09] <smoser> well, yeah, and if the kernel cmdline says 'ro' then it a bug to not be 'ro'
[20:09] <hallyn> fsck, what's that? :)
[20:09]  * hallyn makes a note in his journal
[20:09] <smoser> but, hallyn, lxc is a special case here, because nothing told it 'ro'
[20:10] <smoser> *and* the case where you run something other than /sbin/init,  you most likely dont want 'ro'
[20:10] <hallyn> right, and fsck better detect that the fs is mounted and not run.
[20:10] <hallyn> in most cases, / is just a dir on the host's rootfs,
[20:10] <hallyn> so actually it can't be ro
[20:10] <smoser> you can mount bind ro
[20:10] <slangasek> sure, fsck will detect the case that the fs is mounted rw, but that doesn't help the fact that we actually want the root fs to be fscked ;)
[20:10] <hallyn> smoser: sort of
[20:11] <smoser> real men 'ln /sbin/fsck /bin/true'
[20:11] <hallyn> slangasek: but you don't :)  not when / is just a subdir of /var on the host
[20:11] <stgraber> is there any reason to boot with / ro other than fsck? because on lxc, the container root is on an fs that's already been checked when the host booted
[20:11] <slangasek> hallyn: I'm talking about the initramfs case
[20:12] <slangasek> on real hardware, we have a guarantee that the rootfs is mounted ro when upstart starts
[20:12] <hallyn> slangasek: oh right
[20:12] <hallyn> yup
[20:12] <smoser> hallyn, hm..
[20:12] <slangasek> lxc deviates from this, so the question is if we can change that or if we need to change mountall
[20:12] <smoser> i guess the other thing i could do ofr this is tell lxc to mount /run for me
[20:12] <smoser> before it calls /sbin/init
[20:12] <smoser> right?
[20:12] <slangasek> note that I don't actually care if it's mounted ro, I just care that mountall *sees* that it's ro ;)
[20:13] <slangasek> smoser: nope
[20:13] <smoser> no?
[20:13] <slangasek> smoser: because udev needs 'virtual-filesystems' emitted, which is a whole bunch of filesystems, not just /run
[20:13] <smoser> true.
[20:13] <smoser> so s/run/all-of-those/
[20:13] <smoser> but... yeah.
[20:13] <slangasek> and there's a change to the set of those filesystems staged in the unapproved queue.  not maintainable.
[20:14] <smoser> well, it could be maintainble.
[20:14] <smoser> the change you speak of would just have to be tied to a change in lxc that was release aware
[20:14] <smoser> but , yeah. suck.
[20:15] <hallyn> ok wel lif we're just trying to fool mountall, then yes we could remount the container / ro (two-step process, but you don't care about that)
[20:15] <slangasek> that would probably help
[20:15] <slangasek> though I actually haven't worked out yet that the virtual filesystems are guaranteed to be mounted before /
[20:25] <slangasek> smoser: so I believe there's a potential race condition for whether / gets mounted before or after virtual-filesystems is emitted, even with this change
[20:26] <slangasek> smoser: if you haven't run into it yet, then all to the good; but I mention it in case that is happening somewhere
[20:26] <smoser> its not that i know of.
[20:27] <smoser> i think imight have hit it once when /dev/pts didn't exist... or something like that.
[20:27] <smoser> yeah, if root didn't hae a mount point in it that a virtual mount needed
[20:27] <smoser> i guess if root didn't have /dev
[20:27] <smoser> but thats somewhat busted anyway
[20:28] <slangasek> well, root waits for /dev to be mounted, but it doesn't wait for /proc /sys /run /proc/sys/fs/binfmt_misc /sys/fs/fuse/connections /sys/kernel/debug /sys/kernel/security /dev/pts /tmp /run/lock /run/shm, any of whom will block the virtual-filesystems signal
[20:28] <slangasek> I wonder if fixing bug #643289 would make this better or worse
[20:30] <slangasek> if done right, that would allow the virtual filesystems, which do not block on /, to continue being mounted even while the mounted MOUNTPOINT=/ hook is blocked
[20:31] <slangasek> so I *think* that makes it better
[20:31] <slangasek> indeed, it might make it irrelevant whether / is mounted ro in lxc
[20:32] <smoser> slangasek, well, yeah, sort of better.
[20:33] <smoser> but that would sort of viorlate my reading of 'mounted'
[20:33] <slangasek> smoser: note that the change in question would not cause the 'filesystems' event to be emitted before the 'mounted' hook returns
[20:33] <smoser> mountall(8) will wait for all services started by this event to be running,  all tasks started by this event to have finished and all jobs stopped by this event to be stopped before continuing with other filesystems.
[20:33] <slangasek> yeah, I know that's what it says
[20:33] <slangasek> I'm suggesting this is the wrong thing to do ;)
[20:34] <slangasek> I think it should still continue in parallel with *unrelated* filesysetms
[20:34] <slangasek> just not with any which depend on the current one
[20:35] <smoser> well, that woudl defeat a lot of my intent
[20:35] <slangasek> not really
[20:35] <slangasek> because the only filesystems that are unrelated to the rootfs, in mountall's view, are the virtual filesystems
[20:35] <smoser> yeah. and not much starts on virtual-filesystesm alone
[20:36] <slangasek> except things like udev, which is exactly what we're trying to unblock ;)
[20:36] <smoser> yeah
[20:36] <smoser> so yeah, that would fix this case.
[20:36] <smoser> so i should update this bug with our understanding of it
[20:36] <smoser> as i failed to do that before, and that resulted in much lost time.
[20:37] <slangasek> ok, great
[20:37] <smoser> and while i do that, you can come up with a solution :)
[20:37] <slangasek> well, there's a proposed patch to mountall that's been sitting for a while
[20:37] <slangasek> I'll put it on my queue to look at, but I don't think I'm going to get to it this week, and jodh is on vacation
[20:41] <smoser> slangasek, yeah, thanks for your help
[20:41] <melodie> hi
[20:43] <melodie> I try to use the "LiveCDFromScratch" howto, and I would like to get some help to understand or improve the way to use some parts of that page, and I don't know where would a chan with people likely to have the knowledge. Anyone here can give me an advice ? Here is the page and I am at about the middle : https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
[20:49] <herton> @pilot out
[21:10] <smoser> slangasek, it would seem to me to be "early enough" (and even ideal) if i could run when virtual filesystems were available and / was mounted.
[21:10] <smoser> i dont think there is any way to block at such a state though.
[21:10] <slangasek> smoser: there indeed is not
[21:13] <slangasek> stokachu: I don't think I understand https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/977959/comments/6 and https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/977959/comments/7.  The debdiff you provided doesn't include any changes around dlopen(), which libgnome in fact doesn't use.  But I'm also not sure what "gnome-program" refers to here?
[22:19] <barry> cjwatson: correct me if i'm wrong, but i believe software-properties is now py3
[22:22] <melodie> hi again
[22:23] <melodie> is there a chan where I could ask help specifically with some parts of this page ? https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
[22:28] <cjwatson> barry: believe so
[22:29] <barry> cjwatson: awesome, that's what i though.  spreadsheet updated
[22:29] <barry> cjwatson: thx
[22:30] <cjwatson> barry: buggy #! I notice, though.  must fix that.
[22:30] <barry> cjwatson: /usr/bin/env lines?
[22:31] <cjwatson> Was more thinking of #! /usr/bin/python3.2 at the top of add-apt-repository
[22:31] <cjwatson> Likely needs the same pile of stuff I worked out for germinate to avoid that
[22:31] <barry> cjwatson: ah, yes.  /usr/bin/python3 i suppose would be better ;)
[22:32] <cjwatson> Indeed
[22:46] <barry> jdstrand: ufw is python3 now?
[22:54] <slangasek> barry: apt-cache show ufw | grep python
[22:54] <slangasek> :)
[22:55] <barry> slangasek: yep, just looking for mindless confirmation :)
[23:32] <melodie> gn
[23:42] <slangasek> barry: hey, did you ever get a resolution to your vmvga issue in quantal?
[23:43] <barry> slangasek: nope.  we've had some traffic on the issue today.  i have a workaround, but no fix
[23:43] <slangasek> drat
[23:43] <barry> slangasek: or really, understanding of what's wrong
[23:43] <barry> yeah
[23:44] <slangasek> barry: I see that qemu actually implements vmvga as one of the options; I was vaguely hoping that this would prove to work with guest acceleration :)
[23:44] <RAOF> barry: That's the llvmpipe-doesn't-kick-in-under virtualbox, rigth?
[23:44] <slangasek> but we can't very well test it until we have a driver
[23:44] <slangasek> RAOF: vmware, not vbox
[23:44] <barry> RAOF: actually, it's a kernel module no longer getting loaded by default
[23:45]  * RAOF waves hands. Some sort of virtualisation thingy!
[23:45] <slangasek> RAOF: also, I'm pretty sure llvmpipe does kick in correctly everywhere, and just fails to be up to the task of lifting unity off the floor?
[23:46] <RAOF> slangasek: Apparently not; I got assigned a bug last night about llvmpipe not kicking in in some virtualisation thingy.
[23:46] <barry> yep. llvmpipe does work better now than the day i filed the bug (but still painfully slow on fusion)
[23:46] <slangasek> RAOF: hmmm, bug #?
[23:46]  * RAOF wishes evolution wasn't in the process of slowly throttling itself to death
[23:48] <slangasek> :-)
[23:48] <RAOF> Hah. It's finished. Now there's an apport popup instead :)
[23:48] <RAOF> slangasek: Bug #1039155
[23:50] <RAOF> Urgh. I've just looked at that.
[23:52] <slangasek> RAOF: isn't https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1039155/comments/8 the real issue?  I've definitely had llvmpipe get used correctly on armhf
[23:52] <slangasek> so I suspect the problem is the user has some other GL driver that's not up to snuff
[23:52] <RAOF> Possibly.
[23:53] <RAOF> There's also the case where the user has a mesa GL driver, but it doesn't support what Unity needs; in that case we *do* need to force llvmpipe.
[23:53] <slangasek> how do you do that effectively?
[23:53] <slangasek> since the choice of driver is an X server thing as much as a client thing...
[23:56] <RAOF> Set LIBGL_ALWAYS_SOFTWARE in Unity's environment.
[23:57] <RAOF> libGL is all client-side; it asks the X server what driver it should be loading, but it's under no compulsion to accept that.
[23:57] <slangasek> ah
[23:58] <slangasek> doesn't the server have to load /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?  does it do that automatically when a client says the magic word?
[23:59] <ion> Why should the client care about how the GL implementation renders stuff? :-( Shouldn’t the GL implementation choose between hardware acceleration and LLVM-and-CPU transparently in a perfect world?
[23:59] <RAOF> No; libGL loads swrast_dri.so (or r600_dri.so, or whatever hardware driver is appropriate)
[23:59] <RAOF> The server *also* loads a dri driver, but that's for AIGLX, which nothing uses anymore.