Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Thorsten,
On Wed, Feb 01, 2023 at 04:03:12PM +, Thorsten Glaser wrote:
> Helge Kreutzmann dixit:
>
> >> >odler than stable. It also shipped them in every backport until
> >> >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
> >> >
> >> >But I wonder if I should remove them there.
> >>
> >> Yes, please. Otherwise it’s impossible to do the package
>
> >Done in the upcoming 4.17.0-2~bpo11+1.
> >
> >For the three languages where we have a conflict, namely, de, fr and
> >uk.
>
> Okay. So, assuming no newer version of manpages-{de,fr,uk} will
> bring them in, in either bpo or bookworm/sid, xz-utils now needs
> Replaces+Breaks on manpages-{de,fr,uk} (<< 4.17.0-2~bpo11+1) in sid.
> (Also assuming 4.17.0-2 does not have them.)
>
> That is, from the xz-utils PoV 4.17.0-2~bpo11+1 and 4.17.0-2
> are the first “fixed” (as in, don’t ship conflicting files)
> versions and all later ones will not “regress”.
The removal is intended to stay in the package.
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit:
>> >odler than stable. It also shipped them in every backport until
>> >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
>> >
>> >But I wonder if I should remove them there.
>>
>> Yes, please. Otherwise it’s impossible to do the package
>Done in the upcoming 4.17.0-2~bpo11+1.
>
>For the three languages where we have a conflict, namely, de, fr and
>uk.
Okay. So, assuming no newer version of manpages-{de,fr,uk} will
bring them in, in either bpo or bookworm/sid, xz-utils now needs
Replaces+Breaks on manpages-{de,fr,uk} (<< 4.17.0-2~bpo11+1) in sid.
(Also assuming 4.17.0-2 does not have them.)
That is, from the xz-utils PoV 4.17.0-2~bpo11+1 and 4.17.0-2
are the first “fixed” (as in, don’t ship conflicting files)
versions and all later ones will not “regress”.
bye,
//mirabilos
--
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Thorsten, On Wed, Feb 01, 2023 at 03:11:19PM +, Thorsten Glaser wrote: > Helge Kreutzmann dixit: > > >odler than stable. It also shipped them in every backport until > >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. > > > >But I wonder if I should remove them there. > > Yes, please. Otherwise it’s impossible to do the package > relationships right. This will leave users of xz-utils from > stable with manpages-fr from backports without french xz > manpages, but it’s the only way to do this that doesn’t > cause worse trouble elsewhere. Done in the upcoming 4.17.0-2~bpo11+1. For the three languages where we have a conflict, namely, de, fr and uk. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit: >odler than stable. It also shipped them in every backport until >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. > >But I wonder if I should remove them there. Yes, please. Otherwise it’s impossible to do the package relationships right. This will leave users of xz-utils from stable with manpages-fr from backports without french xz manpages, but it’s the only way to do this that doesn’t cause worse trouble elsewhere. Otherwise, xz-utils will have to add a conflict with 4.17.0-2 *in bookworm/sid*, and that will also carry to the next xz-utils backport (if any) *and* it’ll require an xz-utils upload *in bookworm/sid* for every manpages-fr upload to bpo. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Sebastian, lets clarify the facts: Xz-utils ships the localized manpages since 5.2.7. I do not see any backport yet, I assume it will be 5.4.1-0.0~bpo11+1 manpages-l10n shipped the localized manpages before 4.1.0-1. This is odler than stable. It also shipped them in every backport until 4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. But I wonder if I should remove them there. Please tell me, which languages you (intend to) ship in the backport. On Tue, Jan 31, 2023 at 09:50:20AM +, Thorsten Glaser wrote: > Sebastian Andrzej Siewior dixit: > > >It is bpo but if you look I'd you look at the files for the same > >version in bpo and sid you will see that sid skipped a few man pages > >while bpo created them. > > Ouch! > > That adds to the problems, of course. That makes fully resolving > this in all possible combinations a nightmare. > > In general, these have to go: Let's try: > stable → next-stable No problem, manpages-l10n never shipped it in stable and next-stable. > stable → stable+backports I assume if I *remove* the xz manpages for 4.17.0-2~bpo11+1, then users upgrading manpages-l10n and/or xz-utils get the translations from xz-utils (no longer from manpages-l10n). I keep the conflict, in case they take xz-utils with manpages-l10n 4.16.0-3~bpo11+1 installed. > stable+backports → next-stable The conflict in manpages-l10n backports ensures that it is not co-installed with xz-utils in next-stable. > stable+backports → stable+backports+backports-sloppy I don't know "stable+backports+backports-sloppy" and I never uploaded to -sloppy. > stable+backports+backports-sloppy → next-stable+backports Dito. > stable → testing (at any point) No problem, manpages-l10n never shipped the localizied man-pages in stable. > stable → unstable (at any point) The same. > testing → testing (at any point) The same. > testing → unstable (at any point) The same. > unstable → unstable (at any point) The same. > testing (at any point) → next-stable The same. > stable+backports → testing (at any point) The conflict in the upcoming manpages-l10n 4.17.0-2~bpo11+1 should ensure this. > stable+backports → unstable (at any point) The same. > In addition, partial upgrades that do not span more than a release > either way need to work (so you could have, say, manpages-fr from > buster and xz-utils from sid(before the bookworm release), or vice > versa, on one single bullseye system). I think these are covered in your considerations above. > Explicit Depends are needed to make all these either work or the > package manager not consider them (which forces upgrading a part > of the system to match). In addition, Build-Depends need versioning > unless present in stable, better oldstable, because buildds are not > required to upgrade (only update) before a run, plus packages can be > lagging on some architectures. I don't see any depends involved here, Replaces/Breaks and conflicts should suffice. There should not be any problems with build-depends. > Now backports take from testing at the point of backporting. > If the backported packages significantly differ from the > package in testing, however, combinatory explosion, as the > above holds true for every single package… This is what we try to tame here, yes. And I hope we did it right. > In particular, I’ve personally held back from backporting > packages when I know I had versioned constraints on the > package in question but backporting would require bringing > the old behaviour back (i.e. the backported package needs > to behave like the new one, not the old one, and if that’s > not possible in the old distro, then don’t package it). Translations need to mirror the english content. If that evolves in backports, then so do need the translations. > I see why this would be a problem for manpages… but you > cannot re-enable manpages in bpo that aren’t in testing > meaningfully when there’s also a backport of the package > from testing that includes the manpage (and you cannot > meaningfully drop the manpage from the backport because > then the package relationships aren’t possible any more). Yes, this is the first time a translation moved packages *and* there was a backport of said package (here: xz-utils). > Good luck, Thanks Greetings -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >It is bpo but if you look I'd you look at the files for the same >version in bpo and sid you will see that sid skipped a few man pages >while bpo created them. Ouch! That adds to the problems, of course. That makes fully resolving this in all possible combinations a nightmare. In general, these have to go: stable → next-stable stable → stable+backports stable+backports → next-stable stable+backports → stable+backports+backports-sloppy stable+backports+backports-sloppy → next-stable+backports stable → testing (at any point) stable → unstable (at any point) testing → testing (at any point) testing → unstable (at any point) unstable → unstable (at any point) testing (at any point) → next-stable stable+backports → testing (at any point) stable+backports → unstable (at any point) In addition, partial upgrades that do not span more than a release either way need to work (so you could have, say, manpages-fr from buster and xz-utils from sid(before the bookworm release), or vice versa, on one single bullseye system). Explicit Depends are needed to make all these either work or the package manager not consider them (which forces upgrading a part of the system to match). In addition, Build-Depends need versioning unless present in stable, better oldstable, because buildds are not required to upgrade (only update) before a run, plus packages can be lagging on some architectures. Now backports take from testing at the point of backporting. If the backported packages significantly differ from the package in testing, however, combinatory explosion, as the above holds true for every single package… In particular, I’ve personally held back from backporting packages when I know I had versioned constraints on the package in question but backporting would require bringing the old behaviour back (i.e. the backported package needs to behave like the new one, not the old one, and if that’s not possible in the old distro, then don’t package it). I see why this would be a problem for manpages… but you cannot re-enable manpages in bpo that aren’t in testing meaningfully when there’s also a backport of the package from testing that includes the manpage (and you cannot meaningfully drop the manpage from the backport because then the package relationships aren’t possible any more). Good luck, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 31 January 2023 08:00:23 UTC, Thorsten Glaser wrote: >Sebastian Andrzej Siewior dixit: > >>Then I will update the versions as suggested. My understanding was the >>problem persists because the bpo version was not yet updated. The >>version in sid did not ship the man-pages. > >The bpo version was once in both sid and testing and this >is therefore a problem for people updating incrementally. It is bpo but if you look I'd you look at the files for the same version in bpo and sid you will see that sid skipped a few man pages while bpo created them. > >bye, >//mirabilos -- Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >Then I will update the versions as suggested. My understanding was the >problem persists because the bpo version was not yet updated. The >version in sid did not ship the man-pages. The bpo version was once in both sid and testing and this is therefore a problem for people updating incrementally. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 21:57:28 [+], Thorsten Glaser wrote: > Sebastian Andrzej Siewior dixit: > > >Okay. So I do nothing and just wait for the bpo package to appear which > >will then solve the problem? > > No, you must fix the problem in xz-utils in bookworm/sid as well. > It also exists outside of backports. Then I will update the versions as suggested. My understanding was the problem persists because the bpo version was not yet updated. The version in sid did not ship the man-pages. > bye, > //mirabilos Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >Okay. So I do nothing and just wait for the bpo package to appear which >will then solve the problem? No, you must fix the problem in xz-utils in bookworm/sid as well. It also exists outside of backports. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit: >The problem is that we both upload (conflicting) packages to >backports. I'm not sure a good solution exists here. No, you need to fix the package relationships for incremental and partial upgrades in sid anyway. As far as I can tell, manpages-fr had the first version of xz-utils that ships the pages in its Breaks+Replaces, but xz-utils’ Breaks+Replaces did not cover all versions of manpages-fr that also shipped the pages. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 21:51:11 [+0100], Helge Kreutzmann wrote: > Hello Sebastian, Hi Helge, > On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote: > > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > > > reopen 1028375 > > > found 1028375 5.4.1-0.0 > > > thanks > > > > > > Patrice Duroux dixit: > > > > > > >Was this supposed to be closed? Or will it be with another manpages-fr > > > >bpo? > > So far the manpages-fr bpo has not yet happend. My sponsor intends to > upload it today and then we need to wait for NEW processing. okay. > > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > > > so the upload did not fix the problem. > > > > > > As far as I can tell it must be (<< 4.17.0-1~) instead. > > > (Also do note the tilde, it breaks bpo otherwise.) > > > > Okay. So I add this new suggested version and close 1028375? > > The problem is that we both upload (conflicting) packages to > backports. I'm not sure a good solution exists here. > > If the freeze continues for quite some time, even 4.18.0-1~ might hit > backports. (In the last freeze it was the case.). > > This is rather tricky. Okay. So I do nothing and just wait for the bpo package to appear which will then solve the problem? > Greetings > > Helge Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Sebastian, On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > > reopen 1028375 > > found 1028375 5.4.1-0.0 > > thanks > > > > Patrice Duroux dixit: > > > > >Was this supposed to be closed? Or will it be with another manpages-fr bpo? So far the manpages-fr bpo has not yet happend. My sponsor intends to upload it today and then we need to wait for NEW processing. > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > > so the upload did not fix the problem. > > > > As far as I can tell it must be (<< 4.17.0-1~) instead. > > (Also do note the tilde, it breaks bpo otherwise.) > > Okay. So I add this new suggested version and close 1028375? The problem is that we both upload (conflicting) packages to backports. I'm not sure a good solution exists here. If the freeze continues for quite some time, even 4.18.0-1~ might hit backports. (In the last freeze it was the case.). This is rather tricky. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >> As far as I can tell it must be (<< 4.17.0-1~) instead. >> (Also do note the tilde, it breaks bpo otherwise.) > >Okay. So I add this new suggested version and close 1028375? I think so. 4.17.0-1 was the first version of -fr to not ship it any more (from reading its changelog), and the tilde is to permit 4.17.0-1~bpo* to match. It’d need to update both Breaks and Replaces. (I hope I got this right, too ☺) bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > reopen 1028375 > found 1028375 5.4.1-0.0 > thanks > > Patrice Duroux dixit: > > >Was this supposed to be closed? Or will it be with another manpages-fr bpo? > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > so the upload did not fix the problem. > > As far as I can tell it must be (<< 4.17.0-1~) instead. > (Also do note the tilde, it breaks bpo otherwise.) Okay. So I add this new suggested version and close 1028375? > bye, > //mirabilos Sebastian
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
reopen 1028375 found 1028375 5.4.1-0.0 thanks Patrice Duroux dixit: >Was this supposed to be closed? Or will it be with another manpages-fr bpo? 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) so the upload did not fix the problem. As far as I can tell it must be (<< 4.17.0-1~) instead. (Also do note the tilde, it breaks bpo otherwise.) This is not only needed for bpo but also for incremental updates within sid. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hi, During an upgrade from Bullseye with some bpo packages to Testing/Bookworm, I faced the following issue: Dépaquetage de xz-utils (5.4.1-0.0) sur (5.2.5-2.1~deb11u1) ... dpkg: erreur de traitement de l'archive /tmp/apt-dpkg-install-IJKguW/37-xz-utils_5.4.1-0.0_amd64.deb (--unpack) : tentative de remplacement de « /usr/share/man/fr/man1/xz.1.gz », qui appartient aussi au paquet manpages-fr 4.16.0-3~bpo11+1 (sorry for the French output) Was this supposed to be closed? Or will it be with another manpages-fr bpo? Thanks, Patrice
