Build-Depends: debhelper-compat (= 13)
xdelta3: Removal of obsolete debhelper compat 5 and 6 in bookwormhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965883
I favor moving away from pre-dh7 packages and I support people pushing for it. But I
am in intriguing situation with this effort. Can someone help me.
At: https://udd.debian.org/cgi-bin/autoremovals.cgi
I see:
Osamu Aoki <osamu@debian.org>
debian-history: buggy deps xdelta3, flagged for removal in 28.4 days
debian-reference: buggy deps xdelta3, flagged for removal in 28.4 days
maint-guide: buggy deps xdelta3, flagged for removal in 28.4 days
These are all COMPAT=13 packages with d/control having:
Build-Depends: debhelper-compat (= 13)
Thus, it doesn't make sense to be connected to
xdelta3: Removal of obsolete debhelper compat 5 and 6 in bookwormhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965883
Also, these packages are not even listed in the original hit list: https://lists.debian.org/debian-devel/2020/07/msg00065.html
I have been using at least compat=8 since 2013 for 2 of these packages[...]
and compat=7 since 2010 for another. So I can't figure out why these packages are suddenly flagged.
Hi,These say "buggy deps". It means they are not affected themselves but they (maybe indirectly) depend on an affected package.
I favor moving away from pre-dh7 packages and I support people pushing for it. But I
am in intriguing situation with this effort. Can someone help me.
At: https://udd.debian.org/cgi-bin/autoremovals.cgi
I see:
Osamu Aoki <osamu@debian.org>
debian-history: buggy deps xdelta3, flagged for removal in 28.4 days
debian-reference: buggy deps xdelta3, flagged for removal in 28.4 days
maint-guide: buggy deps xdelta3, flagged for removal in 28.4 days
Afaiui xdelta3 was (see below) rc-buggy, because it used dh 5 or 6 and
was therefore marked for autoremoval. Afaik autoremovals are recursive,
i.e. we do not make packages uninstallable by removing their
dependencies but instead also remove these depending packages. I think
this also extends to build-dependencies, we do not want unbuildable
packages in testing so these would be removed, too.
This is probably very academic now since Andreas Tille has uploaded a fixed xdelta3 package today.
From apt-rdepends -b
This is probably very academic now since Andreas Tille has uploaded a fixed xdelta3 package today.
This is probably very academic now since Andreas Tille has uploaded a fixed xdelta3 package today.
Now that I know that the new xdelta3 is uploaded, I am OK.
Am Thu, Feb 24, 2022 at 11:58:12PM +0900 schrieb Osamu Aoki:
This is probably very academic now since Andreas Tille has
uploaded a fixed xdelta3 package today.
Now that I know that the new xdelta3 is uploaded, I am OK. Â
BTW, I stumbled upon xdelta3 since also a package of mine received
this autoremoval warning. Usually I try to take action on it.
I had to decide between a "proper NMU" and an "upload that fits the packaging standards I apply to what I upload" (which includes
maintained on Salsa, usage of dh, DEP5 copyright ... basically
removing the smell from the package). I decided for the latter but at
the same time I was aware that I violated the rules we gave given each other.
Given the fact that there was a nearly 4 year old patch (#895957) made
me feel that I'm not alone with this but on the other hand the creator
of the patch (thanks Jeremy for doing at least half of the necessary
work) hesitated to upload his work. This brings up again the
discussion about how much changes are allowed to simply remove smell
from packages is accepted.
fixes for trivial bugs that block a transition, [where] it is
desirable that the fixed package reaches unstable sooner [than 10
days].
Am Thu, Feb 24, 2022 at 11:58:12PM +0900 schrieb Osamu Aoki:
This is probably very academic now since Andreas Tille has uploaded a fixed
xdelta3 package today.
Now that I know that the new xdelta3 is uploaded, I am OK. Â
BTW, I stumbled upon xdelta3 since also a package of mine received this autoremoval warning. Usually I try to take action on it.
I had to decide between a "proper NMU" and an "upload that fits the
packaging standards I apply to what I upload" (which includes maintained
on Salsa, usage of dh, DEP5 copyright ... basically removing the smell
from the package). I decided for the latter but at the same time I
was aware that I violated the rules we gave given each other.
Given the fact that there was a nearly 4 year old patch (#895957) made
me feel that I'm not alone with this but on the other hand the creator
of the patch (thanks Jeremy for doing at least half of the necessary
work) hesitated to upload his work. This brings up again the discussion about how much changes are allowed to simply remove smell from packages
is accepted.
I would certainly be frustrated if someone fast-tracked an NMU with structural changes like switching to short-form dh, with the reasoning
that "the packaged had a smell to it", for a package that I maintain.
I had to decide between a "proper NMU" and an "upload that fits the packaging standards I apply to what I upload" (which includes maintained on Salsa, usage of dh, DEP5 copyright ... basically removing the smell from the package). I decided for the latter but at the same time I was aware that I violated the rules we gave given each other.
Given the fact that there was a nearly 4 year old patch (#895957) made
me feel that I'm not alone with this but on the other hand the creator
of the patch (thanks Jeremy for doing at least half of the necessary
work) hesitated to upload his work. This brings up again the discussion about how much changes are allowed to simply remove smell from packages
is accepted.
FWIW I also started work on xdelta3 when I saw the removal warning for installation-guide, but when I got to the point of creating a repo on
salsa you'd beaten me to it by about an hour :-)
I'd gone for a slightly lighter-touch approach, in that I'd only done
about half of what you'd done, but having looked, you had clearly done a
much more thorough job, and I had nothing to add.
Given that the bug that's threatening its removal (#965883) has been
ignored for almost 2 years, and is about the fact that it had a dh
compat version of 5, which is completely trivial to fix, so the package certainly has the look of having been abandoned, which is why I think
it's fine to do what you did, and I think you did a very good job of it.
Given the fact that there was a nearly 4 year old patch (#895957) made
me feel that I'm not alone with this but on the other hand the creator
of the patch (thanks Jeremy for doing at least half of the necessary
work) hesitated to upload his work. This brings up again the
discussion about how much changes are allowed to simply remove smell
from packages is accepted.
Do you mean to say above that "smell removal" is somehow not an NMU?!?
I would certainly be frustrated if someone fast-tracked an NMU with structural changes like switching to short-form dh, with the reasoning
that "the packaged had a smell to it", for a package that I maintain.
I recall that we have discussed which packaging style to recommened
someone that has no strong opinion, but I am unaware that we have
decided that "smelly" packages are now somehow "outlawed" in the sense
that they don't need *exactly* the same caution as any other NMU.
Andreas Tille <andreas@an3as.eu> writes:
Am Thu, Feb 24, 2022 at 11:58:12PM +0900 schrieb Osamu Aoki:
This is probably very academic now since Andreas Tille has
uploaded a fixed xdelta3 package today.
Now that I know that the new xdelta3 is uploaded, I am OK. Â
BTW, I stumbled upon xdelta3 since also a package of mine received
this autoremoval warning. Usually I try to take action on it.
I had to decide between a "proper NMU" and an "upload that fits the packaging standards I apply to what I upload" (which includes
maintained on Salsa, usage of dh, DEP5 copyright ... basically
removing the smell from the package). I decided for the latter but
at the same time I was aware that I violated the rules we gave given
each other.
FWIW I also started work on xdelta3 when I saw the removal warning for installation-guide, but when I got to the point of creating a repo on
salsa you'd beaten me to it by about an hour :-)
I'd gone for a slightly lighter-touch approach, in that I'd only done
about half of what you'd done, but having looked, you had clearly done
a much more thorough job, and I had nothing to add.
I had replaced CDBS with dh simply because CDBS was FTBFS, and was
only a minimal 2-includes rules file, so it wasn't really contributing anything that would justify working out how to fix it.
Given the fact that there was a nearly 4 year old patch (#895957)
made me feel that I'm not alone with this but on the other hand the creator of the patch (thanks Jeremy for doing at least half of the necessary work) hesitated to upload his work. This brings up again
the discussion about how much changes are allowed to simply remove
smell from packages is accepted.
Given that the bug that's threatening its removal (#965883) has been
ignored for almost 2 years, and is about the fact that it had a dh
compat version of 5, which is completely trivial to fix, so the
package certainly has the look of having been abandoned, which is why
I think it's fine to do what you did, and I think you did a very good
job of it.
On Fri, Feb 25, 2022 at 09:50:18AM +0100, Jonas Smedegaard wrote:
I would certainly be frustrated if someone fast-tracked an NMU with structural changes like switching to short-form dh, with the
reasoning that "the packaged had a smell to it", for a package that
I maintain.
Well, do you ignore RC bugs for a long time? Do you not respond at
all the same way?
xdelta3 was not uploaded for six years. So you can somehow say it was abandoned.
Yes, which means you can fast-track for *THAT* reason - unrelated to
code smell, which is specifically what I was talking about.
Jonas Smedegaard <jonas@jones.dk> writes:
...
Yes, which means you can fast-track for *THAT* reason - unrelated to
code smell, which is specifically what I was talking about.
I understand that you were reacting to the idea that one can just
stomp on the existing packaging simply because it "smells bad", but I
don't think that was really what was being suggested.
I took Andreas's question to be more about:
If a package is obviously suffering badly from neglect, and urgently
needs an upload anyway, is it reasonable to fix as many problems as
you can while you are at it, or should one only do the bare minimum
to get past the RC bug that's prompting the upload?
Having looked at how it was done, I applaud Andreas for doing a proper
job.
If the package gets any attention from the maintainer in future, I
would guess that the fact that the package is now in a much better
state will be rather motivating.
If the maintainer happens to disagree with any of the changes, each is
in a separate commit, so would be very easily reverted, but every
change seemed like a worthwhile improvement to me.
Please note that "has no RC bugs" is *NOT* the threshold for NMUs, and certainly not if your approach to doing the NMU involved package
refactoring: When you do an NMU, it is your responsibility to ensure
that your changes did not introduce new bugs (not only RC bugs, any
bug!).
One of the reasons it is recommended to do minimal NMUs is exactly that:
To limit the risk of introducing new bugs.
When you choose to do a complex NMU which involves refactoring packaging (because is smelled), then you should expect to continue to keep that
"on your radar" for some time because subtle bugs may have been
introduced from such a radical change.
On 25-02-2022 15:02, Andreas Tille wrote:
My point was rather that the suggested salvage procedure might not raise any signal and I'm pretty sure that I would have lost track on this.
Everybody is now free to help and fix the autopkgtest regression that causes the NMU to fail to migrate.
"""
/usr/bin/ld: cannot find -llzma: No such file or directory
"""
Having looked at how it was done, I applaud Andreas for doing a proper job.
On 2/25/22 11:38, Philip Hands wrote:
Having looked at how it was done, I applaud Andreas for doing a
proper job.
+1
Anyone complaining about this kind of contribution to Debian is a
moron and a barrier to progress. We really need to get rid of this
toxic mentality in Debian.
In other words, I think what was done here was a "proper NMU" (just
not a simple one).
Thanks for the NMU, Andreas,
Jonas, I strongly disagree with using this type of example like you
just did in this thread. In many cases, switching from long-form dh to
short form is by the way a very nice improvement (if the result is
obviously very minimal, as opposed to a very verbosy-for-nothing long
form, for example). Though you've decided to take the extreme example
when one is strongly opposed to short-form dh, because of "packaging
style". So IMO, your reply is inappropriate, we should only give encouragements to Andreas, and welcome progress.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 47:57:39 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,066 |
| Messages: | 6,417,282 |
| Posted today: | 1 |