Re: Debian Policy 4.1.4.0 released
[trimming the CC a bit; Russ and Ian read -devel] Hello Jonathan, Andreas, I don't think that what either of you have said is a response to the reasons that there were for removing this optional target from Policy. The thought driving this is that not every trick in a Debian package maintainer's toolbox should be detailed in Policy. What we want to write down here are techniques that apply to most packages, where the cases to which the techniques do not apply can be written down too. The problem with get-orig-source is that it is always an edge case. It's only needed when d/watch and Files-Excluded aren't sufficient, which already puts you out in the weeds, and it is going to need to work differently in every package that uses it. So it doesn't make sense to standardise it. However, the use cases that you raise are valid, and I agree with you that package maintainers should make it possible for users to extract the information that the two of you are trying to extract. They might do that by providing a rules target called get-orig-source, which is perfectly allowed. But that's now package-specific machinery. It seems that what you actually want is not a very loose and unhelpful get-orig-source convention, but a recommendation or requirement that package maintainers make it possible to obtain a list of the files that were excluded, or similar. Maintainers could fulfill that using Files-Excluded, a rules target, text in README.source, or whatever. If you think you know exactly what that recommendation or requirement should be, please file a new bug proposing its addition to Policy. That's something that it makes sense to standardise, unlike get-orig-source. On Tue, Jul 03 2018, Andreas Tille wrote: > Since this does not exist any more I'm afraid we will end up with more > upstream tarballs a third person will not have any clue how to fetch > the source. IMHO that's an unfortunate change in policy. I don't see why removing an /optional/ target, which you can still use if you want to, makes it likely we'll end up with more such source packages. The fact that the target isn't there won't make it much less likely someone will think, "I should ensure the tarball is fetchable." -- Sean Whitton signature.asc Description: PGP signature
Re: Debian Policy 4.1.4.0 released
> Git mode for uscan helps as well in many cases. Is the git mode currently broken? I keep getting the error message "fatal: Not a valid object name" when fetching a new release: $ uscan --download-version 9.2.25 uscan: Newest version of jetty9 on remote site is 9.2.25, specified download version is 9.2.25 Cloning into bare repository '../jetty9-temporary.15124.git'... remote: Counting objects: 6674, done. remote: Compressing objects: 100% (4546/4546), done. remote: Total 6674 (delta 2037), reused 3517 (delta 785), pack-reused 0 Receiving objects: 100% (6674/6674), 18.04 MiB | 7.95 MiB/s, done. Resolving deltas: 100% (2037/2037), done. fatal: Not a valid object name uscan die: git archive failed Emmanuel Bourg
Re: Debian Policy 4.1.4.0 released
Hi Sean, On Tue, Jul 03, 2018 at 09:59:55AM +0100, Sean Whitton wrote: > [trimming the CC a bit; Russ and Ian read -devel] > > Hello Jonathan, Andreas, > > I don't think that what either of you have said is a response to the > reasons that there were for removing this optional target from Policy. > > The thought driving this is that not every trick in a Debian package > maintainer's toolbox should be detailed in Policy. What we want to > write down here are techniques that apply to most packages, where the > cases to which the techniques do not apply can be written down too. > > The problem with get-orig-source is that it is always an edge case. > It's only needed when d/watch and Files-Excluded aren't sufficient, > which already puts you out in the weeds, and it is going to need to work > differently in every package that uses it. So it doesn't make sense to > standardise it. We had discussed this some weeks ago. My answer was: Policy should enforce that any random person gets a tool to reproduce the upstream tarball. Usually it is uscan but if there is no chance to accomplish that task with uscan some alternative should be provided. I have seen many such "edge cases" and IMHO policy should cover all packages including edge cases. We are extremely picky to document the copyright and license of every single file in a source tarball. I fail to see a good reason why we should not encourage maintainers to also provide code to fetch those files. > However, the use cases that you raise are valid, and I agree with you > that package maintainers should make it possible for users to extract > the information that the two of you are trying to extract. They might > do that by providing a rules target called get-orig-source, which is > perfectly allowed. But that's now package-specific machinery. I understand that the sense of the policy change is that it is package specific and that I'm allowed to use it. However, I'm now missing a highly ranked documentation to point a newcomer to which answers the question how to fetch the source code if uscan fails. > It seems that what you actually want is not a very loose and unhelpful > get-orig-source convention, but a recommendation or requirement that > package maintainers make it possible to obtain a list of the files that > were excluded, or similar. Maintainers could fulfill that using > Files-Excluded, a rules target, text in README.source, or whatever. Not really, I do not want to use README.source or something like this. I have a *personal* policy: I will not sponsor any package if there is no code I could run that recreates the source tarball. May be I'm to strict and the sponsee might find some other sponsor. The Debian policy change simply weakens my point where I think there are very good reasons for. > If you think you know exactly what that recommendation or requirement > should be, please file a new bug proposing its addition to Policy. > That's something that it makes sense to standardise, unlike > get-orig-source. I would love to create a new bug report but this would rather be: Provide get-orig-source target if (and only if) uscan would fail. The previous discussion seem to show a tendency that this bug will be at best tagged wontfix which for the moment prevents me from calling reportbug right now. Kind regards Andreas. > On Tue, Jul 03 2018, Andreas Tille wrote: > > > Since this does not exist any more I'm afraid we will end up with more > > upstream tarballs a third person will not have any clue how to fetch > > the source. IMHO that's an unfortunate change in policy. > > I don't see why removing an /optional/ target, which you can still use > if you want to, makes it likely we'll end up with more such source > packages. The fact that the target isn't there won't make it much less > likely someone will think, "I should ensure the tarball is fetchable." > > -- > Sean Whitton -- http://fam-tille.de
Re: Bug#515856: Debian Policy 4.1.4.0 released
On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > Jonathan Nieder writes: > > > Context: I have run into a few packages that used the +dfsg convention > > without documenting what they removed from the tarball and I was not > > able to locally update them. :( > > This is one of the cases that now has a better solution and more standard > tools than the get-orig-source target, specifically Files-Excluded in > debian/copyright. See the documentation of Files-Excluded in uscan(1). Files-Excluded requires to use the new copyright format, and is far less powerful than a shell script. This is not a true replacement. How many packages are using Files-Excluded ? Cheers, -- Bill. Imagine a large red swirl here.
Re: Bug#515856: Debian Policy 4.1.4.0 released
Hi, On 07/03/2018 01:20 PM, Bill Allombert wrote: > How many packages are using Files-Excluded ? 1781 Using codesearch.d.o [1] to look through the debian/copyright files, then running curl -s https://codesearch.debian.net/results/2d02749753b89563/packages.json | jq -r '.Packages[]' | wc -l gets the list of the source packages. Best, Andrius [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+Files-Excluded&perpkg=1 -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Bug#515856: Debian Policy 4.1.4.0 released
On Tue, Jul 03, 2018 at 12:20:28PM +0200, Bill Allombert wrote: > On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > > > > This is one of the cases that now has a better solution and more standard > > tools than the get-orig-source target, specifically Files-Excluded in > > debian/copyright. See the documentation of Files-Excluded in uscan(1). > > Files-Excluded requires to use the new copyright format, and is far less > powerful than a shell script. This is not a true replacement. To be honest: If the fact that get-orig-source is not part of Debian policy any more would have the effect that people get motivation to replace the old copyright format by the modern one I would stop asking for re-introducing get-orig-source. > How many packages are using Files-Excluded ? Codesearch will give you the exact number. I've checked on my local clones of Debian Med packages (released and in preparation): 266 out of 901 are using Files-Excluded Remark: I'm using Files-Excluded even when there is a need to write an get-orig-source script and parse debian/coprright for it. It might be different over the whole package pool but for my use case its more than 25%. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#515856: Debian Policy 4.1.4.0 released
On Tue, Jul 03, 2018 at 04:11:14PM +0200, Bill Allombert wrote: > > When the new copyright format was introduced, it was agreed there > would be no compulsion to migrate to the new copyright format. > > There is nothing that prevent to add Files-Excluded stanzas to old > format copyright files for documentation, though uscan will ignore them. Its called "machine readable copyright" format. The old one is not machine readable. Thus if you want Files-Excluded use the modern format. And if you want some consistent reading experience for your team mates please use it as well. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Bug#515856: Debian Policy 4.1.4.0 released
On Tue, Jul 03, 2018 at 03:43:19PM +0200, Andreas Tille wrote: > On Tue, Jul 03, 2018 at 12:20:28PM +0200, Bill Allombert wrote: > > On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > > > > > > This is one of the cases that now has a better solution and more standard > > > tools than the get-orig-source target, specifically Files-Excluded in > > > debian/copyright. See the documentation of Files-Excluded in uscan(1). > > > > Files-Excluded requires to use the new copyright format, and is far less > > powerful than a shell script. This is not a true replacement. > > To be honest: If the fact that get-orig-source is not part of Debian > policy any more would have the effect that people get motivation to > replace the old copyright format by the modern one When the new copyright format was introduced, it was agreed there would be no compulsion to migrate to the new copyright format. There is nothing that prevent to add Files-Excluded stanzas to old format copyright files for documentation, though uscan will ignore them. Cheers, Bill.
Bug#902930: ITP: libanyevent-socket-perl -- AnyEvent::Socket implements various utility functions for handling internet protocol addresses and sockets, in an as transparent and simple way as possible.
Package: wnpp Severity: wishlist Owner: Ian Jackson * Package name: libanyevent-socket-perl Version : 7.14 Upstream Author : Marc A. Lehmann * URL : https://metacpan.org/pod/AnyEvent::Socket * License : Artistic / GPL1+ Programming Lang: Perl Description : TCP sockets and socket utilities for AnyEvent AnyEvent::Socket provides functions for creating and handling TCP sockets. It also implements various utility functions for handling internet protocol addresses and sockets.
Bug#902940: ITP: omegamap -- describing selection and recombination in sequences
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: omegamap Version : 0.5 Upstream Author : Daniel Wilson * URL : http://www.danielwilson.me.uk/omegaMap.html * License : GPL Programming Lang: C, C++ Description : describing selection and recombination in sequences Team-maintained on salsa.debian.org/med-team/omegamap.
Re: workarounds for Planet bugs?
Hello Daniel El 02/07/18 a las 20:04, Daniel Pocock escribió: > > > Hi everybody, > > Planet struggles to poll certain blogs (see below), including some new > contributors. > > Does anybody know of workarounds these people can use until Planet is > updated to a recent version of planet-venus? For example, at least > three of them I communicated with are using Wordpress, is there some > setting in Wordpress they need to enable or disable to make their feed work? > I've switched some feeds to HTTPS: https://salsa.debian.org/planet-team/config/commit/32a1934f4f142a664f397f5c6c8b6cc664689f60 I hope this fixes the issue. In other cases, the blogs were inaccessible. I suggest to contact with each one of their authors, because the issue may not be the same for all of them, and try to find a working feed that can be added to the planet. Regards, > Regards, > > Daniel > > > > $ curl -o - -s https://planet.debian.org | grep 'href=""' > > (feed) > Anisa Kuci href="http://anisakuci.com/feed/";>(feed) > Benjamin Kerensa (feed) > Eduard Bloch href="http://www.rootfs.net/jaws/data/xml/blog.Debian.rss";>(feed) > James Bromberger href="https://blog.james.rcpt.to/category/computing/linux/feed/";>(feed) > Jona Azizaj href="https://blog.azizaj.com/tag/debian/feed/";>(feed) > Jose Luis Rivas href="https://ghostbar.co/feed-planetdebian.xml";>(feed) > Kristi Progri href="http://kristiprogri.com/feed/";>(feed) > Marco d'Itri href="http://blog.bofh.it/debian/?format=atom";>(feed) > Martin Meredith (feed) > -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
A message from CMake upstream: announcing dh-cmake
Hello everyone! My name is Kyle. I work at Kitware, Inc., the upstream maintainer of the CMake buildsystem (https://www.cmake.org/) and VTK, the Visualization Toolkit (https://www.vtk.org/). As some of you on the Debian Science list may have heard, we are making an effort to officially support our flagship product, VTK, on Debian and its derivatives. To that end, we have created a new set of Debhelper utilities to meet the unique challenges of packaging a large CMake- based project like VTK. We have named this project "dh-cmake". It allows Debhelper to take advantage of some of the more advanced capabilities of CMake. For example: * CMake's install() command takes an optional COMPONENT parameter, which allows you to break the installation up into multiple "components", such as "Libraries" and "Development". dh-cmake allows you to assign these components to separate binary packages, to avoid having to enumerate every file or file glob in the *.install files. * Projects that are CTest-aware can optionally have the output of dh_auto_configure, dh_auto_build, and dh_auto_test captured by CTest and submitted to a CDash server as part of a continuous integration process. This is very useful for making sure a large software project builds properly on Debian. * CPack includes a mechanism to declare dependencies between installation components, for example, stating that the "Development" component depends on the "Libraries" component. dh-cmake can propagate this information into the output packages, so that libexample-dev will automatically depend on libexample. You can download the source code at https://gitlab.kitware.com/debian/dh-cmake, and read more details about the rationale and how it works. You can also install the binaries from our own APT repository. Follow the instructions at https://apt.kitware.com/ to set up the repository, and then install the "dh-cmake" package. Our end goal is to get both dh-cmake and VTK into Debian proper, but it is still in an experimental state, and there is still a lot of work to be done yet. We would like to get some feedback on dh-cmake, and we will eventually file a formal ITP and RFS for it as it becomes more mature. We would also like to see other CMake-based packages follow our lead and use these utilities. If you have a package that uses CMake, we encourage you to give dh-cmake a try. Thank you in advance for the feedback. We are very excited to venture into Debian development. Kyle
Bug#902960: ITP: sweed -- assessment of SNPs for their evolutionary advantage
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: sweed Version : 3.2.1 * URL : https://sco.h-its.org/exelixis/web/software/sweed/ * License : GPL Programming Lang: C Description : assessment of SNPs for their evolutionary advantage About to be team-maintained with salsa.debian.org/med-team/sweed
Re: A message from CMake upstream: announcing dh-cmake
On Wed, Jul 4, 2018 at 3:56 AM, Kyle Edwards wrote: > Our end goal is to get both dh-cmake and VTK into Debian proper, but it > is still in an experimental state, and there is still a lot of work to > be done yet. We would like to get some feedback on dh-cmake, and we > will eventually file a formal ITP and RFS for it as it becomes more > mature. We would also like to see other CMake-based packages follow our > lead and use these utilities. If you have a package that uses CMake, we > encourage you to give dh-cmake a try. Once it is available in the archive, I'd suggest announcing it via DevNews: https://wiki.debian.org/DeveloperNews -- bye, pabs https://wiki.debian.org/PaulWise
