[01:02] <ScottK> Mirv: It should not go back in.  That was the agreement.
[02:19] <dantti> stgraber: hi, I've been told you could maybe give me a hand, grub2 isn't booting W7 it boots kubuntu fine then I installed Ubuntu and still no lucky, the boot-repair tool from what I can tell installed grub1 which then managed to boot Windows but not ubuntu.. the error message is around the web but nobody did have a real fix other than I reinstalled everything and now it works:/
[02:19] <dantti> and the error is that it says Invalid EFI path when windows is choosen
[02:55] <balloons> so a nice evening random question for anyone who might be about :-) If I want a stupid simple key-value store, is there any reason to look beyond berkeleydb?
[03:02] <ScottK> Depends on how much you care about Oracle being the steward of the open source project you're going to depend on.
[03:04] <psusi> dantti, sounds like an existing bug report about grub2 not generating the correct chainloader path on efi systems... i.e. it still tries to do chainloader +1
[03:04] <balloons> ScottK, indeed.. is there an alternative?
[03:04] <dantti> psusi: yes, that's right it is +1
[03:04] <ScottK> I hadn't really thought much about it.
[03:05] <ScottK> I'd just suggest that as a reason to perhaps look beyond it.
[03:05] <dantti> psusi: I tried to change this to sth like boot/efi/microsoft... but didn work (tho I dunno if the path was correct)
[03:05] <psusi> dantti, yea, there's a bug report for that
[03:06] <balloons> ScottK, :-) thanks
[03:06] <dantti> psusi: do you know if there is a workaround? like putting the right path?
[03:06] <psusi> dantti, yea, put the right path ;)
[03:09] <dantti> psusi: ok, I'll try some variants of the path here :) thanks
[03:26] <infinity> ScottK: I'm not deeply concerned about Orable messing up BDB, to be fair.
[03:26] <infinity> ScottK: Or Oracle. :P
[03:26] <ScottK> I think so far they haven't, but looking at the trends in mysql and java, I'm not sure how much one should assume that will continue.
[03:27] <ScottK> In other news, I figured out why sip4 didn't migrate and fixed it.
[03:27] <infinity> ScottK: Wildly different projects.  MySQL already had the dual-license model, Java already had completely closed IP, BDB is, on the other hand, one of the freest of the free.
[03:28] <infinity> ScottK: If they try to mess up BDB in any meaningful fashion we'll all just fork and they can eff off, but it wouldn't be painful like the MySQL/Maria business.
[03:28] <ScottK> Right.
[03:29] <ScottK> Is LP running slow on updating from Debian?  There's a package that was accepted in Debian over 24 hours ago that I still can't sync via LP.
[03:30] <infinity> ScottK: I believe zumbi broke our imports.
[03:30] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709118
[03:31] <infinity> Though, I think wgrant was going to blacklist that gdb version and make it all go again.
[03:31] <wgrant> Yes, getting there :)
[03:31] <wgrant> mipsel of -2 failed to build
[03:31] <ScottK> Nice.
[03:31] <infinity> So did mips.
[03:31] <wgrant> So -1 is going to stick around blocking gina for a while
[03:32] <wgrant> infinity: mips failed on -1 too
[03:32] <ScottK> OK, now I don't feel guilty for manually syncing pyqwt5 so sip4 could migrate.
[03:32] <wgrant> It's only mipsel that's regressed from -1 to -2
[03:33] <ScottK> The other package I'm waiting for though is no rush.
[03:33] <wgrant> It'll hopefully be working again tonight
[03:33] <ScottK> Tonight where?
[03:33] <wgrant> Here :)
[03:33] <wgrant> So next <12 hours
[03:34] <ScottK> "Lunchtime"
[03:40] <pitti> Good morning
[05:43] <GunnarHj> slangasek: ping?
[05:44] <slangasek> GunnarHj: hi
[05:45] <GunnarHj> slangasek: Hi, Steve! What about the other tasks at bug 1155327? Are they possibly invalid now?
[05:45] <slangasek> GunnarHj: oh... probably
[05:45] <slangasek> (closed them out now)
[05:46] <slangasek> or rather, would have if LP hadn't timed out
[05:46] <GunnarHj> slangasek: Ok, you are fast today. :)
[05:50] <GunnarHj> slangasek: I removed the GLib upstream task as well, so now the whole bug report is history.
[05:53] <pitti> ev: FYI, I just fixed apport (-retrace) to actually be able to map files for the target release; before, it was always using Contents.gz for the host release, which led to bad retraces
[05:53] <pitti> ev: so it would be good if you could update apport to current trunk, and apply http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/7 to your retracer config
[06:27] <dholbach> good morning
[06:35] <mlankhorst> slangasek: ping?
[07:12] <mardy> cyphermox: hi! Could you please have a look at this whenever you got a spare minute? https://code.launchpad.net/~mardy/qmenumodel/root-index/+merge/164705
[07:19] <tjaalton> I need an advocate for the debian NM process.. volunteers? :) (I'm a DM already)
[07:22] <Noskcaj> could someone look at http://launchpad.net/bugs/1172015 . i'm starting to think someone hates sydney
[07:28] <Mirv> ScottK: I know (appmenu). There's a dispute, not sure how it could be resolved. I quoted the FFe bug text, but I was asked to push it anyhow. For my part I'm neutral, I understand the agreement and also understand the wish to not have regressions (but then why have an agreement in the first place). The QPA plugin is still under work, and there's now a blueprint for it https://blueprints.launchpad.net/appmenu-qt/+spec/qt5-qpa-appmenu
[07:29] <Mirv> hopefully it will get completed soon and the patch dropped for good
[07:31] <Mirv> the patch does not do other harm but potentially give a wrong impression of a problem solved, while it's not yet
[07:37] <seb128> ScottK, Mirv: I don't have the backlog but I discussed it with didrocks and it doesn't make sense to us to break Ubuntu "just to drop a patch that's not creating any issue", knowing that a proper solution is being worked and that we will drop the patch this cycle anyway
[07:37] <tvoss> didrocks, ping
[07:38] <didrocks> seb128: +1
[07:38] <didrocks> tvoss: pong
[07:41] <Mirv> seb128: yes. it should have been rised during the FFe approval discussion to disagree with the saucy plan. that's the only problem.
[07:41] <seb128> ok
[07:41] <Mirv> so not optimal, but here we are
[07:41] <seb128> right
[07:42] <seb128> I also though we would have the QPA by now, but as said, as long as that's happening there is no reason to drop the patch in that upload and break Ubuntu
[07:43] <didrocks> yeah, Qt5 is not really used in saucy, and the patch doesn't break anything, so as long as the replacement isn't ready, I don't see why we will break saucy for the sake of breaking it
[07:43] <didrocks> then, once touch is in saucy, we can resume the QPA work
[07:43] <didrocks> and have something clean
[07:43] <didrocks> (help from the kubuntu team is welcomed of course)
[07:44] <rbasak> doko: have you seen bug 1182613?
[07:58] <ttx> rbasak: oops.
[07:59] <rbasak> dep8 tests FTW
[07:59] <ttx> rbasak: rolling distros are hard, when you only test 1% of your functionality ;)*
[07:59]  * rbasak is waiting on review for a facter merge which adds one for the same issue
[08:00] <ttx> it's much easier for upstreams than for distros.
[08:08] <jamespage> rbasak, does puppet support ruby 1.9 at all?
[08:10] <rbasak> jamespage: http://docs.puppetlabs.com/guides/platforms.html#ruby-versions
[08:10] <rbasak> jamespage: for 3.x, looks like 1.8.7 and 1.9.3 only
[08:11] <rbasak> "To the best of our knowledge, these issues were fixed in the second public release of Ruby 1.9.3 (p125), and we are positive they are resolved in p392 (which ships with Fedora 18). Unfortunately, Ubuntu Precise ships with p0 for some reason, and there’s not a lot we can do about it. If you’re using Precise, we recommend using Puppet Enterprise or installing a third-party Ruby package."
[08:41] <mitya57> xnox: did you "escalate for someone to poke those builds harder" or should I do that?
[08:42] <xnox> mitya57: well, the second rebuild failed as well. I've been recommended by myself to poke it harder myself on my pandaboard.
[08:42] <xnox> mitya57: briefly discussed on #ubuntu-release last night.
[08:42]  * mitya57 reads the log
[08:44] <mitya57> that was a very brief discussion :)
[08:44] <mitya57> I don
[08:44] <mitya57> I don't have a pandaboard, but if someone gives an armhf-enabled ppa to me, I could try to debug this
[08:52] <geser> mitya57: https://dev.launchpad.net/CommunityARMBuilds
[09:05] <pitti> rsalveti: hey Ricardo! Can you please forward http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/udev/saucy/revision/237 to upstream? (bugzilla or systemd-devel@lists.freedesktop.org)
[09:09] <pitti> apw: I'm about to do a systemd upload; should I still wait a bit to include the fix for bug 1100386, or do you reckon that this will take longer?
[09:28] <xnox> ScottK: $ syncpackage --force cmake ;-))))))
[09:29] <apw> pitti, yeah i have that here ... give me 5m, i am struggling with unity, it has lost half my windows
[09:30] <xnox> apw: stop using Windows =)
[09:30] <apw> xnox, heh ... even restarting it is not sorting its head out, dammit
[09:31] <NikTh> Hey all
[09:31] <NikTh> anybody here ? apw , cjwatson  , infinity  ?
[09:40] <NikTh> How to overcome this error ? => https://launchpadlibrarian.net/140439152/buildlog_ubuntu-raring-i386.linux_3.8.0-21.32ubuntu1~nikth2_FAILEDTOBUILD.txt.gz
[09:46] <apw> pitti, ok ... finally got unity sorted (logout time) and I have attached the diff to the bug: bug #1100386 (for systemd)
[09:47] <apw> NikTh, you are better off coming over to #ubuntu-kernel for these kernel related build issues
[09:47] <NikTh> apw: Thanks
[09:47] <apw> NikTh, ping me when you get there
[10:05] <pitti> apw: great, thanks! (and no hurry, if you need more time then take it)
[10:09] <apw> pitti, that one should be good to go, tested and the like, though i did mod the changelog to get the bug number right :)
[10:10] <pitti> apw: ack, thanks; uploading now
[10:10] <apw> pitti, ta
[11:11] <mitya57> geser: Qt takes more than 4 hours to build on armhf (i.e. the 4:4.8.4+dfsg-0ubuntu9 build took 13 hours, 28 minutes, 34.2 seconds)
[11:11] <mitya57> (sorry for not noticing your message earlier, I was not online)
[11:47] <vassie> hello, not sure if this is the correct channel to ask but i packaged an app for raring, i have packaged a new version of it and uploaded to my ppa, i'm not sure what i need to do now
[11:55] <mdeslaur> @pilot in
[11:57] <ScottK> xnox: No.  There's one Ubuntu change left.
[12:01] <pitti> yolanda: did you see the postfix autopkgtest failure on i386? that looks curious, is that a bug in python itself?
[12:01] <ScottK> seb128: I approved an FFe based on an agreement.  If people didn't want to follow the agreement, then that was the time to discuss it.  I can't stop anyone from uploading whatever they want, but I can learn the lesson to never, ever agree to such an FFe again.  What's the date when the patch can be dropped?
[12:01] <yolanda> pitti, no, i didn't see it, can you point me at it?
[12:01] <seb128> ScottK, "when the qpa is ready"
[12:02] <seb128> ScottK, it doesn't make sense to advocate for runtime regressions for users just for the sake of dropping a patch which is creating no issue...
[12:02] <ScottK> i.e. maybe never  and who cares what we agreed.
[12:02] <pitti> yolanda: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-postfix/1/ARCH=i386,label=adt/
[12:02] <seb128> ScottK, well, I do care about fixing it properly, but I don't see the point to break users for the sake of making a point
[12:02] <ScottK> OK.  That's why I asked for when.
[12:03] <ScottK> I didn't say I'd try to stop you adding it back.
[12:03] <seb128> good, sorry that the qpa thing is not ready yet
[12:04] <yolanda> pitti, let me test them locally again
[12:04] <xnox> ScottK: hm?!
[12:04] <ScottK> I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now.
[12:04] <yolanda> i haven't seen that error before
[12:05] <seb128> ScottK, agreed
[12:05] <xnox> ScottK: after last merge by Riddell, there were two patches left, both are in Debian and filed upstream.
[12:05] <pitti> RAOF: do you plan to package colord 1.0 soon? if so, any chance you can import upstream commit 4c6792 to drop the g_type_init() calls, and add a valgrind test dependency? that's the two issues I see on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-colord/
[12:05] <ScottK> seb128: I do, however, consider this going back on an agreement and I'll of course consider that when reviewing FFes in the future.
[12:06] <ScottK> xnox: OK.  I knew about one being in Debian.  I didn't check the other.
[12:07] <seb128> ScottK, hum, that's fair enough, I don't think the request made by then was appropriate (e.g "let's accept it but add a clause that we will regress it early next cycle for no good reason if the new work is not ready yet") but that one is done so no point to discuss it now
[12:07] <ScottK> Then was the time to discuss it, not now.
[12:08] <ScottK> I would be less grumpy about the situation if there was a date beyond "when ready" for dropping this Qt4 forward port.
[12:09] <seb128> well, the guys are working on the QPA support but that's not the only thing they have to work on, and I've no idea how much work that is
[12:09] <seb128> I just know it's being tracked but it's not trivial enough to say "it will be squeezed in an afternoon next week"
[12:10] <seb128> e.g it's going to take some extra time
[12:10] <ScottK> Could you ask for an estimate?
[12:10]  * cjwatson curses at build systems that don't fail immediately
[12:10] <yolanda> pitti, i tested with saucy - amd64 and works locally, let me test with i386
[12:11] <pitti> yolanda: yes, it succeeds on amd64 in jenkins, too
[12:11] <seb128> ScottK, ok, I will try to get one
[12:11] <mitya57> xnox: no, there is also disable_overlay_scrollbars.diff which is not in Debian/upstream
[12:13] <mitya57> it is of course an ubuntu-specific hack, and I don't know if there is another way to fix the issue (see i.e. bug 1170384)
[12:14] <xnox> mitya57: are we talking about the same thing? I was discussing cmake package with scottk.
[12:14] <xnox> mitya57: btw. I could give you ssh access to a panda board if you want to poke qt4-x11.
[12:15] <xnox> pm if you are interested.
[12:15] <mitya57> xnox: I was talking about:
 I think keeping our patches in Qt5 to a minimum and not having them devolve into a unmaintainable mess is an important goal and it has to start now.
[12:15] <mitya57> xnox: not today (I hope it's not urgent)
[12:15] <xnox> ScottK: ^, not me then =) I'm not involved in Qt5 packaging much.
[12:16] <xnox> mitya57: nah. I'll get around to it eventually.
[12:17] <mitya57> xnox: btw, do you have any plans to package pyqt5 or do you want me to do that? :))
[12:18] <xnox> mitya57: i haven't tried it since before they published qt5 preview snapshot.
[12:18] <xnox> i think i did push my latest trial somewhere to launchpad.
[12:19] <mitya57> xnox: ok, I'll look at it next week and let you know if I get any success
[12:20] <mitya57> pitti: fyi, I have dep-8 fixes for docutils and pandas in the sponsoring queue
[12:21] <pitti> mitya57: ah, splendid, thanks
[12:21] <mitya57> (pandas is not yet failing on jenkins, but it doesn't work with the latest nose)
[12:22] <seb128> there is a good stack of tests work in the sponsoring queue
[12:22] <seb128> we need a patch pilot round from somebody from qa :p
[12:22] <seb128> there are like 10 of those waiting
[12:23] <yolanda> pitti, fails for me locally on i386 also
[12:23] <pitti> mitya57: ah, you fixed it in Debian and merged? awesome
[12:23] <pitti> seb128: yeah, I sponsor quite a lot of them (but mostly just if someone pokes me outside of my patch pilot days)
[12:23]  * pitti looks at these two
[12:23] <seb128> pitti, you are piloting next monday I see ;-)
[12:23] <mitya57> pitti: if you speak about nose, then I broke it, not fixed :)
[12:24] <pitti> mitya57: I meant docutils
[12:24] <mitya57> pitti: jwilk fixed that
[12:25] <pitti> +XS-Testsuite: autopkgtest
[12:25] <pitti> mitya57: ^ FYI, this is perfectly fine for Debian
[12:26] <pitti> it's part of the DEP8 spec
[12:26] <pitti> mitya57: and dropping pysupport in Debian will certainly get you applauds from doko, too :)
[12:26] <pitti> mitya57: what is debian/x-rst.xml? (that's not mentioned in the remaining delta)
[12:27] <mitya57> pitti: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=685509
[12:27] <yolanda> pitti, it fails in that regular expression, but looks good to me? child.expect(r'.*[pP]assword', timeout=5)
[12:27] <pitti> yolanda: yeah, hence my suspicion of "bug in python"
[12:27] <pitti> it said "internal error in regex machine" or so
[12:27] <mitya57> pitti: oops, x-rst.xml is an old version of docutils.xml, will now remove it
[12:27] <yolanda> oh yes: RuntimeError: internal error in regular expression engine
[12:28] <yolanda> all the failures are the same
[12:33] <pitti> mitya57: no worries, I can just remove it in the merge
[12:34] <mitya57> pitti: already removed it, and fixed the version number
[12:34]  * pitti pulls again
[12:34] <pitti> mitya57: forgot to push?
[12:34] <mitya57> pitti: no, pushed
[12:36] <mitya57> pitti: looks like mdeslaur just uploaded pandas fix
[12:37] <pitti> heh, me too
[12:37] <mitya57> (thanks!)
[12:37] <pitti> so I guess mdeslaur's will win :)
[12:37] <mdeslaur> oops :)
[12:37] <pitti> mitya57: anyway, thank you! (also uploaded docutils)
[12:37] <pitti> mdeslaur: sorry
[12:37] <mitya57> pitti: thanks
[12:40] <yolanda> pitti, so what we do with that isuse?
[12:40] <cjwatson> Riddell: Was kdegames-data going away intentional?  Looks like that needs some transition work in saucy-proposed.
[12:41] <pitti> yolanda: I suppose as a first step you should report a bug against python3.3; then, maybe you can find a workaround by slightly altering the RE
[12:43] <cjwatson>   ** gcc version 4.8 found, expected gcc 3.x with x>1 or gcc 4.x with 0<x<8!
[12:43] <cjwatson> seriously, virtualbox?
[12:43] <cjwatson> debfx: ^- you might like to have a look at that
[12:54] <Riddell> cjwatson: mm not sure, will look into it thanks
[13:11] <cjwatson> infinity: I synced libnss-db, although you're touched-it-last; I'm pretty sure that Julien's and my QA uploads cover everything we need between them, but feel free to double-check.
[13:26] <Mirv> cjwatson: can you comment on keeping or ditching Architecture line delta to Debian related to powerpc builds? you were mentioned here: http://pastebin.ubuntu.com/5690298/ - we're planning to do uploads/syncs tomorrow
[13:27] <cjwatson> Mirv: please see the discussion in this channel yesterday
[13:27] <Mirv> cjwatson: ok, scrolling back
[13:28] <cjwatson> But I'll address one thing to make sure it sticks: the assertions that proposed-migration prevents migration of packages with FTBFSes is false.  It prevents migration of packages with regressions in the set of builds that worked.
[13:28] <cjwatson> s/is false/are false/.
[13:30]  * cjwatson peers at the sweep package.  So much ugliness that could just be dh_autoreconf
[13:33] <Mirv> cjwatson: thanks, read the discussion
[13:34] <seb128> Mirv, I opened https://bugs.launchpad.net/cupstream2distro/+bug/1182570 on the daily landing tools
[13:34] <seb128> Mirv, didrocks said he would work on it next week I think
[13:34] <didrocks> yep
[13:36] <mardy> kenvandine: hi! Did you see my "categories" branch for the SystemSettings?
[13:36] <mardy> (the branch name doesn't match the content very closely, actually :-) )
[13:36] <kenvandine> mardy, yes... did you see my comment on it?
[13:36] <mardy> kenvandine: obviously not :-)
[13:36] <kenvandine> Looks like you forgot to add SystemSettings.pc.in
[13:36] <kenvandine> :-D
[13:37] <mardy> ops
[13:37] <kenvandine> mardy, i also pushed a fix for my branch you reviewed
[13:37] <mardy> kenvandine: just approved
[13:37] <kenvandine> thx
[13:38] <kenvandine> i'll just merge these to trunk until we get the merger setup for it
[13:38] <kenvandine> mardy, i'm going to add a settings stack for daily release today
[13:38] <kenvandine> and get that configured for the merger, etc
[13:38] <kenvandine> and CI
[13:40] <mardy> kenvandine: looking forward to it!
[13:41] <mardy> cyphermox: hi, thanks for your review. Do you have some names to suggest?
[13:42] <cyphermox> mardy: not really. people who've done Qt and helped you with QMenuModel before?
[13:42] <NikTh>  waiting
[13:42] <cyphermox> mardy: perhaps timo, but he doesn't seem to be around
[13:44] <cyphermox> NikTh: ask in #ubuntu-kernel, but I think your config file for the kernel you're building is incorrect or not found
[13:45] <NikTh> cyphermox: I'm sorry, I just tested some commands on IRC .. to another channel , but the message appeared here too. Sorry. :-)
[13:46] <NikTh> cyphermox: Actually I'm waiting but not for an answer here. I'm waiting for building results.. :-)
[13:46] <kenvandine> mardy, merge conflict now :)
[13:47] <cyphermox> NikTh: ok
[13:48] <mardy> kenvandine: updated :-)
[13:48] <kenvandine> thx
[13:49] <kenvandine> mardy, can you make me an admin of ~system-settings-touch
[13:49] <kenvandine> i want to setup a PPA for CI builds
[13:50] <rsalveti> pitti: I didn't forward that patch upstream as it's only relevant when you're booting in an android kernel
[13:50] <mardy> kenvandine: done
[13:50] <rsalveti> which is what happens only with touch
[13:51] <kenvandine> mardy, thx
[13:51] <rsalveti> but I can give it a try
[13:51] <pitti> rsalveti: yeah, I don't think it hurts to have that working in udev upstream; thanks!
[13:52] <mardy> seb128: about this blueprint: https://blueprints.launchpad.net/ubuntu/+spec/client-s-touch-system-settings
[13:53] <mardy> seb128: you added one item "[mardy] write the "base shell" app: TODO"
[13:53] <mardy> seb128: isn't that the same as the first item?
[14:00] <kenvandine> mardy, not part of this merge, but i just noticed some copy and paste noise, like a reference to signon-ui.pot in src.pro
[14:02] <mardy> kenvandine: oh, that might be. I'll check
[14:02] <kenvandine> mardy, i've merged this branch, just clean that up in your next branch
[14:03] <mardy> kenvandine: OK
[14:27] <stgraber> pitti: hey, so I'm definitely loosing ACLs on /dev/snd/* every so often, it's not directly related to suspend/resume but it does happen every few days or so (may be related to some package updates)
[14:27] <stgraber> (physical sound card)
[14:35] <cjwatson> pitti: I'm trying to figure out why all our livefs builds are hanging, and it turns out that there's a stray 'udevd --daemon' process running, started a rather suspicious 40 seconds after the start of the build.  Do you know what might have regressed here?
[14:36] <cjwatson> pitti: Specifically, started during debootstrap
[14:39] <cjwatson> pitti: I notice we no longer have the udevadm.upgrade stuff; might that be relevant?
[14:42] <cjwatson> pitti: This appears to be the same as bug 1182540
[14:53] <seb128> mardy, yes, seems so, sorry I just dumped the session notes in there and didn't check for duplicates
[15:03] <slangasek> mlankhorst: pong
[15:04] <pitti> re
[15:04] <pitti> cjwatson: ah, I didn't really see why disabling udevadm is related to starting/stopping the daemon
[15:04] <cjwatson> I suspect something else calls udevadm which starts udevd
[15:05] <pitti> cjwatson: so I'll put it back; it's almost certainly due to dropping these bits, yes
[15:05] <cjwatson> I have an strace but it's gigantic
[15:05] <pitti> I'll use above bug for that
[15:05] <pitti> shouldn't be too hard to reproduce
[15:05] <cjwatson> just debootstrap and you'll find an extra udevd --daemon process hanging around when you're done
[15:06] <pitti> *nod*
[15:07] <mlankhorst> slangasek: can you accept all the new packages in precise?
[15:07] <pitti> stgraber: does that only affect /dev/snd/*, or other devices as well
[15:07] <cjwatson> Hm, it actually looks as though it's being started directly
[15:07] <cjwatson> 11398 write(1, " * Starting the hotplug events dispatcher udevd\n", 48) = 48
[15:08] <cjwatson> Why is that touching /etc/init.d/udev ...
[15:08] <slangasek> mlankhorst: I don't think I'll have a chance to look at it this morning; maybe SpamapS has some time?
[15:08] <pitti> hm, where does that string come from; doesn't look like /etc/init/udev.conf
[15:08] <cjwatson> /etc/init.d/udev
[15:08] <mlankhorst> slangasek: friday's fine too, it's been lingering for ages in NEW
[15:09] <SpamapS> slangasek: definitely not. I'm wrangling contractors today
[15:09] <cjwatson> Via invoke-rc.d, WTF
[15:09] <stgraber> pitti: assuming I should have an ACL on /dev/dri/card0, it affects all devices, though I think sound devices are more visible as pulseaudio appears to close them and reopen rather frequently (whereas the dri devices are kept open)
[15:10] <pitti> cjwatson: hm, I assume we have a policy-rc.d somewhere?
[15:10] <cjwatson> Ah
[15:10] <cjwatson> This might be a debootstrap bug
[15:10] <cjwatson> It has a fake initctl which doesn't respond to initctl version
[15:10] <cjwatson> Which invoke-rc.d now cares about
[15:10] <pitti> oh, I remember slangasek's mail about that
[15:11] <cjwatson> So I could make it pass through version and see if that helps
[15:12] <cjwatson> Something like http://paste.ubuntu.com/5690668/
[15:13] <pitti> double quoting?
[15:13] <pitti> ah, I guess it's a script that writes a script
[15:13] <pitti> right, nevermind me
[15:14] <slangasek> cjwatson: hah, doh
[15:15] <cjwatson> Wonder what else might have a similar bug
[15:16] <pitti> stgraber: do you still have a running session? ("loginctl show-session")
[15:17] <cjwatson> debian-installer-utils and ubiquity at least
[15:17] <cjwatson> With any luck that's the limit of the clone-and-hack
[15:17] <slangasek> why is this not done via policy-rc.d?
[15:18] <cjwatson> It installs a policy-rc.d as well
[15:18] <cjwatson> I believe this is insurance against policy-violating packages
[15:18] <cjwatson> Of which there were many more earlier on
[15:19] <cjwatson> I mean, even openssh was at best skating on very thin policy until this morning
[15:19] <stgraber> pitti: http://paste.ubuntu.com/5690694/
[15:20] <stgraber> pitti: loginctl also says "c2     201105 stgraber         seat0" so the session is definitely registered
[15:20] <cjwatson> Yep, that debootstrap change appears to fix it - just testing a bit more and I'll upload
[15:20] <pitti> cjwatson: thanks
[15:20] <cjwatson> Wonder if gina's unstuck yet
[15:21] <pitti> stgraber: can you check if the devices have TAGS=:uaccess in "udevadm info --export-db|less"?
[15:21] <stgraber> pitti: E: TAGS=:seat:uaccess:
[15:21] <pitti> ok
[15:21] <stgraber> (looking at /dev/dri/card0 in this case)
[15:21] <pitti> stgraber: do the ACLs come back if you switch to VT1 and back?
[15:22] <pitti> stgraber: you can also try "sudo udevadm trigger --sysname-match=card0 --verbose"
[15:23] <stgraber> pitti: hmm, well, interstingly enough I can't switch vt... ctrl+alt+FX won't work and chvt won't either
[15:23] <pitti> stgraber: try the udev trigger?
[15:24] <stgraber> pitti: the udevadm trigger didn't help, still no ACL for my user on the device
[15:25] <stgraber> pitti: starting to wonder if I somehow hit a kernel bug... stracing chvt I'm seeing "ioctl(3, KDGKBTYPE, 0x7fffbecbf14f)     = -1 ENOTTY (Inappropriate ioctl for device)" when trying to do the ioctl against any of /dev/tty, /dev/tty0 or /proc/self/fd/0
[15:26] <stgraber> oh, actually that's wrong, tty0 doesn't give the ENOTTY
[15:26] <stgraber> but it doesn't quite work either
[15:26] <pitti> stgraber: otherwise, the output of this might give some insight:
[15:26] <pitti> sudo strace -fvvs1024 udevadm test-builtin uaccess /devices/pci0000:00/0000:00:02.0/drm/card0
[15:26] <stgraber> http://paste.ubuntu.com/5690716/
[15:26] <pitti> stgraber: the sysfs path probably doesn't match for you, you can look it up in udevadm info --export-db
[15:27] <pitti> stgraber: hm, wait -- I remember that I've seen something like this in otto
[15:27] <pitti> stgraber: i. e. with ACLs in a container
[15:27] <pitti> stgraber: you run your whole desktop in LXC, right?
[15:27] <stgraber> pitti: strace => http://paste.ubuntu.com/5690719/
[15:28] <cjwatson> slangasek: Ah, though it's true that if we had a policy-rc.d that would have acted as a stopgap.  We have that in other stop-daemons-running code but *not* in debootstrap
[15:28] <stgraber> pitti: nope, that's a fairly standard desktop machine, I have a container running though but it doesn't have tty access
[15:28] <cjwatson> So I think I should fix both
[15:29] <pitti> cjwatson: so disabling udevadm during package upgrade wouldn't help at all here, right? (as the daemon is not normally started through udevadm)
[15:29] <slangasek> pitti: udevadm needs to be disabled during package upgrade anyway; was that change dropped?
[15:29] <pitti> stgraber: ok, comparing mine to your's, I have getxattr() == 44, then setxattr() == 0, and the writev("unload module index"), your's is missing the setxattr
[15:30] <stgraber> right, that confirms it's not even trying to set the ACL, doesn't really tell us why
[15:30] <pitti> slangasek: it wasn't ported over, yes; what's wrong with running udevadm during package upgrade?
[15:30] <cjwatson> pitti: It's unrelated, but as slangasek says, I believe it's important for packages not to be able to call udevadm during udev package upgrade for the same reason it always was
[15:30] <cjwatson> Let me dig up Scott's post about it
[15:30] <pitti> yeah, I'm curious why that is
[15:30] <stgraber> though I wonder if my messed up VTs could somehow break the code that detects whether I'm at the console or not
[15:31] <pitti> at least info works just fine without udevd
[15:31] <pitti> it just reads /run/udev, it doesn't query the daemon
[15:31] <slangasek> pitti: I think that's the wrong question; why would you drop any part of the packaging before knowing why it was there?
[15:31] <cjwatson>   * It is not permitted to call udevadm trigger or settle during an upgrade
[15:32] <cjwatson>     without depending on udev.  Attempting this will fail.
[15:32] <cjwatson> was the specific one
[15:32] <slangasek> yes
[15:32] <pitti> well, that's not much of an explanation
[15:32] <slangasek> there were lots of upgrade failures because of this
[15:32] <cjwatson> And info is a complete red herring, because udevadm.upgrade *passed through info calls*!
[15:32] <pitti> and both trigger and settle work fine without udevd
[15:32] <pitti> so that seemed obsolete to me
[15:33] <pitti> I can add it back, but it seems like unnecessary complexity to me
[15:33] <slangasek> how can 'trigger' work without udevd?
[15:33] <cjwatson> This was associated with https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027260.html
[15:33] <cjwatson> Although that doesn't really explain it very well either
[15:33] <pitti> slangasek: the trigger operation works fine, but of course rules wouldn't be processed
[15:34] <stgraber> slangasek: IIRC trigger just uses /sys/..../uevent to re-emit the uevent
[15:34] <pitti> but that's just the same net result as diverting udevadm trigger and saying that it won't work
[15:34] <cjwatson> So I think Scott was concerned precisely that rules wouldn't be processed, and was trying to force packages to get this right
[15:34] <cjwatson> Even if udevadm "works" (i.e. exits 0)
[15:35] <pitti> ah, so that's not for *preventing* package installation failures, but for *causing* them to expose problems
[15:35] <slangasek> cjwatson: but if 'udevadm trigger' now passes with no effect, how does that enable the caller to retry later?
[15:35] <pitti> so in that regard we could put it back, but if anything that should cause more install failures, not less
[15:36] <cjwatson> slangasek: indeed I'm arguing that we should put the previous implementation back because it's better to fail than to do the wrong thing
[15:36] <slangasek> ah
[15:36] <slangasek> the previous implementation failed?
[15:36] <cjwatson> especially given that this has been intentionally failing for four years, so it's not a hidden source of problems
[15:36] <slangasek> oh, right
[15:37] <cjwatson> if [ "${0##*/}" = "udevtrigger" ] || [ "$1" = "trigger" ]; then
[15:37] <cjwatson>     echo "udevadm trigger is not permitted while udev is unconfigured." 1>&2
[15:37] <slangasek> yes, now I have the right end of the stick
[15:37] <cjwatson>     exit 1
[15:37] <cjwatson> fi
[15:37] <cjwatson> etc.
[15:37] <slangasek> yes, so udevadm would be called but we would lose the trigger
[15:37] <slangasek> (potentially)
[15:37] <tvoss> seb128, ping
[15:37] <seb128> tvoss, hey
[15:37] <pitti> so I guess what that really wants to say is that udevadm trigger should fail if udevd isn't running
[15:38] <pitti> (udevadm settle, info, monitor, hwdb, test, etc. are all fine)
[15:38] <cjwatson> pitti: If it causes install failures, we've been seeing those for four years, so they aren't new - it's basically an assertion about the correct design of other packages using udevadm
[15:38] <cjwatson> The previous implementation explicitly excluded settle as well
[15:38] <pitti> ok
[15:38] <cjwatson> And doesn't settle also essentially require rules to be in place?
[15:39] <pitti> trigger does (as that will cause re-processing the rules)
[15:39] <pitti> settle just waits for udevd to finish with this, but if there's no udevd, there's nothing to wait for
[15:39] <cjwatson> Mm, I suppose ...
[15:40] <pitti> anyway, I'll put it back
[15:40] <slangasek> right, furthermore I heard 'settle' no longer works upstream
[15:40] <pitti> sorry for the misunderstanding
[15:40] <cjwatson> if udevd isn't running> provided, basically, that udevd works as if it were Essential and can operate even when the package is unconfigured
[15:40] <cjwatson> pitti: It's not this critical bug affecting lxc and livefs builds, anyway, so you can take a little more time about it if you like
[15:41] <pitti> cjwatson: yeah, I won't get to that today any more anyway
[15:41] <cjwatson> I've stolen that bug and will sort it out
[15:44] <pitti> filed as bug 1182948
[15:45] <pitti> slangasek: why doesn't "settle" work any more? there's even a systemd unit for it
[15:49] <slangasek> pitti: I don't know; it's just something I heard, perhaps I heard wrong
[15:51] <ion> mvo: Any thoughts about this? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1182932
[15:52] <mvo> ion: I think that is a good idea
[15:52] <mvo> thanks for working on this!
[15:53] <ion> No problem, it was little effort.
[15:54] <mvo> ion: any preferences what I should put in the changelog?
[15:55] <ion> “[Johan Kiviniemi]”, “* Add PPA keys to /etc/apt/trusted.gpg.d/{owner}-{ppa}.gpg” perhaps? Feel free to write anything you like.
[15:55] <mdeslaur> @pilot out
[15:58] <ion> mvo: Hmm, i suppose apt-key should be patched to create keyring files using a more permissive mode than 0600.
[15:59] <mvo> ion: hm, 0644 should be ok
[15:59] <davmor2> mvo: how do chap, how's life?
[16:00] <mvo> ion: commited, thanks, I will upload in a bit
[16:00] <mvo> davmor2: hey! nice to see you. I'm good, how are you?
[16:01] <davmor2> mvo: I'm well thanks, busy as hell, but that is good too :)
[16:02] <mvo> davmor2: haha, indeed! nice to see all the progress on the touch front, its very exciting to watch
[16:03] <ion> mvo: I fail to see a gpg parameter to set the mode. Perhaps a chmod in apt-key after running gpg when --keyring was given? For every invocation or only when we detect a new keyring file was created?
[16:05] <mvo> ion: I think its ok to keep 0644, /etc/apt/trusted.gpg is also 0644
[16:18] <mlankhorst> 666 ofc
[16:19] <mlankhorst> trust goes both ways right?
[16:45] <tvoss> slangasek, ping
[16:45] <slangasek> tvoss: hi
[17:03] <debfx> cjwatson: re virtualbox: is it urgent to fix that? otherwise I'd fix it through Debian once it has migrated to testing.
[17:14] <tvoss> gema, ping
[17:15] <tvoss> slangasek, is there a wiki page around somewhere that captures any resource measurement things
[17:15] <tvoss> ?
[17:17] <slangasek> tvoss: I believe there is...at least there's one that lool created
[17:18] <slangasek> but I don't remember the page and don't see it linked from https://wiki.ubuntu.com/Touch/
[17:19] <slangasek> tvoss: ah, https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage - should maybe be converted to live under Touch/
[17:23] <gema> tvoss: pong
[17:54] <tvoss> slangasek, thanks
[17:54] <tvoss> gema, did you start summarizing the memory measurement work, yet?
[17:56] <gema> tvoss: we are looking into the stacked graphing you showed me
[17:57] <gema> tvoss: doanac is leading this work and can give you previews as we make progress
[17:57] <gema> doanac: ^
[17:58] <tvoss> gema, cool. but I'm looking for a wiki page documenting the current work
[17:58] <gema> tvoss: if you are referring to the memory performance indicator (the summary page) we haven't started that one yet
[17:58] <gema> tvoss: this is where the work is being tracked: https://blueprints.launchpad.net/ubuntu/+spec/qa-s-dashboard
[18:06] <pmcgowan> cjohnston, hey can ask you some questions on how topics and blueprints work
[18:20] <doanac> tvoss: documenting the plan to improve the view or a document about the existing view?
[18:21] <tvoss> doanac, documenting the measurement approach :) not necessarily the UI
[18:22] <doanac> tvoss: ah - okay. will do and get back to you on it
[18:23] <tvoss> doanac, perhaps you can take it from here https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage and move it to Touch. Would you mind keeping me and jasoncwarner in the loop?
[18:24] <doanac> tvoss: okay. also an idea: instead of doing this in the wiki. would it make more sense to put these explanations in the views themselves?
[18:25] <tvoss> doanac, for step two: yes, having a wiki page would help on a short timescale
[18:26] <doanac> tvoss: okay. will do and will keep jason in the loop as well
[18:26] <tvoss> doanac, awesome, thank you
[18:27] <ion> mvo: Does this look okay? https://github.com/ion1/apt/commits/debian/sid
[18:39] <cjohnston> pmcgowan: you can
[18:43] <pmcgowan> cjohnston, if I want to define new topics and associate blueprints to them, is that all done via bp dependencies?
[18:43] <pmcgowan> what makes a topic show up
[18:43] <pmcgowan> for ubuntu-s status tracking that is
[18:47] <cjohnston> pmcgowan: IIRC lool made a doc on it last cycle. trying to find it
[19:07] <ScottK> wgrant: Still not picked up.  How's it going?
[19:12] <roaksoax> howdy! Has something change in saucy that symlinks (in /etc/init.d) are no longer being create for upstart jobs
[19:12] <roaksoax> ?
[19:13] <infinity> roaksoax: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html
[19:13] <roaksoax> infinity: thanks!!
[19:16] <ev> pitti: ooh, thanks! Will do!
[19:20] <roaksoax> infinity: what about for packages that do not exist in debian and have no init script, any ideas what's needed to get to work correctly?
[19:24] <rbasak> roaksoax: just the upstart job, surely? Why do you need init.d symlinks?
[19:25] <rbasak> Forget I said that. I'm being stupid.
[19:26] <roaksoax> rbasak: I don,t but dh_installinit is add a check of "if [ -x "/etc/init.d/XYZ" ]; then", which means that invoke-rc.d will never be called, hence the server will never start on postinst
[19:26] <roaksoax> is adding*
[19:26] <roaksoax> s/server/service
[19:31] <barry> bdmurray: lp: #1173704
[19:49] <ScottK> barry: You should ask doko to push your python-imaging change to Debian (if you didn't) and phatch is PAPT maintained.
[19:58] <stgraber> lifeless, barry: so where do we meet? hangout?
[19:58] <lifeless> yeah
[19:58] <lifeless> sounds good, let me see
[20:00] <lifeless> stgraber: barry; sent you a hangout invite, no response :P
[20:05] <roaksoax> infinity: --upstart-only doesn't seem to make an effect
[20:06] <barry> lifeless, stgraber sorry i was a bit late, looking for the invite now
[20:51] <cjwatson> debfx: as long as it's in the next couple of weeks, I guess that's fine
[21:02] <Logan_> Has anyone been noticing that new Debian versions aren't being picked up by LP, according to syncpackage?
[21:05] <stgraber> Logan_: is the source package name > gdb? :)
[21:05] <Logan_> Yup...
[21:05] <stgraber> so yeah, known issue
[21:06] <Logan_> Bug link?
[21:06] <stgraber> good question, I just saw that mentioned a couple of times on IRC, there's probably a bug against Launchpad/the package importer
[21:07] <Logan_> Not seeing any. :/
[21:08] <stgraber> Logan_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709118
[21:08] <cjwatson> Yeah, it's being fixed
[21:08] <cjwatson> wgrant is applying a workaround in LP at some point
[21:09] <Logan_> Ooh, awesome.
[21:09] <Logan_> Thanks guys!
[21:09] <cjwatson> Ideally we'd be able to work out why that got accepted in Debian in the first place, as the code says it shouldn't have done
[21:10] <cjwatson> Ansgar's best guess observes that the lintian command in question is run through sudo and that maybe sudo fell over
[21:10] <cjwatson> But without dak privileges on ftp-master.d.o I can't really check
[21:14] <ScottK> DktrKranz: ^^^ maybe you could ...
[21:14] <Laney> cjwatson: Couldn't it be because dak checked the _amd64.changes which doesn't seem to be invalid: http://packages.qa.debian.org/g/gdb/news/20130520T194802Z.html
[21:15] <Laney> (didn't check what that lintian check actually does, mind)
[21:15] <cjwatson> Laney: It's the .dsc that's invalid, and lintian does fail on the _amd64.changes (which is sourceful) when run manually
[21:16] <cjwatson> Even when run manually on franck, I'm told (I've only tried on ries myself)
[21:17] <Laney> ho hum
[21:19] <cjwatson> Furthermore, 'dak process-upload' rejects it when run by hand
[21:19] <cjwatson> All a bit mysterious really
[21:23] <cjwatson> Logan_: It's annoying me though so don't fear it'll get forgotten.  Also I will notice when it gets fixed in the form of a gigantic mail from auto-sync, I expect ...
[21:29] <cjwatson> debfx: Ah, I see you fixed it anyway - thanks
[21:31] <Noskcaj> kirkland, can you merge some of the changes into testdrive? Andres has been rather slow to respond
[21:42] <cjwatson> Riddell: I've uploaded rebuilds of the stuff that was still depending on libkdegamesprivate1, which should be enough to get it past proposed-migration
[21:42] <cjwatson> Didn't test-build them all but the result of test-building kapman looked plausible
[21:55] <doko> rbasak, so what about rebuilding all the facter stuff?
[21:58] <cjwatson> Riddell: Oh, except kmahjongg apparently needs adjustment because libkmahjongg took over one of its binary packages?  Not going to worry about that now - bedtime.
[21:59] <rbasak> doko: I've fixed facter in bug 1173265 - infinity said he'd review and sponsor soon
[21:59] <rbasak> doko: is the puppet failure due to facter?
[23:29] <NikTh> Here I am again. You will never get rid of me :P New build error. As I guess I must add something in debian/rules, but what ? Error here: https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz
[23:46] <wgrant> cjwatson, ScottK: Working on getting the fix deployed... a bit difficult atm.