=== cinerama_ is now known as cinerama === pjdc_ is now known as pjdc [02:30] doko: did you need something from me? [02:33] Some days are better than others: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/992941/comments/5 [02:34] Launchpad bug 992941 in wxwidgets2.6 (Ubuntu) "Remove wxwidgets2.6" [Low,Fix released] [02:34] excellent! [02:35] awesome, now if we can just get rud of sqlite [02:35] *rid [03:26] Good morning [03:33] infinity: you around? [03:34] kees: Nope. [03:35] infinity: dang. I was gonna ask you about eglibc coordination. [03:35] * slangasek marks infinity absent [03:36] infinity: I have a patchset that cleans up the existing patches (making them not ubuntu-specific) [03:36] kees: email would be better, I'm only sort of here. [03:36] infinity: okidoky. [03:37] infinity: alternatively, I could just upload it to quantal. ;) [03:38] You don't want a review of any sort? :P [03:38] hehe [03:38] emailing you the debdiff now. [04:18] SpamapS: I now added test cases and regression potential to all apport SRU bugs [05:51] rickspencer3, cjwatson, slangasek: FYI, just sent the May stable+1 status to u-devel@ [05:51] hi pitti [05:51] thanks! [06:23] pitti: thanks much :) === tkamppeter_ is now known as tkamppeter [07:09] good morning === dendro-afk is now known as dendrobates [08:10] good morning together [08:26] hello larsduesing [08:42] mvo, hey [08:42] mvo, is upgrade to quantal still blocked on py3 port of the release-upgrader ? [08:44] yes, afaict its still not working, but we need to make it work for a1 [08:49] mvo, ta === dendrobates is now known as dendro-afk [09:19] what can i use in place of gobject.Mainloop in Python3? [09:20] brendand: use python3-gi, and GLib.MainLoop [09:22] 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] pitti - from gi.repository import Glib? [09:23] pitti - i know for sure i have python3-gi installed [09:23] pitti - btw, i'm on precise [09:24] GLib, not Glib [09:25] pitti - ahem [09:29] Never mind found it: https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/591100 [09:29] Launchpad bug 591100 in autofs5 (Ubuntu Lucid) "autofs5 eats the cpu if you have large groups" [Undecided,Fix released] [09:37] another question. what are we meant to use instead of pygst? am i correct in thinking some gi binding? [09:41] brendand: that's the general idea, but gstreamer 0.10 is not yet introspectable; gstreamer 1.0 will mostly be [09:41] (it's in universe now) [09:42] brendand: if you need gst 0.10, then you can't use python3 yet [09:42] pitti - will that be in precise? [09:42] no, it won't [09:42] precise -> python 2 [09:42] (and pygst) [09:43] pitti - so i can't install gstreamer 1.0 on precise to test? [09:44] pitti - just want to know if i need to be updating to quantal [09:44] brendand: oh, you certainly can backport/build/install it, but it is not in precise prpoer [09:44] pitti, ok [09:44] brendand: I figure the gstreamer1.0 etc. packages will build on precise just fine [09:45] 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? === MacSlow is now known as MacSlow|lunch [11:21] 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] 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] smb: All other things being equal, that looks like a reasonable SRU candidate [11:41] 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] 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] mvo: I was sure I'd fixed that in revisions 2430 to 2432. What's the exact error? [11:44] Oh [11:44] Ddamnit, it had worked [11:44] OK, give me a minute, I'll fix that [11:46] cjwatson: thanks! once that is done, I look at the merge from mterry and do a new upload for a1 [11:50] Oh, wow, it's using __import__, what could possibly go wrong [11:57] *cough* [11:58] 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] It's OK, I broke it, I'll fix it [11:58] ... somehow [12:02] mvo: Try r2436 [12:02] cjwatson: using importlib? [12:02] * mvo checks [12:02] cjwatson: oh, interessting! [12:03] Possibly ought to have passed locals() as well, but the docs say that the standard implementation only uses globals() [12:03] I'm fairly sure this won't work yet with Python 3, but that's for another day [12:04] cjwatson: thanks a bunch! I look at the py3, I think we can use importlib for this [12:04] cjwatson: I check that out and if its good commit [12:05] py3 can probably use __import__ too, with some extra fiddling - not susre [12:05] but yeah, importlib should be a possibility [12:06] 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] ok === MacSlow|lunch is now known as MacSlow === martikka is now known as Goodi === _salem is now known as salem_ === chuck__ is now known as zul [13:01] 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] seb128, that was from ev's weekly report, he can probably elaborate [13:03] 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] 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] 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] 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] 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] less work, I will not complain ;-) [13:06] ev, thanks! [13:06] :) [13:07] I'm glad that ogra pointed that to -release and that I read it [13:07] seb128: sure thing. Still in the planning stages, but I'll keep you in the loop. [13:07] thanks [13:07] 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] ah, glad I could automate that task away for you :) [13:08] ;-) [13:31] ev, is there a way to see the issues you submit on errors.ubuntu.com? [13:41] 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] i.e they run it on the .crash and get a .upload and nothing else and they get confused on what happened [13:41] so they go on launchpad and open a bug saying they get a segfault and can't report it [13:42] hm, what kind of users? i. e. the "kenvandine" kind, or the "my mother" kind? [13:42] I'm not sure how we solve that and if we should wait on errors.ubuntu.com to improve [13:42] the whole point of disabling this was that we stop getting reports for stables, after all? [13:42] pitti, people who run quantal [13:42] seb128: oh, quantal; we can just re-enable LP bugs for quantal again [13:42] i was on precise though [13:42] there's no reason why it's disabled there other than "we did not get around to do it" [13:43] but that isn't the norm [13:43] pitti, do we have retracers for q yet? [13:43] seb128: sure, since day 1 :) [13:43] they are now trivial to set up [13:43] right, your new setups make that trivial ;-) [13:43] just copy the precise config file, s/precise/quantal/, done [13:43] pitti, ok, can we get apport turned on again in quantal soon then? [13:43] I think that's most of the issue I faced recently [13:44] seb128: yes - http://errors.ubuntu.com/user/$your_sha512_hashed_system_uuid [13:44] users who jumped on quantal, have segfaults and struggled to report them [13:44] ev, how do I compute "your_sha512_hashed_system_uuid"? ;-) [13:44] 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] cool [13:45] ev, btw errors.ubuntu.com seems to regressed on something that worked the other day for me [13:45] ev, if I do [13:45] seb128: uploaded [13:45] "Error reports for "12.04" gnome-control-center "all installed version"" on a month [13:46] I get nothing listed [13:46] i.e "No data to display" [13:46] oh [13:46] seb128: oh? (working on a one-liner for the compuation) [13:46] is "month" a "since the month start"? [13:46] i.e today? [13:46] yes [13:46] ok [13:46] that's why :p [13:46] hehe :) [13:46] I though it was a month timeframe [13:46] good, no bugs yet today :) [13:46] yeah, I'll fix this when we do the date range stuff [13:46] i.e sliding win [13:47] indeed [13:47] exactly that [13:47] ev, thanks [13:47] sure thing [13:48] 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] ev, and is there a way the repartition of a specific issue by versions? [13:49] seb128: can you elaborate please? [13:49] 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] -on first [13:49] all 3 are completely independent [13:49] 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] is there some nifty way to test apport hook triggers? [13:50] hallyn: yes :-) [13:50] hallyn: apport-bug [13:50] 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] hallyn: apport-bug [13:51] larsduesing: doesn't work well without x or without giving my lp id [13:52] 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] oh wait, maybe that gets me far enough [13:52] thanks :) [13:53] hallyn: it works in commandline-mode... [13:53] 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] hallyn: apport-bug --save [13:53] I'll do that when we're back on Wednesday [13:53] larsduesing: perfect. thanks. [13:53] hallyn: np [13:54] hallyn: to be fair, I had these troubles a few days ago, and was helped here :) [13:55] larsduesing: the libvirt apport hooks have been wrongly isntalled forever. I needed a somewhat simple test case for SRU justification. :) [13:55] (that did not include "force libvirt to segv") [13:55] ev, I'm done with questions, thanks for the replies ;-) [13:55] pitti, thanks as well for the replies and for re-enabling apport in q ;-) [13:57] 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] I've added that to my todo item for talking to Matthew [13:58] seb128: sure thing. Always looking for ways to make this thing more useful for you guys. [13:58] ;-) [14:00] seb128: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum [14:00] that should give you the other part of the URL [14:00] so http://errors.ubuntu.com/user/$that [14:00] without the dollar sign, of course [14:01] ev, excellent, thanks again ;-) [14:05] seb128: I take it that worked? [14:07] ev, yes [14:07] yay [14:08] 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] I don't see a '--override' option [14:09] ev, is there any way to go from those report to the "master" or to see if they have associated launchpad bugs? [14:09] seb128: not as yet. Adding to the list. :) [14:10] ;-) [14:10] seb128: I should've just created another blueprint/UDS session for "things Seb wants/needs" ;) [14:11] lol [14:11] ++ [14:48] Hi all! [14:54] how does apt determine the order in which packages are configured? does the Priority field get used in any way? [14:54] jono: hi! do the accomplishment descriptions use tabs or are spaces fine as well (for listing the steps)? [14:58] htorque, tabs please :-) [14:58] 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] libreoffice-3.6.0~alpha1 succeeded building in 1h52min on precise. [15:01] now only have to lob that over to quantal. [15:05] that quick! =) [15:09] sbeattie, are the new openjdk-6 packages ready for < 12.04 yet? [15:14] xnox: ccache+16GB RAM+SSD. Half an hour of that is tar/xz compressing the 2GB libreoffice-dbg package. [15:14] heh =) [15:15] xz need multithreading. [15:15] *nods* [15:22] xnox: do you know if sunrpc's max_shared parameter was ever accepted upstream? [15:23] mterry: do you feel good about your software-updater branch to land in a upload for today? [15:23] stokachu: no clue. should check. this is with regards to nfs, right? [15:23] mvo, the move-changelogs one? Sure [15:23] mterry: excellent [15:23] stokachu: or something else? [15:23] xnox: yea [15:24] 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] xnox: i lowered the sunrpc.min_resvport=200 and can allow these 13k mounts to succeed [15:25] well done! =) [15:25] but i dont want it to interfere with other services like samba [15:26] 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] ok will do, thanks! [15:27] stokachu: try jelmer, he might know a lot. [15:27] https://launchpad.net/~jelmer [15:27] he is deep into samba and might now quirks like that [15:28] zul: you didn't actually make the change in nova-common.postinst ... [15:29] Laney: fix is coming now [15:30] 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] Laney: second upload is coming [15:31] sweet === scott-work_ is now known as scott_work === Guest88650 is now known as zumbi [17:21] wasn't there a kernel team member asking about package install failures and postinst earlier this week? [17:21] bdmurray: apw possibly [17:22] i was asking about postinst indeed, though not about errors [17:22] 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] okay, I'm just looking at bug 991282 [17:23] Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [High,Confirmed] https://launchpad.net/bugs/991282 [17:36] and that bug seems to be a duplicate of bug 996373 [17:36] Launchpad bug 996373 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Undecided,New] https://launchpad.net/bugs/996373 [17:49] mterry, hey [17:50] jono, hello [17:50] mterry, dpm mentioned that the Quickly flash template and /opt bug have been fixed in quickly trunk [17:50] jono, yup. I pushed to precise-proposed too [17:50] awesome! that was going to be my next question [17:50] jono, (and quantal) [17:50] I will check proposed, thanks! [17:51] I plan on upgrading to Quantal at A1 next week [17:51] thanks [17:51] jono, please do, let me know of any issues so I can fix them before it actually hits users! :) [17:51] mterry, will do, will test now [17:53] mhall119: swing global menu> !! wicked [17:55] what in the world is swing global menu? [17:55] mterry, when did you push it to proposed? [17:55] highvoltage: global menu integration for apps using swing java toolkit [17:56] aah [17:56] jono, oh right, it hasn't been accepted yet by an archive admin [17:56] ahhh np [17:57] mterry, did you manage to take a look at the qt-quick template? [17:57] I am not sure if it has been submitted [17:59] jono, no I haven't looked yet [18:00] jono, was it ready for review? [18:00] I am not sure, I am checking into it [18:00] I just wasnt sure if he had submitted it yet [18:00] I know there is the qt-quick one and the HTML5 template [18:26] oh that's fantastic all the dupes of bug 991282 are from the same person [18:26] Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [High,Confirmed] https://launchpad.net/bugs/991282 [18:26] 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] 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] mterry: yeah, jibel is made of awsome, it just needs a proper source package now and upload and we should be good :) [18:29] mvo, yar, I can do that [18:30] ta [18:30] 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] mvo, you mean like bug 956175 ? [18:32] Launchpad bug 956175 in Auto Upgrade Testing "Add an option to pull update-manager from bazaar" [Wishlist,Triaged] https://launchpad.net/bugs/956175 [18:33] mterry: yeah [18:33] mvo, patches welcome... ;) [18:33] hahahaha [18:33] thats not what you tell upstream, its the other way around ;) [18:34] mvo, isn't that what every feature request is? A "patches welcome" to upstream? :) [18:34] I shouldn't argue with you, you are too smart ;) [18:35] mvo, flattery will get you no patches, sir. :) [18:35] *damm* [18:35] ;) [18:35] * mvo tries to offer some tea and cookies next [18:35] heh [18:45] >< 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] jibel, is lp:auto-upgrade-testing in a releasable state? Like, can I package it up and put it in quantal? [18:57] 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] cyphermox: ^^ what you're asking isn't possible in LP [19:03] cyphermox: ^^ [19:03] the what? [19:04] cyphermox: it's yet another problem with UDD :) [19:04] isn't the merge done somehow? [19:04] what do you mean it's not possible, I've done it before ;) [19:04] cyphermox: oh, you mean in the changelog? [19:04] or in the LP diff? [19:04] yes [19:05] no, changelog should have the diff from what's left as a delta :) [19:05] 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] cyphermox: ah, ok, yes [19:05] or actually, a description of what is left as changes [19:05] larsduesing: ^^ see above conversation, update the changelog with the list of changes over Debian [19:05] I must have written it in an unclear way :) [19:06] micahg: sorry, I got nothing here [19:06] netsplit or such [19:06] larsduesing: you're merging from Debian; which implies there are still changes left as differences from how the package is in Debian [19:06] these remaining changes should be listed in changelog :) [19:07] hmm [19:07] ok [19:07] larsduesing: something like this https://launchpad.net/ubuntu/+source/fox1.6/1.6.45-1ubuntu1 [19:07] right [19:07] it should as a minimum be listing the upstart job file added [19:08] micahg: I'm curious as to what you said wasn't possible though? [19:08] cyphermox: having LP show the diff in the merge proposal from Debian :) [19:09] oh, so I should add all changes from ubuntu since the last merge from debian? [19:09] *diff from Debian in the merge proposal [19:10] larsduesing: yes [19:10] ok... I'm doing [19:10] micahg: no, indeed LP wouldn't show it, but that's fine as I should be able to generate that myself [19:12] and indeed it's just the upstart job that isn't listed === yofel_ is now known as yofel [19:18] yes. That should be all. [19:18] sorry, I'm learning and learning [19:18] :) [19:18] thanks [19:21] 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] larsduesing: not sure how you committed your merge though, bzr commit or debcommit? [19:21] At least I have only a small package [19:22] debcommit [19:22] but a very useful one [19:22] All I saw was nobody is really caring for it, and so I try my best [19:23] 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] larsduesing: thanks for looking at it [19:25] simple learning how to do it in real world :) [19:25] (with more than 10-15 committers as normal...) [19:26] ok, so I should delte this branch, do a new one, and this time real correct :) [19:27] away for 10-15 minutes, got to fetch shopping out of the car from my wife :) [19:33] larsduesing: no real reason to delete the branch, you can just apply your fixes on top of it [19:40] mvo: I'm looking at bug 991282 and thinking about how to stop duplicates from the same reporter coming in [19:40] Launchpad bug 991282 in initramfs-tools (Ubuntu) "package linux-image-3.2.0-24-generic 3.2.0-24.37 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1" [Low,Confirmed] https://launchpad.net/bugs/991282 [19:40] mvo: what do you think of search DpkgTerminalLog for the same 'DuplicateSignature' and stop reporting if it exists? [19:41] I guess that assumes they reported it before [19:43] yes, that sounds reasonable [19:44] we would have to SRU that, right? [19:44] well, doing it in Quantal alone would be fine with me [19:45] in this case feel free to just add it to trunk [19:55] 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] LP merge proposals are much more useful when people do that [20:34] dobey: so is lptools not supposed to be Ubuntu specific? [20:35] bdmurray: not sure i understand that question [20:35] bdmurray: it is for tools that use the launchpad API [20:38] 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] dobey: however, it'll do none apport specific things too [20:38] er non-apport [20:38] ok [20:39] lptools still seems like an okay place for it? [20:39] yeah, i don't see why not [20:40] cool, thanks [20:41] that doesn't seem ubuntu specific to me. [20:41] for things that are truly ubuntu specific, i guess ubuntu-dev-tools is where they'd belong though. [20:59] infinity: did you get the eglibc patch? [21:01] did ya get that THING I sent ya [21:09] 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] cnd: looks like the SRU from bug 973297 is a fail, can you confirm? [21:15] Launchpad bug 973297 in xserver-xorg-input-evdev (Ubuntu) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Triaged] https://launchpad.net/bugs/973297 [21:15] hm, is bzr merge-upstream known to do something to po files? Like, wrap long lines? [21:19] ahasenack: I thought my wishlist bug requesting that bzr merge do intelligent .po handling was still outstanding [21:20] 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] slangasek: so no difference bar one real change, a typo [21:20] slangasek: yet the resulting po file has all long lines wrapped, resulting in a big diff [21:20] interesting [21:21] if I just replace the po file with the one from the tarball, this is the diff: http://pastebin.ubuntu.com/1018636/ [21:22] ahasenack: bug #884270? [21:22] Launchpad bug 884270 in Bazaar "bzr should do smarter merging of .po files" [High,Fix released] https://launchpad.net/bugs/884270 [21:22] apparently it is fixed :) [21:22] if I run merge-upstream with the tarball, I get this diff: http://pastebin.ubuntu.com/1018638/ [21:22] slangasek: let me check that bug [21:24] so it's configurable and overrideable [21:24] but yeah, with that code enabled, by default your .po files are going to be in a normalized format after merge [21:24] ok, that explains it [21:25] basically, because it's using the gettext merging tools that understand .po format, instead of bzr's default line-based merge [21:25] so, po_merge [21:25] I do have it [21:25] * ahasenack keeps on reading [21:26] I occasionally do bzr remerge --no-plugins when it annoys me [21:26] well, on the specific files [21:26] good to know [21:26] that said, if your .po files aren't already run through msgcat before committing them to bzr, you're doing it wrong [21:26] though honestly, everyone should normalize their .po files anyway, to reduce noise in the VCS diffs :) [21:26] * slangasek nods [21:27] you can do that once in one separate commit before merging [21:27] in this case both the previous and the current one are not normalized [21:27] and to normalize them I will have to add a package patch [21:28] heh, yeah, not the thing to do in this case then [21:28] because the upstream tarball has them like that [21:28] but I guess upstream is in poking distance, so they can fix it for next time ;0 [21:28] ;) [21:28] yeah, I could cheat even for this one I guess [21:29] anyway, good to understand what is going on [21:29] thanks [21:31] good to know about remerge too [21:31] since bzr merge-upstream --no-plugins wouldn't work :) [21:31] Indeed :) [21:32] hrm, this is an odd nut here.. [21:33] https://launchpadlibrarian.net/106616529/apt-get-install.log [21:33] install zookeeperd on a fresh quantal box... [21:33] the dep chain is zookeeperd->zookeeper->default-jre-headless->openjdk-7-jre-headless ... [21:33] but somehow, default-jre-headless is configured *before* openjdk-7-jre-headless [21:34] any Recommends or circular dependencies involved? [21:34] 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]