Bug#836156: improper handling of source+binary changes triggering binary builds

[Stephan Sürken]

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

[Sam Hartman]

> "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

[Sam Hartman]

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.