Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
On 01/27/2012 01:45 PM, Jakub Wilk wrote:
> * Stephen M. Webb <stephen.webb@bregmasoft.ca>, 2012-01-26, 12:05:
>
>> since the library is a part of an MMORPG stack, and I anticipate a
>> newer client app revision getting in to Debian long before a new
>> server app, so the coexistence of both old and new SONAMEs will be
>> required, at least for a little while.
>
> Could elaborate more of this? What is "client app" and "server app" in
> this context?
The MMORPG server and client both use this library. While both are
actively developed upstream, the server has been removed from Debian
because it has been unmaintained for too long and will require going
through the ITP process (I believe, please correct me if I'm wrong).
The client has merely been orphaned, and I currently have an ITA on it.
The server package is still available in derivates (like Ubuntu) as a
binary package and will continue to depend on the older libraries until
a newer upstream is available. Mean time, the newer client is
wire-protocol compatible with older servers, so it's more important to
focus on that.
> Please bear in mind that having multiple versions of the same source
> package in a single suite is not really a desired state.
>
> As far as unstable is concerned, you don't have control over when the
> old package will be removed. While I think ftp-masters usually wait
> until the old version don't have rdepeds anymore, they can also do it
> whenever they see fit (possibly rendering not-yet-rebuilt packages
> uninstallable).
>
> Until very recently, it wasn't even possible (unless some dirty hacks
> were involved) to keep multiple versions of a library in testing. It's
> doable now, but such a state certainly doesn't make the Release Team happy.
Assuming the remaining packages in the WorldForge stack get uploaded, it
does not matter to me that the older libraries are available. I am just
starting at the bottom of the dependency stack wit this package.
> Did you build in unstable? I just did (with DEB_BUILD_OPTIONS=noopt),
> and saw this in the build log:
>
> /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
> -I.. -I.. -g -O2 -Wall -DNDEBUG -c -o sksocket.lo sksocket.cpp
OK, this is the famous noppt bug in dh. Fixed by bumping up to compat
level 9. Seems someone changed the default behind my back while I
wasn't looking. Unfortunately this bump pulls in the magic of
multi-arch, but fortunately that does not harm and dependent packages
continue to build OK.
>> I would appreciate an explicit list of any apparent regressions, since
>> they aren't apparent to me from the build logs or runtime testing of
>> the package.
>
> I didn't have anything specific in mind (except noopt support). Looking
> at old debian/rules there are some things that dh certainly doesn't do:
> - setting LDFLAGS=-lstdc++;
> - passing --disable-debug to configure.
> Maybe these were no-ops or simply wrong. Maybe not. I didn't check. :)
The GCC c++ compiler links with its library now, since version 3.0. The
default config is --disable-default. Yes, these are noops.
> Now some things I didn't catch in my initial review:
>
> The package descriptions were modified, but this is not documented in
> the changelog.
Nice catch. Remediated.
> The .orig.tar is compressed with bz2, but uscan would download a
> .tar.gz. I see the upstream provides bzip2ed tarballs too, so it should
> be a matter of fixing debian/watch.
OK, done.
New package uploaded to
http://mentors.debian.net/debian/pool/main/s/skstream/skstream_0.3.8-1.dsc
Changes:
skstream (0.3.8-1) unstable; urgency=low
.
* new maintainer: Debian games team (closes: #653977)
- added myself as uploader
* new upstream release
* changed package description (iostream, not isostream)
* renamed binary packages due to SONAME change
* converted packaging to use dh sequenceer
* converted packaging to 3.0 (quilt) format
* updated Standards-Version to 3.9.2 (no changes required)
* added debian/symbols file
* added VCs- fields to debian/control
* debian/copyright: convert to DEP-5 format
* debian/compat: set to compatibility level 9
* debian/rules: add --with autoreconf to regenerate autoconfigury
* debian/control: tweaked for multi-arch
--
Stephen M. Webb <stephen.webb@bregmasoft.ca>
Reply to: