If a package is out of sync between unstable and testing for a longerperiod, this usually means that bugs in the package in testing cannot be
My package cannot be upgraded from current version to latest versionWell those errors are clearly caused by dbab.maintscript saying
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
It might have something to do with obsoleted conffile files or it
might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
package cannot be properly upgraded.
- I don't understand what breaks and why, from the output of the
package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
Hi Mentors,
I need help.
My package cannot be upgraded from current version to latest version
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
It might have something to do with obsoleted conffile files or it
might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
package cannot be properly upgraded.
- I don't understand what breaks and why, from the output of the
package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
- Thus, I have no idea how to fix it, and all my previous attempts failed. So,
Please help. The package source is at:
https://salsa.debian.org/debian/dbab/
Also, I've been trying to solve it on my own for so long that now the
good version in testing is marked for autoremoval, for the reason
that:
If a package is out of sync between unstable and testing for a longerperiod, this usually means that bugs in the package in testing cannot be fixed via unstable.
However, this is not true in my case. So if I still cannot fix the
problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?
Thanks for helping
---------- Forwarded message ---------
From: Debian testing autoremoval watch <noreply@release.debian.org>
Date: Sat, Nov 20, 2021 at 11:40 PM
Subject: dbab is marked for autoremoval from testing
To: <dbab@packages.debian.org>
dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11
It is affected by these RC bugs:
999581: dbab: fails to migrate to testing for too long: unresolved RC bug
https://bugs.debian.org/999581
This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Hi,I guess it was removed by your "dpkg-maintscript-helper rm_conffile
I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
I.e.,
----
grep: /etc/dbab/dbab.list-: No such file or directory
cat: /etc/dbab/dbab.addr: No such file or directory
----
They should be there but I have no idea why they are not.
On Thu, Dec 2, 2021 at 10:46 AM Tong Sun wrote:
Hi,
I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
I.e.,
----
grep: /etc/dbab/dbab.list-: No such file or directory
cat: /etc/dbab/dbab.addr: No such file or directory
----
Well those errors are clearly caused by dbab.maintscript saying
"rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a file. So it would be helpful if you told us what were you trying to do by this. If this is about #958900 then rm_conffile is *not* about removing
files on purge.
OK, I want to remove all conffile files and reinstall the new ones
when doing package upgrade, as there isn't much user intervention to
those conffile files. All are provided by the package.
So I do `rm_conffile` to the old conffile files when doing package
upgrade, but the new conffile files provided by the new upgrading
package did not get installed afterwards, before they were used.
They should be there but I have no idea why they are not.
That's why they are there if doing fresh package installation but they
are not there if doing package upgrade.
How to properly handle conffile files in such a case?
You should remove them manually in postrm, but only on
purge.
Unrelated, but is the package doesn't function without files downloaded
from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this?
Please, please help.
Again, the package source is at:
https://salsa.debian.org/debian/dbab/
Thanks
Is there any way to have more insights into what's going on during the package upgrade or conffile files handling?
thx
On Thu, Nov 25, 2021 at 3:45 PM Tong Sun
<suntong001@users.sourceforge.net> wrote:
Hi Mentors,
I need help.
My package cannot be upgraded from current version to latest version
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
It might have something to do with obsoleted conffile files or it
might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my package cannot be properly upgraded.
- I don't understand what breaks and why, from the output of the
package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
- Thus, I have no idea how to fix it, and all my previous attempts failed. So,
Please help. The package source is at:
https://salsa.debian.org/debian/dbab/
Also, I've been trying to solve it on my own for so long that now the good version in testing is marked for autoremoval, for the reason
that:
If a package is out of sync between unstable and testing for a longerperiod, this usually means that bugs in the package in testing cannot be fixed via unstable.
However, this is not true in my case. So if I still cannot fix the problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?
Thanks for helping
---------- Forwarded message ---------
From: Debian testing autoremoval watch <noreply@release.debian.org>
Date: Sat, Nov 20, 2021 at 11:40 PM
Subject: dbab is marked for autoremoval from testing
To: <dbab@packages.debian.org>
dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11
It is affected by these RC bugs:
999581: dbab: fails to migrate to testing for too long: unresolved RC bug
https://bugs.debian.org/999581
This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Hi,
I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
I.e.,
----
grep: /etc/dbab/dbab.list-: No such file or directory
cat: /etc/dbab/dbab.addr: No such file or directory
----
They should be there but I have no idea why they are not.
Is there any way to have more insights into what's going on during the package upgrade or conffile files handling?
thx
On Thu, Nov 25, 2021 at 3:45 PM Tong Sun
<suntong001@users.sourceforge.net> wrote:
Hi Mentors,
I need help.
My package cannot be upgraded from current version to latest version
-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769
It might have something to do with obsoleted conffile files or it
might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my
package cannot be properly upgraded.
- I don't understand what breaks and why, from the output of the
package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769).
- Thus, I have no idea how to fix it, and all my previous attempts failed. So,
Please help. The package source is at:
https://salsa.debian.org/debian/dbab/
Also, I've been trying to solve it on my own for so long that now the
good version in testing is marked for autoremoval, for the reason
that:
If a package is out of sync between unstable and testing for a longerperiod, this usually means that bugs in the package in testing cannot be fixed via unstable.
However, this is not true in my case. So if I still cannot fix the
problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing?
Thanks for helping
---------- Forwarded message ---------
From: Debian testing autoremoval watch <noreply@release.debian.org>
Date: Sat, Nov 20, 2021 at 11:40 PM
Subject: dbab is marked for autoremoval from testing
To: <dbab@packages.debian.org>
dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11
It is affected by these RC bugs:
999581: dbab: fails to migrate to testing for too long: unresolved RC bug
https://bugs.debian.org/999581
This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
OK, I want to remove all conffile files and reinstall the new onesThen they shouldn't be conffiles and shouldn't be in /etc.
when doing package upgrade, as there isn't much user intervention to
those conffile files. All are provided by the package.
So I do `rm_conffile` to the old conffile files when doing packagerm_conffile is about preserving user modifications.
upgrade,
How to properly handle conffile files in such a case?If they shouldn't be modified by the user, they should be in /usr.
The correct way, it seems, would be to follow the suggestion in theYou should remove them manually in postrm, but only on
purge.
How to do that please?
I've already filed #1001009. It says what needs to be done. The relevantUnrelated, but is the package doesn't function without files downloaded from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this?
Please don't yet, as I totally don't understand what you want me to
do, now. Unless you can send me a patch, please let me get this thing
over first.
On Sat, Dec 04, 2021 at 11:29:58PM -0500, Tong Sun wrote:
You should remove them manually in postrm, but only on
purge.
But now you will need to also recover from a bad state
left by upgrades to 1.5.7-1.
How to do that please?The correct way, it seems, would be to follow the suggestion in the
original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
the 1.3.3-1 postrm.
----
grep: /etc/dbab/dbab.list-: No such file or directory
cat: /etc/dbab/dbab.addr: No such file or directory
----
They should be there but I have no idea why they are not.
Are you asking whether you can assume that no system had 1.5.01-1 and then 1.5.7-1 installed, because in that cause it would be impossible to haveYou should remove them manually in postrm, but only on
purge.
But now you will need to also recover from a bad state
left by upgrades to 1.5.7-1.
Ah... it is getting more and more complicated. Nobody would be able to upgrade to 1.5.7-1 normally, so it is OK to use next good version as
the fix please?
Else, all the upgrade related problems can be easily fixed by purgingI don't think you can assume this is what was done though. Downgrading to
the old version, and installing a brand new version.
I just mean the original bug report already had a suggestion that seemsHow to do that please?The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
the 1.3.3-1 postrm.
I still don't quite understand what you actually mean,
On Sun, Dec 05, 2021 at 10:19:44AM -0500, wrote:
How to do that please?The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
the 1.3.3-1 postrm.
I still don't quite understand what you actually mean,I just mean the original bug report already had a suggestion that seems correct to me.
How to properly handle conffile files in such a case?
You should remove them manually in postrm, but only on
purge.
fix the "rm -f /etc/dnsmasq.d/dbab.*" line in
the 1.3.3-1 postrm.
Sorry, I'm not going to make an upload a package for this.How to do that please?The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in the 1.3.3-1 postrm.
I still don't quite understand what you actually mean,I just mean the original bug report already had a suggestion that seems correct to me.
Can you give me a simple example package showing how it should be done please?
It is not that I didn't try my best but the case is I've already tried
my best to guess what the above means but it seems I guessed wrong
each time. Thus I need detailed help, those few words only get me
going around the circles.
OK, let's start from the beginning:But #958900 was about files that were not affected by that.
How to properly handle conffile files in such a case?
You should remove them manually in postrm, but only on
purge.
That's actually what I've been doing, removing them manually in postrm
and on purge --
https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328
But I was told to "using rm_conffile directive from .maintscript file"This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or
So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.
and that's what I did, instead removing them manually in postrm withThat's not even a circle, these are multiple separate problems, some of
`rm`, I used
`dpkg-maintscript-helper rm_conffile` instead.
And now I'm at
W: maintainer-script-should-not-use-dpkg-maintscript-helper
I.e., I've gone through a full circle.
On Tue, Dec 07, 2021 at 12:57:37PM -0500, wrote:
How to do that please?The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in the 1.3.3-1 postrm.
I still don't quite understand what you actually mean,I just mean the original bug report already had a suggestion that seems correct to me.
Can you give me a simple example package showing how it should be done please?
It is not that I didn't try my best but the case is I've already triedSorry, I'm not going to make an upload a package for this.
my best to guess what the above means but it seems I guessed wrong
each time. Thus I need detailed help, those few words only get me
going around the circles.
Here are the instructions I meant and I don't know what can be clearer
than that short of an actual debdiff:
"""
I see the postrm has
/etc/dnsmasq.d/dbab.*
which I take it would have to be dbab-map.*
"""
OK, let's start from the beginning:
How to properly handle conffile files in such a case?
You should remove them manually in postrm, but only on
purge.
That's actually what I've been doing, removing them manually in postrm
and on purge --
https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328But #958900 was about files that were not affected by that.
But I was told to "using rm_conffile directive from .maintscript file"This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or
/etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as they are not shipped in the package, as far as I can see).
So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.
and that's what I did, instead removing them manually in postrm with
`rm`, I used
`dpkg-maintscript-helper rm_conffile` instead.
And now I'm at
W: maintainer-script-should-not-use-dpkg-maintscript-helper
I.e., I've gone through a full circle.That's not even a circle, these are multiple separate problems, some of
them unrelated.
Right.But I was told to "using rm_conffile directive from .maintscript file"This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as they are not shipped in the package, as far as I can see).
So you are saying that the correct way to do it is this -- https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.postrm
right?
Right.So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong.
what's the correct way for the fix then?
remove the dbab.maintscript file, i.e., https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.maintscript, right?
On Tue, Dec 7, 2021 at 4:07 PM Andrey Rahmatullin wrote:
On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote:
right?Right.
...Right.
right?
Thanks, one more thing,
The dbab can upgrade from oldstable (Buster) just fine, but I'm trying
to remove the conffile files no longer exist since then
(dbab_1.3.2-2),
| If the conffile has not been shipped for several versions, and you
are now modifying the maintainer scripts to clean up the obsolete
file, prior-version should be based on the version of the package that
you are now preparing, not the first version of the package that
lacked the conffile.
So I did this:
$ cat debian/dbab.maintscript
rm_conffile /etc/dnsmasq.d/dbab.adblock.conf 1.5.7-2~
rm_conffile /etc/dnsmasq.d/dbab.trashsites.conf 1.5.7-2~
rm_conffile /etc/dbab/dbab.proxy 1.5.7-2~
However, when I installed my 1.5.7-2 built such a way, I found the
above files are still there.
What's the problem and how can I fix it? thx
Thanks, one more thing,
The dbab can upgrade from oldstable (Buster) just fine, but I'm trying
to remove the conffile files no longer exist since then
(dbab_1.3.2-2),
| If the conffile has not been shipped for several versions, and you
are now modifying the maintainer scripts to clean up the obsolete
file, prior-version should be based on the version of the package that
you are now preparing, not the first version of the package that
lacked the conffile.
So I did this:
$ cat debian/dbab.maintscript
rm_conffile /etc/dnsmasq.d/dbab.adblock.conf 1.5.7-2~
rm_conffile /etc/dnsmasq.d/dbab.trashsites.conf 1.5.7-2~
rm_conffile /etc/dbab/dbab.proxy 1.5.7-2~
However, when I installed my 1.5.7-2 built such a way, I found the
above files are still there.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 88:07:24 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,265 |