Hi,

this is a regression introduced between August 8 2018 and today, August
2018. I haven't done anything on the system running mini-buildd aside of
keeping sid current.

After successful build, inclusion into the archive fails:

Aug 20 13:16:03 spinturn [packager           ] INFO    : Called with retval 0: reprepro --verbose --waitforlock 10 --basedir /var/lib/mini-buildd/repositories/zg copysrc stretch-zg-unstable-rollback0 stretch-zg-unstable mutt  [mini_buildd.call:72]
Aug 20 13:16:03 spinturn [packager           ] INFO    : Called with retval 255: reprepro --verbose --waitforlock 10 --basedir /var/lib/mini-buildd/repositories/zg includedsc stretch-zg-unstable /var/lib/mini-buildd/incoming/mutt_1.10.1-2~zg90+1.dsc  [mini_buildd.call:72]
Aug 20 13:16:03 spinturn [packager           ] WARNING : ? reprepro.. (stderr): Could not check validity of signature with '3F9BF396B3AEB4D1A0D4772BC2246E7BE5BCB129' in '/var/lib/mini-buildd/incoming/mutt_1.10.1-2~zg90+1.dsc' as public key missing! [mini_buildd.call:116]
Aug 20 13:16:03 spinturn [packager           ] WARNING : ? reprepro.. (stderr): No section and no priority for 'mutt', skipping. [mini_buildd.call:116]
Aug 20 13:16:03 spinturn [packager           ] WARNING : ? reprepro.. (stderr): There have been errors! [mini_buildd.call:116]
Aug 20 13:16:04 spinturn [packager           ] INFO    : Moving changes to package log: '/var/lib/mini-buildd/incoming/mutt_1.10.1-2~zg90+1_mini-buildd-buildresult_amd64.changes'->'/var/lib/mini-buildd/var/log/zg/_failed/mutt/1.10.1-2~zg90+1/amd64' [mini_buildd.changes:438]
Aug 20 13:16:04 spinturn [packager           ] INFO    : Moving 'mutt_1.10.1-2~zg90+1_mini-buildd-buildresult_amd64.changes' to '/var/lib/mini-buildd/var/log/zg/_failed/mutt/1.10.1-2~zg90+1/amd64' [mini_buildd.changes:445]

I guess that it's the "public key missing" part the makes reprepro
unhappy. I don't have those messages in the log from older build
processes, as:

Aug  8 21:05:24 spinturn [packager           ] INFO    : Called with retval 0: reprepro --verbose --waitforlock 10 --basedir /var/lib/mini-buildd/repositories/zg includedsc stretch-zg-unstable /var/lib/mini-buildd/var/tmp/tmpcQ00eK/aide_0.16-3.2~zg90+2.dsc  [mini_buildd.call:72]
Aug  8 21:05:24 spinturn [packager           ] INFO    : Called with retval 0: reprepro --verbose --waitforlock 10 --basedir /var/lib/mini-buildd/repositories/zg include stretch-zg-unstable /var/lib/mini-buildd/var/tmp/tmp52TKO_/aide_0.16-3.2~zg90+2_amd64.changes  [mini_buildd.call:72]

Please note that the reject happens _after_ the package was accepted for
building _and_ successfully built. The signature was actually intended
to be made with 3F9BF396B3AEB4D1A0D4772BC2246E7BE5BCB129, that key is a
valid uploader for the mini-buildd instance.

This is a crippling bug.

Greetings
Marc

severity #906747 normal
thanks

I now think that this is actually a reprepro issue, and it only applies
to the mutt package. Trying to poke a locally built mutt package into
the archive bypassing mini-buildd yielded the same error, and I had to
manually specify section and priority on the reprepro command line to
get the package into the archive.

Otoh, I cannot see any difference between mutt and, for example,
ser2net, a package that runs through mini-buildd just fine even if both
.dsc files don't contain explicit Section and Priority lines, but have
Section and Priority only listed in a "Package-List" stanza.

My beef against mini-buildd is therefore reduced to the fact that it
once more hides the actual error message in the logs, and that I
cannot access the built packages for manual testing since they're killed
off as soon as the error happens.

Greetings
Marc

(...)

fwiw: This went to control@ only, pasting here again for convenience/explanation:

retitle 906747 Please keep build data (even if installation finally fails)
fixed 906747 2.0.0
thanks

Since 2.0.0, all build data is kept in a resp. builds directory (including potentially built
binary packages), and can be downloaded via HTTP.

Builds data expires after 5 days (or, for 2.2.x, by default after 5 days).

For expert debugging, m-b-debug-build may be used to help analyze faild builds (while the
build data is still there).

Hth,

S