=== NCommander is now known as Guest42296 === cpg is now known as cpg|away === cpg|away is now known as cpg === cpg is now known as cpg|away [01:08] is there some info I can read somewhere on the procedure for managing debian packages in git? === chiluk is now known as chiluk_away === jono is now known as Guest95318 === cpg|away is now known as cpg === chiluk_away is now known as chiluk === sgnb` is now known as sgnb === chiluk is now known as chiluk_away === LordOfTime is now known as TheLordOfTime === cpg is now known as cpg|away === cpg|away is now known as cpg === reed is now known as [reed] [08:58] 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] 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? === cpg is now known as cpg|away === henrix_ is now known as henrix === henrix is now known as henrix_ === chiluk_away is now known as chiluk === Quintasan_ is now known as Quintasan [13:43] pitti: Is apport meant to ignore crashes until I log out and back in, or is that a bug/misfeature? [13:44] pitti: (And how can I force it to re-scan /var/crash/ and report everything that hasn't been reported yet without logging out?) === NCommander is now known as Guest31620 [14:01] infinity: Well you can give it one explicitly, i.e. apport-cli /var/crash/whatever [14:03] penguin42: Not quite what I was hoping for, with a backlog of a dozen or so. [14:03] infinity: well, that's trivial in shell [14:05] penguin42: Not the point, but thanks. [14:06] 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] achiang: mpi-default-dev is in universe, as is its direct dep (libopenmpi-dev) [14:13] achiang: Doing a logical revert of this bit could be the path of least resistance: [14:14] * Enable mpiwrap module (Closes: #565139) [14:14] - Add new valgrind-mpi package [14:14] - valgrind Suggests valgrind-mpi [14:25] 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] achiang: Uploaded, with the following diff on top of yours: http://paste.ubuntu.com/1443561/ === chiluk is now known as chiluk_away [14:53] achiang: Oh, and FTBFS on arm because of retaining the dh_autoreconf delta. Oops. === rsalveti_ is now known as rsalveti === yofel_ is now known as yofel [16:47] infinity: the FTBFS is why it was rejected? [16:51] achiang: I uploaded a fixed version. [16:53] infinity: oh, thanks! [16:56] 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] achiang: https://launchpad.net/ubuntu/+source/valgrind <-- All good now. [16:57] derp. thank you [16:57] * achiang only built on x86, will definitely build on armhf next time [16:58] <= ashamed [16:58] S'ok, I didn't test on ARM either. :P [16:58] And, arguably, it's a bug in the Debian patches that he patches configure without patching configure.in to match. [16:59] But not autoreconfing fixes it, so whatever. Keeps the delta lower. [17:01] valgrind upgrade closes 1077014 and 1041117 [17:05] Close away, then. [17:21] we should probably backport 3.8 to precise [17:21] the avx support makes it useful longer [17:43] 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] admittedly in one case this required a giant patch to upgrade from 2.13 [17:52] (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] 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] cjwatson: (Because, yes, as noted, we may not notice if Debian introduces a patch to the generated files) [18:26] 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] s/go/got/ [19:53] jtaylor: would a valgrind backport to precise be an SRU candidate or just go into -backports ? [19:53] achiang: backports [19:54] probably a quite simple one [19:54] no rdepends and builds unmodified [19:54] wait it has rdepends o_O [19:54] but probably all not problematic === cpg|away is now known as cpg [19:55] what rdepends does it have? (in the middle of eating a meal now ;) [19:55] looks like programs to display its results [19:56] kcackegrind eclipse codeblocks stuff [19:57] I'll let it settle a bit in raring and file a request [19:57] you are welcome to help testing :) [19:57] heh [19:57] ok [19:57] thx for the update [19:58] 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] that probably pushes it out into the "nice to have if someone else did it" territory for my own personal bandwidth. :-/ [19:58] but yeah, i could help test [20:01] 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] which package? [20:02] jtaylor: It's xserver-xorg-video-cirrus I've been debugging [20:08] (EE) module ABI minor version (1) is newer than the server's version (0) [20:12] ah right, yes it has [20:12] got bumped last week [20:14] cjwatson, why is libparted packaged in libparted0-debian1 with a dummy libparted0 depending on it? === NCommander is now known as Guest27410 === NCommander is now known as Guest36286 [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] _abbe: which bug? [23:00] <_abbe> https://bugs.launchpad.net/ubuntu/+source/libnfsidmap/+bug/1088154 [23:00] Ubuntu bug 1088154 in libnfsidmap (Ubuntu) "LDAP support broken in rpc.idmapd" [Undecided,Confirmed] [23:00] _abbe: the usual process is to attach a debdiff and subscribe ubuntu-sponsors [23:01] _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] _abbe: a debdiff is a package-patch [23:02] 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] for a proper debdiff use dch -i, describe your changes and then build source the package [23:03] with debuild -us -uc -S [23:04] that will give you the new dsc [23:04] 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] the quilt patch can be sufficient, depends on who sponsors it in the end [23:06] 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] 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] please follow the wiki for an update in precise [23:10] but it first needs to be fixed in raring [23:10] and quantal [23:13] _abbe: could it be a duplicate of bug 939232? [23:13] Launchpad bug 939232 in libnfsidmap (Ubuntu) "nfs mount fails and rpc.idmapd fails" [Medium,Fix released] https://launchpad.net/bugs/939232 [23:13] 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 === chiluk_away is now known as chiluk [23:30] <_abbe> posted. thanks for the help jtaylor [23:40] hm making functions static is problematic [23:40] psusi: who knows, maybe I explained it in the changelog? see 2.2-4 [23:41] archaeology (changelog or otherwise) is a fundamental skill in package maintenance :) [23:42] cjwatson, does that mean that this was done because upstream broke abi without changing sonamever? [23:42] cjwatson, and since upstream has moved to a new sonamever, this can be dropped now? [23:43] please read the changelog and the contained bug reference, and say that you've done so, before asking further questions? [23:44] (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] 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] and when I do that I know how to do the appropriate things with its versioning [23:48] I just don't see the point of doing it knowing that it will break the installer [23:49] _abbe: nfs-utils does not contain libraries, so it might be ok [23:50] _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] _abbe: it would be good if you could contact upstream about it, maybe the debian maintainers too [23:53] 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] thx [23:54] i'd file against Debian anyways [23:54] but that's just me ;) [23:55] I must leave now, bye [23:57] 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] Not that simple. [23:58] I'm sure I've explained this at some length before. [23:58] I'm currently filing a Debian bug on partman-base with the details of what needs to be done.