Updating the debian package from TinyMUX 2.6 to say TinyMUX 2.11

[Stephen Dennis]

I'm starting to get build failure messages for some platfroms. We should find a new Debian maintainer to freshen the package to a later version. The required files are already under source control.

Any ideas? My search leads to 'New Maintainer's Guide" and "4 months since the last Debian Maintainer was approved".

In other news, I suspect the old PCRE version will become a submission roadblock at some point if it isn't already.I'm steadily bumping the version of that in TinyMUX 2.12, but there is no release of that out there (people are still using it).

Stephen

[Emily Backes]

> I'm starting to get build failure messages for some platfroms. We
> should find a new Debian maintainer to freshen the package to a
> later version. The required files are already under source control.

I've been looking into (okay, daydreaming) about doing that, at least
with my branch. For what it's worth though, I can build on Debian 8
(Jessie) with no trouble. I've made some significant changes to
configure.ac and the Makefile.in infrastructure, though.

I'm poking toward the direction of making the old Debian-style
install-- single set of binaries/libraries/modules and a script to
deploy new "game/" instances as the default install type.

I suspect that getting people to actually go along with that will be
the harder part. I'm inclined to make git a pre-req for the deploy
script so that updates are more easy to merge in, but that might be
asking for trouble.

> Any ideas? My search leads to 'New Maintainer's Guide" and "4 months
> since the last Debian Maintainer was approved".

Well, we can probably get it ready to go on a number of architectures
independent of that. Debian Linux 8 on x86_64 is my primary dev
platform, and i386 is reasonably straightforward to test. I can
probably test on Solaris Sparc/Intel, AIX, HP-UX PA-RISC/Itanium (heh,
yes really), Linux on ARMv6, and OS X if there is interest.

I rather doubt the more arcane unixes are going to be of interest to
anyone other than me, but there's likely some jackass keen on running
a MUX server on their raspberry pi.

I will be pursuing the MSYS/MinGW build angle as an alternative to
providing regular builds on win32/64.

> In other news, I suspect the old PCRE version will become a submission
> roadblock at some point if it isn't already.I'm steadily bumping the
> version of that in TinyMUX 2.12, but there is no release of that out there
> (people are still using it).

The Reach has been on 2.12 for several weeks now and been nicely
stable. Mudstats lists the 30 day max at 350 users, so I wager its
getting a good pounding. A fair chunk of that code uses regexes and a
great deal of inline sql() chicanery. Complaints have been minimal,
save for the one you already found to be unrelated. Memory is at 127M
virtual, 105M resident, so I suspect their are no big new leaks.

Speaking of-- been poking around with dropping the slab allocator
entirely to use just straight malloc() stuff for everything and then
using a better malloc like TCmalloc. I won't recommend this until I
have some performance numbers to back it up, but at a minimum it will
make leaktesting with modern tools a great deal easier.

--
Emily Backes
lash...@gmail.com

[Stephen Dennis]

On Wed, Aug 20, 2014 at 6:58 PM, Emily Backes <lash...@gmail.com> wrote:

> I'm starting to get build failure messages for some platfroms. We
> should find a new Debian maintainer to freshen the package to a
> later version. The required files are already under source control.

I've been looking into (okay, daydreaming) about doing that, at least
with my branch.  For what it's worth though, I can build on Debian 8
(Jessie) with no trouble.  I've made some significant changes to
configure.ac and the Makefile.in infrastructure, though.

I understand you to mean you aren't sure whether the stock code builds on Debian 8 because you've made changes. But, if you mean you think those significant changes are probably required, then I'd want to understand each change. 

 

I'm poking toward the direction of making the old Debian-style
install-- single set of binaries/libraries/modules and a script to
deploy new "game/" instances as the default install type.

Hence the significant changes? Or, is this something different that harmonizes the style of FreeBSD package with the Debian package?

I suspect that getting people to actually go along with that will be
the harder part.  I'm inclined to make git a pre-req for the deploy
script so that updates are more easy to merge in, but that might be
asking for trouble.

Oh, I don't expect many people to be persuaded to use either. Most people will still download the tarball and build that way. Any Debian, Ubuntu, or FreeBSD package is more about broad platform exposure.

> Any ideas? My search leads to 'New Maintainer's Guide" and "4 months
> since the last Debian Maintainer was approved".

Well, we can probably get it ready to go on a number of architectures
independent of that.  Debian Linux 8 on x86_64 is my primary dev
platform, and i386 is reasonably straightforward to test.  I can
probably test on Solaris Sparc/Intel, AIX, HP-UX PA-RISC/Itanium (heh,
yes really), Linux on ARMv6, and OS X if there is interest.

Testing on Solaris et al, is welcome, but my immediate focus is narrower. The existing Debian package is just stale. The package files have old version numbers which are now depreciated. The autoconf.guess-related files (which we do not author) are just old and no longer detect the newer platforms, so we get build errors for that simple reason. It's not more complicated than that.

I rather doubt the more arcane unixes are going to be of interest to
anyone other than me, but there's likely some jackass keen on running
a MUX server on their raspberry pi.

Right. Building on those arcane platforms is more about clean living. If they stop building, it is an indication that the main ones may also eventually stop building. That's really all.

 

I will be pursuing the MSYS/MinGW build angle as an alternative to
providing regular builds on win32/64.

Cygwin builds did work. I haven't tried them recently, but I assume they still work. You're welcome to poke at MSYS/MinGW, but that is again separate work that extends what is -- not an immediate ask.

 

> In other news, I suspect the old PCRE version will become a submission
> roadblock at some point if it isn't already.I'm steadily bumping the
> version of that in TinyMUX 2.12, but there is no release of that out there
> (people are still using it).

The Reach has been on 2.12 for several weeks now and been nicely
stable.  Mudstats lists the 30 day max at 350 users, so I wager its
getting a good pounding.  A fair chunk of that code uses regexes and a
great deal of inline sql() chicanery.  Complaints have been minimal,
save for the one you already found to be unrelated.  Memory is at 127M
virtual, 105M resident, so I suspect their are no big new leaks.

Thanks.

 

Speaking of-- been poking around with dropping the slab allocator
entirely to use just straight malloc() stuff for everything and then
using a better malloc like TCmalloc.  I won't recommend this until I
have some performance numbers to back it up, but at a minimum it will
make leaktesting with modern tools a great deal easier.

Sounds good. I took the four-line change you made.

 

--
Emily Backes
lash...@gmail.com

[Stephen Dennis]

And really, even the required changes for submitting a new Debian package are done and checked in. Literally just need an official Debian maintainer to pick it up the pieces.