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 (?).

Thanks,
Guillem

Hi Guillem,

Thanks for the report
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