Hi Sebastian,
On Sonntag, 13. September 2015, Mattia Rizzolo wrote:
> On Sun, Sep 13, 2015 at 12:44:12PM +0200, Sebastian Ramacher wrote:
> > On my DDPO page intel-vaapi-driver is displayed as not-for-us in the
> > reproducible build column which is caused by r.d.n reporting
> > intel-vaapi-driver as not-for-us on armhf. This is expected since
> > intel-vaapi-driver restricts its Architecture field to i386, amd64,
> > kfreebsd-i386 and kfreebsd-amd64. So please ignore results for
> > architectures that are explicitely excluded in the package.
Thanks for bringing this case to our attention. The addition of another arch
to rb.d.n is quite new and there are still some bugs we need to weed out.
That said, I'm not sure how differences in test results between are to be
presented to consumers like DDPO or the tracker. In general I think the
problematic result should "win" (the package is unreproducible on armhf and
reproducible on amd65 -> it should be displayed as unreproducible, idealy with
the extra remark "on armhf"). I'm not sure this is the case already.
src:u-boot is a good candidate to check on this, as we know its reproducible
on amd64 atm and unreproducible on armhf…
That said, I think 404 and not-for-us should be ignored when preparing the
json output and I've just pushed this changed, which should be visible
tomorrow.
> There is a bug somewhere i can't find anymore about using another data
> source, so we can keep reproducible.json full with real data, while
> using a different .json to feed stuff like ddpo. I believe that's the
> wrong approach.
the bugs is #785531 and as you can read, I first thought it was wrong too, but
got convinced otherwise.
And as this bug is done, we already produce two json files: reproducible.json
and reproducible-tracker.json
> We provide data and consumers needs to be aware on how to use it.
Yes. But we define how it's to be used, so we should present a data source
with such definitions. Else we would need to tell consumers to change their
code each time we change the way we look at the data. This is why we have
reproducible-tracker.json already.
> In particular I believe the followings:
> * not-for-us needs to be filtered by the DDPO: there is no point in
>throwing them at the user
I don't think we should present results solely based on how well our
architecture coverage is. This is nothing package maintainers are interested
in.
> * needs support for multiple architecture (it's very new: less than a
>month)
yeah
> * maybe care only about unstable: if a version in unstable is repr.
>while the lower version in testing is not, then there is no need to
>notify the user
/reproducible-tracker.json already only includes data about unstable, for this
very reason.
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
