Re: Machine readable interface for crossqa.d.n

[Helmut Grohne <helmut@subdivi.de>]

Hi Johannes,

On Thu, Sep 08, 2022 at 01:44:41PM +0200, Johannes Schauer Marin Rodrigues wrote:
> {
>   "format": 1,
>   "name": "srcpkgname",
>   "bugs": [ 123456 ],

We actually have more data here. For each bug, I store whether it is a
ftbfs (native), cross-satisfiability or ftcbfs bug. Do you see a good
way to include that?

Also does it make sense to include bugs at all? All I'm doing is pulling
them from udd. Wouldn't you want to pull them from udd directly?

>   "sat": {
>     "version": "1.2.3",

Actually, there is not always a single version. If we are in the middle
of a depcheck, there can be multiple versions. How bad would it be to
move it into the actual results per architecture combination?

>     "results": {
>       "amd64": {
>         "mipsel": "conflict libc6-dev-mipsel-cross",
>         "arm64": "ok"

Wouldn't you want the categorization into "good" vs "temporary problem"
(e.g. multiarch skew) vs "permanent problem" somehow?

>       }
>     }
>   }
>   "builds": [
>     {
>       "timestamp": 1234567,

Is that seconds since epoch?

>       "version": "1.2.3",
>       "buildarch": "amd64",
>       "hostarch": "mipsel",
>       "state": "failed"
>     },
>   ]
> }
> 
> If a link to the buildlog is desired, then that can be generated from the
> source package name, the version, the host architecture and the timestamp.

Please don't reconstruct the log filename in a mechanical way. Due to
directory limits I will have to change the layout and filenames will
probably change. I'd prefer to include them in the machine readable
thingy.

Other than these remarks, this seems implementable. How about putting it
at <service>/src/<package>/status.json?

I kinda fear people performing 64000 requests (all packages times 4
dinstalls) per day though. Should we maybe push the data into udd
instead?

Helmut