Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

Reproduce this by adding 'sleep 100' into the libmux.so: part of the
Makefile. It reproduces in the initial submission. It does not reproduce in
the second. So, I am confident it has been fixed.

On Tue, Jul 26, 2022 at 8:03 PM Adam Borowski  wrote:

> On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote:
> >  * Package name: tinymux
> >Version : 2.12.0.10-1
>
> >  tinymux (2.12.0.10-1) unstable; urgency=medium
> >  .
> >* New upstream release
> >  + fixes ftbfs with GCC-12. (Closes: #1013053)
> >* Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
> >  + Removed build date and number for reproducible build.
> >(Closes: #866945)
>
> Alas, it fails to build:
> g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux: No such file or directory
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
> ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
> ⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...
>

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

I've submitted a second upload to mentors that:

1. I believe will address libmux.so being used before it is built. I've
tried to reproduce a race condition with make -j12, but I am unsuccessful.
For me, the build always succeeds.
2. I hope the above fix prevents any random reference to an external libmux
or random and unintended reference to libxbase64 or .la files.

On Tue, Jul 26, 2022 at 9:18 PM Stephen Dennis 
wrote:

> Could it be a naming collision between the private libmux and an
> official libmux package?
>
> On Tue, Jul 26, 2022 at 9:13 PM Stephen Dennis 
> wrote:
>
>> How can I reproduce what you are seeing? The package doesn't use libtool,
>> and no .la files are produced or included. There should be no reference to
>> libxbase64. I'm not even sure what that is.
>>
>>
>> On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski 
>> wrote:
>>
>>> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
>>> >Package name: xbase64
>>> >Version : 3.1.2-14
>>>
>>> >  xbase64 (3.1.2-14) unstable; urgency=medium
>>> >  .
>>> >* Migrate to debhelper-compat 13:
>>> >  - debian/control: Add debhelper-compat (= 13).
>>> >  - Remove debian/compat.
>>> >  - Add usr/bin/xbase64-config into new debian/not-installed.
>>> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
>>> >  debian/libxbase64-bin.install.
>>> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
>>> >* debian/copyright:
>>> >  - Add year 2022 to myself.
>>> >* Disable Link time optimization (Closes: #1015707):
>>> >  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
>>> >* debian/control: Add Rules-Requires-Root: no.
>>>
>>> Is there a reason you include the .la file?  From my experience it being
>>> needed for anything suggests severe borkage, and the Policy concurs:
>>>
>>> # [...] these files normally should not be included in the Debian
>>> package,
>>> # since the information they include is not necessary to link with the
>>> # shared library on Debian and can add unnecessary additional
>>> dependencies
>>> # to other programs or libraries.
>>>
>>> It then says:
>>>
>>> # If the ".la" must be included, it should be included in the
>>> # development ("-dev") package, unless the library will be loaded by
>>> # "libtool"’s "libltdl" library. If it is intended for use with
>>> # "libltdl", the ".la" files must go in the run-time library package.
>>>
>>> libxbase64-bin is neither.
>>>
>>>
>>> Meow!
>>> --
>>> ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
>>> ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
>>> ⢿⡄⠘⠷⠚⠋⠀
>>> ⠈⠳⣄ You should also never anthropomorphize spammers and
>>> telemarketers.
>>>
>>>

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

Could it be a naming collision between the private libmux and an
official libmux package?

On Tue, Jul 26, 2022 at 9:13 PM Stephen Dennis 
wrote:

> How can I reproduce what you are seeing? The package doesn't use libtool,
> and no .la files are produced or included. There should be no reference to
> libxbase64. I'm not even sure what that is.
>
>
> On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski  wrote:
>
>> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
>> >Package name: xbase64
>> >Version : 3.1.2-14
>>
>> >  xbase64 (3.1.2-14) unstable; urgency=medium
>> >  .
>> >* Migrate to debhelper-compat 13:
>> >  - debian/control: Add debhelper-compat (= 13).
>> >  - Remove debian/compat.
>> >  - Add usr/bin/xbase64-config into new debian/not-installed.
>> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
>> >  debian/libxbase64-bin.install.
>> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed)

Bug#1015968: RFS: xbase64/3.1.2-14 -- xbase compatible C++ class library

[Stephen Dennis]

How can I reproduce what you are seeing? The package doesn't use libtool,
and no .la files are produced or included. There should be no reference to
libxbase64. I'm not even sure what that is.


On Tue, Jul 26, 2022 at 8:30 PM Adam Borowski  wrote:

> On Sun, Jul 24, 2022 at 04:53:52PM +0200, Jörg Frings-Fürst wrote:
> >Package name: xbase64
> >Version : 3.1.2-14
>
> >  xbase64 (3.1.2-14) unstable; urgency=medium
> >  .
> >* Migrate to debhelper-compat 13:
> >  - debian/control: Add debhelper-compat (= 13).
> >  - Remove debian/compat.
> >  - Add usr/bin/xbase64-config into new debian/not-installed.
> >  - Add usr/lib/${DEB_HOST_MULTIARCH}/libxbase64.la to
> >  debian/libxbase64-bin.install.
> >* Declare compliance with Debian Policy 4.6.1.0 (No changes needed).
> >* debian/copyright:
> >  - Add year 2022 to myself.
> >* Disable Link time optimization (Closes: #1015707):
> >  - debian/rules: Add optimize=-lto to DEB_BUILD_MAINT_OPTIONS.
> >* debian/control: Add Rules-Requires-Root: no.
>
> Is there a reason you include the .la file?  From my experience it being
> needed for anything suggests severe borkage, and the Policy concurs:
>
> # [...] these files normally should not be included in the Debian package,
> # since the information they include is not necessary to link with the
> # shared library on Debian and can add unnecessary additional dependencies
> # to other programs or libraries.
>
> It then says:
>
> # If the ".la" must be included, it should be included in the
> # development ("-dev") package, unless the library will be loaded by
> # "libtool"’s "libltdl" library. If it is intended for use with
> # "libltdl", the ".la" files must go in the run-time library package.
>
> libxbase64-bin is neither.
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
> ⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.
>
>

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

I wonder if it is a race condition in the Makefile. libmux.so is built from
code in the package. It isn't an external dependency. From the Makefile:

MUX_LIBS = -lmux
...
all: libmux.so netmux slave stubslave links subdirs
...
stubslave: stubslave.o
$(CXX) $(ALLCXXFLAGS) -o stubslave stubslave.o -L. $(LIBS)
$(MUX_LIBS) $(STUBLIBS)

I bet that should be

  stubslave: stubslave.o libmux.so
$(CXX) $(ALLCXXFLAGS) -o stubslave stubslave.o -L. $(LIBS)
$(MUX_LIBS) $(STUBLIBS)

This has probably been an issue forever, but no one has tried to build it
on enough cores, yet. And, likewise, I won't know for certain that it is
fixed without someone without enough cores.

Stephen

On Tue, Jul 26, 2022 at 8:03 PM Adam Borowski  wrote:

> On Tue, Jul 26, 2022 at 03:29:03PM -0600, Stephen Dennis wrote:
> >  * Package name: tinymux
> >Version : 2.12.0.10-1
>
> >  tinymux (2.12.0.10-1) unstable; urgency=medium
> >  .
> >* New upstream release
> >  + fixes ftbfs with GCC-12. (Closes: #1013053)
> >* Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
> >  + Removed build date and number for reproducible build.
> >(Closes: #866945)
>
> Alas, it fails to build:
> g++ -std=c++14 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux: No such file or directory
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
> ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
> ⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...
>

Bug#1016091: RFS: tinymux/2.12.0.10-1 [RC] -- text-based multi-user virtual world server

[Stephen Dennis]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "tinymux":

 * Package name: tinymux
   Version : 2.12.0.10-1
   Upstream Author : Stephen Dennis 
 * URL : http://www.tinymux.org/
 * License : BSD-3-clause, Artistic-1.0 and TinyMUD-revised
 * Vcs : https://github.com/brazilofmux/tinymux
   Section : games

The source builds the following 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, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/t/tinymux/tinymux_2.12.0.10-1.dsc

Changes since the last upload:

 tinymux (2.12.0.10-1) unstable; urgency=medium
 .
   * New upstream release
 + fixes ftbfs with GCC-12. (Closes: #1013053)
   * Update Standards-Version in debian/control from 4.0.1 to 4.6.1.
 + Removed build date and number for reproducible build.
   (Closes: #866945)

Regards,

Stephen Dennis

Bug#968153: RFS: tinymux/2.12.0.10-1 -- text-based multi-user virtual world server

[Stephen Dennis]

Thanks. I've setup pbuilder, re-built (without issue), and uploaded the
signed package again with dput.

On Wed, Aug 12, 2020 at 4:04 AM Baptiste BEAUPLAT  wrote:

> Hi Stephen,
>
> On 8/12/20 7:22 AM, Stephen Dennis wrote:
> > It builds and rebuilds for me on two different clean Debian
> environments. I
> > have never gotten the '/usr/bin/ld: cannot find -lmux' error. Adam hasn't
> > responded in two days and is probably waiting for me to fix an error I
> > cannot reproduce. Can anyone else build it? Am I building this a wrong
> way?
> >
> > dpkg-buildpackage -k<...>
> > lintian
> > dput
>
> You will need to use sbuild[1] or pbuilder[2] to create clean minimal
> Debian build environment.
>
> [1]: https://wiki.debian.org/sbuild
> [2]: https://www.debian.org/doc/manuals/maint-guide/build.en.html#pbuilder
>
> --
> Baptiste BEAUPLAT - lyknode
>
>

Bug#968153: RFS: tinymux/2.12.0.10-1 -- text-based multi-user virtual world server

[Stephen Dennis]

Current status:

It builds and rebuilds for me on two different clean Debian environments. I
have never gotten the '/usr/bin/ld: cannot find -lmux' error. Adam hasn't
responded in two days and is probably waiting for me to fix an error I
cannot reproduce. Can anyone else build it? Am I building this a wrong way?

dpkg-buildpackage -k<...>
lintian
dput

On Mon, Aug 10, 2020 at 5:01 AM Adam Borowski  wrote:

>
> Alas, still fails:
> g++ -std=c++14 -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -g -O
>  -DSTUB_SLAVE   -o stubslave stubslave.o -L. -lm -lcrypt   -lmux -lpcre
> /usr/bin/ld: cannot find -lmux

Bug#968153: RFS: tinymux/2.12.0.10-1 -- text-based multi-user virtual world server

[Stephen Dennis]

Package is updated.

I made those changes and tried to upload last night,but the update was
silently dropped. Deleting the first upload and uploading again worked.
But, doing that caused other problems last time.

I don't understand why debian/control tries to have a tidy Build-Depends
but dpkg-buildpackage creates debian/tinymux/DEBIAN/control with the full
dependencies including libpcre3. And, that doesn't show up on a lintian
report. It's hard to know what it cares about and what it doesn't care
about. My guess is that everything on the Depends: line is
debian/tinymux/DEBIAN/control is part of the base system _except_ for
libpcre3 so that must be called out explicitly in Build-Depends?

Thanks for your help.

Stephen

On Sun, Aug 9, 2020 at 6:38 PM Adam Borowski  wrote:

> On Sun, Aug 09, 2020 at 04:32:31PM -0600, Stephen Dennis wrote:
> >  * Package name: tinymux
> >Version : 2.12.0.10-1
>
> >
> https://mentors.debian.net/debian/pool/main/t/tinymux/tinymux_2.12.0.10-1.dsc
>
> >  tinymux (2.12.0.10-1) UNRELEASED; urgency=medium
>  ^^
> This tag designates the package's state as WIP, and would have caused an
> autoreject if uploaded.  By the time you send a RFS, the package is
> supposed
> to be ready to go.  Thus, could you please target unstable?
>
> >* New upstream release.
> >* Update Standards-Version in debian/control from 4.0.1 to 4.5.0 (no
> >  change needed).
> >* Avoid embedding PCRE.
> >* Removed PCRE license from debian/copyright.
>
> Alas, it fails to build in a clean environment:
>
> command.cpp:23:10: fatal error: pcre.h: No such file or directory
>23 | #include 
>   |  ^~~~
>
> which is caused by an obvious missing Build-Dependency.
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁
> ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
> ⠈⠳⣄
>

Bug#968153: RFS: tinymux/2.12.0.10-1 -- text-based multi-user virtual world server

[Stephen Dennis]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "tinymux":

 * Package name: tinymux
   Version : 2.12.0.10-1
   Upstream Author : Stephen Dennis 
 * URL : http://www.tinymux.org/
 * License : Artistic-1.0 and TinyMUD-revised
 * Vcs : https://github.com/brazilofmux/tinymux
   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.12.0.10-1.dsc

Changes for the initial release:

 tinymux (2.12.0.10-1) UNRELEASED; urgency=medium
 .
   * New upstream release.
   * Update Standards-Version in debian/control from 4.0.1 to 4.5.0 (no
 change needed).
   * Avoid embedding PCRE.
   * Removed PCRE license from debian/copyright.

Regards,

Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]

[Stephen Dennis]

Control: tags 871693 - moreinfo


On Sun, Sep 24, 2017 at 2:16 PM, Stephen Dennis <brazilof...@gmail.com>
wrote:

> The latest package at mentors has the version restriction removed.
>
> On Wed, Aug 16, 2017 at 1:03 PM, Andrey Rahmatullin <w...@debian.org>
> 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]

[Stephen Dennis]

The latest package at mentors has the version restriction removed.

On Wed, Aug 16, 2017 at 1:03 PM, Andrey Rahmatullin <w...@debian.org> 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]

[Stephen Dennis]

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 <w...@debian.org>
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]

[Stephen Dennis]

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]

[Stephen Dennis]

Found a way to suppress/fix the warnings.

On Mon, Aug 14, 2017 at 2:55 PM, Stephen Dennis <brazilof...@gmail.com>
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 <w...@debian.org>
> 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]

[Stephen Dennis]

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]

[Stephen Dennis]

Control: tags 871693 - moreinfo

On Thu, Aug 10, 2017 at 12:11 PM, Andrey Rahmatullin <w...@debian.org>
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]

[Stephen Dennis]

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 <brazilof...@gmail.com>
 * 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 <brazilof...@gmail.com>  Sat, 05 Aug 2017 13:26:02
-0600


Regards,
 Stephen Dennis

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

On Thu, Jan 5, 2017 at 12:32 AM, Tobias Frost  wrote:

> Control: tags -1 moreinfo
>
> BTW, you're using the tar.gz .. Can you use the tar.bz2 for the
> packaging as it compresses better? This is also the one that is picked
> up by uscan... (Just use uscan --force-download to get a copy and then
> delete the other one)
>

Done.


> - d/clean: You can use wildcards, eg. it is less fragile if your clean
> games/bin/* instead of the individual files.
>

Done.


> - you do not need to d/clean condig.(log|status)
>

Done.


> About the install:
> - there are a few files with *.conf that are going to /usr/share/...
> Are they conf-files that should actually go to /etc/ as a kind of
> system-wide configuration?
>

They would be game-specific -- the name of the game, ports used, The
tinymux-install script doesn't support it directly, but someone could run
that script multiple time, and rename the resulting tinymux directory to
the um-teen different games they want to run. Each one would need to have
it's own configuration.


>
> >  - There's no obvious override for the duplicate changelog warning.
>
> The problem is that dh_installchangelogs will pick it up, but you've
> got it also specified in d/docs.


Just removed CHANGES from d/docs.

>
>
You shouldn't install the doc INSTALL, as this is not relevant for
> Debian binary packages -- it talks mostly about how to compile etc.
> (README.Debian takes it job appearantly already)
>

Did not see that one in the d/docs file. There are references to it in
other readme files, but that file itself is not being installed.

>
> While this explains the why very well (and is too extensive on the what
> (this is will be in the diff) Convention is just to write:
>* New maintainer. (Closes: #YourITABugNumber)
>

Let's be fashionable. Changed to reference the bug.


> One thing I noted: NOTES mentions there is a default password. (I guess
> it it a kind of admin password) This is a bad idea, securitywise and
> should be changed.


It is a kind of admin password, the password to the ''god' account within
the game. A bit of tradition buried there (
https://en.wikipedia.org/wiki/Potrzebie). These mud games were once hosted
in hidden fashion on University boxes, hidden in plain sight. You had to be
smart enough to find the party or deserve an invitation. It's not like that
now.

OK, back to business. I agree that it is a bad idea. A fix would require
that the following lines in netmux.db be changed at install time:

>5
"$SHA1$X0PG0reTn66s$FxO7KKs/CJ+an2rDWgGO4zpo1co="

Or, a command-line option to netmux added that went through the steps of
loading the game's database but immediately changing the password to
something else before accepting connections. Both options would need
upstream work. I prefer the second option, but any option would require
upstream work.

None of the game accounts are given any control over the shell account. The
worst #1 should be able to do is delete the database from the inside or
change a configuration option which takes the game down by causing a
divide-by-zero. What worries me more than the initial, default #1 password.
is the UTF-8 state machine that parses input for all users and the fact all
users have access to PCRE globs. I still remember the old telnet bugs, and
PCRE globs are mini-programs, and it isn't hard to tie the game up for an
hour with a carefully chosen ones. We've added CPU limits within the inner
loops in the PCRE code to forestall this, and that's the only reasons why I
use the PCRE statically instead of using it as a library.

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Thanks for the starting point. I had worked out the d/watch file enough
that it works locally (mentors.debian.net still complains), but I like your
wildcards better, so I'm using that one (mentors.debian.net still
complains). The simple short d/rules is very much appreciated. I only just
begin to discover the override_* stuff before you sent it. You saved me two
days there. That and writing d/install and d/clean exposed some
embarrassing stray symbolic links. I actually prefer enumerating the exact
placement of all the files. So, what remains:

 - I think the fortify complaint about slave and stubslave is probably
because they are so minimal. I don't think they use any libc functions
actually.
 - There's no obvious override for the duplicate changelog warning.
 - Revisit d/changelog to make sure the package changes are fully captured.
 - It would be nice to get make -j2 working. They did work once upon a
time. Might be better to fix that upstream.
 - Test. The prettiest package in the world doesn't necessarily install
anything that works.

On Wed, Jan 4, 2017 at 4:32 PM, Tobias Frost  wrote:

> Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> >
> > I wrote you a rule file as starting point. Attached. It is thought to
> > get you started.
> > (Some parts are missing, like the hardening; also stuff and you need
> > to
> > do outside of the rules, like to create the file d/clean with all
> > files
> > listed and d/install to to put the files actually in place
> >
> PS: I needed to add --no-parallel because parallel build is broken
> here. This is also bug in your Makefile...
>
> To trigger
> #debuild -j1
> (works)
>
> #debuild -j4
> (...)
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o -L.
> -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:189: recipe for target 'stubslave' failed
> make[1]: *** [stubslave] Error 1
> make[1]: *** Waiting for unfinished jobs
> ( if [ -f netmux ]; then mv -f netmux netmux~ ; fi )
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o netmux _build.o alarm.o
> alloc.o attrcache.o boolexp.o bsd.o command.o comsys.o conf.o cque.o
> create.o db.o db_rw.o eval.o file_c.o flags.o funceval.o funceval2.o
> functions.o funmath.o game.o help.o htab.o local.o log.o look.o mail.o
> match.o mathutil.o mguests.o modules.o move.o muxcli.o netcommon.o
> object.o predicates.o player.o player_c.o plusemail.o powers.o quota.o
> rob.o pcre.o set.o sha1.o speech.o stringutil.o strtod.o svdrand.o
> svdhash.o timer.o timeabsolute.o timedelta.o timeparser.o timeutil.o
> timezone.o unparse.o utf8tables.o vattr.o walkdb.o wild.o
> wiz.o  version.o -L. -lm -lcrypt -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:198: recipe for target 'netmux' failed
> make[1]: *** [netmux] Error 1
> make[1]: Leaving directory
> '/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13/src'
>

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

I've never been able to get the watch file to work right, and it is
mis-behaving like it always has. I think I've made all the other changes
requested except I'm still a total loss as to how to migrate to the short
debhelper format.

On Tue, Jan 3, 2017 at 7:28 AM, Tobias Frost  wrote:

> > Very much appreciate the feedback. Willing to learn, but overwhelmed by
> the
> > Debian machinery.
>
> You're welcome!
>
> Yes, indeed it can be overwhelming. But don't worry, we've all had to learn
> this ;-)
>
> > Stupid question at the top: If I dput another package, does it update
> this
> > one or do I need to delete the currently uploaded package from mentors
> > first?
>
> You can just dput it. It will overwrite the previous version.
>
> > - d/changelog. A lot has changed. Here are pointers to 'brief' change
> logs
> > for 2.7, 2.9, and 2.10:
> >
> > http://www.tinymux.org/changes27.txt
> > http://www.tinymux.org/changes29.txt
> > http://www.tinymux.org/changes.txt
> >
> > That's four years of why to retrace, and the actual check-in messages
> from
> > the repository would be much longer. Does Debian really want all of that?
>
> No, the debian changelog is only for changes done to the (Debian)
> packaging,
> not to the upstream source. See the Debian Policy §4.4
> You ship already an upstream changelog (though it seems only to be limited
> to
> the last version and more a NEWS file than a real changelog...)
>
> > - d/patches
> >
> >   - Not sure what a dep3 header is, yet. More to learn.
>
> http://dep.debian.net/deps/dep3/
> Hint: $ quilt header -e --dep3
>
> >   - All but one of the patches is checked-in upstream already.
>
> Ok. (Document that with the appropiate dep3-header "Applied-Upstream")
>
> >   - I don't know how to have config.guess be updated at build time? Did
> not
> > know about that one. Is this part of automake? TinyMUX is more autoconf
> > than it once was, but it still doesn't use automake or libtool.
>
> https://wiki.debian.org/Autoreconf
>
> NOTE: When you change to compat level 10 and short debhelper format it is
> even
> more easier, as compat level 10 default to use dh_autoreconf.
>
> >   - Dependency-created-noise.patch. The way users normally build
> TinyMUX is
> > untar the package, ./configure;make depend;make. The 'make depend' scans
> > all the include files and builds ".depend" which is then re-consumed by
> > Makefile. It must exist -- at least empty. The Debian build system would
> > see either way as a source change, but it isn't a change to taken
> upstream.
> > It always changes in different ways in every environment.
>
> Another reason to get rid of it to make it really portable ;-) But as said,
> patching it is wrong, especially if it can be reconstructed during the
> build.
>
> If it just needs to exists, why not
> - remove it e.g via (the file) debian/clean
> - after configure, touch it to be present
> - in build run make
>
> > - d/copyright dep5...OK, more to study. The copyright is the same as
> > previous 2.6 package except for the dates. That was hammered out between
> > the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and RhostMUSH). I'm
> > loath to change the substance of it, but if there is some Debian-friendly
> > form to call out that it is the Artistic license, that seems reasonable
> > enough.
>
> Well that happens when a package gets some care only after several years
> (btw, THANK YOU for this caring!) Policies / Procedures have been updated,
> so the "Machine-readable debian/copyright file" is now standard.
>
> > - silent rule. TinyMUX uses the other autoconf tools, but not libool or
> > automake. Silent rule seems to be a term from those things?
>
> When I compiled the package I saw that the gcc command line executed was
> not
> echoed to the console. That needs change. Several Debian tools analyzes the
> build logs to find certain problems.
>
> > - d/rules. I'm picking this up from the previous maintainer, Noltar, and
> > there should be simpler ways of doing this now. I'm just not up to speed
> on
> > them and haven't found examples I grok, yet. I want to use the simple
> > debhelper method. dh, done.
>
> man dh
> (you probably need to override dh_auto_configure and dh_auto_build and
> specify
> the source directory (the manpage above explains it); other tweaks is
> probably
> to fix the install file instead of listing them in the install target.
> Let me know when you're stuck, I'll help with hints
> (my policy is to make you learn and also to use google and e.g
> codesearch.debian.net ;-))
>
> Another point which I missed this morning*: You should provide a watch
> file.
> Hint: https://wiki.debian.org/debian/watch#GitHub
>
> * I was quite time constrained -- I apologize in advance if I find other
> points later :). But lets first tackle the above and then look for the
> missing
> pieces...
>
> --
> tobi
>
> > Stephen
> >
> > On Mon, Jan 2, 2017 at 11:41 PM, Tobias Frost  wrote:
> >
> >> control: tags -1 moreinfo
> 

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Very much appreciate the feedback. Willing to learn, but overwhelmed by the
Debian machinery.

Stupid question at the top: If I dput another package, does it update this
one or do I need to delete the currently uploaded package from mentors
first?


- d/changelog. A lot has changed. Here are pointers to 'brief' change logs
for 2.7, 2.9, and 2.10:

http://www.tinymux.org/changes27.txt
http://www.tinymux.org/changes29.txt
http://www.tinymux.org/changes.txt

That's four years of why to retrace, and the actual check-in messages from
the repository would be much longer. Does Debian really want all of that?

- d/patches

  - Not sure what a dep3 header is, yet. More to learn.
  - All but one of the patches is checked-in upstream already.
  - I don't know how to have config.guess be updated at build time? Did not
know about that one. Is this part of automake? TinyMUX is more autoconf
than it once was, but it still doesn't use automake or libtool.
  - Dependency-created-noise.patch. The way users normally build TinyMUX is
untar the package, ./configure;make depend;make. The 'make depend' scans
all the include files and builds ".depend" which is then re-consumed by
Makefile. It must exist -- at least empty. The Debian build system would
see either way as a source change, but it isn't a change to taken upstream.
It always changes in different ways in every environment.

- d/copyright dep5...OK, more to study. The copyright is the same as
previous 2.6 package except for the dates. That was hammered out between
the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and RhostMUSH). I'm
loath to change the substance of it, but if there is some Debian-friendly
form to call out that it is the Artistic license, that seems reasonable
enough.

- silent rule. TinyMUX uses the other autoconf tools, but not libool or
automake. Silent rule seems to be a term from those things?

- d/rules. I'm picking this up from the previous maintainer, Noltar, and
there should be simpler ways of doing this now. I'm just not up to speed on
them and haven't found examples I grok, yet. I want to use the simple
debhelper method. dh, done.

Stephen

On Mon, Jan 2, 2017 at 11:41 PM, Tobias Frost  wrote:

> control: tags -1 moreinfo
>
> Hallo Stephen,
>
> (not taking ownership of the bug as I cannot guarantee to find time for
> follow ups. Other DDs are welcome to take this bug)
>
> Many thanks for your intention to adopt your pacakge.
> I see that you're also upstream of it; this means that I can also
> request to fix some upstream parts, like the build system ;-)
>
> here is a review:
>
> - d/changelog is incomplete. You've changed quite a bit in the debian
> packaging, more than "new upstream reelase" ;-)
> Please make sure that you really document everything you changed,
> (and as this is often done wrong, the changelog should ensure that
> it explains the "why (have it been changed)" adequately.
>
> - d/patches
>   - they could have use of a dep3 header
>   - as you're upstream, do you plan to roll out a new release with
> them? (question out of curiosity, not required for sponsoring)
>
>autoconf patch:
>   - you should not patch config.guess. They need to be updated on
> build-time! (autotools-dev is your friend, and debhelper with
> compat level 10 will be even better.)
>dependency-created-noise patch:
>- I'm not sure about this patch. What is its purpose?
>  The header reads as it is for canceling changes due to the build
>  process? Looks like it is regenerated at build time? If so, it
>  should not be patched but mereley deleted in the clean target.
>  (Otherwise the build system should be fixed that this is not
>   needed; automake is capable to create dependencie)
>
> - d/copyright should be transferred to dep5 format.
>
> - Please disable silent rules (the buildlog should emit all compiler
> flags)
>
> - d/rules should be converted to short debhelper format.
>   - the buildsystem should be really fixed to properly clean up.
>   - otherwise, errors from rm should not be ignored, also not errors
> from make realclen. Just don't execute it when there is no Makefile.
>
> (Stopping here for time reasons; especially I did not do a d/copyright
> audit, not checked the upstream code)
>
> Please fix above, remove the moreinfo tag, and -- time permitting -- I
> will iterate.
>
> --
> tobi
>
>

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "tinymux". I am the upstream
maintainer, and there is already an ITA from me against the package.

* Package name: tinymux
  Version : 2.10.1.13-1
  Upstream Author : Stephen Dennis <brazilof...@gmail.com>
* URL : http://www.tinymux.org/
* License : Artistic
  Section : games

It builds these 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.13-1.dsc

Changes since the last upload:

  * New upstream release


Regards,
Stephen Dennis

Bug#817804: RFS: tinymux/2.6.5.34-1 NMU

[Stephen Dennis]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "tinymux"

 Package name: tinymux
 Version : 2.6.5.34-1
 Upstream Author : Stephen Dennis <brazilof...@gmail.com>
 URL : http://www.tinymux.org
 License : GPL
 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:
http://mentors.debian.net/package/tinymux


Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/t/tinymux/tinymux_2.6.5.34-1.dsc

More information about hello can be obtained from http://www.example.com.

Changes since the last upload:

tinymux (2.6.5.34-1) unstable; urgency=low

  * Non-maintainer upload
  * Fix "FTBFS with GCC 6: narrowing conversion"  (Closes: #811780)
  * Fix "use autotools-dev to update config.{sub,guess} for new arches"
 (Closes: #736863)
  * Fix "[Mayhem] Bug report on tinymux: netmux crashes with exit status
139"  (Closes: #716615)
  * Fix "run dh-autoreconf to update for new architectures"  (Closes: #759448)

 -- Stephen Dennis <brazilof...@gmail.com>  Thu, 10 Mar 2016 06:01:09 +


Regards,
Stephen Dennis