enigmail
mutextrace
obs-websocket
What do you think about the proposed criteria and suggested set of source packages? Is it reasonable to remove these packages from unstable? In a sense, it is extending the idea of the testing auto remover to unstable. Similarly, a package can be temporarily saved by mailing the respective bug.
What does a package cost?
What does package removal cost?
[…] Sometimes, packages are reintroduced. Doing so incurs a pass
through NEW (and review by the ftp team). […]
php-fig-link-util[…]
php-sabre-event( and more )
php-sabre-http
php-sabre-uri
php-sabre-xml
php-sparkline
php-webimpress-safe-writer
please allow me to open a can of worms. Package removal from unstable. Deciding when it is time to remove a package from unstable is difficult. There may be users still and it is unclear whether keeping the package imposes a cost. In this mail I want to argue for more aggressive package removal and seek consensus on a way forward.
What does package removal cost?
Before a package can be removed, it needs to be reviewed for reverse dependencies and if there are any, they have to be switched to something
else or removed as well.
Human readable explanation:
* Packages in sid
* not in bookworm or trixie
* not a key package
* affected by an RC bug that has been last modified more than a year ago
* not among a few selected exceptions
Let us assume that we agree on there being a set of packages to be
removed. What is a reasonable process? Is it ok to just file a pile of
RoQA bugs or is more warning warranted? Should we maybe use a process
similar to salvaging where there is an "ITR" (intent to remove) bug that
is reassigned to ftp after a reasonable timeout?
Hi,[...]
if I remember correctly, a package can also become a key package by having a high-enough popcon value. If that is correct, maybe there should also be the inverse. Looking at your list, about 85% of those packages have a popcon lower
than 100. Taking the popcon value into account would also kinda make your hand-curated list of exceptions obsolete as your current list has popcons well
above 100, for example. If the popcon is taken into consideration, that would also give a little bit of insurance that only very few users will be affected.
That's what I thought too: we should somehow incorporate the popcon value.
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
please allow me to open a can of worms. Package removal from unstable. Deciding when it is time to remove a package from unstable is difficult. There may be users still and it is unclear whether keeping the package imposes a cost. In this mail I want to argue for more aggressive package removal and seek consensus on a way forward.
What does a package cost?
There are various QA-related teams looking at packages from other maintainers. When it trips a check, that often incurs time from some QA person investigating a report or failure. Examples:
* [...]
By virtue of being part of Debian, a package receives attention by a significant number of developers. Assigning a number is non-trivial, but
we can say for sure that it is significant. Especially developers doing /usr-move NMUS (e.g. Chris Hofstaedler and Michael Biebl) now wonder
how much effort to put into the remaining packages. Removing more
packages would reduce the number of NMUs required there.
[...]
When to remove a package?
I looked at UDD and came up with a suggested query.
https://udd.debian.org/bugs/?release=sid¬bookworm=only¬trixie=only&merged=ign&keypackages=ign&flastmod=ign&flastmodval=366&rc=1&sortby=id&sorto=asc&format=html#results
Human readable explanation:
* Packages in sid
* not in bookworm or trixie
* not a key package
* affected by an RC bug that has been last modified more than a year ago
* not among a few selected exceptions
[...]
What do you think about the proposed criteria and suggested set of
source packages? Is it reasonable to remove these packages from
unstable? In a sense, it is extending the idea of the testing auto
remover to unstable. Similarly, a package can be temporarily saved by
mailing the respective bug.
Let us assume that we agree on there being a set of packages to be
removed. What is a reasonable process? Is it ok to just file a pile of
RoQA bugs or is more warning warranted? Should we maybe use a process
similar to salvaging where there is an "ITR" (intent to remove) bug that
is reassigned to ftp after a reasonable timeout?
My personal motivation for looking into this actually is the /usr-moveOn the "Where do we anchor this"-front, where do you see this live long
work and the cross build support work. Please do consider me biased.
Helmut
[...]
Hi,
On 8/20/24 17:35, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popconI disagree -- the users most affected by a removal are those who
value.
automate installation, and those will not be running popcon.
Popcon was introduced to determine which packages should go on the first installation CDs, but it cannot ever produce an accurate picture of
which packages are actually used (and that was communicated clearly back then, but seems to have been lost to the sands of time).
I think popcon does give a good approximation of how much percent of people installed a certain package even if not everyone uses it, don't you agree?
Last time I installed Debian it was still enabled by default.
There are various QA-related teams looking at packages from other maintainers. When it trips a check, that often incurs time from some QA person investigating a report or failure. Examples:
* Lucas Nussbaum, Santiago Vila and a few more regularly perform
archive rebuilds and report failures. They review a significant
fraction of reports before sending, but there also is CPU resources
for performing all those builds involved.
When to remove a package?
[...]
Human readable explanation:
* Packages in sid
* not in bookworm or trixie
* not a key package
* affected by an RC bug that has been last modified more than a year ago
* not among a few selected exceptions
That's what I thought too: we should somehow incorporate the popconI disagree -- the users most affected by a removal are those who
value.
automate installation, and those will not be running popcon.
Can you elaborate on that claim? I probably miss some context here, but
why do you think users most affected are the ones automating
installations and why do you think they won't be running popcon?
Popcon was introduced to determine which packages should go on the
first installation CDs, but it cannot ever produce an accurate picture
of which packages are actually used (and that was communicated clearly
back then, but seems to have been lost to the sands of time).
I think popcon does give a good approximation of how much percent of
people installed a certain package even if not everyone uses it, don't
you agree?
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
please allow me to open a can of worms. Package removal from unstable. Deciding when it is time to remove a package from unstable is difficult. There may be users still and it is unclear whether keeping the package imposes a cost. In this mail I want to argue for more aggressive package removal and seek consensus on a way forward.
What does a package cost?[ a lot]
There are various QA-related teams looking at packages from other
mixer.app[...]
On Tue, Aug 20, 2024 at 12:12:33PM +0000, Scott Kitterman wrote:criteria are quite reasonable in that regard).
Removing packages that aren't formally orphaned always sounds too bold to >> >me, though it should be fine if we formalize a process (any process) forThe process currently is file an rm but against ftp.debian.org for removal from unstable using RoQA (remember, we're all QA) explaining the rationale and an FTP Team member will assess it and remove the package if it seems reasonable (the above
that.
There are people doing this, we could use more, but it does happen. I've processed lots of these and it's virtually always fine. In the rare case of a mistake, the cost to rectify the mistake is a trip through New.
I don't think we need more process.
Oh, I'm sure it's fine both for people filing these and the FTP team, I'm >worried about reactions from the maintainers of those packages.
criteria are quite reasonable in that regard).Removing packages that aren't formally orphaned always sounds too bold to >me, though it should be fine if we formalize a process (any process) for >that.
The process currently is file an rm but against ftp.debian.org for removal from unstable using RoQA (remember, we're all QA) explaining the rationale and an FTP Team member will assess it and remove the package if it seems reasonable (the above
There are people doing this, we could use more, but it does happen. I've processed lots of these and it's virtually always fine. In the rare case of a mistake, the cost to rectify the mistake is a trip through New.
I don't think we need more process.
please allow me to open a can of worms. Package removal from unstable.
Maybe we could also reduce the cost of removals for users and potential
new maintainers, by improving the information provided in various places
on how to get the latest source and binary packages that were in Debian (pointing to snapshot.debian.org).
Things to look at:
- messages sent to the BTS when closing bugs for removed packages
- tracker.debian.org
Hi,
I also like us to remove more broken and unused packages from unstable.
On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
Maybe we could also reduce the cost of removals for users and potential
new maintainers, by improving the information provided in various places
on how to get the latest source and binary packages that were in Debian (pointing to snapshot.debian.org).
Things to look at:
- messages sent to the BTS when closing bugs for removed packages
- tracker.debian.org
YES, to all of the quoted stuff above. The BTS removal bug for that
package should have a pointer to snapshot.d.o with the last sources
as well as instructions how to reopen all bugs which were closed by
the package removal.
I am surprised to not see more of those packages in the list, there
are many packages in those ecosystems with popcon between 1-10 users.
I have also been wondering if we could take a different approach for packaging libraries for language ecosystems that already have
packaging managers to play nicer with Debian packaging
maintainability. I find myself when I need to use such libraries I
need to build my own bundle to support specific applications since
Debian packaged versions don't tend to work well with the application
(the same is true for Rust, Python, etc.)
maintainability. I find myself when I need to use such libraries I
need to build my own bundle to support specific applications since
Debian packaged versions don't tend to work well with the application
(the same is true for Rust, Python, etc.)
I think popcon does give a good approximation of how much percent of
people installed a certain package even if not everyone uses it, don't
you agree?
I think popcon does give a good approximation of how much percent of people installed a certain package even if not everyone uses it, don't you agree?
Last time I installed Debian it was still enabled by default.
I think popcon does give a good approximation of how much percent of people installed a certain package even if not everyone uses it, don't you agree?
Last time I installed Debian it was still enabled by default.
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
I think popcon does give a good approximation of how much percent of people >> installed a certain package even if not everyone uses it, don't you agree?
No, definitely not. There are hundreds of thousands of Debian systems >running in various cloud environments, and I'd be surprised if any of
them have ever submitted popcon data.
Last time I installed Debian it was still enabled by default.
Oh? I don't think it has ever been enabled by default.
My last installation of Debian on a laptop was approximately 1.5 years ago and >it was off by default. It asked me if I want to enable it or not.
Did that change recently in D-I?
On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin <wrar@debian.org> wrote:
On Tue, Aug 20, 2024 at 12:12:33PM +0000, Scott Kitterman wrote:
There are people doing this, we could use more, but it does
happen. I've processed lots of these and it's virtually always
fine. In the rare case of a mistake, the cost to rectify the
mistake is a trip through New.
I don't think we need more process.
Oh, I'm sure it's fine both for people filing these and the FTP team, I'm >worried about reactions from the maintainers of those packages.
For those cases, the people who have been doing this will
sometimes file a bug against the package as a heads up and then as
for the removal a bit later. Of course I don't ever see the ones
where the maintainer objects and nothing further comes of it, but
my impression is it's rare.
[..]
For most of the packages that fall into this category, I don't think maintainer reaction is a major issue.
golang-github-jesseduffield-asciigraph
golang-github-jesseduffield-gocui
golang-github-jesseduffield-pty
golang-github-jesseduffield-roll
golang-github-jesseduffield-rollrus
golang-github-jesseduffield-termbox-go
golang-github-jesseduffield-yaml
golang-github-manyminds-api2go
I have also been wondering if we could take a different approach for packaging libraries for language ecosystems that already have
packaging managers to play nicer with Debian packaging
maintainability. I find myself when I need to use such libraries I
need to build my own bundle to support specific applications since
Debian packaged versions don't tend to work well with the application
(the same is true for Rust, Python, etc.)
It's a very big and very controversial topic (at least if by "don't tend
to work well" you mean that we have too old or in some cases too new versions).
On 20.08.24 07:55, Johannes Schauer Marin Rodrigues wrote:
Hi,[...]
if I remember correctly, a package can also become a key package by having a
high-enough popcon value. If that is correct, maybe there should also be the
inverse. Looking at your list, about 85% of those packages have a popcon lower
than 100. Taking the popcon value into account would also kinda make your hand-curated list of exceptions obsolete as your current list has popcons well
above 100, for example. If the popcon is taken into consideration, that would
also give a little bit of insurance that only very few users will be affected.
That's what I thought too: we should somehow incorporate the popcon value.
enigmail
Thunderbird has native GPG support now, including (well-hidden) support for calling into the installed gpg binary to use a smartcard.
mutextrace
Oof, I should fix that finally, because in principle a debugging layer to find lock hierarchy violations would be good to have.
obs-websocket
Websocket support was merged into the main program a while ago.
I considered adding popcon to the criteria before hitting send. In the
end, I opted for not including it based on my own cost/benefit analysis. While popcon may be a signal for the benefit-of-keeping aspect, it
provides little value for the cost-of-keeping part that feels most
important to me. As you point out, popcon is partially considered via
the key package constraint. As others (e.g. Niels) point out, the cost
of a package largely is a function of our ability to modify it and long lasting RC bugs are a relatively high quality signal indicating that a package is difficult to modify. Either some of those many users
(according to popcon) eventually gets interested in doing the hard work,
or we should put it onto the chopping block. Even mailing the rc bug
would reset its last modified timer.
If there ends up being consensus for adding popcon as a signal, so be
it. I've explained my reasons and am not too strongly attached to
excluding popcon.
Hi,on packaging lazygit towards the end of the previous year, which I believe was mostly finished, that was then delayed by the person primarily focusing on this being the chief organizer for DebConf24. I am not sure removing them is the best idea, given it
I believe at least some of these packages were probably packaged as dependencies for packaging lazygit. I am not sure which all, but I remember atleast gocui, pty and termbox-go to be needed by lazygit in one way or another. There has been further work
Best,
Ananthu
golang-github-jesseduffield-asciigraph
golang-github-jesseduffield-gocui
golang-github-jesseduffield-pty
golang-github-jesseduffield-roll
golang-github-jesseduffield-rollrus
golang-github-jesseduffield-termbox-go
golang-github-jesseduffield-yaml
golang-github-manyminds-api2go
I believe at least some of these packages were probably packaged as dependencies for packaging lazygit. I am not sure which all, but I
remember atleast gocui, pty and termbox-go to be needed by lazygit in
one way or another. There has been further work on packaging lazygit
towards the end of the previous year, which I believe was mostly
finished, that was then delayed by the person primarily focusing on this being the chief organizer for DebConf24. I am not sure removing them is
the best idea, given it is part of an ongoing work.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 486 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 142:03:25 |
| Calls: | 9,658 |
| Calls today: | 6 |
| Files: | 13,708 |
| Messages: | 6,167,539 |