ppa-hooks ========= [12:03] 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] 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] ev: not pkgbinarymangler, as that runs too late; AFAIK you need to change the ./configure/CFLAG arguments, don't you? [13:00] ev: so it might be a modified dpkg which supplies these extra CFLAGS by default, or something like that [13:01] 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] 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] It does [13:50] 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] pkgbinarymangler could certainly be hacked to extract artifacts, provided that something has arranged to generate them in the first place ... [13:51] (dpkg seems a bit low-level for this though, and that would be an utter pain to maintain) [13:52] 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] Most of our stuff probably uses it already by way of dh9 [13:57] ev: right, I actually meant dpkg-buildflags (I thought that was in dpkg) [14:00] 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] Should be easy enough to divert if that's what's needed - call the underlying one and tweak [14:00] right [14:12] 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] at least as I see it [14:15] 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] 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] ev: it currently only diverts dpkg-deb, but it could additionally divert dpkg-buildflags [14:29] 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] ev: or upload that mangler to ubuntu, and make it check something in the PPA to see whether you want cov enabled [14:36] ev: of course the first tests should actually happen with a forked pacakge in a PPA, yes