[00:40] 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] 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] mwhudson: apt breaks ties by sources.list order [00:48] mwhudson: so just put the PPA first in sources.list [00:53] cjwatson: oh heh ok [07:07] hi, some bugs get spam from a few users. what to do with those? [07:10] id's j-a150678, pin8-h, giuse-obino [07:27] hi LP build recipes try to puzzle me, maybe someone here can help [07:27] recipe as in https://code.launchpad.net/~ubuntu-virt/+recipe/qemu-daily [07:27] 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] what happens is this [07:28] the "packaging" repo has fixes e.g. in d/control now libseccomp-dev (>= 2.2.0) [07:28] that was 2.3 before [07:28] 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] but if running through git-build-recipe or on LP it always picks up old content from the packaging branch [07:29] 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] does anybody have an idea why/how the "old" content of debian/control could slip in here? [08:12] I see git-build-recipe calling git -C qemu-workdir/qemu merge --commit -m Merge master ... [08:12] and it is the right hash with the fixed content [08:12] but the result eventually is still having the old one [08:18] 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] "echo '# autogenerated file, please edit debian/control-in' > debian/control.tmp" (from the buildlog for the source package) === chihchun_afk is now known as chihchun [08:31] cpaelzer: ^^ [09:06] I fount it [09:06] thanks geser [09:07] the worst is I know that it is generated, but I happen to forget once every 3 months :-/ [09:17] hmm it seems currently all LP build recipies on artful fail for me with [09:17] E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. [09:17] Reading package lists... [09:17] E: You must put some 'source' URIs in your sources.list [09:17] is that any sort of known current issue in artful? [09:21] 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] cpaelzer: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826 [09:23] Ubuntu bug 1701826 in launchpad-buildd "APT 1.5: E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. " [Critical,In progress] [09:23] thanks muktupavels - in ubunut-devel there is also some chat backlog to be found about it [09:49] wgrant: ^- could you review my MP for that, please? [10:09] ugh what [10:10] cjwatson: Remember that precise is still in ESM, though hopefully nobody's using git-buildrecipe with it. [10:17] wgrant: precise supports [trusted=yes] [10:17] I said that in my MP :) [10:18] cjwatson: ... indeed. [10:18] I misread that line as "trusty", I guess because it started with "trusted". === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === pbek_ is now known as pbek