Re: Quoting Hell in Manual Pages, or lintian problem?
Marc Haber writes: > How would I quote backslashes in a manual page correctly? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966803#14: if you want to *emit* a backslash, use \e. > Currently I have the source: > > with '"' around each argument, each '"' > in the string converted to '\\"' and each '\\' in the string > converted to ''. > > This renders to: > > with '"' around each argument, each '"' > in the string converted to '\"' and each '\' in the string > converted to '\\'. > > which looks reasonable enough. > > However lintian doesn't like this and flags the construct with > "acute-accent-in-manual-page". Is this a bug in Lintian? Lintian is honorably losing against nroff here. I wouldn't dare to correct it either. However, if you want to use single quotes in your manual pages, note that ' as the first character of the line is active, which is bound to catch you when you least expect it. They are extremely quirky anyway, although Debian killed off at least some of that quirkyness on its own turf. I recommend \(oq\e\e\(cq to get two backslashes between (proper) single quotes. Sorry. -- Regards, Feri
Re: Source with different examples directories
Marc Haber writes: > I have a package which source tarball containst two examples > directories: > > src/examples > src/c++/examples > > Since both directories contain a Makefile, I would like to install > src/examples to /usr/share/doc/package/examples and src/c++/examples to > /usr/share/doc/package/examples/c++. > > This seems to be beyond dh_installexamples' capabilities. > > What would you suggest? I could override dh_auto_installexamples (does > that one exist?), using dh_installexamples to install > src/examples to /usr/share/doc/package/examples and then manually copy > src/c++/examples to /usr/share/doc/package/examples/c++ > > Is there a less ugly way? Hi, I'd use plain dh_install, maybe even for the part dh_installexamples gets right (for symmetry), and skip dh_installexamples. -- Regards, Feri
Re: Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Seunghun Han writes: >>> swtpm - Libtpms-based TPM emulator >>> swtpm-dev - Include files for the TPM emulator's CUSE interface >>> swtpm-libs - Common libraries for TPM emulators >> >> Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? >> Including the SO version in the package name enables installing >> incompatible versions side-by-side, which is useful. >> >> Also, shipping static libraries (like libswtpm_libtpms.a) is generally >> recommended against in Debian. Does this package warrant it? > > The upstream version already has some debian-related files, and I > changed them to adopt the package. The author of it wants to name it > like libswtpm0, so I used the name. The static libraries are also > involved in upstream debian files. Should I change the name like > libswtpm instead of libswtpm0 and remove static libraries from the > package? I questioned the package name, not the names of the shared object within. After a closer look, though, libswtpm_libtpms.so.0.0.0 looks more like an internal convenience library than something which other projects call into. If this is so, the package name loses its relevance, I wonder why it's packaged separately, even. Or why it isn't compiled straight into the single binary (swtpm) linked against it. >>> swtpm-tools - Tools for the TPM emulator >> >> Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and >> swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits >> several Lintian information tags.) > > The author of the upstream project wanted to put them to > /usr/share/swtpm. The files are just for the initialization and don't > be used for TPM operations directly, so maybe he wanted to put > /usr/share/swtpm instead of /usr/bin. Should I move them to /usr/bin? That they have man pages suggests that they are meant for human use. That their man pages are in section 8 suggests that they should live in /usr/sbin. But this is unreliable, since even the *.conf man pages are in section 8, while those belong to section 5. This actually depends on whether the executables are generally used by the system administrator or nonprivileged users (or only internally, in which case the scripts would indeed belong into /usr/share/swtpm). I started to suspect that the current decision wasn't based on the expected usage pattern, but rather on the implementation method (interpreted script or compiled binary), which isn't very useful. But I know too little about the swtpm ecosystem to be sure about the best filesystem layout for the future. -- Regards, Feri
Re: Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Seunghun Han writes: > * Package name: swtpm >Version : 0.7.0-rc2-1 Hi, The upstream version number should be 0.7.0~rc2 with a tilde instead of a hyphen to ensure proper ordering (as Lintian warns about). To do such transformations automatically, put something like this in the watch file: uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ > swtpm - Libtpms-based TPM emulator > swtpm-dev - Include files for the TPM emulator's CUSE interface > swtpm-libs - Common libraries for TPM emulators Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? Including the SO version in the package name enables installing incompatible versions side-by-side, which is useful. Also, shipping static libraries (like libswtpm_libtpms.a) is generally recommended against in Debian. Does this package warrant it? > swtpm-tools - Tools for the TPM emulator Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits several Lintian information tags.) -- Thanks for you work! Regards, Feri
Re: Help With debian/rules File Without Build Tool
Ryan McClue writes: > override_dh_auto_install: > cp program /usr/local/bin Unrelated to your actual question, but this won't work well. You need to install into debian/PACKAGENAME as if it was the filesystem root, that is: cp program debian/PACKAGENAME/usr/bin (after ensuring the directory exists, and using your actual PACKAGENAME). -- Regards, Feri
Re: Help with a syntax error from an autoreconf'ed configure script
John Scott writes: > binutils/libiberty/configure: line 2911: syntax error near unexpected token > `PLUGIN_OPTION' > binutils/libiberty/configure: line 2911: `GCC_PLUGIN_OPTION(PLUGIN_OPTION)' > > This seems bizarre. Why would autoreconf produce a script with a syntax > error, or is dash not robust enough to use what construct it's trying > in the script? I guess GCC_PLUGIN_OPTION (which is meant to be an Autoconf/m4 macro) is not defined in this case for some reason, so it's passed verbatim into the configure script by Autoconf and later misinterpreted by the shell as a function definition. Try to find out why it (and PLUGIN_OPTION) isn't defined in the failing case; it should be provided by config/gcc-plugin.m4, I think. -- Regards, Feri
Re: config file name and format change
Marc Haber writes: > I would like to deliver a YAML config file with the package and have the > old file still supported if an old file is still there (optimally > printing a warning when starting up with old format). I would prefer to > avoid a wrapper script. > > My idea would be to have two distinct systemd units, ser2net and > ser2net-oldconfig, with appropriate ConditionPathExists directives. > > Is there something more elegant? Not sure it's better, but what about checking in the postinst if the old config file is present and if so installing a unit file snippet under /etc/systemd/system/ser2net.service.d overriding the ExecStart line for the old config file? (I wouldn't use /etc/default/ser2net at all.) And of course include a comment asking for its removal. -- Regards, Feri
Re: lintian question - no-debian-changes
Lajos Veres writes: > I am wondering to move the debian folder to a dedicated github > repository to have it version tracked. Or is there any more Debian > friendly place for these debian packaging repositories? Szia Lajos! I prefer Debian packaging branches to separate packaging repositories. See https://wiki.debian.org/PackagingWithGit for a short intro; I like having everything tied together by the --upstream-vcs-tag method. -- Regards, Feri
Re: Built a Debian package using the source code of another one
Hilmar Preuße writes: > the installation/compilation instructions for some proftp modules [1] say: > "To install mod_proxy, go to the third-party module area in the proftpd > source code and unpack the mod_proxy source tarball: [...] > This works fine. How do I do that for a Debian package? After a quick look at https://github.com/Castaglia/proftpd-mod_proxy: I'd try to fix its build system to work against proftpd-dev. That seems to be the intended way after all, so the fix should be accepted upstream. -- Feri
Bug#929467: RFS: tfortune-1.0.0 [ITP]
Andre Noll writes: > 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). -- Regards, Feri
Re: Understanding Git workflow around DEP-14
deb...@lewenberg.com writes: > Looking at DEP-14 I might have these Git branches: > > master > debian/master > debian/stretch > upstream/latest > > I understand that the Debian packaging files in debian/ will appear in > the "debian/*" branch, but my general question is: what is the > workflow around all these branches? When and how do files get merged > from one branch to another? See below for my take on the subject. Don't fear all the complication spelled out, I'm trying to explain the big picture in the most complex setting, so things hopefully start to make sense. In practice it's pretty intuitive once you get the guiding principles. > 1. Besides the debian/ directory, what is the difference between the > "debian/master" branch and the "upstream/latest" branch? Nothing, if you use the "3.0 (quilt)" source format, which you should. upstream/latest tracks the contents of the pristine upstream tarballs. If you use pristine-tar, you can reproduce the exact upstream tarballs from upstream/latest and the appropriate binary deltas (usually stored in a disconnected/orphan branch called pristine-tar). > 2. What should the "master" branch be used for? Whatever your upstream uses it for. As a packager, you use it for cherry-picking upstream commits into your quilt patch queue and for creating upstream pull requests by cherry-picking from your patch queue. In other words: for communicating commits with your upstream. The "master" branch is not special in a packaging repository, it's just one of the upstream branches. The default branch of a packaging repository is usually debian/master. (Some use debian/sid; since uploads from here can target experimental as well, I prefer debian/master.) The point of DEP-14 is to work with a clone of the upstream repository, adding extra branches under the debian/ namespace for packaging for various Debian distributions, under the ubuntu/ namespace for Ubuntu distributions and so on, keeping the package vendors separate while storing upstream tarball contents under the shared upstream/ namespace. The pristine-tar branch is basically an unordered container of binary deltas, so it's unique. > 3. When a new upstream tarball is released, where should it be > imported? In "upstream/latest"? In "debian/master"? Both? It's typically imported into upstream/latest, unless you package from several version series concurrently and thus you have for example an upstream/2.x branch as well: then you import 2.x tarballs into the upstream/2.x branch and 3.x tarballs into upstream/latest. You can name these branches however you please, the point is them being under the upstream/ namespace for all package vendors' use. For best effect these import commits should be formal merge commits: their first parent is the previous import commit, and the second parent is the upstream commit from which your upstream author created the release tarball. This is all formal, just a "note of relations" in the git history; the actual content of the commit is that of the imported release tarball, not influenced by either parent in any way. However, these relations are meaningful and git can use them answering queries like git tag --contains 123456 and similar. Returning to concrete branch names: in the simplest case your upstream author tags commits on the master branch and generates tarballs from them; you then import these tarballs into upstream/latest, formally merging in the tags on the master branch. However, your upstream may as well create their release tags on a release branch (say stable2), and then you import those into upstream/latest all the same, or they can do both and then you might package both release streams importing into upstream/2.x and upstream/latest appropriately; DEP-14 is very flexible. Once the import is done, you fuse it with your packaging work by merging it into debian/master (assuming a single release stream again). This is another formal merge: what actually happens is that you replace the upstream part of the current contents of debian/master with the contents of upstream/latest, keeping the debian directory (ever present in debian/master only) unchanged[1]. Then you adjust your packaging files by committing on debian/master; these commits mustn't touch anything outside the debian/ directory. You can make upstream changes via files under debian/patches. Now, how do you do this all? Simple: $ gbp import-orig --upstream-vcs-tag=v2.3 ../project-2.3.tgz Issue the above command on your debian/master branch, where you committed a debian/gbp.conf file with content like this[2]: [DEFAULT] debian-branch = debian/master upstream-branch = upstream/latest pristine-tar = True [import-orig] merge-mode = replace Instead of specifying the upstream tarball, you can even use --uscan most of the time, if you already have a working debian/watch file. Besides all the git magic described above, this command also creates an upstream/2.3 tag for future reference.
Bug#923050: RFS: pk2/1.2.1-1 [ITP] -- 2D Oldschool platform game where you control a rooster
Hi, Is the g++ dependency of the main game binary intentional? I built the game for stretch, it went OK (after reducing the debhelper compatibility level to 11, but that isn't a problem). The game starts, but I'm unable to select a map: the presented list is empty, though strace shows it finds the /usr/share/games/pk2/data/episodes directory. Also, it tries to create the config directory in /usr/share/games/pk2/data, which fails with permission denied. -- Regards, Feri
Meaning of "Checking build-dependency (indep) on amd64" excuse
Hi, Could somebody please explain me the meaning of the "Checking build-dependency (indep) on amd64" migration excuse as seen on https://qa.debian.org/excuses.php?package=pacemaker? I think I understand the rest, although I don't know whether the autopkgtest regression blocks migration indefinitely. That would be unfortunate, because unstable pcs needs unstable pacemaker, so they deadlock... -- Thanks, Feri
