Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Wed, Apr 29, 22:05, Helmut Grohne wrote > > > 2. dh_installchangelogs does not compress changelogs. You additionally > > >need to run dh_compress. Running lintian would have told you. > > > > Sorry, my bad. The one-liner patch shown below should fix this. However, > > I'm not sure how to proceed from here, given that > > Yes, that patch looks correct. It's in master now. > > > 3. Adrian Bunk NMUed liblopsub. Your upload would revert changes from his > > >upload. Please acknowledge his NMU. If you intend to revert changes, > > >document it in debian/changelog. > > > > Looks like Adrian applied a patch which I proposed already in 2024^[1] but > > never ended up applying. So yes, I can ack his NMU, but I don't know what > > would be the best way to get this change into the repo. Should I split the > > patch into two, one for master that modifies version-gen.sh and one for the > > debian branch which adjusts debian/rules accordingly, then create 1.0.6-3? > > >From a Debian pov, your git tree is out-of-sync with Debian and the > version that is your head was never released. Whatever you do, ideally > your debian branch includes the NMU changes in its head commit. For > instance, you might add a branch importing the NMU and then merge that > branch manually resolving the inevitable debian/changelog conflict. > > To put it another way, building a source package from your git and then > comparing (debdiff) that package to the most recent upload should not > revert the NMU changes unless you explicitly want to revert them and > state so in a changelog entry. Here's what I did to address this: * Applied the old version-gen.sh patch to a temporary branch t/nmu. * Merged this branch into the debian branch, amending the merge commit to add the necessary changes to debian/rules and to resolve the debian/changelog conflict. Please have a look at the current pu branch (proposed updates) of the public repo. If everything looks good to you, I'll make these changes permanent by updating the non-rewinding master and debian branches accordingly. > That feels quite unrelated. To use the pipeline, you need to create a > salsa.debian.org account, create a (e.g. personal) repository to mirror > your repository and then configure the pipeline following > https://wiki.debian.org/SalsaCI. Whenever you consider releasing a > version (or more often), also push to salsa and look at the pipeline's > results. Doing so catches a lot of things that can go wrong before a > reviewer tells you. Thanks for the link. I've just applied for an salsa account. According to the FAQ, it will take a while to get it approved... Best Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Wed, Apr 29, 2026 at 07:13:24PM +0200, Andre Noll wrote: > I talked to my colleague who administers git.tuebingen.mpg.de, and he > activated some countermeasures to rule out the bots which caused this > slowness. Thank you. > > 2. dh_installchangelogs does not compress changelogs. You additionally > >need to run dh_compress. Running lintian would have told you. > > Sorry, my bad. The one-liner patch shown below should fix this. However, > I'm not sure how to proceed from here, given that Yes, that patch looks correct. > > 3. Adrian Bunk NMUed liblopsub. Your upload would revert changes from his > >upload. Please acknowledge his NMU. If you intend to revert changes, > >document it in debian/changelog. > > Looks like Adrian applied a patch which I proposed already in 2024^[1] but > never ended up applying. So yes, I can ack his NMU, but I don't know what > would be the best way to get this change into the repo. Should I split the > patch into two, one for master that modifies version-gen.sh and one for the > debian branch which adjusts debian/rules accordingly, then create 1.0.6-3? >From a Debian pov, your git tree is out-of-sync with Debian and the version that is your head was never released. Whatever you do, ideally your debian branch includes the NMU changes in its head commit. For instance, you might add a branch importing the NMU and then merge that branch manually resolving the inevitable debian/changelog conflict. To put it another way, building a source package from your git and then comparing (debdiff) that package to the most recent upload should not revert the NMU changes unless you explicitly want to revert them and state so in a changelog entry. > > Consider mirroring your git repository into salsa.debian.org. There you > > can enable the default salsa-ci pipeline. It can help you identify a lot > > of problems before it comes to sponsoring. > > Can you please point me to instructions for what I need to do to make this > happen? I found > > https://ruby-team.pages.debian.net/contributing/Starters_Guide_02.html > > but I'm not sure how up-to-date this is. That feels quite unrelated. To use the pipeline, you need to create a salsa.debian.org account, create a (e.g. personal) repository to mirror your repository and then configure the pipeline following https://wiki.debian.org/SalsaCI. Whenever you consider releasing a version (or more often), also push to salsa and look at the pipeline's results. Doing so catches a lot of things that can go wrong before a reviewer tells you. Hope this helps Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Fri, Apr 24, 08:09, Helmut Grohne wrote > I looked again and ran into three distinct problems. > > 1. The git server is incredibly slow. It timed out several times. This >is annoying, but not a show stopper. I talked to my colleague who administers git.tuebingen.mpg.de, and he activated some countermeasures to rule out the bots which caused this slowness. > 2. dh_installchangelogs does not compress changelogs. You additionally >need to run dh_compress. Running lintian would have told you. Sorry, my bad. The one-liner patch shown below should fix this. However, I'm not sure how to proceed from here, given that > 3. Adrian Bunk NMUed liblopsub. Your upload would revert changes from his >upload. Please acknowledge his NMU. If you intend to revert changes, >document it in debian/changelog. Looks like Adrian applied a patch which I proposed already in 2024^[1] but never ended up applying. So yes, I can ack his NMU, but I don't know what would be the best way to get this change into the repo. Should I split the patch into two, one for master that modifies version-gen.sh and one for the debian branch which adjusts debian/rules accordingly, then create 1.0.6-3? > Consider mirroring your git repository into salsa.debian.org. There you > can enable the default salsa-ci pipeline. It can help you identify a lot > of problems before it comes to sponsoring. Can you please point me to instructions for what I need to do to make this happen? I found https://ruby-team.pages.debian.net/contributing/Starters_Guide_02.html but I'm not sure how up-to-date this is. Thanks Andre [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086623 --- commit 06752e8fd1d0c0dea93e1d9675959404758b2fbe Author: Andre Noll Date: Wed Apr 29 18:04:58 2026 +0200 debian: Compress changelogs. Run dh_compress to do that. Fixes the following lintian errors: E: liblopsub-dev: changelog-file-not-compressed [usr/share/doc/liblopsub-dev/changelog.Debian] E: liblopsub1t64: changelog-file-not-compressed [usr/share/doc/liblopsub1t64/changelog.Debian] Suggested-by: Helmut Grohne diff --git a/debian/rules b/debian/rules index 1657fa8..7624646 100755 --- a/debian/rules +++ b/debian/rules @@ -55,6 +55,7 @@ binary: build $(INST_FILE) debian/copyright $(DOCS_DIR)/copyright $(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright dh_installchangelogs + dh_compress dh_fixperms dh_makeshlibs dh_shlibdeps -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, Please excuse my delay in response. On Mon, Mar 16, 2026 at 05:59:18PM +0100, Andre Noll wrote: > I've removed the two offending tags and applied the patch below. Hopefully, > that brings the package back to sanity. I confirm that the tags no longer prevent me from creating an orig.tar. sopv is still unhappy about the upstream signature. Tolerable. > The commit also adds the 1.0.6-2 entry, targeting unstable. Would you be > willing to sponsor the new version? I looked again and ran into three distinct problems. 1. The git server is incredibly slow. It timed out several times. This is annoying, but not a show stopper. 2. dh_installchangelogs does not compress changelogs. You additionally need to run dh_compress. Running lintian would have told you. 3. Adrian Bunk NMUed liblopsub. Your upload would revert changes from his upload. Please acknowledge his NMU. If you intend to revert changes, document it in debian/changelog. Consider mirroring your git repository into salsa.debian.org. There you can enable the default salsa-ci pipeline. It can help you identify a lot of problems before it comes to sponsoring. I consider items 2 and 3 blockers for sponsoring. Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Sun, Mar 22, 14:32, Andre Noll wrote > [Adding some more people to CC since Helmut seems to be offline or busy] > > On Mon, Mar 16, 17:59, Andre Noll wrote > > > > First of all, keep replying. Every reply resets the autoremoval timer. > > > > Done :) > > > > > Then an upload to unstable rather than experimental is needed. The > > > target suite is selected in the most recent debian/changelog entry. > > > > The commit also adds the 1.0.6-2 entry, targeting unstable. Would you be > > willing to sponsor the new version? > > Can somebody please upload this to unstable to prevent the package from > being removed? Ping? Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
[Adding some more people to CC since Helmut seems to be offline or busy] On Mon, Mar 16, 17:59, Andre Noll wrote > > First of all, keep replying. Every reply resets the autoremoval timer. > > Done :) > > > Then an upload to unstable rather than experimental is needed. The > > target suite is selected in the most recent debian/changelog entry. > > The commit also adds the 1.0.6-2 entry, targeting unstable. Would you be > willing to sponsor the new version? Can somebody please upload this to unstable to prevent the package from being removed? Thanks Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Tue, Mar 10, 23:11, Helmut Grohne wrote > On Tue, Mar 10, 2026 at 08:50:00PM +0100, Andre Noll wrote: > > Could be. All lopsub releases are named according to the scheme v$a.$b.$c, > > so replacing @ANY_VERSION@ with > > > > v[[:digit:]]+\.[[:digit:]]+\.[[:digit:]]+ > > > > should work (assuming uscan uses extended regular expressions). Do you want > > me to add a commit which makes this change? > > > > Alternatively, or in addition to that, I could simply remove the two tags > > which contain a dash (v1.0.5-2 and v1.0.6-1). > > Either should work, but the present state doesn't produce a working > source package. I've removed the two offending tags and applied the patch below. Hopefully, that brings the package back to sanity. > > Obviously I'd prefer to not see the package being removed. So what is the > > best way to accomplish this? > > First of all, keep replying. Every reply resets the autoremoval timer. Done :) > Then an upload to unstable rather than experimental is needed. The > target suite is selected in the most recent debian/changelog entry. The commit also adds the 1.0.6-2 entry, targeting unstable. Would you be willing to sponsor the new version? Thanks Andre --- commit f7b30dad8d74a678800fedae6f4da52a7bbcce13 Author: Andre Noll Date: Mon Mar 16 17:22:27 2026 +0100 debian: Use custom regex in watch file. This works around the problem that there existed tags containing a dash character, which confused dpkg-source. These tags have been removed by now, but it is probably a good idea to use a regular expression which is tailored to the upstream naming convention of lopsub. That is, all version strings follow the scheme v$a.$b.$c where a, b and c are decimal numbers. There will be no alpha, beta, pre, rc, whatever. Suggested-by: Helmut Grohne diff --git a/debian/changelog b/debian/changelog index 7c92adb..1ed7ba2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +liblopsub (1.0.6-2) unstable; urgency=medium + + * Use custom regex in watch file + + -- Andre Noll Mon, 16 Mar 2026 17:21:53 +0100 + liblopsub (1.0.6-1) experimental; urgency=medium * Use dh_installchangelogs. Closes: #1126662 diff --git a/debian/watch b/debian/watch index 94ee548..f03e005 100644 --- a/debian/watch +++ b/debian/watch @@ -1,5 +1,5 @@ version=4 opts="mode=git, gitmode=full, pgpmode=gittag" \ https://git.tuebingen.mpg.de/lopsub/ \ - refs/tags/v@ANY_VERSION@ + refs/tags/v([[:digit:]]+\.[[:digit:]]+\.[[:digit:]]) -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Tue, Mar 10, 2026 at 08:50:00PM +0100, Andre Noll wrote: > Could be. All lopsub releases are named according to the scheme v$a.$b.$c, > so replacing @ANY_VERSION@ with > > v[[:digit:]]+\.[[:digit:]]+\.[[:digit:]]+ > > should work (assuming uscan uses extended regular expressions). Do you want > me to add a commit which makes this change? > > Alternatively, or in addition to that, I could simply remove the two tags > which contain a dash (v1.0.5-2 and v1.0.6-1). Either should work, but the present state doesn't produce a working source package. > Obviously I'd prefer to not see the package being removed. So what is the > best way to accomplish this? First of all, keep replying. Every reply resets the autoremoval timer. Then an upload to unstable rather than experimental is needed. The target suite is selected in the most recent debian/changelog entry. Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Sun, Mar 08, 21:57, Helmut Grohne wrote > On Sun, Mar 08, 2026 at 04:20:49PM +0100, Andre Noll wrote: > > Sorry about that. I've now added a fixup commit that adds the space. The > > tip of the updated branch is > > > > 11f06a85b699251b6ef9ecdd87c85503e007fcd4 > > Thank you. > > > > Beyond that, this is uploading a new upstream release. I attempted > > > fetching it via uscan and uscan failed verifying the expected upstream > > > signature. > > > > Hm, works for me. Does the signature of this email verify? > > Yes and the question is pointing at the root cause. I use mutt and mutt > tends to integrate with gnupg. The signature does verify there. uscan > prefers sqop over a gnupg-based implementation. The thing that refuses > your signature is sqop. I'm not sure what exactly is being rejected > here, but one of being a DSA key 1024bits or SHA1 being used probably is > the cause. Sigh. This key is rather old, and 1024 bits was considered more than enough back when the key was created. All signed tags of all my projects use this key, so it's not easy to switch to a newer key. Add to this that the keyserver situation is a bit flaky, to put it mildly. > I was able to make it use gnupg and then uscan succeeds, but then > dpkg-source fails. The upstream version discovered by uscan is 1.0.6-1. > Since the package is non-native, the corresponding Debian version should > be 1.0.6-1-1. Now building the source package attempts to locate an > orig.tar for 1.0.6, but that does not exist. I also tried > > uscan --download-version 1.0.6 > > but that still downloads 1.0.6-1. So this doesn't quite work out. Could > it be that @ANY_VERSION@ is not what we want here and instead skipping > versions with a dash would be better? Could be. All lopsub releases are named according to the scheme v$a.$b.$c, so replacing @ANY_VERSION@ with v[[:digit:]]+\.[[:digit:]]+\.[[:digit:]]+ should work (assuming uscan uses extended regular expressions). Do you want me to add a commit which makes this change? Alternatively, or in addition to that, I could simply remove the two tags which contain a dash (v1.0.5-2 and v1.0.6-1). > It is a bit sad that our tooling insists on the presence of an orig.tar > when all we need here is git. The upstream git history is part of the > Debian git history and there are no patches at all. This should have > been simple but it sadly is not. (Not you to blame.) I couldn't agree more. Quoting Ian Jackson^[1]: > 1. All examination and edits to the source should be performed via > normal git operations. > 2. Source code should be transferred and exchanged as git data, not > tarballs. git should be the canonical form everywhere. > 3. Upstream git histories should be re-published, traceably, as part > of formal git releases published by Debian. > 4. No-one should have to learn about Debian Source Packages, which > are bizarre, and have been obsoleted by modern version control. But we're not yet there, unfortunately. Not you to blame ;) > > I was unable to produce a .debdiff that consisted only of the change > > introduced > > by commit c0cf8e24b72effbe53c7dd840ead5130b87151d9 that fixed the RC bug. > > What > > would be a suitable debdiff command to achieve that? > > I'd normally say that a .debdiff is the output of the debdiff tool when > pointed at two source packages (.dsc). However, this is all git, there > is little benefit of turning two git commits into source packages just > to diff them. Diffing the commits should produce the same thing. Indeed, > the diff 52cbfcd021b7..11f06a85b699 looks very reasonable for sponsoring > to me. I note that this still goes to experimental and thus it will not > prevent your package from being autoremoved. Don't you want this > uploaded to unstable? Obviously I'd prefer to not see the package being removed. So what is the best way to accomplish this? Thanks Andre [1] https://diziet.dreamwidth.org/20436.html -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Sun, Mar 08, 2026 at 04:20:49PM +0100, Andre Noll wrote: > Sorry about that. I've now added a fixup commit that adds the space. The > tip of the updated branch is > > 11f06a85b699251b6ef9ecdd87c85503e007fcd4 Thank you. > > Beyond that, this is uploading a new upstream release. I attempted > > fetching it via uscan and uscan failed verifying the expected upstream > > signature. > > Hm, works for me. Does the signature of this email verify? Yes and the question is pointing at the root cause. I use mutt and mutt tends to integrate with gnupg. The signature does verify there. uscan prefers sqop over a gnupg-based implementation. The thing that refuses your signature is sqop. I'm not sure what exactly is being rejected here, but one of being a DSA key 1024bits or SHA1 being used probably is the cause. I was able to make it use gnupg and then uscan succeeds, but then dpkg-source fails. The upstream version discovered by uscan is 1.0.6-1. Since the package is non-native, the corresponding Debian version should be 1.0.6-1-1. Now building the source package attempts to locate an orig.tar for 1.0.6, but that does not exist. I also tried uscan --download-version 1.0.6 but that still downloads 1.0.6-1. So this doesn't quite work out. Could it be that @ANY_VERSION@ is not what we want here and instead skipping versions with a dash would be better? It is a bit sad that our tooling insists on the presence of an orig.tar when all we need here is git. The upstream git history is part of the Debian git history and there are no patches at all. This should have been simple but it sadly is not. (Not you to blame.) > I was unable to produce a .debdiff that consisted only of the change > introduced > by commit c0cf8e24b72effbe53c7dd840ead5130b87151d9 that fixed the RC bug. What > would be a suitable debdiff command to achieve that? I'd normally say that a .debdiff is the output of the debdiff tool when pointed at two source packages (.dsc). However, this is all git, there is little benefit of turning two git commits into source packages just to diff them. Diffing the commits should produce the same thing. Indeed, the diff 52cbfcd021b7..11f06a85b699 looks very reasonable for sponsoring to me. I note that this still goes to experimental and thus it will not prevent your package from being autoremoved. Don't you want this uploaded to unstable? So the only thing that prevents me from sponsoring this is that I fail to construct the intended source package with the present tooling. (Not you to blame.) Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Tue, Mar 03, 08:21, Helmut Grohne wrote > On Mon, Mar 02, 2026 at 09:29:58PM +0100, Andre Noll wrote: > > Yes, please upload the version I've just tagged as v1.0.6-1. The > > ID of the git commit is cd596839f6d8147ac7464fddad88d0987c728e02. > > Signing a the git commit id in the mail is fine to me. > > Unfortunately, the commit does not seem very well tested. The format of > debian/changelog is rejected by dpkg-source. A space is missing. Sorry about that. I've now added a fixup commit that adds the space. The tip of the updated branch is 11f06a85b699251b6ef9ecdd87c85503e007fcd4 > Beyond that, this is uploading a new upstream release. I attempted > fetching it via uscan and uscan failed verifying the expected upstream > signature. Hm, works for me. Does the signature of this email verify? > This is not in a state that I can sponsor, sorry. > > How about uploading a targeted .debdiff fixing just the rc bug for now > and deferring the upstream release and its signature verification? I was unable to produce a .debdiff that consisted only of the change introduced by commit c0cf8e24b72effbe53c7dd840ead5130b87151d9 that fixed the RC bug. What would be a suitable debdiff command to achieve that? Thanks Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Mon, Mar 02, 2026 at 09:29:58PM +0100, Andre Noll wrote: > Yes, please upload the version I've just tagged as v1.0.6-1. The > ID of the git commit is cd596839f6d8147ac7464fddad88d0987c728e02. Signing a the git commit id in the mail is fine to me. Unfortunately, the commit does not seem very well tested. The format of debian/changelog is rejected by dpkg-source. A space is missing. Beyond that, this is uploading a new upstream release. I attempted fetching it via uscan and uscan failed verifying the expected upstream signature. This is not in a state that I can sponsor, sorry. How about uploading a targeted .debdiff fixing just the rc bug for now and deferring the upstream release and its signature verification? Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Sat, Feb 28, 11:42, Helmut Grohne wrote > On Sat, Feb 28, 2026 at 11:06:32AM +0100, Andre Noll wrote: > > Looks like the package will be removed from testing anyway due to this > > bug. What needs to be done to prevent that? > > You already did the right thing. The autoremover primarily handles > inactive RC bugs. In sending a mail to the bug you defer it. > > Longer term, fixing the bug would be good. Do you need a one-time > sponsor? If yes, consider handing me a pgp-signed .dsc or git tag. Yes, please upload the version I've just tagged as v1.0.6-1. The ID of the git commit is cd596839f6d8147ac7464fddad88d0987c728e02. Thanks Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Sat, Feb 28, 2026 at 11:06:32AM +0100, Andre Noll wrote: > Looks like the package will be removed from testing anyway due to this > bug. What needs to be done to prevent that? You already did the right thing. The autoremover primarily handles inactive RC bugs. In sending a mail to the bug you defer it. Longer term, fixing the bug would be good. Do you need a one-time sponsor? If yes, consider handing me a pgp-signed .dsc or git tag. Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Mon, Feb 02, 17:43, Andre Noll wrote > On Sat, Jan 31, 18:02, Helmut Grohne wrote > > > On Sat, Jan 31, 2026 at 05:16:09PM +0100, Andre Noll wrote: > > > Thanks for pointing out this issue. Is the below sufficient to fix it? > > > > Yes, that looks good to me. > > Great. I've now applied this patch to the "debian" branch and pushed out > the result to the public repo. Looks like the package will be removed from testing anyway due to this bug. What needs to be done to prevent that? Thanks Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Sat, Jan 31, 18:02, Helmut Grohne wrote > On Sat, Jan 31, 2026 at 05:16:09PM +0100, Andre Noll wrote: > > Thanks for pointing out this issue. Is the below sufficient to fix it? > > Yes, that looks good to me. Great. I've now applied this patch to the "debian" branch and pushed out the result to the public repo. Thanks Andre -- Max Planck Institute for Biology Tel: (+49) 7071 601 829 Max-Planck-Ring 5, 72076 Tübingen, Germany https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Hi Andre, On Sat, Jan 31, 2026 at 05:16:09PM +0100, Andre Noll wrote: > Thanks for pointing out this issue. Is the below sufficient to fix it? Yes, that looks good to me. Helmut
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
On Thu, Jan 29, 10:03, Helmut Grohne wrote: > Package: liblopsub1t64 > Version: 1.0.5-3.1+b1 > Severity: serious > Justification: unpack error from dpkg > User: [email protected] > Usertags: ftcbfs > Control: affects -1 + src:tfortune > > liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly > using install. The file is architecture-specific and installed into a > shared location. The package is Multi-Arch: same. Upon coinstallation, > dpkg fails to unpack. > > I suggest using dh_installchangelog as it separates the > architecture-dependent part. Thanks for pointing out this issue. Is the below sufficient to fix it? Best Andre --- commit c0cf8e24b72effbe53c7dd840ead5130b87151d9 Author: Andre Noll Date: Sat Jan 31 17:10:31 2026 +0100 debian: Use dh_installchangelogs liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly using install. The file is architecture-specific and installed into a shared location. The package is Multi-Arch: same. Upon coinstallation, dpkg fails to unpack. Use dh_installchangelog as it separates the architecture-dependent part. Suggested-by: Helmut Grohne diff --git a/debian/rules b/debian/rules index 9801fe6..1657fa8 100755 --- a/debian/rules +++ b/debian/rules @@ -54,10 +54,7 @@ binary: build echo 'activate-noawait ldconfig' > $(DESTDIR)/DEBIAN/triggers $(INST_FILE) debian/copyright $(DOCS_DIR)/copyright $(INST_FILE) debian/copyright $(DEVDOCS_DIR)/copyright - $(INST_FILE) debian/changelog $(DOCS_DIR)/changelog.Debian - $(INST_FILE) debian/changelog $(DEVDOCS_DIR)/changelog.Debian - gzip -fn9 $(DOCS_DIR)/changelog.Debian - gzip -fn9 $(DEVDOCS_DIR)/changelog.Debian + dh_installchangelogs dh_fixperms dh_makeshlibs dh_shlibdeps -- Max Planck Institute for Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 https://people.tuebingen.mpg.de/maan/
Bug#1126662: liblopsub1t64 is not binNMU-safe, causes unpack error
Package: liblopsub1t64 Version: 1.0.5-3.1+b1 Severity: serious Justification: unpack error from dpkg User: [email protected] Usertags: ftcbfs Control: affects -1 + src:tfortune liblopsub1t64 is not binNMU-safe. It installs debian/changelog directly using install. The file is architecture-specific and installed into a shared location. The package is Multi-Arch: same. Upon coinstallation, dpkg fails to unpack. I suggest using dh_installchangelog as it separates the architecture-dependent part. Helmut
