[01:53] <micahg> jamespage: jai-core, yeah, I figure it could be ported, I was wondering if there were an easier way to move forward that porting the code (and this is a sun library that hasn't been updated in 5 years, so I figure there might not be hope)
[02:20] <xnox> @pilot in
[02:29] <stgraber> xnox: seriously? :)
[02:30] <xnox> well... i was pinged to sponsor a few things.... and it's my time to patch pilot..... (my phone buzzed a couple of hours ago)
[02:31] <stgraber> so you went with the night shift then ;)
[03:17] <xnox> I bet everything I patch-pilot will end up tied up in the beta1 block.
[03:54] <xnox> @pilot out
[03:54]  * xnox nap time. will be back for some awesome ureadahead patch merging =)
[03:54] <psusi> xnox, eh?
[03:55] <psusi> there's some ureadahead love somewhere?
[03:55] <xnox> *two* merge proposals https://code.launchpad.net/ubuntu/raring/+source/ureadahead
[03:55]  * psusi needs to dust off his ureadahead love and see if it's still needing updated if possible and merged
[03:56] <psusi> I had been playing with some ureadahead optimizations in conjuunction with e2defrag to pack the files ureadahead wants to preload all in order at the start of the disk... but have been thinking we might want to replace ureadahead with e4rat.. need to do some evauluation
[03:59] <ScottK> xnox: You can still upload it.
[04:16] <ScottK> xnox: Bug 1123186 might be another good one to look into.  Gregor Herman is someone it would nice to have feel good about interacting with Ubuntu.
[04:46] <slangasek> xnox: could you please commit your pam changes to the bzr branch?
[04:47] <slangasek> @pilot in
[05:41] <pitti> Good morning
[05:42] <ion> that
[05:42] <pitti> ScottK, slangasek: NB that lightdm also doesn't support logind in a particular way, it just uses the PAM module
[05:52] <ScottK> pitti: OK. That was from one of the upstream KDE developers that's worked on the KDE greeter, so I didn't know.
[05:54] <pitti> ScottK, slangasek: FYI, I followed up to bug 1153224 with some clarifications
[05:54] <pitti> ScottK: well, the PAM module is sufficient for creating sesssions; it's of course very likely that it has knobs for shutdown/reboot, which do need to talk to CK/logind directly
[05:56] <pitti> ScottK: porting that is easy (it's more or less replacing org.freedesktop.ConsoleKit.Manager.ShutDown() with org.freedstkop.login1.PowerOff()), but also not strictly required if you keep consolekit installed
[05:56] <pitti> but indeed not zero work, if you also just want to ship one stack
[06:06] <slangasek> pitti: ack
[06:12] <slangasek> xnox: I see you commented on bug #1122120 that the patch looked fine, but left it in the sponsorship queue; did you run into a problem with it?
[06:21] <pitti> infinity: would you know, to disable a particular binary from a source package, is it enough to drop it from the binary .changes, or do I actually need to drop it from debian/control?
[06:21] <pitti> infinity: doing the latter is quite intrusive to debian/rules in the systemd case and also breaks --list-missing/--fail-missing quite badly
[06:22] <infinity> pitti: Keeping it in debian/control means it ends up in .dsc, but that might not be world-ending.  Were you thinking of just seding changes at the very end of the build?
[06:22] <infinity> pitti: That should technically work and not upset things too much.  Try it in a PPA.
[06:23] <pitti> infinity: I thought about -N'ing it from dh_<whatever calls dpkg-distaddfile>
[06:24] <pitti> dh_builddeb, I figure
[06:24] <infinity> pitti: Oh, sure.  That could also do the trick.
[06:25] <infinity> pitti: It's pretty hackish (given the incorrect .dsc), but we have dscs that are incomplete and/or overly-complete in other packages, I suspect it wouldn't be a bit deal.
[06:25] <infinity> s/bit/big/
[06:25] <pitti> infinity: it would appear similar to udebs or Arch: <specific> packages I guess
[06:25]  * infinity nods.
[06:26] <infinity> If it has a -dbg package, that will contain pointless symbols from the package you're not building.
[06:26] <infinity> But otherwise, it should more or less behave as expected.
[06:26] <pitti> no, it doesn't
[06:26] <pitti> ok, thanks; it would ease shared maintenance with Debian quite a bit, as well as keeping our --fail-missing safeguard
[06:26] <infinity> It "feels" wrong, but I appreciate the want for a small delta, if it works how you want it to in a PPA test run.
[06:27] <pitti> I'll do that
[06:28] <slangasek> @pilot out
[06:35] <Quintasan> Good morning
[07:05] <pitti> slangasek, ScottK, infinity: libudev1 transition is child's play after all; in the end there's only one package which needs a sourceful upload (lvm2), done in the PPA by cherry-picking the upstream fix for that; all others are just rebuilds
[07:09] <infinity> pitti: Sounds promising.
[07:09] <infinity> pitti: Please don't let actual children play with it.
[07:10] <pitti> I have always wanted a lipyuhdev as a child
[07:10]  * infinity is finding it rather embarassing that he can't seem to find a MicroSD card, despite owning dozens.
[07:10] <infinity> Maybe it's time to clean my desk.
[07:10] <sarnold> they _are_ tiny.
[07:10] <pitti> infinity: maybe it would be easier if they weren't so damn small
[07:11] <infinity> Yeah, exactly.
[07:11] <infinity> Maybe I'll just pull one from a phone.
[07:11]  * pitti wonders if he's the only one who finds "dpkg-deb -z1 -Zxz -Sextreme" rather naughty
[07:11] <infinity> Of course, then I need to also locade my MicroSD USB reader.
[07:12] <pitti> how about leaving it in the phone and using mass storage?
[07:12] <infinity> pitti: Is there even any point to -1e?
[07:13] <pitti> I meant spelling/reading it, not what it does :)
[07:13] <infinity> I refuse to admit to reasons why the word "extreme" may seem naughty to me.
[07:13] <pitti> (apparently these are standard dh 9 udeb options)
[07:13] <infinity> It certainly has nothing to do with any specific mail order agency I've frequented.
[07:14] <pitti> ... for purely scientific reasons, of course
[07:14] <infinity> Obviously.  For science.  I believe in hands-on experimentation.
[07:15] <infinity> Related to the first conversation, but not the second: I miss 8 inch floppy disks.
[07:18] <infinity> Hrm, not quite was I was looking for, but I just found a large cache of GBP and EUR.  Time for a vacation?
[07:32] <pitti> infinity: FYI, I used http://people.canonical.com/~pitti/tmp/systemd-patches/0009-Disable-udev-and-systemd-packages-for-Ubuntu.patch now, which seems to work quite well
[07:33] <infinity> pitti: You might want to change the dpkg-vendor call.
[07:33] <infinity> pitti: Use --derives-from instead of --query vendor.
[07:33] <pitti> can I do a boolean if with make, like if $(shell dpkg-vendor --derives-from ubuntu) ?
[07:34] <infinity> pitti: Unless we want very surprising results for people rebuilding this.
[07:35] <infinity> pitti: ifeq (Yes,$(shell dpkg --derives-from Ubuntu && echo Yes))?
[07:36]  * infinity flails.
[07:36] <pitti> ah, nice trick
[07:36] <infinity> Untested.  Pretty sure that doesn't need quoting, though.
[07:38]  * pitti runs another build
[07:38] <infinity> Err, with a -query on that.
[07:38] <infinity> -vendor even.
[07:38] <infinity> So not awake.
[07:39] <pitti> yeah, I've translated from adamsh to bash and infinipkg to dpkg
[07:39] <infinity> http://paste.ubuntu.com/5607107/
[07:39] <infinity> Hahaha.
[07:39] <infinity> Yeah, seems to DTRT.
[07:44] <pitti> http://people.canonical.com/~pitti/tmp/systemd-patches/0008-Disable-udev-and-systemd-packages-for-Ubuntu.patch works fine
[07:44] <pitti> I'll fix something else and then kick that PPAwards to see what it makes of it
[07:45] <infinity> Hrm, curious that the manpage doesn't document dpkg-vendor as being case-insensitive, but it sure appears to be.
[07:45] <dholbach> good morning
[07:47] <infinity> pitti: Given that vendor and parent in origins/* appear to be all mixed-case, I'd probably stick with Ubuntu over ubuntu since the tool doesn't document its case-insensitivity, but that's probably just me being paranoid.
[07:47] <infinity> pitti: I imagine if someone broke that at this point, people would scream, so the right thing to do is fix the manpage. :P
[07:48] <pitti> oh, I used "ubuntu" in many places by now
[07:48] <infinity> Yeah, see above.  People would scream.  One of them being you.
[07:48] <infinity> So I should probably just push a manpage fix to Debian to document the current behaviour as canonical.
[08:46] <dholbach> FourDollars, mvo just uploaded the patch :)
[08:48] <FourDollars> dholbach: Thanks a lot. :D
[10:29] <Whoopie> debfx: Hi, any timeframe when you plan to upload a new virtualbox? Or could you point to your fix for the XComposite unresolved symbol issue?
[10:34] <xnox> @pilot in
[10:34] <xnox> slangasek: simply was something I didn't feel like sponsoring at 3am ;-)
[10:37] <Whoopie> debfx: btw, for auto-loading, you could use the patch in bug report 1039157 -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039157/+attachment/3295573/+files/vbox.patch
[10:39] <ScottK> pitti: OK.  I've no objections to the systemd update/libudev1 transition.  I'm on my way out the door, so I'll leave it for another u-release member to approve in the bug.  Like slangasek or infinity.
[10:49] <pitti> ScottK: ok, thanks; that'll also require the MIR approval first
[10:51] <seb128> pitti, need to chase the MIR/security guys to get that review done, I've also an accepted FFe blocked on promotion of systemd-services ;-)
[10:52] <pitti> I would settle for a partial move to main at first for the udev libraries
[10:52] <pitti> then we can get the libudev migration out of the way
[10:52] <pitti> and it's just slightly newer code than what we have already
[10:53] <pitti> but again this needs a formal FFE first for updating systemd to 198 (that should be easy, though)
[11:09] <seb128> ev: hey
[11:09] <ev> seb128: hi
[11:10] <seb128> ev: seems like your RT59730/r284 didn't work out as it should (or I'm hitting another very similar issue)
[11:10] <seb128> ev: https://errors.ubuntu.com/?package=telepathy-glib never finish loading... here
[11:13] <ev> seb128: looking
[11:16] <seb128> ev: ok, I guess that's my error, unping
[11:17] <ev> hm? Is it working now?
[11:17] <seb128> ev: telepathy-glib provides a library so it probably has no report against its component
[11:17] <seb128> the reports probably go to the packages using the lib
[11:17] <ev> ah, it wont, yeah
[11:17] <ev> there's still a javascript error to fix here that's preventing the table from saying "no results"
[11:17] <seb128> yeah, it's the "loading..." not going away that confused me first ;-)
[11:18] <ev> :)
[11:21] <ev> fixed the javascript as lp:errors r297
[11:22] <ev> I'll try to get that deployed today
[11:23] <infinity> slangasek: Thanks for packaging heimdall-flash, BTW.  Your version was 98% less sad than the precompiled binaries on the interwebs.  (Googling various failure modes was how I even noticed it was in the archive, probably time to go mass updating a ton of CM wiki pages to say "if you're running Ubuntu, ...")
[11:23] <seb128> ev: thanks
[11:23] <ev> sure thing
[11:53] <pitti> cjwatson: wrt. "Check whether openssh needs to grow logind support, and add it if necessary", what particular magic should happen there?
[11:54] <pitti> cjwatson: if I ssh into my box, that user gets a sessio in logind, a $XDG_SESSION_ID and $XDG_RUNTIME_DIR through the PAM module
[11:54] <pitti> cjohnston: I guess that's the important bit? or is there anything else?
[11:55] <pitti> sorry cjohnston, I mean cjwatson
[11:55] <om26er> who should i contact to let know that there are quite a large number of download mirrors that are behind the main servers. like a few months behind
[12:01] <xnox> om26er: is it known? https://launchpad.net/ubuntu/+archivemirrors
[12:02] <xnox> om26er: hopefully someone in #launchpad can direct you to the right place.
[12:03] <om26er> xnox, its mentioned there but with "last update unknown"
[12:03] <om26er> xnox, i'll try  #launchpad Thanks
[12:05] <xnox> om26er: some of the mirrors listed there, are not under our control. We cannot force push update them. They are maintained by their respective owners.
[12:06] <smartboyhw> xnox, you're the patch pilot today?
[12:06] <xnox> smartboyhw: yes.
[12:06] <smartboyhw> xnox, please review https://code.launchpad.net/~smartboyhw/ubuntu/raring/blender/2.66a-3ubuntu1-merge/+merge/152894 then:P
[12:07] <xnox> smartboyhw: way too quick =) even the diff is not there yet =))))
[12:07] <smartboyhw> xnox, yep:P
[12:07] <smartboyhw> Just notification
[12:08] <smartboyhw> Hey popey
[12:08] <xnox> infinity: i'll give that qemu powerpc building a try with blender above ;-)
[12:08] <smartboyhw> xnox, /me \o/ +1
[12:10] <StevenK> smartboyhw: O HAI. If you fix the description in your Launchpad MP to include more details, I'll review it.
[12:10] <smartboyhw> StevenK, OK:)
[12:12] <infinity> smartboyhw: A 70MB diff for a merge might not always be the most clever idea ever.
[12:12] <infinity> smartboyhw: Giving people just the Ubuntu diff over the current Debian is much more manageable.
[12:12] <smartboyhw> infinity, debdiff ok
[12:13] <StevenK> infinity: "Sure, I'll review that. I'll get back to by April, 2014."
[12:13] <jpds> om26er: Do you have any particular examples?
[12:13] <infinity> smartboyhw: debdiffs are great for me, but it's xnox or StevenK you get to ask. :)
[12:13] <smartboyhw> infinity, :P
[12:14] <smartboyhw> infinity, there wasn't even a tag for it hmmm
[12:15] <infinity> In all honesty, given how simple the merge actually is (when you strip away the 70MB patch), I'd be more inclined to just do it myself than try to fuss with sponsoring, if it was me.
[12:15] <smartboyhw> infinity, I'm not Ubuntu dev or whatever.....
[12:15] <smartboyhw> infinity, ah you mean you do it
[12:15] <smartboyhw> ....
[12:15] <smartboyhw> LOL
[12:15]  * infinity is still not sure why we think merges are a good way to get people to contribute for sponsorship, since they tend to be either "so trivial that your patch isn't worth the effort" or "so complicated that I need to read it line-by-line and do it myself anyway".
[12:16] <smartboyhw> infinity, I like it though
[12:17] <infinity> smartboyhw: Yeah.  There's nothing wrong with you liking merges.  My complaint is with having non-uploading people do them for the sponsorship queue, I guess, because of the above.
[12:17] <om26er> jpds, here both Pakistan mirrors, https://launchpad.net/ubuntu/+archivemirrors and then tried the Quwait mirror, same problem as well. What worked for me was the main server but its slow
[12:17] <infinity> They're pretty much the silliest things to "sponsor", since I have to re-do it myself to verify it's correct.
[12:17] <smartboyhw> ...
[12:17] <smartboyhw> Anyway I'm not the one to decide
[12:17] <tumbleweed> infinity: I don't think anyone recommends them for new people. but somehow new people find them
[12:17]  * smartboyhw hides
[12:17] <tumbleweed> probably because they are an easy list of things to do
[12:17] <infinity> tumbleweed: I think there've been various docs that recommend them actually.
[12:18] <smartboyhw> tumbleweed, and the Packaging Guide teaches them
[12:18] <infinity> tumbleweed: I'm sure I've seen Colin raise the same complaint. :P
[12:18] <smartboyhw> That's why I used it
[12:18] <tumbleweed> it's something you need to know how to do. It doesn't mean you go and do other people's merges
[12:18] <tumbleweed> (not talking specifically about this case)
[12:18] <infinity> I don't even mind people merge-sniping occasionally, it really is the sponsorship aspect.  They're almost literally unsponsorable.
[12:19] <jpds> om26er: Well, click on them for more information.
[12:19] <Laney> https://wiki.ubuntu.com/MOTU/TODO
[12:19] <infinity> Byt the time I'm done, I've re-done exactly the same work to verify it's correct, and then I put someone else's name in my changelog.  Which isn't really sponsorship.
[12:19]  * tumbleweed finds sponsoring merges to be a useful way to encourage a bunch of behavior in new developers. It's a hell of a lot of work, though
[12:20] <xnox> infinity: smartboyhw: i have no problem with bzr merges with large diffs. Afterall all i need to do is $ bzr diff -rtag:$DEBIAN_VERSION to get the debdiff against debain.
[12:20] <smartboyhw> xnox, Ok
[12:20] <infinity> xnox: Whatever works for you.
[12:20] <om26er> jpds, i am going to try to contact their admins and see what i get out of that
[12:21] <infinity> tumbleweed: Yeah, sponsoring/reviewing/(re-doing) merges can be a good way to teach people about a ton of other packaging gotchas, and just generally rap them on the knuckles for doing silly things.
[12:21] <infinity> tumbleweed: But I'm not sure that has much to do with merges as much as it has to do with volume and diversity of packages that need merging.
[12:22] <infinity> tumbleweed: If you were to ask apw what the best packaging crash course is, he'd probably say a massive library API transition. :P
[12:22] <apw> infinity, that'd do it ... with some gnarly c++ in it
[12:22] <infinity> tumbleweed: 17 different patch formats, a few source formats, a ton of weird ways to make that all work together, different VCSes, different upstreams...
[12:23]  * xnox realised i'm a bit clueless with old-style / verbose dh_* way of packaging stuff.
[12:23] <tumbleweed> :)
[12:23] <xnox> infinity: one source package split twice in main & universe is the nail in the coffin though that hardly anyone manages to notice ;-)
[12:23] <tumbleweed> so, we should send new contributors to the +1 team?
[12:24] <infinity> xnox: Poor, poor boost.
[12:24] <infinity> xnox: You should cleverly make them interdepend strongly enough that they can't migrate without being in sync.
[12:24] <infinity> xnox: Or, y'know, help with ArchiveReorg so we can make boost-mpi go the *&!% away.
[12:24] <xnox> i think they do.
[12:24] <infinity> xnox: Oh, do they?  Maybe all the problems were pre-britney, then.  Yay for another solved problem. :P
[12:25]  * xnox was pondering about 3.0 (custom) which generates two source packages....
[12:25] <tumbleweed> wat
[12:25] <infinity> tumbleweed: Actually, I wouldn't mind having some new blood here and there.  The problem is that it needs to be new blood with sufficient programming clue.
[12:25] <tumbleweed> yeah
[12:25] <tumbleweed> and, presumably, time
[12:25] <xnox> infinity: way too picky =))))
[12:25] <infinity> tumbleweed: I don't need people who understand Debian packaging (I can teach that via pain), but I need people who speak a few programming languages and can adapt.
[12:26] <apw> yeah that was my supprise, that although packaging is important, most of what one does is not packaging in +1
[12:30] <infinity> apw: To be fair, I threw specific things at you because I know you're a strong programmer, there's plenty of packaging fixes in +1 too.
[12:31] <apw> infinity, fair enough indeed, +1 was fun and i do recommend a stint
[12:31] <infinity> But while I can teach a strong programmer to fix packaging, I'm not particularly good at teaching a strong packager C and Python. :/
[12:31] <infinity> And understanding WHY something breaks is critical before you go and work around it by breaking a package. :P
[12:31] <infinity> (And then understanding how to fix it...)
[12:33] <infinity> tumbleweed: But, in all seriousness, if you have people wandering in who say "I have a really good fundamental knowledge of C/C++, but don't know thing one about Debian packaging", send them my way, I can make use of them.
[12:33] <infinity> dholbach: ^
[12:34] <seb128> infinity, you don't especially need strong programming skills to be helpful on +1
[12:34] <rbasak> infinity: AIUI, having merge experience is essentially a requirement to get upload rights. So getting sponsorship for them becomes a requirement.
[12:34] <seb128> often the work is "look if Debian/upstrea
[12:34] <rbasak> (or am I mistaken?)
[12:34] <tumbleweed> infinity: finding people like that is tough :P
[12:34] <seb128> often the work is "look if Debian/upstream/other distro have a fix for the issue we can backport"
[12:34] <infinity> seb128: Sometimes it's just patch hunting, sure.  I can teach that too. ;)
[12:35] <rbasak> I guess that only applies to people seeking those upload rights though
[12:35] <seb128> yeah
[12:35] <infinity> seb128: But even then, while you don't need to be a *good* programmer to backport a patch, you need to understand general programming well enough to know how to massage it and fix it when you break it.
[12:35] <infinity> seb128: I suspect you take that skill for granted, since you're good at it. :)
[12:35] <seb128> lol, could be :p
[12:36] <infinity> (I, for instance, am not a particularly good programmer, but I'm good enough to know why and how I've broken something, rather than throwing my hands in the air and saying "HALP, IT DOESN'T COMPILE")
[12:36] <dholbach> infinity, errr... do what exactly?
[12:37] <infinity> dholbach: Just saying that if you have any people with programming experience but no Debian/Ubuntu experience looking for places to contribute, I can probably make use of them in +1... I know I've seen that once or twice.
[12:38] <infinity> rbasak: I'd suggest that if merges are a prereq for upload rights, we're doing it wrong, but that's something to bring up with the DMB.
[12:39] <infinity> rbasak: Given that most merges are fairly mechanical, all those ones do is add to your upload volume rather than proving anything interesting about your skills, I'd rather see people fixing packages, submitting lots of useful patches, etc.  But, I don't vote either.
[12:39]  * rbasak is looking forward to +1 in April
[12:40] <infinity> April will be a boring month for it, probably. :/
[12:40] <infinity> But you'll get some inner workings of archive maintenance at least.
[12:40] <dholbach> infinity, sure sure
[12:40] <infinity> Since pre-release is when we try to fix the few things we still have time to fix, and then give up and purge all the crap that's still broken.
[12:50] <cjwatson> It was more exciting than it probably ought to have been last time.
[12:50] <cjwatson> Speaking of, I *really* ought to get started on +1 work this month ...
[12:51] <cjwatson> Been too busy fighting fires (some self-started).
[13:00] <xnox> infinity: gcc-4.8 fixes in april ;-)
[13:11] <Reezz> Hey guys, could anyone help me out with a linker problem? I've set the LDFLAGS to the lib's location.. But still no help :)
[13:12] <cjwatson> Not volunteering, but it'll probably work better if you describe the full problem up-front (perhaps with the aid of a pastebin).
[13:13] <Reezz> Sure, hold on
[13:13] <xnox> Reezz: please pastebin full build-log with all command-lines verbose (e.g. no silent make rules, V=1, --verbose, etc)
[13:14] <jdstrand> pitti: hi! fyi, http://people.canonical.com/~jamie/archive-grep/
[13:15] <pitti> jdstrand: good morning
[13:15] <jdstrand> http://people.canonical.com/~jamie/archive-grep/pitti-fs_cgroup_systemd_or_sd_booted.log that is
[13:15] <pitti> jdstrand: splendid, many thanks!
[13:15] <jdstrand> np
[13:19] <rtg_> how does one turn off the drum sound at boot when lightdm starts up ?
[13:19] <highvoltage> rtg_: start up in system recovery mode,
[13:20] <highvoltage> rtg_: then take a soldering iron and shove it in until the speakers melt
[13:20] <rtg_> highvoltage, hmm, thats less helpful then you might think.
[13:20] <rtg_> these mac minis are a drag to take apart.
[13:21] <henrix> rtg_: renaming /usr/share/sounds/ubuntu/stereo/system-ready.ogg should work :)
[13:21] <rtg_> ah, thats what I was looking for .
[13:21] <pitti> I guess there might be a lightdm config option for this
[13:22] <Reezz> Ok so, here's the pastebin for my linker problems. http://pastebin.com/qYHC3QVS
[13:23] <Reezz> I saw that it indeed did not go through the directories I specified, but I can't make out why? (directory where the libs are is "/usr/local/lib")
[13:24] <pitti>       if (UGSettings.get_boolean (UGSettings.KEY_PLAY_READY_SOUND))
[13:24] <pitti>             canberra_context.play (0,
[13:24] <pitti> rtg_: ^ that looks promising (in unity-greeter)
[13:24] <pitti> com.canonical.unity-greeter play-ready-sound true
[13:24] <cjwatson> That looks like just missing -l options.  What libraries include the symbols (e.g.) skeltrack_joint_list_get_joint and gfreenect_device_new_finish?
[13:25] <pitti> rtg_: so try sudo -u lightdm gsettings set com.canonical.unity-greeter play-ready-sound false
[13:25] <rtg_> pitti, ack, will give it a try
[13:25] <pitti> . o { we used to have a checkbox for this in control-center.. }
[13:26] <Reezz> cjwatson: libgfreenect-0.1.a and skeltrack-0.1.a (in /usr/local/lib)
[13:26] <Reezz> I've added the dir to the LDFLAGS .. So I don't know why it won't link properly (although I'm probably missing something here :D)
[13:27] <rtg_> pitti, hmm, dbus-launch errors.... Think I'll just redirect system-ready.ogg
[13:27] <infinity> rtg_: I believe that, instead of all this fiddling about with settings, if you just mute the volume in lightdm, it remembers that independently of your user volume.
[13:27] <infinity> There's a speaker icon there for a reason...
[13:27] <rtg_> infinity, but I'm too stupid to remember to do it consistently.
[13:27] <infinity> rtg_: Hence the remembering part.  You only have to do it once.
[13:28] <rtg_> infinity, except that I often listen to tunes and mumble, etc
[13:28] <infinity> rtg_: As the lightdm user?
[13:28] <rtg_> infinity, you mean before I login ?
[13:28] <infinity> rtg_: Yes.
[13:28] <rtg_> ah, I'll try that
[13:28] <rtg_> back in a sec
[13:29] <infinity> rtg_: Unless we broke that, the lightdm user's volume prefs used to get saved.
[13:29] <infinity> And you left.
[13:29] <Reezz> Well he's trying your suggestion :)
[13:29] <infinity> Yes, but how dare he run off to try something while I was still being pointlessly verbose in his direction.
[13:32] <cjwatson> Reezz: forget -L; as far as I can see you're not asking the linker to use those libraries
[13:33] <cjwatson> Reezz: the linker doesn't just look for any relevant library in the directories you provide, or anything like that.  You have to actually state the library name, either using the -l option or by adding libwhatever.a to the link line
[13:33] <cjwatson> Reezz: So  -lgfreenect-0.1 -lskeltrack-0.1  should help
[13:33] <Reezz> cjwatson: Ah, that might just be it. Gonna give it a go :D
[13:34] <cjwatson> Reezz: Basically all that -L does is govern where libraries named in -l options are looked up
[13:34] <rtg_> infinity, that did the trick, though I had to reboot to get pulseaudio (I think) to behave
[13:36] <infinity> rtg_: \o/
[13:36] <infinity> It's nice when there's an almost intuitive solution to a simple problem.  It's a bit sad when our initial reaction to "how do I" is to go rooting around in filesystem mangling and obscure settings trees, though. :P
[13:37] <rtg_> infinity, I guess its just training from the bad ol days
[13:37] <infinity> We were dangerously close to someone suggesting locally patching lightdm of g-s-d and rebuilding it.
[13:37] <infinity> s/of/or/
[13:39] <rtg_> I _would_ like to figure out why the combination of pulse and mumble consumes 75% of my CPU. that seems kind of high.
[13:39] <infinity> Yeah, I don't have a simple answer to that one. :)
[13:39] <rtg_> its eventually drops down to 20-30%. some kind of network profiling ?
[13:40] <Reezz> cjwatson: Did the trick, with full path names though :) Thanks a lot!
[13:40] <infinity> Or recalculating echo cancellation or something?
[13:40] <infinity> But unless your computer is awful, none of those things should take much CPU, so it's still pretty clearly buggy behaviour.
[13:40] <cjwatson> Reezz: You're welcome
[13:43] <Reezz> cjwatson: might you know how to add all the known installed libraries to the search list? :x
[13:44] <pitti> Reezz: you usually don't want that; normally you call pkg-config --libs to find out the linker flags for the libs you want to link with
[13:45] <cjwatson> Reezz: What pitti said; the linker has no way of its own to do what you're asking, and it's (to say the least) a highly unconventional thing to do
[13:47] <Reezz> cjwatson: Yea I understand, but there has to be a better way than manually adding each and every linked library? I'm quite new to the uni environment, but as I recall I had to export certain paths in which my used libraries (or includes, can't remember) are stated?
[13:48] <pitti> Reezz: no, your build system needs to declare which library (or more abstractly, pkg-config module) it needs to link to
[13:49] <pitti> Reezz: if you are using autotools there are convenient macros for that; if you are writing a plain Makefile it works similarly; just call "pkg-config --libs foo bar baz .." with all the libs you need
[13:49] <pitti> you usually need it for --cflags more than for --libs, though
[13:50] <cjwatson> hallyn: Hmm, I think a recent qemu change has broken grub2
[13:50] <Reezz> pitti: aah, ok! Thanks :)
[13:50] <cjwatson> hallyn: 'grub-mkrescue -o grub.iso', 'qemu -cdrom grub.iso', then type 'halt' at the GRUB prompt, and it fails to shut down - I think this is what's causing grub2 to fail to build at the moment
[13:53] <cjwatson> Though I wonder if it's just failing to decode the ACPI table or something ...
[13:53] <hallyn> trying
[13:53]  * hallyn installs xorisso...
[13:54] <cjwatson> 'set debug=acpi' does sort of suggest the latter (get_sleep_type is returning -1), so maybe it's not qemu's problem; I just wonder why it changed

[13:55]  * cjwatson sets up a quantal chroot to investigate
[14:03] <sconklin> @pilot in
[14:21] <hallyn> cjwatson: a grub.iso created in a precise chroot does the same thing (with raring's qemu)
[14:22] <hallyn> so sounds like qemu or seabios bug
[14:23] <cjwatson> I'd have tried quantal's qemu by now if I hadn't created a chroot with the wrong arch by mistake
[14:23] <cjwatson> Happens with my upstream checkout too (a bit stale but not very)
[14:23] <cjwatson> Of grub, that is
[14:24] <hallyn> building upstream checkout of qemu...
[14:24] <hallyn> (hopefully that doesn't overheat my laptop)
[14:24] <cjwatson> Will raring's qemu work with quantal's seabios, and vice versa?
[14:24] <cjwatson> (Er, meaning quantal's qemu with raring's seabios)
[14:25] <hallyn> not sure.  the versions did change, i'm just not sure how closely tied they need to be
[14:26] <cjwatson> OK, definitely different debug=acpi output
[14:26] <hallyn> cjwatson: same thing with uptodate upstream qemu
[14:27] <hallyn> my money's on a seabios bug though
[14:27] <cjwatson> http://paste.ubuntu.com/5607839/
[14:28] <cjwatson> It's far from impossible that the DSDT is just shaped differently and is tickling a bug in GRUB's parser
[14:28] <cjwatson> Does that live in seabios?
[14:29] <hallyn> uh....  i think so.
[14:29] <cjwatson> And indeed, quantal qemu + raring seabios => same problem
[14:30] <hallyn> yeah, acpi-dsdt in seabios/src
[14:30] <cjwatson> Guess I'll need to dig out the ACPI spec :-/
[14:30] <cjwatson> Gotcha
[14:30] <hallyn> (going by http://smackerelofopinion.blogspot.com/2010/09/hacking-custom-dsdt-into-qemu-bios.html )
[14:30] <hallyn> thanks cking :)
[14:31] <cjwatson> hallyn: OK, thanks a lot for the pointers; I'll see what I can make of it from here for a while, and will shout if I get stuck
[14:32] <hallyn> cjwatson: np (last seabios change affecting dsdt directly was acpi: Use prt_slot() macro to describe irq pins of first PCI device. btw)  ttyl
[14:48] <xnox> cjwatson: slangasek: can you look at bug 952185 again and see what's available to sponsor next, and if it's wanted or not. openssh is involved and other packages that slangasek looked at before.
[14:56] <cjwatson> xnox: I'll have a look, but not today
[14:57] <xnox> cjwatson: ok, thanks. Not very urgent, as i think slangasek did fix the bulk of it for raring already.
[15:00] <slangasek> infinity: heimdall-flash> you're welcome :)  as for the CM wiki, there's a surprising amount of bad information in CM wiki pages that are locked :-P
[15:01] <infinity> slangasek: Well, I'm not sure that pointing to upstream's builds would be generally considered "bad information", except that they currently seem broken, and yours works.
[15:02] <infinity> slangasek: I also need to hunt down this upstream and figure out WTF they got their compiler.
[15:03] <infinity> slangasek: It's baking in a PI of /lib/ld-linux-x86-64.so.2 (note the lack of 64 in the directory name...)
[15:04] <infinity> So, some distro/toolchain is gratuitously incompatible with the world, and I want to find out so I can point and laugh at them.
[15:07] <slangasek> infinity: heh, cute
[15:07] <slangasek> infinity: I didn't mean the heimdall-flash stuff specifically; but there was some content on some of the pages giving users bad directions on how to do things on Ubuntu, and I was powerless to fix it
[15:08] <infinity> slangasek: Isn't NCommander CM upstream still?  Get him to give you teh l33t access.
[15:08] <slangasek> is he?  I didn't know he ever was
[15:08] <slangasek> but anyway, now I'd have to remember where the page in question was
[15:10] <slangasek> xnox: well, there's still an at branch awaiting my review on there; I don't remember seeing if there's an openssh patch ready for sponsoring
[15:10] <slangasek> xnox: the bug state should in general be correct though
[15:10] <xnox> slangasek: there are a few patches attached, one of them is for openssh last time i looked at that bug.
[15:13] <cjwatson> There is an openssh one, but (a) openssh is in sync with Debian and I like to keep it that way now that I've gone to all that effort to get it there, (b) I really want to check quite hard what effect this might have on other bits of openssh
[15:19] <slangasek> cjwatson: ok, understood
[15:20] <ev> bdmurray: mind looking this over? http://paste.ubuntu.com/5607992/ mpt and I have been discussing how to fix bug 1077122.
[15:22] <bdmurray> ev: I might need some more coffee for that topic, but sure.
[15:22] <ev> bdmurray: whenever you have time today. I'm going to move on to your MP, then onto the script that rebuilds BucketVersions, since we have the new comparator finally in place on the cluster \o/
[15:23] <ev> actually, coffee is a grand idea
[15:25] <ev> oh and if anyone else finds the problem of calculating the average errors per calendar day interesting, do feel free to have a read through as well :)
[15:26] <bdmurray> ev: is it ErrorsByDate or ErrorsByRelease?
[15:26] <bdmurray> line 22-33
[15:27] <ev> by release
[15:27] <ev> fixing
[15:27] <mterry> wgrant, heyo!  I have this old merge I'd like you to look at: https://code.launchpad.net/~mterry/launchpad-buildd/prefer-install/+merge/117318
[15:27] <ev> http://paste.ubuntu.com/5608021/
[15:43] <xnox> @pilot out
[15:44]  * xnox had enough.
[15:44] <ev> quitter
[15:44] <smartboyhw> xnox, LOL
[15:44] <xnox> ev: when is your patch pilot turn?! =)))))
[15:44] <ev> xnox: never
[15:45] <ev> for medical reasons I can't touch other people's dirty code
[15:46] <pitti> hey slangasek, good morning
[15:49] <pitti> Laney: FYI, I found a workaround for cleaning up sessions now (for logind without systemd)
[15:50] <pitti> slangasek: quick status update: libudev1 transition prepared in PPA (was trivial after all, just cherrypicking an lvm2 upstream commit, the rest works), logind shutdown/reboot/suspend etc. now works, and sessions are cleaned up properly
[15:50] <pitti> slangasek: so by and large we are now blocked on the small FFE for updating systemd and at least a partial MIR for moving systemd's libudev* bits into main
[15:51] <seb128> slangasek, pitti: if you partial MIR please partial MIR systemd-services as well ;-)
[15:51] <pitti> seb128: well, neither me nor slangasek are in ~ubuntu-mir
[15:51] <pitti> the udev bits are certainly trivial, as we already ship libudev in main
[15:51] <pitti> -services might need an actual review
[15:51] <seb128> right
[15:51] <seb128> I just wanted to mention it
[15:52] <seb128> I guess jdstrand/security team will want to review that one
[15:55] <jdstrand> sarnold is assigned to that
[15:55] <jdstrand> I think he is actively working on it
[15:56] <vibhav> jdstrand: Incorrect usage of format strings is a security risk, right?
[15:56] <pitti> sarnold: are you looking at the raring package (version 44) or the PPA (version 198)?
[15:58] <jdstrand> vibhav: there is a class of vulnerabilities called format string vulnerabilities, yes. the compiler should pick these up and reduce them to DoS if using gcc
[15:59] <vibhav> jdstrand: I had fixed a format string vulnerabilites in thoggen, would this qualify as a security update? https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning
[15:59] <vibhav> And ther merge request for it: https://code.launchpad.net/~vibhavp/ubuntu/raring/thoggen/fix-format-string-warning/+merge/150969
[16:01] <jdstrand> vibhav: only if errmsg->str is attacker controlled. even then, in lucid and higher this would result in an application termination and likely only 'low'
[16:02] <vibhav> jdstrand: How are the incorrect use detected?
[16:03] <jdstrand> vibhav: you have to go through the code paths and see how the error message is set
[16:04] <jdstrand> vibhav: if it is just pulling strings from enums or something, then no worries. if you are adding a string that comes from outside your program which an attacker can control, then it would likely qualify as a security vuln
[16:04] <vibhav> jdstrand: I mean how is the application terminated in lucid and higher? Is there a mechanism for detecting these risks?
[16:05] <seb128> jdstrand, thanks ;-)
[16:10] <jdstrand> vibhav: iirc, it is abort
[16:11] <jdstrand> vibhav: the mechanism is code inspection. eg, going backwards from that point, seeing all the callers of the functions that calls that patched code, etc
[16:12] <vibhav> jdstrand: ah
[16:12] <vibhav> jdstrand: thanks
[16:13] <cjwatson> Is it just me who has to look up which way round dd's seek and skip arguments go every single time?
[16:15] <pitti> certainly not; clear case of poor naming
[16:18] <sarnold> pitti: I started with the raring version (44) and moved to your ppa version after seeing your request :)
[16:18] <sarnold> cjwatson: every. single. time.
[16:19] <cjwatson> oh good.  what's the word for Schadenfreude when it applies to yourself as well?
[16:19] <cjwatson> Schadenschade :P
[16:20] <pitti> cjwatson: "Trost"? :-)
[16:21] <cjwatson> Heh, maybe
[16:21] <cjwatson> schwacher Trost
[16:21] <vibhav> making fun of yourself?
[16:21] <vibhav> (probably)
[16:35] <bdmurray> ev: have you noticed the bucket page for most failed buckets appears empty?
[16:35] <bdmurray> https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fgtk-window-decorator%3A11%3Ai686%3A%2Flib%2Fi386-linux-gnu%2Flibglib-2.0.so.0.3400.0%2B35587%3A%2Fusr%2Fbin%2Fgtk-window-decorator%2B14f3e%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B562ce%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B57b0b%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-x11-2.0.so.0.2400.13%2B57bbd%3A%2Flib%2Fi386-linux-gnu%2Fli
[16:36] <ev> that got cut off
[16:36] <ev> and causes an exception that I'll fix now
[16:38] <bdmurray> which exception? I just fixed one regarding bucket ids
[16:40] <ev> bdmurray: that'd be the one :)  https://errors.ubuntu.com/oops-local/2013-03-12/59978.errors.ubuntu.com1
[16:43] <ev> bdmurray: https://bugs.launchpad.net/errors/+bug/1154189
[16:45] <bdmurray> ev: looking at the pastebin again I'm not clear where the system id exists in ErrorsByRelease
[16:47] <bdmurray> ev: particularly the statement in lines 24-26 regarding 'first time we saw an error from this system'
[16:47] <ev> bdmurray: I originally has the system id as part of a composite for the column name, but realised it wasn't needed
[16:48] <cjwatson> hallyn,stgraber: Right.  The problem here is that seabios moved the description of the S5 state out of the DSDT into an SSDT.  GRUB should (I think) gain the ability to parse those, but can't right now
[16:49] <ev> bdmurray: we could the number of unique systems elsewhere (the denominator), we just need to somehow weight each instance of problems seen over this period (the numerator)
[16:49] <ev> count*
[16:50] <ev> and we have the data to do that in the column value, the date of the first time the system which is responsible for this instance reported an error for that Ubuntu version
[16:56] <bdmurray> so then is the statement regarding the system in lines 50-52 also unnecessary?
[16:58] <ev> bdmurray: which part of it? Each column name is a uuid.uuid1(), which we create for each error coming in. Each value of that column is the date for the first time we received an error for the release, for the system reporting.
[17:02] <smoser> stgraber, could you take a read / offer thoughts on https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570
[17:03] <bdmurray> ev: I guess I'm not seeing the relationship between ErrorsByRelease and a system e.g. a378 from line 1
[17:04] <ev> bdmurray: there doesn't need to be. Instead of providing a key, the system identifier in this case, that we use as a link off to another column family where the rest of the data lives, we just include the data we need in the ErrorsByRelease CF
[17:04] <ev> which duplicates it, but that's a common pattern in nosql
[17:05] <ev> so we never actually need to know what the system identifier is. We just need to know that for the uuid for the error instance we're recording, the system first reported an error on X date
[17:05] <blitzkrieg3> would it be possible for someone to sponsor bug 1025508
[17:05] <blitzkrieg3> ?
[17:05] <ev> bdmurray: we'll then grab the number of unique systems from UniqueUsers90Days and use that as the denominator
[17:06] <ev> but we don't need system identifiers for the numerator
[17:08] <psusi> cjwatson: why does grub know or care about the acpi s5 description?
[17:09] <cjwatson> psusi: It has a 'halt' command
[17:09] <cjwatson> Which is quite important in its test suite
[17:09] <cjwatson> (BTW sorry but I really don't have time to get into a design discussion about this right now)
[17:10] <stgraber> smoser: it's on my todo for when I get to look at bug reports, this week for sure, maybe today, if not, tomorrow
[17:11] <psusi> ahh... nifty.
[17:12] <psusi> kind of a strange thing to move to an ssdt
[17:12] <kaleo> Ubuntu suddenly displaying everything in Chinese, known bug?
[17:13] <kaleo> maybe related to one of these 2 https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/992263 https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1024800
[17:13] <cjwatson> psusi: It was something to do with some fancy qemu integration in seabios, apparently
[17:14] <cjwatson> Looks like it patches the SSDT at run-time
[17:18] <xnox> blitzkrieg3: it hasn't even make it into the sponsorship queue http://reqorts.qa.ubuntu.com/reports/sponsoring/ ubuntu-sponsors is subscribed, somebody will get around to it soon once it's in the report.
[17:19] <xnox> (report updates every hour or so)
[17:19] <blitzkrieg3> xnox: okay, thanks
[17:19] <blitzkrieg3> xnox: I think I subscribed a while ago, any reason it didn't make it into the report?
[17:19] <blitzkrieg3> xnox: I just added the libgnomekbd component
[17:20] <xnox> blitzkrieg3: strange. adding tag patch to it, to see if that will make a difference.
[17:21] <blitzkrieg3> xnox: thanks
[17:21] <xnox> blitzkrieg3: right, so none of the open tasks were against ubuntu.
[17:21] <xnox> blitzkrieg3: the g-c-c is invalid, and the rest are on the upstream projects.
[17:21] <xnox> blitzkrieg3: now that libgnomekdb (ubuntu) added it will finally appear on the report.
[17:22] <xnox> (not sure about tag patch, i don't think it's required but added for good luck anyway)
[17:22] <blitzkrieg3> okay, so it was because I forgot to target libgnomekbd (ubuntu) I guess
[17:26] <jbicha> kaleo: that's bug 1035219
[17:33] <psusi> cjwatson: why would s5 be changed at runtime?  weirdness
[17:39] <xnox> blitzkrieg3: it's up on the report now. should be dealt with soon.
[17:39] <xnox> (well give it a couple of days)
[17:39] <blitzkrieg3> xnox: awesome, thanks again for your help
[17:39] <xnox> no problem.
[17:39] <blitzkrieg3> xnox: yeah I'll re-ping if no one picks it up
[17:55] <cjwatson> psusi: http://code.coreboot.org/p/seabios/source/commit/d51c4a0df1ae7bcb20ec3d569e409cf50f3ed760/ is all I know
[17:56] <mitya57> debfx: hey, what's happening with bug 1081307? Were your packages rejected from -proposed? If yes, do you have any plans to upload the new ones?
[17:57]  * mitya57 can prepare the updated packages (maybe on the weekend), but wants to know if/why debfx's ones were rejected
[18:04] <infinity> mitya57: slangasek's comment in bug 1031217 explain why the previous upload was rejected.
[18:06] <infinity> mitya57: If you'd like to fish his out of the rejected queue and add your fix on top, that's cool, but please update the other two bugs with proper SRU justifications and testcases.
[18:06] <infinity> mitya57: Otherwise, just uploading your own fix and letting him deal with the others later is just fine. :P
[18:07] <kaleo> jbicha: thanks!
[18:12] <mitya57> infinity: Thanks! I think it'll be fine to just re-upload his changes with the SRU information added and changelog fixed
[18:13]  * mitya57 will look at other two bugs and add missing information tomorrow
[18:20] <hallyn> stgraber: cgroup-lite breakage
[18:21] <hallyn> stgraber: at least on a server iso, after first reboot, none is mounted on /sys/fs/cgroup
[18:21] <hallyn> did mountall start doing that?
[18:22] <hallyn> yeah there it is in /lib/init/fstab
[18:23] <hallyn> aaaaand.  i see stgraber did it :)
[18:23] <tkamppeter> OdyX, hi
[18:24] <tkamppeter> OdyX, a second patch to complete the fix of bug 1069671 is posted by Mike Sweet, CUPS STR 4291.
[18:30] <stgraber> hallyn: hehe, yeah. I thought we had a check in cgroup-lite that should have dealt with that properly?
[18:31] <hallyn> stgraber: yes, it deals with it by saying "if that's mounted dont' do anything'
[18:31] <hallyn> i can just pull tat check if that's the right thing to do :)
[18:32] <stgraber> hallyn: ah, I thought it'd still setup the cgroups and just not mount /sys/fs/cgroup itself
[18:32] <hallyn> it just figures that someone's been mucking with it, so it doesn't want to mess things up
[18:33] <hallyn> stgraber: should cgroup-lite just be merged into mountall? :)
[18:33] <NCommander> slangasek, infinity: wow, that's special (re: linker path). I thought heimdall-flash was open source, but if it isn't ....
[18:33] <stgraber> hallyn: ah, ok. Then we should change that. Either to assume /sys/fs/cgroup is always mounted or to only mount /sys/fs/cgroup if it's not mounted and then always setup the cgroups
[18:34] <stgraber> hallyn: mountall doesn't create directories and cgroup-lite may at some point do more than create directories and mount stuff
[18:34] <hallyn> stgraber: really someday soon cgroup-lite may go back into libcgroup
[18:34] <hallyn> jbernard is working on sysvinit scripts so we can have both upstart+sysvinit scripts there for simple boot stuff
[18:35] <hallyn> anyway - i'll update cgroup-lite, thanks.
[18:39] <slangasek> NCommander: it is open source, and a proper build is in Debian and Ubuntu.  That's separate from the question of upstream distributing bustificated binaries.
[18:39] <stgraber> hallyn: np. Sorry for not noticing that the logic was wrong before I changed mountall. I wrongly assumed it'd do the "right" thing.
[18:40] <hallyn> stgraber: heck, at this point it may be better to turn cgroup-lite into a mounted-cgroup script
[18:41] <hallyn> but not right now
[18:42] <hallyn> stgraber: so i take it i should now not umount /sys/fs/cgroup when it stops?
[18:42] <stgraber> hallyn: right
[18:44] <infinity> NCommander: That has nothing to do with heimdall-flash itself, per se, and has to do with whatever distro/toolchain they're using to build their binaries.
[19:26] <slangasek> xnox: eh, how is bug #1154260 anything but a kernel bug?
[19:26] <slangasek> xnox: this is the known, "overlayfs lies about inotify support" bug
[19:28] <infinity> xnox: slangasek is refering to bug 882147, if it's not familiar to you.
[19:29] <infinity> xnox: You could, arguably, "fix" upstart's testsuite to skip that test when it detects that it's running on overlayfs, I suppose.
[19:29] <infinity> (I was going to do the same for glibc's testsuite, then decided to just use aufs instead and lowered my blood pressure in the process)
[19:32] <xnox> slangasek: well surely, upstart can detect broken inotify support and surely it can skip those tests?! we already skip all of inotify tests, if there is no inotify support or all inotify watches are taken up.
[19:32] <infinity> xnox: You can't detect broken inotify support.  That's part of the bug.
[19:32] <infinity> xnox: You can, however, detect that you're on a filesystem that you don't like.
[19:34] <xnox> infinity: and you can totally inspect mounts, add one more confsource which is the location of the overlayfs upperdir and totally get complete inotify support, for the purposes that upstart needs ;-)
[19:34] <infinity> xnox: 0x794c764f being the magic statfs constant for overlayfs, if you feel the urge.
[19:34] <xnox> afterall we made multiple conf-sources rock for user-sessions, why can we not abuse that for system init. Since well there are _two_ /etc/init dirs when running on top of overlayfs.
[19:34] <infinity> Three.
[19:35] <xnox> infinity: sure, but the other two are combined in the same way upstart combines multiple sources.
[19:35] <xnox> infinity: hence upstart really just needs the upper & lower dirs separately prefferably, we combine the outputs ourself.
[19:36] <infinity> But sure, you could do something vile like that.  I tend to think that second-guessing your VFS layer is just writing bugs for future programmers to hate you for, but...
[19:36] <xnox> hardly vile, just willing to bend backwards to get inotify support.
[19:37] <infinity> I think it's vile to assume you know the structure of something that's meant to be opaque, yes. :P
[19:38] <infinity> The fact that you *do* know the structure is irrelevant, it could all change tomorrow, and the bug is with you, not the kernel, cause you're only ever supposed to be "talking" to the top layer.
[19:39] <xnox> infinity: sure we can make the top layer authorative, but we can accept commandline options for something else to tell us where the other layers are, like for example on livecds we can be told by (casper?!) that there are other places to listen for inotify watches.
[19:46] <slangasek> xnox: I think hacking around overlayfs in upstart's test suite is a losing proposition.  Like infinity says, it's writing bugs for future programmers.
[19:46] <slangasek> xnox: tests fail when running on overlayfs because *upstart* fails to work correctly when running on overlayfs.  overlayfs at a minimum should be fixed to not lie about supporting inotify
[19:48] <xnox> ack.
[19:50] <xnox> slangasek: what about establishing additional watches & rewalk confsource when we get inotify events for other (shadow) directories?
[19:51] <slangasek> xnox: doesn't that come back to assuming implementation details about overlayfs?
[19:53] <xnox> no, it's a generic file based API to ask upstart to essentially do `initctl reload-configuration`
[19:54] <xnox> i'm not proposing for upstart to transverse and try to figure out exactly how many times nested overlayfs there is, simply "by the way please inotifywatch this dir as well"
[19:57] <infinity> xnox: The livecd use case that everyone cares about (I installed ssh but the job isn't found) could be solved with a dpkg trigger that registers interest in /etc/init and forces a conf reload.
[19:57] <infinity> slangasek: ^
[19:57] <slangasek> xnox: sorry, my question is, "what dir"?
[19:58] <slangasek> is this a matter of passing information from the mounter to upstart?
[19:58] <xnox> yes.
[19:58] <slangasek> hmm
[19:59] <slangasek> infinity: put the trigger in casper?  we don't want to have to rely on a trigger on the installed system.  Also, this doesn't solve user jobs
[19:59] <xnox> I am prototyping a demo locally, now. I'll post something to upstart-devel once I have it working. But yeah, it's the usecase infinity outlined above.
[19:59] <infinity> slangasek: No, have the trigger in upstart.
[20:00] <slangasek> mm
[20:00] <slangasek> then that means the trigger is active post-install too
[20:00] <infinity> slangasek: But yeah, it doesn't solve user jobs on a live union.
[20:00] <slangasek> which is wasteful
[20:00] <infinity> It's mildly wasteful, but I assume executes quickly.
[20:01] <infinity> It made more sense when I suggested it six months ago, before user jobs came into the picture.
[20:01] <infinity> Anyhow, I'm going to take a jetlag-induced afternoon nap, I've been up all night.  Back later this evening.
[20:03] <infinity> I'm not wildly happy about the idea of assuming overlayfs implementation, but given that casper needs to do that already to mount the filesystem inthe first place, if it then just passes the top layer as an extra argument to upstart, that's probably not world-ending.
[20:04] <infinity> Any change in how overlayfs works would have needed a casper change regardless, so now it would just need two.
[20:05] <xnox> infinity: yeap.
[20:32] <mdeslaur> soren: were you planning a ruby1.8 upload for LP: 1142977?
[20:41] <Sweetshark> cjwatson, bdrung: https://launchpad.net/ubuntu/+source/libreoffice/1:4.0.1-0ubuntu2/+build/4361643 <- should be finished any minute now ...
[20:58] <yofel> any reason why lp:ubuntu/raring/apport is lagging behind the archive for several versions?
[20:59] <slangasek> yofel: import failures explained here: http://package-import.ubuntu.com/status/
[20:59] <soren> mdeslaur: I tried to poke doko about it, but didn't catch him. It was during vUDS, so I guess that's to be expected.
[20:59] <yofel> slangasek: thanks! Didn't know about that page yet
[21:00] <mdeslaur> soren: ok, I'll try and poke him about it too...I don't want the doko beatdown either :)
[21:25] <sconklin> @pilot out
[22:01] <stgraber> smoser: finally got around to looking at that isc-dhcp bug. I'm not against carrying patches, it wouldn't exactly be the first one we have and that ISC disagrees on. I'll take a closer look tomorrow.
[22:47] <wgrant> mterry: Hm, you should probably get infinity's opinion on that. Really someone should just upgrade sbuild.
[22:47] <mterry> wgrant, apparently we are very divergent at this point, and we didn't want to risk unforking?  (iirc)
[22:50] <wgrant> mterry: That's completely wrong, we've wanted to unfork for several years. I did most of the work a few years ago, but ddebs and similar bits and pieces ended up problematic.
[22:50] <wgrant> So it's the preferred approach
[22:50] <wgrant> Mostly just a lack of time :/
[23:17] <mterry> wgrant, ah fair OK