inn2 and sm both attempt to install /usr/share/man/man1/sm.1.gz. This
may result in an unpack error from dpkg.
mmdebstrap --verbose --variant=essential unstable /dev/null --include=inn2,sm
Preparing to unpack .../79-sm_0.29-1_amd64.deb ...
Unpacking sm (0.29-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb (--unpack):
trying to overwrite '/usr/share/man/man1/sm.1.gz', which is also in package inn2 (2.7.3~20250201-1)
Errors were encountered while processing:
/tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb
E: Sub-process env returned an error code (1)
Please figure out which of these should be the proper owner of this file
and reassign the bug to the other in a way that still associates it
correctly:
Control: reassign -1 $package1
Control: affects -1 + $package2
Helmut
On 23 March 2025 at 13:53, Helmut Grohne wrote: | Package: inn2,sm | Severity: serious | User: debian-qa@lists.debian.org | Usertags: fileconflict Maintainer of mistakenly addressed package here: for 'historical' reason, source package 'sm' is CRAN package 'r-cran-sm' as a binary. You likely mean source package 'screen-message' which produces binary 'sm'. Dirk | inn2 and sm both attempt to install /usr/share/man/man1/sm.1.gz. This | may result in an unpack error from dpkg. | | mmdebstrap --verbose --variant=essential unstable /dev/null --include=inn2,sm | | Preparing to unpack .../79-sm_0.29-1_amd64.deb ... | Unpacking sm (0.29-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb (--unpack): | trying to overwrite '/usr/share/man/man1/sm.1.gz', which is also in package inn2 (2.7.3~20250201-1) | Errors were encountered while processing: | /tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb | E: Sub-process env returned an error code (1) | | Please figure out which of these should be the proper owner of this file | and reassign the bug to the other in a way that still associates it | correctly: | | Control: reassign -1 $package1 | Control: affects -1 + $package2 | | Helmut
On 23 March 2025 at 13:53, Helmut Grohne wrote: | Package: inn2,sm | Severity: serious | User: debian-qa@lists.debian.org | Usertags: fileconflict Maintainer of mistakenly addressed package here: for 'historical' reason, source package 'sm' is CRAN package 'r-cran-sm' as a binary. You likely mean source package 'screen-message' which produces binary 'sm'. Dirk | inn2 and sm both attempt to install /usr/share/man/man1/sm.1.gz. This | may result in an unpack error from dpkg. | | mmdebstrap --verbose --variant=essential unstable /dev/null --include=inn2,sm | | Preparing to unpack .../79-sm_0.29-1_amd64.deb ... | Unpacking sm (0.29-1) ... | dpkg: error processing archive /tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb (--unpack): | trying to overwrite '/usr/share/man/man1/sm.1.gz', which is also in package inn2 (2.7.3~20250201-1) | Errors were encountered while processing: | /tmp/apt-dpkg-install-FgpAQz/79-sm_0.29-1_amd64.deb | E: Sub-process env returned an error code (1) | | Please figure out which of these should be the proper owner of this file | and reassign the bug to the other in a way that still associates it | correctly: | | Control: reassign -1 $package1 | Control: affects -1 + $package2 | | Helmut
Hi Dirk, I think this is a bug in debbugs here. "sm" should refer to the binary package and the binary package only. If I were to mean the source package, I'd have to say "src:sm" or "Source: sm". In any case, I concur that the problem exists between sm built from src:screen-message and inn2 built from src:inn2. Helmut
Hi Helmut, On 23 March 2025 at 19:57, Helmut Grohne wrote: | On Sun, Mar 23, 2025 at 11:03:07AM -0500, Dirk Eddelbuettel wrote: | > On 23 March 2025 at 13:53, Helmut Grohne wrote: | > | Package: inn2,sm | > | Severity: serious | > | User: debian-qa@lists.debian.org | > | Usertags: fileconflict | > | > Maintainer of mistakenly addressed package here: for 'historical' reason, | > source package 'sm' is CRAN package 'r-cran-sm' as a binary. You likely mean | > source package 'screen-message' which produces binary 'sm'. | | I think this is a bug in debbugs here. "sm" should refer to the binary | package and the binary package only. If I were to mean the source | package, I'd have to say "src:sm" or "Source: sm". Yes, I see your point here. It's also a minor bug in my package I should clean up 'eventually'. | In any case, I concur that the problem exists between sm built from | src:screen-message and inn2 built from src:inn2. Can you reassign accordingly? Tschoe, Dirk
From my pov, it is correctly assigned. The problem is with the binary packages sm and inn2, not with the corresponding source packages. The next step for reassignment is figuring out which package should properly own the manual page and the command name. Helmut
On 23 March 2025 at 21:42, Helmut Grohne wrote: | On Sun, Mar 23, 2025 at 02:28:48PM -0500, Dirk Eddelbuettel wrote: | > | In any case, I concur that the problem exists between sm built from | > | src:screen-message and inn2 built from src:inn2. | > | > Can you reassign accordingly? | | >From my pov, it is correctly assigned. The problem is with the binary | packages sm and inn2, not with the corresponding source packages. The | next step for reassignment is figuring out which package should properly | own the manual page and the command name. As you wish, but it strikes we as odd because - Your bug report went to the maintainer of package r-cran-sm (i.e., me). - Your bug report was about package sm (and another package). You wanted its maintainer (or their maintainers). Dirk
Control: clone -1 -2 Control: reassign -2 debbugs Control: retitle -2 debbugs incorrectly delivers mails for the sm binary package to the sm source package maintainer Control: affects -2 + src:sm I recognize that this happens, but I argue this is due to a bug in debbugs rather than being intended. Moreover, I agree with you that using having sm has two distinct maintainers (when interpreting as source and binary) is something that should be avoided by renaming either package. discovery tool would no longer recognize the bug as it were no longer affecting sm and as a result it would be filing a duplicate. The technically correct assignment is with sm even though it causes mails to reach an unintended destination. The next step in reassignment should be one of Control: reassign -1 sm Control: affects -1 + inn2 or Control: reassign -1 inn2 Control: affects -1 + sm at which point the bts hopefully stops delivering mails to src:sm by no longer triggering the faulty code path. Helmut