Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
The latest package at mentors has the version restriction removed. On Wed, Aug 16, 2017 at 1:03 PM, Andrey Rahmatullin wrote: > On Wed, Aug 16, 2017 at 01:00:21PM -0600, Stephen Dennis wrote: > > > > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= > 2.28.0. > > > > > > > > > > > > > Fixing. > > > You've changed it to >= 2.25-5. Why? Also, why this restriction is > needed? > > > > > > > I don't know what the guidance is for versions, so I picked the versions > > for Jessie (oldstable). There's nothing in the code that would prevent it > > from being built with older versions of these dependencies. > Then why do you have a version restriction at all? > > -- > WBR, wRAR >
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Control: tags 871693 - moreinfo On Sun, Sep 24, 2017 at 2:16 PM, Stephen Dennis wrote: > The latest package at mentors has the version restriction removed. > > On Wed, Aug 16, 2017 at 1:03 PM, Andrey Rahmatullin > wrote: > >> On Wed, Aug 16, 2017 at 01:00:21PM -0600, Stephen Dennis wrote: >> > > > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= >> 2.28.0. >> > > > > >> > > > >> > > > Fixing. >> > > You've changed it to >= 2.25-5. Why? Also, why this restriction is >> needed? >> > > >> > >> > I don't know what the guidance is for versions, so I picked the versions >> > for Jessie (oldstable). There's nothing in the code that would prevent >> it >> > from being built with older versions of these dependencies. >> Then why do you have a version restriction at all? >> >> -- >> WBR, wRAR >> > >
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Wed, Aug 16, 2017 at 01:00:21PM -0600, Stephen Dennis wrote: > > > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > > > > > > > > > > Fixing. > > You've changed it to >= 2.25-5. Why? Also, why this restriction is needed? > > > > I don't know what the guidance is for versions, so I picked the versions > for Jessie (oldstable). There's nothing in the code that would prevent it > from being built with older versions of these dependencies. Then why do you have a version restriction at all? -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Thank you for the feedback and for the effort it takes to review these packages. On Wed, Aug 16, 2017 at 12:40 PM, Andrey Rahmatullin wrote: > On Tue, Aug 15, 2017 at 12:05:26PM -0600, Stephen Dennis wrote: > > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > > > > > > > Fixing. > You've changed it to >= 2.25-5. Why? Also, why this restriction is needed? > I don't know what the guidance is for versions, so I picked the versions for Jessie (oldstable). There's nothing in the code that would prevent it from being built with older versions of these dependencies. However, if you have better guidance, lead on. Should I pick all the versions from testing? I've run license-reconcile on the package, it shows a lot of copyright > mismatches and asks you to name the pcre.* license "BSD-3-clause". I've > alos noticed src/wild.cpp says "This code is hereby placed under GNU > copyleft" which is not clarified, not mentioned in debian/copyright and > may be problematic in conjuction with Artistic 1.0. > Glad to make the BSD-3-clause change. The wild.cpp code is very old (on the order of 20-25 years), and it has changed little in that time. Code that old has been licensed and re-licensed by the original authors, starting with GNU but eventually landing under Artistic 1.0. There is a long and complex history, and it is possible that someone contributed code that I don't know about, but I know for certain that all of the primary maintainers have agreed to put their work under Artistic 1.0 (not only for TinyMUX but for the entire family of MUSH-style servers). If you want to read about this complex history, check out http://wiki.tinymux.org/index.php/History. Stephen
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Tue, Aug 15, 2017 at 12:05:26PM -0600, Stephen Dennis wrote: > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > > > > Fixing. You've changed it to >= 2.25-5. Why? Also, why this restriction is needed? I've run license-reconcile on the package, it shows a lot of copyright mismatches and asks you to name the pcre.* license "BSD-3-clause". I've alos noticed src/wild.cpp says "This code is hereby placed under GNU copyleft" which is not clarified, not mentioned in debian/copyright and may be problematic in conjuction with Artistic 1.0. -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Tue, Aug 15, 2017 at 11:48 AM, Andrey Rahmatullin wrote: > Are you sure you need autotools-dev? > Removing. > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > Fixing. > So now to talk about the dpkg-shlibdeps warningsI think the problem > is really dh_makeshlibs. > I don't think so. > You were correct. Fixed it with -l option
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Mon, Aug 14, 2017 at 02:55:57PM -0600, Stephen Dennis wrote: > Ah. missed the compat level because I changed the it to version 10 in the > debian/control file. Next upload will have debian/compat of 10, and > debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= > 2.28.0), autotools-dev (>= 20161112.1)" Are you sure you need autotools-dev? By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0. > So now to talk about the dpkg-shlibdeps warnings. The Debian package > installs the binaries (libmux.so and others) > under usr/lib/tinymux/game/bin, and then for a specific game, one runs > tinymux-install script to install a symbolic link into the current > directory. The install scripts creates a minimal game tree from which to > start a game. So, the server itself never runs directly from the > /usr/lib/tinymux/game/bin directory. That's why it works despite these > warnings. That doesn't matter, as the libs are not searched for in the current dir/the dir of the dependent binary. > But, I agree that suppressing or fixing these warning is a good thing > except that nothing I Google and no man pages I read describe how to > actually go about doing this. dh_shlibdeps(1)/dpkg-shlibdeps(1) "It tells dpkg-shlibdeps (via its -l parameter), to look for private package libraries in the specified directory" > dh_makeshlibs does run but it isn't picking > up the location where libmux.so is placed. The man page for dh_shlibdeps > describes this exact scenario and suggests to run dh_makeshlibs first as > the obvious solution, but that is already happening and it doesn't work. No, it describes a scenario with a public shared lib in a separate package. Your problem is caused by a private shared lib in a private path. > Solutions point to using override_dh_shlibdeps, but then, I need to pass it > all the right arguments and I think the problem is really dh_makeshlibs. I don't think so. -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Found a way to suppress/fix the warnings. On Mon, Aug 14, 2017 at 2:55 PM, Stephen Dennis wrote: > Ah. missed the compat level because I changed the it to version 10 in the > debian/control file. Next upload will have debian/compat of 10, and > debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= > 2.28.0), autotools-dev (>= 20161112.1)" > > So now to talk about the dpkg-shlibdeps warnings. The Debian package > installs the binaries (libmux.so and others) under usr/lib/tinymux/game/bin, > and then for a specific game, one runs tinymux-install script to install a > symbolic link into the current directory. The install scripts creates a > minimal game tree from which to start a game. So, the server itself never > runs directly from the /usr/lib/tinymux/game/bin directory. That's why it > works despite these warnings. > > But, I agree that suppressing or fixing these warning is a good thing > except that nothing I Google and no man pages I read describe how to > actually go about doing this. dh_makeshlibs does run but it isn't picking > up the location where libmux.so is placed. The man page for dh_shlibdeps > describes this exact scenario and suggests to run dh_makeshlibs first as > the obvious solution, but that is already happening and it doesn't work. > Solutions point to using override_dh_shlibdeps, but then, I need to pass it > all the right arguments and I think the problem is really dh_makeshlibs. > Nothing I've found describes how dh_makeshlibs does its job or how to > control it. Sorry, but I'm always at a loss for how to control these builds. > > On Mon, Aug 14, 2017 at 12:15 PM, Andrey Rahmatullin > wrote: > >> On Thu, Aug 10, 2017 at 11:11:26PM +0500, Andrey Rahmatullin wrote: >> > The build logs says: >> > >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: >> 'elf64-x86-64' >> > abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: >> > 'elf64-x86-64' abi: '0201003e'; RPATH: '') >> > dpkg-shlibdeps: warning: cannot find library libmux.so needed by >> > debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: >> 'elf64-x86-64' >> > abi: '0201003e'; RPATH: '') >> This is still happening. How are these libs going to find libmux.so? If >> you thnk nothing needs to be fixed at the upstream side then please tell >> dh_shlibdeps where to look for this lib. >> >> > Please switch to the debhelper compat level 10. >> debian/compat is still 9. >> >> -- >> WBR, wRAR >> > >
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Ah. missed the compat level because I changed the it to version 10 in the debian/control file. Next upload will have debian/compat of 10, and debian/control has "Build-Depends: debhelper (>= 10.0.0), binutils (>= 2.28.0), autotools-dev (>= 20161112.1)" So now to talk about the dpkg-shlibdeps warnings. The Debian package installs the binaries (libmux.so and others) under usr/lib/tinymux/game/bin, and then for a specific game, one runs tinymux-install script to install a symbolic link into the current directory. The install scripts creates a minimal game tree from which to start a game. So, the server itself never runs directly from the /usr/lib/tinymux/game/bin directory. That's why it works despite these warnings. But, I agree that suppressing or fixing these warning is a good thing except that nothing I Google and no man pages I read describe how to actually go about doing this. dh_makeshlibs does run but it isn't picking up the location where libmux.so is placed. The man page for dh_shlibdeps describes this exact scenario and suggests to run dh_makeshlibs first as the obvious solution, but that is already happening and it doesn't work. Solutions point to using override_dh_shlibdeps, but then, I need to pass it all the right arguments and I think the problem is really dh_makeshlibs. Nothing I've found describes how dh_makeshlibs does its job or how to control it. Sorry, but I'm always at a loss for how to control these builds. On Mon, Aug 14, 2017 at 12:15 PM, Andrey Rahmatullin wrote: > On Thu, Aug 10, 2017 at 11:11:26PM +0500, Andrey Rahmatullin wrote: > > The build logs says: > > > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: > > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: > > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: > > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: > 'elf64-x86-64' > > abi: '0201003e'; RPATH: '') > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: > > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > > debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: > 'elf64-x86-64' > > abi: '0201003e'; RPATH: '') > This is still happening. How are these libs going to find libmux.so? If > you thnk nothing needs to be fixed at the upstream side then please tell > dh_shlibdeps where to look for this lib. > > > Please switch to the debhelper compat level 10. > debian/compat is still 9. > > -- > WBR, wRAR >
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
On Thu, Aug 10, 2017 at 11:11:26PM +0500, Andrey Rahmatullin wrote: > The build logs says: > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: 'elf64-x86-64' > abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: 'elf64-x86-64' > abi: '0201003e'; RPATH: '') This is still happening. How are these libs going to find libmux.so? If you thnk nothing needs to be fixed at the upstream side then please tell dh_shlibdeps where to look for this lib. > Please switch to the debhelper compat level 10. debian/compat is still 9. -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Control: tags 871693 - moreinfo On Thu, Aug 10, 2017 at 12:11 PM, Andrey Rahmatullin wrote: > Control: severity -1 important > Control: tags -1 + moreinfo > > On Thu, Aug 10, 2017 at 11:32:54AM -0600, Stephen Dennis wrote: > > Package: sponsorship-requests > > Severity: normal [RC bug will auto-remove package on the 20th] > That statement actually means "put "important" here if RC". > > > Changes since the last upload: > > > > tinymux (2.10.1.14-1) unstable; urgency=medium > > > > * New upstream release (Closes: #853683) > This should be written as: > > * New upstream release > + fixes (Closes: #853683) > > * Update Standards-Version in debian/control from 3.9.8 to 4.0.0. > Note that the current one is 4.0.1. > Also, you don't just update Standards-Version in debian/control, you > consult the upgrading checklist and make any required changes, and if non > is required the changelog entry should contain "(no change needed)". > > debian/patches/cppflags.diff was dropped, please mention that. > > The build logs says: > > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: 'elf64-x86-64' > abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: > 'elf64-x86-64' abi: '0201003e'; RPATH: '') > dpkg-shlibdeps: warning: cannot find library libmux.so needed by > debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: 'elf64-x86-64' > abi: '0201003e'; RPATH: '') > > lintian says: > E: tinymux changes: orig-tarball-missing-upstream-signature > tinymux_2.10.1.14.orig.tar.bz2 > > Please switch to the debhelper compat level 10. > > src/pcre.* are not mentioned in debian/copyright, they are also an > embedded code copy and should be replaced with the packaged libpcre. > > -- > WBR, wRAR >
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Control: severity -1 important Control: tags -1 + moreinfo On Thu, Aug 10, 2017 at 11:32:54AM -0600, Stephen Dennis wrote: > Package: sponsorship-requests > Severity: normal [RC bug will auto-remove package on the 20th] That statement actually means "put "important" here if RC". > Changes since the last upload: > > tinymux (2.10.1.14-1) unstable; urgency=medium > > * New upstream release (Closes: #853683) This should be written as: * New upstream release + fixes (Closes: #853683) > * Update Standards-Version in debian/control from 3.9.8 to 4.0.0. Note that the current one is 4.0.1. Also, you don't just update Standards-Version in debian/control, you consult the upgrading checklist and make any required changes, and if non is required the changelog entry should contain "(no change needed)". debian/patches/cppflags.diff was dropped, please mention that. The build logs says: dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/stubslave (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/sample.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/sqlproxy.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/netmux (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/sqlslave.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libmux.so needed by debian/tinymux/usr/lib/tinymux/game/bin/sum.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') lintian says: E: tinymux changes: orig-tarball-missing-upstream-signature tinymux_2.10.1.14.orig.tar.bz2 Please switch to the debhelper compat level 10. src/pcre.* are not mentioned in debian/copyright, they are also an embedded code copy and should be replaced with the packaged libpcre. -- WBR, wRAR signature.asc Description: PGP signature
Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]
Package: sponsorship-requests Severity: normal [RC bug will auto-remove package on the 20th] Dear mentors, I am looking for a sponsor for my package "tinymux" * Package name: tinymux Version : 2.10.1.14-1 Upstream Author : Stephen Dennis * URL : https://www.tinymux.org * License : Artistic Section : games It builds those binary packages: tinymux- text-based multi-user virtual world server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tinymux Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tinymux/ tinymux_2.10.1.14-1.dsc Changes since the last upload: tinymux (2.10.1.14-1) unstable; urgency=medium * New upstream release (Closes: #853683) * Update Standards-Version in debian/control from 3.9.8 to 4.0.0. -- Stephen Dennis Sat, 05 Aug 2017 13:26:02 -0600 Regards, Stephen Dennis