Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hi, Am Thu, Jan 27, 2022 at 02:52:18PM -0700 schrieb Sean Whitton: > > We don't remove files for the sole reason that they're intended for use > on other platforms. It's typically only done if the files are huge. So > please remove this one from the list. > > How about just saying: we always remove non-DFSG files if the package is > intended for main or contrib, and sometimes there are other files that > are removed for technical reasons or because they are both unneeded and > very large, and both these sorts of removal are documented using this > field? I like this wording. I'm not sure whether we might add what I'm doing in practice: If there is the need to remove non-DFSG files it might make sense to use other files that are typically unused for Debian and thus are just bluring the content of the tarball. I'm unsure whether we should really add this to policy but this is what I'm doing. > > + > > +These types of files, or any others that Debian does not want to > > +include in our archive, must be stripped from the upstream tarball > > +prior to uploading. The Files-Excluded field > > serves > > How about "are stripped" not "must be stripped", as the normative stuff > is explained more precisely over in the Policy manual itself? +1 > > +to document the removal of these files from the original upstream > > +source. This allows others to understand or audit how the source > > +distribution in Debian is derived from the upstream source. > > + > > + > > +Additionally, once documented in this manner, various tools such as > > +uscan or mk-origtargz can use > > +this information as instructions on how to automatically repack an > > +upstream source distribution into one suitable for use within > > Debian. > > Nice. Thanks a lot for working on this in Debian policy Andreas. -- http://fam-tille.de
Bug#976402: Proposed official virtual packages - todo and todo.txt
On 1/27/22 5:11 PM, Sean Whitton wrote: Hello David, ... Reviewing this bug, it is still not clear to me that a virtual package is wanted as opposed to just making /usr/bin/todo a path managed by the alternatives system. I'm closing the bug, but if development that has taken place in the todo.txt world since our previous dicsussion has changed matters such that there are concrete usecases for the virtual packages that you can explain, then please consider opening a new bug with that explanation. We have a significant disconnect here. The todo.txt-base (and gtd) packages place more requirements on an alternative implementations other than just owning the name. The proposed virtual package would codify that contract. That represents a concrete set of use cases, laid out previously in this thread, in Dec 2020 (the stuff about autodiscovery of the datafile, and support of hooks - both allow todo.txt-gtd to properly interact). The packages that interact with todo.txt are released: https://tracker.debian.org/pkg/todo.txt-base https://github.com/davesteele/todo.txt-base https://packages.debian.org/sid/todo.txt-gtd Also, aesthetically, I believe that Debian should have a package named todo.txt that installs todo.txt-cli by default. OTOH, I undertook this process only because Ondrej required it before supporting integration of todo.txt-cli with todo.txt-base. I'd be happy to support the majority consensus between the three of us on how to proceed. OpenPGP_signature Description: OpenPGP digital signature
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
On Thu, Jan 27, 2022 at 02:52:18PM -0700, Sean Whitton wrote: > Hello Joe, > > + > > +These types of files, or any others that Debian does not want to > > +include in our archive, must be stripped from the upstream tarball > > +prior to uploading. The Files-Excluded field > > serves This feature is orthogonal to the machine readable copyright format. It should be possible to use it with the plain old copyright format too, otherwise we are kind of renegating on our promise that the machine readable copyright format be optionnal. Cheers, -- Bill. Imagine a large red swirl here.
Bug#976402: marked as done (Proposed official virtual packages - todo and todo.txt)
Your message dated Thu, 27 Jan 2022 15:11:51 -0700 with message-id <87wnik96c8@melete.silentflame.com> and subject line Re: Bug#976402: Proposed official virtual packages - todo and todo.txt has caused the Debian Bug report #976402, regarding Proposed official virtual packages - todo and todo.txt to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 976402: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-policy Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, charlesmel...@outlook.com, on...@debian.org thanks I'd like to propose adding the virtual packages "todo" and "todo.txt" to the authoritative list of virtual package names. I'm submitting this per Policy section 3.6 and the preamble to the [authoritative list]. [Todo.txt] describes an ecosystem of task management tools that revolve around a standard for a freeform-text tasking file. The reference cli has been packaged for some time, as "todotxt-cli". It provides the executable "todo-txt". An alternative cli provider, "topydo", has been recently added, adding an executable by the same name. I propose uniting this packages using the name "todo" - the common name for the utility. Since not all todo list packages that may want to share that name conform to the todo.txt standards, I also propose "todo.txt", a strict subset of "todo", for packages which conform. Note that topydo already implements these virtual packages, and that there now exists a todo.txt-base packages that extends cli todo.txt capabilities. There is also a todo.txt-cli package in Sid. This is redundant, and has a pending RM request. I did a screen scrape of p.d.o to find any possible collisions for these names. There is a single package, devtodo (popcon 74, recently ITA'd), that installs a "todo" executable. Currently, topydo Conflicts with this package. I'd propose adding it to the "todo" virtual package. This is a request for comment per the procedure in the list. Please copy replies to this bug report. [authoritative list]: https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml [Todo.txt]: http://todotxt.org/ signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hello David, On Wed 16 Dec 2020 at 03:10PM -05, David Steele wrote: > On Wed, Dec 16, 2020 at 2:34 PM David Steele wrote: > >> >> >> On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton >> wrote: >> >>> >>> Okay, and you expect every implementation of todo.txt to have >>> tdtcleanup? I think we probably want to specify that as one of the (or >>> the only?) requirements of the virtual package. >>> >> >> No, no. >> >> The gtd stuff is an optional add-on to todo.txt. The requirements on >> todo.txt to support these types of add-ons I listed earlier in the thread. >> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402#98 Reviewing this bug, it is still not clear to me that a virtual package is wanted as opposed to just making /usr/bin/todo a path managed by the alternatives system. I'm closing the bug, but if development that has taken place in the todo.txt world since our previous dicsussion has changed matters such that there are concrete usecases for the virtual packages that you can explain, then please consider opening a new bug with that explanation. -- Sean Whitton signature.asc Description: PGP signature --- End Message ---
Processed: limit source to debian-policy, tagging 999566
Processing commands for cont...@bugs.debian.org: > limit source debian-policy Limiting to bugs with field 'source' containing at least one of 'debian-policy' Limit currently set to 'source':'debian-policy' > tags 999566 + pending Bug #999566 [src:debian-policy] debian-policy: highlight source code examples Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 999566: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999566 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hello Joe, Thanks for the patch. Here's a review: On Sat 13 Nov 2021 at 11:21PM -05, Joe Nahmias wrote: > + > + Pre-compiled executable binary or other non human-editable > files; > + The reason we remove these is also DFSG. > + > + > + > + Files intended for use with other platforms. > + We don't remove files for the sole reason that they're intended for use on other platforms. It's typically only done if the files are huge. So please remove this one from the list. How about just saying: we always remove non-DFSG files if the package is intended for main or contrib, and sometimes there are other files that are removed for technical reasons or because they are both unneeded and very large, and both these sorts of removal are documented using this field? > + > +These types of files, or any others that Debian does not want to > +include in our archive, must be stripped from the upstream tarball > +prior to uploading. The Files-Excluded field > serves How about "are stripped" not "must be stripped", as the normative stuff is explained more precisely over in the Policy manual itself? > +to document the removal of these files from the original upstream > +source. This allows others to understand or audit how the source > +distribution in Debian is derived from the upstream source. > + > + > +Additionally, once documented in this manner, various tools such as > +uscan or mk-origtargz can use > +this information as instructions on how to automatically repack an > +upstream source distribution into one suitable for use within Debian. Nice. -- Sean Whitton
