[Reproducible-builds] Bug#798826: DDPO: displays not-for-us in reproducible builds column for architectures excluded in the package

[Holger Levsen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150913/796095b5/attachment.sig>