[00:12] PPA-builder-masters: is there a way to compel a PPA-build to drag in a package as a dependency save doctoring the build's debian/control file to add? [00:14] that is the way to manage build dependencies [00:23] tsimpson, sure; I'm talking about doing this during pkgbinarymangling, e.g. in the dh_auto_test script, to pull in a special dependency to enable coverage reporting--is there a sudo command that'll give me apt-get powers there? [00:24] somehow this seems less illegal than modifying a building package's debian/control [00:26] no, you don't have root access in the build [00:30] doesn't pkgbinarymangler mangle *binary* packages? [00:31] tsimpson, thanks--which debhelper or dpkg script runs early enough to facilitate editing control? reading a log but nothing leaping out at me [00:32] ie, for the langpacks thing, it strips translations out of binary packages for getting them into langpacks [00:32] dobey, I do see that in pitti's code, yes--I think it does this by overriding dh_translations (i.e. diverting it) [00:33] alesage: what are you trying to accomplish exactly? nothing runs early enough to alter debian/control in a PPA (and nothing should alter it) [00:33] for the record I'm using these diversions to replicate a pbuilder-hooks process we use in Jenkins presently [00:33] ok, so PPAs don't have diversions for langpacks and such [00:34] dobey, right the 'no editing control' seems ethical [00:35] if you want to enable diversions of dpkg build tools on PPAs somehow, you probably need to talk to wgrant about adding a feature to launchpad to do that [00:35] dobey just wanting to add li'l ol' gcovr to everybody's control so that I can spit out coverage.xml [00:36] alesage: the best way to do that is probably to just fix the packaging to do that [00:36] dobey, for the record it's working in a PPA with pkgbinarymangler installed, I think that's the design [00:36] dobey that's fair, good suggestion [00:36] pkgbinarymangler is always installed. [00:36] It disables most of its functionality for PPA builds. [00:37] wgrant ok I'm learning :) [00:37] If your pkgbinarymangler changes depend on a package, your pkgbinarymangler should depend on that pacakge. [00:38] wgrant, intriguing, wouldn't have thought of that--this means I could drag in a package, e.g. via pkgbinarymangler itself [00:38] we'll call it retromangling [00:38] If a package uses another package, it must depend on that package. [00:38] So if you adjust pkgbinarymangler to use gcov, pkgbinarymangler must depend on gcov. [00:39] for the curious, an early sketch of this is in lp:~allanlesage/pkgbinarymangler/coverage-mangler [00:39] wgrant, this sounds just, let me experiment with [00:40] wgrant, also thanks--the 'pkgbinarymangler always installed' resolves a question as to how my modified version was pulled in === ndec is now known as ndec|vacations [12:06] hello, please take a look at https://answers.launchpad.net/launchpad/+question/253093 === cyphermox__ is now known as cyphermox [19:46] I'm finding that my dputs to PPA don't always arrive--some do, some don't http://pastebin.ubuntu.com/8056412 --am I making a versioning error here? or is there a permissions scheme? this is for https://launchpad.net/~allanlesage/+archive/ubuntu/coverage-mangler-12 [19:49] alesage: are you getting e-mails for them? [19:49] dobey good q let me investigate [19:50] dobey thanks, should've gone directly to that :/ [19:50] :) [19:51] dobey in this case I'm getting 'already exists in primary archive'--can you suggest a versioning scheme for me so that I a) don't break the world and b) can experiment at will? [19:52] been tacking on ~alesage0X but evidently I have to tick the rev as well [19:54] alesage: don't build the source package with -sa option to debuild [19:55] alesage: the error is about the orig.tar.gz right? [19:55] dobey, true [20:06] dobey, trying to grok which of the bzr bd options to use to accomplish this, any hints? [20:09] alesage: what are you running right now? [20:09] dobey, I'm in trusty [20:09] dobey sorry I'm just bzr bd -S 'ing [20:10] * alesage is having a case of the Fridays [20:11] alesage: hrmm, that shouldn't be including the orig.tar.gz in the upload then i don't think [20:11] alesage: what is the full error message from LP exactly? [20:11] dobey I'll paste one min [20:12] dobey http://paste.ubuntu.com/8056735/ [20:14] oh [20:15] oh? [20:16] yeah, oh, a lot of projects that are managed by ci train do versioning wrong [20:16] they have non-native versions, and act like they aren't native packges, but they really are [20:17] so you changed something in the source files directly in the tree [20:17] and it built a new orig.tar.gz with the same version, and is complaining about that [20:18] this makes sense although the only change I've made was to the changelog [20:18] (don't know if we consider that to be "part of the tree" as it's in the repository) [20:19] what branch did you build the source from? [20:20] dobey I'm just going to the lp: repos. . . . [20:21] dobey what's the correct source? [20:22] though if you really only changed debian/changelog and used the right branch, it doesn't make sense, as the orig.tar.gz should be the same that's in ubuntu already i would think [20:23] dobey this also makes sense [20:24] you used lp:platform-api ? [20:24] dobey yes [20:25] alesage: do you also have a .debian.tar.gz or .diff.gz that has the debian/ contents? or are those in the orig.tar.gz as well? [20:27] dobey I mean I start clean--let me produce a run [20:28] dobey http://pastebin.ubuntu.com/8057070/ [20:31] dobey going to ask the ci ppl as they must work around this all day