ppa-hooks

[12:03] <ev> infinity, cjwatson, pitti, others: do we have a means of extracting coverity data, code coverage, and test results inside packages built in a PPA (from dep8 tests)? Could we (ab)use binarypkgmangler for such a task?

[12:04] <ev> we’re trying to be good citizens of Launchpad in the new CI Airline architecture, but this is one area where we’ve seemingly needed pbuilder hooks

[12:59] <pitti> ev: not pkgbinarymangler, as that runs too late; AFAIK you need to change the ./configure/CFLAG arguments, don’t you?

[13:00] <pitti> ev: so it might be a modified dpkg which supplies these extra CFLAGS by default, or something like that

[13:01] <pitti> ev: I don’t know whether it’s just CFLAGS or whether the build system needs to support gcov/lcov in other ways; so far I’ve just used the gnome-common macros

[13:49] <ev> pitti: sorry, I’m not sure I follow. How can we provide a modified dpkg to a PPA? If you upload dpkg to a PPA does it automatically pick up and use that version (if so, very clever). Does pkgbinarymangler really run too late for extracting out the coverage, coverity, and test case artifacts?

[13:50] <cjwatson> It does

[13:50] <cjwatson> Since the PPA itself is in sources.list for any builds to that PPA, and the builder upgrades its chroot at the start of each build

[13:51] <cjwatson> pkgbinarymangler could certainly be hacked to extract artifacts, provided that something has arranged to generate them in the first place ...

[13:51] <cjwatson> (dpkg seems a bit low-level for this though, and that would be an utter pain to maintain)

[13:52] <cjwatson> You could divert dpkg-buildflags, as long as you only care about packages that use it (we could reasonably mandate that for things we own)

[13:52] <cjwatson> Most of our stuff probably uses it already by way of dh9

[13:57] <pitti> ev: right, I actually meant dpkg-buildflags (I thought that was in dpkg)

[14:00] <cjwatson> pitti: It’s in dpkg-dev, yes, but it would be quite a bit of ongoing cost to do that by uploading a modified dpkg - would have to keep merging

[14:00] <cjwatson> Should be easy enough to divert if that’s what’s needed - call the underlying one and tweak

[14:00] <pitti> right

[14:12] <ev> well the problem then becomes how do you make the package doing the diverting of dpkg-buildflags a requirement for all the packages in the PPA without explicitly asking for it in their control files

[14:12] <ev> at least as I see it

[14:15] <cjwatson> ev: That’s not a problem if it’s one of the things that’s already preinstalled in the chroot; pkgbinarymangler would qualify

[14:19] <ev> cjwatson: I thought while pkgbinarymangler was determined to be a good target for extracting the artifacts, it ran too late to divert dpkg-buildflags? Or did I misunderstand what you said above?

[14:25] <pitti> ev: it currently only diverts dpkg-deb, but it could additionally divert dpkg-buildflags

[14:29] <ev> pitti: ohh. So if I understand correctly: given a PPA that we want to extract gcov data from, we upload a fork of pkgbinarymangler that diverts dpkg-buildflags to include the gcov flags and also splits out the coverage data into a “-coverage” package?

[14:33] <pitti> ev: or upload that mangler to ubuntu, and make it check something in the PPA to see whether you want cov enabled

[14:36] <pitti> ev: of course the first tests should actually happen with a forked pacakge in a PPA, yes