Re: Debian Policy 4.1.4.0 released
Ole Streicher wrote: > Sean Whitton writes: >> On Sat, Apr 07 2018, Ole Streicher wrote: [...] >>> Sure, but why do we give up a common rule? I think the cases where >>> d/watch does not work are not so rare (at least I have quite a number >>> of them), and keeping them unified is not the worst thing we can do. >> See discussion in #515856. > Maybe I didn't read it too carefully, but I didn't find the argument why > get-orig-source is not kept for the cases where uscan doesn't do the > job. > And when I extrapolate from my packages, this is not an exceptionally > rare case. Imho Sean's last mail sums it up pretty well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Systemd user instance equivalent of dh_systemd_enable?
Hello, I'm working on a package that installs a systemd user instance unit file that needs to be enabled with # systemctl --global enable foo.service Using debhelper, dh_systemd_enable takes care of this automatically for system unit files, but not for user unit files. Is there some other (semi)automatic way of doing it or should I take care of it manually in the postinst and prerm maintainer scripts? Thanks! Cheers, Dan
Re: Debian Policy 4.1.4.0 released
On Sat, Apr 7, 2018 at 8:49 PM, Ole Streicher wrote: > I have a number of "uncommon" upstreams: It would be really nice if these folks could switch to something more standard. Have they considered using a version control system for a start? > * aladin, download http://aladin.unistra.fr/java/download/AladinSrc.jar > look for the VERSION string in cds/aladin/Aladin.java and remove the > leading "v" (and for Pre-releases, download AladinBetaSrc.jar, or a > ad-hoc named jar, like AladinSrcV10Premiere.jar). The version number can be obtained here: http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=downloading With a pagemangle, uscan could detect the version and associated tarball. > * coyote, http://www.idlcoyote.com/programs/zip_files/coyoteprograms.zip > look for the latest file date in the zip file (no upstream versioning) There is apparently a github org for this: https://github.com/idl-coyote With a pagemangle, you can get the latest date from that: https://sources.debian.org/src/purple-discord/latest/debian/watch > * idlastro, https://idlastro.gsfc.nasa.gov/ftp/astron.tar.gz > similar (latest file date; no upstream versioning) There is apparently a github repo for this, use pagemangle: https://github.com/wlandsman/IDLAstro > * mpfit, https://cow.physics.wisc.edu/~craigm/idl/down/mpfit.tar.gz > Take version number from "Revision" in mpfit.pro and add the latest > file date This contains the mpfit.pro Revision and all dates, use pagemangle: https://cow.physics.wisc.edu/~craigm/idl/down/cmtotal.txt PS: the $Id things are from CVS, could you ask upstream to publicly expose their CVS repository? > * skyview, https://skyview.gsfc.nasa.gov/current/jar/skyview.jar > look for "Version=" in skyview.settings The version number is listed on two pages, use pagemangle: https://skyview.gsfc.nasa.gov/current/cgi/titlepage.pl https://skyview.gsfc.nasa.gov/blog/ Unfortunately both are outdated compared to the jar... > * starjava-*, download via svn (subdir of > https://github.com/Starlink/starjava) > add the main LICENSE.txt file, > get the version from build.xml property, and add latest file date > (but download only tagged versions of starjava-topcat, starjava-ttools, > and starjava-table). uscan can deal with git repos just fine. > The rules may change over time (since I try to convince them to be more > friendly here), so unless there is a flexible way for me to change them > myself, I doubt it would be a good idea to put it there. We could add you to the salsa qa group so you can commit them, but given the above I think most are best dealt with by uscan. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian Policy 4.1.4.0 released
Hello, On Sun, Apr 08 2018, kact...@gnu.org wrote: > It breaks my workflow ;) I use pristine-tar(1) to store orig tarballs > with their upstream signature in git. You can continue to use your target. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian Policy 4.1.4.0 released
[2018-04-07 10:35] Ben Finney > Sean Whitton writes: > > > I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 > > people who contributed to this release, which includes several first > > time contributors of patches. > > […] > > > > 4.9 > > The ``get-orig-source`` rules target has been removed. Packages > > should use ``debian/watch`` and uscan instead. It breaks my workflow ;) I use pristine-tar(1) to store orig tarballs with their upstream signature in git. dpkg-buildpackage(1) do not extract orig.tar.gz from `pristine-tar' automatically, so I add `get-orig-source' rule that invokes `pristine-tar(1)' with proper arguments. I have debian/watch too, but it `uscan(1)` would require network access. How can I do better with new Policy?
Bug#895156: ITP: easyloggingpp -- single-header logging library for C++ applications
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: easyloggingpp Version : 9.96.4 Upstream Author : Muflihun Labs * URL : https://muflihun.github.io/easyloggingpp/ * License : MIT Programming Lang: C++ Description : single-header logging library for C++ applications Easylogging++ is a light-weight, high performance logging library for software written in C++11 and higher. It is highly configurable and extensible, supports both severity- and verbosity-based logging, provides crash handling, STL logging, integration with syslog, log rotation, performance-specific logging for profiling, pointcut-style extensions of third-party code... I’m packaging this as a pre-requisite for loggedfs.
Re: Debian Policy 4.1.4.0 released
Sean Whitton writes: > On Sat, Apr 07 2018, Ole Streicher wrote: > >> Adam Borowski writes: >>> get-orig-source merely isn't described by the Policy any more, it is >>> no different from an arbitrary private target you have in >>> debian/rules. >> >> Sure, but why do we give up a common rule? I think the cases where >> d/watch does not work are not so rare (at least I have quite a number >> of them), and keeping them unified is not the worst thing we can do. > > See discussion in #515856. Maybe I didn't read it too carefully, but I didn't find the argument why get-orig-source is not kept for the cases where uscan doesn't do the job. And when I extrapolate from my packages, this is not an exceptionally rare case. Best regards Ole
Re: Debian part of a version number when epoch is bumped
On Mon, Apr 02, 2018 at 08:41:00PM +0100, Simon McVittie wrote: > > A recap of what happened, for those who might have lost track: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10 > > The old source package contained two tar > > balls, the "real" tarball plus a separate one with patches (upstream wanted > > things separate). The build script was, say, not optimal, and I also made > > the mistake of uploading it as debian native package. By bumping the epoch > > and repackaging from scratch, I tried to fix all the mistakes I had made a > > long time ago. > > The newest version of the old tar-in-tar packaging can be seen here: > https://sources.debian.org/src/moon-buggy/1.0.51-11/ > > What I would personally have done *then*, from that starting point, would > be to bump the version to 1.0.51+repack, or maybe 1.0.51+upstream if > the new orig tarball was something that the upstream developer released, > or something similar, then package and upload revision 1 of that. That > would have been fine - no epoch needed. > > However, because you previously maintained this as a native package, > there has been no collision for the filename of the orig.tar.gz, because > before the epoch was added there *was* no orig.tar.gz; and you've already > paid the maintenance cost of having an epoch, so you might as well benefit > from it. So what I'd advise *now* would be to increase the revision to 12 > and carry on from there. This has been addressed by policy now, does you recommendation still hold? I understand the explanation for source and binary package, but I wonder if I have the right interpretation for the upstream source code: https://www.debian.org/doc/debian-policy/#uniqueness-of-version-numbers 3.2.2. Uniqueness of version numbers ... Additionally, for non-native packages, the upstream version must not be reused for different upstream source code, so that for each source package name and upstream version number there exists exactly one original source archive contents (see Files). Since the intial upload was as native package, and the latest as non-native, this does not apply to moon-buggy and I can upload with revision 12 as you suggested? thanks, Christian
Re: Debian Policy 4.1.4.0 released
Hello, On Sat, Apr 07 2018, Ole Streicher wrote: > Adam Borowski writes: >> get-orig-source merely isn't described by the Policy any more, it is >> no different from an arbitrary private target you have in >> debian/rules. > > Sure, but why do we give up a common rule? I think the cases where > d/watch does not work are not so rare (at least I have quite a number > of them), and keeping them unified is not the worst thing we can do. See discussion in #515856. -- Sean Whitton signature.asc Description: PGP signature
Bug#895139: ITP: node-babel-plugin-array-includes -- Babel plugin to replace the array includes syntax
Package: wnpp Severity: wishlist Owner: Paolo Greppi * Package name: node-babel-plugin-array-includes Version : 2.0.3 Upstream Author : Christoph Hermann * URL : https://github.com/stoeffel/babel-plugin-array-includes#readme * License : Expat Programming Lang: JavaScript Description : Babel plugin to replace the array includes syntax This Babel plugin replaces the array includes(val) syntax with a check based on indexOf. . Babel is a JavaScript compiler to use next generation JavaScript, today. . Node.js is an event-based server-side JavaScript engine. This is a build-dependency of node-yarnpkg, see ITP: https://bugs.debian.org/843021 My intention is to maintain it within the JavaScript maintainers team. The repo will be on salsa: https://salsa.debian.org/js-team/node-babel-plugin-array-includes Paolo
Re: Debian Policy 4.1.4.0 released
Paul Wise writes: > On Sat, Apr 7, 2018 at 4:40 PM, Ole Streicher wrote: > >> I have some packages where the version is not encoded in the file name, >> but must be extracted from the file content. Shall one keep >> get-orig-source here to be consistent, or what would be the right >> solution here? > > If uscan can find the right tarball, it will rename it correctly. > > If uscan cannot find a tarball, it will need assistance from a redirector. > > The fakeupstream CGI is a good place to add new redirectors. > > Please include some details and maybe we can add something. I have a number of "uncommon" upstreams: * aladin, download http://aladin.unistra.fr/java/download/AladinSrc.jar look for the VERSION string in cds/aladin/Aladin.java and remove the leading "v" (and for Pre-releases, download AladinBetaSrc.jar, or a ad-hoc named jar, like AladinSrcV10Premiere.jar). * coyote, http://www.idlcoyote.com/programs/zip_files/coyoteprograms.zip look for the latest file date in the zip file (no upstream versioning) * idlastro, https://idlastro.gsfc.nasa.gov/ftp/astron.tar.gz similar (latest file date; no upstream versioning) * mpfit, https://cow.physics.wisc.edu/~craigm/idl/down/mpfit.tar.gz Take version number from "Revision" in mpfit.pro and add the latest file date * skyview, https://skyview.gsfc.nasa.gov/current/jar/skyview.jar look for "Version=" in skyview.settings * starjava-*, download via svn (subdir of https://github.com/Starlink/starjava) add the main LICENSE.txt file, get the version from build.xml property, and add latest file date (but download only tagged versions of starjava-topcat, starjava-ttools, and starjava-table). The rules may change over time (since I try to convince them to be more friendly here), so unless there is a flexible way for me to change them myself, I doubt it would be a good idea to put it there. But feel free to do so :-) Best Ole
Re: Debian Policy 4.1.4.0 released
Adam Borowski writes: > On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote: >> Ben Finney writes: >> > Sean Whitton writes: >> >> 4.9 >> >> The ``get-orig-source`` rules target has been removed. Packages >> >> should use ``debian/watch`` and uscan instead. >> > >> > Especially for this, my ‘debian/rules’ files thank you. >> >> I have some packages where the version is not encoded in the file name, >> but must be extracted from the file content. Shall one keep >> get-orig-source here to be consistent, or what would be the right >> solution here? > > get-orig-source merely isn't described by the Policy any more, it is no > different from an arbitrary private target you have in debian/rules. Sure, but why do we give up a common rule? I think the cases where d/watch does not work are not so rare (at least I have quite a number of them), and keeping them unified is not the worst thing we can do. Best Ole
Re: Debian Policy 4.1.4.0 released
On Sat, Apr 7, 2018 at 4:40 PM, Ole Streicher wrote: > I have some packages where the version is not encoded in the file name, > but must be extracted from the file content. Shall one keep > get-orig-source here to be consistent, or what would be the right > solution here? If uscan can find the right tarball, it will rename it correctly. If uscan cannot find a tarball, it will need assistance from a redirector. The fakeupstream CGI is a good place to add new redirectors. Please include some details and maybe we can add something. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian Policy 4.1.4.0 released
On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote: > Ben Finney writes: > > Sean Whitton writes: > >> 4.9 > >> The ``get-orig-source`` rules target has been removed. Packages > >> should use ``debian/watch`` and uscan instead. > > > > Especially for this, my ‘debian/rules’ files thank you. > > I have some packages where the version is not encoded in the file name, > but must be extracted from the file content. Shall one keep > get-orig-source here to be consistent, or what would be the right > solution here? get-orig-source merely isn't described by the Policy any more, it is no different from an arbitrary private target you have in debian/rules. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? ⠈⠳⣄
Re: Debian Policy 4.1.4.0 released
Ben Finney writes: > Sean Whitton writes: >> I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 >> people who contributed to this release, which includes several first >> time contributors of patches. >> […] >> >> 4.9 >> The ``get-orig-source`` rules target has been removed. Packages >> should use ``debian/watch`` and uscan instead. > > Especially for this, my ‘debian/rules’ files thank you. I have some packages where the version is not encoded in the file name, but must be extracted from the file content. Shall one keep get-orig-source here to be consistent, or what would be the right solution here? Best regards Ole
Bug#895113: ITP: ruby-process-daemon -- Provides standard operations
Package: wnpp Severity: wishlist Owner: Manas kashyap X-Debbugs-CC: debian-devel@lists.debian.org, debian-r...@lists.debian.org * Package name: ruby-process-daemon Version : 1.0.1 Upstream Author : Samuel G. D. Williams. * URL : https://github.com/ioquatix/process-daemon * License : Expat Programming Lang: Ruby Description : Defines a daemon using a Ruby class It provides common functionality like start, stop . It is a stable and helpful base class for long running tasks and daemons Provides standard `start`, `stop`, `restart`, `status` operations.
Re: Debian Policy 4.1.4.0 released
On Sat, Apr 07, 2018 at 08:02:11AM +0200, Andreas Tille wrote: > On Sat, Apr 07, 2018 at 10:35:02AM +1000, Ben Finney wrote: > > Sean Whitton writes: > > > > > > 4.9 > > > The ``get-orig-source`` rules target has been removed. Packages > > > should use ``debian/watch`` and uscan instead. > > > > Especially for this, my ‘debian/rules’ files thank you. > > While I really like to have this consistent approach but it seems I've > missed how uscan can spot new versions in for instance untagged VCS or > download files with changing content but no version number. Is there > some way to do this with something else than a manually craftet script? Since devscripts 2.18.1, uscan is able to track the HEAD of a git a repository. See the section titled "direct access to the git repository (HEAD)" in uscan(1) for an example. It is possible to choose how to customize how the upstream version string is created using the "pretty" option. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: Debian Policy 4.1.4.0 released
Hi Andreas
>> > 4.9
>> > The ``get-orig-source`` rules target has been removed. Packages
>> > should use ``debian/watch`` and uscan instead.
>>
>> Especially for this, my ‘debian/rules’ files thank you.
>
> While I really like to have this consistent approach but it seems I've
> missed how uscan can spot new versions in for instance untagged VCS or
> download files with changing content but no version number. Is there
> some way to do this with something else than a manually craftet script?
yes, d/watch can use the qa.debian.org fakeupstream service to create a fake
new release for every
commit. I use this on projects that have very occasional (bugfix-only) commits
and don't seem to be
interested in actually making releases any more:
https://sources.debian.org/src/svn-all-fast-export/1.0.10+git20160822-3/debian/watch/
opts="uversionmangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3/, \
filenamemangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3.tar.gz/" \
https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=github_commits_package_json/svn-all-fast-export/svn2git
\
.*/archive/(.*\.tar\.gz?.*)
A version 1.0.10+git20180406 would therefore appear from a commit made
yesterday and if I were to package
and upload that version, that would also be the upstream part of the version
string I'd use. With uscan
integration, tools like the UDD Maintainer Dashboard also show when new commits
are made.
(Thanks to Paul Wise for creating this a couple of years ago when I was musing
on how to track this sort
of upstream)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
