Bug#882642: RFS: quickcal/1.0 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "quickcal" * Package name: quickcal Version : 1.0 Upstream Author : * URL : https://sourceforge.net/projects/quickcal/ * License : GPL Section : utils It builds those binary packages: quickcal - It is a fast and easy to use calculator. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/quickcal Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/quickcal/quickcal_1.0.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: Closes ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882566 Regards, Nathan SR
Bug#882568: RFS: nq/0.2.1-1 [ITP]
On Fri, Nov 24, 2017 at 10:05:29PM +0100, Vincent Bernat wrote: > ❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni >: > For 8 packages, you can file the bug directly. As for severity, people > may not agree with the interpretation of the policy: CC0 is equivalent > to public domain and the license text is very verbose. It would be > easier to push the change without a "threatening" severity. Thanks a bunch for the explanation and upload :) signature.asc Description: PGP signature
Re: How to find Multi-Arch path(s)
Hi! On Fri, 2017-11-24 at 13:59:40 +0100, Ole Streicher wrote: > Guillem Joverwrites: > > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote: > >> So, how can I canonically (ideally from C) retrieve a sorted list of > >> supported multi arch paths at runtime? Or is there another good way to > >> solve this? I would think it is a standard use case for multi arch, > >> isn't it? > > > > In general if you have to modify an upstream codebase to make it > > package-manager aware (be that dpkg, rpm or whatever), that to me seems > > like a big red sign too. In this case I think the problem is indeed that > > the original question is flawed, so there's no good answer. :) > > IRAF is a quite old program (>>30 years), with some unconventional > solutions. And it is in "maintenance mode" yet. > > The Multi-Arch solution upstream took is to put the binaries into > directories > > /iraf/iraf/bin.linuxfor 32 bit Linux (x86) > /iraf/iraf/bin.linux64 for 64 bit Linux (x86) > /iraf/iraf/bin.macosx for 32 bit Mac OSX > /iraf/iraf/bin.macintel for 32 bit Mac OSX > > (similar subdirs bin. are under /iraf/iraf/unix, /iraf/iraf/noao etc.) This is closer to the old multilib approach, which we are trying to deprecate. I'd completely scrap and ignore this concept from upstream. > and then have explicit if statements "if 64-bit linux also look in > 32-bit dirs". This is not applicable for Debian; first because of the > FHS violation; but also because other archs are not really possible. The > ARM architecture is however a working platform, with some use cases > (people want to run it on their raspberry). Exactly. > Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because > it is arch independent), except the bin.* dirs, which in a Debian > Multiarch environment should go into /usr/lib//iraf, right? Nope, as I've mentioned on my previous mail, I'd make the executables also arch-neutral on their pathnames. The point is that the Multi-Arch concept in Debian is all about the interfaces. How packages and files interface with each other, and what is possible and allowed. Some examples: * A script might be arch-independent in the contents sense; i.e., it is the same on all architectures. But its interface might be arch-dependent, because itself uses processor or kernel specific interfaces, and its output changes depending on the architecture. These cannot be marked as Mutli-Arch foreign. * A compiled binary might be arch-dependent in the contents sense; i.e., it is different on each architecture. But its interface might be arch-independent, because it does not change independently on where it is executed, or for what arch it was built for. These can be marked as Multi-Arch foreign. * A shared library that is being linked by some other package with executables, needs to match their architecture and needs to be coinstallable with itself, otherwise you could not install packages of different architectures linking againts that library. Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64. These are usually as Multi-Arch same. There are other fancy scenarios, and there's the more complex "allowed" value, but the examples below should cover our case here. > > So, going back. AFAIUI the iraf project supports plugins/extensions in > > the form of executables. > > Yes. > > > And some might only be available in a single arch. > > No. They are available under 32-bit archs. At least armhf and > i386 (linux + kfreebsd). Maybe x32. Well, ok, so arch-classes, all the same. :) So, say, your native arch (the one dpkg was built for) is amd64, and you have enabled i386 as a foreign arch. You then install the main iraf package for amd64 (the default), and then want to use some extension/plugin that is available only for 32-bit arches. apt for example will just pull the i386 version, because it'd be marked as Multi-Arch foreign and the dependencies would be fullfilled. That of course means, that whoever is calling those extension should not need to care what the arch is, because supposedly anything that can be executed will do. And what to install is decided by the package manager and/or the user. So that's why the executable pathnames should be arch-neutral. > > If that's the case, that looks like those extensions should be > > placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if > > we allowed that!), and those package be marked "Multi-Arch: foreign", > > then that's the package manager's problem to choose the most > > appropriate architecture for those binaries (perhaps by using the > > futurable executable attribute of an arch). > > This does not work: I have no way to execute from these binaries the > correct 64-bit binary, since it does not know its directory (the > multiarch dir known at compile time is i386-linux-gnu, not > x86_64-linux-gnu). See above, you should not need to know what arch
Bug#882568: marked as done (RFS: nq/0.2.1-1 [ITP])
Your message dated Fri, 24 Nov 2017 22:27:25 + with message-idand subject line closing RFS: nq/0.2.1-1 [ITP] has caused the Debian Bug report #882568, regarding RFS: nq/0.2.1-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 882568: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882568 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Control: block 882567 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear mentors, I am looking for a sponsor for my package "nq" * Package name: nq Version : 0.2.1-1 Upstream Author : Leah Neukirchen * URL : https://github.com/chneukirchen/nq * License : CC0 Section : utils It builds those binary packages: nq- Lightweight queue system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nq Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nq/nq_0.2.1-1.dsc Regards, Nicolas Braud-Santoni - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXeWcZHG5pY29sYXNA YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z41hHEACMlbQ7lpMz29Ye9Ue+JN94 CYns2tLK5gVYWaKVfWd1wyp7v182bulZv6y2+RgToRaDvy8XCZw1H9MAqK3fgT5P Zbg6dJP64v6qbG0vl6vOl6nQeT6nBKVkgWplXcUrwPOG9sN+eo/O6S3tncnQAZtk e1oy1WZz503VipIaHkYQf0m2lkyFxR8zzOtDngLTNCQ4JoxR3/ygy7WlqlQtNfdA tskJM55dJvXhXW4nGce134511baG91ltTBQaVIANBZZtQSOAGrcmwNNySyOdgwjp liXfEeTKFvCx88xF3vsBZxvqMx7mUZKtADAwMDHvjDwR2MvydvTFDHGQ41QpDK2Q R9R607EFr57+5kUXwMW4/vJVN0gaIY/39qepUkurC0al3F5saufD8P2lMJ2J8Eu+ W/+ZoUPsgdxFyW+xhQLehPW+75+8zzeaKuddD5Tcs079nnVMw+E0Dj5MRg6ZEW8k ZycxqqNkOiMS6OL1AFeKbGFx2bfP+kx56LLj4Rm9pzBXhq5X7DiuixfsUUNxmvCK lcYnhWn69uKvIrphSfK9ejDD0+PE/YQIkT8wiaJTNaSLA/ECBWJ28UmYRcK9yu89 mXPCc/XRT0MNUptMCjnrvCy25tqJXdACaed2uyO/gHqzJZQyVIErVaNti7VdXmR4 TIoaRtJ8tyrq4p9EJcVPDQ== =2pRn -END PGP SIGNATURE- --- End Message --- --- Begin Message --- Package nq version 0.2.1-1 is in NEW now, and the package at mentors is not newer (2017-11-24) than the package in NEW (2017-11-24), so there is currently no package to sponsor. https://ftp-master.debian.org/new/nq_0.2.1-1.html https://mentors.debian.net/package/nq Please remove the package from mentors or mark it "needs sponsor = no". If for some reason you need to replace the package in NEW, then you can upload an updated package to mentors and feel free to reopen this RFS 882568 or open a new RFS.--- End Message ---
Bug#882568: RFS: nq/0.2.1-1 [ITP]
❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni: >> Any MBF should be discussed first on debian-devel@ first. For me, >> this seems a small violation and it would be preferable to stick with >> severity normal to not appear too agressive. > > Only 8 source packages are concerned (re: not shipping the CC0 text), > so I didn't realise that constituted a MBF. > > Thanks for the advise on the severity, I was under the impression that all > policy violations should be `serious` or greater. How should I > proceed? For 8 packages, you can file the bug directly. As for severity, people may not agree with the interpretation of the policy: CC0 is equivalent to public domain and the license text is very verbose. It would be easier to push the change without a "threatening" severity. >> > Thanks a bunch for the review, >> >> Looks good. Tell me what you want to do about the remaining lintian >> warning. > > If that's fine by you, I would rather have it uploaded as-is. So, it's uploaded. -- Debian package sponsoring guidelines: https://vincent.bernat.im/en/debian-package-sponsoring signature.asc Description: PGP signature
Bug#882568: RFS: nq/0.2.1-1 [ITP]
On Fri, Nov 24, 2017 at 08:21:39PM +0100, Vincent Bernat wrote: > ❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni >: > > > - include the whole CC0 license in debian/copyright > > (this is already uploaded to mentors.d.n); > > - open a bug against base-files to ship the CC0 in > > /usr/share/common-licences > > - open bugs against concerned packages, to refer to the licence's text > > as installed by base-files; (what should the severity be? I guess > > serious, > > since it is a violation of Debian policy 12.5 [1]) > > > > [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0 > > [1]: https://www.debian.org/doc/debian-policy/#copyright-information > > Any MBF should be discussed first on debian-devel@ first. For me, > this seems a small violation and it would be preferable to stick with > severity normal to not appear too agressive. Only 8 source packages are concerned (re: not shipping the CC0 text), so I didn't realise that constituted a MBF. Thanks for the advise on the severity, I was under the impression that all policy violations should be `serious` or greater. How should I proceed? > >> You override the debian-watch-may-check-gpg-signature, but you also need > >> to override orig-tarball-missing-upstream-signature. Since the tooling > >> to check signatures the way you need it is not here, an alternative > >> would be to not ship upstream GPG signature. > > > > That's something lintian picks up in the changes file, and there is > > currently > > no way to override those, if I'm not mistaken: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400 > > Oh, yes, I remember now. On my own packages, I have removed the GPG > signature because of this. I don't know what's the stance of the FTP > masters on this particular problem, so I don't know if it's best to get > rid of the warning or just leave it as is. In your case, I would just > remove the key since it is not used. I would rather keep it there, to make it obvious which signing (sub)key I am trusting for upstream. :) > > Thanks a bunch for the review, > > Looks good. Tell me what you want to do about the remaining lintian > warning. If that's fine by you, I would rather have it uploaded as-is. Thanks, nicoo signature.asc Description: PGP signature
Bug#882568: RFS: nq/0.2.1-1 [ITP]
❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni: >> In d/copyright: you need to include the complete CC0 license. > > OK; I did so based on what other packages were doing, according to > codesearch.d.n [0]. If that's an acceptable solution, I will > - include the whole CC0 license in debian/copyright > (this is already uploaded to mentors.d.n); > - open a bug against base-files to ship the CC0 in /usr/share/common-licences > - open bugs against concerned packages, to refer to the licence's text > as installed by base-files; (what should the severity be? I guess serious, > since it is a violation of Debian policy 12.5 [1]) > > [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0 > [1]: https://www.debian.org/doc/debian-policy/#copyright-information Any MBF should be discussed first on debian-devel@ first. For me, this seems a small violation and it would be preferable to stick with severity normal to not appear too agressive. >> You override the debian-watch-may-check-gpg-signature, but you also need >> to override orig-tarball-missing-upstream-signature. Since the tooling >> to check signatures the way you need it is not here, an alternative >> would be to not ship upstream GPG signature. > > That's something lintian picks up in the changes file, and there is currently > no way to override those, if I'm not mistaken: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400 Oh, yes, I remember now. On my own packages, I have removed the GPG signature because of this. I don't know what's the stance of the FTP masters on this particular problem, so I don't know if it's best to get rid of the warning or just leave it as is. In your case, I would just remove the key since it is not used. > Thanks a bunch for the review, Looks good. Tell me what you want to do about the remaining lintian warning. -- Debian package sponsoring guidelines: https://vincent.bernat.im/en/debian-package-sponsoring signature.asc Description: PGP signature
FEP Automotive injection Mold-- one of your mold suppliers' choice in the future
Hello Sir, I'm Lily from FEP Mold. How's it going today? Fine very well, i hope. if not, i also would like become your loyal listener. As the head of the mold market, Have you ever concerned your molds' price and quality? or want to find the better suppliers that can let you have absolute advantage in the mold market? From now on, why not try our company? we can help you solve the mold problem that bothers you, may be we can become the best partner, welcome to contact me at any time. 如果你不想再收到该产品的推荐邮件,请点击这里退订
Bug#882568: RFS: nq/0.2.1-1 [ITP]
On Fri, Nov 24, 2017 at 08:14:51AM +0100, Vincent Bernat wrote: > > In d/changelog: you forgot to include the ITP bug number. Thanks for the catch; it seems I had included the ITP number in git (present on my laptop and alioth) but forgot to rebuild before dput... > In d/copyright: you need to include the complete CC0 license. OK; I did so based on what other packages were doing, according to codesearch.d.n [0]. If that's an acceptable solution, I will - include the whole CC0 license in debian/copyright (this is already uploaded to mentors.d.n); - open a bug against base-files to ship the CC0 in /usr/share/common-licences - open bugs against concerned packages, to refer to the licence's text as installed by base-files; (what should the severity be? I guess serious, since it is a violation of Debian policy 12.5 [1]) [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0 [1]: https://www.debian.org/doc/debian-policy/#copyright-information > You override the debian-watch-may-check-gpg-signature, but you also need > to override orig-tarball-missing-upstream-signature. Since the tooling > to check signatures the way you need it is not here, an alternative > would be to not ship upstream GPG signature. That's something lintian picks up in the changes file, and there is currently no way to override those, if I'm not mistaken: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400 > Also, I don't care about the use of short commands like fq, nq, tq (they > are currently free), but that's something others may feel is > inappropriate. You could keep them as is and see if the upload is > accepted by FTP masters. Yeah, I thought it would be more confusing than anything to rename the binaries (and I checked that the names were free using `command-not-found`). Thanks a bunch for the review, nicoo signature.asc Description: PGP signature
Re: How to find Multi-Arch path(s)
Hi Guillem, thanks for the quick answer. Guillem Joverwrites: > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote: >> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf > > It that was to be used, then it should be DEB_HOST_MULTIARCH, the > _TARGET_ variants are for canadian cross-compilers. :) If this is not > clear from the man page, I'm happy to clarify it further. OK; I was not sure. >> So, how can I canonically (ideally from C) retrieve a sorted list of >> supported multi arch paths at runtime? Or is there another good way to >> solve this? I would think it is a standard use case for multi arch, >> isn't it? > > In general if you have to modify an upstream codebase to make it > package-manager aware (be that dpkg, rpm or whatever), that to me seems > like a big red sign too. In this case I think the problem is indeed that > the original question is flawed, so there's no good answer. :) IRAF is a quite old program (>>30 years), with some unconventional solutions. And it is in "maintenance mode" yet. The Multi-Arch solution upstream took is to put the binaries into directories /iraf/iraf/bin.linuxfor 32 bit Linux (x86) /iraf/iraf/bin.linux64 for 64 bit Linux (x86) /iraf/iraf/bin.macosx for 32 bit Mac OSX /iraf/iraf/bin.macintel for 32 bit Mac OSX (similar subdirs bin. are under /iraf/iraf/unix, /iraf/iraf/noao etc.) and then have explicit if statements "if 64-bit linux also look in 32-bit dirs". This is not applicable for Debian; first because of the FHS violation; but also because other archs are not really possible. The ARM architecture is however a working platform, with some use cases (people want to run it on their raspberry). Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because it is arch independent), except the bin.* dirs, which in a Debian Multiarch environment should go into /usr/lib//iraf, right? > So, going back. AFAIUI the iraf project supports plugins/extensions in > the form of executables. Yes. > And some might only be available in a single arch. No. They are available under 32-bit archs. At least armhf and i386 (linux + kfreebsd). Maybe x32. > If that's the case, that looks like those extensions should be > placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if > we allowed that!), and those package be marked "Multi-Arch: foreign", > then that's the package manager's problem to choose the most > appropriate architecture for those binaries (perhaps by using the > futurable executable attribute of an arch). This does not work: I have no way to execute from these binaries the correct 64-bit binary, since it does not know its directory (the multiarch dir known at compile time is i386-linux-gnu, not x86_64-linux-gnu). And I also don't think it is a clean way to make the place of a 32-bit executable dependent on whether a 64-bit executable exists. Also I would also like to be able to choose the 32-bit plugin even when a 64-bit one exists. I could even think of more exotic test cases, like loading some qemu-aware kernel modules that enable to run armhf binaries on my intel machine, and then debug a small plugin for armhf -- so the list of supported archs may even change at runtime. To me, this all looks like the perfect use case for "Why do we need Multi-Arch at the end?", and that's why I would like to have it implemented in a clean way. I don't see that the problem appears from an ugly upstream code either: I have no problem with heavily patching it (in fact, the version being packages is my own fork that significantly deviates from the original code base). If you think this should be solved upstream, please tell me how :-) Best regards Ole
Re: How to find Multi-Arch path(s)
Hi! On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote: > I want to package a software, "iraf" (with extensions) that uses some > system dependent binaries internally. Some of the extensions will be > available in 32 bit only, so this is a good use case for > Multi-Arch. That means, that the binaries will go to > > /usr/lib/${DEB_TARGET_MULTIARCH}/iraf It that was to be used, then it should be DEB_HOST_MULTIARCH, the _TARGET_ variants are for canadian cross-compilers. :) If this is not clear from the man page, I'm happy to clarify it further. > At run time, I would now need to get the list of paths that are > supported by the system, in their "preferred" order (so, even from a > binary compiled for i386, it would be preferred to call a x86_64 binary > if that is supported on the system). This list is generally not known at > compile time, since it depends on the details of the target system > configuration (f.e. an architecture may be supported via a software > emulation). > > However, I could not find out how to get this list? > > "dpkg --print-architecture" and "dpkg --print-foreign-architectures" > gives only what dpkg is configured for, not what is supported as > executable. And, it does not return the multi-arch triplet. While there are requests to include this information, so that it can be retrieved and used, in this case it does not seem this is what you should be using anyway, even if it was there. > "dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture > (default, or specified by the arch name), but from the manpage and the > package description of dpkg-dev it is not intended for runtime, but for > package build/development. Exactly. When one needs the matching triplet or multiarch normalized triplet for the package's arch, that's best solved by injecting that at build time, which is already known at that point. In most cases when one needs to know those matching triplets for *any* arch at run-time, that's a sign there's something wrong with the design, and I'd recommend going back to the drawing board. :) > So, how can I canonically (ideally from C) retrieve a sorted list of > supported multi arch paths at runtime? Or is there another good way to > solve this? I would think it is a standard use case for multi arch, > isn't it? In general if you have to modify an upstream codebase to make it package-manager aware (be that dpkg, rpm or whatever), that to me seems like a big red sign too. In this case I think the problem is indeed that the original question is flawed, so there's no good answer. :) So, going back. AFAIUI the iraf project supports plugins/extensions in the form of executables. And some might only be available in a single arch. If that's the case, that looks like those extensions should be placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if we allowed that!), and those package be marked "Multi-Arch: foreign", then that's the package manager's problem to choose the most appropriate architecture for those binaries (perhaps by using the futurable executable attribute of an arch). Hope that helps! Thanks, Guillem
How to find Multi-Arch path(s)
Hi, I want to package a software, "iraf" (with extensions) that uses some system dependent binaries internally. Some of the extensions will be available in 32 bit only, so this is a good use case for Multi-Arch. That means, that the binaries will go to /usr/lib/${DEB_TARGET_MULTIARCH}/iraf At run time, I would now need to get the list of paths that are supported by the system, in their "preferred" order (so, even from a binary compiled for i386, it would be preferred to call a x86_64 binary if that is supported on the system). This list is generally not known at compile time, since it depends on the details of the target system configuration (f.e. an architecture may be supported via a software emulation). However, I could not find out how to get this list? "dpkg --print-architecture" and "dpkg --print-foreign-architectures" gives only what dpkg is configured for, not what is supported as executable. And, it does not return the multi-arch triplet. "dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture (default, or specified by the arch name), but from the manpage and the package description of dpkg-dev it is not intended for runtime, but for package build/development. So, how can I canonically (ideally from C) retrieve a sorted list of supported multi arch paths at runtime? Or is there another good way to solve this? I would think it is a standard use case for multi arch, isn't it? Best regards Ole
Bug#882392: RFS: dmg2img/1.6.7-1 [ITA]
Hi Denys, On Wed, Nov 22, 2017 at 04:08:05AM +, Denys Berkovskyy wrote: > I am looking for a sponsor for my package "dmg2img" Excellent, thanks for taking care of this! > Changes since the last upload: > * New upstream version 1.6.6 (Closes: #778827) > * New upstream version 1.6.7 > * Fix FTCBFS: Let cdbs' makefile.mk pass cross compilers. (Closes: #864511) > * Update patches > * Update debhelper compatibility level to v10 > * Bump standards version to 4.1.1 (No changes required) > * Fix homepage URL, remove obsolete URLs > * Update debian/copyright file > * Fix typo in packet description > * New maintainer (Closes: #881838) I have a few review comments... In the changelog, I don’t think there’s much point in repeating “New upstream version”. I also prefer distinguishing close reasons in detail: so “New upstream version” would close a bug requesting a new upstream version, but not bugs which happen to be fixed in the upstream release. This would result in something like * New upstream release: - fixes a crash on invalid block signatures (Closes: #778827) While you’re at it, could you check to see whether the other crashing bugs are fixed? I think some of them might be... It would be nice too to see whether bindnow and fortify can be enabled (unless those are false positives in Lintian’s output). Regards, Stephen signature.asc Description: PGP signature