Hi Andreas
Good point on anonscm as well... that really does blow out the numbers.
However... some of them still work via the aliasing mechanism that was
introduced at the time of migration to salsa. Duck used to check them
all but I don't think it is running any more, unfortunately. vcswatch
still does, more on that later.
The vast majority of these packages have seen post-alioth uploads but with
the broken Vcs fields still in place.
Do you have numbers backing up this "vast majority" statement?
Yes, that's in the table below. Of those 161 packages, 145 have been
uploaded since salsa launched and alioth stopped. (updated data with
anonscm at the bottom - the story is still the same, although not all
those anonscm links are broken)
year | count
-----+-------
2011 | 1
2012 | 4
2013 | 3
2014 | 4
2015 | 1
2016 | 1
2017 | 2
2018 | 2 (salsa.d.o general availability)
2019 | 1
2020 | 13
2021 | 95
2022 | 20
2023 | 7
2024 | 6
2025 | 1
[...]
(I accidentally found 2 python-team packages without Vcs URLs yesterday -
the repos were on salsa, just not listed in d/control)
Not so nice. Did you just injected these? If not would you mind naming
the packages?
One got uploaded because I was sorting other changes for qtpy, the other
is fixed in git. Having looked at 20-something packages in the last 2
days, I'm not sure I could actually name which ones at this stage...
In pursuing this, you might also find the vcswatch table in udd - it
lists 1533 packages where the VCS fields might need fixing. Some of the
errors there are transient, but this also picks up typos in the VCS
fields ('debain', 'debian/packages/') and repos that simply don't exist.
Updated queries and data appended. (and btw postgres can do regex
matches which simplifies the sql quite a lot)
regards
Stuart
Majority of packages with invalid vcs_url uploaded post salsa:
SELECT
DATE_PART('year', date) AS year,
COUNT(*)
FROM
sources AS s
JOIN upload_history AS h
ON s.source = h.source AND s.version = h.version
WHERE
release = 'sid'
AND vcs_url ~ '/(git|svn|alioth|anonscm).debian.org'
GROUP BY
year
ORDER BY
year ASC;
year | count
-----+-------
2011 | 2
2012 | 5
2013 | 7
2014 | 9
2015 | 9
2016 | 20
2017 | 102
2018 | 85 ← (salsa.d.o general availability)
2019 | 10
2020 | 77
2021 | 411
2022 | 115
2023 | 13
2024 | 31
2025 | 3
(15 rows)
Teams with packages to fix - and the packages are probably already on
salsa so this is just metadata, not lots of work.
SELECT
maintainer_name, COUNT(*)
FROM sources
WHERE
release = 'sid'
AND vcs_url ~ '/(git|svn|alioth|anonscm).debian.org'
AND maintainer ~ '(team|group|lists)'
GROUP BY
maintainer_name
ORDER BY
count DESC;
maintainer_name | count
---------------------------------+-------
Debian Ruby Extras Maintainers | 196 (+2 that are in Uploaders)
Debian Java Maintainers | 178
Debian Go Packaging Team | 105
Debian Perl Group | 83
pkg-go | 25
Debian Javascript Maintainers | 20
Debian Fonts Task Force | 15
Debian PHP PEAR Maintainers | 14
Debian X Strike Force | 12
Debian Science Maintainers | 11
Debian XML/SGML Group | 5
Debichem Team | 4
Debian VDR Team | 4
Debian CLI Applications Team | 2
Debian Games Team | 2
Debian Java maintainers | 2
Debian Tasktools Packaging Team | 2
Debian VoIP Team | 2
Debian Astronomy Maintainers | 2
Debian Privacy Tools Maintainers | 2
Debian Clojure Maintainers | 2
Debian Astronomy Team | 2
Debian Telepathy maintainers | 2
Live Systems Maintainers | 1
The Debian Lua Team | 1
Pulseaudio maintenance team | 1
Android Tools Maintainers | 1
Debian PhotoTools Maintainers | 1
Puppet Package Maintainers | 1
ClamAV Team | 1
Debian-IN Team | 1
Debian CLI Libraries Team | 1
Debian Islamic Maintainers | 1
Debian GNOME Maintainers | 1
Debian Science Team | 1
Debian Sugar Team | 1
Debian GNUKhata Team | 1
Debian Emacs addons team | 1
Debian Med Packaging Team | 1
Debian Salt Team | 1
NeuroDebian Team | 1
Find packages in your favourite team that you want to work on...
SELECT
source, vcs_url
FROM sources
WHERE
release = 'sid'
AND vcs_url ~ '/(git|svn|alioth|anonscm).debian.org'
AND maintainer ~ 'science'
ORDER BY
source;
The vcswatch table has lots of interesting things... Note that the salsa
error "could not read Username" in the table is not a misconfiguration -
it means that the repo couldn't be obtained anonymously, which could be
that it doesn't exist, or that it needs permissions - both are wrong for
Debian.
SELECT
source, url, error
FROM
vcswatch
WHERE
error IS NOT NULL
ORDER BY
source;
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
