Hi Guillem, Thanks for the report
On 24/05/26 at 21:17 +0200, Guillem Jover wrote: > Package: qa.debian.org > User: [email protected] > Usertags: udd > > Hi! > > I just noticed that there seems to be stale/bogus information for at > least the experimental release, for versions of packages that were > never uploaded to experimental. > > For example: > > ,--- > $ udd-query "SELECT sources.source, sources.version, sources.release \ > FROM sources \ > WHERE sources.source = 'golang-github-cheggaaa-pb.v3' \ > ORDER BY sources.version;" > source | version | release > ------------------------------+-----------------+-------------------- > golang-github-cheggaaa-pb.v3 | 3.1.0-1 | bookworm > golang-github-cheggaaa-pb.v3 | 3.1.5-1~bpo12+1 | bookworm-backports > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | experimental > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | forky > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | sid > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | trixie > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | trixie-backports > golang-github-cheggaaa-pb.v3 | 3.1.7-1 | sid > (8 rows) > $ rmadison golang-github-cheggaaa-pb.v3 > golang-github-cheggaaa-pb.v3 | 3.1.0-1 | oldstable | > source > golang-github-cheggaaa-pb.v3 | 3.1.5-1~bpo12+1 | oldstable-backports | > source > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | stable | > source > golang-github-cheggaaa-pb.v3 | 3.1.5-1 | testing | > source > golang-github-cheggaaa-pb.v3 | 3.1.7-1 | unstable | > source > $ udd-query "SELECT sources.source, sources.version, sources.release \ > FROM sources \ > WHERE sources.source = 'golang-github-go-openapi-jsonpointer' \ > ORDER BY sources.version;" > source | version | > release > > --------------------------------------+---------------------------------+-------------------- > golang-github-go-openapi-jsonpointer | 1:0.0~git20160704.0.46af16f-1.1 | > bullseye > golang-github-go-openapi-jsonpointer | 1:0.19.5-3 | > experimental > golang-github-go-openapi-jsonpointer | 1:0.19.5-4 | > bookworm > golang-github-go-openapi-jsonpointer | 1:0.19.5-4 | > bookworm-backports > golang-github-go-openapi-jsonpointer | 1:0.21.1-2 | > experimental > golang-github-go-openapi-jsonpointer | 1:0.21.1-2 | > forky > golang-github-go-openapi-jsonpointer | 1:0.21.1-2 | > sid > golang-github-go-openapi-jsonpointer | 1:0.21.1-2 | > trixie > golang-github-go-openapi-jsonpointer | 1:0.23.1-1 | > forky > golang-github-go-openapi-jsonpointer | 1:0.23.1-1 | > sid > (10 rows) > $ golang-github-go-openapi-jsonpointer | 1:0.0~git20160704.0.46af16f-1.1 | > oldoldstable | source > golang-github-go-openapi-jsonpointer | 1:0.19.5-4 | > oldstable | source > golang-github-go-openapi-jsonpointer | 1:0.21.1-2 | > stable | source > golang-github-go-openapi-jsonpointer | 1:0.23.1-1 | > testing | source > golang-github-go-openapi-jsonpointer | 1:0.23.1-1 | > unstable | source > `--- > > This seems to be having an effect on lintian reports for example, and > I suspect also for DDPO CI passing results being reported as failing > due to vcswatch information for these ghost experimental entries (?). Those have extra_source_only=true (they are included in the experimental Sources file only because they have been used to build other packages in experimental). That raises the question on how to deal with those packages: (1) in the various checkers; (2) in dashboards that display QA checkers results. When they are checked by QA checkers, it might not be trivial to exclude them from dashboards. As a result, dashboards currently mostly choose to include them in results, which is confusing. The current status is that most checkers include checking those packages, and that most dashboards fail to exclude test results for those packages. I don't know what is the best path foward: A) stop checking those packages? B) continue checking those packages, but fix dashboards so that they don't include results for those? I'm inclined to think that B) is the correct path: dashboards make simplifications anyway (for example, displaying the results only for unstable when a source is both in unstable and experimental). Also the additional results could be useful (for a example, we could be interested in making sure that a release does not include packages built with a known-lintian-broken source). Lucas
