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
Description: This is a digitally signed message part.
_______________________________________________ Reproducible-builds mailing list Reproduciblefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds