Bug#917788: libmedc11: Overwrites a file from libmedc1v5
Control: close -1 4.0.0+repack-5 On Sun, Jan 06, 2019 at 09:29:30AM +0200, Adrian Bunk wrote: > On Sat, Jan 05, 2019 at 11:10:52PM +0100, Mattia Rizzolo wrote: > > On Sat, Jan 05, 2019 at 09:53:13PM +0100, Gilles Filippini wrote: > >... > > > > Incidentally, I think that would also cover the just openend #918372, > > > > as with a Conflicts the libgmsh3 package from testing woudln't be > > > > installable, so it would force an upgrade to the version in unstable, > > > > making the test pass. > > > > > > Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 > > > from the broken med-fichier 4.0.0+repack-1 are still present into > > > unstable. Is there a way to have them removed? > > > > He also said this. > > However, I think that -generally, at least- the presence of cruft > > packages in the archive should not be an excuse, and upgrades like the > > one debci is trying to emulate should just work. > >... > > The problem is not the presence of a cruft package in general. > > The problem is that there was one completely broken version of > a package, that was fixed by removing/renaming this package. > > debci is trying to install a known-broken cruft package > that will never migrate to testing (due to it being cruft). Oh, I see now indeed. I didn't completely notice the versions involved in that test. Indeed I see now it's picking up libmed1v5=4.0.0+repack-1 instead of the testing version which is what I'd expect… > The actual bug is that debci considers such cruft packages still part of > the source package, so the upgrade that is actually tested for gmsh is > to the known-broken old med-fichier 4.0.0+repack-1. Right. Sorry for making useless noise, I'm closing this bug again, and I'm keeping an eye out as well. Now that I looked deper I indeed expect to work out by itself once dak auto-decrufts libmed1v5 away (which should happen in the next few hours). -- 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#917788: libmedc11: Overwrites a file from libmedc1v5
On Sat, 5 Jan 2019 22:11:44 +0100 pini wrote: > On Sat, 5 Jan 2019 21:53:13 +0100 Gilles Filippini wrote: > Oh, looking at cruft-report [1] I see that syrthes-tools still dépends on > libmedc1v5, preventing the removal : > * source package med-fichier version 4.0.0+repack-6 no longer builds > binary package(s): libmed1v5 libmedc1v5 > on amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x > - suggested command: > dak rm -m "[auto-cruft] NBS (no longer built by med-fichier)" -s unstable > -a amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x > -p -R -b libmed1v5 libmedc1v5 > - broken Depends: > syrthes: syrthes-tools [amd64 arm64 armel armhf hurd-i386 i386 mips > mips64el mipsel ppc64el] > > [1] http://ftp-master.debian.org/cruft-report-daily.txt > > I'm going to fix that. I've uploaded a new release of the syrthes package. There shouldn't be any blocker left for these cruft packages removal. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#917788: libmedc11: Overwrites a file from libmedc1v5
On Sat, Jan 05, 2019 at 11:10:52PM +0100, Mattia Rizzolo wrote: > On Sat, Jan 05, 2019 at 09:53:13PM +0100, Gilles Filippini wrote: >... > > > Incidentally, I think that would also cover the just openend #918372, > > > as with a Conflicts the libgmsh3 package from testing woudln't be > > > installable, so it would force an upgrade to the version in unstable, > > > making the test pass. > > > > Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 > > from the broken med-fichier 4.0.0+repack-1 are still present into > > unstable. Is there a way to have them removed? > > He also said this. > However, I think that -generally, at least- the presence of cruft > packages in the archive should not be an excuse, and upgrades like the > one debci is trying to emulate should just work. >... The problem is not the presence of a cruft package in general. The problem is that there was one completely broken version of a package, that was fixed by removing/renaming this package. debci is trying to install a known-broken cruft package that will never migrate to testing (due to it being cruft). The actual bug is that debci considers such cruft packages still part of the source package, so the upgrade that is actually tested for gmsh is to the known-broken old med-fichier 4.0.0+repack-1. > regards, > Mattia Rizzolo 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#917788: libmedc11: Overwrites a file from libmedc1v5
On Sat, Jan 05, 2019 at 09:53:13PM +0100, Gilles Filippini wrote: > > > In this special case, you probably need to add > > > Breaks+Replaces: libmed1v5 (>= 4) > > > respectively > > > Breaks+Replaces: libmedc1v5 (>= 4) > > > since the versions before 4 should not have any file conflicts. > > > > Actually, I think Breaks+Replaces is wrong here. > > > > Breaks+Replaces allow for silent replacing of the old package, but here > > you need to forcefully remove it, which is what you'd use Conflicts for. > > As a data point, that what we usually use when renaming packages during > > ABI breaks like what has been done for #916881. > > I agree that Conflicts suits better regarding the need to forcibly > remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1). Apparently bunk disagrees with me and mentioned on IRC that it should be fine, and also: > > Incidentally, I think that would also cover the just openend #918372, > > as with a Conflicts the libgmsh3 package from testing woudln't be > > installable, so it would force an upgrade to the version in unstable, > > making the test pass. > > Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 > from the broken med-fichier 4.0.0+repack-1 are still present into > unstable. Is there a way to have them removed? He also said this. However, I think that -generally, at least- the presence of cruft packages in the archive should not be an excuse, and upgrades like the one debci is trying to emulate should just work. Anyway, please consider holding on any upload, I'll try to do a few update tests locally tomorrow afternoon (CET). (bunk, anbe: feel free to chime in here) -- 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#917788: libmedc11: Overwrites a file from libmedc1v5
On Sat, 5 Jan 2019 21:53:13 +0100 Gilles Filippini wrote: > On Sat, 5 Jan 2019 17:23:11 +0100 Mattia Rizzolo wrote: > > Control: reopen -1 > > > > On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote: > > > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki > > > wrote: > > > > I was just about to open a bug on this same issue. It's actually present > > > > in both libmed11 and libmedc11. Instead of Conflicts, they both need > > > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar > > > > > > In this special case, you probably need to add > > > Breaks+Replaces: libmed1v5 (>= 4) > > > respectively > > > Breaks+Replaces: libmedc1v5 (>= 4) > > > since the versions before 4 should not have any file conflicts. > > > > Actually, I think Breaks+Replaces is wrong here. > > > > Breaks+Replaces allow for silent replacing of the old package, but here > > you need to forcefully remove it, which is what you'd use Conflicts for. > > As a data point, that what we usually use when renaming packages during > > ABI breaks like what has been done for #916881. > > I agree that Conflicts suits better regarding the need to forcibly > remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1). > > > Incidentally, I think that would also cover the just openend #918372, > > as with a Conflicts the libgmsh3 package from testing woudln't be > > installable, so it would force an upgrade to the version in unstable, > > making the test pass. > > Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 > from the broken med-fichier 4.0.0+repack-1 are still present into > unstable. Is there a way to have them removed? Oh, looking at cruft-report [1] I see that syrthes-tools still dépends on libmedc1v5, preventing the removal : * source package med-fichier version 4.0.0+repack-6 no longer builds binary package(s): libmed1v5 libmedc1v5 on amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x - suggested command: dak rm -m "[auto-cruft] NBS (no longer built by med-fichier)" -s unstable -a amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x -p -R -b libmed1v5 libmedc1v5 - broken Depends: syrthes: syrthes-tools [amd64 arm64 armel armhf hurd-i386 i386 mips mips64el mipsel ppc64el] [1] http://ftp-master.debian.org/cruft-report-daily.txt I'm going to fix that. Thanks, _g.
Bug#917788: libmedc11: Overwrites a file from libmedc1v5
On Sat, 5 Jan 2019 17:23:11 +0100 Mattia Rizzolo wrote: > Control: reopen -1 > > On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote: > > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki wrote: > > > I was just about to open a bug on this same issue. It's actually present > > > in both libmed11 and libmedc11. Instead of Conflicts, they both need > > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar > > > > In this special case, you probably need to add > > Breaks+Replaces: libmed1v5 (>= 4) > > respectively > > Breaks+Replaces: libmedc1v5 (>= 4) > > since the versions before 4 should not have any file conflicts. > > Actually, I think Breaks+Replaces is wrong here. > > Breaks+Replaces allow for silent replacing of the old package, but here > you need to forcefully remove it, which is what you'd use Conflicts for. > As a data point, that what we usually use when renaming packages during > ABI breaks like what has been done for #916881. I agree that Conflicts suits better regarding the need to forcibly remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1). > Incidentally, I think that would also cover the just openend #918372, > as with a Conflicts the libgmsh3 package from testing woudln't be > installable, so it would force an upgrade to the version in unstable, > making the test pass. Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5 from the broken med-fichier 4.0.0+repack-1 are still present into unstable. Is there a way to have them removed? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#917788: libmedc11: Overwrites a file from libmedc1v5
Control: reopen -1 On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote: > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki wrote: > > I was just about to open a bug on this same issue. It's actually present > > in both libmed11 and libmedc11. Instead of Conflicts, they both need > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar > > In this special case, you probably need to add > Breaks+Replaces: libmed1v5 (>= 4) > respectively > Breaks+Replaces: libmedc1v5 (>= 4) > since the versions before 4 should not have any file conflicts. Actually, I think Breaks+Replaces is wrong here. Breaks+Replaces allow for silent replacing of the old package, but here you need to forcefully remove it, which is what you'd use Conflicts for. As a data point, that what we usually use when renaming packages during ABI breaks like what has been done for #916881. Incidentally, I think that would also cover the just openend #918372, as with a Conflicts the libgmsh3 package from testing woudln't be installable, so it would force an upgrade to the version in unstable, making the test pass. -- 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#917788: libmedc11: Overwrites a file from libmedc1v5
On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki wrote: > I was just about to open a bug on this same issue. It's actually present > in both libmed11 and libmedc11. Instead of Conflicts, they both need > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar In this special case, you probably need to add Breaks+Replaces: libmed1v5 (>= 4) respectively Breaks+Replaces: libmedc1v5 (>= 4) since the versions before 4 should not have any file conflicts. Andreas
Bug#917788: libmedc11: Overwrites a file from libmedc1v5
Hi Rock & Gilles,
On Sun, 30 Dec 2018 11:01:07 + Rock Storm wrote:
> Package: libmedc11
> Severity: grave
>
> Dear Maintainer,
>
> While trying to update freecad I run into the following broken apt
> state:
>
> Preparing to unpack .../libmedc11_4.0.0+repack-3_amd64.deb ...
> Unpacking libmedc11:amd64 (4.0.0+repack-3) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libmedc11_4.0.0+repack-3_amd64.deb (--unpack):
> trying to overwrite '/usr/lib/x86_64-linux-gnu/libmedC.so.11.0.0', which is
> also in package libmedc1v5:amd64 4.0.0+repack-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
> /var/cache/apt/archives/libmedc11_4.0.0+repack-3_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> I've followed the solution given in this post [1] to fix it. It is also
> suggested that a line such as 'Conflict: libmedc1v5' be added to the
> control file.
>
> [1]: https://askubuntu.com/a/433510
>
>
> Thanks a lot,
> Rock
>
I was just about to open a bug on this same issue. It's actually present
in both libmed11 and libmedc11. Instead of Conflicts, they both need
Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar
instance. One can replicate this behavior with:
sudo piuparts -a -d buster -d sid libmed{,c}-dev
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906110
Bug#917788: libmedc11: Overwrites a file from libmedc1v5
Package: libmedc11 Severity: grave Dear Maintainer, While trying to update freecad I run into the following broken apt state: Preparing to unpack .../libmedc11_4.0.0+repack-3_amd64.deb ... Unpacking libmedc11:amd64 (4.0.0+repack-3) ... dpkg: error processing archive /var/cache/apt/archives/libmedc11_4.0.0+repack-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libmedC.so.11.0.0', which is also in package libmedc1v5:amd64 4.0.0+repack-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libmedc11_4.0.0+repack-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) I've followed the solution given in this post [1] to fix it. It is also suggested that a line such as 'Conflict: libmedc1v5' be added to the control file. [1]: https://askubuntu.com/a/433510 Thanks a lot, Rock -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmedc11 depends on: ii libc62.28-3 ii libgcc1 1:8.2.0-13 iu libhdf5-openmpi-103 1.10.4+repack-4 ii libopenmpi3 3.1.3-6 ii libstdc++6 8.2.0-13 libmedc11 recommends no packages. Versions of packages libmedc11 suggests: pn libmed-doc pn libmed-tools -- Rock Storm GPG KeyID: 4096R/C96832FD GPG Fingerprint: C304 34B3 632C 464C 2FAF C741 0439 CF52 C968 32FD
