[01:45] <ScottK> pitti: Did the retracer die again?
[02:04] <micahg> BenC:  you might want to chat with Laney about the potential for ghc 7.4.2 in quantal before rebuilding the world again
[02:05] <BenC> micahg: I'm speaking with erikd about the fixes so far
[02:05] <BenC> This last build is final for me
[02:06] <micahg> BenC: I was referring to the no change rebuilds you uploaded (as any ghc update will require them to happen again)
[02:06] <ScottK> Laney's not top uploader for Quantal yet, so I'm sure he wouldn't mind rebuilding the world a few times.
[02:07] <BenC> micahg: Ah, well, it was only an ABI rebuild for ppc, but yeah, I'm trying to handle the buildX uploads gently
[02:08] <micahg> well, queue seems to be empty anyways, I thought he had the fix for armel as well which would mean we could do a full rebuild across the board
[02:09] <micahg> ah, it's being worked on elsewhere I see :)
[02:39] <scientes> does -dev package multi-arch work in quantal?
[02:39] <scientes> cause i want to do this type of stuff https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompile
[02:40] <scientes> make my package support it
[02:43] <RAOF> scientes: Yes, as long as your -dev package is consistent across architectures.
[02:48] <scientes> but not in precise?
[02:49] <scientes> i tried to install the build-deps and i couldn't even install libc6:armhf
[02:50] <RAOF> Not all -dev packages are multiarchable.
[02:50] <scientes> yeah, my package is multi-arch
[02:50] <scientes> but i want it to be cross-buildable the multi-arch way
[02:50] <scientes> https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompile
[02:51] <RAOF> Installing libc6:armhf will require you to have the ability to execute armhf code.
[02:51] <scientes> only if you want to run it
[02:51] <scientes> but besides that i have qemu-user-static
[02:52] <scientes> just using it to link against with the cross-toolchain included in ubuntu is a perfectly reasonable use-case
[02:52] <RAOF> No, the dpkg triggers will run armhf code.
[02:52] <RAOF> ie: installing it will attempt to execute armhf code.
[02:52] <RAOF> If you've got qemu-user-static that should work, though.
[02:52] <scientes> oh, well i do have qemu-user-static installed
[02:52] <scientes> its failing on tzdata:armhf not installable
[02:52] <RAOF> I'm not sure why that's the case.
[02:53] <RAOF> libc6 is certainly multiarch in Precise.
[02:53] <RAOF> And I've tested libc6:amd64 + libc5:i386; there's no obvious reason why libc6:armhf would be different.
[02:53] <RAOF> Except for arm being crack, of course :)
[02:53] <scientes> libc5!
[02:54] <scientes>  libc6:armhf : Depends: tzdata:armhf but it is not installable
[02:54] <RAOF> Heh. libc6:amd64 + libc6:i386 :)
[02:55] <scientes>  libc6:armel : Depends: tzdata:armel but it is not installable
[02:57] <StevenK> But tzdata is arch all?
[02:58] <scientes> exactly
[02:58] <scientes> oh
[02:58] <scientes> maybe I need [arch=i386,amd64,all]
[02:58] <scientes> ?
[03:00] <micahg> hrm, tzdata is marked multiarch foreign, at least in precise
[03:01] <TheMuso> Same in quantal.
[03:02] <micahg> this sounds familiar
[03:08] <scientes> i can't test "cross-compiling" to i386 either, cause there is no seperate compiler
[03:08] <scientes> but anyways, i guess i can fix it to work, instead of not working
[03:08] <scientes> even though few care
[03:10] <scientes> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613584
[04:20] <OdyX> pitti: thanks for the pyppd sync: letting uploads arrive "first" in Debian is very appreciated, really.!
[04:20] <pitti> ScottK: yes, it did; restarted again, need to see what's upsetting gdb now
[04:21] <pitti> OdyX: makes things easier and better for everyone :)
[04:21] <ScottK> pitti: Thanks
[04:24] <OdyX> pitti: ^5!
[04:24] <pitti> :)
[04:25] <OdyX> I should really put more time into making sure tkamppeter has the proper rights to do his foomatic-* uploads in Debian first; I'm yet to convince him.
[04:32] <ScottK> pitti: Can you perhaps prioritize what gets retraced next?  1023231 may relate to newly released hardware and I'd like to let upstream know about it ASAP if it does.
[04:33] <pitti> ScottK: there are only some 30 bugs to retrace, that ought to finish in half an hour or less
[04:34] <pitti> but it seems the core dump in bug 1019781 makes gdb hang forever
[04:34] <ScottK> pitti: ok.  It got through 6 of the i386 ones yesterday before it died again, so I wasn't optimistic.
[04:34]  * pitti untags and restarts
[04:34] <pitti> 07/12/12 04:32:04: retracing #1019781 (left in pool: 54)
[04:34] <pitti> ok, 54
[04:35] <ScottK> At least you've got a reliable test case now.
[04:37] <pitti> untagged that bug and restarted; /me locally runs apport-retrace -S system -sv 1019781
[04:37] <pitti> ah, won't work, i386
[04:37] <pitti> anyway, I'll look into it
[04:40] <StevenK> pitti: You'll have to blow the dust off your i386 chroot?
[04:40] <pitti> StevenK: I don't have one; fortunately apport-retrace makes it quite a bit easier to retrace an i386 bug on amd64 :)
[05:37] <pitti> ScottK: oh, it caught up on i386 now
[05:42] <ScottK> Yeah.
[05:42] <ScottK> Trying to make sense of the backtrace now.
[06:45] <jussi> morning all
[06:45] <jussi> was there a decision taken to not make alternate cd's anymore ?
[07:00] <pitti> jussi: as soon as Ubiquity gets taught to handle LVM and encrypted partitions
[07:00] <jussi> pitti: ahh, good, that woul have been my objection to dropping it :)
[07:04] <dholbach> good morning
[07:26] <pitti> bdmurray: would it still be possible to set up http://reports.qa.ubuntu.com/reports/bug-fixing/quantal-fixes-report.html ? I. e. can it scan the quantal-changes@ archives, or does it need to be subscribed from day 1?
[08:33] <apw> i see gpg/ssh key timeout options have gone in quanta (are those from seahorse?), are they reenablable ?  security is going to be grumpy
[08:36] <seb128> apw, bug #987167 ?
[08:53] <mpt> ev, fixed examples of "[Invalid UTF-8]" include bug 837246 and bug 874194; open examples include bug 874755, bug 841821, and bug 823649.
[08:53] <ev> mpt: thanks! I'll have a look
[08:55] <seb128> how do the copies from quantal-proposed to quantal happen?
[08:55] <seb128> like unity in proposed seems ready to be copied
[08:55] <seb128> will that happen automatically? or should we ask for the copy? or just do the copy?
[09:01] <cjwatson> seb128: It's all manual right now.  What set of packages need to be moved?
[09:02] <cjwatson> And is the set that's on pending-sru complete and coinstallable
[09:02] <cjwatson> ?
[09:04] <seb128> cjwatson, the set is "nux unity unity-2d unity-lens*"
[09:04] <seb128> cjwatson, it's at the bottom of the pending-sru, it's supposed to be complete if we didn't overlook something
[09:04] <seb128> cjwatson, what do you mean "coinstallable"?
[09:05] <cjwatson> Installable at once
[09:05] <seb128> yes
[09:05] <cjwatson> Won't break upgrades, that kind of thing
[09:05] <cjwatson> I have no easy way to verify because we don't have tools :)
[09:05] <pitti> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html should give some good hints, though
[09:05] <seb128> ok, I was unsure how far the tool writing went so far
[09:06] <pitti> that says unity is uninstallable
[09:06] <pitti> which it isn't in quantal
[09:06] <cjwatson> no, those are just NBS binaries
[09:06] <cjwatson> check the version
[09:06] <seb128> pitti, "unity 5.12-0ubuntu4 produces uninstallable binaries: "
[09:06] <seb128> let me try in a vm to be sure
[09:06] <pitti> ah, I see
[09:06]  * seb128 fires virtualbox
[09:07] <cjwatson> fires or fires up? :-)
[09:07] <seb128> fires up :p
[09:07] <cjwatson> English is such a wonderfully ambiguous language sometimes
[09:11] <seb128> @english: yeah ;-)
[09:11] <udevbot> Error: "english:" is not a valid command.
[09:11] <seb128> cjwatson, pitti: ok, I booted yesterday's daily iso, enabled quantal-proposed, apt-get update && dist-upgrade goes well, everything is going to be upgraded, only libunity-core-5.0-5  is to be uninstalled
[09:12] <seb128> which is normal, everything got transitioned to the new soname
[09:12] <seb128> and the old lib doesn't work with the new unity
[09:12] <seb128> cjwatson, can we get the set copied to quantal? ;-)
[09:13] <pitti> seb128: sru-release -r quantal unity otherpkg ...
[09:13] <cjwatson> In progress now
[09:13] <cjwatson> done
[09:13] <pitti> erk, /me notices a typo in --help
[09:14] <pitti> "Copy to release pocket instead of -proposed"
[09:14] <pitti> that should be -updates, fixing
[09:14] <cjwatson> Er, no!
[09:14] <cjwatson> Oh, sorry, yes, you're right
[09:14] <didrocks> thanks cjwatson :)
[09:14] <pitti> done
[09:14] <cjwatson> (Sorry, my wife was talking to me at the same time, cognitive leakage)
[09:15] <seb128> cjwatson, thanks
[09:15] <pitti> cjwatson: no worries :)
[09:15] <pitti> "Copy to release pocket instead of -updates", that's better
[09:16] <seb128> cjwatson, btw I did half a dozen test installs yesterday I never hit the ubiquity bug :-(
[09:17] <cjwatson> Makes two of us.  Let's see what jenkins says today, I guess
[09:18] <seb128> yeah, once we get an iso ;-)
[09:23]  * apw wonders if we are aware gvfs-mount -u has stopped working
[09:23] <seb128> apw, not that I know about
[09:24]  * apw files a bug
[09:24] <seb128> is that quantal?
[09:24] <seb128> what error do you get?
[09:25] <apw> seb128, quantal yes: "Error finding enclosing mount: Containing mount does not exist"
[09:25] <seb128> what do you try to unmount?
[09:25] <apw> a usb stick
[09:26] <seb128> can you umount it?
[09:26] <seb128> or does that fail as well?
[09:26] <apw> i can unmount it from nautilus
[09:26] <seb128> hum, ok
[09:26] <seb128> could be an udisks2 fallout..
[09:27]  * apw is suspicious its /run/media/ fallout
[09:28] <seb128> apw, how do you try to umount it? gvfs-mount -u /dev... or /mountpoint ?
[09:28] <apw> seb128, -u mountpoint
[09:28] <seb128> ok, that works on precise
[09:29] <apw> yep it worked on this machine before updating too indeed, and still does on my other box ->
[09:29] <seb128> I'm still on precise and I can't really test that in my vm, the usb stick mounts on the real box, not in the vm
[09:29] <seb128> ok
[09:29] <seb128> I guess it's a bug for pitti ;-)
[09:33] <apw> seb128, pitti, bug #1023815
[09:33] <seb128> apw, thanks
[09:38] <pitti> apw: thanks, will have a look at it
[09:43] <seb128> pitti, danke
[10:11] <pitti> seb128: FYI, the i386 retracer hung again this morning, I untagged the bad bug and it caught up now
[10:11] <pitti> seb128: I can reproduce the gdb hang
[10:11] <seb128> pitti, thanks, do you know what in the bug lead to the hang?
[10:11] <seb128> oh, gdb bug, great...
[10:11] <pitti> gdb is spinning with 100% CPU when calling it on the core dump
[10:12] <pitti> it's not even doing the bt yet
[10:12] <pitti> _llseek(10, 135168, [135168], SEEK_SET) = 0
[10:12] <pitti> ad infinitum
[10:13] <apw> are we aware of some quantal indicator menus having back colours ?
[10:15] <seb128> apw, bug #1015488
[10:15]  * apw idly wonders how seb128 keeps all these bug numbers in his head
[10:15] <apw> (and thanks once again)
[10:15] <seb128> apw, I don't but the firefox awesome bar is called "awesome" for a reason ;-)
[10:16] <apw> heh that is awsome
[10:25] <pitti> seb128, ScottK: FYI, bug 1023835
[10:25] <seb128> pitti, thanks
[10:25] <pitti> ev: ^ this might actually affect "your" retracers as well
[10:26] <ev> pitti: ah, yikes
[11:09] <apw> cjwatson or pitti, can you recall what consumes the modules.*map files that depmod makes?
[11:13] <cjwatson> apw: used to be hotplug stuff; depmod(8) says they're "largely deprecated"
[11:13] <cjwatson> though I wouldn't want to risk removing them without a thorough audit
[11:14] <apw> cjwatson, well kmod no longer makes them
[11:14] <apw> and htey have been off by default in debian since forever, as we carry a patch to turn them back on
[11:14]  * apw removed them from his system and reboots, lets find out
[11:15] <cjwatson> I suspect it's probably OK
[11:15] <apw> well my fairly 'standard' machine boots fine without them
[11:16] <apw> most annoying to have this wrinkle else i'd be happy to say lets follow debian and switch
[11:16]  * apw will do some wider testing next week with his team
[11:17] <pitti> apw: I'm not aware of anything that still uses them
[11:17] <apw> no i can't find anything in udev using them which would be my primary expectation
[11:17] <pitti> apw: there are now binary maps which greatly speed up dependency calculation, AFAIR
[11:18]  * pitti needs to leave for some two hours, bbl
[11:18] <apw> pitti, yeah i suspect its done a differnet way now
[11:18] <pitti> apw: modules.dep.bin, presumably
[11:24] <apw> pitti, yeah that one i presume
[11:25] <apw> pitti, i assume hal used to use them
[11:32] <apw> cjwatson, any suggestions as to how one might review this?
[11:34] <cjwatson> Not sure really.  I note that modules.*map here have atimes of 26 June
[11:34] <cjwatson> Which is a bit after their mtimes, but I think that corresponds to the time of my nightly backups shortly after they were created
[11:35] <cjwatson> So that suggests to me that they're unused here at least
[11:35] <cjwatson> (And in particular those atimes are considerably earlier than my last reboot)
[11:36] <apw> cjwatson, my *map atimes files on precise are all the same as the mtimes
[11:39] <apw> cjwatson, same on another box
[12:13] <cjwatson> gema: No jenkins run with 20120712?
[12:13] <cjwatson> (Ubuntu desktop)
[12:14] <gema> cjwatson: babyface told me the images were late
[12:14] <gema> cjwatson: we have a problem with jenkins, it does not start jobs automatically
[12:14] <gema> cjwatson: if the images are ready I will start them manually
[12:15] <gema> cjwatson: on their way
[12:17] <cjwatson> Yeah, they are, finished about an hour and a half ago
[12:17] <gema> cjwatson: ack, we will be starting things manually until we figure out why jenkins is not triggering the jobs
[12:17] <gema> cjwatson: if you see any obvious misses, just let us know
[13:13] <pitti> apw: not sure what hal would have done with them, but if so, it couldn't be important
[13:44] <BenC> Any chance some one could process haskell-resourcet NEW for me, please?
[13:44] <BenC> Lots of stuff dep-waits on that
[13:45] <Laney> BenC: I advise you not to rebuild very much; 7.4.2 will be brought over soon.
[13:45] <Laney> once Erik commits a version of your patch, in fact.
[13:45] <BenC> Laney: I'm not rebuilding anything, just pushing the FTBFS queue
[13:45] <Laney> well, that too
[13:45] <Laney> it'll all have to be rebuilt anyway
[13:45] <BenC> Well, this NEW will need to be processed sooner or later
[13:46] <Laney> sure
[13:46] <BenC> best now before you crush a rebuild of everything, so nothing waits on it :)
[13:46] <BenC> Same for haskell-configurator
[13:56] <cjwatson> BenC: Done
[13:56] <cjwatson> (both)
[13:57] <cjwatson> It's arguable which is best, since powerpc build time is a bit contended
[13:57] <cjwatson> But I would have done it at some point anyway if I hadn't seen this conversation, so :)
[13:57] <BenC> cjwatson: thanks
[13:59] <dholbach> mterry, could you join us in #ubuntu-arb? :)
[14:00] <Laney> someone else already did an uncoordinated rebuild bonanza anyway, so it probably doesn't matter that much
[14:03] <BenC> Laney: I'm going to leave haskell in your capable hands now…my goal of getting ghci working on ppc and having things build without errors is now complete
[14:03] <BenC> So hopefully when you do 7.4.2, powerpc will be able to keep in sync
[14:03] <Laney> \o/
[14:04] <Laney> did it get upstream?
[14:04] <Laney> I note hackage is down …
[14:04] <BenC> I gave it to erik, I haven't sent it upstream...
[14:04] <Laney> k
[14:24] <dobey> can someone please accept ubuntuone-storage-protocol and ubuntuone-client into precise-proposed?
[14:50] <bdmurray> pitti: oh, whoa sorry about that fixing now.
[14:58] <pitti> bdmurray: great, thanks!
[15:00] <mterry> @pilot in
[15:00] <mterry> infinity, heyo!  What pilot stuff are you working on?  (So I can avoid dup work)
[15:03] <stgraber> mterry: he's been piloting for days ;)
[15:03] <mterry> stgraber, ah, OK.  Poor man
[15:03] <pitti> probably just forgot to remove himself
[15:04] <pitti> /nick infinity Amelia_Earhardt ?
[15:07] <mterry> mvo, I'm guessing https://code.launchpad.net/~evfool/synaptic/ancientfixes/+merge/93134 is fine now?  (You had requested fixes, they were made, but no re-review yet)
[15:08] <hallyn> anyone else having trouble getting quantal apt-get update to finish this morning?
[15:10] <jamespage> hallyn, i *might* have seen something like that but I could not rule out flakey broadband
[15:12] <hallyn> jamespage: i thought i couldn't rule it out, but at this point it's getting ridiculous
[15:18] <mvo> mterry: yes, its on my todo since forever :(
[15:19] <mterry> mvo, OK.  :)  no worries, it's just the first item on the sponsoring report, so I thought I'd check it out
[15:21] <mvo> mterry: i know :( I need to send evfool (and the synaptic users) a box of chocolate for leaving this idle for *so* long
[15:21] <mterry> mvo, I didn't realize you/Ubuntu had so much of a hand in synaptic upstream
[15:21] <seb128> mvo, hey, aptdaemo... oh, you did that, sorry I just got used to it :p
[15:21] <mterry> mvo, thought that was someone else's baby
[15:22] <mterry> mvo, you just love apt  :)
[15:22] <mvo> mterry: I do :)
[15:22] <seb128> mterry, mvo is well famous for synaptic, he was a rockstar before Ubuntu even existed ;-)
[15:22] <mvo> seb128: haha
[15:22] <mvo> seb128: playing in front of a rather small audience, but still!
[15:23] <seb128> mvo, ;-)
[15:43] <jamespage> Sweetshark, what currency do you take bribes in?  I need to get a couple of changes into libreoffice for quantal...
[16:00] <Sweetshark> jamespage: currency base unit is a removed C++11 ABI symbol in quantal ....
[16:01] <jamespage> Sweetshark, oh joy
[16:01] <jamespage> does that mean we can't change it?
[16:18] <seb128> bdmurray, hey, is there anything special in bug #927515 that you assign it to us?
[16:19] <Sweetshark> jamespage: na, just kidding (although there _are_ still issues with gcc4.7/C++11 stuff). what changes would you need?
[16:19] <jamespage> Sweetshark, specifically bug 1023405 to support demoting tomcat6 to universe
[16:20] <jamespage> Sweetshark, and switching from openjdk-6 to openjdk-7 - I believe Debian has this in experimental ATM
[16:20] <bdmurray> seb128: its a regression in a -updates package as I understand it
[16:21] <Sweetshark> jamespage: I think both of it is already done, the package is just not in quantal because of the failing tests ...
[16:21]  * Sweetshark checks
[16:21] <seb128> bdmurray, well, it's "some people seem to have some performance" issues, which was really never confirmed as a regression, and it was reported in february on tb10 and we are at tb13
[16:22] <bdmurray> seb128: if its not confirmed as a regression then maybe the tag should be removed?
[16:22] <seb128> bdmurray, it might be a regression
[16:23] <Sweetshark> jamespage: please verify with the package in https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/
[16:23] <seb128> bdmurray, sorry, let's reboot that discussion, I meant to ask "did you assign the bug because the issue increased recently and is urgent, or did you just want to make it visible to us"?
[16:23] <jamespage> Sweetshark, will do
[16:23] <Sweetshark> jamespage: I see no openjdk, but fault-jdk, default-jdk (>= 1:1.7-48) [ia64]
[16:24] <bdmurray> seb128: as a part of the SRU team I've subscribed to reression-update and regression-proposed bug reports.  So now I get email about comments on those bugs.  So somebody commented on it recently and I wanted to make it visible to you as there is no comment from the desktop team about it.
[16:24] <Sweetshark> jamespage: hmm, but there is still libservlet2.5-java. I can give it a try with 3.0 though -- if that 'Just works(tm)' there is no issue.
[16:25] <jamespage> Sweetshark, it should - there is no API change - I did take a look and it appears to parse stuff from commons-logging?
[16:27] <seb128> bdmurray, ok, thanks, I just wanted to make sure I don't overlook something when descoping that, it's there since february and hitting some users but it's a normal bug
[16:27] <seb128> bdmurray, I will untag
[16:32] <jamespage> Sweetshark, I think the openjdk-7/default-jdk stuff looks OK - I will take a more thorough look tommorow
[16:33] <jamespage> servlet transition should be a no-change transition, i.e. packaging only
[16:34] <bdmurray> seb128: is empathy applying for a micro release exception? bug 1018784
[16:35] <seb128> bdmurray, empathy is part of GNOME
[16:35] <seb128> bdmurray, which has one ;-)
[16:39] <ScottK> How is "GNOME" defined?
[16:40] <stgraber> ScottK: the DMB has a definition for "GNOME" IIRC, I can try to dig that out
[16:40] <ScottK> I'm curious if it matches the MRE definition.
[16:42] <stgraber> ScottK: http://git.gnome.org/browse/jhbuild/tree/modulesets that's what we're using
[16:43] <stgraber> for example for desktop-extra we used:
[16:43] <stgraber> Create desktop-extra packageset with description "Every package that is NOT
[16:43] <stgraber>   in ubuntu-desktop, desktop-core or core, but needed for a vanilla GNOME.
[16:43] <stgraber>   Vanilla GNOME is defined by upstream in gnome-suites-core,
[16:43] <stgraber>   gnome-suites-core-deps, and gnome-apps:
[16:43] <stgraber>   http://git.gnome.org/browse/jhbuild/tree/modulesets"
[16:44] <ScottK> Interesting.
[16:44] <stgraber> I don't think the MRE is nearly as clear but I suppose it could be updated to use the same source of modules list
[16:45] <ScottK> Probably not a bad thing for when SRU team people like me run into a question.
[16:46] <ScottK> For KDE it's https://projects.kde.org/projects/kde and websvn.kde.org/trunk/KDE/ (since not everything's in Git yet)
[16:55] <infinity> mterry: It's entirely possible that I've been piloting for a week.
[16:55] <infinity> @pilot out
[16:56] <mterry> infinity, :)
[17:08] <SpamapS> bdmurray: FYI, I missed my SRU shift yesterday, so I'm going to work backwards (hardy -> precise, newest -> oldest) for a couple of hours to try and avoid colliding with you :)
[17:09] <cjwatson> gema: Would there be any chance of adding /var/log/installer/debug to the jenkins test results for ISO testing jobs, when it exists?  I'll need that to debug bug 1023036 further.
[17:09] <gema> cjwatson: we'll look into it
[17:10] <cjwatson> Thanks.  I assume it's a fairly small change somewhere ...
[17:10] <gema> cjwatson: I am about to leave, but I will leave hggdh on the case
[17:10] <cjwatson> Thanks.  If possible it would be helpful if it could be done before the run that's going to start soon for the images I'm building right now :-)
[17:10] <cjwatson> Only just occurred to me.
[17:11] <bdmurray> SpamapS: bug 979661 was overridden by a security upload I believe
[17:12] <ScottK> SpamapS: There was a push for precise SRUs lookiing at 12.04.1, so you might want to start from one end of those.
[17:13] <SpamapS> ScottK: indeed, I will, there's only a few in the older buckets anyway
[17:17] <gema> cjwatson: if not, we'll rerun them jobs, hggdh is on the case
[17:18] <hggdh> cjwatson: looking at it now, should have something in a few. I understand you would like the desktop jobs re-run ASAP with the debug log, correct?
[17:19] <cjwatson> hggdh: Only if they've already picked up the build I just finished
[17:19] <cjwatson> 20120712.2
[17:19] <hggdh> cjwatson: ack
[17:20] <mterry> The latest python3 upgrade seems broken.  Is that a known issue?
[17:21] <mterry> "py3clean: error: only one action is allowed at the same time" breaks the python rtupdate hook
[18:25] <toabctl> charles, i'm trying to use dbus 1.6 on ubuntu 12.10 but the indicators are not shown (see #1014850). how can i debug the indicator stuff?
[18:31] <dobey> is python3 3.2.3-2 failing to install for everyone else on quantal?
[18:40] <charles> toabctl: none of the indicators are shown?
[18:41] <toabctl> charles, i see some (datetime, message, sound)
[18:41] <toabctl> and also "system" (i don't know the name). the one with the username (but my username is not shown. the user name is "User Name")
[18:42] <charles> fun fun
[18:42] <toabctl> charles, i tried to run: /usr/lib/libindicator/indicator-loader3 /usr/lib/indicators3/7/libpower.so
[18:43] <toabctl> charles, then i get:
[18:43] <toabctl> http://paste.ubuntu.com/1088487/
[18:43] <toabctl> charles, and the indicator is visible in a window :)
[18:46] <stokachu> seb128: dbus-test-runner failing to build, looks like it needs a build-depends on dbus as well
[18:47] <stokachu> since the test cases require dbus running
[18:47] <seb128> stokachu, thanks
[18:47] <stokachu> seb128: sure thing, i was gonna do a mergeproposal if you'd like
[18:48] <seb128> stokachu, your call, I'm happy to just do it, it's not like it was hard work ;-)
[18:48] <stokachu> seb128: ill do it an re-test then give you a ping when its done
[18:49] <stokachu> helps me keep track of +1 stuff anyway
[18:49] <seb128> stokachu, ok
[18:49] <seb128> stokachu, thanks
[18:49] <charles> toabctl: the accessible description + atk-bridge lines aren't relevant to this...
[18:50] <charles> ...but the "/bin/dbus-daemon: no such file or directory" sounds suspicious given what you're trying to do
[18:52] <charles> toabctl: what are the relevant changes in dbus between 1.4.18 and 1.6?
[18:53] <toabctl> charles, good question. i don't know
[18:53] <toabctl> charles, http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14740
[18:57] <toabctl> charles, btw: the global menu is not shown, too
[18:58] <charles> toabctl: hooray! :/
[18:59] <stokachu> seb128: lol you went ahead and did it?
[18:59] <stokachu> to fast for me
[18:59] <charles> toabctl: do you have a repo for 1.6?
[18:59] <stokachu> seb128: oh nm thats just depends
[18:59] <stokachu> bah been staring out build outputs to long
[18:59] <seb128> stokachu, yeah, I was going to ask
[18:59] <toabctl> charles, no
[18:59] <seb128> stokachu, I did add the depends because libindicate ftbfs
[19:00] <stokachu> seb128: ah ok
[19:00] <stokachu> seb128: i created the merge which explains what i did if you want to take a look
[19:00] <stokachu> nothing major
[19:00] <seb128> stokachu, sure
[19:00] <stokachu> cool thanks man
[19:01] <toabctl> charles, i used the version from debian with some small modifications (copied upstart script, removed systemd build-dep)
[19:01] <seb128> stokachu, url?
[19:01] <stokachu> seb128: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/dbus-test-runner/build-depends-dbus/+merge/114704
[19:01] <stokachu> seb128: and... if you got time i fixed aces3 build as well
[19:01] <stokachu> https://code.launchpad.net/~adam-stokes/ubuntu/quantal/aces3/build-fix/+merge/114675
[19:01] <seb128> stokachu, url? ;-)
[19:01] <seb128> stokachu, ok
[19:02] <stokachu> sweet thanks a lot, ttyl
[19:02] <seb128> stokachu, small comment on the dbus-test-runner one, .1 is for SRUs, we just bump the number on dev series, i.e ubuntu1 -> ubuntu2
[19:02] <seb128> stokachu, don't worry about fixing it, I'm doing that
[19:02] <stokachu> seb128: ah ok ill remember that
[19:02] <stgraber> BenC: I'm running a test build of libguestfs on powerpc, if it passes I'll upload the fix for bug 1002991
[19:02] <stokachu> seb128: i kinda figured but wasn't sure
[19:03] <BenC> stgraber: Thanks, let me know if I can do anything
[19:06] <stgraber> BenC: should that change also be applied to Debian? looks like we're in sync on libguestfs and I don't see a bug report on the Debian BTS
[19:06] <BenC> Yeah, I'm bad about pushing bugs that deep
[19:07] <BenC> I'll do that today
[19:07] <stgraber> thanks
[19:11] <cr3> what might be the reason for lintian to complain about missing-dependency-on-python-support for a python3 project which already specifies ${python3:Depends}?
[19:13] <dobey> cr3: the debian/rules is using dh_pysupport probably
[19:14] <hallyn> roaksoax: hi, bug 799858 really wants to be SRUd, but i think it's been held up bc i haven't had the rights to upload the proposed fix to -proposed
[19:15] <roaksoax> hallyn: give me a sec and I'll upload it :)
[19:15] <hallyn> roaksoax: would you mind taking a look at http://people.canonical.com/~serge/procps-e.debdiff and sponsoring it ifi t looks ok to you?
[19:15] <hallyn> roaksoax: thanks
[19:15] <hallyn> i was sure someone had done that for me in march.  but don't know where it went
[19:17] <roaksoax> hallyn: looks good to me
[19:17] <hallyn> roaksoax: hm, wait
[19:17] <hallyn> roaksoax: i see it in the Rejected queue
[19:17] <hallyn> don't know why it was rejected
[19:18] <cr3> dobey: debian/rules seems clean, dh "$@" --with translations,python3
[19:18] <roaksoax> hallyn: "The fix itself looks ok, but I think the changelog entry needs work - specifically, it doesn't actually describe the problem it fixes at all. I've rejected it from the queue; please upload again with an expanded changelog entry (something like ‘fixes failure to install when $STUFF’)."
[19:19] <roaksoax> hallyn: just update the description on the changelog and that should be it
[19:19] <hallyn> meh
[19:19] <dobey> cr3: postinstall script or something? check the build log to see if dh_pysupport is being run anywhere?
[19:19] <hallyn> roaksoax: where did you see that msg?
[19:20] <roaksoax> hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/799858/comments/22
[19:20] <mterry> @pilot out
[19:23] <hallyn> roaksoax: oh that's right, that's why i uploaded a new one to the bug.  guess that got lost
[19:24] <roaksoax> hallyn: could you ellaborate more the fix on the changelog so it doens;t get rejected again please :)?
[19:24] <hallyn> roaksoax: i'm going to claim that i already did that in the bug and it was ignored, but hold on, i don't like that one and am doing a new one
[19:25] <cr3> dobey: the postinst script uses #DEBHELPER# which is being replaced with something that contains: # Automatically added by dh_pysupport
[19:25] <hallyn> roaksoax: http://people.canonical.com/~serge/procps-e2.debdiff
[19:25] <cr3> dobey: and, the generated debian/*debhelper.log contains dh_pysuppport; not sure where it's coming from though
[19:27] <dobey> cr3: is there a debian/pyversions file?
[19:27] <ScottK> cr3: Dehelper's automatic buildsystem selection
[19:27] <cr3> dobey: not sure if it matters, but I'm running debuild on precise rather than quantal
[19:27] <cr3> dobey: no, just debian/pycompat containing: 2
[19:27] <ScottK> It doesn't know about dh_python3.
[19:28] <dobey> ah
[19:28] <ScottK> I suspect if you add --with python2 (even if there's no python in it) that will go away).
[19:28] <dobey> cr3: you should probably remove that file if you're using dh_python2/3
[19:29] <cr3> ScottK: really? I do have /usr/bin/dh_python3 and I'm using --with translations,python3
[19:29] <dobey> also what ScottK said
[19:29] <ScottK> cr3: That doensn't say anything about how to deal with python code.
[19:30] <ScottK> bdmurray: There are a number of bugs like Bug #1024016  where the offending package is wrongly selected as python3-defaults.  Is there some way that could be automated based on the error message?
[19:30] <cr3> ScottK: will that ultimately mean that I'll also need to add ${python:Depends} in addition to ${python3:Depends} to my requires line?
[19:30] <ScottK> No.
[19:30] <roaksoax> hallyn: done!
[19:30] <cr3> ScottK: cool, I'll give that a try then. thanks!
[19:31] <ScottK> dh_python2 just won't do anything.
[19:31] <ScottK> I think, I didn't actually try this.
[19:31] <dobey> ScottK: is there a way to workaround that bug? my quantal laptop is hosed at the moment with python3 failing to configure :-/
[19:33] <ScottK> Dunno.  remove ubuntu-common-drivers and the apt-get -f install?
[19:34] <cr3> ScottK: when I changed --with python3 to python2, lintian returns lots of python-script-but-no-python-dep
[19:34] <ScottK> cr3: I didn't say change it, I said add it.
[19:34] <cr3> ScottK: heh, my mistake. trying again then :)
[19:36] <cr3> ScottK: now I get: missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev
[19:36] <ScottK> Right.
[19:36] <ScottK> didn't think about that.
[19:37] <hallyn> roaksoax: thanks!
[19:37] <ScottK> Avoiding having any python installed at all will also solve it.
[19:39] <cr3> ScottK: I'll revert to the previous missing-dependency-on-python-support lintian error and try to document the problem; it's the only remaining warning/error returned by lintian, so doesn't seem that bad
[19:39] <ScottK> No.  It's not.
[19:39] <stgraber> BenC: test build failed on the porter box. one of the tests failed. (when doing a test build of the precise version of libguestfs)
[19:51] <dobey> ScottK: would "--buildsystem python3" not work on precise to fix cr3's issue?
[19:51] <ScottK> I don't think so, but it might.
[19:52] <ScottK> overriding dh_auto_build definitely would.
[19:52] <toabctl> charles, i added dbus 1.6 to my testing ppa: https://launchpad.net/~toabctl/+archive/testing
[19:54] <cr3> dobey, ScottK: I tried keeping --with python2,python3,translations and adding python, python3, python-distutils-extras, python3-distutils-extras, etc. in the Build-Depends; no more warnings
[19:54] <tumbleweed> there is a python3 buildsystem in dh?
[19:56] <toabctl> tumbleweed, there is dh_python3
[19:56] <cr3> ScottK: I already had an override for dh_auto_build: set -ex; for python in $(shell py3versions -r); do $$python setup.py build; done;
[19:56] <tumbleweed> toabctl: they are totally different things
[19:56] <ScottK> Maybe it's auto_configure that needs the overrid.
[19:57] <ScottK> cr3: Did you also run auto_build before or after that snippet?
[19:57] <cr3> ScottK: nope, but I've noticed apport call dh_auto_build and then python3 setup.py build
[19:58] <ScottK> You don't need them both, as a rule.
[19:59] <cr3> ScottK: ok, that's reassuring. what do you think about having both python and python3 in build-depends though? seems to quiet lintian :)
[20:00] <ScottK> I think it's the wrong way to solve the problem.
[20:00] <ScottK> You need to override debhelper's auto magic so it's not trying to build for python.
[20:21] <cjohnston> slangasek: ping
[20:24] <stgraber> tkamppeter: what's the status of bug 998156? you targeted it to the point release but I don't see any activity on it. Will it be fixed in the next few days and make it to the point release?
[20:51] <xnox> stgraber: stop spamming me =)
[20:51] <xnox> stgraber: I know that time is ticking away
[20:51] <stgraber> xnox: ;)
[20:51] <highvoltage> stgraber: keep spamming him, maybe he'll be less noisy
[20:52]  * xnox punches highvoltage
[20:52] <stgraber> don't worry I'm spamming everyone just as much, except for these that already have all their SRUs uploaded :P
[20:52] <xnox> =))))))))))))))))))))))))))))
[20:52] <highvoltage> he nearly smacked me with that might beast of a laptop he has!
[20:52] <highvoltage> *mighty
[20:53] <xnox> stgraber: me tumbleweed and highvoltage are all sitting next to each other ;-)
[20:53] <Laney> i heard it's raining over there
[20:53] <tumbleweed> just a little
[20:53] <tumbleweed> we're all taking shelter in the xen talk
[20:53] <infinity> It's not raining, it just sounds like it is.
[20:53] <infinity> We're going to send xnox outside to prove this theory.
[20:54] <xnox> infinity: you will get my toe in your face in 3, 2, 1
[20:54]  * xnox infinity says:"that's terrifying"
[20:54] <infinity> I'm going to be scarred for life.
[20:55]  * stgraber spams xnox some more
[20:55] <xnox> stgraber: lp is slow, didn't get the email yet
[20:55]  * xnox waits
[20:56] <highvoltage> hmm, it should be pretty easy to port most "yo mamma" jokes to "launchpad" jokes.
[20:56]  * highvoltage feels a new twitter account in the making
[20:58] <infinity> highvoltage: Yo' webapp so fat, it gots its own datacenter?
[21:01] <stgraber> xnox: I have that feeling that whenever mdadm lands in -updates we'll suddenly see a quarter of the 12.04.1 bugs be closed at once ;)
[21:01] <xnox> infinity: LOL
[21:02] <highvoltage> infinity: yo launchpad is so big that the long double numeric variable type in C++ is insufficient to express its weight
[21:04] <BenC> stgraber: Are the tests built-in to the package?
[21:04] <BenC> I'll attempt to get it running from my box
[21:05] <stgraber> BenC: yeah, all I did was run debuild
[21:09] <cr3> hi folks, how could we go about removing hwdb-client from universe since it's been deprecated for quite a while now
[21:51] <stgraber> ScottK: Can I assign bug 991754 to you and mark fix commited? I believe it's part of that postfix SRU that got in this morning.
[21:51] <ScottK> stgraber: Sure (and it is)
[22:04] <hggdh> cjwatson: I know it is late, but are you still there? I cannot see how to save the Ubiquity debug log you asked for (at least 'd-i early-command httpd' seems to fail with "sh: httpd not found"
[22:05] <hggdh> and all I can find on it suggests one has to manually copy over the /var/log/installer/*
[22:16] <ScottK> Those python3-defaults fails to configure bugs are python3-defaults after all.
[22:16] <ScottK> I just uploaded half the fix.  Waiting to here from POX on the rest.
[22:16] <ScottK> The affected packages are going to have to be rebuilt.
[22:19] <slangasek> cjohnston: hi there
[22:23] <cjwatson> hggdh: that seems like kind of a d-i-ish approach; live filesystems don't have apache2 installed ...
[22:24] <hggdh> cjwatson: how to save it, then? It was indeed a d-i-ish approach :-)
[22:24] <hggdh> the only one I knew how to do, and the Ubiquity docs do not clearly state as, ah, wrong
[22:24] <cjwatson> hggdh: I guess maybe you could apt-get install apache2 instead?  it should automatically start then
[22:25] <cjwatson> though you'd have to configure a site that let you download stuff from /var/log
[22:25] <hggdh> heh
[22:26] <hggdh> cjwatson: I will see this one (although is starting to get more complex, and may cause spurious errors); I will also try SSH
[22:27] <cjwatson> the latter might be easier, yeah
[22:27] <hggdh> cjwatson: thanks, and sorry to bother
[22:27] <cjwatson> can't you use the same approach that works for /var/log/syslog?
[22:28] <cjwatson> Or is that via some kind of magic one-use-only channel?
[22:28] <hggdh> cjwatson: /var/log/installer/syslog is tied to the serial console; perhaps I could open a second serial
[22:28] <hggdh> then yeah, it would be quite simple
[22:29] <cjwatson> worst case, it wouldn't be awful to conflate the two logs just for the time being
[22:29] <cjwatson> although it would be better to have something that could be used permanently
[22:30] <hggdh> indeed. But you need it ASAP, so I will see if a second serial is easily set, otherwise I will just conflate them
[22:59] <cjohnston> slangasek: you still around?
[23:12] <slangasek> cjohnston: ish
[23:26] <cjohnston> slangasek: two things.. have you come up with some sort of wording for the 'required' stuff in LP/Summit... and.. We need someone who is good with writing algorithms to help us write one for scheduling to take into account certain things like we discussed... any suggestions on anyone who may be able to help?