[00:40] <mwhudson> cjwatson, wgrant: if the primary archive and the ppa have packages of the same version, packages in the ppa seem to get preferred
[00:40] <mwhudson> cjwatson, wgrant: is this done via apt preferences or, to state my real question, how do i reproduce this in a local schroot?
[00:48] <cjwatson> mwhudson: apt breaks ties by sources.list order
[00:48] <cjwatson> mwhudson: so just put the PPA first in sources.list
[00:53] <mwhudson> cjwatson: oh heh ok
[07:07] <tjaalton> hi, some bugs get spam from a few users. what to do with those?
[07:10] <tjaalton> id's j-a150678, pin8-h, giuse-obino
[07:27] <cpaelzer> hi LP build recipes try to puzzle me, maybe someone here can help
[07:27] <cpaelzer> recipe as in https://code.launchpad.net/~ubuntu-virt/+recipe/qemu-daily
[07:27] <cpaelzer> but I can perfectly recreate locally with rm -rf qemu-workdir/*; git-build-recipe --allow-fallback-to-native qemu-daily/qemu.recipe qemu-workdir
[07:27] <cpaelzer> what happens is this
[07:28] <cpaelzer> the "packaging" repo has fixes e.g. in d/control now libseccomp-dev (>= 2.2.0)
[07:28] <cpaelzer> that was 2.3 before
[07:28] <cpaelzer> also if I clone the packaging repo into a new dir I see that it fetches master with the "libseccomp-dev (>= 2.2.0)"
[07:29] <cpaelzer> but if running through git-build-recipe or on LP it always picks up old content from the packaging branch
[07:29] <cpaelzer> which leads to dependency killing the build as in https://launchpadlibrarian.net/326205008/buildlog_ubuntu-xenial-amd64.qemu_2%3A0~daily-201706300837-c5eb584~ubuntu16.04.1_BUILDING.txt.gz
[07:30] <cpaelzer> does anybody have an idea why/how the "old" content of debian/control could slip in here?
[08:12] <cpaelzer> I see git-build-recipe calling git -C qemu-workdir/qemu merge --commit -m Merge master ...
[08:12] <cpaelzer> and it is the right hash with the fixed content
[08:12] <cpaelzer> but the result eventually is still having the old one
[08:18] <geser> looks like something triggers the "debian/control" target in debian/rules to regenerate debian/control from debian/control-in and the later file still has the old dependency
[08:21] <geser> "echo '# autogenerated file, please edit debian/control-in' > debian/control.tmp" (from the buildlog for the source package)
[08:31] <geser> cpaelzer: ^^
[09:06] <cpaelzer> I fount it
[09:06] <cpaelzer> thanks geser
[09:07] <cpaelzer> the worst is I know that it is generated, but I happen to forget once every 3 months :-/
[09:17] <cpaelzer> hmm it seems currently all LP build recipies on artful fail for me with
[09:17] <cpaelzer> E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed.
[09:17] <cpaelzer> Reading package lists...
[09:17] <cpaelzer> E: You must put some 'source' URIs in your sources.list
[09:17] <cpaelzer> is that any sort of known current issue in artful?
[09:21] <cpaelzer> while the issue is at the recipe building, not the follow on build of the binary package - I'll ask in ubuntu-devel to get a wider audience if one has seen the issue in general
[09:23] <muktupavels> cpaelzer: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826
[09:23] <cpaelzer> thanks muktupavels - in ubunut-devel there is also some chat backlog to be found about it
[09:49] <cjwatson> wgrant: ^- could you review my MP for that, please?
[10:09] <wgrant> ugh what
[10:10] <wgrant> cjwatson: Remember that precise is still in ESM, though hopefully nobody's using git-buildrecipe with it.
[10:17] <cjwatson> wgrant: precise supports [trusted=yes]
[10:17] <cjwatson> I said that in my MP :)
[10:18] <wgrant> cjwatson: ... indeed.
[10:18] <wgrant> I misread that line as "trusty", I guess because it started with "trusted".