[01:08] <psusi> is there some info I can read somewhere on the procedure for managing debian packages in git?
[08:58] <trijntje> Hi all, I'm trying to build localised iso images for dutch for Quantal, but for some reason all builds on amd64 fail because of an error configuring the kernel:http://pastebin.com/DUCv8j4h
[08:58] <trijntje> The full build log can be found here (https://launchpadlibrarian.net/122238857/binary.log), can somebody provide me some pointers on how to resolve this?
[13:43] <infinity> pitti: Is apport meant to ignore crashes until I log out and back in, or is that a bug/misfeature?
[13:44] <infinity> pitti: (And how can I force it to re-scan /var/crash/ and report everything that hasn't been reported yet without logging out?)
[14:01] <penguin42> infinity: Well you can give it one explicitly, i.e. apport-cli /var/crash/whatever
[14:03] <infinity> penguin42: Not quite what I was hoping for, with a backlog of a dozen or so.
[14:03] <penguin42> infinity: well, that's trivial in shell
[14:05] <infinity> penguin42: Not the point, but thanks.
[14:06] <infinity> achiang: So, that new valgrind from unstable will require some MIRs for openmpi stuff, or some removal of build-deps and (presumably) features.
[14:09] <infinity> achiang: mpi-default-dev is in universe, as is its direct dep (libopenmpi-dev)
[14:13] <infinity> achiang: Doing a logical revert of this bit could be the path of least resistance:
[14:14] <infinity>   * Enable mpiwrap module (Closes: #565139)
[14:14] <infinity>     - Add new valgrind-mpi package
[14:14] <infinity>     - valgrind Suggests valgrind-mpi
[14:25] <infinity> achiang: In fact, I've just done that on your behalf, and will sponsor this with your name attached to it, so you get the merge nags. :P
[14:33] <infinity> achiang: Uploaded, with the following diff on top of yours: http://paste.ubuntu.com/1443561/
[14:53] <infinity> achiang: Oh, and FTBFS on arm because of retaining the dh_autoreconf delta.  Oops.
[16:47] <achiang> infinity: the FTBFS is why it was rejected?
[16:51] <infinity> achiang: I uploaded a fixed version.
[16:53] <achiang> infinity: oh, thanks!
[16:56] <achiang> infinity: so no action needed from me? (i got the rejected emails so not entirely clear to me what i need to do)
[16:56] <infinity> achiang: https://launchpad.net/ubuntu/+source/valgrind <-- All good now.
[16:57] <achiang> derp. thank you
[16:57]  * achiang only built on x86, will definitely build on armhf next time
[16:58] <achiang> <= ashamed
[16:58] <infinity> S'ok, I didn't test on ARM either. :P
[16:58] <infinity> And, arguably, it's a bug in the Debian patches that he patches configure without patching configure.in to match.
[16:59] <infinity> But not autoreconfing fixes it, so whatever.  Keeps the delta lower.
[17:01] <jtaylor> valgrind upgrade closes 1077014 and 1041117
[17:05] <infinity> Close away, then.
[17:21] <jtaylor> we should probably backport 3.8 to precise
[17:21] <jtaylor> the avx support makes it useful longer
[17:43] <cjwatson> I've been gradually converting all my autotoolsy packages to dh-autoreconf after realising *just how much easier* it makes it to apply build system patches
[17:43] <cjwatson> admittedly in one case this required a giant patch to upgrade from 2.13
[17:52] <cjwatson> (And yeah, I realise it breaks if somebody has foolishly patched generated files - wants to be done as far upstream as possible, really)
[18:25] <infinity> cjwatson: Oh, I'm all for attempts to autoreconf sanely with one's own Debian packages, just noting that it can fail miserably if Ubuntu deviates from Debian on that score.
[18:25] <infinity> cjwatson: (Because, yes, as noted, we may not notice if Debian introduces a patch to the generated files)
[18:26] <infinity> In this case, I noticed because the build actually failed when said patch go regenerated into oblivion, but that was just luck, really.
[18:26] <infinity> s/go/got/
[19:53] <achiang> jtaylor: would a valgrind backport to precise be an SRU candidate or just go into -backports ?
[19:53] <jtaylor> achiang: backports
[19:54] <jtaylor> probably a quite simple one
[19:54] <jtaylor> no rdepends and builds unmodified
[19:54] <jtaylor> wait it has rdepends o_O
[19:54] <jtaylor> but probably all not problematic
[19:55] <achiang> what rdepends does it have? (in the middle of eating a meal now ;)
[19:55] <jtaylor> looks like programs to display its results
[19:56] <jtaylor> kcackegrind eclipse codeblocks stuff
[19:57] <jtaylor> I'll let it settle a bit in raring and file a request
[19:57] <jtaylor> you are welcome to help testing :)
[19:57] <achiang> heh
[19:57] <achiang> ok
[19:57] <jtaylor> thx for the update
[19:58] <achiang> it would be nice for another thing i'm working on to see a newer valgrind in -backports, but now i'm weighing the effort of the rdepends too
[19:58] <achiang> that probably pushes it out into the "nice to have if someone else did it" territory for my own personal bandwidth. :-/
[19:58] <achiang> but yeah, i could help test
[20:01] <penguin42> has something changed with X ABI over the last week ? I've just rebuilt a package with some debug added and it's complaining about ABI version mismatch, doing that last week was fine
[20:02] <jtaylor> which package?
[20:02] <penguin42> jtaylor: It's xserver-xorg-video-cirrus I've been debugging
[20:08] <penguin42>  (EE) module ABI minor version (1) is newer than the server's version (0)
[20:12] <penguin42> ah right, yes it has
[20:12] <penguin42> got bumped last week
[20:14] <psusi> cjwatson, why is libparted packaged in libparted0-debian1 with a dummy libparted0 depending on it?
[22:58] <_abbe> Hola!
[22:59] <_abbe> I've a fix for a bug report for which I've patched the sources, and generated quilt patches (courtesy: dpkg-source --commit)
[22:59] <_abbe> I'm wondering how to go about submitting it
[23:00] <_abbe> should i just upload the quilt patch ? or is there something else i need to follow?
[23:00] <jtaylor> _abbe: which bug?
[23:00] <_abbe> https://bugs.launchpad.net/ubuntu/+source/libnfsidmap/+bug/1088154
[23:00] <jtaylor> _abbe: the usual process is to attach a debdiff and subscribe ubuntu-sponsors
[23:01] <jtaylor> _abbe: for stable release update follow https://wiki.ubuntu.com/StableReleaseUpdates
[23:01] <_abbe> jtaylor: debdiff ? is that a package i need to install
[23:01] <jtaylor> _abbe: a debdiff is a package-patch
[23:02] <jtaylor> it can be generated with the debdiff program, debdiff old.dsc new.dsc
[23:02] <_abbe> oh, devscripts
[23:02] <_abbe> i didn't have that installed, installing it then posting to the bugreport
[23:03] <jtaylor> for a proper debdiff use dch -i, describe your changes and then build source the package
[23:03] <jtaylor> with debuild -us -uc -S
[23:04] <jtaylor> that will give you the new dsc
[23:04] <jtaylor> you may need to install build dependencies, most conviniently that is done with mk-build-deps -ir
[23:05] <_abbe> I'm actually running new .deb in production, i've done anything to control file, just fixed the bug, generate the quilt patch, and built .deb
[23:06] <jtaylor> the quilt patch can be sufficient, depends on who sponsors it in the end
[23:06] <jtaylor> if possible please check if it applies to debian to and submit your patch there too
[23:07] <_abbe> okay, i guess i'll go with quilt then
[23:08] <jtaylor> we also need to know to which release it applies to
[23:09] <_abbe> it's for precise, but looking at changelog i don't see anything in quantal which fixes it
[23:10] <jtaylor> please follow the wiki for an update in precise
[23:10] <jtaylor> but it first needs to be fixed in raring
[23:10] <jtaylor> and quantal
[23:13] <jtaylor> _abbe: could it be a duplicate of bug 939232?
[23:13] <jtaylor> no thats fixed in precise
[23:14] <_abbe> jtaylor: i searched for my bug already, and didn't find in tracker a week ago, and the one you pasted is different from what i'm experiencing
[23:30] <_abbe> posted. thanks for the help jtaylor
[23:40] <jtaylor> hm making functions static is problematic
[23:40] <cjwatson> psusi: who knows, maybe I explained it in the changelog?  see 2.2-4
[23:41] <cjwatson> archaeology (changelog or otherwise) is a fundamental skill in package maintenance :)
[23:42] <psusi> cjwatson, does that mean that this was done because upstream broke abi without changing sonamever?
[23:42] <psusi> cjwatson, and since upstream has moved to a new sonamever, this can be dropped now?
[23:43] <cjwatson> please read the changelog and the contained bug reference, and say that you've done so, before asking further questions?
[23:44] <cjwatson> (if you had, you wouldn't be asking that question)
[23:44]  * cjwatson -> bed
[23:47] <_abbe> yes needs proper testing, but from what i see in my setup, it didn't break anything
[23:48] <cjwatson> BTW I am more than happy to deal with parted 3.x packaging once d-i is migrated away from the relevant obsolete functions
[23:48] <cjwatson> and when I do that I know how to do the appropriate things with its versioning
[23:48] <cjwatson> I just don't see the point of doing it knowing that it will break the installer
[23:49] <jtaylor> _abbe: nfs-utils does not contain libraries, so it might be ok
[23:50] <jtaylor> _abbe: but I think that change should be done upstream first
[23:50] <_abbe> yes, definitely
[23:50] <_abbe> but only if someone else tests it as well
[23:50] <_abbe> this needs a bit of time!
[23:53] <jtaylor> _abbe: it would be good if you could contact upstream about it, maybe the debian maintainers too
[23:53] <jtaylor> this is unfortunately far outside my area of knowledge
[23:53] <_abbe> Okay, I'll post it to upstream as well, and if they accept then file a bug report against Debian
[23:54] <jtaylor> thx
[23:54] <TheLordOfTime> i'd file against Debian anyways
[23:54] <TheLordOfTime> but that's just me ;)
[23:55] <jtaylor> I must leave now, bye
[23:57] <psusi> cjwatson, the fs resize functions have been put back, but in a separate lib, so I think it just needs packaged properly, and d-i and gparted and whatever else patched to link to the new lib
[23:58] <cjwatson> Not that simple.
[23:58] <cjwatson> I'm sure I've explained this at some length before.
[23:58] <cjwatson> I'm currently filing a Debian bug on partman-base with the details of what needs to be done.