Re: Concerns/problems shipping multiple shared libs in one package
Ross Vandegrift writes: > Are there things I should look out for if I try to combine many shared > library packages into one? In my case, the concerns in policy section 8 > do not apply (same source, same sonames, and all components libs must be > kept at the same version). If all the SONAMEs of the libraries will *always* be kept in lockstep, absolutely guaranteed, then you can probably combine them safely into one binary package. Just be aware that you are signing yourself (and the package's users) up for a complicated and tricky transition if at some point upstream breaks that guarantee and the SONAMEs diverge. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Copyright for contributors
Jongmin Kim writes: > On Sat, Jul 06, 2019 at 02:48:12AM +0900, Jongmin Kim wrote: >> when upstream copyright text explicitly state the "contributors", like [1]: >> >> Copyright (c) 1998 - 2009, Paul Johnston & Contributors >> >> what should I write at License: in d/copyright? >> >> I could think >> >> License: 1998-2009 Paul Johnston & Contributors > Copyright: 1998-2009 Paul Johnston & Contributors >> >> or just >> >> License: 1998-2009 Paul Johnston > Copyright: 1998-2009 Paul Johnston I would just copy the upstream notice verbatim, so the first of your two examples. This may or may not be the best possible copyright notice from a legal standpoint, but that isn't really our concern, and usually licenses that require preserving copyright notices just want us to preserve whatever notice upstream decided to write. There's generally no useful purpose served in trying to improve upstream's copyright notices or make them more accurate, and it arguably can be a technical violation of some licenses that require preserving copyright notices. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#922965: Bug#923220: DFSG compliance concerns
Philipp Meisberger writes: > What about the java-package and DFSG? It is very similar to my package > and also does not build a .deb from source but is contained in Debian. java-package is not in Debian. It's in the contrib distribution, which is a set of packages provided alongside Debian for working with non-free software. This sort of upstream repackager, if it itself is released under a free software license, is in general acceptable for contrib if someone is willing to sponsor it. (I haven't looked at the details of this specific package.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Formal definitions of Provides and Replaces
Andrius Merkys writes:
> On 09/06/2018 07:12 AM, Russ Allbery wrote:
>> As part of that transition, it looks like exactly what you said
>> ("adaptation and rebuilding of all packages depending on blacs-mpi")
>> was done for the packages in Debian.
> many thanks for the explanation. I was not aware of #886711, thanks for
> pointing it out to me. Surprisingly, espresso hasn't received a ping
> about the transition or the bug, that's why it took so long for me to
> find out the reason.
Oh, whoops. Yes, that seems less than ideal!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Formal definitions of Provides and Replaces
Andrius Merkys writes:
> thanks for pointing this out. I was quite surprised that
> Provides/Replaces does not formally require the providing/replacing
> binaries to completely cover provided/replaced binaries.
> The reason I'm asking is the removal of binaries of blacs-mpi, which is
> indicated as provided/replaced by scalapack now. However, scalapack's
> libraries have other sonames, what requires adaptation and rebuilding of
> all packages depending on blacs-mpi. I have spent quite some time to
> figure this out when packaging espresso. Isn't this a bug in scalapack?
I think you're expecting a stronger guarantee than Debian necessarily
provides here. Even a newer version of the same package doesn't have to
provide all the same files as an earlier version of the package.
Some history is here: https://bugs.debian.org/886711. It sounds from that
bug at least like the functionality provided in blacs-mpi is now provided
by scalapack, and at least some packages could just be rebuilt against
scalapack to handle that transition. That's about all that's needed to
justify a Provides/Replaces. There isn't a requirement that everything
work; it's a transition, and the functionality provided is changing (in
this case, apparently based on upstream changes). Using Provides/Replaces
is a mostly pragmatic decision: does it create less work than just
removing the package completely and forcing sourceful uploads of all other
packages? (With an eye to what the upgrade experience for Debian users is
as well, of course.)
As part of that transition, it looks like exactly what you said
("adaptation and rebuilding of all packages depending on blacs-mpi") was
done for the packages in Debian.
Usually it's not worth the effort to diverge too far from upstream in
trying to maintain backward compatibility. If upstream has decided not to
maintain that compatibility, trying to do it ourselves in Debian is rarely
a good use of scarce resources. That sometimes means package-breaking
transitions that require a bit of work for dependencies.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: debhelper-compat-version 11 and systemd
Tong Sun writes: > I have a d/rules file that uses systemd: > rules: dh $@ --with systemd > When setting debhelper-compat-version to 11 to fix the > “package-uses-old-debhelper-compat-version” problem, I got: > dh: unable to load addon systemd: dh: The systemd-sequence is no > longer provided in compat >= 11, please rely on dh_installsystemd > instead > Compilation failed in require at (eval 10) line 1. > I've searched for the solution but didn't find the answer. > How to fix it? Just omit the "--with systemd" part entirely. From debhelper(7): - The dh_systemd_enable and dh_systemd_start helpers have been replaced by the new dh_installsystemd helper. For the same reason, the systemd sequence for dh has also been removed. If you need to disable the dh_installsystemd helper tool, please use an empty override target. Please note that the dh_installsystemd tool has a slightly different behaviour in some cases (e.g. when using the --name parameter). You may want to read the dh_installsystemd(1) man page to see if any of the changes affect your package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: VCS repositories
"Warlich, Christof" writes: > I'm a bit desperate to find out how the Debian project maintains its > patches w.r.t. upstream repositories. Thus, while I can explore the > _current_ patches of a package by looking at the > "*.debian.tar.gz"-archive after obtaining its sources through "apt-get > source ", I'd be rather interested in both history and > future of these patches along the lifetime of a Debian releases' > maintainance period. I suspect you may be looking for dgit, which exposes the history of a package as a Git repository. For maintainers that also use Git and make dgit-aware uploads, this will be the full Git history; for packages whose maintainers don't use dgit for whatever reason, it will just have one revision per upload to the archive. But that may still be enough granularity for your purposes. If you install dgit and then run man dgit-user, hopefully that should get you started. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How to fix symbols files to work with gcc-7 and gcc-8
Andreas Tille writes: > Well, it took a *long* time before I've undergone the process from > ignoring symbols files to finally providing some in cases where there > are good reasons to use them. Shortly after I now get adise to not > use them. I'm not sure whether this is fully honest - but to you > want to file a bug report against lintian to warn only about missing > symbols files if its not a C++ library? I took a pretty deep look at this 6 years ago. I'm not sure if the tooling has substantially improved; if not, I recommend against trying to use symbols files for C++. See: https://www.eyrie.org/~eagle/journal/2012-01/007.html https://www.eyrie.org/~eagle/journal/2012-01/008.html https://www.eyrie.org/~eagle/journal/2012-02/001.html Looks like two of my pkg-kde-tools bug reports were closed, but this one is still open: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658333 -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Fixing incorrect .orig
wf...@niif.hu (Ferenc Wágner) writes: > Wookey writes: >> Is there a suffix typically used for this situation of essentially >> 're-done upstream source' > $ grep "Version.*real" > /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages > > reveals some other options like +real and (+)really, and I've seen .real > as well. +really is more often used when one has to upload an older version of upstream and doesn't want to use an epoch. As, for instance, in the following version sequence, where a revert to upstream's 1.0 release was required: 1.0-1 1.1-1 1.1+really1.0-1 It's a temporarily ugly way to avoid an epoch if one hopes to be able to upload 1.2 or something in the future. I think that's a bit different from Wooky's use case (for which I'd probably use +pristine). We don't have great or consistent naming conventions for this stuff. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Built-Using usage question
Lukas Schwaighofer writes: > Ok, I expected as much. Any suggestions on where to put that? > /usr/share/doc/syslinux-efi/copyright seems like the obvious place (and > is mandated by policy §12.5) but if I understand the machine readable > format correctly, it doesn't support my use-case at all (since there are > no files in the source package that can be matched). Yeah, I don't think the machine-readable format really anticipated this. This might be a good use case for just not using that format for this package. But also feel free to open a bug against debian-policy to come up with some better approach for representing this sort of information. (This somewhat ties into the long-standing argument over whether debian/copyright should document the copyright and license of the artifacts in the binary package, or the files in the source package.) One interesting alternative approach (although this is not the way this usually works, so you'll be swimming upstream against the tools) is to only document the contents of your package in debian/copyright, but install a separate copyright file into the built binary package that documents the copyright and license of the artifacts in that package (including the information for syslinux-efi). > Also this could also be a more systematic problem. At least when > looking quickly at some of the other packages which build-depend on > gnu-efi, I couldn't see them reproducing the copyright notice in the > binary package either (I did not check thoroughly though). My guess is that most people don't think of it, and it's also very unlikely that anyone is going to sue over it or anything. But to be fully in compliance with the license, I do think the resulting binary package needs a copy of that license. > Do you think it's possible to apply some sort of automated solution to > the problem? I could think of a "built-using" support in debhelper that > will not only add the built-using header but also copy the (complete) > copyright file from the included package into the including binary > package somewhere in /usr/share/doc/$package. While it will waste some > space (and duplicate files), it will also make sure that we correctly > follow any copyright changes without requiring the package maintainers > to manually track them. Yes, this does seem like a good idea to me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Built-Using usage question
Paul Wise writes: > Personally, I feel this change to policy is a mistake. Alternative proposals that achieve the goal of not adding Built-Using fields to the entire archive are welcome. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Built-Using usage question
Lukas Schwaighofer writes: > The syslinux-efi binary package contains parts of the gnu-efi package > due to static linking. I believe that, independent of the license > question, in order to satisfy DFSG §2 (“The program must include source > code, […]”) I need to keep using the Built-Using control field. > Especially since it's conceivable that a new version of gnu-efi breaks > compatibility with some specific efi implementation. However, on a > technical level, I don't really see the difference between my case and > linking against glibc, which according to the debian-policy bug used to > discuss this change [1] should not use the Built-Using field. I don't think you need to change anything about Built-Using. That seems like exactly the sort of reason anticipated by DFSG compliance. The clarification in Policy is because the previous wording would have required literally every program in the archive written in C to declare Built-Using against the version of GCC used to build them because of the nature of libgcc, and at the request of the release team to not use Built-Using for library update purposes. > While thinking about the above problem I noticed something else which > brings me to my second question: Parts of gnu-efi are covered by the > BSD-3-clause license. In order to satisfy the second clause > (“Redistributions in binary form must reproduce the above copyright > notice […]”) do I need to somehow include the debian/copyright file from > gnu-efi in the syslinux-efi binary package? Yes, or at least the portions relevant to the code that's being statically linked. The resulting binary is a derivative work of the syslinux-efi package, so you need to follow its license. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: pandoc example for implementing Policy 12.4
Nicholas D Steeves writes: > Would someone please point me to an example package that shows the > correct way to override or use a special > debian/package.convert-list-of-files-to-convert-to-html > debian/package.convert-list-of-files-to-convert-to-plain-text > debian/package.convert-list-of-files-to-info-pages > etc. > info/man pages and convert documentation out of markdown format. I'm > trying to comply with Policy 12.4 regarding converting README.org to > README.html, because README.org is markdown. > I guess it's also arguable that README.html should be further > converted using html2text, if pandoc can't do that... So, I think it's entirely fine to just install README.org as-is as text documentation, since that's part of the point of Markdown: to not require any special formatting. That satisfies Policy. But if you *really* want to provide an HTML version for some reason, multimarkdown < README.org > README.html does a pretty good job (probably redirecting it to some path under the staging area for building the new package). BTW, are you sure that this is in Markdown? org-mode is something else that isn't necessarily Markdown -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Copyright for Autoconf stuff
wf...@niif.hu (Ferenc Wágner) writes: > In #832941 Sean Whitton writes: >> 6. config.guess, config.sub, configure, configure.in, Makefile.in and >> install-sh are not accounted for in d/copyright. > The license and the copyright of these files is pretty much the same all > the time (some details can depend on the date). However, tracking this > all properly in the copyright files of all packages using Autoconf takes > a huge amount of work. Is there really no way to redirect all that > effort towards something productive? For example by declaring at a > central place that these files have the usual license and copyright > unless specified otherwise in debian/copyright, and be done with them? It's very widespread practice in the archive to not bother documenting the copyright and license of the build system files that come from Autoconf and Automake. I'm sure people have various opinions about the merits of that, but as long as nothing weird is happening here (upstream adding code to those files under some weird license), I really doubt that ftp-master will care, which is the metric that matters the most. The licenses are very well-understood and don't pose any interesting issues. Package sponsors can of course have their own policies, but I'd upload packages without that documentation, since I think it's a fair amount of effort for very little gain. (I have stanzas for those files in some, although not all, of my packages, but only because I have a half-assed script that semi-automates it, although not horribly well.) For those who think it's important to document the licenses of these files, I would encourage you to work on writing a well-tested and reliable tool to automatically generate those stanzas (the notices are fairly consistent and open for that sort of automation) rather than asking people to do tedious and not very productive manual work. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Data updates in debian packages
Ole Streicher writes: > We need it to put correct time on astronomical registrations, so it is > most important to have them once they are effective. Having them in > advance would be an additional plus, however, since f.e. a computer may > be disconnected during/after the observation, if that happens on a place > without internet connection. Christian's data is excellent. I can also add that, having followed the project for a while, I think it's pretty safe to assume that tzdata will have the updated leap seconds in a released version and therefore in a Debian stable package before the leap second takes effect with a high level of reliability, and probably at least several months before. I was mostly worried if you needed the data ASAP after an IERS announcement, since the leap second data is sufficiently ancillary to the tz project that it probably wouldn't, by itself, trigger a new release. So the update would wait for some other time zone change to be rolled into a release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Data updates in debian packages
Christian Seiler writes: > On 10/30/2016 10:20 AM, Ole Streicher wrote: >> IETF is responsible for internet standards, not for leap seconds. They >> will take the leap seconds from IERS. I would assume that this >> connection is well-established to rely on it. I was not so much >> questioning upstream here, but I worry a bit about the Debian package >> for tzdata: how sure can I be that the tzdata is actual (wrt upstream)? > Regular stable updates (via stable/updates, not only point releases) > happen for that package, in addition to regular uploads to unstable. > See the timeline in: > https://tracker.debian.org/pkg/tzdata > From what I can tell, this is probably the package that's updated in > stable most consistently in the entirety of Debian. I would really > recommend that you rely on tzdata directly, this will also save the > release team a lot of work. (It's much easier for them to approve just a > single package than 100 packages that need the time zone and/or leap > second information.) Speaking as a long-time lurker of the tz mailing list, I would recommend confirming with upstream that they intend to be a timely (enough) source for leap second information, as I believe that has been a bit controversial. Note that leap second information is used in the tzdata package for a fairly ancillary purpose (the maintenance of the "right" time zones, which almost no one uses), and is not a primary goal of the project. tzdata definitely just takes a copy of leap second information from IERS (actually, I think they may pull the data from NIST, which gets it from IERS). IERS is the correct upstream source. If many Debian packages want a high-quality, timely source of leap seconds, it might be better to have a separate package devoted to that, so that any update timeliness is not entangled with issues with tzdata. That said, tzdata is, as mentioned, a very reliably updated package in Debian stable releases, so if upstream is willing, maybe it's fine to rely on that. The required timeliness depends a lot on what you're using leap seconds for, and in particular if you need to know about them far in advance, or if it's only necessary to have an updated table before the leap second itself arrives. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Packaging mmh (fork of nmh)
Wookey writes: > +++ Dmitry Bogatov [2016-04-10 08:34 +0300]: >> nmh installs it's binaries (~20) into /usr/bin/nmh. Now I try to >> do the same, and install mmh's binaries into /usr/bin/mmh, but >> Lintian complain about FHS violation. The only allowed >> subdir of /usr/bin is /usr/bin/mh. > So nmh is not following FHS either. mh implementations have a special historical exception in the FHS. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: git-buildpackage pattern question
Ross Vandegrift writes: > In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2. > So my packaging looks like this: > o---ooooo master > \ \ > o---o 1.0.0o---o 1.1.0 >\ \ > o---o 1.0.1o---o 1.1.1 > \ > o---o 1.0.2 >\ > o debian/sid > To update to 1.1.1, I've read that I should merge 1.1.1 into debian/sid. > But this is painful - upstream 1.1.1 conflicts with 1.0.2. This is exactly why git-buildpackage by default uses an upstream/latest branch that tracks upstream releases. If upstream has tarball releases, when moving from 1.0.2, you would advance the upstream branch to 1.1.1 with: gbp import-orig --upstream-vcs-tag=1.1.1 /path/to/tarball and gbp will make a merge commit in the upstream/latest branch that moves all files to the contents of the 1.1.1 tarball, forcing all files to move to the 1.1.1 contents. You will then, from Git's perspective, have a commit in the upstream branch that goes from 1.0.2 -> 1.1.1, and you can merge the upstream/latest branch into the debian/sid branch without any conflicts. If upstream doesn't do tarball releases, you can't use gbp import-orig (I think), so you have to synthesize that commit yourself. You still need a separate branch that doesn't have your packaging files. Conventionally, this is upstream/latest. This gets a bit tricky, since you have to use the "ours" merge strategy. I *think* something like this would work, but I haven't tested it. git checkout -b upstream/1.1 1.1.1# assuming 1.1.1 is the upstream tag git merge -s ours upstream/latest git branch -d upstream/latest git branch -m upstream/1.1 upstream/latest The idea is that you want to move the tip of upstream/latest to a commit that exactly matches upstream's 1.1.1 release, but which Git has recorded as a merge between upstream's 1.1.1 branch and your existing upstream/latest branch (which was upstream's 1.0.2 branch). This will give Git enough information to properly merge your new upstream/latest branch into your debian/sid branch by just moving upstream source to 1.1.1 without changing anything about your packaging. I think gbp import-orig, under the hood, does something more complicated using Git plumbing to create the merge commit directly. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: public-domain in the debian/copyright
"Gustavo S. L." writes: > Thanks Wookey, > I did this: "License: public-domain > No license required for any purpose; the work is not subject to copyright > in > any jurisdiction. > " What Lintian is trying to do (maybe not phrased as well as possible) is to prod you into providing some explanation for how you know that. This is a very unusual situation for a work to be in, so ftp-master needs to be able to verify this somehow. It saves them a lot of time if you can include the details of how you know this in the license paragraph, or at least somewhere in debian/copyright (a Comment field or whatever). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: To override or not to override?
Paul Tagliamonte writes: > I don't like having overrides sit around, and having them sit around > while the version of lintian that's being used is no longer triggering > makes me feel unfomfortable This is why Lintian will warn you about unused overrides so that you can remove them. That should make it safer to add an override for a Lintian bug, since when the bug is fixed, Lintian will tell you that you can remove it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How to determine when being packaged under Debian?
Jeffrey Walton writes: > On Wed, Sep 30, 2015 at 3:55 AM, Russ Allbery wrote: >> Yeah, this is why I'd put a check into the Debian packaging to be sure >> that the software was built this way and abort the build during the >> check phase if it wasn't, with a big comment explaining the situation. >> Then hopefully anyone else who picks up the package, if that happens, >> would be aware. > OK, so this is something only a maintainer can do? (I'm OK with that; > I'm just trying to understand the process). It would be a check that could be added to the Debian packaging files to verify the build. Anyone who can push changes to the packaging files could do that, and of course people could submit a diff via the BTS, but yeah, normally the package maintainer would maintain those files. > We try to minimize external dependencies (even a package maintainer is > a dependency in the process). So we were hoping/looking for something > like (its a C++ library): > #if defined(PACKAGE_BUILD) && !defined(CRYPTOPP_INIT_PRIORITY) > # pragma message "It is recommended you define CRYPTOPP_INIT_PRIORITY." > # pragma message "See https://cryptopp.com/wiki/Config.h for details." > #endif Hm, given that this is just a warning, why not do this regardless of the PACKAGE_BUILD variable? The package build wouldn't fail, but people building with the wrong options would see that message. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How to determine when being packaged under Debian?
Jeffrey Walton writes: > OK, thanks. We are working with László Böszörményi. He's been very > helpful. > But if László ever leaves Debian or stops Crypto++, then I loose my > contact and the path to ensure things are handled correctly. Yeah, this is why I'd put a check into the Debian packaging to be sure that the software was built this way and abort the build during the check phase if it wasn't, with a big comment explaining the situation. Then hopefully anyone else who picks up the package, if that happens, would be aware. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How to determine when being packaged under Debian?
Jeffrey Walton writes: > We have specific recommendations for packaging Crypto++ for distribution > (cf., http://cryptopp.com/wiki/Config.h#Recommendations). Soon to be > released Crypto 5.6.3 introduces two new defines, and we feel distros > should enable them by default. The defines are > CRYPTOPP_NO_UNALIGNED_DATA_ACCESS and CRYPTOPP_INIT_PRIORITY. > When being packaged for distribution, we want to fail the compile unless > the defines are in effect. However, we only want it to apply to distros > at this point (and not the general user community). We are not trying to > be rude; rather we are trying to ensure the library is in the best state > it can be to avoid problems on a mass scale. > (In Crypto++ 6.0, they will be in effect, and this wrinkle will go > away. But we can't make the breaking change on a patch-level revision > bump). > Is there a way I can detect when Debian is building the library for > packaging and distribution? Crypto++ does not use Autotools, so we > need to detect it in the Makefile or preprocessor. We would really, really prefer that you not do this, and instead work with whoever is packaging the library for Debian to add a test to the packaging rules themselves to be sure that they're built correctly. The reason for this is that Debian's packaging tools, by design, work exactly the same way when run by an individual user to build a package for their own personal purposes as when we use them to build packages for the distribution. This is in the spirit of open source: there shouldn't really be anything special about Debian as a distribution that any individual can also do. But as a result, it's pretty hard to distinguish between a Debian build and an individual build. Also, I would question the assumption a bit: if this is important for distributions, wouldn't it be important for all builds? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: apt-get upgrade and package consolidation
Frank de Lange writes: > In packaging owncloud (https://owncloud.org) for Debian we've hit on a > bit of a snag. In previous versions of the Debian packages, many > disparate components were delivered in their own package > (owncloud-app-encryption, owncloud-app-kichensink, owncloud-app-., > etc). These functions have now been consolidated into the main package, > named owncloud-server. The main question now is how to get this upgrade > to go ahead using a normal apt-get upgrade (or the equivalent in other > upgrade mechanisms) without needing to resort to dist-upgrade or a > targeted upgrade (apt-get upgrade/install owncloud-server). > Currently the following happens: > - user has the whole bunch of owncloud-app-... packages installed >as well as owncloud-server, all at v 8.1.1-1. > - the next version of owncloud-server (v 8.1.3-6.1) includes all these >owncloud-app-... packages. In the control file this is stated: > Conflicts: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud- > app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long) > Breaks: ... owncloud-app-activity (<< 8.1.3-6.1), owncloud- > app-encryption (<< 8.1.3-6.1), ... (etcetera - the list is long) You basically never want both Conflicts and Breaks. Breaks is a weaker version of Conflicts. In this case, I think you want Conflicts, not Breaks, plus Provides and Replaces. > - user tries a normal upgrade but this fails - owncloud-server >is held back > - attempting to solve this by adding a 'Provides:' section with the >consolidated packages does not solve it either - now both the >owncloud-server package as well as all those 'Provided' packages >are held back. I think you need Replaces. See: https://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2 -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How much is lintian an expert in english language ?
"Thomas Schmitt" writes: > Russ Allbery wrote: >> That intransitive form of allow is almost always used >> in combination with the preposition "for". > But why then isn't the lintian check called > "allows to allows for" or "allow is not the right word here" ? In part technical limitations. That part of Lintian can only suggest corrections, and there isn't a special tag just for this. So Lintian suggests the simplest and most flexible idiomatic English replacement that changes as few words as possible, which is "allows one to" (making it transitive). It's probably more accurate to say that this is clunky phrasing in English, and there's probably a much more direct way of rephrasing the same sentence. But Lintian isn't very good at suggesting such things. In most cases where I've seen someone use this construction, it would have been better to just drop all those words. For example, to pick the first change in your proposed diff (for those who didn't see the diff, I'm looking at a whole sentence in upstream documentation), instead of: A permissive mode depicted by option -tao which needs no predicted track size and allows to make use of eventual multi-session capabilities. I would say something like: Permissive mode, set with the -tao option. This mode does not require track size and can use eventual multi-session capabilities. (Not 100% sure whether "eventual" is a term of art here, or is intended to have the English meaning of something that isn't implemented yet but may appear later. If the latter, I'd probably rephrase this more, since that isn't very clear.) Note that most of what I did was delete words. Both native and non-native speakers, on first draft, often add far more words than are required. A lot of editing in English involves deleting words that don't add to the meaning of the sentence. In this case, the whole "allows to make use of" phrase just became "can use". I have great sympathy for people trying to write documentation in a non-native language! It's so hard to get subtleties of meaning and phrasing right. For example, "depicted by" is subtlely off here in ways that are a bit hard to explain. A depiction of something is an image or representation of it. For example, one would say that a photograph of me "depicts me" or (a more common usage) "depicts a Debian developer," since you often use "depict" to describe a specific image of some general concept. You therefore wouldn't say that a command-line option "depicts" a mode, because the command-line option does not, itself, form a representation of that mode. Rather, the command-line option chooses, selects, or enables that mode. Here, I looked for the shortest and simplest word I could find and went with "set." -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: How much is lintian an expert in english language ?
"Thomas Schmitt" writes: > It seems all to hang at Justin B Rye's statement > "Most English transitive verbs are pretty easygoing about >being turned into intransitives like this, >"to allow" is one of the exceptions" > Sez who ? > http://www.merriam-webster.com/dictionary/allow > has 5 items of "transitive verb" and 2 of "intransitive verb". The intransitive meanings of allow don't mean the same thing. That's the "people should allow for personal differences" meaning of allow, which means "tolerate" or "make allowances for" or "design for." You don't want that meaning when you're trying to say that a program allows someone to do a specific thing. That intransitive form of allow is almost always used in combination with the preposition "for". It *is* possible to have a legitimate and grammatical use of the phrase "to allow" by saying something like "This program is designed to allow for a variety of uses," but it's not as common of phrasing for a package description, and it's usually a pretty indirect and unusual way of phrasing things. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Re: Dropping a link reference
Leopold Palomo-Avellaneda writes: > I'm packaging a non-free software (better not ask, it's a pain :-(). The > question is that there are some executables that has a link to an old > version of libraw1394-8. > The funny thing is that I have tested to create a fictitious > libraw1394.so.8 library making a symbolic link to the current > libraw1394.so.11 and it works. When I created the package, > dpkg-shlibdeps shows some messages with shouldn't be linked with > libXXX.so.X (it uses none of its symbols). And one of them is > libraw1394.so.8. > So, as I have _only_ the binary, there's some way to drop a dependency > of a library produced by the linker knowing that not use any of its > symbols? You need to edit the ELF metadata for the binary and remove the NEEDED entry for that shared library from the dynamic section. It looks like patchelf can do that (in the patchelf package): $ patchelf --remove-needed libraw1394.so.8 /path/to/binary -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3sdkg28@hope.eyrie.org
Re: odd Vcs-Git pointer in control file, package fortune-zh
lumin writes: > I'm a very newbie trying to adopt a package, according to the Debian new > maintainer's guide. My target package is now "fortune-zh", as it seems > to be very simple to work with (to fix chinese character typo that I > noticed). > In the 1.10 version (jessie, unstable) of fortune-zh, I found this line > in control: > Vcs-Git: git://anonscm.debian.org/chinese/fortune-zh.git > So I cloned that Git repo, and then found the latest version in that git > repo is 1.9 .. > Then I looked up for bugs filed for fortune-zh, then found #518054 and > #629014. I didn't found any hint revealing where the newest repo lies. > I wonder if that 1.10 commit was out of nothing? I have no idea where > to clone that newest repo (containing 1.10) so I can continue my ITA. The 1.10 upload was a QA upload, and probably didn't push anything to the Git repository. Debian packages are not required to use Git, and QA uploads for orphaned packages often don't. You can import the changes from 1.10 into the repository using a tool such as gbp import-dsc from the git-buildpackage package. That's what I'd do at this point. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mr2qnke@hope.eyrie.org
Re: code reuse in debian/package.config
"Yuri Oleynikov (יורי אולייניקוב" writes: > I've tried to - that not helped at all Hm, I'm not sure there's a way to do what you want, then, other than by moving all your debconf work to postinst. Note debconf-devel(7): Note that the config script is run before the package is unpacked. It should only use commands that are in essential packages. The only dependency of your package that is guaranteed to be met when its config script is run is a dependency (possibly versioned) on debconf itself. which indeed doesn't say that even Pre-Depends will work. I thought it might, but it looks like it won't. You may want to consider using the approach used in various Debian packages instead: Build-Depend on the package containing the common library, and assemble your maintainer scripts during the build so that they're self-contained in the generated package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761cvfjx3@hope.eyrie.org
Re: code reuse in debian/package.config
"Yuri Oleynikov (יורי אולייניקוב" writes: > But, when installing packageA without libxyz-common-tools is > preinstalled - packageA.config script won' run? > Is there any way to solve the problem? The config script runs during a preinstall stage, before the package dependencies are installed. I think that you can work around this by having your internal packages use Pre-Depends for the package that provides your script library (instead of Depends). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a927fkke@hope.eyrie.org
Re: Sample Debian package to show-case all
T o n g writes: > Is there a *simple* sample Debian package somewhere out there that show- > case most of the important Debian packaging aspects? > E.g., with a small C/C++ file, the sample package shows > - the latest standard of debian/rules file > - the most simplified Makefile > - how to build from ./configure > - how to properly put/handle .1 man file > - how to properly put/handle .html doc file > - how to properly name patch files > Also, hope the debian directory is within the source tree. > Again, the keyword is *simple*. I.e., everything is there to show-case > Debian packaging, instead of distracting to other things, e.g. 10K+ line > of C code, etc. That's the intent of the hello package, similar to how GNU hello is an example of GNU coding standards. I'm not sure if it has all the elements that you name, though (but bugs and requests are probably welcome!). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx0xd40q@hope.eyrie.org
Re: Sample systemd service init file please
T o n g writes:
> --- a/src/Makefile
> +++ b/src/Makefile
> @@ -8,6 +8,12 @@ docdir = ${prefix}/share/doc/dbab
> bindir = ${exec_prefix}/sbin
> etcdir = ${DESTDIR}/etc
> astdir = ${etcdir}/dbab
> +ssddir = ${etcdir}/systemd
You should install into /lib/systemd/system, not /etc/systemd. (It's
always /lib, even if your prefix is /usr.) I think that's the cause of
the Lintian message about a missing systemd unit file.
> @@ -23,12 +29,14 @@ install:
> $(INSTALL) -m 755 -d $(etcdir)
> $(INSTALL) -m 755 -d $(etcdir)/init.d
> $(INSTALL) -m 755 -d $(astdir)
> + $(INSTALL) -m 755 -d $(ssddir)
Mode 644 for the service file.
> for the purpose of adding that single systemd configuration file,
> - do I need to add the dh-systemd to Build-Depends
> and use `dh $@ --parallel --with systemd`?
You want --with systemd and the dh-systemd dependency, since that takes
care of activating your systemd unit file. --parallel is up to you and
depends on whether your package supports parallel build. (It's unrelated
to systemd support.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnn5erma@hope.eyrie.org
Re: Sample systemd service init file please
T o n g writes: > Can you provide me a sample systemd service init file, that correspond > to init.d script please? I.e., the corresponding file for systemd to > replace /etc/init.d/service. Take a look at the lbcd package in Debian. It has an init script, a systemd unit, and an upstart configuration, all of the same (simple) daemon, so it's easy to compare them. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egs2lt9z@hope.eyrie.org
Re: Self-maintained Debian packages best practice
T o n g writes: > Ok, good to know, but that's more targeting towards package building, > not source code developing and maintaining. Does it imply that I should > put the `debian` folder within my source tree now? Because as mentioned > before, the last thing I want to do is to separate my source and my > `debian` folder into two git repos. http://www.eyrie.org/~eagle/notes/debian/git.html#combine may (or may not) be helpful. This is a little out of date with current tools, unforunately. The major change is use of --upstream-vcs-tag in git-import-orig. Some people do find this approach too complicated. I guess I'm just used to it, but it works for me. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw78t7dr@hope.eyrie.org
Re: Fixing the warning of Depends field unknown substitution variable ${perl:Depends}
T o n g writes:
> On Sat, 29 Nov 2014 21:26:10 +0100, Stephen Kitt wrote:
>> If you think ${perl:Depends} should have a value then there may be
>> something else going on; what does dbab end up depending on once it's
>> built? (dpkg-deb -I dbab*deb will tell you.)
>>
>> (Note that IO::Socket::INET is part of perl, so you don't need to depend
>> on anything beyond that as far as I can see.)
> Yes, you are right. once it's built, here is what from dpkg-deb -I:
> Depends: dnsmasq, curl
So, missing the perl dependency, which is what the ${perl:Depends}
substitution variable is for.
>>> $ grep '^Depends: ' debian/control
>>> Depends: ${misc:Depends}, ${perl:Depends}, dnsmasq, curl
>> If you want to fix the warning you should remove ${perl:Depends}.
> But you and Paul Wise in https://lists.debian.org/debian-mentors/2013/12/
> msg00059.html suggest that I remove ${perl:Depends}. However, I AM
> packaging a Perl script, would it be better that I put just a 'perl'
> there?
If you are packaging something that uses Perl, such as this package, you
should include ${perl:Depends} in the Depends line in debian/control so
that dh_perl can use it to add the perl dependency. If you're not, you
can leave it out.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oarpju8v@hope.eyrie.org
Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]
Raphael Hertzog writes: > In fact, I believe they should be mostly disjoint. As a maintainer, I > welcome help on all bugs. > When I tag a bug help it's because I believe that I don't have the > skills to fix it by myself and that external help is really needed to > make some progress. +1. I use help as a sort of variant of wontfix. It means that I'm not opposed to a fix for that bug, but I'm not going to work on it, either because I don't have the time or I don't have the necessary skills. Therefore, unless someone else works on it, it's not going to get fixed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ujflkv6@hope.eyrie.org
Re: libtool zealeousness: how to stip off -pthread added by libtool
Jerome BENOIT writes: > for my current packaging, a program that does not use pthread directly > is linked against a library that uses (intensively) pthread: libtool > add the option -pthread while is not necessary (and not wanted in my > case). I'm a little dubious that this is guaranteed to always be the case. The reason why libraries that use pthreads heavily export that linker flag is that I believe there are some situations where this *does* matter and the program needs to be linked with -pthread when it uses such libraries, even if it doesn't use pthreads itself. I'm not sure if any of those situations occur on Linux, but I would be a little dubious about removing this. > So I get the following warning message from dpkg-shlibdeps: > warning: package could avoid a useless dependency if > debian/tachyon-bin-nox/usr/bin/tachyon-nox was not linked against > libpthread.so.0 (it uses none of the library's symbols) Note that libpthread is included in the libc6 package already, so while there's a warning about this, it doesn't create any unnecessary package dependencies. That means this causes essentially zero ill effects for your program (in fact, I wonder if libpthread should just be whitelisted for this check in dpkg-shlibdeps). That's particularly true since your program is linked with a library that uses libpthread, so libpthread is going to be loaded by your program anyway. In short, I'd just ignore this. That's what I do in similar situations for my packages. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3374r2i@hope.eyrie.org
Re: dh_installman and camel case name in .TH (repost)
Ole Streicher writes: > Russ Allbery writes: >> This is arguably a bug in te dh_installman documentation. It takes the >> section component of the man page name from the .TH line, but the name >> component is taken from the basename of the source file. So you need to >> rename funopen.3 to FunOpen.3, and then it should install in the correct >> location. > which is rather difficult to fix. > Is there a reason why the name is not taken from the manpage? Yes, the name given in .TH is traditionally in all uppercase regardless of the case of the thing being documented. So this would get the capitalization of the installed man page wrong in many (most?) situations. Another option is to not use dh_installman to install the man pages and instead use explicit install / cp commands in debian/rules to put them in the correct path under usr/share/man?/ in the package build directory. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq7qvggh@hope.eyrie.org
Re: dh_installman and camel case name in .TH (repost)
Ole Streicher writes: > Following the man page of dh_installman: > | If you have a properly formatted .TH or .Dt line, your man page will > | be installed into the right directory, with the right name > I thought I could just change the name in the TH line: > -8< > [...] > ..TH FunOpen 3 "January 2, 2008" "version 1.4.2" "SAORD Documentation" > [...] > -8< > to get the correct man page. However, the manpage is still installed as > funopen.3 -- contrary to the dh_installman documentation shown above. > Is this a bug in dh_installman, and how can I fix this (without renaming > all manpage files, which is much harder then just patching them)? This is arguably a bug in te dh_installman documentation. It takes the section component of the man page name from the .TH line, but the name component is taken from the basename of the source file. So you need to rename funopen.3 to FunOpen.3, and then it should install in the correct location. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnp2x0uf@hope.eyrie.org
Re: Build-depending on non-free package
debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) writes: > Russ Allbery writes: >> I'm pretty sure that default is applied before dak ever sees the binary >> package priority. (In other words, it's expanded via the build process >> before priorities are added to the *.changes file.) > So it is a debhelper bug? Still a "serious" one? (Violation of Policy)? Section and Priority are only meaningful for binary packages and for setting the defaults for binary packages. What you see in the PTS for the source package really should just be suppressed from the PTS entirely, since nothing cares about those field values and they're not used for anything inside Debian. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siky7wbg@hope.eyrie.org
Re: Build-depending on non-free package
debian-de...@liska.ath.cx (Оlе Ѕtrеісhеr) writes: > Ansgar Burchardt writes: >> As I don't really care about Priority and Section for source packages, I >> haven't thought further about this and dak currently uses misc:extra for >> all of them. > Policy, 5.6.6: Priority > | This field represents how important it is that the user have the > | package installed. See Priorities, Section 2.5. > | > | When it appears in the debian/control file, it gives the value for the > | subfield of the same name in the Files field of the .changes file. It > | also gives the default for the same field in the binary packages. > Which means: If this is set, i *must* be taken as default for the binary > packages (everything else would be a policy violation and therefor an RC > bug, right?). I'm pretty sure that default is applied before dak ever sees the binary package priority. (In other words, it's expanded via the build process before priorities are added to the *.changes file.) Also, dak is canonical for priorities, and values in binary packages are only used on initial upload to set the initial override value. From that point forward, changes have to be made via bugs filed with ftp.debian.org. It's possible that Policy could stand some work to make this clearer. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4ur6ixc@hope.eyrie.org
Re: Autoreconfing guide
Henrique de Moraes Holschuh writes: > Indeed. In most cases, there will be a shell script somewhere (one of > the usual names is "autogen.sh") that will call autoreconf with the > appropriate options. Be careful of those scripts. Often they do other things that you don't actually want done, and they don't always regenerate everything. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4vq9smm@windlord.stanford.edu
Re: Autoreconfing guide
Yavor Doganov writes: > Probably you're right; I guess this is due to the misarable experience I > had in the past, with Gtk+/GNOME packages in particular. Even now if I > look at the packages I maintain, they're full of underquoted and > obsolete macros. These things are fixable, as you say, but some > upstream maintainers are very reluctant to incorporate changes to the > build system. I have seen my proper m4 quotation deliberately removed > and classified as "obfuscation". In this age, some people still use > AC_TRY_* macros in new packages because that is what they copy/pasted > eons ago. Yes, you're not wrong. I suppose the caveat I should attach to my experience is that I'm a fairly experienced Autoconf user (dating back to the version 1 days, in fact, although I only started using it in earnest with version 2), so while writing detailed m4 macros is usually beyond me, I can fairly easily debug and fix most Autoconf scripts. People with less experience will be less comfortable being aggressive about this. I do wish that more maintainers would treat Autoconf with the same care that they would treat, say, their C or Perl or Python coding style and stay similarly current in the language. It's not that hard to go through the changelog of new Autoconf releases and adjust for new recommended macros. But if you don't do it regularly, the accumulated work becomes intimidating. > What about packages that use a custom bootstrap script and/or gnulib? > Should gnulib be updated too? I would not update gnulib. A good case can be made to do this, but, as you say, it's dangerous. The huge difference with gnulib vs. Autoconf and Automake is that the latter don't contain any code that actually makes it into the final binaries. You can get some weird bugs, but by and large the software just doesn't build, or, worst case, builds with the wrong libraries. Updating gnulib can violate the expectations of the actual code, and possibly even introduce security vulnerabilities. That's a lot trickier. Most of gnulib *should* be inactive on a current glibc system, although I know that's not always the case. > What about packages which have AC_PREREQ for an Autoconf version that is > not yet packaged for Debian, or depend on a new Automake version/feature > (a minor issue, but it has happened in the past)? This used to be quite common, but honestly I've not seen it in years. A lot of the concerns that people have about always running autoreconf were completely valid and correct five years ago or so, but they've gotten a lot more stable (in part because upstream development of the projects has died down a bit again). > I also wonder why debian/autoreconf is needed given that autoreconf > is recursive. I don't think autoreconf can always figure out what to do when the files are buried in some random subdirectory without anything at the top level. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjg9g5ci@windlord.stanford.edu
Re: Autoreconfing guide
Yavor Doganov writes: > Russ Allbery wrote: >> I would still use dh-autoreconf. It's not as critical, since it's >> unlikely to be necessary for supporting new architectures, but I think >> the Autoconf and Automake files are better treated as source, and the >> generated files regenerated on every build. > However, this is not how the GNU build system is intended to be used. Meh. I think this is a non-issue. Most free software is used in ways that it wasn't originally designed for, and I think this is a clearly superior way to use it on platforms where we have the right tools. The pre-built configure scripts and Makefiles still provide valuable portability to systems where it's hard to get all the right tools installed. >> This ensures that the files can still be generated from the source, >> which in turn ensures that anyone wanting to make changes to the source >> package will be able to do so easily. > > This is an obvious plus, but consider the cons: > - It can provide non-deterministic builds for packages which misuse > the build system (improper quotation, usage of broken third-party > macros, etc). No, it's not non-deterministic. It's quite deterministic; it just may be broken with newer versions of the tools, just like badly written C code may be broken by newer versions of the compiler. This is exactly *why* you should always regenerate from source: so that you can catch those bugs and *fix* them. That's part of the point of free software. > - It can provide non-deterministic builds for legitimate use, when a > macro changes its semantics (this used to happen quite a lot in the > past). Which is equivalent to saying that unmaintained Autoconf or Automake files will *break* the builds for legitimate uses, like needing to modify some part of the build system and finding that it can't be recreated with the Autoconf and Automake currently available. This is why these bugs should be flushed out and fixed. > - It can introduce bugs for no good reason if a buggy > Autoconf/Automake version is used (either an upstream release that > introduced a regression or caused by a Debian patch). Well, obviously I completely disagree with "no good reason." Yes, actually using our build chain will uncover bugs in our build chain, so that we can then fix them. This is very good, even if it's painful when we find the bugs. > - Packages may (will?) FTBFS if they're silently "upgraded" to a new > Autoconf/Automake release that requires sourceful changes to > configure.ac/Makefile.am's/etc and such changes are not made by the > upstream/Debian maintainer (consider binNMUs, or the regular archive > rebuilds). Again, this is no different than buiding with a new C compiler. Those are bugs that should be fixed, and better that we know about them than not. > - All of the above can happen on a large scale if a big library > transition is involved and some stack of packages is being rebuilt. I find your concerns excessively alarmist. I have been rebuilding all the Autoconf and Automake files from scratch for all packages I maintain for quite some time now, including some very complex packages and packages with a mess of Autoconf macros, and have had few problems apart from a few latent upstream bugs that were flushed out and are now fixed. The only significant problem that I had that fell into one of your categories was the need to add: m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) to configure.ac in several of my packages due to an Automake behavior change. I've had considerably more work to do with C++ compiler transitions. If a particular package uses Autoconf and Automake in such a fragile and broken way that it keeps causing problems, maybe it's useful as a matter of expediency to fall back on not rebuilding the files until those bugs can be fixed. I know some packages mangled those tools very badly in the past. But for the vast majority of packages this works fine, or with at most minor patches that upstream is happy to take. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r41ml144@windlord.stanford.edu
Re: Autoreconfing guide
Guido van Steen writes: > I maintain a package that does not need any compiling. Still upstream > development is done using autoconf and autotools. Building the Debian > package yields a single binary package for all architectures. AFAIK in > this case I need neither dh-autoreconf nor autotools-dev. Correct me if > I am wrong though... IMO this could be useful information for the wiki > as well. I would still use dh-autoreconf. It's not as critical, since it's unlikely to be necessary for supporting new architectures, but I think the Autoconf and Automake files are better treated as source, and the generated files regenerated on every build. This ensures that the files can still be generated from the source, which in turn ensures that anyone wanting to make changes to the source package will be able to do so easily. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnsqmka5@windlord.stanford.edu
Re: Dual licence + linking openssl
Dariusz Dwornikowski writes: > I know that OpenSSL licence is incompatible with GPL but what when a > package linking to openssl is dual licenced under GPL and MIT. > Can I just "choose" MIT and say, hey they are compatible ? > Is such a package suitable for Debian ? Yes, and yes. There really isn't much difference between dual-licensed MIT and GPL and just MIT. Mostly, it just makes it explicitly clear that the software can be redistributed under the terms of the GPL in case anyone is particularly nervous or conservative about that. (It's generally believed that this can be done for MIT-licensed software regardless of whether it's dual-licensed, since there aren't any license terms that conflict.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g5yqiti@windlord.stanford.edu
Re: Install /usr/bin/something from upstream source to /usr/bin/something on hdd?
Patrick Schleizer writes: > Would a package created that way be allowed to enter Debian (if there > are no other issues)? I see no reason why not. Whether it's easy to install the software outside of Debian isn't really something that Debian itself should be that worried about, as long as the packages in Debian do the right thing. > Is any of these Stanford-internal packages available to be looked at in > a public place? It doesn't look like it, unfortunately. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877g6dtelo@windlord.stanford.edu
Re: Install /usr/bin/something from upstream source to /usr/bin/something on hdd?
Patrick Schleizer writes: > I am upstream as well as would like to become a debian maintainer some > day. Still learning packaging. > Due to the luxury of being upstream as well, the upstream source package > can be formatted in any way I wish. [In this case it is a simple package > with shell scripts only.] > Personally I find it useful to have a folder layout like this: > upstream_source_folder/usr/bin/some_script > upstream_source_folder/usr/bin/another_script > upstream_source_folder/etc/some_config > upstream_source_folder/etc/init.d/some_init > Those should get installed to /usr/bin/some_script etc. > Is it possible to simplify packaging? I mean, is it possible to automate > this without using a package.install file? In other words, is it > possible to tell debhelper, "use the > upstream_source_folder/usr/bin/some_script and install it to > /usr/bin/some_script"? For all of the Stanford-internal packages that we make that are just collections of scripts like that, we use the following rune in debian/rules: override_dh_auto_install: rsync -C --recursive --links --perms --times --delete \ --exclude debian --exclude t --exclude .gitignore \ $(CURDIR)/ debian/$(PACKAGE) and then just make the internal layout of the package match the installed layout. (Obviously you need a build dependency on rsync.) This provides zero assistance to people using your package not inside Debian, so you may not want to do things this way and instead provide some sort of Makefile to install things, but it works great for quick internal packages. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhuttgwd@windlord.stanford.edu
Re: dh, autoreconf, "remember to run libtool --finish"
Nico Schlömer writes: > I'm packaging a project that uses autoreconf and on my local machine > configures and builds fine with default options throughout. With the > minimal debian/rules file > <https://github.com/nschloe/launchpad-submitter/blob/master/debian-netcdfcxx/rules>, > it all seems to work out fine. However, at the installation step, I get > libtool: install: warning: remember to run `libtool --finish > /usr/lib/x86_64-linux-gnu' > [...] This is normal and can be ignored. Debian systems don't require libtool --finish. The only thing this does on Linux is refresh the ld.so cache, and that's handled by the package postinst during installation. > and the actual .a and .so files are not put where they belong. This > leads to a failure at dh_install, > <https://launchpadlibrarian.net/171725911/buildlog_ubuntu-trusty-amd64.netcdfcxx_1%3A4.2.1~20140403-trusty3_FAILEDTOBUILD.txt.gz>. It looks like you have the wrong path in your *.install file. Following Debian's multiarch standard, the library is being installed in /usr/lib/$(DEB_HOST_MULTIARCH), but your *.install file is listing /usr/lib/*.a directly. Changing that to /usr/lib/*/*.a is usually the right fix (and similarly for the other patterns in other *.install files). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87sipp13u0@windlord.stanford.edu
Re: public extension linked with libpython* vs. -Wl,-no-undefined
Jakub Wilk writes: > Actually, you usually don't get these kind of warnings for Python > extension modules. The warning is emitted only if a module has SONAME, > and it typically doesn't. If you build a module with libtool's -module flag, it looks like it still gets an SONAME. I'm not sure why -- I think it shouldn't -- but that will at least affect Apache and PHP modules. I must be misremembering the Python situation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738ifqktl@windlord.stanford.edu
Re: public extension linked with libpython* vs. -Wl,-no-undefined
Nico Schlömer writes: > Understood, thanks! > I'll just ignore the warnings of the type > ``` > dpkg-shlibdeps: warning: > debian/python-pytrilinos/usr/lib/python2.7/dist-packages/PyTrilinos/NOX/_Abstract.so > contains an unresolvable reference to symbol PyString_FromFormat: it's > probably a plugin. > ``` > then. Yes. The "it's probably a plugin" part is basically trying to tell you to ignore this as long as the message is correct and it is a plugin. Python, PHP, and Apache modules all generally get this warning. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha6wjlv6@windlord.stanford.edu
Re: Lintian error for package with Apache2 module
Atle Solbakken writes: > I'm getting the Lintian error > apache2-module-does-not-depend-on-apache2-api > <http://lintian.debian.org/tags/apache2-module-does-not-depend-on-apache2-api.html> > on my package http://mentors.debian.net/package/pstar . > I apparently have to make the package depend on a virtual package called > apache2-api-* provided by apache2.2-bin (i think). I have been looking > in other packages to find out how to do this, but with no luck. I've got > apache2.2-bin version 2.2.22-13 installed on the system I build on. Look at, for example, the webauth source package in unstable or testing. > I have found this virtual package in other distros, but I can't find it > in wheezy. Yes, you won't be able to find this in wheezy since it's part of the changes for Apache 2.4 support. You need to look at packages in unstable or testing. wheezy was still Apache 2.2, and the Apache packaging for wheezy is substantially different than Apache packaging for jessie and newer releases. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k3c1ydqu@windlord.stanford.edu
Re: Splitting in /usr/lib/ and /usr/share
Jakub Wilk writes: > * Andrey Rahmatullin , 2014-03-10, 20:24: >> I also wonder if finding an arch-indep file in /usr/lib should result >> in an RC bug. > No. We should relax the policy to match the current practice. I concur -- I really doubt this is important enough these days for most packagers to spend time on. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87txb5yeb3@windlord.stanford.edu
Re: Weird conffile case
Dariusz Dwornikowski writes: > The previous maintainer of maradns modified conffiles in postinst > (dynamically checked for the maradns user id and filled > /etc/maradns/mararc with this info). This obviously rendered RC bug of > violation of policy 10.7.3 [2]. I closed the bug in a new release by not > modifying the config and leaving the user to do it, informing her/him > with a appropriate message with a user id to fill in. Does maradns require that the user ID be specified as a UID? Why doesn't it support specifying the ID as a name (which it would then turn into a UID via getpwnam)? Then you wouldn't have to modify the configuration file. If it doesn't support names now, could that be added? It might be a fairly simple patch, a few lines at most. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iorwfhy3@windlord.stanford.edu
Re: Maintainer scripts: execute command as another user: use sudo or su?
Emilien Klein writes: > TLDR: in order to execute a command as another user, should `sudo` or > `su --command` be used? su. You don't want to depend on sudo to ensure that it's available, since package users may not want sudo installed on their systems. (I tend not to install it on servers myself, since I use Kerberos authentication and don't use any system that involves sending long-term keys to servers, such as sudo's default password model.) In addition, I recommend explicitly setting the shell to use when running commands with su (using the -s flag). Specialized users for running particular applications normally should not have a valid shell, and auditors will often require that they not have a valid shell. You don't want that sort of change (possibly required by local audit policies) to break the package. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y50xv3l1@windlord.stanford.edu
Re: Working with gbp and older releases
Dariusz Dwornikowski writes: > On wto, lut 18, 2014 at 01:29:06 -0800, Russ Allbery wrote: >> I think you were also saying this, but just to be very clear: please >> also include the CVE numbers directly in debian/changelog in the entry >> for whatever release they were fixed in, not just in the bug text. The >> security team's tracking of open security vulnerabilities relies on >> being able to analyze the debian/changelog file to determine when CVEs >> were closed in the Debian packaging. > Do I need to take experimental under consideration, i.e. modify > changelog for experimental releases ? I don't believe it's particularly important whether CVEs show up as fixed in the experimental version in which they were actually fixed or in the first unstable version in which the fix appears. The former is more pedantically correct, but I believe the security team primarily cares about having a complete picture of open security bugs in unstable, testing, and stable releases. Experimental doesn't receive the same type of security support and is therefore less important for tracking purposes. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqgsoz06@windlord.stanford.edu
Re: Working with gbp and older releases
Tobias Frost writes: > Never had a CVE myself, but I think this is the way to go: > technically you don't need a debian bug, you could just write (random > example here [1]) > maradns (version-1) unstable; urgency=high > * new upstream release > - fixes CVE--, CVE-- ... > but I would file one "cover" bugs smth like "Serveral security bugs" and > listing alls CVE's in the bug's text and just add a Closes: # to the new > upstream release line. I think you were also saying this, but just to be very clear: please also include the CVE numbers directly in debian/changelog in the entry for whatever release they were fixed in, not just in the bug text. The security team's tracking of open security vulnerabilities relies on being able to analyze the debian/changelog file to determine when CVEs were closed in the Debian packaging. > For the CVE's already fixed by a older version than 1.4.12, it is > allowed to modify the old changelog entries, when the fix was actually > added. Yup. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877g8sqfdp@windlord.stanford.edu
Re: How to selectively silence git-multimail messages ?
Charles Plessy writes: > Sometimes, I can guess in advance that a push will generate a flood of > emails that will not be very relevant at best and annoying at worse on > my packaging team's mailing list. For instance, merges from upstream's > master branch, with hundreds of commits that do not change the contents > of the debian directory. Sometimes, to avoid them, I log on Alioth and > disable temporarly the commit hook. > Would anybody be able to improve the system so that, when pushing with the > --quiet option, the individual emails for each commits will be skipped ? I've been wondering about this too. Something to send out only a summary mail message if a given push results in, say, more than 20 commits would be very nice. The last time I pushed the upstream merge for OpenAFS, I think it sent about 200 mail messages with all the upstream changes since the previous release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y524tya5@windlord.stanford.edu
Re: Requirement for compat level 9
T o n g writes: > I know I can force compat level to 9 just like that. But what I want to > know is how to make sure my building environment is up to that level. > E.g., in a very old Debian system, e.g., potato, you can "set" debian/ > compat to 9, but I don't think it will work. The requirement, that's > what I'd like to know. The supported compat level is (roughly) the major version number of debhelper. (Usually the previous major version supports an experimental version of that compat level, but it hasn't been finalized.) Therefore, for compat level 9, you need debhelper 9 or later, which means stable or squeeze-backports (but not squeeze itself). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eh4nb8vm@windlord.stanford.edu
Re: File modification and the copyright
T o n g writes: > If I take a simple file (BSD-licensed), (greatly) improved it, and > include it in my package. How should I handle the situation? > - I should claim that the author of the new file is me, right? Usually I list both authors, such as: * Written by Larry Schwimmer * Extensively modified by Russ Allbery from one of my projects. > - I should inherit the BSD-licensed, right? Yes, almost always. > - How to express that the new file was based on another old file from a > different author in the debian/copyright file? Copyright: 2003-2008 John Doe 2014 Jane Doe In other words, you can list multiple copyright holders. I usually use two spaces at the start of subsequent lines to suppress word wrapping. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bnzung69@windlord.stanford.edu
Re: empty-binary-package
T o n g writes: > I am doing test build of my binary package, and I get the following > warnings. > W: zh-autoconvert: empty-binary-package > I checked and it *is* empty, only containing copyright and changelog, > nothing else. I don't know why because it looks like the installation was > fine. > I've post the build log at > http://paste.debian.net/73847/ > Please see if you can spot anything unusual, and tell me if you need > anything else. You're building multiple binary packages from the same source package. This means that the Debian package build infrastructure has no inherent way of determining which files go into which package. You have to tell it explicitly. When there are multiple binary packages built from the same source package, dh_auto_install runs upstream's make install so as to put all the files in debian/tmp. This is outside of the package staging areas for each of the packages, which are named debian/. It's up to you to move the files into the appropriate package staging area after dh_auto_install runs. The normal way to do this is to use the facilities provided by dh_install (which will be run automatically by dh binary). There are various ways to do this (see the man page), but here's the one I recommend: create files for each package, named debian/.install, and in each one, list the files from debian/tmp that belong in that package. Here's an example from one of my source packages, shibboleth-sp2, which splits the upstream installation into multiple binary packages: ==> libapache2-mod-shib2.install <== usr/bin usr/sbin etc/shibboleth usr/lib/*/shibboleth usr/share/shibboleth ==> libshibsp-dev.install <== usr/include/* usr/lib/*/lib*.so ==> libshibsp-doc.install <== doc/api/* usr/share/doc/libshibsp-doc ==> libshibsp6.install <== usr/lib/*/lib*.so.* ==> shibboleth-sp2-schemas.install <== usr/share/xml/shibboleth As you can see, you can use wildcards, and you can name whole directories or individual files. If you want the files in debian/tmp to be moved into the package in exactly the same relative paths as they occupy in debian/tmp, you can just name them, as in most of the examples above. If you want to move them to a different location, see libshibsp-doc.install, which specifies a destination directory. Be aware of one gotcha: the destination column in *.install files specifies the destination *directory*, not file name. You cannot use dh_install to rename files; you will end up with the file installed with its current name in a directory named after the thing you were trying to rename it to, which is obviously broken. If you want to rename things, you'll need to do that separately, usually with an override and some code that runs before dh_install. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ha9mp3s3@windlord.stanford.edu
Re: generic debian/rules that creates directories
Russ Allbery writes: > I guess I should say, for the sake of completeness, that you *can* make > dh_installdirs do this with the -P flag. But I would find that > confusing; I think an explicit install -d is easier to understand. And, > regardless, dh_installdirs isn't normally run before dh_auto_install, so > you'd still need an override if you're using dh. Argh. It is too run before dh_auto_install. Sorry about the incorrect information. dh_installdirs would indeed work for this... except that I'm still pretty sure it doesn't act on debian/tmp. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gajezhj@windlord.stanford.edu
Re: generic debian/rules that creates directories
Russ Allbery writes: > First, dh_installdirs is not actually useful for solving this particular > problem since dh_installdirs creates directories in the package staging > area. Your problem is happening prior to that; make install of the > upstream source into debian/tmp is failing because it's expecting > $DESTDIR/usr/bin to already exist. dh_installdirs doesn't create > directories in debian/tmp, so it doesn't help with that. I guess I should say, for the sake of completeness, that you *can* make dh_installdirs do this with the -P flag. But I would find that confusing; I think an explicit install -d is easier to understand. And, regardless, dh_installdirs isn't normally run before dh_auto_install, so you'd still need an override if you're using dh. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bnzvezzb@windlord.stanford.edu
Re: generic debian/rules that creates directories
T o n g writes: > Is it possible to have a generic debian/rules that creates directories? > The upstream Makefiles was not designed to install into $DESTDIR but > to /, so it assumes /usr/bin exists, while that creates problems for me: > install -s -m 755 autogb /export/build/zh-autoconvert/bld/zh- > autoconvert-0.3.16/debian/tmp/usr/bin > install: cannot create regular file '/export/build/zh-autoconvert/bld/ > zh-autoconvert-0.3.16/debian/tmp/usr/bin': No such file or directory > Is it possible to alter the following `debian/rules` file so that it > plays nicely with such upstream Makefiles? There have been several replies to this, but none of them quite tell you exactly what to do, so let me take a stab at that. First, dh_installdirs is not actually useful for solving this particular problem since dh_installdirs creates directories in the package staging area. Your problem is happening prior to that; make install of the upstream source into debian/tmp is failing because it's expecting $DESTDIR/usr/bin to already exist. dh_installdirs doesn't create directories in debian/tmp, so it doesn't help with that. The quick solution that doesn't help other users of upstream is to edit debian/rules and add the command: install -d debian/tmp/usr/bin prior to running make install (or, more likely, dh_auto_install). If you're using dh rule minimization and therefore aren't currently running that directly, you do this with an override, which looks like: override_dh_auto_install: mkdir -p debian/tmp/usr/bin dh_auto_install The solution that helps other users of upstream as well is to look at the upstream Makefile (or Makefile.in or Makefile.am, although probably not the last since Automake gets this right) and find where it's running that install command. Add, before that install command, the command: install -d $(DESTDIR)/$(bindir) (or $(INSTALL) if upstream is generally using that). This assumes an Autoconf project that uses $(bindir); if upstream is using something else to name the destination binary directory, use whatever variable upstream is using; if they're just using usr/bin literally, then use: install -d $(DESTDIR)/usr/bin -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvp7f065@windlord.stanford.edu
Re: [Help] Usable command options parser for C
T o n g writes: > I know that the best command options parser is the GNU getopt(3) > routines. I know that the GNU has a wrapper to generate C code around the > GNU getopt(3) routines -- the http://www.gnu.org/software/gengetopt/. > However, that wrapper, gengetopt, is dated and lacks of maintenance now. > It is causing segmentation faults on newer systems -- > https://savannah.gnu.org/bugs/?40370 > So I'm wondering what my other options are. If I need to build a tool in > C that needs command options parsing, which tool/lib will make my life a > bit easier? I don't need fancy functionalities. Nice and simple would be > good enough for me and more preferable. You could try AutoOpts: https://www.gnu.org/software/autogen/autoopts.html although "nice and simple" isn't how I'd describe it. But it's certainly actively maintained. I always just write this stuff by hand, but I also mostly don't support long options. I keep meaning to find a more portable solution to that for C programs than GNU getopt_long(3). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vbyhskxy@windlord.stanford.edu
Re: Which targets need their requirements in “Build-Depends*” declared?
Ben Finney writes: > Which of the standard ‘debian/rules’ targets need their requirements > declared in “Build-Depends” (and “Build-Depends-Indep”)? > Policy §7.7 says: > Source packages that require certain binary packages to be installed > or absent at the time of building the package can declare > relationships to those binary packages. > This is done using the `Build-Depends', `Build-Depends-Indep', > `Build-Conflicts' and `Build-Conflicts-Indep' control fields. > What standard targets does this “at the time of building the package” > entail? The “test” target? The “get-orig-source” target? What official > set of standard targets obligate their requirements to be declared in > this field? > Note that I'm not looking for opinions about what would be a good idea; > I'm looking for how this policy section is interpreted for normative > behaviour. What's currently done everywhere in the archive is that the targets run by dpkg-buildpackage (either arch or arch-indep builds) must have their dependencies listed, and dependencies for the other targets are not listed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9g11h02@windlord.stanford.edu
Re: Please help fix these build errors
Paul Wise writes:
> On Sat, Dec 7, 2013 at 11:00 AM, T o n g wrote:
>> dpkg-gencontrol: warning: package dbab: unused substitution variable
>> ${perl:Depends}
>> ^^
> If you aren't packaging Perl stuff you don't need this variable. You
> can read the dh_perl manual page to find out what this is for.
> http://manpages.debian.org/man/0/dh_perl
In this case, it's saying that it's unused, as opposed to unknown, which
means it's set but not mentioned in debian/control. (The two errors are
annoyingly similar; "unused" means something set it but you didn't use it,
and "unknown" means you tried to use it and nothing set it.) This that
dh_perl found some Perl script or library in the package and tried to
write out the substitution variable.
You probably just want to replace perl in your Depends line with
${perl:Depends}, although the details can depend on the exact situation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9gdcpx7@windlord.stanford.edu
Re: How to determine build dependency
T o n g writes: > How to determine build dependencies? Well, the best way is to read upstream documentation and possibly the configure script and figure out what the dependencies are stated to be. But if you're looking for more of an automatically-determined method, I have been known to start with the empty set and just keep building and adding dependencies to fix each failure or each missing feature in configure. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y54n3ant@windlord.stanford.edu
Re: DESTDIR Support for debian/install
T o n g writes: > Not it the 'debian/install' file that should be fixed. Here is its > content: > > --- > usr/bin/tbuild usr/lib/glimpse > usr/bin/cast usr/lib/glimpse > usr/bin/uncast usr/lib/glimpse > usr/bin/buildcast usr/lib/glimpse > usr/bin/glimpseindex > usr/bin/wgconvert usr/lib/glimpse > usr/bin/glimpse > usr/bin/glimpseserver > usr/share/man > --- > All usr/bin/ files have been successfully generated under > debian/glimpse/ usr/bin. Should I change all 'usr' to > 'debian/glimpse/usr' without knowing why, or there is more proper way to > fix it? It looks like you're installing (from upstream) directly into debian/glimpse, which is the final staging area for the package. Generally, when you're using dh_install, you want to install somewhere else (debian/tmp is the convention) and then use dh_install to move the files over, as mentioned in the dh_install page: From debhelper compatibility level 7 on, dh_install will fall back to looking in debian/tmp for files, if it doesn't find them in the current directory (or whereever you've told it to look using --sourcedir). debhelper, however, defaults to running make install DESTDIR=debian/$(PACKAGE) when the source package builds only one binary package. So, you have a few options: 1. Override the default dh_auto_install rule to pass --destdir=$(CURDIR)/debian/tmp: override_dh_auto_install: dh_auto_install --destdir=$(CURDIR)/debian/tmp (be sure to fix the indentation to be a tab), and then use dh_install per the above to move the files from there. 2. Let the package install directly into debian/glimpse and then just move the files around yourself instead of using dh_install. Which in this case means making a debian/glimpse/usr/lib/glimpse directory and moving some of the files into it. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjp5ksna@windlord.stanford.edu
Re: Bug#729375: RFS: authprogs/0.5.1-1 [ITP #616126]
Paul Wise writes: > Send the lintian authors a patch to update the current > Standards-Version. This is already in progress -- no need to send more patches. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwl9ur00@windlord.stanford.edu
Re: Cannot create regular file under /usr/share/man/man1
T o n g writes:
> On Mon, 11 Nov 2013 21:14:48 +0100, Dominik George wrote:
>> Tadaa ... it is ${DESTDIR}. Which leads us to the conclusion that, as
>> stated in my initial reply, that the lack thereof is the culprit
> So how to fix it then? Upstream has been dead for several years. I have
> fix it myself, but I don't know how.
Generally it's as simple as adding $(DESTDIR) in front of the installation
paths for all install rules in the upstream Makefiles.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y54uekdb@windlord.stanford.edu
Re: Cannot create regular file under /usr/share/man/man1
T o n g writes: > Hmm... I don't know if that is accurate, because it is at the end of > binary package *building*, not the binary package *installation*. Upstream doesn't appear to support DESTDIR in their build system and is just trying to install things directly under prefix. You can possibly work around this by setting prefix to $(CURDIR)/debian/tmp, but this really should be fixed upstream by adding support for DESTDIR. http://www.gnu.org/prep/standards/html_node/DESTDIR.html -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vbzyg0l2@windlord.stanford.edu
Re: Is it OK to have compile warnings
Gert Wollny writes:
>> To directly answer your question, since I think everyone so far has told
>> you that you should fix it, this answer from S/O [1]
>>
> [...]
>> [1]
>> http://stackoverflow.com/questions/3614691/casting-to-void-doesnt-remove-warn-unused-result-error/3615000#3615000
> One should note that the question on S/O was about opening "/dev/null"
> which is unlikely to fail.
Less unlikely than one might think. I've seen this fail in several
situations, usually because the program is being run in a partial chroot,
but on one occasion because someone deleted the device. In the latter
case, /dev/null later became a regular file because some program was
opening it with O_CREAT (aie), and that caused all sorts of truly bizarre
problems.
It's sometimes the case that errors really don't need checking, but more
rarely than people think. Good software needs error handling mechanisms
for unusual failure conditions. If you really think that this should
never fail, check the return status with assert(). That way, if the
impossible happens, at least you terminate the process rather than
continuing under false assumptions.
The only exception I've run into for this particular warning in my own
code was in monitoring software that was speaking the IMAP protocol. It
sent a "tag logout" command to the server before closing the socket, but
it truly, absolutely did not care if that write failed, since the correct
action to take if the write failed was to... close the socket. Sending
the logout command was just being polite to the server. In that case, I
used the following construct:
/* Only for clean shutdown, don't care about failure. */
if (socket_write(sd, "tag logout\r\n", 12) < 0) {}
socket_close(sd);
which gcc is happy with. (The socket_* calls are, on Linux, just macros
that expand to write and close. They exist for compatibility with
Windows, where different functions have to be used when working with
sockets.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wql4m0b3@windlord.stanford.edu
Re: how to allocate a TCP port?
Paul Elliott writes: > In any case, the sender and reciever need to share a privledged port. > What is the official way of getting one of these allocated in > /etc/services? https://www.iana.org/form/ports-services However, if by privileged port you mean a port number lower than 1024, note: User port numbers range between 1024 and 49151. If you wish to register a system port — those numbered 1023 or less — it must be done through the standardisation process of the IETF. In other words, you will need to write an RFC for your protocol and have it approved by the normal IETF process. (I think this is quite reasonable given how scarce such ports are.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gd77bs2@windlord.stanford.edu
Re: possible-gpl-code-linked-with-openssl
Dominik George writes: > That said, I my personal opinion is that doing the above is plain > nonsense from a FOSS point of view, and if upstream's intention is to > produce open software, they have to respond to the license issue. Unfortunately, upstreams don't necessarily see it that way. I've seen upstreams just refuse to add the license exception on the grounds that they think Debian's concern is silly and they refuse to cater to it. *sigh* -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u3lfbp6@windlord.stanford.edu
Re: race condition
Beco writes:
> After implementing the score (using SGID), I have a race condition in my
> game.
> The comparisson is between the just scored point with the last point
> in the top-10.
> readscore_file2memory();
> If(pt>top[9])
> {
> printf("Congrats... and stuff\n");
> reorderscore_memory();
> savescore_memory2file();
> }
> What would be the standard way to lock the scorefile?
fcntl(fd, F_SETLK). See fcntl(2).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob73faol@windlord.stanford.edu
Re: Should .pc filenames depend on the version number?
Paul Wise writes: > I am not sure which version numbers you are referring to but the API > version number should be part of the .pc file name (for example GTK+ has > gtk+-2.0.pc and gtk+-3.0.pc) but the ABI version number should not > be. The version number of the library is usually not the same as either > of the API/ABI version numbers (for example GTK+ is 2.24.21 and 3.8.4 in > Debian). One way to think of it is that you should have a version number in the *.pc file in mostly the same circumstances where you would maintain multiple versioned -dev packages in the Debian archive, and for the same reasons. Normally, you'd want to avoid this, since it means a lot more work and security fixes to both versions of the API and usually isn't needed or warranted. But sometimes the API changes so much in libraries that are so widely used that we have to maintain two parallel APIs for a while. There are a few places where it may make sense to put a version number on the *.pc file without supporting multiple versions of the -dev package at the same time in Debian, generally where there's a radical API change that will break all current users but the library isn't widely used enough that it's worth maintaining two versions, but I think those are generally rarer. But the default should be to not include it, just like the default for -dev packages is to not include version numbers in the package name or support more than one -dev package for a given library at a time. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjqpluqh@windlord.stanford.edu
Re: Upgrading the Debian Policy
T o n g writes: > The package that I want to pick up has a status: > "The package should be updated to follow the last version of Debian > Policy (Standards-Version 3.9.4 instead of 3.8.3)". > I never knew the details of Debian Policy before, but did try to read > the policy from 3.8.4 to 3.9.4, and find it a rather long list with no > further details. At first, I was trying to find a wiki/blog dedicated to > upgrading the Debian Policy, failing to find that, now I'm thinking, To expand on what Niels said, the intended workflow is to look at the upgrading checklist, either on the web at: http://www.debian.org/doc/debian-policy/upgrading-checklist or just install the debian-policy package and look at: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Find the current standards version, and then look at the summary of changes since then. If you see any change that might affect your package, there's always an associated section number; find that section in Policy and read through the details if need be to see if that's something that affects you. Most of the time, 90% of the entries are obviously unrelated to your package and don't require any further investigation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo3hkh8s@windlord.stanford.edu
Re: Bug#718323: another hyperrogue suggestion from debian reviewers
Zeno Rogue writes: > Neon Corridor has agreed to compose music for HyperRogue, under the > Creative Commons BY-NC-ND 3.0 licence. Is this OK for Debian? Unfortunately, non-commercial and no-derivatives means that it's not DFSG-free and therefore can't be part of Debian. See DFSG #1 and #3. (It would be okay for the separate non-free archive.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqmic6wp@windlord.stanford.edu
Re: Bug#668505: dwarf fortress debian package
Russ Allbery writes: > Beren Minor writes: >> I can either: >> - exclude usr/lib/gemrb from dh_makeshlibs > I would do this. If the library is not a public API that should be used > by other projects, then having out it ouf /usr/lib is probably the right > decision (particularly if that's what upstream does by default). Wow, I have no idea what happened to that sentence. That was supposed to say "keeping it out of /usr/lib is probably the right decision." -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738pjowo8@windlord.stanford.edu
Re: Bug#668505: dwarf fortress debian package
Beren Minor writes: > There is indeed one shared library in the package, located in > usr/lib/gemrb/. The library is only meant to be used by the game > executable, and that's why it is located here. The executable does not > need any help from ldconfig as it has its rpath pointing directly to > usr/lib/gemrb. I think that this unusual location is why lintian > complains about useless ldconfig. When I move the library to usr/lib, > the lintian warnings go away (although some other appear) Yes, indeed, this would be the problem. > I can either: > - exclude usr/lib/gemrb from dh_makeshlibs I would do this. If the library is not a public API that should be used by other projects, then having out it ouf /usr/lib is probably the right decision (particularly if that's what upstream does by default). So just telling dh_makeshlibs to ignore it is the correct path forward. Note that this only works if the only binaries linked with that shared library are built from the same source package. If you have to link with that shared library across source packages, you may want to consider a different approach. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvtjp0om@windlord.stanford.edu
Re: Bug#668505: dwarf fortress debian package
Beren Minor writes: > On Wed, Sep 4, 2013 at 12:49 AM, Russ Allbery wrote: >> Alternately (and in my opinion preferrably) just exclude the plugins >> directory from dh_makeshlibs: >> override_dh_makeshlibs: >> dh_makeshlibs -Xusr/lib/gemrb/plugins >> (This is really a (minor) upstream bug, since, as plugins, these objects >> should not have SONAMEs.) > Well, not setting SONAME in the plugins, and even overriding > dh_makeshlibs doesn't help with these lintian warnings. Hm, that makes me really wonder what's going on here. That makes me think there's something deeper that isn't quite right. The Lintian warnings about invoking ldconfig indicate that dh_makeshlibs thought your package contained shared libraries, and therefore added that postinst fragment, but Lintian doesn't agree. Lintian uses fairly complex logic to determine what are shared libraries and what aren't (which is suitable for a package checking tool where getting it wrong isn't a huge problem). dh_makeshlibs takes a much more conservative approach to ensure that it doesn't *miss* any shared libraries, since that could cause user-visible issues, at the cost of possibly including things it shouldn't. My understanding is that it excludes any files that don't have SONAMEs and won't consider them shared libraries. It certainly will exclude things that are explicitly excluded with -X. The short version is that dh_makeshlibs still thinks your package has non-excluded shared libraries in it. Maybe in a different directory? Or maybe the override didn't take? I don't think just ignoring the Lintian warnings is really the right solution, although it's not a bad expedient solution in the name of getting the package in front of users. The invocations of ldconfig are harmless in terms of correct functionality, but they do take a bit of unnecessary time. It's the kind of thing that I'd obsess over getting right if I were you, but I respect other people's lack of desire to care as much about little nits as I do. :) Regardless, though, I wouldn't override the Lintian warnings unless you've confirmed that your postinst actually doesn't call ldconfig, or that it *needs* to call ldconfig because your package does contain shared libraries. If neither of those are true, Lintian is actually correct; I think it's better to leave the warnings visible so that people (including yourself later on) know it's an unfixed problem, rather than suppressing them. You don't have to fix every Lintian warning immediately; some of my packages have had them for a time until I found the right solution. (Of course, I'm not a sponsor, and some sponsors may have different policies.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ioygihss@windlord.stanford.edu
Re: Bug#668505: dwarf fortress debian package
Scott Howard writes: > 3) Lintian report: > I: gemrb: desktop-entry-lacks-keywords-entry > usr/share/applications/gemrb.desktop > I: libgemrb: hardening-no-fortify-functions > usr/lib/gemrb/plugins/2DAImporter.so > I: libgemrb: hardening-no-fortify-functions > usr/lib/gemrb/plugins/BAMImporter.so > I: libgemrb: hardening-no-fortify-functions > usr/lib/gemrb/plugins/CREImporter.so > W: libgemrb: postinst-has-useless-call-to-ldconfig > W: libgemrb: postrm-has-useless-call-to-ldconfig > the first 4 are minor and can be fixed if you'd like to whenever you > get a chance. > The last two should be overridden for being a bug in debhelper. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205142 Alternately (and in my opinion preferrably) just exclude the plugins directory from dh_makeshlibs: override_dh_makeshlibs: dh_makeshlibs -Xusr/lib/gemrb/plugins (This is really a (minor) upstream bug, since, as plugins, these objects should not have SONAMEs.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uzdo714@windlord.stanford.edu
Re: multi arch shared libarary with non multi arch -dev package?
Paul Elliott writes: > Is it OK to have a shared library multi arch with the corresponding -dev > package not multi arch? > The the -dev package contains some utilitiy arch dep executables and > thus can not be made multi arch? Yes, absolutely. Much of the benefit of multi-arch comes from just having the libraries be multi-arch, and we've not yet made a push to multi-arch the dev packages. The dev packages pose a variety of additional challenges that we haven't completely sorted through. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nb05dgo@windlord.stanford.edu
Re: correct packaging of web applications
Arno Töll writes: > On 23.07.2013 20:08, Russ Allbery wrote: >> Hm, how do you deal with the conf.d vs. conf-available change and the >> completely different maintainer script actions? > there are several possibilities, but I suggest something like [1] which > I wrote for that purpose. > [1] > http://wiki.debian.org/Apache/PackagingFor24#Making_web_applications_compatible_to_both.2C_Apache_2.2_and_2.4 Ah! Yes, of course. I should have thought of those techniques. Thanks! -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738r4nbm9@windlord.stanford.edu
Re: correct packaging of web applications
Alexander Wirt writes: > On Tue, 23 Jul 2013, Russ Allbery wrote: >> You pretty much have to branch to support both. The packaging is >> substantially different. > I have several packages working well for 2.2 and 2.4. At least for > webapps, it is possible. Hm, how do you deal with the conf.d vs. conf-available change and the completely different maintainer script actions? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txjlp2ss@windlord.stanford.edu
Re: correct packaging of web applications
Alexander Wirt writes: > Arno Töll schrieb am Tuesday, den 23. July 2013: >> you can stop worrying about Apache2 2.2 right now. Any new package you >> are going to upload will go through Sid into Debian which will have >> Apache 2.4 only. > To be honest: I don't think thats true. As long as you care about > backporting your package to stable, 2.2 should still be considered. You pretty much have to branch to support both. The packaging is substantially different. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwpds57x@windlord.stanford.edu
Re: correct packaging of web applications
Sebastian Tramp writes: > In 5.1.2 "Registering and unregistering an application with web servers" > of the webapps-common documentation [1] there is the hint to create > apache config files in /etc/PACKAGE/xxx.conf and symlink it to the > conf.d directory of the apache. This is now obsolete with Apache 2.4. There is no longer a conf.d directory; instead, there is a conf-available directory and a2enconf/a2disconf helper programs. > Unfortunately there is no discussion on how to reload the apache > configuration? /usr/share/doc/apache2/PACKAGING.gz The short version for most packages is "use dh_apache2". -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87siz6cp8x@windlord.stanford.edu
Re: PostScript with Copyright from Adobe Systems
Mathieu Malaterre writes: > On of my upload was recently rejected. The reason was that an icon > file generated using Adobe did contained a copyright statement: > $ apt-get source pixelmed-java > $ strings ./com/pixelmed/web/favicon.ill |grep Copyright > %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1987-1998 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1987-1996 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1992-1996 Adobe Systems Incorporated All Rights Reserved) > %%Copyright: ((C) 1987-1997 Adobe Systems Incorporated All Rights Reserved) This problem, perhaps? http://wiki.debian.org/qa.debian.org/type1nondfsg Seems weird to have it in a favicon, though. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip0boh3u@windlord.stanford.edu
Re: Files with "All rights reserved."
Mathieu Malaterre writes: > My pixelmed-java upload has been rejected for the following reason: > o com/pixelmed/web/package.html is "Copyright all rights reserved" > The only reference I could find about this, is the following [1]: > http://forums.debian.net/viewtopic.php?f=20&t=62656#p363466 > Could someone please point me to proper debian documentation > explaining the issue with "all rights reserved". "All rights reserved" was a magic legal phrase given meaning by the Buenos Aires Convention, which required that phrase be present in order to get international copyright protection under that convention. The Buenos Aires Convention was an American (in the continental sense) copyright agreement that predated American adoption of Berne. All signatories to Buenos Aires are now signatories to Berne and have been since 2000 when Nicaragua signed, so apart from some technicalities that remain in effect in the broader context of Berne, it no longer has any real effect. In particular, Berne eliminates the need for appending the magic "All rights reserved" phrase in order to get international copyright protection. The short version is that it's a legal vestigiality, and you can usually just ignore it. There is probably some upstream somewhere that (confusingly) uses that as their (non-free) license statement, but as long as a clear license statement accompanies a copyright statement with that phrase, you can safely consider it legal boilerplate and ignore it. I suspect the problem in this case is the lack of some accompanying clear license statement. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v18w2fs@windlord.stanford.edu
Re: PHP libraries in /usr/share/
Tomasz Muras writes: > It looks like a common place to put PHP libraries is under > /usr/share. However, our wiki page [1] says: > /usr/share/ : Architecture-independent (shared) data > I think the "data" bit there is misleading, are you OK to remove it? For > the PHP packages, it's really a source code that we put there. That's the wording from the FHS, so rather than removing it, I think it would be better to add a clarification of what the FHS means by "data" (which is basically "anything that isn't a user-executable program or configuration file and includes such things as architecture-independent libraries"). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4fe5gnn@windlord.stanford.edu
Re: Need detailed help on creating a Debian package (package name)
T o n g writes: > On Tue, 25 Jun 2013 20:45:15 -0700, Russ Allbery wrote: >> The typical thing to do in this sort of situation is to document the >> required modification in README.Debian; it's not entirely satisfactory, >> but sometimes there isn't another good option. > Understand & will do. So just create a README.Debian under the debian > directory, parallel to the README provided by the upstream right? If you create debian/README.Debian, debhelper (assuming you're using that) will install it as README.Debian in the /usr/share/doc directory for the first package listed in debian/control. If you have multiple packages built from the same source package, you want to instead name the package debian/.README.Debian, where is the package that should get that documentation. > One more question related to the package I'm building. The upstream > call it pam-ssh-agent-auth, and the tarball is called > pam_ssh_agent_auth-0.9.5.tar.bz2, in which contains a directory named > pam_ssh_agent_auth-0.9.5. But the RFP wants to call it libpam-ssh-agent > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595817). Not libpam-ssh-agent-auth? Although I suppose that doesn't matter that much. > Let's suppose it'd be called libpam-ssh-agent in Debian, what exactly > should I do to the tarball name and expanded directory name? mv pam_ssh_agent_auth-0.9.5.tar.bz2 libpam-ssh-agent_0.9.5.orig.tar.bz2 Don't do anything at all with the expanded directory name. You don't need to change the tarball in the slightest. > Is there anywhere else that I should also change? Any of these renaming > should be packed in the Debian source package as patches? Nope. The Debian package will be named based on debian/control and debian/changelog, and you just need to be sure the build system can find the *.orig.tar file when building the source package (by naming it in the very specific format _.orig.tar.). Everything else is automatic, including unpacking the upstream tarball into the correct directory regardless of what the contents of the upstream tarball look like. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjuc9sl1@windlord.stanford.edu
Re: Need detailed help on creating a Debian package (post-install configuration)
T o n g writes: > I've successfully built a package, the building and installation was > fine. The problem is that when people use Debian packages, they tend to > assume that the package will work out of the box, whereas this pam-ssh- > agent-auth PAM module need a bit of post-install configuration before it > can be used, which I found at > http://www.evans.io/posts/ssh-agent-for-sudo-authentication/ > I.e., it need to configure 3 system files, /etc/sudoers, > /etc/pam.d/sudo, and /etc/ssh/sudo_authorized_keys. > I've trying to automate the configuration as much as possible and have > created patch files for /etc/sudoers, and /etc/pam.d/sudo: > etc/sudoers: http://paste.debian.net/12646/ > /etc/pam.d/sudo: http://paste.debian.net/12647/ For /etc/sudoers, the Debian sudo package supports loading configuration fragments dropped into /etc/sudoers.d. So you can just install the configuration fragment there. For the PAM configuration, do you have to install this module *only* for sudo and not for any other program? Normally, in Debian, you would use the pam-auth-update mechanism to customize common-auth, which handles things like skipping other modules if an overriding module succeeds. But that will of course affect common-auth for all PAM-enabled applications. If you need to customize *only* /etc/pam.d/sudo, I'm afraid that Debian Policy says you're not allowed to do that. Basically, configuration files are owned by a single package, and only that package may modify it. That package *can* provide an interface for modifications that other packages can use, but for this sort of thing, that's probably overkill. The typical thing to do in this sort of situation is to document the required modification in README.Debian; it's not entirely satisfactory, but sometimes there isn't another good option. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc51pmb8@windlord.stanford.edu
Re: Bug#710473: RFS: bats/0.2.0-1
Grzegorz Niewisiewicz writes: > OK, so I'll change to "optional". > BTW: what kind of packages should be classified as "extra"? The distinction between optional and extra is basically pointless these days. That said, I usually classify packages as extra if they are particularly obscure, if they are only useful for very specific purposes (such as all debugging symbol packages), or if they conflict with packages with a higher priority (such as alternative implementations of the same functionality). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738s5lsqu@windlord.stanford.edu
Re: What's the proper way to build from debian dsc
T o n g writes: > So I found the glimpse dsc file at > ftp://ftp.cstone.net/debian/pool/non-free/g/glimpse/glimpse_4.18.5-1.dsc > Can anyone explain me in simple commands how I can build and test upload > this glimpse package please? Of course, starting from to get it, and then > properly update the debian/changelog, all the way to test upload, in as > few steps as possible. > Maybe "increase the least significant version # and add my change > comment, and my id" can be handled by a single properly parameterized > dch command, or maybe not. But proper commands always speaks for > themselves. % export DEBEMAIL=mlist4sunt...@yahoo.com % export DEBFULLNAME="T o n g" # or whatever you want to use % dget ftp://ftp.cstone.net/debian/pool/non-free/g/glimpse/glimpse_4.18.5-1.dsc % cd glimpse-4.18.5 # make required changes to the package # change Maintainer in debian/control to match DEB* settings above % dch -i # add descriptions of your changes using your editor, opened by dch # save and exit % debuild # if build is successful, *.deb packages will be left up one level # install packages, test, iterate as needed % cd .. % debsign *.changes # the previous step requires you have a GnuPG key set up They're now ready to upload, which you probably want to do with dput. If you're uploading it to mentors, see the mentors documentation for the correct dput configuration and target. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ndt583k@windlord.stanford.edu
Re: pristine-tar and upstream zip
Felix Natter writes: > So I add a download rule: > get-orig-source: > uscan --force-download --repack > and use the result as input to git-import-orig and everything should be > ok? Yup, that's what I'd do. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc6dv82w@windlord.stanford.edu
Re: pristine-tar and upstream zip
Felix Natter writes:
> as far as I understand Debian packaging, the .orig.tar.{gz,bz2} shall
> have the same checksum as the original upstream tarball (by using
> pristine-tar). This worked for me when the upstream tarball is *.tar.gz,
> but in a package libidw-java, where the upstream tarball is *.zip, this
> does not seem to work:
*.zip is not a supported upstream compression format in the Debian
archive, so git-buildpackage is converting it to something else for you.
You will have to repack an upstream distribution in *.zip format to
something else, I'm afraid, and therefore won't be able to use the
upstream distribution verbatim.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip2dy5he@windlord.stanford.edu
Re: Multiarch and architecture specific headers
Thomas Moulard writes: > On Tue, May 14, 2013 at 9:56 AM, Russ Allbery wrote: >> Thomas Moulard writes: >>> A package I maintain contains a configuration header (vpConfig.h) >>> which differ depending on the architecture we are (here the >>> dependencies are not the same on i386 and powerpc). >>> So far, the only solution I can think of is moving this header into >>> /usr/include/ >>> and patching the .pc file accordingly. >> There should be no need to modify the *.pc file. (Indeed, I think that >> would be incorrect.) /usr/include/ is part of the default >> search path for the compiler for exactly this purpose. > Hum I see. However, the headers are located into include/visp/* and > not include/* > so still I think patching the .pc containing already > -I/usr/include/visp to append > -I/usr/include/`dpkg-architecture -qDEB_HOST_MULTIARCH` is necessary... Oh, yes, indeed. You may want to try to talk upstream out of that include style. It's essentially always better to not have the -I flag and instead require that programs using those headers use the full name of the header. In other words, omit -I and modify programs to do: #include The whole point of putting the headers in the visp subdirectory is for namespace management: it avoids problems if they conflict with some other header name. You don't want to then go and undo the benefit of namespace management with the -I flag so that you have to worry about conflicts with other headers of the same name again! About the only time when -I makes sense is if you're doing it for API control or alternative API selection; in other words, you have (to pick an example) apr-1.0 and apr-0.4, and you want to be able to build an application against either one without changing the source code of the application, or (more generally) you have two different implementations of the same API and you want to be able to pick between them at compile time. Based on the description of libvisp, it seems unlikely that either of those apply to it. (It specifically says it's unique. :)) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v3gq0rc@windlord.stanford.edu
Re: Multiarch and architecture specific headers
Thomas Moulard writes: > A package I maintain contains a configuration header (vpConfig.h) which > differ depending on the architecture we are (here the dependencies are > not the same on i386 and powerpc). > So far, the only solution I can think of is moving this header into > /usr/include/ > and patching the .pc file accordingly. There should be no need to modify the *.pc file. (Indeed, I think that would be incorrect.) /usr/include/ is part of the default search path for the compiler for exactly this purpose. > I saw that some packages are already putting headers in this directory > but I never heard of this strategy on the Debian wiki. That's mostly because multiarch for -dev packages isn't really well-documented yet. But I believe this is the right approach. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc6me5ut@windlord.stanford.edu
Re: git packaging workflow notes, diagram
Andreas Rütten writes: > schrieb Russ Allbery : >> Yeah, I agree. That's partly what I was trying to do with my notes, >> but they need more revision, and I wouldn't at all mind the content >> being copied somewhere that's more generally editable so that other >> workflows can be added. (I'll probably keep maintaining my page to >> document precisely what I personally do, but I can make those changes >> in more than one place.) > I think it would be great if you would add it to > http://wiki.debian.org/PackagingWithGit I strongly encourage anyone who feels like going to the effort to move anything and everything from my notes page into the wiki that you feel is appropriate there. I'm happy to give my blessing in whatever licensing one may want. Given that I don't currently even have time to update the pages with some of my current practices, I'm realistically just not going to get to this myself any time soon, and people shouldn't wait for me if they feel like it would be better in the wiki. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppyavwem@windlord.stanford.edu
