Bug#836156: improper handling of source+binary changes triggering binary builds
Hi Sam, On Di, 2016-09-06 at 08:27 -0400, Sam Hartman wrote: (...) > I don't know. We normally do source only uploads. > Actually, it may be arch all handling. The package in question only > produced an arch all binary. > So, the most direct thing to test would be a binary+source upload of > a > package producing only an arch all deb. sorry for the delay. I did debug this today, and I can reproduce it. What I think is happening: * Binary+source upload is happening. * Build requests are uploaded to the builders (including debs). * sbuild is triggered. Now, sbuild (newly?) fails to overwrite (existing) debs in the builddir for some reason (and will also state so in the build log via an error log), but otherwise happily continues as "successful" build. mini-buildd now (also very happy) mixes the new changes with the old (not overwritten) deb in the build result. The first thing were this crashes is when trying to install the binary via the wrong changes file into the repository via reprepro. This usually leads to only the source package being installed, and misleading errors. It's maybe noteworthy that reproducible builds (i.e., current builds for sid) often masquerade this bug as the resulting debs may actually be identical ;). I am now going towards not adding any *.deb-Files to the build requests in the first place, which (is some improvement in its own) and should fix the issue, no matter how sbuild actually behaves. So this should hopefully be fixed with the next upload. Thx for spotting this! S
Bug#836156: improper handling of source+binary changes triggering binary builds
> "Stephan" == Stephan Sürken writes: Stephan> Hi Sam, Stephan> On Di, 2016-08-30 at 21:27 -0400, Sam Hartman wrote: >> package: mini-buildd version: 1.0.12 severity: normal >> >> reprepro 4.17.1-1 Stephan> fwiw, I am assuming yor mini-buildd instance runs on an Stephan> (older) sid (or is it jessie+backports?). Older stretch. Stephan> There are currently a bunch of (other) problems on current Stephan> sid I am trying to work out. Noticed that and decided now would not be the time to upgrade:-) >> As an aside, this is coming from a trusted builder and a trusted >> chroot; it would be really convenient if there were a way to >> convince mini-buildd to accept binaries signed by a particular >> key along with sources. Stephan> Ok, sounds reasonable. Maybe you could add a wishlist bug Stephan> for this? Will do. >> What actually happens is far more annoying. Stephan> (...) >> I find that the size, sha-1 and md5 of the .deb are not what is >> expected. Stephan> That sounds strange - I don't recall such an behaviour Stephan> (afaiu it). Will retest binary uploads in my current stint Stephan> ;). Stephan> On your mini-buildd instance, is this limited to one Stephan> special package or a general problem? I don't know. We normally do source only uploads. Actually, it may be arch all handling. The package in question only produced an arch all binary. So, the most direct thing to test would be a binary+source upload of a package producing only an arch all deb.
Bug#836156: improper handling of source+binary changes triggering binary builds
package: mini-buildd version: 1.0.12 severity: normal reprepro 4.17.1-1 The CI on our source control runs sbuild -d sid-hadron-snapshot --arch-all --source . Producing a changes file that includes binaries and sources. If that succeeds in passing some tests, we upload to mini-buildd. I expected it to throw away the binaries and run its own build. As an aside, this is coming from a trusted builder and a trusted chroot; it would be really convenient if there were a way to convince mini-buildd to accept binaries signed by a particular key along with sources. What actually happens is far more annoying. What I know for sure is that if I do a source upload not including the binaries the sources get installed into the repo, but the binaries never do. I tried to debug it. reprepro include is failing, but I don't seem to get the output from reprepro itself in daemon.log. When I unpack the buildresult by hand and run the same reprepro include command, I find that the size, sha-1 and md5 of the .deb are not what is expected. My guess is that the older deb from the initial .changes is getting left in incoming or somewhere where reprepro finds it and because of the rebuild it doesn't match what is expected.