[Reproducible-builds] Applying to Outreachy to work on Reproducible Builds

[spectranaut at riseup.net]

On 2016-03-29 23:01, Holger Levsen wrote:
> 
> I think an awesome initial contribution would also be to set up such a
> local test setup *and document the needed steps*. (First in the wiki is 
> fine,
> but this should really go into INSTALL or CONTRIBUTE in
> jenkins.d.n.git.)

Haha, definately! I'm keeping track of everything I've had to do.
> 
>>   (3) enhance bin/reproducible_json.py to create include an arch 
>> agnostic
>>     summary. currently the json will have results for amd64 and armhf, 
>> but
>>   its not clear which is authorative. the result should be: if it 
>> fails in
>>   some suite/arch combination, the result should be failure.
>> 
>> I'm pretty sure that I can do this quickly enough :) I've run the 
>> script on
>> reproducible.db and it looks like we only need to do a little extra 
>> data
>> munging. But I'm confused about the goal:
>> - Do we want an additional json file to be published, with information 
>> about
>> whether the package succeeds across all architectures? Who is going to 
>> do
>> anything with that file?
> 
> one of the json files (we have two) is used by eg tracker.debian.org as 
> well as
> ddpo.debian.org and probably others. the other is to be used by
> individuals who prefer to parse json over downloading the sqllite db 
> and
> use that.
> 
> that seperation has historically been created and is maybe not the 
> best.
> 
>> - Or do we want to write an "arch agnositic" summary to 
>> reproducible.json
>> instead? Should the "architecture" key be blank or non-existant? (I 
>> haven't
>> looked into to whatever is using this file)
> 
> that.
> 
> there should be an arch agnostic summary plus specific information for
> each arch.
> 
> we do have two json files though: reproducible.json has all the
> information about all suites, while reproducible-tracker.json only has
> data for unstable. *Probably* the arch-summary should only be given for 
> the
> rb-tracker.json, maybe only the arch-summary?
> 
> rb-tracker.json should also exclude the "not-for-us" status as this is 
> a
> deficiancy in our test setup and should not be displayed on trackers.
> 
> OTOH, if it fails somewhere, it should be displayed on trackers even
> if's that package is nicely reproducible somewhere else. (Though for
> trackers we just care about unstable & maybe experimental.)
> 
> We got consumers for the json data faster than we could create a
> coherent design :/ :)
> 

Hurray! I started coding (when trapped without Internet earlier), now 
for confirmation:

All possible status (Holger you mentioned "not for us" over irc, but 
that results with that status are already excluded, along with 
"blacklisted" and "404"):
['FTBFS', 'depwait', 'reproducible', 'unreproducible']

Tables of the result status, across (all two) architectures:
arch1  | reproducible | reproducible   | ftbfs | depwait       | depwait 
    |
arch2  | reproducible | unreproducible | *     | repro/unrepro | depwait 
    |
status | reproducible | unreproducible | ftbfs | repro/unrepro | depwait 
?? |

Questions:
- see ?? above -- I assume I copy over "depwait" here?

About the JSON format!
Old format:
     {
         "architecture": "armhf",
         "build_date": "2016-02-06 22:26",
         "package": "zzzeeksphinx",
         "status": "reproducible",
         "suite": "unstable",
         "version": "1.0.17-1"
     },
     {
         "architecture": "amd64",
         "build_date": "2016-03-19 23:35",
         "package": "zzzeeksphinx",
         "status": "reproducible",
         "suite": "unstable",
         "version": "1.0.17-1"
     },

New proposed format:
     {
         "architecture": "armhf",
         "build_date": "2016-02-06 22:26",
         "package": "zzzeeksphinx",
         "status": "reproducible",
         "suite": "unstable",
         "version": "1.0.17-1"
         "architecture_status": [
             {
                 "architecture": "armhf",
                 "build_date": "2016-02-06 22:26",
                 "status": "reproducible"
             },
             {
                 "architecture": "amd64",
                 "build_date": "2016-03-19 23:35",
                 "status": "reproducible"
             },
         ]
     }

Or, should I drop the architecture_status in the "new proposed format" 
altogether? Will no one need it?

yay!
Valerie