Hi,
I now have code that fixes the issues raised in this bug. It certainly still
has some rough edges but the functionality is implemented. You can find the
code in my top commits to this repository:
https://salsa.debian.org/josch/dose
Amongst the nine top commits, six fix some drive-by issues. Feel free to cherry
pick. The other three are address the main issues of this bugreport.
Quoting Johannes Schauer (2015-07-16 12:38:02)
> it would be useful to show information about unsatisfiability of binary
> and source packages in DMD and the tracker. For that, qa.d.o/dose should
> export machine readable data of the latest runs of distcheck and
> buildcheck. I guess that the dose yaml format would be sufficient for
> this.
Turns out, that internally, the script is using a line-based plain text format
as a caching mechanism. The data in these cache files contains precisely the
information that would be needed by the distro tracker, so I added a commit
that exposes these internal cache files to the public alongside the HTML.
> It would also be interesting if DMD and the tracker could link back to
> the right page on qa.d.o/dose. For that purpose it would be useful to
> have stable urls for a given source package which would then redirect to
> the page of that source package with the latest timestamp.
After generating the pages, a symlink called "latest" is created alongside the
timestamp directories which links to the latest timestamp. The distro-tracker
probably is only interested in the latest run, so it can now just query:
https://qa.debian.org/dose/debcheck/unstable_main/latest/some.txt
Instead of (at the time of writing this):
https://qa.debian.org/dose/debcheck/unstable_main/1534050004/some.txt
The txt file is not served yet. It's the internal cache that I exposed in the
other commit.
Quoting Johannes Schauer (2015-07-31 11:20:55)
> sadly I'll not be able to attend all of debconf so let me add another note to
> consider here:
>
> Maybe in the future, qa.debian.org/dose could also generate some crossbuild
> dependency satisfaction results for some common architecture combinations like
> buildarch=amd64 and hostarch={armhf,arm64,mipsel}. In terms of dose3 invocation
> that would just be a matter of adding --deb-host-arch as another argument and
> the existing way of turning dose3 yaml output into HTML can probably entirely
> be kept.
>
> So if it is not too crazy of an idea that qa.debian.org/dose could also
> regularly generate crossbuild dependency satisfaction results, then please take
> this future possibility into account when thinking about how to export the data
> currently generated by qa.debian.org/dose in a machine readable format, so that
> later adding of crossbuild results does not break things.
The third commit adds this. It adds a new scenario type called "cross" which
will run dose-builddebcheck with the build architecture amd64 and all the host
architectures that the software is otherwise testing. Theoretically, we could
also test cross-build satisfiability with other build architectures but in
practice only amd64 is used, so lets start with this restriction.
The results are generated correctly but there are a few cosmetic issues left:
- the packages in the explanation table need architecture annotations or
otherwise it's confusing to see perl-base conflict with perl-base
- amd64 should be excluded as the host architecture, because that would just
be native compilation
- the codebase somehow has to force the existence of the amd64 architecture
I propose that we start with implementing the first two features (serve results
in a machine readable format and stable url of latest results) and adding them
to the tracker. Once this is all working, lets polish the third commit and also
add cross-build satisfiability information.
Thoughts?
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature