Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)
On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > Just yesterday > I had an example where the upstream download archive is lacking some > files from upstream SVN which need to be merged in to enable building > the software[1]. This often happens in Autotools packages whose upstream developer works from git, produces (but does not use) dist tarballs, and does not use `make distcheck`. You don't particularly need to repack the orig tarball for this: what I normally do is to put the missing file in `debian/dist` and copy it into place during the build. The only times repacking the orig tarball is required are: - there is non-distributable content in it - there is non-free content in it (and it isn't in the non-free component) - it isn't available in a format supported by dpkg (with the extreme case of this being that there is no orig tarball at all, only a VCS repository) You might also choose to repack it if there's enough free-but-unnecessary content to be a practical problem, either because it would require you to put an impractical amount of missing source code in debian/missing-sources or just because it's very large. smcv
Re: get-orig-source and standardized source repacking
Simon McVittie writes: > The only times repacking the orig tarball is required are: > > […] > - it isn't available in a format supported by dpkg (with the extreme case > of this being that there is no orig tarball at all, only a VCS repository) A case more extreme: the work is not distributed upstream as tarball nor as VCS. It is available upstream only as disparate files, not from any single URL. (For a simple example of that, see the ‘lojban-common’ package.) -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney
Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)
On Fri, Jul 06, 2018 at 08:27:13AM +0100, Simon McVittie wrote: > On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > > Just yesterday > > I had an example where the upstream download archive is lacking some > > files from upstream SVN which need to be merged in to enable building > > the software[1]. > > This often happens in Autotools packages whose upstream developer works > from git, produces (but does not use) dist tarballs, and does not use > `make distcheck`. You don't particularly need to repack the orig tarball > for this: what I normally do is to put the missing file in `debian/dist` > and copy it into place during the build. ... and cluebat the upstream developer into please pretty please with cherry on top use "make distcheck", because while your approach works and is a decent workaround, it's extremely ugly to do so long-term. [...] -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)
On Fri, Jul 06, 2018 at 08:27:13AM +0100, Simon McVittie wrote: > On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > > Just yesterday > > I had an example where the upstream download archive is lacking some > > files from upstream SVN which need to be merged in to enable building > > the software[1]. > > This often happens in Autotools packages whose upstream developer works > from git, produces (but does not use) dist tarballs, and does not use > `make distcheck`. You don't particularly need to repack the orig tarball > for this: what I normally do is to put the missing file in `debian/dist` > and copy it into place during the build. Or just don't use that tarball but grab what's in git. An autotools dist tarball is not the preferred form for modification anyway. Meow. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: A message from CMake upstream: announcing dh-cmake
On Thu, 2018-07-05 at 14:04 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > From what you write above I tend to think that simply by not using > dh-cmake whatever upstream has defined as packaging it will be simply > ignored (ie, it will become a "standard" CMake project). Yes, this is true. dh-cmake only adds optional new functionality and doesn't take anything away from existing packages. > Now it turns out that you get a bug report where you need to split > the packaging. It's not an upstream issue per-se, but rather a > packaging one. Following normal Debian workflow that would mean > simply creating a new Debian revision. In our opinion, this actually *is* an upstream issue. To explain why, I think it would help if I give a brief explanation of the CMake philosophy. CMake is intended to be a high-level, cross-platform buildsystem that lets the end user use whatever tools they like most. Barring hard technical limitations (such as functionality that is highly specific to one operating system), if a CMake project is written properly, the developer and end user should be able to: * build and run the software on their operating system of choice, whether it be Windows, Mac, or Linux (among others), * generate build files for their favorite build tools (Makefiles, Ninja files, or project files for various IDEs), and * through the use of CPack, generate installers in whichever format they desire, including .deb, .rpm, WiX for Windows, and .dmg for Mac. Expanding on the third point, ideally, upstream would properly split the project output into components that have all the files in the right place. Then, the end user can generate well-formed packages in any format they want with CPack, or, in this case, with dh-cmake in cooperation with CPack. If any of these assumptions don't hold true, then the project isn't utilizing CMake to its full potential, and it can create a poor experience for the end user if they can't use the tools they feel most comfortable with. In this case, if a Debian developer can't generate a package from it using dh-cmake, then we consider it an upstream bug. > What would happen with dh-cmake? Would be a new upstream release > required? Would the package maintainer need to patch the packaging > editing a CMake file? In a word, yes. See my comment above about this being an upstream issue. Of course, many upstream projects won't do things correctly, and the Debian maintainer will have to do a lot of work no matter what tools they use. We realize this is unavoidable. In that case, the solution is to package it as a "traditional" Debian CMake package, without dh- cmake, the way it's always been done. This project is meant for the subset of cases where upstream DOES package it correctly, leaving almost no work for the Debian maintainer - just add configuration files for dh-cmake and it's ready to go right away, complete with upstream's dependency graph and project description. > [+dfsg] Maybe you can work out to fix this so a repackaging is not > needed? That would be *really* welcomed. I have a question about this (and I apologize if this is slightly off topic): VTK includes "convenience copies" of third-party libraries it uses to avoid "dependency hell", and also because we've made modifications to them that haven't yet been upstreamed. I know that on Debian it's not allowed to *use* these libraries (and we have flags to use the system versions instead), but do they have to be removed from the tarball entirely to comply with DFSG? If the DFSG modifications are because of a non-free file in VTK, we would certainly like to know about it, and possibly try to fix it. We don't intend to distribute anything with VTK that's under a non-free, restrictive license. Kyle
Bug#903134: ITP: milib -- library for Next Generation Sequencing (NGS) data processing
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: milib Version : 1.8.4 * URL : https://github.com/milaboratory/milib * License : Apache Programming Lang: Java Description : library for Next Generation Sequencing (NGS) data processing About to appear on https://salsa.debian.org/java-team/milib .
Re: A message from CMake upstream: announcing dh-cmake
On Fri, Jul 06, 2018 at 11:59:58AM -0400, Kyle Edwards wrote: > I have a question about this (and I apologize if this is slightly off > topic): VTK includes "convenience copies" of third-party libraries it > uses to avoid "dependency hell", and also because we've made > modifications to them that haven't yet been upstreamed. I know that on > Debian it's not allowed to *use* these libraries (and we have flags to > use the system versions instead), but do they have to be removed from > the tarball entirely to comply with DFSG? If the libraries in question are DFSG-free themselves, there's no DFSG issue and you don't need to remove them from the tarball (and we'd generally encourage not modifying the upstream tarball unnecessarily for upload to Debian). The policy about bundling is separate from the DFSG. Of course it'd be incumbent on whoever's doing the Debian upload to actually check the licensing status. -- Colin Watson [cjwat...@debian.org]
Re: A message from CMake upstream: announcing dh-cmake
On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote: > If the libraries in question are DFSG-free themselves, there's no > DFSG issue and you don't need to remove them from the tarball (and > we'd generally encourage not modifying the upstream tarball > unnecessarily for upload to Debian). The policy about bundling is > separate from the DFSG. Of course it'd be incumbent on whoever's > doing the Debian upload to actually check the licensing status. Thank you Colin, this is good to know. In that case, I will investigate VTK's DFSG issues when I get a chance. If there's something in there with a licensing issue, then we as upstream would like to fix it. Kyle
Re: A message from CMake upstream: announcing dh-cmake
On Fri, Jul 06, 2018 at 04:40:44PM -0400, Kyle Edwards wrote: > On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote: > > If the libraries in question are DFSG-free themselves, there's no > > DFSG issue and you don't need to remove them from the tarball (and > > we'd generally encourage not modifying the upstream tarball > > unnecessarily for upload to Debian). The policy about bundling is > > separate from the DFSG. Of course it'd be incumbent on whoever's > > doing the Debian upload to actually check the licensing status. > > Thank you Colin, this is good to know. In that case, I will investigate > VTK's DFSG issues when I get a chance. If there's something in there > with a licensing issue, then we as upstream would like to fix it. Whilst everything Colin wrote is true, there is also the detail that we do a copyright and license check for every file shipped in the tarball. If there are too many convenience copies this can easily outgrow the patience (or more simply the available time) of the maintainer, at which point repacking the upstream tarball is way simpler, easier and quicker. It's a convenience call the maintainer decides, but one that IMHO always ought to be done because with our current tooling removing files from the upstream tarball is an automated process that takes seconds, where the license check easily takes much more. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: A message from CMake upstream: announcing dh-cmake
On Sat, Jul 07, 2018 at 12:25:15AM +0200, Mattia Rizzolo wrote: > On Fri, Jul 06, 2018 at 04:40:44PM -0400, Kyle Edwards wrote: > > On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote: > > > If the libraries in question are DFSG-free themselves, there's no > > > DFSG issue and you don't need to remove them from the tarball (and > > > we'd generally encourage not modifying the upstream tarball > > > unnecessarily for upload to Debian). The policy about bundling is > > > separate from the DFSG. Of course it'd be incumbent on whoever's > > > doing the Debian upload to actually check the licensing status. > > > > Thank you Colin, this is good to know. In that case, I will investigate > > VTK's DFSG issues when I get a chance. If there's something in there > > with a licensing issue, then we as upstream would like to fix it. > > Whilst everything Colin wrote is true, there is also the detail that we > do a copyright and license check for every file shipped in the tarball. > If there are too many convenience copies this can easily outgrow the > patience (or more simply the available time) of the maintainer, at which > point repacking the upstream tarball is way simpler, easier and quicker. > It's a convenience call the maintainer decides, but one that IMHO always > ought to be done because with our current tooling removing files from > the upstream tarball is an automated process that takes seconds, where > the license check easily takes much more. FWIW the "tooling removing files from the upstream tarball is an automated process" is `uscan` and debian/copyright having a 'Files-Excluded:' entry Groeten Geert Stappers -- Leven en laten leven
Re: A message from CMake upstream: announcing dh-cmake
On Sat, 07 Jul 2018 00:25:15 +0200, Mattia Rizzolo wrote: > On Fri, Jul 06, 2018 at 04:40:44PM -0400, Kyle Edwards wrote: > > On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote: > > > If the libraries in question are DFSG-free themselves, there's no > > > DFSG issue and you don't need to remove them from the tarball (and > > > we'd generally encourage not modifying the upstream tarball > > > unnecessarily for upload to Debian). The policy about bundling is > > > separate from the DFSG. Of course it'd be incumbent on whoever's > > > doing the Debian upload to actually check the licensing status. > > Thank you Colin, this is good to know. In that case, I will investigate > > VTK's DFSG issues when I get a chance. If there's something in there > > with a licensing issue, then we as upstream would like to fix it. > Whilst everything Colin wrote is true, there is also the detail that we > do a copyright and license check for every file shipped in the tarball. > If there are too many convenience copies this can easily outgrow the > patience (or more simply the available time) of the maintainer, at which > point repacking the upstream tarball is way simpler, easier and quicker. > It's a convenience call the maintainer decides, but one that IMHO always > ought to be done because with our current tooling removing files from > the upstream tarball is an automated process that takes seconds, where > the license check easily takes much more. In addition to what Colin and Mattia said, repackaging/removing convenience copies is sometimes also done for other reasons, e.g. - when the embedded files take a huge percentage of the package size - to make sure they are really not used during the build process In cases where third-party files are not removed for DFSG reasons, usually the version is not created with a +dfsg suffix but frequently with +ds (debian source). Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Bettina Wegner: für klein zaches signature.asc Description: Digital Signature
