[02:30] <micahg> doko: did you need something from me?
[02:33] <ScottK> Some days are better than others: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/992941/comments/5
[02:34] <ajmitch> excellent!
[02:35] <micahg> awesome, now if we can just get rud of sqlite
[02:35] <micahg> *rid
[03:26] <pitti> Good morning
[03:33] <kees> infinity: you around?
[03:34] <infinity> kees: Nope.
[03:35] <kees> infinity: dang. I was gonna ask you about eglibc coordination.
[03:35]  * slangasek marks infinity absent
[03:36] <kees> infinity: I have a patchset that cleans up the existing patches (making them not ubuntu-specific)
[03:36] <infinity> kees: email would be better, I'm only sort of here.
[03:36] <kees> infinity: okidoky.
[03:37] <kees> infinity: alternatively, I could just upload it to quantal. ;)
[03:38] <infinity> You don't want a review of any sort? :P
[03:38] <kees> hehe
[03:38] <kees> emailing you the debdiff now.
[04:18] <pitti> SpamapS: I now added test cases and regression potential to all apport SRU bugs
[05:51] <pitti> rickspencer3, cjwatson, slangasek: FYI, just sent the May stable+1 status to u-devel@
[05:51] <rickspencer3> hi pitti
[05:51] <rickspencer3> thanks!
[06:23] <slangasek> pitti: thanks much :)
[07:09] <dholbach> good morning
[08:10] <larsduesing> good morning together
[08:26] <pitti> hello larsduesing
[08:42] <jibel> mvo, hey
[08:42] <jibel> mvo, is upgrade to quantal still blocked on py3 port of the release-upgrader ?
[08:44] <mvo> yes, afaict its still not working, but we need to make it work for a1
[08:49] <jibel> mvo, ta
[09:19] <brendand> what can i use in place of gobject.Mainloop in Python3?
[09:20] <pitti> brendand: use python3-gi, and GLib.MainLoop
[09:22] <xnox> If anyone knows autofs or likes cryptic patches, could you please take a look and tell me (1) what does this do (2) and why: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/autofs5/quantal/view/head:/debian/patches/16group_buffer_size.patch
[09:23] <brendand> pitti - from gi.repository import Glib?
[09:23] <brendand> pitti - i know for sure i have python3-gi installed
[09:23] <brendand> pitti - btw, i'm on precise
[09:24] <pitti> GLib, not Glib
[09:25] <brendand> pitti - ahem
[09:29] <xnox> Never mind found it: https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/591100
[09:37] <brendand> another question. what are we meant to use instead of pygst? am i correct in thinking some gi binding?
[09:41] <pitti> brendand: that's the general idea, but gstreamer 0.10 is not yet introspectable; gstreamer 1.0 will mostly be
[09:41] <pitti> (it's in universe now)
[09:42] <pitti> brendand: if you need gst 0.10, then you can't use python3 yet
[09:42] <brendand> pitti - will that be in precise?
[09:42] <pitti> no, it won't
[09:42] <pitti> precise -> python 2
[09:42] <pitti> (and pygst)
[09:43] <brendand> pitti - so i can't install gstreamer 1.0 on precise to test?
[09:44] <brendand> pitti - just want to know if i need to be updating to quantal
[09:44] <pitti> brendand: oh, you certainly can backport/build/install it, but it is not in precise prpoer
[09:44] <brendand> pitti, ok
[09:44] <pitti> brendand: I figure the gstreamer1.0 etc. packages will build on precise just fine
[09:45] <xnox> my piuparts is not up to date. Is there a latest / greatest way to set up piuparts for multiple ubuntu and debian distributions, considering i have switched to using pbuilder-dist?
[11:21] <smb> cjwatson, Sorry to ask again, I am just not sure whether this may be just a just about acceptable thing: would a 3-4 minute delay on each boot justify a SRU to initramfs-tools which looks to be low risk and testable (back into Lucid/10.04)? The alternative would be to document the workaround (I assume in the release note?).
[11:39] <cjwatson> mvo: I thought I'd fixed the upgrader; it's still not fully py3, but it shouldn't have those import bugs any more[6~
[11:40] <cjwatson> smb: All other things being equal, that looks like a reasonable SRU candidate
[11:41] <mvo> cjwatson: I haven't looked into details yet, but sudo ./dist-upgrade.py fails for me with import errors, I'm at r2435
[11:42]  * mvo actually looks closer
[11:43] <smb> cjwatson, Ok thanks. I tested a modified version in a vm and found it doing as claimed (so only adding the non-obviously depending module when the one that depends on it is requested to be in). So I will proceed to bring the report into proper state for SRU. Thanks again
[11:44] <cjwatson> mvo: I was sure I'd fixed that in revisions 2430 to 2432.  What's the exact error?
[11:44] <cjwatson> Oh
[11:44] <cjwatson> Ddamnit, it had worked
[11:44] <cjwatson> OK, give me a minute, I'll fix that
[11:46] <mvo> cjwatson: thanks! once that is done, I look at the merge from mterry and do a new upload for a1
[11:50] <cjwatson> Oh, wow, it's using __import__, what could possibly go wrong
[11:57] <mvo> *cough*
[11:58] <mvo> cjwatson: if its a hassle I'm happy to have a look at it myself, I just wanted to avoid digging into something that potentially was already done
[11:58] <cjwatson> It's OK, I broke it, I'll fix it
[11:58] <cjwatson> ... somehow
[12:02] <cjwatson> mvo: Try r2436
[12:02] <mvo> cjwatson: using importlib?
[12:02]  * mvo checks
[12:02] <mvo> cjwatson: oh, interessting!
[12:03] <cjwatson> Possibly ought to have passed locals() as well, but the docs say that the standard implementation only uses globals()
[12:03] <cjwatson> I'm fairly sure this won't work yet with Python 3, but that's for another day
[12:04] <mvo> cjwatson: thanks a bunch! I look at the py3, I think we can use importlib for this
[12:04] <mvo> cjwatson: I check that out and if its good commit
[12:05] <cjwatson> py3 can probably use __import__ too, with some extra fiddling - not susre
[12:05] <cjwatson> but yeah, importlib should be a possibility
[12:06] <cjwatson> The rest of update-manager isn't finished for py3 yet (I still have a stack of patches to sort out), so don't worry about it too much
[12:06] <mvo> ok
[13:01] <seb128> ev, pitti, ogra_: "* moving of the Launchpad retracers onto the crash database system" ... does that concern only errors.ubuntu.com or also the launchpad retracers?
[13:02] <ogra_> seb128, that was from ev's weekly report, he can probably elaborate
[13:03] <ev> seb128: pitti and I are discussing how we can reduce the duplication of effort around retracing. The functionality would remain the same, but behind the scenes the duplicate db that crash-digger uses would live in Cassandra and the Launchpad retracers themselves would run from the same server that the error tracker retracers are on.
[13:04] <ev> So this wouldn't remove Launchpad bug duplication. It would just mean that we have a single location for the apport duplicate db.
[13:05] <seb128> ev, ok, that's fine, so it means I should stop sshing to the retracers (I used to grep logs to get stats and help restarting them when they get stucked, that sort of things)
[13:06] <seb128> ev, but I feel like if you change the setup and I'm out of the loop I better step out to not create issues
[13:06] <ev> seb128: Eventually, yes. Stats will be available via a web API (let me know if there are specifics you need there). Restarting them and handling issues will fall on me and webops - so you wont have to worry about that anymore.
[13:06] <seb128> less work, I will not complain ;-)
[13:06] <seb128> ev, thanks!
[13:06] <ev> :)
[13:07] <seb128> I'm glad that ogra pointed that to -release and that I read it
[13:07] <ev> seb128: sure thing. Still in the planning stages, but I'll keep you in the loop.
[13:07] <seb128> thanks
[13:07] <seb128> ev, @stats: nothing specific, I used to build "bug which get the most duplicates" lists from the log before we had errors.ubuntu.com
[13:08] <ev> ah, glad I could automate that task away for you :)
[13:08] <seb128> ;-)
[13:31] <seb128> ev, is there a way to see the issues you submit on errors.ubuntu.com?
[13:41] <seb128> pitti, so, re. making easy to still report bugs to launchpad, we get an increasing number of users who report useless bugs about segfaults because they don't manage to use ubuntu-bug anymore
[13:41] <seb128> i.e they run it on the .crash and get a .upload and nothing else and they get confused on what happened
[13:41] <seb128> so they go on launchpad and open a bug saying they get a segfault and can't report it
[13:42] <pitti> hm, what kind of users? i. e. the "kenvandine" kind, or the "my mother" kind?
[13:42] <seb128> I'm not sure how we solve that and if we should wait on errors.ubuntu.com to improve
[13:42] <pitti> the whole point of disabling this was that we stop getting reports for stables, after all?
[13:42] <seb128> pitti, people who run quantal
[13:42] <pitti> seb128: oh, quantal; we can just re-enable LP bugs for quantal again
[13:42] <kenvandine> i was on precise though
[13:42] <pitti> there's no reason why it's disabled there other than "we did not get around to do it"
[13:43] <kenvandine> but that isn't the norm
[13:43] <seb128> pitti, do we have retracers for q yet?
[13:43] <pitti> seb128: sure, since day 1 :)
[13:43] <pitti> they are now trivial to set up
[13:43] <seb128> right, your new setups make that trivial ;-)
[13:43] <pitti> just copy the precise config file, s/precise/quantal/, done
[13:43] <seb128> pitti, ok, can we get apport turned on again in quantal soon then?
[13:43] <seb128> I think that's most of the issue I faced recently
[13:44] <ev> seb128: yes - http://errors.ubuntu.com/user/$your_sha512_hashed_system_uuid
[13:44] <seb128> users who jumped on quantal, have segfaults and struggled to report them
[13:44] <seb128> ev, how do I compute "your_sha512_hashed_system_uuid"? ;-)
[13:44] <ev> seb128: I'll have an upload of activity-log-manager soon that puts this into a button in the diagnostics tab of the privacy page
[13:44] <seb128> cool
[13:45] <seb128> ev, btw errors.ubuntu.com seems to regressed on something that worked the other day for me
[13:45] <seb128> ev, if I do
[13:45] <pitti> seb128: uploaded
[13:45] <seb128> "Error reports for "12.04" gnome-control-center "all installed version"" on a month
[13:46] <seb128> I get nothing listed
[13:46] <seb128> i.e "No data to display"
[13:46] <seb128> oh
[13:46] <ev> seb128: oh? (working on a one-liner for the compuation)
[13:46] <seb128> is "month" a "since the month start"?
[13:46] <seb128> i.e today?
[13:46] <ev> yes
[13:46] <seb128> ok
[13:46] <seb128> that's why :p
[13:46] <kenvandine> hehe :)
[13:46] <seb128> I though it was a month timeframe
[13:46] <kenvandine> good, no bugs yet today :)
[13:46] <ev> yeah, I'll fix this when we do the date range stuff
[13:46] <seb128> i.e sliding win
[13:47] <ev> indeed
[13:47] <ev> exactly that
[13:47] <seb128> ev, thanks
[13:47] <ev> sure thing
[13:48] <larsduesing> Hmpf... Short question.. I now have 3 different patches for aiccu, 2 of them possibly SRUable, one merge with debian sid... What should I do? Some ranking?
[13:48] <seb128> ev, and is there a way the repartition of a specific issue by versions?
[13:49] <ev> seb128: can you elaborate please?
[13:49] <seb128> ev, like the s-c listed first on first on e.u.c is supposed to be fixed in 5.2.2.1, can we see if the reports we still get are from users who didn't upgrade yet?
[13:49] <seb128> -on first
[13:49] <larsduesing> all 3 are completely independent
[13:49] <seb128> ev, we have "last seen" in 5.2.2.1 but my guess is that because we don't have the "was the running version the current one"
[13:49] <hallyn> is there some nifty way to test apport hook triggers?
[13:50] <larsduesing> hallyn: yes :-)
[13:50] <larsduesing> hallyn: apport-bug
[13:50] <seb128> ev, I would like to see if on those 486 reports 480 were running 5.2.2.1 and 6 a false positive from users who still had the old binary running
[13:51] <larsduesing> hallyn: apport-bug <packagename>
[13:51] <hallyn> larsduesing: doesn't work well without x or without giving my lp id
[13:52] <ev> seb128: hmm, okay. I'll have a chat with mpt and see if we can come up with a good UI for that.
[13:52] <hallyn> oh wait, maybe that gets me far enough
[13:52] <hallyn> thanks :)
[13:53] <larsduesing> hallyn: it works in commandline-mode...
[13:53] <seb128> ev, well maybe my usecase is just created by the fact that we have that issue with "is the running version current", but I still think it would be somewhat useful to know the stats by version, it can give an indication of if the update worked most most user, some users, none of the users
[13:53] <larsduesing> hallyn: apport-bug --save <bugreportfilename> <packagename>
[13:53] <ev> I'll do that when we're back on Wednesday
[13:53] <hallyn> larsduesing: perfect.  thanks.
[13:53] <larsduesing> hallyn: np
[13:54] <larsduesing> hallyn: to be fair, I had these troubles a few days ago, and was helped here :)
[13:55] <hallyn> larsduesing: the libvirt apport hooks have been wrongly isntalled forever.  I needed a somewhat simple test case for SRU justification.  :)
[13:55] <hallyn> (that did not include "force libvirt to segv")
[13:55] <seb128> ev, I'm done with questions, thanks for the replies ;-)
[13:55] <seb128> pitti, thanks as well for the replies and for re-enabling apport in q ;-)
[13:57] <ev> seb128: noted. I have a branch that (at Matthew's suggestion) greys out lines that we reasonably believe to be fixed (either there are no instances of the crash in the latest version, or the attached bug is marked fix released). But I had not until now thought about separating out the frequency counts by version, so we could show the stats you mention.
[13:57] <ev> I've added that to my todo item for talking to Matthew
[13:58] <ev> seb128: sure thing. Always looking for ways to make this thing more useful for you guys.
[13:58] <seb128> ;-)
[14:00] <ev> seb128: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
[14:00] <ev> that should give you the other part of the URL
[14:00] <ev> so http://errors.ubuntu.com/user/$that
[14:00] <ev> without the dollar sign, of course
[14:01] <seb128> ev, excellent, thanks again ;-)
[14:05] <ev> seb128: I take it that worked?
[14:07] <seb128> ev, yes
[14:07] <ev> yay
[14:08] <hallyn> is there a way to force apport-cli, when doing --save, to give me output even though I'm running a custom built package?
[14:09] <hallyn> I don't see a '--override' option
[14:09] <seb128> ev, is there any way to go from those report to the "master" or to see if they have associated launchpad bugs?
[14:09] <ev> seb128: not as yet. Adding to the list. :)
[14:10] <seb128> ;-)
[14:10] <ev> seb128: I should've just created another blueprint/UDS session for "things Seb wants/needs" ;)
[14:11] <seb128> lol
[14:11] <ogra_> ++
[14:48] <PaoloRotolo> Hi all!
[14:54] <jamespage> how does apt determine the order in which packages are configured? does the Priority field get used in any way?
[14:54] <htorque> jono: hi! do the accomplishment descriptions use tabs or are spaces fine as well (for listing the steps)?
[14:58] <jono> htorque, tabs please :-)
[14:58] <htorque> jono: alright
[15:00]  * Sweetshark dances to the left ..
[15:00]  * Sweetshark dances to the right ..
[15:00]  * Sweetshark jumps and turns around.
[15:01] <Sweetshark> libreoffice-3.6.0~alpha1 succeeded building in 1h52min on precise.
[15:01] <Sweetshark> now only have to lob that over to quantal.
[15:05] <xnox> that quick! =)
[15:09] <jamespage> sbeattie, are the new openjdk-6 packages ready for < 12.04 yet?
[15:14] <Sweetshark> xnox: ccache+16GB RAM+SSD. Half an hour of that is tar/xz compressing the 2GB libreoffice-dbg package.
[15:14] <xnox> heh =)
[15:15] <Sweetshark> xz need multithreading.
[15:15] <Sweetshark> *nods*
[15:22] <stokachu> xnox: do you know if sunrpc's max_shared parameter was ever accepted upstream?
[15:23] <mvo> mterry: do you feel good about your software-updater branch to land in a upload for today?
[15:23] <xnox> stokachu: no clue. should check. this is with regards to nfs, right?
[15:23] <mterry> mvo, the move-changelogs one?  Sure
[15:23] <mvo> mterry: excellent
[15:23] <xnox> stokachu: or something else?
[15:23] <stokachu> xnox: yea
[15:24] <xnox> stokachu: I was under impression that sunrpc's max_shared is separately configured / enabled. but I do not know if it is upstream on linux. and which upstream of nfs. As far as I remember there were multiple implementations.
[15:24]  * xnox has vague and out-of-date nfs knoweledge, but I could pick up on it.
[15:24] <stokachu> xnox: i lowered the sunrpc.min_resvport=200 and can allow these 13k mounts to succeed
[15:25] <xnox> well done! =)
[15:25] <stokachu> but i dont want it to interfere with other services like samba
[15:26] <xnox> stokachu: cryptic. i am not even sure where to ask this to get wide exposure about this. try ubuntu-kernel mailing list or even ubuntu-devel to get more information on this.
[15:26] <stokachu> ok will do, thanks!
[15:27] <xnox> stokachu: try jelmer, he might know a lot.
[15:27] <xnox> https://launchpad.net/~jelmer
[15:27] <xnox> he is deep into samba and might now quirks like that
[15:28] <Laney> zul: you didn't actually make the change in nova-common.postinst ...
[15:29] <zul> Laney: fix is coming now
[15:30] <Laney> zul: I'm looking at 2012.2~f2~20120531.14249-0ubuntu1 now (the one you just uploaded), unless you mean that there is a second upload incoming
[15:30] <zul> Laney: second upload is coming
[15:31] <Laney> sweet
[17:21] <bdmurray> wasn't there a kernel team member asking about package install failures and postinst earlier this week?
[17:21] <cjwatson> bdmurray: apw possibly
[17:22] <apw> i was asking about postinst indeed, though not about errors
[17:22] <apw> i may have been asking about errors separatly, as there was an uptick but we didn't know if that was cause of an uptick in installs
[17:23] <bdmurray> okay, I'm just looking at bug 991282
[17:36] <bdmurray> and that bug seems to be a duplicate of bug 996373
[17:49] <jono> mterry, hey
[17:50] <mterry> jono, hello
[17:50] <jono> mterry, dpm mentioned that the Quickly flash template and /opt bug have been fixed in quickly trunk
[17:50] <mterry> jono, yup.  I pushed to precise-proposed too
[17:50] <jono> awesome! that was going to be my next question
[17:50] <mterry> jono, (and quantal)
[17:50] <jono> I will check proposed, thanks!
[17:51] <jono> I plan on upgrading to Quantal at A1 next week
[17:51] <jono> thanks
[17:51] <mterry> jono, please do, let me know of any issues so I can fix them before it actually hits users!  :)
[17:51] <jono> mterry, will do, will test now
[17:53] <slangasek> mhall119: swing global menu> !! wicked
[17:55] <highvoltage> what in the world is swing global menu?
[17:55] <jono> mterry, when did you push it to proposed?
[17:55] <slangasek> highvoltage: global menu integration for apps using swing java toolkit
[17:56] <highvoltage> aah
[17:56] <mterry> jono, oh right, it hasn't been accepted yet by an archive admin
[17:56] <jono> ahhh np
[17:57] <jono> mterry, did you manage to take a look at the qt-quick template?
[17:57] <jono> I am not sure if it has been submitted
[17:59] <mterry> jono, no I haven't looked yet
[18:00] <mterry> jono, was it ready for review?
[18:00] <jono> I am not sure, I am checking into it
[18:00] <jono> I just wasnt sure if he had submitted it yet
[18:00] <jono> I know there is the qt-quick one and the HTML5 template
[18:26] <bdmurray> oh that's fantastic all the dupes of bug 991282 are from the same person
[18:26] <mhall119> slangasek: if we can get that into OpenJDk and make it available by default for all Swing apps, that would be a big win
[18:27] <mterry> jibel, oh neat.  I was about to split the auto-upgrade-tester out of update-manager, but I see you already made a project (auto-upgrade-testing) that has done that?
[18:29] <mvo> mterry: yeah, jibel is made of awsome, it just needs a proper source package now and upload and we should be good :)
[18:29] <mterry> mvo, yar, I can do that
[18:30] <mvo> ta
[18:30] <mvo> mterry: one of my whishlist items there would also be to allow the upgrade tester to directly pull from a bzr branch instead of doing do-release-upgrade -d
[18:32] <mterry> mvo, you mean like bug 956175 ?
[18:33] <mvo> mterry: yeah
[18:33] <mterry> mvo, patches welcome...  ;)
[18:33] <mvo> hahahaha
[18:33] <mvo> thats not what you tell upstream, its the other way around ;)
[18:34] <mterry> mvo, isn't that what every feature request is?  A "patches welcome" to upstream?  :)
[18:34] <mvo> I shouldn't argue with you, you are too smart ;)
[18:35] <mterry> mvo, flattery will get you no patches, sir.  :)
[18:35] <mvo> *damm*
[18:35] <mvo> ;)
[18:35]  * mvo tries to offer some tea and cookies next
[18:35] <mterry> heh
[18:45] <maco> >< might be time to update my server precise. i can't apt-get build-dep the dependencies for a package added in oneiric on a lucid box
[18:51] <mterry> jibel, is lp:auto-upgrade-testing in a releasable state?  Like, can I package it up and put it in quantal?
[18:57] <larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
[19:03] <micahg> cyphermox: ^^ what you're asking isn't possible in LP
[19:03] <dobey> cyphermox: ^^
[19:03] <cyphermox> the what?
[19:04] <micahg> cyphermox: it's yet another problem with UDD :)
[19:04] <cyphermox> isn't the merge done somehow?
[19:04] <cyphermox> what do you mean it's not possible, I've done it before ;)
[19:04] <micahg> cyphermox: oh, you mean in the changelog?
[19:04] <micahg> or in the LP diff?
[19:04] <cyphermox> yes
[19:05] <cyphermox> no, changelog should have the diff from what's left as a delta :)
[19:05] <larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
[19:05] <micahg> cyphermox: ah, ok, yes
[19:05] <cyphermox> or actually, a description of what is left as changes
[19:05] <micahg> larsduesing: ^^ see above conversation, update the changelog with the list of changes over Debian
[19:05] <cyphermox> I must have written it in an unclear way :)
[19:06] <larsduesing> micahg: sorry, I got nothing here
[19:06] <larsduesing> netsplit or such
[19:06] <cyphermox> larsduesing: you're merging from Debian; which implies there are still changes left as differences from how the package is in Debian
[19:06] <cyphermox> these remaining changes should be listed in changelog :)
[19:07] <larsduesing> hmm
[19:07] <larsduesing> ok
[19:07] <micahg> larsduesing: something like this https://launchpad.net/ubuntu/+source/fox1.6/1.6.45-1ubuntu1
[19:07] <cyphermox> right
[19:07] <cyphermox> it should as a minimum be listing the upstart job file added
[19:08] <cyphermox> micahg: I'm curious as to what you said wasn't possible though?
[19:08] <micahg> cyphermox: having LP show the diff in the merge proposal from Debian :)
[19:09] <larsduesing> oh, so I should add all changes from ubuntu since the last merge from debian?
[19:09] <micahg> *diff from Debian in the merge proposal
[19:10] <cyphermox> larsduesing: yes
[19:10] <larsduesing> ok... I'm doing
[19:10] <cyphermox> micahg: no, indeed LP wouldn't show it, but that's fine as I should be able to generate that myself
[19:12] <cyphermox> and indeed it's just the upstart job that isn't listed
[19:18] <larsduesing> yes. That should be all.
[19:18] <larsduesing> sorry, I'm learning and learning
[19:18] <larsduesing> :)
[19:18] <larsduesing> thanks
[19:21] <cyphermox> larsduesing: no problem at all; I just didn't think I should be fixing this particular thing myself for your merge; it was a good opportunity to show bzr diff --old ;)
[19:21] <cyphermox> larsduesing: not sure how you committed your merge though, bzr commit or debcommit?
[19:21] <larsduesing> At least I have only a small package
[19:22] <larsduesing> debcommit
[19:22] <cyphermox> but a very useful one
[19:22] <larsduesing> All I saw was nobody is really caring for it, and so I try my best
[19:23] <cyphermox> larsduesing: (really just personal preference there) I'd use bzr commit for merges, to avoid having the commit list Debian changes; just the actual merge revision changelog
[19:23] <cyphermox> larsduesing: thanks for looking at it
[19:25] <larsduesing> simple learning how to do it in real world :)
[19:25] <larsduesing> (with more than 10-15 committers as normal...)
[19:26] <larsduesing> ok, so I should delte this branch, do a new one, and this time real correct :)
[19:27] <larsduesing> away for 10-15 minutes, got to fetch shopping out of the car from my wife :)
[19:33] <cyphermox> larsduesing: no real reason to delete the branch, you can just apply your fixes on top of it
[19:40] <bdmurray> mvo: I'm looking at bug 991282 and thinking about how to stop duplicates from the same reporter coming in
[19:40] <bdmurray> mvo: what do you think of search DpkgTerminalLog for the same 'DuplicateSignature' and stop reporting if it exists?
[19:41] <bdmurray> I guess that assumes they reported it before
[19:43] <mvo> yes, that sounds reasonable
[19:44] <mvo> we would have to SRU that, right?
[19:44] <bdmurray> well, doing it in Quantal alone would be fine with me
[19:45] <mvo> in this case feel free to just add it to trunk
[19:55] <cjwatson> larsduesing: in fact you should generally actively *not* delete branches when you get needs-fixing reviews; it's easier for your reviewer to see what you've fixed if you simply commit the fixes on top
[19:56] <cjwatson> LP merge proposals are much more useful when people do that
[20:34] <bdmurray> dobey: so is lptools not supposed to be Ubuntu specific?
[20:35] <dobey> bdmurray: not sure i understand that question
[20:35] <dobey> bdmurray: it is for tools that use the launchpad API
[20:38] <bdmurray> dobey: okay, I've a tool that parses the description for apport information not every project has bugs that are reported by apport
[20:38] <bdmurray> dobey: however, it'll do none apport specific things too
[20:38] <bdmurray> er non-apport
[20:38] <dobey> ok
[20:39] <bdmurray> lptools still seems like an okay place for it?
[20:39] <dobey> yeah, i don't see why not
[20:40] <bdmurray> cool, thanks
[20:41] <dobey> that doesn't seem ubuntu specific to me.
[20:41] <dobey> for things that are truly ubuntu specific, i guess ubuntu-dev-tools is where they'd belong though.
[20:59] <kees> infinity: did you get the eglibc patch?
[21:01] <slangasek> did ya get that THING I sent ya
[21:09] <dobey> can someone accpet ubuntuone-client into precise-proposed now please? i've gone through and added [Test Case] and [Regression Potential] headers to bugs. thanks
[21:14] <stgraber> cnd: looks like the SRU from bug 973297 is a fail, can you confirm?
[21:15] <ahasenack> hm, is bzr merge-upstream known to do something to po files? Like, wrap long lines?
[21:19] <slangasek> ahasenack: I thought my wishlist bug requesting that bzr merge do intelligent .po handling was still outstanding
[21:20] <ahasenack> slangasek: not sure what is happening, but I'm using merge-upstream with a new tarball, and in both the tarball and local branch some entries in the po are very long lines
[21:20] <ahasenack> slangasek: so no difference bar one real change, a typo
[21:20] <ahasenack> slangasek: yet the resulting po file has all long lines wrapped, resulting in a big diff
[21:20] <slangasek> interesting
[21:21] <ahasenack> if I just replace the po file with the one from the tarball, this is the diff: http://pastebin.ubuntu.com/1018636/
[21:22] <slangasek> ahasenack: bug #884270?
[21:22] <slangasek> apparently it is fixed :)
[21:22] <ahasenack> if I run merge-upstream with the tarball, I get this diff: http://pastebin.ubuntu.com/1018638/
[21:22] <ahasenack> slangasek: let me check that bug
[21:24] <slangasek> so it's configurable and overrideable
[21:24] <slangasek> but yeah, with that code enabled, by default your .po files are going to be in a normalized format after merge
[21:24] <ahasenack> ok, that explains it
[21:25] <slangasek> basically, because it's using the gettext merging tools that understand .po format, instead of bzr's default line-based merge
[21:25] <ahasenack> so, po_merge
[21:25] <ahasenack> I do have it
[21:25]  * ahasenack keeps on reading
[21:26] <cjwatson> I occasionally do bzr remerge --no-plugins when it annoys me
[21:26] <cjwatson> well, on the specific files
[21:26] <slangasek> good to know
[21:26] <cjwatson> that said, if your .po files aren't already run through msgcat before committing them to bzr, you're doing it wrong
[21:26] <slangasek> though honestly, everyone should normalize their .po files anyway, to reduce noise in the VCS diffs :)
[21:26]  * slangasek nods
[21:27] <cjwatson> you can do that once in one separate commit before merging
[21:27] <ahasenack> in this case both the previous and the current one are not normalized
[21:27] <ahasenack> and to normalize them I will have to add a package patch
[21:28] <slangasek> heh, yeah, not the thing to do in this case then
[21:28] <ahasenack> because the upstream tarball has them like that
[21:28] <slangasek> but I guess upstream is in poking distance, so they can fix it for next time ;0
[21:28] <slangasek> ;)
[21:28] <ahasenack> yeah, I could cheat even for this one I guess
[21:29] <ahasenack> anyway, good to understand what is going on
[21:29] <ahasenack> thanks
[21:31] <ahasenack> good to know about remerge too
[21:31] <ahasenack> since bzr merge-upstream --no-plugins wouldn't work :)
[21:31] <cjwatson> Indeed :)
[21:32] <SpamapS> hrm, this is an odd nut here..
[21:33] <SpamapS> https://launchpadlibrarian.net/106616529/apt-get-install.log
[21:33] <SpamapS> install zookeeperd on a fresh quantal box...
[21:33] <SpamapS> the dep chain is  zookeeperd->zookeeper->default-jre-headless->openjdk-7-jre-headless ...
[21:33] <SpamapS> but somehow, default-jre-headless is configured *before* openjdk-7-jre-headless
[21:34] <cjwatson> any Recommends or circular dependencies involved?
[21:34] <SpamapS> then zookeeper is  configured, and then zookeeperd, which then fails because start-stop-daemon: unable to stat /usr/bin/java (No such file or directory)
[21:34] <SpamapS> the java world is one big circular dependency .. so its quite likely
[21:35] <cjwatson> Doesn't seem likely that e.g. openjdk would depend on zookeeper though
[21:35] <SpamapS> ahh, --no-install-recommends produces a different order
[21:35] <SpamapS> the "correct" order
[21:36] <slangasek> SpamapS: I'm confused, I don't see the error you're describing in that log (zookeeper start/running, process 9007)
[21:37] <SpamapS> slangasek: thats just the script
[21:37] <SpamapS> slangasek: it fails shortly thereafter
[21:37] <dobey> hi SpamapS
[21:37] <slangasek> so the package configuration doesn't guarantee a working package?
[21:37] <slangasek> anyway, ca-certificates-java is almost certainly part of the lovely dependency loop... not sure why zookeeper turns up in the middle though
[21:38] <dobey> also, can someone accept ubuntuone-control-panel into precise-proposed ? i've added the test/regression headings as requested on its bugs as well.
[21:38] <slangasek> possibly because zookeeper only depends on default-jre-headless, which *is* configured, so dpkg/apt have no reason to think zookeeper can't also be configured?
[21:39] <SpamapS> slangasek: yeah not sure, start-stop-daemon should be returning 0, meaning that the job shouldn't show 'started' .. but maybe it returns non-zero *after* forking
[21:39] <slangasek> that's a buggy assumption of course, it should entirely solve the dependency loop before proceeding
[21:39] <SpamapS> slangasek: but default-jre-headless depends on openjdk-7-jre-headless
[21:39] <slangasek> yes, but there's a dependency loop
[21:39] <slangasek> it has to be broken *somewhere*
[21:39] <SpamapS> slangasek: so default-jre-headless shouldn't be configuring until after openjdk-7-jre-headless
[21:40] <slangasek> we appear to be going in circles about loops ;)
[21:41]  * SpamapS agrees and tries desperately to avoid crossing the streams
[21:41] <SpamapS> slangasek: something in the Recommends path changes the problem :p
[21:42] <slangasek> oh actually, I hallucinated that loop
[21:42] <slangasek> default-jre-headless isn't part of the loop
[21:43] <slangasek> SpamapS: this seems to not be the ca-certificates-java in quantal though, which is still -6-?
[21:44] <SpamapS> slangasek: right, seems to dep only on 6
[21:44] <SpamapS> slangasek: but openjdk-7-jre-headless does Provide: java6-runtime-headless
[21:45] <SpamapS> don't we have tools for finding circular deps?
[21:46] <slangasek> circular deps are not a bug
[21:47] <slangasek> ah, so the problem is that default-jre-headless *also* Provides: java6-runtime-headless
[21:48] <slangasek> so apt/dpkg get confused and decide that the circular dependency is between default-jre-headless, openjdk-7-jre-headless, and ca-certificates-java
[21:48] <slangasek> when it's supposed to only be between openjdk-7-jre-headless and ca-certificates-java
[21:48] <slangasek> SpamapS: I think the workaround is to drop the provides from default-jre-headless
[21:49] <slangasek> SpamapS: but it's still a bug in the package manager's configure ordering
[21:53] <SpamapS> slangasek: so, should I open a dpkg task on bug 1007433 ?
[21:53] <hyperair> why is upower refusing to allow me to hibernate? =\
[21:53] <slangasek> SpamapS: seems like it
[21:53] <hyperair> it seems to be a polkit issue.
[21:56] <hyperair> aha, found it: http://askubuntu.com/questions/94754/how-to-enable-hibernation-in-12-04
[21:59] <larsduesing> cyphermox: if you are still here, i fixed the changelog
[22:38] <ahasenack> Daviey: around?
[22:39] <ahasenack> Daviey: fwiw, #1004678 is back in sponsorship, I also just subscribed ubuntu-sponsors
[22:39] <ahasenack> Daviey: just pinging you because you took a look before
[22:40] <bdmurray> slangasek: do you have an idea of what is wrong in bug 991282?
[22:53] <slangasek> bdmurray: a wrong successful exit from mkinitramfs?  Maybe a wrong mkinitramfs on the path that's not from Ubuntu?
[22:58] <bdmurray> a modified mkinitramfs should show up in the bug description
[23:04] <slangasek> bdmurray: right, but it could be in /usr/local/bin or something
[23:05] <bdmurray> ah, sure
[23:05] <maco3> is there some sort of rule that says "the more you learn about how something works, the weirder the error conditions you hit become"?
[23:25] <penguin42> maco3: You do normally manage to make more complex configs and work past the simpler errors to points where less knowlegeable people won't have reached
[23:25] <penguin42> maco3: The other theory is the code  is just out to get you
[23:27] <maco3> penguin42: i learned today that doing a dist upgrade inside of byobu is a bad ide
[23:27] <maco3> *ideda
[23:27] <maco3> *idea
[23:27] <maco3> grawr
[23:27] <penguin42> the boyobu died during the upgrade?
[23:27] <maco3> yep
[23:27] <maco3> ps tells me dpkg is still running and trying to ask me questions
[23:27] <maco3> i just can't *answer* the questions
[23:28] <penguin42> is that a valid bug in byobu?
[23:28] <maco3> probably not? i think python is was mid-upgrade
[23:29] <maco3> you're technically supposed to close all applications before going to a new release
[23:29] <penguin42> hmm - I wouldn't expect screen to die in those circumstances
[23:29] <maco3> its just not the sort of thing i think of as an "application"
[23:31]  * penguin42 doesn't know enough about python to know if it's supposed to be able to cope - it's a mess if it can't
[23:33] <maco3> JanC just pointed out that when running an upgrade remotely is when you *really* want screen
[23:34] <JanC> I think the server upgrade notes recommend that actually
[23:35] <JanC> I'm sure Debian recommends it
[23:35] <penguin42> yeh it's good for when the network disappears during the upgrade
[23:37] <Laney> yeah it's known when screen gets upgraded
[23:38] <Laney> for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788
[23:38] <JanC> ah, so screen is still running, but you can't attach?
[23:38]  * maco3 raises an eyebrow
[23:38] <Laney> if it is this bug
[23:39] <JanC> that's ugly  :-/
[23:40] <JanC> does tmux have the same issue?
[23:40] <maco3> that bug only talks about if you get disconnected from the ssh session
[23:41] <maco3> i was connected the entire time. screen stopped
[23:41] <JanC> Laney: I guess that's why Debian makes you upgrade some essential packages first, then the rest?
[23:42] <maco3> https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1007658 <- my bug