--=-=-=
Content-Type: text/plain

Hi,

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up,
including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

Ansgar

--=-=-=
Content-Type: text/plain
Content-Disposition: inline; filename=trash-experimental.txt Content-Description: Removal candidates for experimental

projectb=> select s.source, s.created from source s
where exists (
select 1 from src_associations sa
where s.id = sa.source and
sa.suite = (select id from suite where suite_name = 'experimental')
)
and s.created < '2020-01-01' order by source;
source | created -----------------------------------+-------------------------------
android-platform-external-doclava | 2019-07-24 21:08:04.691192+00
critterding | 2014-11-03 01:19:08.643578+00
darkice | 2019-03-24 11:18:56.087124+00
dtc | 2012-06-08 09:17:11.189323+00
go-cpe-dictionary | 2018-12-26 05:34:06.439036+00
golang-github-golang-geo | 2017-03-09 15:19:27.388525+00
golang-golang-x-debug | 2017-03-23 09:03:43.615567+00
gv | 2019-03-09 20:41:24.058607+00
imip-agent | 2019-01-06 13:34:33.740546+00
libewf | 2018-12-28 20:47:47.223343+00
librep | 2018-08-25 05:34:08.814689+00
libtaverna2-server-java | 2013-11-24 21:20:33.311726+00
libvirt-tck | 2011-11-13 15:07:12.072289+00
m2m-aligner | 2016-04-12 10:38:28.348764+00
markdown | 2019-12-28 20:57:03.304098+00
mediagoblin | 2017-08-28 13:19:49.32023+00
mitlm | 2016-04-24 16:23:21.734803+00
monkeysphere | 2019-05-19 23:33:52.925219+00
musescore-snapshot | 2019-07-05 00:19:11.735843+00
node-solid-jose | 2019-09-27 10:05:56.642068+00
node-trust-jwa | 2019-02-04 04:36:38.354632+00
nvidia-texture-tools | 2016-05-18 10:32:37.829021+00
openhft-chronicle-bytes | 2018-09-14 06:04:31.457889+00
openhft-chronicle-network | 2018-09-17 03:51:04.998927+00
openhft-chronicle-threads | 2018-09-15 20:35:37.601005+00
openhft-chronicle-wire | 2018-09-16 17:50:13.421894+00
partman-swapfile | 2019-03-12 04:54:30.304068+00
phonetisaurus | 2016-05-05 16:29:26.102649+00
php-sabre-event | 2015-11-06 01:20:46.165676+00
php-sabre-vobject | 2016-04-07 01:48:57.375779+00
pluto-sat-code | 2018-03-01 22:06:10.485772+00
poti | 2013-01-14 14:47:46.613882+00
quasselc | 2017-01-14 21:36:32.548429+00
ruby-devise-i18n | 2019-06-03 15:34:25.854689+00
ruby-nmatrix | 2016-03-03 15:26:31.250004+00
sawfish | 2019-07-19 15:35:40.94432+00
subethasmtp | 2017-12-21 12:43:37.751214+00
sump-logicanalyzer | 2011-07-27 07:17:07.488676+00
tcltk-defaults | 2019-02-24 20:54:53.737672+00
tinysvm | 2013-02-16 13:48:04.758297+00
urjtag | 2016-12-14 21:36:28.988139+00
vuls | 2019-06-18 23:16:21.087982+00
yamcha | 2017-09-25 21:34:17.955363+00
yorick-optimpack | 2017-01-08 07:03:14.977687+00
(44 rows)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline; filename=trash-experimental-dd-list.txt Content-Transfer-Encoding: quoted-printable
Content-Description: Removal candidates for experimental (dd-list)

Andrea Pappacoda <andrea@pappacoda.it>
markdown

Andreas Tille <tille@debian.org>
critterding (U)

Android Tools Maintainers <android-tools-devel@lists.alioth.debian.org>
android-platform-external-doclava

Antoine Beaupré <anarcat@debian.org>
monkeysphere (U)

Bernhard R. Link <brlink@debian.org>
gv

Christopher Hoskin <mans0954@debian.org>
subethasmtp

Cédric Boutillier <boutil@debian.org>
ruby-nmatrix (U)

Daniel Kahn Gillmor <dkg@fifthhorseman.net>
monkeysphere (U)

David Prévot <taffit@debian.org>
php-sabre-event (U)
php-sabre-vobject (U)

Debian Go Packaging Team <pkg-go-maintainers@lists.alioth.debian.org>
go-cpe-dictionary
golang-github-golang-geo
golang-golang-x-debug
vuls

Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
vuls

Debian Install System Team <debian-boot@lists.debian.org>
partman-swapfile

Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
openhft-chronicle-bytes
openhft-chronicle-network
openhft-chronicle-threads
openhft-chronicle-wire

Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org>
node-solid-jose
node-trust-jwa

Debian Libvirt Maintainers <pkg-libvirt-maintainers@lists.alioth.debian.org>
libvirt-tck

Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
mediagoblin

Debian PHP PEAR Maintainers <pkg-php-pear@lists.alioth.debian.org>
php-sabre-event
php-sabre-vobject

Debian Privacy Tools Maintainers <pkg-privacy-maintainers@lists.alioth.debian.org>
monkeysphere

Debian QA Group <packages@qa.debian.org>
markdown

Debian Ruby Extras Maintainers <pkg-ruby-extras-maintainers@lists.alioth.debian.org>
ruby-devise-i18n
ruby-nmatrix

Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
critterding
yorick-optimpack

Debian Security Tools <team+pkg-security@tracker.debian.org>
libewf

Debian Tcl/Tk Packagers <pkg-tcltk-devel@lists.alioth.debian.org>
tcltk-defaults

Emmanuel Bourg <ebourg@apache.org>
openhft-chronicle-bytes (U)
openhft-chronicle-network (U)
openhft-chronicle-threads (U)
openhft-chronicle-wire (U)

Francesco Paolo Lovergine <frankie@debian.org>
tcltk-defaults (U)

Gabriele Giacone <1o5g4r8o@gmail.com>
critterding (U)

Geert Stappers <stappers@debian.org>
urjtag

Giulio Paci <giuliopaci@gmail.com>
m2m-aligner
mitlm
phonetisaurus
tinysvm
yamcha

Guido Günther <agx@sigxcpu.org>
libvirt-tck (U)

Jameson Rollins <jrollins@finestructure.net>
monkeysphere (U)

Jelmer Vernooij <jelmer@debian.org>
quasselc

Jochen Friedrich <jochen@scram.de>
darkice

Jonas Smedegaard <dr@jones.dk>
imip-agent
mediagoblin (U)
node-solid-jose (U)
node-trust-jwa (U)

Jose M Calhariz <jose@calhariz.com>
librep
sawfish

Kai-Chung Yan <seamlik@debian.org>
android-platform-external-doclava (U)

Kai-Chung Yan <seamlikok@gmail.com>
android-platform-external-doclava (U)

Lennart Weller <lhw@ring0.de>
nvidia-texture-tools

Marc Bigler <marc@towards.ch>
darkice

Mathieu Parent <sathieu@debian.org>
php-sabre-vobject (U)

Matt Kraai <kraai@debian.org>
markdown

Michael Stapelberg <stapelberg@debian.org>
golang-github-golang-geo (U)
golang-golang-x-debug (U)

Nobuhiro Iwamatsu <iwamatsu@debian.org>
go-cpe-dictionary (U)
vuls (U)

ownCloud for Debian maintainers <pkg-owncloud-maintainers@lists.alioth.debian.org>
php-sabre-event (U)

Pierre Chifflier <pollux@debian.org>
libewf (U)

Samyak Jain <samyak.jn11@gmail.com>
ruby-devise-i18n (U)

Sergei Golovan <sgolovan@debian.org>
tcltk-defaults (U)

Steffen Moeller <moeller@debian.org>
libtaverna2-server-java
pluto-sat-code
sump-logicanalyzer (U)

Thibaut Paumard <thibaut@debian.org>
yorick-optimpack (U)

Thomas Goirand <zigo@debian.org>
dtc

Thorsten Glaser <tg@mirbsd.de>
musescore-snapshot

Uwe Hermann <uwe@debian.org>
urjtag

Vincent Danjean <vdanjean@debian.org>
poti

Yannick Heinrich <yannick.heinrich@gmail.com>
sump-logicanalyzer

--=-=-=--

--==-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIgEARYKADAWIQR3hZU8YXPYylUJRxfDof4h+X+qzwUCZ3E73BIcYW5zZ2FyQGRl Ymlhbi5vcmcACgkQw6H+Ifl/qs8H7AD7BkS7pMwV0/w9Kt1KvvYXVvqWNxUQmdXX EBoL7WNZiWoA/0nzUxvTpP/mWDu2Bm9k7TZVjxxeNjnh5zwYHny6ZjIB
=klfg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Date: Sun, 29 Dec 2024 13:37:50 +0100
From: Matthias Geiger <werdahias@riseup.net>
To: <ansgar@debian.org>, <debian-devel@lists.debian.org>
Cc:
Bcc:
Subject: Re: Remove ancient uploads from experimental (and later
unstable)
In-Reply-To: <87ikr2zo6m.fsf@43-1.org>

Hi,

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Sure, seems like a sane choice. If a package has been in exp for 2+
years and never has been uploaded to unstable it's likely been "forgot".
As experimental is a staging ground for packages I agree it should be periodically be checked for outdated cruft(where the date is > 2 years).

best,

werdahias

Please CC me as I am not subscribed to the list.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

This is a very good idea.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

This one deserves some discussion but is also a good idea. It was also
proposed recently in https://lists.debian.org/debian-devel/2024/08/msg00298.html


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdxSrEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 5iQP/2rrdUy05kMDtOOBFyB8CAEPPljTmGLzSNcOlVOYAt3ObLfbK/OxjN0M3ROR q0/vanBuBZaiqUxzqtRvdIJEFyYxB2Z3MSOXwftxoTP/teil+L+bcVAE2oEJGo9V 9l307KDgmgOoQjHUaLCrRF2Z5fxVtE7yh4azEEQIgWkXVZXDbJmlKttTkXljmYYt 2sEpu9Wam2jJLVv2YH0ad1LaAH0KDmUNn9ufvD451JEJ1z31gFHj8bc087EQ+C3L sLHcjtpRjOQu4MS16xdR4szE+nMWcIEMunl3HQ7IevunB55aVAxiV/idtBIxdwNt LdgWsMGRq2Sf42feMHm0i+na1lh3cRnN98Vk8+H+CxlUSDb2uLmYdyM3eiFXXIp3 P3a12A6p3DGV0YUCqpXYQKc8V3MIIu+ap8oQM/+Asug0RDCNg5nmHx7CYj0JVSsp l3cy0mCKcpHDi+ysgijefs6aD9AVWQiV9horORisgYclqwy30GPDbPdY2NX1seWC T9PqO9ghF7i7vtol1CFF8aeQpsIR+8KrVhX7MRmRLHdNN1byaMDeu2iLy2v60WRF HhE6SAMdMk8bogN78ohJ+xIj94da3Sct6LKcMDbeV9kqbK+h2jEMy5rYyPdCFBVf bX/FVI5hgath4M71R5R26aWNOA4dHLrdVym7h7xd4GuzseW8
=b2Ev
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 29/12/2024 13:08, Ansgar 🐱 wrote:
[…]

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

Yes please.

David Prévot <taffit@debian.org>
php-sabre-event (U)
php-sabre-vobject (U)

Ouch, you have my consent on these.

Regards,

taffit

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ansgar dixit:

musescore-snapshot | 2019-07-05 00:19:11.735843+00

I do have plans to pick that up once I find the tuits for it
and have finished the preceding musescore{2,3} uploads. (Lots
to do there.) So please keep that for now.

Thanks,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ansgar,

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Thanks for cleaning up the archive. The proposed criteria vaguely makes
sense to me for experimental, but not as much for unstable.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been
interacted with within one year and where the package in question is not
part of stable nor testing and is not a key package. For each of those
packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to
work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

For unstable, I think there is more reason to keep packages that have
not been uploaded in a while - so long as they do not accumulate rc
bugs.

monkeysphere | 2019-05-19 23:33:52.925219+00

I removed it from unstable, and missed experimental. Do you have any
hints on how to improve the RM bug #1085868 such that experimental is
also covered?

php-sabre-event | 2015-11-06 01:20:46.165676+00

I think I also removed this from unstable. Same question.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 a écrit :

Hi,

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

What do people think about this?

Only if that does not lead to a subsequent upload of the package to be
directed to the NEW queue again. This would waste way too much time.

I would also like to do something similar to unstable; maybe start with packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

Not for some of my packages at least. As a rule do not remove packages
that do not have RC bugs, even if they are barred of entering testing.

Cheers,
Bill.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-29 Helmut Grohne <helmut@subdivi.de> wrote:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

[...]

I would also like to do something similar to unstable; maybe start with
packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been
interacted with within one year and where the package in question is not
part of stable nor testing and is not a key package. For each of those packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to
work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

[...]

Good morning,

I think this needs a mechanism fo excempt packages which are kept
out of testing *intentionally* with a dummy rc bug (like firefox's
#817954).

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Andreas Metzler <ametzler@bebt.de> [241231 06:59]:

On 2024-12-29 Helmut Grohne <helmut@subdivi.de> wrote:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

[...]

I would also like to do something similar to unstable; maybe start with
packages uploaded before some arbitrary date that are also not included
in any of oldstable/stable/testing. These can cause problems like
wasting time to investigate cruft removals, build failures, ...

Does that seem reasonable as well?

I earlier proposed unstable removals and am now operating a
semi-automatic unstable auto remover. Its semantics are as follows.

Consider packages that have an rc bug in unstable that hasn't been interacted with within one year and where the package in question is not part of stable nor testing and is not a key package. For each of those packages file an important removal suggestion bug. Reassign such bugs to ftp.d.o as RM/RoQA bugs to ftp after a month of idleness. This seems to work out quite well and I removed more than 100 source packages this
way. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=sidremove
Feedback welcome.

[...]

Good morning,

I think this needs a mechanism fo excempt packages which are kept
out of testing *intentionally* with a dummy rc bug (like firefox's
#817954).

Thats this usertag:

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg@debian.org&tag=sidremove-ignore

C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

for experimental: yes, please!
for unstable: what Helmut said & does.

As a very simple start, I would like to remove packages from
experimental that haven't seen an upload for a long time (arbitrarily
chosen as before 2020-01-01 for the list below).

I'd propose to be more "aggressive" and use 2021-08-14 as the date, IOW
the bullseye release date. 2023-06-10 (=bookworm release date) would IMO
be too agressive *now*, but fine after the trixie release.

Thanks for bringing this up; cruft like this wastes human and computing ressources regularily, so we regularily need to reduce it, as it accumulates all the time.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Bananas are berries.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmd2gIoACgkQCRq4Vgaa qhwIaA//Z/op89oiHIrzS/NZJeiTpsKU/X4O1zU9WmKD5+e++mtbLOKFSgbSl6Lr vCZb3RbMnMXlVISSSBEqUdcRWaHheRy8bR883lK8ntdlRBArpnlRdgVkGF/VKxrP 7RR2XfmV/MVpAJ5kKSAd3FxIx0tljD3Otq7axY/r7+zV+JJc712gua5CA6IJY63g vRNlwIGS5np3BVnRUIg8Bi1Voek6wi4Rv9WOHMp9kjsd7r7EL4t4STLROfEpI1ra 3MqqhVj8X85GPq2wyBguC389rQ/REtgtG0DLyfFJ4ATEfjp+qjTt3qUpETGlRcEz uJXO1MjIxu2WRNV1qu9CDOivxDtEAhXJNPXf2Se0CZI4w4lvIwIWXqKh40SVyNiz bU5oieEqV4hClqXEl3mbw4V3rBYBGpMj4hPy4Oydw1qt9sgT4JR5vfLW6TNkLKCX CbjmwJQ5KR1y7NyvUHMJnvNpjFwrcyOKOs5LbXfFv+1wHG57oF2jcVyttqkK2Rul 0CRC9kznOuUJvsy/HcZJm4ptOyvhMqlNMrpaDY+Hk8rBop+XjcdWIg8upVRSBhah vsAyZHrBQg4oRWcPFALxOPlt+ReuwsNyDWKV33ZsVGFcuC0mkzswYPnVTYPt/V0B j/+2Tsecme0xyE9smAuJmQgVdU

* Holger Levsen <holger@layer-acht.org> [250102 13:03]:

On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:

I'm wondering how we can clean up suites like experimental and
unstable. They tend to slowly accumulate cruft that nobody cleans up, including no longer installable packages.

for experimental: yes, please!
for unstable: what Helmut said & does.

My thoughts too.

Cutoff date could be more aggressive, but I don't have a strong
opinion on it.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)