Re: [j...@debian.org: Your Debian package(s) will not migrate to testing]
On Thu, Sep 05, 15:57, Andrey Rahmatullin wrote > On Thu, Sep 05, 2019 at 12:47:43PM +0200, Andre Noll wrote: > > > > There have been no changes since June, so your existing repo should > > > > still be uptodate. > > > > > > You will need to upload a new version, though; the system will not > > > accept a package with the same version number. > > > > I've released and tagged v1.0.1. Adam, please use the tip commit of > > the current master branch instead. > You don't need to make new upstream releases for changeless source uploads. Well, the last upstream release was more than a year ago, and some fixes and improvements went in since then, so I felt it was about time to make a new release anyway. But yes, I guess it would have been enough to just bump the debian version (last digit) in debian/changelog. Thanks for the hint Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Re: [j...@debian.org: Your Debian package(s) will not migrate to testing]
On Thu, Sep 05, 10:57, Julian Gilbey wrote > > There have been no changes since June, so your existing repo should > > still be uptodate. > > You will need to upload a new version, though; the system will not > accept a package with the same version number. I've released and tagged v1.0.1. Adam, please use the tip commit of the current master branch instead. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
[j...@debian.org: Your Debian package(s) will not migrate to testing]
Hi Adam, looks like tfortune needs a new source-only upload to migrate to testing. Could you please do this for me? Here's the commands to build the source package: git archive --prefix tfortune-1.0.0/ origin/master > ../tfortune_1.0.0.orig.tar.xz dpkg-buildpackage -S There have been no changes since June, so your existing repo should still be uptodate. Thanks Andre - Forwarded message from Julian Gilbey - Subject: Your Debian package(s) will not migrate to testing From: Julian Gilbey To: Andre Noll Message-Id: Date: Wed, 04 Sep 2019 22:16:56 +0100 Dear Andre Noll, This is a courtesy message about your package(s) which is/are stuck in sid, and will not migrate to testing, in case you are unaware; they are listed below. The release managers announced on 7th July 2019 in their email to debian-devel-announce and debian-release (Message-ID: <20190707014700.gf15...@powdarrmonkey.net>) that only source-only uploads would transition to testing. Here is the relevant part of what they wrote: ~ No binary maintainer uploads for bullseye = The release of buster also means the bullseye release cycle is about to begin. >From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. Q: I already did a binary upload, do I need to do a new (source-only) upload? A: Yes (preferably with other changes, not just a version bump). Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. Q: Does this also apply to contrib and non-free? A: No. Not all packages in contrib and non-free can be built on the buildds, so maintainer uploads will still be allowed to migrate for packages outside main. ~ To perform a source-only build and upload, run dpkg-buildpackage -S and then upload the relevant files in the normal way (for example, using dupload or dput). Your package(s) involved is/are as follows: Source package: tfortune Version: 1.0.0-2 One relevant line of the excuse file (including the uploader): Not built on buildd: arch amd64 binaries uploaded by kilobyte Transition verdict: REJECTED_PERMANENTLY I hope this is of help to you! Best wishes, Julian - End forwarded message - -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Wed, Jun 19, 14:01, Adam Borowski wrote > > Both issues have been fixed in v2 of the t/tfortunes branch which > > I've just pushed out. This branch also contains two new commits > > which fix a gcc warning and a harmless memory leak. > > Uploaded, with some changes. Thanks a bunch for fixing my mistakes! > > PS: I shall be offline until next Tuesday. > > To skip the wait, I applied some fixes myself. They are: a bogus > day-of-week (which our tools detect and complain about) and the data package > not being Arch:all. Here's the diff: [snip] I've applied your patch and folded in the fixes into the existing commit. See the v2 -> v3 section of the modified commit message. Thanks again Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Tue, Jun 18, 17:48, Adam Borowski wrote > > Here we go. The public repo now contains the t/tfortunes branch with > > the following four commits on top of master: > > Looks good. > > However, version 1.0.0-1 is already in NEW, thus unless it's REJECTed, the > version number cannot be reused. > > There's also a typo: "considerd". Thanks for the review. Both issues have been fixed in v2 of the t/tfortunes branch which I've just pushed out. This branch also contains two new commits which fix a gcc warning and a harmless memory leak. Best Andre PS: I shall be offline until next Tuesday. -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Fri, Jun 07, 10:39, Andre Noll wrote > > > OK. Do you think it makes sense to provide another package which > > > installs a few tagged epigrams in, say, /usr/share/games/tfortunes > > > and make tfortune fall back to this directory if ~/.tfortune does > > > not exist? > > > > That'd be nice. > > > > What about tfortune-data that ships as many good epigrams as you have, > > that's Recommended: by tfortune? > > Sounds good. I've merged and pushed out the t/debian branch so > that current master corresponds to what you have uploaded. I'll come > back to you when the tfortune-data package is ready. Here we go. The public repo now contains the t/tfortunes branch with the following four commits on top of master: de10d1 Add a few sample epigrams and the fortunes package. f36a62 Fall back to system-wide epigram directory. 79362d Make errors from regfile_iter_new() non-fatal. 278b70 com_stats(): Avoid division by zero. The commit messages contain more information about the new feature and the epigram file. Please have a look. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Thu, Jun 06, 12:56, Adam Borowski wrote > > > The RFS and ITP are unrelated. > > > > IDGI. For an RFS email one needs to provide the source package with > > a debian/ directory, correct? If so, the debian/changelog file must > > contain a line of the form > > > > * Initial Release. Closes: #929467 > > > > But the number will only be assigned after the mail has been sent. > > What am I missing here? > > You file ITP stating you intend to work on package X. > > Once you're done, you file a RFS. I see, will keep this in mind for the next submission. > > OK. Do you think it makes sense to provide another package which > > installs a few tagged epigrams in, say, /usr/share/games/tfortunes > > and make tfortune fall back to this directory if ~/.tfortune does > > not exist? > > That'd be nice. > > What about tfortune-data that ships as many good epigrams as you have, > that's Recommended: by tfortune? Sounds good. I've merged and pushed out the t/debian branch so that current master corresponds to what you have uploaded. I'll come back to you when the tfortune-data package is ready. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Wed, Jun 05, 01:40, Adam Borowski wrote > On Tue, Jun 04, 2019 at 05:06:00PM +0200, Andre Noll wrote: > > v3 is pushed out now and contains > > a simple debian/rules file which fully relies on dh. Besides > > dh_auto_configure I also had to override dh_autoreconf for reasons > > explained in the commit message. > > The package looks almost good now. You do close a completely unrelated ITP > bug though: "ITP: eazel-engine". That's the old hen and egg problem: One needs to provide a bug number in debian/changelog for the initial RFS, i.e. before the bug has been opened. So I put a dummy number there and forgot to update it after the bug number had been assigned. Fixed now. > On the other hand, the package neither ships any data files, nor can't > handle their lack gracefully: it crashes with: > regfile_iter_new: opendir /home/kilobyte/.tfortune/epigrams: No such file or > directory I'd argue that this is not a crash but a graceful exit due to a fatal error :) But yeah, the error message could be more user-friendly. We could make it print something like fatal: could not open epigram directory and a similar message for the tag expression directory. Alternatively, tfortune could create the two directories at startup. What do you think? Best Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Wed, Jun 05, 10:41, wf...@niif.hu wrote > > I also had to override dh_autoreconf for reasons explained in the > > commit message. > > It isn't a packaging issue, I just wonder: why do you wrap configure? > The usual approach to making it available is distributing it (and not > requiring Autoconf to build the software from the distribution tarball, > only to build it from the VCS checkout). It's a feature. With the configure wrapper you can always do ./configure --foo --bar && make regardless of whether the real configure script, configure.sh, exists or not (it does not exist after a fresh clone or after git clean -dfqx, for example). And this command also works if configure.sh is outdated, for example after the checkout of a different branch which touches configure.ac. So you don't have to remember to run ./autogen.sh or similar to update the autoconf files. Even better, plain "make" also works out of the box with missing or outdated autoconf files. It recreates the real configure script and runs it if necessary (with the same arguments as in the previous invocation). Also note that there are no distribution tarballs for tfortune, just (signed) tags. Yes, this requires git and autoconf being installed in order to compile from source. However, generating signed distribution tarballs that contain not only the source but also a certain set of generated files is tedious and has no real advantage, since people who have gcc installed usually also install autoconf. Putting those generated files under version control is even worse IMO. Best Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Sun, Jun 02, 22:57, Adam Borowski wrote > On Sat, Jun 01, 2019 at 11:17:53PM +0200, Andre Noll wrote: > > Adam, do you want me to provide v3 with debian/rules changed to > > something like the above? > > v2 still suffers from the non-standard perms on usr/ and so on, thus I guess > it'd be simpler to move to the dh workflow rather than to fix what you > currently have. > > It's by no means mandatory, but our newly elected Dear Leader is waging a > campaign to make it strongly recommended, especially for new packages. I > quite see why. And I for one prefer packages where a reviewer doesn't have > to fire up the brain to comprehend what's being done. :) This is a compelling argument. v3 is pushed out now and contains a simple debian/rules file which fully relies on dh. Besides dh_auto_configure I also had to override dh_autoreconf for reasons explained in the commit message. Please review. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Sat, Jun 01, 16:46, Alexis Murzeau wrote
> I think Adam meant to not implement low level makefile targets yourself,
> but use dh like this:
> ```
> #!/usr/bin/make -f
>
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> %:
> dh $@
>
> override_dh_auto_configure:
> dh_auto_configure -- \
> --bindir=\$${prefix}/games \
> --datadir=\$${prefix}/share/games
> ```
That's indeed much simpler and seems to work as well. Thanks for
pointing this out!
Adam, do you want me to provide v3 with debian/rules changed to
something like the above?
Note, however, that building with the simple debian/rules file prints a
warning because dh_auto_configure seems to add --disable-silent-rules,
--disable-maintainer-mode and --disable-dependency-tracking to the
configure command line, which tfortune's configure doesn't know.
This seems to be a common problem. One solution is to call configure
directly, as recommended in the dh_auto_configure man page. Another way
to avoid the warning is to provide noop-stubs for the three options
in configure.ac. I'd prefer to call configure directly because this
is a bit simpler and touches only debian/rules. Opinions anybody?
Best
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
On Fri, May 31, 17:32, Adam Borowski wrote > On Fri, May 24, 2019 at 08:57:49AM +0200, Andre Noll wrote: > > * Package name: tfortune > >Version : 1.0.0 > > > git clone git://git.tuebingen.mpg.de/tfortune/ > > Hi! > I'm afraid your packaging unnecessarily reinvents a good part of usual > tools, and does this wrong. For example: > * directories have non-standard permissions, and this affects common dirs as > well Oops, this was indeed broken. Should be fixed now. > * gzip is invoked without -n, which renders the package non-reproducible That was also easy enough to fix. I've added -n to both gzip commands. > * standard build flags don't get passed to the compiler Can you elaborate this concern? The Makefile does add $(CPPFLAGS) and $(CFLAGS) to the cc command and $(LDFLAGS) to the linker command. Which standard build flags don't get passed? > * no md5sum files are generated Fixed. I've pushed out v2 of the t/debian branch, which addresses all concerns except the one about the build flags. Would you please have another look? Thanks for your feedback Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#929467: RFS: tfortune-1.0.0 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tfortune": * Package name: tfortune Version : 1.0.0 Upstream Author : Andre Noll * URL : http://people.tuebingen.mpg.de/maan/tfortune/ * License : GPLv3 Section : games It builds the following binary package: tfortune - fortune cookies with tags About: tfortune is a re-implementation of the venerable fortune program with a couple of additional features for epigram selection and management. It depends on the lopsub library which was recently uploaded to unstable but has no other unusual requirements. Quoting from the above web page: Like fortune(1), tfortune is a Unix command line utility which prints a random epigram. Epigrams are stored as plain text files, but they must be annotated with tags to make full use of the features which tfortune offers over other implementations. Tfortune has a built-in matching language for epigrams. User-supplied tag expressions define subsets of admissible epigrams. If a tag expression is given, epigrams are picked from the admissible subset only. You can grab a copy by running git clone git://git.tuebingen.mpg.de/tfortune/ This will get you three branches: master, pu, and t/debian The t/debian branch contains a two of commits on top of master which add the debian/ directory with the usual files in it. The commands git checkout origin/t/debian git archive --prefix tfortune-1.0.0/ @ | xz > ../tfortune_1.0.0.orig.tar.xz dpkg-buildpackage should work as expected. This has been tested on debian-9, debian-10 and debian-11. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Mon, Apr 22, 17:30, Andre Noll wrote > > But in general, the package already seems to be in a releasable state. > > Could you please change "UNRELEASED" to "unstable" so it can be uploaded? > > Done. Please have a final look. If everything is fine, I can merge > the various topic branches to master (so that master becomes what is > pu now), and tag the result as v1.0.3. Ping Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Sun, Apr 21, 22:25, Adam Borowski wrote > On Sun, Apr 21, 2019 at 05:11:05PM +0200, Andre Noll wrote: > > That's just because I misread section 8.1 of the Debian Policy Manual. > > I've renamed the -dev package to liblopsub-dev. > > Not sure if you'd want the _source_ package to have a simple soname-less > name as well; I would but that's up to you -- that'd be nicer and make > having only-one-version transitions easier; on the other hand a > soname-encoded source name is better when there's a need for multiple > coinstallable versions. There are no plans for multiple incompatible versions. Instead, the plan is to keep the ABI compatible forever, using symbol versioning if necessary. Therefore I've changed the name of the source package from liblopsub1 to liblopsub. > * installation instructions don't really belong in the man page -- if you > can read it, you've already managed to install the package. Right. OTOH, the instructions might be helpful for the web page, which is just the html version of lopsub.7. I've moved the instructions to the README file, and adjusted lopsub.7 slightly. > * please copy the description for liblopsub1 to liblopsub-dev; it currently > says just "This package contains the development environment for the > lopsub library." It's pointless to require the user to check the other > package -- other libraries alter merely the last part. Also, it's -dev > what users pull by hand. Done. > * is there a reason for shipping the static library? Static linking is > frowned upon in a distribution -- whenever the library gets updated, > every reverse dependency has to be recompiled; this is especially nasty > for security updates. The main reason I've kept it is that the Debian Policy Manual says The static library (libraryname.a) is usually provided in addition to the shared version. But yes, nobody needs the static library, so I've removed it from the build. > * (bonus) The nicely documented process for building the example looks > like something that could be turned into an autopkgtest. Unlike > build-time tests, autopkgtests are run against installed packages, > the way an user would. That's of course extra effort, by no means > required -- but, extra testing is always good. I guess I need some help here. https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html describes the format of debian/tests/control, but does not say how to set up the test environment. Since the tests do not need to run as root, and do not access the network either, a simple chroot environment should be fine. But how do I set up such an environment for use with autopkgtest? > But in general, the package already seems to be in a releasable state. > Could you please change "UNRELEASED" to "unstable" so it can be uploaded? Done. Please have a final look. If everything is fine, I can merge the various topic branches to master (so that master becomes what is pu now), and tag the result as v1.0.3. Thanks Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Sun, Apr 14, 15:41, Adam Borowski wrote
> On Sat, Apr 06, 2019 at 09:52:53PM +0200, Andre Noll wrote:
> > > > I see a static library installed by the package. Those shouldn't
> > > > generally
> > > > be used unless you're doing something special -- static linking makes
> > > > security and bugfix updates extremely tedious. Libraries should also be
> > > > split into separate binary packages, with lib${name}dev providing
> > > > development files while lib${name}${so} the runtime lib.
>
> I'm afraid that the shared library doesn't work: liblopsub1 in /usr/lib
> has nothing but an infinite symlink loop from liblopsub.so.unnamed_version
> back to itself.
It worked when compiling from git, but the generated source tarball
was broken because the version.gen.sh script relied on git. This has
been fixed now.
> Besides a proper soname, the file should also go to a multiarch dir (ie,
> /usr/lib/x86_64-linux-gnu on amd64, /usr/lib/aarch64-linux-gnu on arm64,
> etc -- most build systems get it right without your action).
Done.
> Also, I wonder why you include the soname in the -dev package's name.
> That's allowed but usually not what you want -- an ABI break will also
> require changing every depending package instead of a simple recompile.
> Unless you change the API every time there's a soname bump, it'd be
> better to have the -dev package be unversioned. But this is up to you.
That's just because I misread section 8.1 of the Debian Policy Manual.
I've renamed the -dev package to liblopsub-dev.
Please find the updated repository at the usual location. As before,
you have to check out the "pu" branch:
git clone git://git.tuebingen.mpg.de/lopsub.git
cd lopsub
git checkout origin/pu
git archive --prefix liblopsub1-1.0.2/ @ | xz >
../liblopsub1_1.0.2.orig.tar.xz
dpkg-buildpackage
If there are further issues, just let me know.
Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Sat, Apr 06, 21:52, Andre Noll wrote
> On Mon, Apr 01, 00:57, Andre Noll wrote
>
> > > I see a static library installed by the package. Those shouldn't
> > > generally
> > > be used unless you're doing something special -- static linking makes
> > > security and bugfix updates extremely tedious. Libraries should also be
> > > split into separate binary packages, with lib${name}dev providing
> > > development files while lib${name}${so} the runtime lib.
> >
> > Yes, I had this concern as well. I'll change the build system to
> > create a shared library instead and split the binary package as you
> > suggest. I'll follow up with another reply when it's ready.
>
> Meanwhile I've addressed these two issues and fixed the remaining
> lintian warnings. Please have a look at the current "pu" branch of
> the lopsub repo (pu: proposed updates). This branch merges the various
> topic branches, notably the branch which adds the debian/ directory and
> the branch which adds support for shared libraries. dpkg-buildpackage
> now builds two binary packages called liblopsub1 and liblopsub1-dev.
>
> To create the .deb files, run something like
>
> git clone git://git.tuebingen.mpg.de/lopsub.git
> cd lopsub
> git checkout origin/pu
> git archive --prefix liblopsub1-1.0.2/ @ | xz >
> ../liblopsub1_1.0.2.orig.tar.xz
> dpkg-buildpackage
>
> This should work on debian-9 and debian-10. I've checked that the
> two packages can be installed with dpkg -i and that all projects of
> mine which depend on lopsub compile and work as before. ldd shows
> that the resulting executables are now linked against the dynamic
> library rather than the static one (which still gets installed as
> part of the -dev package).
>
> If there are further issues, just let me know.
Ping
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Mon, Apr 01, 00:57, Andre Noll wrote
> > I see a static library installed by the package. Those shouldn't generally
> > be used unless you're doing something special -- static linking makes
> > security and bugfix updates extremely tedious. Libraries should also be
> > split into separate binary packages, with lib${name}dev providing
> > development files while lib${name}${so} the runtime lib.
>
> Yes, I had this concern as well. I'll change the build system to
> create a shared library instead and split the binary package as you
> suggest. I'll follow up with another reply when it's ready.
Meanwhile I've addressed these two issues and fixed the remaining
lintian warnings. Please have a look at the current "pu" branch of
the lopsub repo (pu: proposed updates). This branch merges the various
topic branches, notably the branch which adds the debian/ directory and
the branch which adds support for shared libraries. dpkg-buildpackage
now builds two binary packages called liblopsub1 and liblopsub1-dev.
To create the .deb files, run something like
git clone git://git.tuebingen.mpg.de/lopsub.git
cd lopsub
git checkout origin/pu
git archive --prefix liblopsub1-1.0.2/ @ | xz >
../liblopsub1_1.0.2.orig.tar.xz
dpkg-buildpackage
This should work on debian-9 and debian-10. I've checked that the
two packages can be installed with dpkg -i and that all projects of
mine which depend on lopsub compile and work as before. ldd shows
that the resulting executables are now linked against the dynamic
library rather than the static one (which still gets installed as
part of the -dev package).
If there are further issues, just let me know.
Thanks
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Sat, Mar 30, 23:58, Adam Borowski wrote
> On Thu, Mar 28, 2019 at 11:41:45AM +0100, Andre Noll wrote:
> > * Package name: lopsub
> >Version : 1.0.2
>
> Such a version means a native package; only software written specifically
> for Debian which makes no sense outside it should use the native format.
> Even if you're both upstream and the packager, a non-native format is
> helpful in case someone other than you would upload a fix.
>
> This library is certainly not something for Debian only, thus please append
> "-1" to the version, and set debian/source/format to "3.0 (quilt)" (which,
> despite the name, doesn't require actually using quilt).
Sure, I just wasn't aware of this convention, and that "3.0 (quilt)"
is the right choice for a package like lopsub. One question: With this
change applied, dpkg-buildpackage wants the upstream tarball in the
parent directory. I guess I'm supposed to run git archive here to
create it as part of the before-build hook, but I couldn't figure
out where this hook is defined.
> >Upstream Author : Andre Noll
> > * URL : http://people.tuebingen.mpg.de/maan/lopsub/
> > * License : (L)GPLv3
>
> It would be nice to mention more prominently what parts are GPLv3-ed and
> which are LGPLv3-ed.
The library is LGPLv3 while the lopsubgen executable is GPLv3. The
source code generated by lopsubgen is licensed with a simple
all-permissive license. See lopsub.7 for more information. I've
changed debian/copyright to make this distinction stand out a bit more.
> I'd recommend running "lintian -i" which gives a long descriptive message
> for every warning, including hints how to fix.
Point. This was a very helpful hint indeed. With the long descriptions,
it was easy to squash the remaining few warnings.
> I see a static library installed by the package. Those shouldn't generally
> be used unless you're doing something special -- static linking makes
> security and bugfix updates extremely tedious. Libraries should also be
> split into separate binary packages, with lib${name}dev providing
> development files while lib${name}${so} the runtime lib.
Yes, I had this concern as well. I'll change the build system to
create a shared library instead and split the binary package as you
suggest. I'll follow up with another reply when it's ready.
Thanks a bunch for the review
Andre
--
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
signature.asc
Description: PGP signature
Bug#925911: RFS: lopsub-1.0.2 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lopsub": * Package name: lopsub Version : 1.0.2 Upstream Author : Andre Noll * URL : http://people.tuebingen.mpg.de/maan/lopsub/ * License : (L)GPLv3 Section : libdevel It builds the following package: lopsup - The Long Option Parser for Subcommands To access further information about this package, please visit the above URL. About lopsub: It's not a new idea to provide a library for parsing command line options as there are libargtable2 and gengetopt which are conceptually similar. Nevertheless, here is yet another option parser which was written already some years ago. Compared to the existing option parsers, lopsub offers a couple of additional features, for example support for subcommands and direct man page generation. It is actively maintained, yet mature, and the API is stable and well documented. Although no debian packages use the lopsub library so far, it makes sense to get this in because (a) it makes life easier for people who want to use software that depends on lopsub [1], and (b) it paves the way to debianize those software packages as well. Moreover, lopsub is tiny and has no build dependencies other than a C compiler, flex and m4. The binary package has no dependency other than libc. This is my first attempt to get a package sponsored, and also my first attempt to create a debian package. I've tried to address the issues listed in the docs and I believe the package is ready for upload. However, there are still some warnings from lintian I don't know how to deal with. While there is certainly some room for improvement, I'm confident that the remaining issues can be addressed easily. You can grab a copy by running git clone git://git.tuebingen.mpg.de/lopsub.git This will get you three branches: master, pu, and t/debian The t/debian branch contains a single commit on top of master which adds the debian/ directory with the usual files in it. The commands git checkout origin/t/debian dpkg-buildpackage should build the debian package as expected. This has been tested on debian-9 and debian-10. This package is known to compile and work on Debian and Ubuntu Linux (x86_64, x86_32, armv6l), FreeBSD-12.0 (x86_64) and NetBSD-8.0 (x86_64). Thanks Andre --- [1] http://people.tuebingen.mpg.de/maan/ -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
