broken DDPO by not-so-broken reproducible-tracker.json

[Mattia Rizzolo]

Last night we held a short meeting, where one of the item in agenda was
reproducible-tracker.json¹ and how a recentish commit to jenkins² broke
one of its consumers, namely DDPO; after a bit of a discussion³ I
oh-so-happily volunteered⁴ to bring the issue in ML.

One of the purpose of reproducible-tracker.json is to export only data
that we (reproducible builds team) believes should be of interest to the
maintainers, and thus reflected in DDPO and distro-tracker; for example
we filter out blacklisted not-for-us 404 packages, packages tagged with
issues known to be due to our infrastructure, and show only one entry
per package containing the most interesting data across the tested
architectures.

That json used to contain only data about unstable; after this change it
only contains data about testing.

The shortcomings of this change: DDPO broke (no data is shown at all),
and the change of a maintainer fix is only displayed after testing
migration, which could take a while, and everybody hates waiting.

Possible actions from here (numbered only for easier referencing,
otherwise casual ordered):

1. just revert the change and let maintainer live with that
2. revert to unstable, but filter out packages tagged
   captures_build_path and friends (DDPO/tracker will just show no data
   about those packages)
3. revert to unstable, but pseudocreate a pseudostate where packages
   tagged with those issues as point 2 will move on (i.e., instead of
   being state "unreproducible" will be "buildpathfuckup" or some such
   (note: this would be a pure invention, only the json export would
   contain such data, as I don't really want to mess with the internal
   data just to hide the fact that the package is plain unreproducible)
4. figure out why the hell DDPO doesn't deal with that edit in the json,
   see the code⁵ in Debian's QA Team SVN repo, and leave the json to
   display testing data as it is now

Anything else?


Personally I'd vote 1243 (with the gotcha that figuring out why DDPO
cares so much and fixing it would still be nice).


¹ https://tests.reproducible-builds.org/debian/reproducible-tracker.json
² https://anonscm.debian.org/git/qa/jenkins.debian.net.git/commit/?id=0dcfe01d8d742f51d49c071c56b1d0efe0d9a1f3
³ http://meetbot.debian.net/reproducible-builds/2016/reproducible-builds.2016-10-17-19.01.log.html#l-132
⁴ http://meetbot.debian.net/reproducible-builds/2016/reproducible-builds.2016-10-17-19.01.log.html#l-178
⁵ https://anonscm.debian.org/viewvc/qa/trunk/data/cronjobs/ddpo.reproducible?view=markup
  https://anonscm.debian.org/viewvc/qa/trunk/data/ddpo/extract_reproducible.pl?view=markup

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161018/94bd791d/attachment.sig>