Bug#852470: Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Please continue discussion in this *NEW* bug. On 2017-01-24 23:25, Maarten van Gompel wrote: > Hi Andreas, Mattia, > > Quoting Andreas Beckmann (2017-01-24 19:04:24) >>> >>> Oops... Well spotted, I just fixed it in git, but it is probably overkill >>> to prepare/upload a new release just >>> for that now I guess? >> >> Correct. But let me see what else I found: >> >> jessie-> sid upgrades: >> >> ucto.maintscript is missing, doing rm_conffile on the conffiles shipped >> in jessie (use 0.9.6-2~ as prior version, if this gets fixed in -2). >> If there was a post-jessie version shipping more conffiles in /etc, >> clean them up as well. >> >> ucto: obsolete-conffile /etc/ucto/exotic-eos.eos >> ucto: obsolete-conffile /etc/ucto/nl_afk.abr >> ucto: obsolete-conffile /etc/ucto/tokconfig-nl >> ucto: obsolete-conffile /etc/ucto/smiley.rule >> ucto: obsolete-conffile /etc/ucto/tokconfig-it >> ucto: obsolete-conffile /etc/ucto/standard-eos.eos >> ucto: obsolete-conffile /etc/ucto/tokconfig-sv >> ucto: obsolete-conffile /etc/ucto/tokconfig-fr >> ucto: obsolete-conffile /etc/ucto/exotic-quotes.quote >> ucto: obsolete-conffile /etc/ucto/tokconfig-nl-twitter >> ucto: obsolete-conffile /etc/ucto/tokconfig-es >> ucto: obsolete-conffile /etc/ucto/url.rule >> ucto: obsolete-conffile /etc/ucto/e-mail.rule >> ucto: obsolete-conffile /etc/ucto/tokconfig-nl-sonarchat >> ucto: obsolete-conffile /etc/ucto/es.abr >> ucto: obsolete-conffile /etc/ucto/tokconfig-fy >> ucto: obsolete-conffile /etc/ucto/tokconfig-de >> ucto: obsolete-conffile /etc/ucto/tokconfig-en >> ucto: obsolete-conffile /etc/ucto/ligatures.filter >> ucto: obsolete-conffile /etc/ucto/standard-quotes.quote > > I think I get it. Because these moved to uctodata, which did not exist yet for > jessie (before the split), the config files are owned by ucto and uctodata > can't clean > it. Hadn't thought of that yet. I added an ucto.maintscript now for 0.9.6-2 > (in > git). Theoretically making uctodata cleaning them up, too, is possible, but the tasks in uctodata are already "interesting" enough. And ucto is not going to be removed on the jessie->stretch upgrade. >> frog looks fine >> >> stretch -> sid upgrades: >> >> libucto2:amd64: obsolete-conffile /etc/ucto/textcat.cfg > > added > >> >> uctodata: obsolete-conffile /etc/ucto/spa.abr >> uctodata: obsolete-conffile /etc/ucto/por.abr >> uctodata: obsolete-conffile /etc/ucto/nld_afk.abr >> > > added > >> frog looks fine, too >> >> >> That's not RC, the upgrades went smooth, but it would still be great to >> get this cleaned up properly. > > I'm glad it went smooth in spite of this. Hopefully the next releases will > clean it up for good. > >> >> But lets take a detailed look what happened here: >> >> Unpacking uctodata (0.4-1) over (0.3.1-1) ... >> dpkg: warning: unable to delete old directory '/etc/ucto': Directory >> not empty >> Setting up uctodata (0.4-1) ... >> Obsolete conffile /etc/ucto/es.abr has been modified by you. >> Saving as /etc/ucto/es.abr.dpkg-bak ... >> Removing obsolete conffile /etc/ucto/exotic-eos.eos ... >> Removing obsolete conffile /etc/ucto/exotic-quotes.quote ... >> Removing obsolete conffile /etc/ucto/ligatures.filter ... >> Obsolete conffile /etc/ucto/nl_afk.abr has been modified by you. >> Saving as /etc/ucto/nl_afk.abr.dpkg-bak ... >> Obsolete conffile /etc/ucto/pt.abr has been modified by you. >> Saving as /etc/ucto/pt.abr.dpkg-bak ... >> Removing obsolete conffile /etc/ucto/tokconfig-deu ... >> Removing obsolete conffile /etc/ucto/tokconfig-eng ... >> Removing obsolete conffile /etc/ucto/tokconfig-spa ... >> Removing obsolete conffile /etc/ucto/tokconfig-fra ... >> Removing obsolete conffile /etc/ucto/tokconfig-fry ... >> Removing obsolete conffile /etc/ucto/tokconfig-ita ... >> Removing obsolete conffile /etc/ucto/tokconfig-nld ... >> Removing obsolete conffile /etc/ucto/tokconfig-nld-sonarchat ... >> Removing obsolete conffile /etc/ucto/tokconfig-nld-twitter ... >> Removing obsolete conffile /etc/ucto/tokconfig-nld-withplaceholder ... >> Removing obsolete conffile /etc/ucto/tokconfig-por ... >> Removing obsolete conffile /etc/ucto/tokconfig-rus ... >> Removing obsolete conffile /etc/ucto/tokconfig-swe ... >> Removing obsolete conffile /etc/ucto/tokconfig-tur ... >> Processing triggers for libc-bin (2.24-9) ... >> >> You probably shouldn't call rm_conffile on the symlinks owned by >> uctodata - these are no conffiles, but you seem to confuse dpkg by doing >> this. Removing the conffiles from jessie is better left to >> ucto.maintscript. > > But before these were symlinks in uctodata, they were normal files in > uctodata... Only the 0.3.1 release introduced the symlinks (for a very short > while since it was only accepted not so long ago).. Not sure how to make the > distinction. Hmm, interesting ... how many (and which) conffiles in uctodata (not the ones from ucto) have
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On 2017-01-24 23:25, Maarten van Gompel wrote: I'll reply to 852...@bugs.debian.org Andreas
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Hi Andreas, Mattia, Quoting Andreas Beckmann (2017-01-24 19:04:24) > > > > Oops... Well spotted, I just fixed it in git, but it is probably overkill > > to prepare/upload a new release just > > for that now I guess? > > Correct. But let me see what else I found: > > jessie-> sid upgrades: > > ucto.maintscript is missing, doing rm_conffile on the conffiles shipped > in jessie (use 0.9.6-2~ as prior version, if this gets fixed in -2). > If there was a post-jessie version shipping more conffiles in /etc, > clean them up as well. > > ucto: obsolete-conffile /etc/ucto/exotic-eos.eos > ucto: obsolete-conffile /etc/ucto/nl_afk.abr > ucto: obsolete-conffile /etc/ucto/tokconfig-nl > ucto: obsolete-conffile /etc/ucto/smiley.rule > ucto: obsolete-conffile /etc/ucto/tokconfig-it > ucto: obsolete-conffile /etc/ucto/standard-eos.eos > ucto: obsolete-conffile /etc/ucto/tokconfig-sv > ucto: obsolete-conffile /etc/ucto/tokconfig-fr > ucto: obsolete-conffile /etc/ucto/exotic-quotes.quote > ucto: obsolete-conffile /etc/ucto/tokconfig-nl-twitter > ucto: obsolete-conffile /etc/ucto/tokconfig-es > ucto: obsolete-conffile /etc/ucto/url.rule > ucto: obsolete-conffile /etc/ucto/e-mail.rule > ucto: obsolete-conffile /etc/ucto/tokconfig-nl-sonarchat > ucto: obsolete-conffile /etc/ucto/es.abr > ucto: obsolete-conffile /etc/ucto/tokconfig-fy > ucto: obsolete-conffile /etc/ucto/tokconfig-de > ucto: obsolete-conffile /etc/ucto/tokconfig-en > ucto: obsolete-conffile /etc/ucto/ligatures.filter > ucto: obsolete-conffile /etc/ucto/standard-quotes.quote I think I get it. Because these moved to uctodata, which did not exist yet for jessie (before the split), the config files are owned by ucto and uctodata can't clean it. Hadn't thought of that yet. I added an ucto.maintscript now for 0.9.6-2 (in git). > > frog looks fine > > stretch -> sid upgrades: > > libucto2:amd64: obsolete-conffile /etc/ucto/textcat.cfg added > > uctodata: obsolete-conffile /etc/ucto/spa.abr > uctodata: obsolete-conffile /etc/ucto/por.abr > uctodata: obsolete-conffile /etc/ucto/nld_afk.abr > added > frog looks fine, too > > > That's not RC, the upgrades went smooth, but it would still be great to > get this cleaned up properly. I'm glad it went smooth in spite of this. Hopefully the next releases will clean it up for good. > > But lets take a detailed look what happened here: > > Unpacking uctodata (0.4-1) over (0.3.1-1) ... > dpkg: warning: unable to delete old directory '/etc/ucto': Directory > not empty > Setting up uctodata (0.4-1) ... > Obsolete conffile /etc/ucto/es.abr has been modified by you. > Saving as /etc/ucto/es.abr.dpkg-bak ... > Removing obsolete conffile /etc/ucto/exotic-eos.eos ... > Removing obsolete conffile /etc/ucto/exotic-quotes.quote ... > Removing obsolete conffile /etc/ucto/ligatures.filter ... > Obsolete conffile /etc/ucto/nl_afk.abr has been modified by you. > Saving as /etc/ucto/nl_afk.abr.dpkg-bak ... > Obsolete conffile /etc/ucto/pt.abr has been modified by you. > Saving as /etc/ucto/pt.abr.dpkg-bak ... > Removing obsolete conffile /etc/ucto/tokconfig-deu ... > Removing obsolete conffile /etc/ucto/tokconfig-eng ... > Removing obsolete conffile /etc/ucto/tokconfig-spa ... > Removing obsolete conffile /etc/ucto/tokconfig-fra ... > Removing obsolete conffile /etc/ucto/tokconfig-fry ... > Removing obsolete conffile /etc/ucto/tokconfig-ita ... > Removing obsolete conffile /etc/ucto/tokconfig-nld ... > Removing obsolete conffile /etc/ucto/tokconfig-nld-sonarchat ... > Removing obsolete conffile /etc/ucto/tokconfig-nld-twitter ... > Removing obsolete conffile /etc/ucto/tokconfig-nld-withplaceholder ... > Removing obsolete conffile /etc/ucto/tokconfig-por ... > Removing obsolete conffile /etc/ucto/tokconfig-rus ... > Removing obsolete conffile /etc/ucto/tokconfig-swe ... > Removing obsolete conffile /etc/ucto/tokconfig-tur ... > Processing triggers for libc-bin (2.24-9) ... > > You probably shouldn't call rm_conffile on the symlinks owned by > uctodata - these are no conffiles, but you seem to confuse dpkg by doing > this. Removing the conffiles from jessie is better left to > ucto.maintscript. But before these were symlinks in uctodata, they were normal files in uctodata... Only the 0.3.1 release introduced the symlinks (for a very short while since it was only accepted not so long ago).. Not sure how to make the distinction. > I think you found a bug in dpkg here :-) > > Preparing to unpack .../libucto2_0.9.6-1_amd64.deb ... > Unpacking libucto2:amd64 (0.9.6-1) over (0.9.5-1) ... > dpkg: warning: unable to delete old directory '/etc/ucto': Directory > not empty > Setting up libgomp1:amd64 (6.3.0-4) ... > Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ... > Processing triggers for libc-bin (2.24-9) ... > Setting up libucto2:amd64 (0.9.6-1) ... > Removing obsolete conffile /etc/ucto/e-mail.rule ... >
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On 2017-01-24 19:30, Mattia Rizzolo wrote: > Wow, upgrades issues are so full of cases. > Anyhow, I still don't think we should fix these, if nothing to try to > have the newer upstream versions and their fairly big diffs into > stretch. > > I suggest you (Andreas) file a new bug(s) copy-pasting what you wrote > here, and we (=> Maarten) will possibly deal with it after the current > testing migrations happen. #852470 Fixing in git and testing should happen before migration s.t. the current stretch version is still available for my tests. (I'll throw the new packages in my piuparts engine.) See you over there :-) >> I think you found a bug in dpkg here :-) > > ISTR reading something somewhere that not handling symlinks as conffile > is a known decision, because it's particuarly hard to do. #852468 I was more thinking about rm_conffile messing around with something that is not a conffile. Andreas
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On Tue, Jan 24, 2017 at 07:04:24PM +0100, Andreas Beckmann wrote:
> On 2017-01-24 09:32, Maarten van Gompel wrote:
> > Quoting Andreas Beckmann (2017-01-24 02:54:36)
> >> On 2017-01-24 02:51, Andreas Beckmann wrote:
> >>> spotted a typo (trailing "a") in frogdata.maintscript
> >>>
> >>> echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
> >>> 0.13.7~"a
> >>
> >> but that's harmless, its still a valid version to achieve your goal
> >
> > Oops... Well spotted, I just fixed it in git, but it is probably overkill
> > to prepare/upload a new release just
> > for that now I guess?
>
> Correct. But let me see what else I found:
Wow, upgrades issues are so full of cases.
Anyhow, I still don't think we should fix these, if nothing to try to
have the newer upstream versions and their fairly big diffs into
stretch.
I suggest you (Andreas) file a new bug(s) copy-pasting what you wrote
here, and we (=> Maarten) will possibly deal with it after the current
testing migrations happen.
Fixing those should only be about adding few maintscripts lines, so that
should be feasible for the release team to grant, surely more than the
current update (note that what I want to avoid is to needlessly burden
the release team; I think they would grant also the current upgrade, but
it'd take more for them to review).
> You probably shouldn't call rm_conffile on the symlinks owned by
> uctodata - these are no conffiles, but you seem to confuse dpkg by doing
> this. Removing the conffiles from jessie is better left to
> ucto.maintscript.
>
> I think you found a bug in dpkg here :-)
ISTR reading something somewhere that not handling symlinks as conffile
is a known decision, because it's particuarly hard to do.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On 2017-01-24 09:32, Maarten van Gompel wrote:
> Quoting Andreas Beckmann (2017-01-24 02:54:36)
>> On 2017-01-24 02:51, Andreas Beckmann wrote:
>>> spotted a typo (trailing "a") in frogdata.maintscript
>>>
>>> echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
>>> 0.13.7~"a
>>
>> but that's harmless, its still a valid version to achieve your goal
>
> Oops... Well spotted, I just fixed it in git, but it is probably overkill to
> prepare/upload a new release just
> for that now I guess?
Correct. But let me see what else I found:
jessie-> sid upgrades:
ucto.maintscript is missing, doing rm_conffile on the conffiles shipped
in jessie (use 0.9.6-2~ as prior version, if this gets fixed in -2).
If there was a post-jessie version shipping more conffiles in /etc,
clean them up as well.
ucto: obsolete-conffile /etc/ucto/exotic-eos.eos
ucto: obsolete-conffile /etc/ucto/nl_afk.abr
ucto: obsolete-conffile /etc/ucto/tokconfig-nl
ucto: obsolete-conffile /etc/ucto/smiley.rule
ucto: obsolete-conffile /etc/ucto/tokconfig-it
ucto: obsolete-conffile /etc/ucto/standard-eos.eos
ucto: obsolete-conffile /etc/ucto/tokconfig-sv
ucto: obsolete-conffile /etc/ucto/tokconfig-fr
ucto: obsolete-conffile /etc/ucto/exotic-quotes.quote
ucto: obsolete-conffile /etc/ucto/tokconfig-nl-twitter
ucto: obsolete-conffile /etc/ucto/tokconfig-es
ucto: obsolete-conffile /etc/ucto/url.rule
ucto: obsolete-conffile /etc/ucto/e-mail.rule
ucto: obsolete-conffile /etc/ucto/tokconfig-nl-sonarchat
ucto: obsolete-conffile /etc/ucto/es.abr
ucto: obsolete-conffile /etc/ucto/tokconfig-fy
ucto: obsolete-conffile /etc/ucto/tokconfig-de
ucto: obsolete-conffile /etc/ucto/tokconfig-en
ucto: obsolete-conffile /etc/ucto/ligatures.filter
ucto: obsolete-conffile /etc/ucto/standard-quotes.quote
frog looks fine
stretch -> sid upgrades:
libucto2:amd64: obsolete-conffile /etc/ucto/textcat.cfg
uctodata: obsolete-conffile /etc/ucto/spa.abr
uctodata: obsolete-conffile /etc/ucto/por.abr
uctodata: obsolete-conffile /etc/ucto/nld_afk.abr
frog looks fine, too
That's not RC, the upgrades went smooth, but it would still be great to
get this cleaned up properly.
But lets take a detailed look what happened here:
Unpacking uctodata (0.4-1) over (0.3.1-1) ...
dpkg: warning: unable to delete old directory '/etc/ucto': Directory
not empty
Setting up uctodata (0.4-1) ...
Obsolete conffile /etc/ucto/es.abr has been modified by you.
Saving as /etc/ucto/es.abr.dpkg-bak ...
Removing obsolete conffile /etc/ucto/exotic-eos.eos ...
Removing obsolete conffile /etc/ucto/exotic-quotes.quote ...
Removing obsolete conffile /etc/ucto/ligatures.filter ...
Obsolete conffile /etc/ucto/nl_afk.abr has been modified by you.
Saving as /etc/ucto/nl_afk.abr.dpkg-bak ...
Obsolete conffile /etc/ucto/pt.abr has been modified by you.
Saving as /etc/ucto/pt.abr.dpkg-bak ...
Removing obsolete conffile /etc/ucto/tokconfig-deu ...
Removing obsolete conffile /etc/ucto/tokconfig-eng ...
Removing obsolete conffile /etc/ucto/tokconfig-spa ...
Removing obsolete conffile /etc/ucto/tokconfig-fra ...
Removing obsolete conffile /etc/ucto/tokconfig-fry ...
Removing obsolete conffile /etc/ucto/tokconfig-ita ...
Removing obsolete conffile /etc/ucto/tokconfig-nld ...
Removing obsolete conffile /etc/ucto/tokconfig-nld-sonarchat ...
Removing obsolete conffile /etc/ucto/tokconfig-nld-twitter ...
Removing obsolete conffile /etc/ucto/tokconfig-nld-withplaceholder ...
Removing obsolete conffile /etc/ucto/tokconfig-por ...
Removing obsolete conffile /etc/ucto/tokconfig-rus ...
Removing obsolete conffile /etc/ucto/tokconfig-swe ...
Removing obsolete conffile /etc/ucto/tokconfig-tur ...
Processing triggers for libc-bin (2.24-9) ...
You probably shouldn't call rm_conffile on the symlinks owned by
uctodata - these are no conffiles, but you seem to confuse dpkg by doing
this. Removing the conffiles from jessie is better left to
ucto.maintscript.
I think you found a bug in dpkg here :-)
Preparing to unpack .../libucto2_0.9.6-1_amd64.deb ...
Unpacking libucto2:amd64 (0.9.6-1) over (0.9.5-1) ...
dpkg: warning: unable to delete old directory '/etc/ucto': Directory
not empty
Setting up libgomp1:amd64 (6.3.0-4) ...
Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ...
Processing triggers for libc-bin (2.24-9) ...
Setting up libucto2:amd64 (0.9.6-1) ...
Removing obsolete conffile /etc/ucto/e-mail.rule ...
Removing obsolete conffile /etc/ucto/smiley.rule ...
Removing obsolete conffile /etc/ucto/url.rule ...
Removing obsolete conffile /etc/ucto/standard-eos.eos ...
Removing obsolete conffile /etc/ucto/standard-quotes.quote ...
Removing obsolete conffile /etc/ucto/tokconfig-generic ...
Processing triggers for libc-bin (2.24-9) ...
libucto2.maintscript is missing this line:
rm_conffile /etc/ucto/tokconfig-generic 0.9.6-2~
Andreas
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On Tue, Jan 24, 2017 at 09:32:38AM +0100, Maarten van Gompel wrote:
> Quoting Andreas Beckmann (2017-01-24 02:54:36)
> > On 2017-01-24 02:51, Andreas Beckmann wrote:
> > > spotted a typo (trailing "a") in frogdata.maintscript
> > >
> > > echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
> > > 0.13.7~"a
> >
> > but that's harmless, its still a valid version to achieve your goal
>
> Oops... Well spotted, I just fixed it in git, but it is probably
> overkill to prepare/upload a new release just for that now I guess?
As Andreas said it's harmless for you, it works just fine.
And yes, I would not upload it, as it would delay all the other packages
by half a day now, making everything dangerously near the freeze moment
(the release team would very probably accept these changes, but well, if
we can avoid bothering them it's just better; they are going to have
very busy moments even without us).
IMHO, just keep in git for whatever next upload will be.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-24 02:54:36)
> On 2017-01-24 02:51, Andreas Beckmann wrote:
> > spotted a typo (trailing "a") in frogdata.maintscript
> >
> > echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt
> > 0.13.7~"a
>
> but that's harmless, its still a valid version to achieve your goal
Oops... Well spotted, I just fixed it in git, but it is probably overkill to
prepare/upload a new release just
for that now I guess?
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl
Telegram: proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On 2017-01-24 02:51, Andreas Beckmann wrote:
> spotted a typo (trailing "a") in frogdata.maintscript
>
> echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt 0.13.7~"a
but that's harmless, its still a valid version to achieve your goal
Andreas
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Hi,
just browsed the git commits in the web interface
spotted a typo (trailing "a") in frogdata.maintscript
echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt 0.13.7~"a
BTW, you could also add the slash here:
for subdir in "" "nld/" "nl/"
besides that, everything looks ok on a quick glance
will report after I got piuparts results tomorrow ...
Andreas
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On Mon, Jan 23, 2017 at 08:31:01PM +0100, Maarten van Gompel wrote: > This is what I was looking for yes, I knew something must exist to take care > of > this but didn't know what it was. I now followed Andreas' instructions, but > on but upon gbp buildpackage I now get > errors like: > > /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 1: > /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: > rm_conffile: not found > > So I'm still doing something wrong. Any idea what I am missing? You said no > dpkg-maintscript-helper prefix.. 1) the file is executable: remember that debhelper will try to execute all executable file, and then interpret the output of whatever run, instead of reading the file (this is a feature, commonly used with dh-exec, but sometimes also for something else. You could for example do it for that other package where you do a loop 2) There is a spurious leading space in all lines -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
Hi Mattia, Andreas, @Mattia: Thanks! I'm trying to finalize the packages but still running into something: > use debian/$package.maintscript instead of doing it directly in maintscripts > > put in there lines like > > rm_conffile /etc/ucto/tokconfig-es 0.4-1~ > > no dpkg-maintscript-helper prefix, no default arguments, no trailing > comments! > use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument > > this will generate appropriate pre/post/inst/rm scripts with the same > content This is what I was looking for yes, I knew something must exist to take care of this but didn't know what it was. I now followed Andreas' instructions, but on but upon gbp buildpackage I now get errors like: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 1: /home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: rm_conffile: not found So I'm still doing something wrong. Any idea what I am missing? You said no dpkg-maintscript-helper prefix.. Ciao, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On Mon, Jan 23, 2017 at 07:48:34PM +0100, Andreas Beckmann wrote: > On 2017-01-23 19:17, Maarten van Gompel wrote: > > Hi Andreas, Mattia, et. al. Hi Maarten :) > > > >> uploads should happen early enough to allow automatic migration after 10 > >> days on Feb 05 (so probably at most 2 days left) Yes. Also, I would have advise against uploading before today, as that would have mean blocking the migration that was ongoing (that finished last night). > > I followed the documentation and created postint/preinst/postrm scripts for > > libucto2 (ucto), uctodata and frogdata that takes care of removing the old > > files, as you suggested. I tested it on migration from the previous releases > > and it works. Still, a second look from someone with more knowledge about > > these > > things is highly appreciated. I haven't been able to test the upgrade from > > the > > jessie versions yet but I'll try to look into piuparts to do that. I think > > everything should be solved with the releases I prepared today (but again; > > double checks appreciated!) > > I'll take a look It looks ok from my side, but as Andreas wrote below, please use the tools dh_installdeb(1) give you, i.e. the debian/$pkg.maintscript file. > > @Mattia: Do you happen to be available on such short notice to > > sponsor/upload > > these four packages again? Considering also the very tight deadline before > > the > > freeze. Sorry for the inconvenience! > > If needed, I can sponsor that as well Yes I am. I haven't followed the other discussion at all, mostly because I trust Andreas and bunk to know what they are writing :) Just to confirm: in this case there is no order to follow, right? > > PS: the postinst/preinst/postrm scripts are currently three copies of the > > same > > thing. I realize this is probably ugly (unnecessary duplication) and not the > > best way, but I didn't know what would be the best solution and since I was > > in > > a rush I left it like this. > > use debian/$package.maintscript instead of doing it directly in maintscripts > > put in there lines like > > rm_conffile /etc/ucto/tokconfig-es 0.4-1~ > > no dpkg-maintscript-helper prefix, no default arguments, no trailing > comments! > use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument > > this will generate appropriate pre/post/inst/rm scripts with the same > content > Andreas (in a hurry) Andreas: Dont worry, if you don't have time for this I'll happily sponsor them; I already have all of them locally, etc. :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr
On 2017-01-23 19:17, Maarten van Gompel wrote: > Hi Andreas, Mattia, et. al. > >> uploads should happen early enough to allow automatic migration after 10 >> days on Feb 05 (so probably at most 2 days left) > > Right. We have prepared new upstream releases for uctodata, ucto, frogdata and > frog today that rely on the data being in share/ instead of etc/, and should > therefore resolve this persistent bug. I updated all the debian packages > accordingly. The fact I did frog and frogdata as well is because the same > issue > might likely arise there and it depends on ucto anyhow. Putting the stuff in > etc/ was unnecessary overengineering on our part. piuparts probably didn't test frog* if their dependencies failed, otherwise it would have found the same error there > > I followed the documentation and created postint/preinst/postrm scripts for > libucto2 (ucto), uctodata and frogdata that takes care of removing the old > files, as you suggested. I tested it on migration from the previous releases > and it works. Still, a second look from someone with more knowledge about > these > things is highly appreciated. I haven't been able to test the upgrade from > the > jessie versions yet but I'll try to look into piuparts to do that. I think > everything should be solved with the releases I prepared today (but again; > double checks appreciated!) I'll take a look > @Mattia: Do you happen to be available on such short notice to sponsor/upload > these four packages again? Considering also the very tight deadline before > the > freeze. Sorry for the inconvenience! If needed, I can sponsor that as well > For completion's sake, the packages are: > > * https://anonscm.debian.org/cgit/debian-science/packages/uctodata.git > * https://anonscm.debian.org/cgit/debian-science/packages/ucto.git > * https://anonscm.debian.org/cgit/debian-science/packages/frogdata.git > * https://anonscm.debian.org/cgit/debian-science/packages/frog.git > > Regards, > > PS: the postinst/preinst/postrm scripts are currently three copies of the same > thing. I realize this is probably ugly (unnecessary duplication) and not the > best way, but I didn't know what would be the best solution and since I was in > a rush I left it like this. use debian/$package.maintscript instead of doing it directly in maintscripts put in there lines like rm_conffile /etc/ucto/tokconfig-es 0.4-1~ no dpkg-maintscript-helper prefix, no default arguments, no trailing comments! use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument this will generate appropriate pre/post/inst/rm scripts with the same content Andreas (in a hurry)
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
On 2017-01-23 12:06, Maarten van Gompel wrote:
> Hi Andreas et al,
>
> Short follow up: we discussed it internally and think it's indeed best to just
> move the 'configuration' files to /usr/share, as you pointed out; simplifying
> the package and
> resolving the conflicts.
so you'll need to add a log of rm_conffile to
{ucto,uctodata,libucto2}.maintscript
and you probably don't have add libucto-common either, if the library
packages no longer have conffiles
> We're currently working on new upstream releases for
> ucto, uctodata, frogdata, and frog (the latter two have the same division and
> make the same mistake, and depends on ucto/uctodata too) that implement this.
> I
> hope releasing four new packages so close to the freeze is not going to be a
> problem. At least it should fix this bug for good.
uploads should happen early enough to allow automatic migration after 10
days on Feb 05 (so probably at most 2 days left)
Andreas
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Hi Andreas et al, Short follow up: we discussed it internally and think it's indeed best to just move the 'configuration' files to /usr/share, as you pointed out; simplifying the package and resolving the conflicts. We're currently working on new upstream releases for ucto, uctodata, frogdata, and frog (the latter two have the same division and make the same mistake, and depends on ucto/uctodata too) that implement this. I hope releasing four new packages so close to the freeze is not going to be a problem. At least it should fix this bug for good. Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd Quoting Maarten van Gompel (2017-01-23 11:10:18) > Hi Andreas, > > Thanks for your elaborate response! It seems this has indeed opened quite a > can > of worms.. Here we go: > > Quoting Andreas Beckmann (2017-01-22 22:27:08) > > TL;DR: You have an ambitious task before you. > > So I see... > > > Let me see if I understand what's going on. > > > > Renaming conffiles and changing the owning package at the same time is a > > PITA. > > You add an extra point by making the old name a symlink to the new one, > > owned by the new package > > > > In jessie, everything in /etc/ucto was owned by ucto. > > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata > > or libucto2, a m-a:same library package. These come from 2 different > > source packages. > > Indeed.. > > > Yuck. While putting conffiles in m-a:same packages is allowed, I highly > > discourage this. Even if I haven't seen this fail once, yet. I'm just > > afraid, someone has to clean up a mess caused by this at some point in > > the future. and I'm afraid, I won't keep my fingers out of then :-( > > Ok, we'll come back to this in your later suggestion to move the conffiles to > a > new package. > > > Before we start: Are these really conffiles? Supposed to be modified by > > the local admin? Or are these rather data files that are not supposed to > > be updated locally? And would better live in /usr/share in that case? > > You have a point there; the user MAY add a new configuration or modify an > existing one, but it is indeed not something that NEEDS to be modified to > run. You may be right that > /usr/share might be better here. I'd have to discuss with the main upstream > developer, but I think we're not opposed to such 'radical' solutions if that > solves the packaging problems and makes more semantic sense anyway. > What do you think is best for the short term to get this fixed before the > freeze? > > > And nearly everything from jessie's /etc/ucto content is now renamed and > > a symlink. > > > Can't you just fork the project? I'd suggest 'hpgb' and then use > > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new > > source packages ... > > > > Oh yeah, it well be a mess. But we will do it right. Including making > > dpkg forget about the old conffiles. > > > > Right now, all upgrade attempts from jessie to stretch should always > > have failed, so there is no further messed up state inbetween that > > should be supported for clean upgrades. > > Right > > > can we move the conffiles from libucto2 to a new package, e.g. > > ucto-common (which would be either m-a:foreign or m-a:allowed, but I > > always mess up these two, I need to look up what's right? > > Okay, that sounds good to me, if there's no objection to having yet another > package. > > > * Which version introduced the new layout? > > * can you give me a list of > > + removed conffiles > > + renamed conffiles (old name, new name, new owning package, whether > > they have a compat symlink, did the content change between jessie and sid) > > ucto 0.9.2 introduced the split into uctodata. The jessie version is very > old: 0.5.3-3.1 > The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata > package: > > config/es.abr > config/exotic-eos.eos > config/exotic-quotes.quote > config/ligatures.filter > config/nl_afk.abr > config/pt.abr (not in jessie version) > config/tokconfig-de > config/tokconfig-en > config/tokconfig-es > config/tokconfig-fr > config/tokconfig-fy > config/tokconfig-it > config/tokconfig-nl > config/tokconfig-nl-sonarchat > config/tokconfig-nl-twitter > config/tokconfig-nl-withplaceholder(not in jessie version) > config/tokconfig-pt(not in jessie version) > config/tokconfig-ru(not in jessie version) > config/tokconfig-sv > config/tokconfig-tr(not in jessie version) > > The following remained in ucto
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Hi Andreas, Thanks for your elaborate response! It seems this has indeed opened quite a can of worms.. Here we go: Quoting Andreas Beckmann (2017-01-22 22:27:08) > TL;DR: You have an ambitious task before you. So I see... > Let me see if I understand what's going on. > > Renaming conffiles and changing the owning package at the same time is a > PITA. > You add an extra point by making the old name a symlink to the new one, > owned by the new package > > In jessie, everything in /etc/ucto was owned by ucto. > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata > or libucto2, a m-a:same library package. These come from 2 different > source packages. Indeed.. > Yuck. While putting conffiles in m-a:same packages is allowed, I highly > discourage this. Even if I haven't seen this fail once, yet. I'm just > afraid, someone has to clean up a mess caused by this at some point in > the future. and I'm afraid, I won't keep my fingers out of then :-( Ok, we'll come back to this in your later suggestion to move the conffiles to a new package. > Before we start: Are these really conffiles? Supposed to be modified by > the local admin? Or are these rather data files that are not supposed to > be updated locally? And would better live in /usr/share in that case? You have a point there; the user MAY add a new configuration or modify an existing one, but it is indeed not something that NEEDS to be modified to run. You may be right that /usr/share might be better here. I'd have to discuss with the main upstream developer, but I think we're not opposed to such 'radical' solutions if that solves the packaging problems and makes more semantic sense anyway. What do you think is best for the short term to get this fixed before the freeze? > And nearly everything from jessie's /etc/ucto content is now renamed and > a symlink. > Can't you just fork the project? I'd suggest 'hpgb' and then use > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new > source packages ... > > Oh yeah, it well be a mess. But we will do it right. Including making > dpkg forget about the old conffiles. > > Right now, all upgrade attempts from jessie to stretch should always > have failed, so there is no further messed up state inbetween that > should be supported for clean upgrades. Right > can we move the conffiles from libucto2 to a new package, e.g. > ucto-common (which would be either m-a:foreign or m-a:allowed, but I > always mess up these two, I need to look up what's right? Okay, that sounds good to me, if there's no objection to having yet another package. > * Which version introduced the new layout? > * can you give me a list of > + removed conffiles > + renamed conffiles (old name, new name, new owning package, whether > they have a compat symlink, did the content change between jessie and sid) ucto 0.9.2 introduced the split into uctodata. The jessie version is very old: 0.5.3-3.1 The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata package: config/es.abr config/exotic-eos.eos config/exotic-quotes.quote config/ligatures.filter config/nl_afk.abr config/pt.abr (not in jessie version) config/tokconfig-de config/tokconfig-en config/tokconfig-es config/tokconfig-fr config/tokconfig-fy config/tokconfig-it config/tokconfig-nl config/tokconfig-nl-sonarchat config/tokconfig-nl-twitter config/tokconfig-nl-withplaceholder(not in jessie version) config/tokconfig-pt(not in jessie version) config/tokconfig-ru(not in jessie version) config/tokconfig-sv config/tokconfig-tr(not in jessie version) The following remained in ucto 0.9.2 (libucto2) config/e-mail.rule config/smiley.rule config/url.rule config/standard-eos.eos(not in jessie version) config/standard-quotes.quote (not in jessie version) config/tokconfig-generic (not in jessie version) The very latest uctodata 0.3.1-1 introduces the new naming scheme for the language codes: config/tokconfig-de -> config/tokconfig-deu config/tokconfig-en -> config/tokconfig-eng config/tokconfig-es -> config/tokconfig-spa config/tokconfig-fr -> config/tokconfig-fra config/tokconfig-fy -> config/tokconfig-fry config/tokconfig-it -> config/tokconfig-ita config/tokconfig-nl -> config/tokconfig-nld config/tokconfig-nl-sonarchat -> config/tokconfig-nld-sonarchat config/tokconfig-nl-twitter -> config/tokconfig-nld-twitter config/tokconfig-nl-withplaceholder(not in jessie version) -> config/tokconfig-nld-withplaceholder config/tokconfig-pt(not in jessie version) -> config/tokconfig-por config/tokconfig-ru(not in jessie version) -> config/tokconfig-rus config/tokconfig-tr(not in jessie version) -> config/tokconfig-tur config/tokconfig-sv -> config/tokconfig-swe At that point we decided to symlink from the old
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
On 2017-01-22 09:48, Adrian Bunk wrote: > es.abr was a conffile in the jessie ucto, that needs additional treatment. > > The solution might be using mv_conffile from dpkg-maintscript-helper(1) > in a .maintscript to move the conffile to the new name spa.abr and the > new package (es.abr is now a symlink), but Andreas should comment on > that since he knows this better. TL;DR: You have an ambitious task before you. Let me see if I understand what's going on. Renaming conffiles and changing the owning package at the same time is a PITA. You add an extra point by making the old name a symlink to the new one, owned by the new package In jessie, everything in /etc/ucto was owned by ucto. In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata or libucto2, a m-a:same library package. These come from 2 different source packages. Yuck. While putting conffiles in m-a:same packages is allowed, I highly discourage this. Even if I haven't seen this fail once, yet. I'm just afraid, someone has to clean up a mess caused by this at some point in the future. and I'm afraid, I won't keep my fingers out of then :-( Before we start: Are these really conffiles? Supposed to be modified by the local admin? Or are these rather data files that are not supposed to be updated locally? And would better live in /usr/share in that case? And nearly everything from jessie's /etc/ucto content is now renamed and a symlink. Can't you just fork the project? I'd suggest 'hpgb' and then use /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new source packages ... Oh yeah, it well be a mess. But we will do it right. Including making dpkg forget about the old conffiles. Right now, all upgrade attempts from jessie to stretch should always have failed, so there is no further messed up state inbetween that should be supported for clean upgrades. can we move the conffiles from libucto2 to a new package, e.g. ucto-common (which would be either m-a:foreign or m-a:allowed, but I always mess up these two, I need to look up what's right? * Which version introduced the new layout? * can you give me a list of + removed conffiles + renamed conffiles (old name, new name, new owning package, whether they have a compat symlink, did the content change between jessie and sid) Do you *really* need the compat symlinks? OK, packaging is in git. Need to check whether I have write permissions there ... rough plan: ucto uses d-m-h move-conffile (but provides no new version, so the old conffile should "disappear" and dpkg should forget about it. Maybe it's better to rm_conffile it instead. uctodata will probably need a Conflicts against ucto (<< current+fixed~) Andreas
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Adding Andreas, the BTS does not Cc the submitter on messages. On Mon, Jan 16, 2017 at 08:17:03PM +0100, Maarten van Gompel wrote: > Quoting Andreas Beckmann (2017-01-16 17:24:19) > > Followup-For: Bug #838112 > > Control: found -1 0.3.1-1 > > Control: affects -1 + ucto > > > > that bug has just reappered: > > > > Preparing to unpack .../ucto_0.9.5-1_amd64.deb ... > > Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ... > > dpkg: warning: unable to delete old directory '/etc/ucto': Directory not > > empty > > Selecting previously unselected package uctodata. > > Preparing to unpack .../uctodata_0.3.1-1_all.deb ... > > Unpacking uctodata (0.3.1-1) ... > > dpkg: error processing archive > > /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack): > >trying to overwrite '/etc/ucto/es.abr', which is also in package ucto > > 0.9.5-1 > > > > > > Andreas > > Hi, > > Thanks for the notification. It seems this bug is a persistent one and I > don't really get why it's > resurfacing; I'm probably missing something so CC'ing the debian-science list > for help. Ucto 0.9.5 no longer has the > mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then > moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 > (package libucto2 actually), > states: > > Replaces: ucto (<< 0.5.5-1) > Breaks: ucto (<< 0.5.5-1) > > Uctodata also states: > > Replaces: ucto (<< 0.9.2-1) > Breaks: ucto (<< 0.9.2-1 > > But as this resurfaced, it's apparently not enough, What am I missing here? es.abr was a conffile in the jessie ucto, that needs additional treatment. The solution might be using mv_conffile from dpkg-maintscript-helper(1) in a .maintscript to move the conffile to the new name spa.abr and the new package (es.abr is now a symlink), but Andreas should comment on that since he knows this better. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Quoting Andreas Beckmann (2017-01-16 17:24:19) > Followup-For: Bug #838112 > Control: found -1 0.3.1-1 > Control: affects -1 + ucto > > that bug has just reappered: > > Preparing to unpack .../ucto_0.9.5-1_amd64.deb ... > Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ... > dpkg: warning: unable to delete old directory '/etc/ucto': Directory not > empty > Selecting previously unselected package uctodata. > Preparing to unpack .../uctodata_0.3.1-1_all.deb ... > Unpacking uctodata (0.3.1-1) ... > dpkg: error processing archive > /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack): >trying to overwrite '/etc/ucto/es.abr', which is also in package ucto > 0.9.5-1 > > > Andreas Hi, Thanks for the notification. It seems this bug is a persistent one and I don't really get why it's resurfacing; I'm probably missing something so CC'ing the debian-science list for help. Ucto 0.9.5 no longer has the mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 (package libucto2 actually), states: Replaces: ucto (<< 0.5.5-1) Breaks: ucto (<< 0.5.5-1) Uctodata also states: Replaces: ucto (<< 0.9.2-1) Breaks: ucto (<< 0.9.2-1 But as this resurfaced, it's apparently not enough, What am I missing here? Regards, -- Maarten van Gompel Centre for Language Studies Radboud Universiteit Nijmegen proy...@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon GnuPG key: 0x1A31555C XMPP: proy...@anaproy.nl Matrix: @proycon:anaproy.nl Telegram: proycon IRC: proycon (freenode) Twitter:https://twitter.com/proycon ORCIRD: https://orcid.org/-0002-1046-0006 Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Followup-For: Bug #838112 Control: found -1 0.3.1-1 Control: affects -1 + ucto Hi, that bug has just reappered: Preparing to unpack .../ucto_0.9.5-1_amd64.deb ... Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ... dpkg: warning: unable to delete old directory '/etc/ucto': Directory not empty Selecting previously unselected package uctodata. Preparing to unpack .../uctodata_0.3.1-1_all.deb ... Unpacking uctodata (0.3.1-1) ... dpkg: error processing archive /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack): trying to overwrite '/etc/ucto/es.abr', which is also in package ucto 0.9.5-1 Andreas ucto_0.9.5-1.log.gz Description: application/gzip
Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr
Package: uctodata Version: 0.1.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'jessie'. It installed fine in 'jessie', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces >From the attached log (scroll to the bottom...): Selecting previously unselected package uctodata. Preparing to unpack .../uctodata_0.1.1-1_all.deb ... Unpacking uctodata (0.1.1-1) ... dpkg: error processing archive /var/cache/apt/archives/uctodata_0.1.1-1_all.deb (--unpack): trying to overwrite '/etc/ucto/es.abr', which is also in package ucto 0.5.3-3.1+b1 Errors were encountered while processing: /var/cache/apt/archives/uctodata_0.1.1-1_all.deb cheers, Andreas ucto=0.5.3-3.1+b1_uctodata=0.1.1-1.log.gz Description: application/gzip
