Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs
Package: debian-policy Version: 3.9.8.0 Severity: wishlist Policy section "Permissions and owners" probably shouldn't recommend contacting the base-passwd maintainer when selecting a username for a dynamically-allocated UID created by a postinst maintscript. It should continue to recommend contacting the base-passwd maintainer when the postinst script needs to create a static UID. The current base-passwd maintainer explains the reasoning for this suggested change: - Forwarded message from Colin Watson - Date: Sun, 23 Oct 2016 23:42:55 +0100 From: Colin Watson To: Sean Whitton Cc: debian-de...@lists.debian.org Subject: Re: Keysafe dynamic UID User-Agent: Mutt/1.5.23 (2014-03-12) Message-ID: <20161023224255.gh14...@riva.ucam.org> On Sat, Oct 22, 2016 at 02:57:23PM -0700, Sean Whitton wrote: > I am packaging Keysafe,[1] and the binary package keysafe-server needs > to create a new system user with a dynamically allocated UID. > > I am using the username 'keysafe'. I do not anticipate any collision > with any other package, but policy says I should e-mail you to confirm > that. Policy should probably only suggest emailing the base-passwd maintainer in the case where you need a statically-allocated ID (I'm not necessarily in a good position to judge uniqueness of dynamically-allocated IDs across the whole archive, and the chances of me requesting that you use a statically-allocated ID rather than the other way round are vanishingly small). In any case, I have no issues with this request. Thanks, -- Colin Watson [cjwat...@debian.org] - End forwarded message - -- Sean Whitton signature.asc Description: PGP signature
Bug#761219: Also update/clarify when real package has same name as virtual package
Hello, Something else that might need updating in light of dpkg's support for versioned Provides: is the advice that If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. Would a versioned Provides:, too, get ignored if there is real package with the same name present? -- Sean Whitton
DebCamp sprint?
Hello policy editors + others, There was a DebConf talk last year about the state of Policy. I also note that there was mention of off-list discussion of the current situation in the latest "Bits from the DPL". How many of the current policy editors expect to be present at DebCamp this year? How about organising a sprint to handle the current backlog? This would raise everyone's spirits about making progress with Policy. I would love to be involved. Thank you for your consideration. -- Sean Whitton signature.asc Description: PGP signature
Re: DebCamp sprint?
Dear Russ, Thank you for your reply! On Sun, Apr 30, 2017 at 05:41:03PM -0700, Russ Allbery wrote: > I think I'm currently the only active Policy editor. Not sure if the > other current editors have plans or hopes to become active again. I do not have much experience organising this kind of event. However, assuming the other policy editors don't become active, I'm optimistic that we could have a productive sprint if you were able to be involved in planning the sprint. > If I were going to prioritize the sort of work that could be done in > sprints (a lot of Policy work requires getting project consensus, > which isn't well-suited to sprints because it's hard to determine the > absence of well-founded objections in the context of a sprint), it > would be documenting the major changes in the project that Policy is > entirely silent about. I was under the impression that there were a lot of stalled bugs that were not at the "waiting for consensus" stage. Is this wrong? I was thinking that a goal for the sprint would be getting bugs to the "waiting for consensus" stage. > Off the top of my head, the most pressing: > > - Triggers > - Multiarch > - systemd integration (there's a draft in an external repo) > - FHS 3.0 > > For the first two, having Guillem or someone else deeply involved in dpkg > development on-hand would be hugely helpful since they'll have to review > the resulting document anyway. Makes sense. -- Sean Whitton signature.asc Description: PGP signature
Re: FYI: Updates to copyright and author notices
Hello, I wonder if Policy might refer to the package changelog for a reader seeking more comprehensive information on copyrights? I have in mind the Haskell team's boilerplate for d/copyright: Files: debian/* Copyright: held by the contributors mentioned in debian/changelog License: BSD-3-clause -- Sean Whitton signature.asc Description: PGP signature
Re: posix standard susv3 for shell scripts
On Fri, Jun 09, 2017 at 01:32:49PM +0200, Ralf Treinen wrote: > Any reason not to update to 4.2? Should I file a bug against debian-policy > for that? Yes -- this might need some discussion to confirm other parts of policy don't need to change to match the new standard. A bug would be the place to do that. -- Sean Whitton signature.asc Description: PGP signature
RFC: draft text for Policy sprint at DebCamp
Hello all, I just created this page: <https://wiki.debian.org/Sprints/2017/DebianPolicy> Please review the text. How can we build momentum and excitement for this sprint? It could be of huge benefit to Policy, and Debian more broadly. Backlogs and outdated docs kill motivation. Let's fix this! Russ has suggested sending out another d-d-a e-mail about Policy 4.x in about a week's time. I'd like to include this sprint in that message, so it would be great if you could take a look before then. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: move forward to Sphinx
Dear Hideki, On Thu, Jun 22, 2017 at 08:23:58PM +0900, Hideki Yamane wrote: > Here's my opinion and PoC > > https://www.slideshare.net/henrich_d/challenge-convert-policy-doc-from-docbook-to-sphinx-77172587 > > and sample output with Sphinx > http://www.ma-aya.to/~henrich/debian/policy/ Thank you for these links. Are you aware that the transition to docbook was only completed about one month ago? I am not sure there is the energy to attempt another complete transition of the manual, once again invalidating all submitted patches. (Sorry to be only negative, but I wanted to make sure you were aware of the docbook timeline.) -- Sean Whitton signature.asc Description: PGP signature
Re: RFC: draft text for Policy sprint at DebCamp
On Sat, Jun 24, 2017 at 03:48:35PM -0700, Russ Allbery wrote: > Looks great to me! And we're probably coming up on time for that new > d-d-a email. I've created Teams/Policy/bits on gobby.debian.org to draft this. I've written some text about the sprint. Perhaps you could write up the introduction, Russ, since you have a clearer idea of the purpose of this d-d-a e-mail than I do. -- Sean Whitton signature.asc Description: PGP signature
Re: Proposal: move forward to Sphinx
On Sun, Jun 25, 2017 at 11:40:00AM +0900, Hideki Yamane wrote: > Yes, exactly what Russ says, converting to DocBook could make it > happen. So, it doesn't mean any waste of time and effort, DocBook > format is **necessary** for next step. Ah, I see what you mean. That's great. It is especially encouraging that the kernel already went through exactly this transition. -- Sean Whitton signature.asc Description: PGP signature
Re: Broken Link in Policy HTML Page
Hello Paul, Russ, On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote: > We should probably open a bug for this since it's not entirely obvious > what to do here. I can think of three options: > > * Ask debian-www to publish the HTML version of that file as well. > * Change the link to point to the wiki version of the file. > * Convert the process doc to DocBook so that we can make it an appendix. > > I'm kind of leaning towards the last, honestly. Agreed. It should be easy enough to convert back and forth with pandoc, and it's much better to have this in our git repo than on the wiki. An appendix is also significantly easier for people to find. -- Sean Whitton signature.asc Description: PGP signature
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote: > > One rarer case is missing here: > > > 1.2.3-4~deb9u1 > > Everything in 1.2.3-4 from unstable was in fact needed in Debian > > 9, so it was simply rebuilt for Debian 9 and uploaded there > > (prominent examples: firefox-esr, intel-microcode) > > Is this widespread enough to be worth describing? It's kind of hard to > describe. I for one had assumed that there was no difference between -deb9u1 and ~deb9u1, so I'd like to see it documented. -- Sean Whitton signature.asc Description: PGP signature
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote: > Concerns, objections, seconds? Thank you for working on this. > +A native package is software written specifically for Debian > +whose canonical distribution format is as a Debian package. > +Native packages have no separate upstream source in their > +source package representation and no separate Debian > +revision in their version numbers. Native packages are an > +exception: most Debian packages are "non-native" and have > +source packages composed of an upstream software release and > +separate Debian-specific modifications. Native packages are also used for software that is intended for use beyond Debian, but where the upstream maintainer also maintains the Debian package. In such cases, the Debian revision and orig tarballs represent needless overhead (tweaks to the packaging can use an increment to the minor version number, or similar). Some people frown upon this practice, but there are more than one of us that do it, so probably worth mentioning in policy as a secondary use of native packages (possibly a footnote, due to lack of consensus? There is certainly not a consensus that it's terrible). -- Sean Whitton signature.asc Description: PGP signature
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Sat, Jul 01, 2017 at 04:46:21PM +0100, Adam D. Barratt wrote: > fwiw, I can't think of situations where -deb9u1 would ever be used. > Either a selected set of changes were applied to the package in stable, > which would be +debXuY, or a newer upload was backported in its > entirety, which would be ~debXuY as above. Sorry, I meant s/-deb9u1/+deb9u1/. -- Sean Whitton signature.asc Description: PGP signature
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Hello Russ, On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote: > I thought there actually was a consensus that it's terrible. I certainly > think it's not good practice. I would recommend against anyone doing > this, speaking as someone who maintains lots of upstream software that I > also package for Debian, and therefore would rather not document it in > Policy, unless we're going to say not to do it. Thank you for your response. I trust your judgement about this consensus. So I withdraw my comments regarding your patch. So as not to let this bug get off-topic, I'll send you some other comments about using native packages privately. -- Sean Whitton signature.asc Description: PGP signature
Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems
control: user debian-pol...@packages.debian.org control: usertag -1 +discussion Hello Bastien, On Sun, Jan 01, 2017 at 01:37:25PM +0100, Bastien ROUCARIÈS wrote: > Following #849830 and generally source-is-missing lintian problems > could you document in 4.9 Main building script: debian/rules that > clean target must no be used for removing dfsg problem but the right > tools is repack I don't think that it should be a point of Policy that the rules clean target is not to be used for this purpose, because it is entailed by the ftp-master's interpretation of DFSG plus this sentence that we already have in Policy: Every [source or binary] package in main must comply with the DFSG (Debian Free Software Guidelines). However, as you say, we should document this to prevent others from tripping over it. As you suggest, such a note would need to refer to repacking the tarball. The Developer's Reference already contains a discussion of repacking upstream tarballs, so perhaps this should go there? Or we could use a footnote to Policy. I attach a patch doing that. -- Sean Whitton From 56fab75d2c803ae9afd8d2186613713b297f9138 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Sun, 2 Jul 2017 10:10:20 +0100 Subject: [PATCH] add a footnote about the clean target and DFSG repacking --- policy.xml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/policy.xml b/policy.xml index 782bd88..303688b 100644 --- a/policy.xml +++ b/policy.xml @@ -2170,6 +2170,16 @@ build has been invoked as root (since build may create directories, for example). + + + The clean target should not be used to remove files + in the source tree that are not compatible with the + DFSG. This is because the files would remain in the + upstream tarball, and thus in the source package, so + the source package would continue to violate DFSG. + Instead, the upstream source should be repacked. + + -- 2.11.0 signature.asc Description: PGP signature
Bug#849853: [debian-policy] Document source-is-missing lintian kind of problems
Hello Bastien, On Sun, Jan 01, 2017 at 01:45:34PM +0100, Bastien ROUCARIÈS wrote: > I get some problems when reporting bug detected by source-is-missing > tag in lintian. > > The main problems are: > * minified javascript is source > * I remove it using rules > * It is not a problems because not included in the binary forms > > [...] > > I believe we should offer on policy pointer to ftp master reject faq > and some description of common problems. Policy currently defers to the DFSG for a definition of what counts as free software for Debian's purposes. Thanks to the DPL's delegation of the ftp-masters, Policy defers to the DFSG plus the ftp-masters jointly. If we included text in Policy about common ways in which a package could fail to satisfy DFSG, Policy would effectively cease to defer to the ftp-masters. I don't think that Policy has the authority to do that, and I don't think it would be desirable. A footnote with a link to the REJECT-FAQ sounds useful. Here's a patch. > Maybe it belong to devref. Perhaps that should be a separate bug, if we're going to use this one to discuss adding a footnote with a link to the REJECT-FAQ. -- Sean Whitton From 61b4453023dcc844e2a49966eea6ea8a1eea725b Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Sun, 2 Jul 2017 10:52:58 +0100 Subject: [PATCH] add a footnote linking to the REJECT-FAQ --- policy.xml | 8 1 file changed, 8 insertions(+) diff --git a/policy.xml b/policy.xml index 782bd88..e0010ab 100644 --- a/policy.xml +++ b/policy.xml @@ -580,6 +580,14 @@ Every package in main must comply with the DFSG (Debian Free Software Guidelines). + + + Debian's FTP Masters publish a https://ftp-master.debian.org/REJECT-FAQ.html";>REJECT-FAQ + which details the project's current working + interpretation of the DFSG. + + In addition, the packages in main -- 2.11.0 signature.asc Description: PGP signature
Bug#866192: Broken Link in Policy HTML Page
control: tag -1 +patch On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote: > * Ask debian-www to publish the HTML version of that file as well. > * Change the link to point to the wiki version of the file. > * Convert the process doc to DocBook so that we can make it an appendix. > > I'm kind of leaning towards the last, honestly. I've taken a stab at this, in branch bug866192-spwhitton of debian-policy.git repo. Reviews very welcome. -- Sean Whitton signature.asc Description: PGP signature
Re: RFC: draft text for Policy sprint at DebCamp
Hello, On Sun, Jul 02, 2017 at 02:23:57PM -0700, Russ Allbery wrote: > Sean Whitton writes: > > I've created Teams/Policy/bits on gobby.debian.org to draft this. I've > > written some text about the sprint. Perhaps you could write up the > > introduction, Russ, since you have a clearer idea of the purpose of this > > d-d-a e-mail than I do. > > I made a few tweaks and added a note about 4.0.0 to the introduction, but > it otherwise looked great to me. Thanks for drafting this! Thank you for your review. Last call for others to check -- I'll send it out tomorrow. -- Sean Whitton signature.asc Description: PGP signature
Bug#866192: Broken Link in Policy HTML Page
control: tag -1 +pending On Sun, Jul 02, 2017 at 02:02:20PM -0700, Russ Allbery wrote: > Sean Whitton writes: > > > I've taken a stab at this, in branch bug866192-spwhitton of > > debian-policy.git repo. Reviews very welcome. > > This looks good to me. Thanks! Merged to master. Thanks for the review. -- Sean Whitton signature.asc Description: PGP signature
Bug#849853: [debian-policy] Document source-is-missing lintian kind of problems
control: tag -1 +pending On Sun, Jul 02, 2017 at 02:42:09PM -0700, Russ Allbery wrote: > As much as I don't like footnotes, this does seem like a good use of one. > I second your patch (not that I really need to since it's informative). > Seems like a good thing to merge. Given that this is indeed not normative, nor even a change to the text of Policy, I've applied my patch. I've also marked the change as closing this bug, but if Bastian feels that adding the footnote does not fully address the concerns he had when filing this bug, he should feel quite welcome to re-open it. -- Sean Whitton signature.asc Description: PGP signature
Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems
control: tag -1 +pending On Sun, Jul 02, 2017 at 02:40:06PM -0700, Russ Allbery wrote: > Well, if it's a common-enough error, I think there's no problem with also > mentioning this in the section on the clean rule. It's not likely that > this interpretation is going to change. Okay. > I'm on a war against footnotes in Policy because I think they make it much > harder to read (particularly in text form, particularly with DocBook which > now moves all the footnotes to the end of the chapter). I'd love to move > them all to either inline text or sidebars of some kind, although that's > going to be a long effort. > > s/should not/cannot/ (to get away from using standards language here and > because this isn't a Policy statement so much as a statement of > capability), and I would say "repacked to remove those files" in the last > sentence, but otherwise this looks good to me and could just be included > directly in that section on clean, I think. I don't have an informed opinion on footnotes, but thinking again, this change would be fine inline with the s/should not/cannot/ change. Since this is informative rather than normative, I've gone ahead and applied the change. Thank you for your review. -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: debian-policy: don't require Uploaders
On Fri, Jul 08, 2016 at 05:36:22PM +0200, Christian Hofstaedtler wrote: > I also want to see this. It makes lots of sense, especially for > teams maintaining very large numbers of packages. Honestly, the > individual package does not carry heavy weight in some of those > teams. At the same time, many packages carry old Uploaders, > including names of people that have long been known to be MIA, and > are kept there only to avoid setting an empty Uploaders field. Let me add the experience of the Debian Haskell Group. We have a wrapper around debchange(1) which allows us to do team uploads without having "Team upload." be the first line of the changelog. We select new upstream versions based on snapshots compiled by an outside group.[1] We upgrade tens of packages to new upstream releases at a time, and upload them all together (for some time, Clint Adams has done these mass uploads). For us, having some random names in the Uploaders: field can do nothing other than confuse newcomers to the team. I suspect that we cannot get consensus on this bug. Many people share Iain's sentiment, but the issue continues to arise in many contributor's Debian work. So it might be advisable to refer to tech-ctte. Before doing that, at the risk of achieving nothing, I'd like to suggest another wording: ... if the Maintainer control field names a group of people and a shared email address, the Uploaders field must be present and must contain at least one human with their personal email address. An exception is made for packaging teams which state clearly on their homepage, documentation or team policy that all packages are taken care of by every team member collectively. Possibly too bureaucratic, but might allay some of the concerns that Tobi raised: barely-established teams aren't likely to have a team homepage/documentation/policy document. [1] https://www.stackage.org/ -- Sean Whitton signature.asc Description: PGP signature
Bug#678607: debian-policy: "original authors" in 12.5 is unclear
I would like to see this bug fixed because there can be no doubt that
the 'original' in "original authors" is ambiguous.
On Wed, Jun 27, 2012 at 07:50:41PM -0500, Jonathan Nieder wrote:
> Here's a strawman illustrating what I think the sentence meant to say.
> [...]
I'm not sure why Jonathan thinks his patch is a strawman. It addresses
the main issue of this bug. I don't think the explanation of what an
upstream contact is needs to be relegated to a footnote. So I am
seeking seconds for the following patch, which uses Jonathan's wording:
diff --git a/policy.xml b/policy.xml
index ce5960b..725a951 100644
--- a/policy.xml
+++ b/policy.xml
@@ -11777,8 +11777,12 @@ END-INFO-DIR-ENTRY
In addition, the copyright file must say where the upstream
-sources (if any) were obtained, and should name the original
-authors.
+sources (if any) were obtained, and should include a name or
+contact address for the upstream authors. This can be the
+name of an individual or an organization, an email address, a
+web forum or bugtracker, or any other means to unambiguously
+identify who to contact to participate in the development of
+the upstream source code.
Packages in the contrib or
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#798476: debian-policy: don't require Uploaders
Hello Bill, On Sat, Jul 15, 2017 at 02:48:36PM +0200, Bill Allombert wrote: > The problem is that the majority of such documentation is outdated and > obsolete to the point of being useless. > Most team start big and then slowly falter until they are reduced to > a single member (because it is easy to distribute work but hard to > distribute responsibility). > > So yes at any time they are a number of active, hard-working team, but there > also a larger number of phantom team that used to be active, but whose > packages are still maintained in Debian. It is important they carry some > valid information about the effective maintainers. The problem is that the information in Uploaders is no more likely to be up-to-date than the team homepage/policy/docs. And it's positively misleading to have some names in Uploaders who haven't worked on the package in ages. So I don't see how my proposal introduces any new problems; it's an improvement because it removes a source of confusion. -- Sean Whitton signature.asc Description: PGP signature
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Hello Paul, On Sun, Jul 16, 2017 at 02:56:24AM -0700, Paul Hardy wrote: > Then would you consider it acceptable to make some mention in a > footnote to the effect that with the latest "dh" build tools, it isn't > necessary to have postinst and postrm scripts in the debian directory > for this purpose? Because otherwise, someone who did not already know > about this could misunderstand the implications of this requirement > and create redundant postinst and postrm scripts. The problem is that if we think there should be footnotes explaining that there is a dh_* tool that takes care of the requirement, we would then need new footnotes to almost every section of Policy. That would be a bad idea. -- Sean Whitton signature.asc Description: PGP signature
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
On Sun, Jul 16, 2017 at 12:21:40PM +0500, Andrey Rahmatullin wrote: > No, the policy doesn't talk about dh_* and other helpers (except in > footnotes). Right. In a sense, Policy is the reference against which such helpers are developed. -- Sean Whitton signature.asc Description: PGP signature
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Hello Paul, On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote: > My intention was to point someone new to packaging fonts in Debian in > the direction of an easy path, rather than leaving it up to that > person to find things out the hard way--or worse yet, doing things the > hard way. Right. It would be good to have that somewhere ... > How about a footnote pointing to > https://wiki.debian.org/Fonts/PackagingPolicy? That document is not > formal policy, but it would make life easier for someone if they are > new to packaging fonts. > > Alternatively, do you think this bug report should get reassigned to > the New Maintainer's Guide and be addressed as a request there? The > scope of that guide is mainly to walk someone through creating a > simple binary package. ... and the new maintainer's guide seems like a decent place. How about adding a section to that guide listing links to packaging guides for specific types of packages, such as fonts? -- Sean Whitton signature.asc Description: PGP signature
Bug#868497: debian-policy: Signed .dsc Files
Hello Paul, On Sun, Jul 16, 2017 at 04:36:55PM -0700, Paul Hardy wrote: > I was wondering if a maintainer signed a .dsc file in a package that > was uploaded (and hence signed) by a sponsor, that the FTP server > would reject the .dsc file for having an invalid signature. The sponsor would probably unpack and then rebuild the source package for the upload. If they didn't, and directly signed the .dsc using debsign(1), it would strip the sponsee's signature, and then sign both the .dsc and the .changes. So I believe the problem case could not arise. > Could the wording be changed to "...possibly surrounded by the > maintainer's PGP signature"? The term "maintainer" is implicitly > defined in the Policy Manual through repeated mention. This wouldn't be sufficient because those without upload rights can be sponsored to perform non-maintainer uploads. > Of course, out of context of this request someone might think "of > course the maintainer would sign the .dsc file--who else would do > that?" Well, again, it could be someone other than the maintainer, perfomring an NMU. -- Sean Whitton signature.asc Description: PGP signature
Moving DebCamp sprint forward one day
Hello all, I've moved the DebCamp sprint forward one day, to 1st August. The thought is that discussion can begin on that day, people can ask process questions, and then those discussions and patches can be worked on for the rest of the week. https://wiki.debian.org/Sprints/2017/DebianPolicy -- Sean Whitton signature.asc Description: PGP signature
Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field
Hello, On Fri, May 22, 2015 at 01:34:42PM +0900, Charles Plessy wrote: > Experiments on new fields are welcome, and it is good to open bugs to track > them. But I think that we should first see how the proposed field gets > traction before adding it to the specification. codesearch.debian.net suggests that this field is now used in quite a few packages. It seems reasonable to add a description of its use to the copyright format. I have some questions about Ben's patch: 1) the patch needs to be rebased against current policy 2) Is there a missing "License-Grant:" here: > Files: debian/patches/fancy-feature > Copyright: 2010 Daniela Debianizer > +This program is free software: you can redistribute it and/or modify > +it under the terms of the GNU General Public License as published by > +the Free Software Foundation, either version 3 of the License, or > +(at your option) any later version. > License: GPL-3+ -- Sean Whitton signature.asc Description: PGP signature
Bug#485776: debian-policy: Adding graphical flowcharts for maintainer scripts invocation would help understand the process
control: retitle -1 Incorporate maintscript flowcharts from Debian Women, or similar Here is an updated URI to the Debian Women flowcharts: https://wiki.debian.org/MaintainerScripts On Fri, Jun 27, 2008 at 07:47:21PM +0100, Ian Jackson wrote: > OK, I'll get out xfig, which is my personal least un-favourite :-). Do you still have some interest in this, Ian? Or anyone else? We are hoping to migrate Policy to rST built by Sphinx. Maybe there is a flowchart tool that integrates particularly well with Sphinx. CCing Hideki in case he knows. -- Sean Whitton signature.asc Description: PGP signature
FYI: "Wording:" changelog convention
Hello, README.md says that "Wording:" is for the author of a change. However, I believe that the intention of the field is not to give credit to the author of a patch, but to indicate who sought seconds for the patch. So I've replaced "author" with "proposer" in README.md. Please let me know if I've misunderstood "Wording:"'s purpose. -- Sean Whitton signature.asc Description: PGP signature
Re: FYI: "Wording:" changelog convention
On Tue, Aug 01, 2017 at 10:18:24AM -0700, Russ Allbery wrote: > I usually try to credit the person who wrote the bulk of the wording, even > if someone else asked for seconds. I think of it as more of a credit > thing than a process thing. Since Bill agrees, I've reverted my change. > Hope the sprint is going well! I should be on IRC to join in starting > sometime tomorrow. Looking forward to that. -- Sean Whitton signature.asc Description: PGP signature
Bug#485776: debian-policy: Adding graphical flowcharts for maintainer scripts invocation would help understand the process
On Tue, Aug 01, 2017 at 04:55:33PM +0100, Ian Jackson wrote: > We should surely import the diagrams as-is. Russ -- you were the one that suggested generating them. What do you think about importing them as-is now? -- Sean Whitton signature.asc Description: PGP signature
Bug#758124: Seconded, and non-normative updates
Hello, I second Charles' patch. I'll note that as a policy delegate I'll make the following purely informative changes to the patch once committed: - don't qualify with dpkg version number since it is older than the version in oldstable - move the text out of tags since we're trying to reduce the number of footnotes in Policy. -- Sean Whitton signature.asc Description: PGP signature
Bug#758124: Seconded, and non-normative updates
control: tag -1 +pending On Tue, Aug 01, 2017 at 11:18:56PM +0200, Bill Allombert wrote: > Please always quote what you are seconding. This avoid confusion. Thanks for the tip, Bill. -- Sean Whitton signature.asc Description: PGP signature
Bug#822430: debian-policy: Please update 8.1.1 to use the "ldconfig" trigger instead
Hello Niels, On Sun, Apr 24, 2016 at 01:14:49PM +0200, Niels Thykier wrote: > Possible wording could be: > > """ > Any package installing shared libraries in one of the default library > directories of the dynamic linker (which are currently /usr/lib and > /lib) or a directory that is listed in /etc/ld.so.conf[60] must use > ldconfig to update the shared library system. > > Any such package must have an "activate-noawait ldconfig" line in > their "triggers" control file. > """ > (replacing the entire section). > > Alternative wordings welcome; I am not entirely certain the one above > is all that well. I think this wording is fine. Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#850157: Please deprecate all ad-hoc patch systems
On Thu, Jan 05, 2017 at 03:22:44PM +1100, Stuart Prescott wrote: > [ various comments on Ian's proposal ] Ian, do you have an updated proposal in response to Stuart's points? > * Deprecating patch systems should also deprecate the 'patch' target > in debian/rules from §4.9. Thanks for noting this. > * There are still other useful roles for d/README.source documented > within policy and in associated documents; the python modules team > refer to README.source as the place to document that a package is not > using their standardised tool (git-dpm) and why, for instance. Agreed, but we probably don't need to list all those roles in policy. -- Sean Whitton signature.asc Description: PGP signature
Bug#758124: Documenting the Testsuite field in the Policy.
Hello Guillem, On Wed, Aug 02, 2017 at 12:54:15AM +0200, Guillem Jover wrote: > Except for the last dpkg which should probably be dpkg-source, I do > like this version better. > > Also perhaps worth mentioning that dpkg-source will remove the value > if there is no debian/tests/control file (and emit a warning). Sorry, I didn't see your message before I applied the older patch that was seconded. In the interests of getting Testsuite: documented, and since the amendments are addendums to the description, rather than changes, I think it would be best not to revert the change. Could you prepare a patch for the versoin you like that applies cleanly against the current git HEAD,[1] and seek seconds for it, please? If policy is released before you can do that, we can just clone the bug or similar. [1] https://anonscm.debian.org/git/dbnpolicy/policy.git -- Sean Whitton signature.asc Description: PGP signature
Bug#485776: Your maintscript flowcharts
Dear Marga, On the wiki[1] you say that your maintainer script diagrams are "GPL". Does this mean GPL-2+, GPL_3+, or something else? I'm planning to include this diagrams in the Debian Policy manual directly. Thanks. [1] https://wiki.debian.org/MaintainerScripts -- Sean Whitton signature.asc Description: PGP signature
Bug#589671: Required package set can be fully usable
control: tag -1 +pending On Mon, Jul 19, 2010 at 11:05:39PM +0200, Thijs Kinkhorst wrote: > How about just simplifying it to the following, without making any > suggestions about its further usability. Describe in a factual way > what it is, and leaves it to the reader to decide on whether they > think this is usable. > > "Systems with only the required packages installed have at least > enough functionality for the sysadmin to boot the system and install > more software." I've applied this change. Thank you for the wording, Thijs. My own view is that the previous wording was almost self-contradictory: it says the system is probably unusable, but can be /used/ to install further packages. -- Sean Whitton signature.asc Description: PGP signature
Bug#835451: debian-policy: Building as root should be discouraged
control: tag -1 +patch Hello Santiago, On Thu, Aug 25, 2016 at 09:41:26PM +0200, Santiago Vila wrote: > We should better avoid building packages as root (including fakeroot). > > Otherwise we will find nasty surprises like the libtool Bug #806654, > where a badly written debian/rules made the whole build to be done as > root, including the tests, which in turn made the build to fail. > > My proposal to fix this would be to remove the quoted paragraph > entirely. The next paragraph says: The build target must not do anything that might require root privilege. I think that we could respond to your concern with the following patch, which I believe reflects current project consensus, and thus for which I am seeking seconds: diff --git a/policy.xml b/policy.xml index 3daa532..829cda4 100644 --- a/policy.xml +++ b/policy.xml @@ -2059,8 +2059,11 @@ possible ways and make the binary package out of each. - The build target must not do anything - that might require root privilege. + The build target, and targets like + build-a and + build-b used per the previous + paragraph, must not do anything that might require root + privilege. The build target may need to run the -- Sean Whitton signature.asc Description: PGP signature
Bug#809637: debian/copyright checks fail on upstream filenames containing blanks
On Sat, Jan 02, 2016 at 10:49:04AM +, Mike Gabriel wrote: > At the moment, we are not able to exactly specify file paths of > files/folders containing blanks in debian/copyright when complying with the > DEP-5 specs. (I agree that it is indeed uncommon as a developer to use > blanks in filenames and that it should be avoided by upstream devs). > > Suggestions to solve this: > > (a) allow escaping of blanks somehow (e.g., "\ ") > (b) allow quotes for filenames or such This should be fixed. Our machine-readable copyright format should not be causing us to file bugs to upstream saying "could you rename this file that our Debian build process doesn't even use, please?" (e.g.) Would it be possible to permit Files: to be a line-based list? Then there could be one glob per line, and I think they could contain spaces. This avoids introducing new syntax. -- Sean Whitton signature.asc Description: PGP signature
Bug#835451: debian-policy: Building as root should be discouraged
control: tag -1 -patch Hello again Santiago, Some of us here at DebCamp have been reading your message and we're still not sure of your intention. On Thu, Aug 25, 2016 at 09:41:26PM +0200, Santiago Vila wrote: > Debian Policy 4.9 says: > > For some packages, notably ones where the same source tree is compiled > in different ways to produce two binary packages, the build target > does not make much sense. For these packages it is good enough to > provide two (or more) targets (build-a and build-b or whatever) for > each of the ways of building the package, and a build target that does > nothing. The binary target will have to build the package in each of > the possible ways and make the binary package out of each. > > Actually, no, I don't think that's "good enough". > > We should better avoid building packages as root (including fakeroot). We already have in policy both: (i) The build target must not do anything that might require root privilege. (iI) The binary targets must be invoked as root [or fakeroot]. However, in the paragraph you quoted, there is a loophole: if the build-a and build-b targets are not invoked by the build target, instead directly invoked by the binary target, then (i) does not apply, and indeed (ii) applies and they will be invoked as root. Is that why you want to delete that paragraph? -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Returning to the requirement that Uploaders: contain humans
Hello,
Here is an updated diff for this bug, against the docbook version of
the policy manual.
I've also included a purely informative change which emphasises that
packages that are team maintained in name only should be orphaned
properly, with their maintainer field set to the QA team. This is
already current best practice, but it's worth emphasising, because one
might fail to orphan a package on the grounds that "someone else on the
team might fix it", which is not true of a lot of teams.
This purely informative change came out of a discussion at DebCamp with
h01ger, gregoa and David Bremner. We are CCing -devel because we want
to determine if there remains, in 2017, a consensus that we should not
drop this requirement. We think that recent objections in the bug are
about implementation details, rather than a concern to retain humans in
the uploaders field.
diff --git a/policy.xml b/policy.xml
index 3daa532..4731507 100644
--- a/policy.xml
+++ b/policy.xml
@@ -1128,13 +1128,6 @@
described in .
-If the maintainer of the package is a team of people with a shared
-email address, the Uploaders control field must
-be present and must contain at least one human with their personal
-email address. See for the syntax
-of that field.
-
-
An orphaned package is one with no current maintainer. Orphaned
packages should have their Maintainer control
field set to Debian QA Group
@@ -1149,6 +1142,12 @@
+
+This includes packages with a group of people or team in the
+Maintainer control field. They should be
+orphaned if the team is not actively maintaining the package.
+
+
@@ -3448,13 +3447,6 @@ endif
Maintainer field, and multiple entries must be comma separated.
- This is normally an optional field, but if the
- Maintainer control field names a group of
- people and a shared email address, the
- Uploaders field must be present and must
- contain at least one human with their personal email address.
-
-
The Uploaders field in debian/control can
be folded.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#835520: Seconding nine patches & seeking seconds for two more
Hello, I second all of Andreas' patches except the 5th and 8th. I've attached the diff to which my second applies. The 5th and 8th patches introduce a normative requirement to use debhelper. This is a first for policy, which up to now only comments that using debhelper is "easiest". I've spoken to h01ger and gregoa IRL and they say that they missed the magic word "should" which is what makes debhelper required by these patches. So I'm seeking seconds for the following replacement for Andreas' 5th and 8th patches: diff --git a/policy.xml b/policy.xml index 3daa532..c6c7412 100644 --- a/policy.xml +++ b/policy.xml @@ -8525,6 +8525,14 @@ fi update-rc.d, please consult its man page update-rc.d8. + +It is easiest for packages not to call +update-rc.d directly, but instead use +debhelper programs that add the required +update-rc.d calls automatically. See +dh_installinit, +dh_systemd_enable, etc. + @@ -8573,6 +8581,14 @@ invoke-rc.d package action invoke-rc.d, please consult its man page invoke-rc.d8. + +It is easiest for packages not to call +invoke-rc.d directly, but instead use +debhelper programs that add the required +invoke-rc.d calls automatically. See +dh_installinit, +dh_systemd_start, etc. + -- Sean Whitton diff --git a/policy.sgml b/policy.sgml index 9cd182b..2b37df8 100644 --- a/policy.sgml +++ b/policy.sgml @@ -7053,12 +7053,6 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) in /run should be stored on a temporary file system. - - Packages must not assume the /run - directory exists or is usable without a dependency - on initscripts (>= 2.88dsf-13.3) until the - stable release of Debian supports /run. - @@ -7654,7 +7648,7 @@ test -f program-executed-later-in-script || exit 0 - Interfacing with the initscript system + Interfacing with init systems Maintainers should use the abstraction layer provided by @@ -7697,19 +7691,6 @@ test -f program-executed-later-in-script || exit 0 - By default update-rc.d will start services in - each of the multi-user state runlevels (2, 3, 4, and 5) - and stop them in the halt runlevel (0), the single-user - runlevel (1) and the reboot runlevel (6). The system - administrator will have the opportunity to customize - runlevels by simply adding, moving, or removing the - symbolic links in /etc/rcn.d if - symbolic links are being used, or by modifying - /etc/runlevel.conf if the file-rc method - is being used. - - - To get the default behavior for your package, put in your postinst script @@ -7727,15 +7708,6 @@ test -f program-executed-later-in-script || exit 0 - This will use a default sequence number of 20. If it does - not matter when or in which order the init.d - script is run, use this default. If it does, then you - should talk to the maintainer of the sysvinit - package or post to debian-devel, and they will - help you choose a number. - - - For more information about using update-rc.d, please consult its man page . @@ -7756,8 +7728,8 @@ test -f program-executed-later-in-script || exit 0 The package maintainer scripts must use invoke-rc.d to invoke the - /etc/init.d/* initscripts, instead of - calling them directly. + /etc/init.d/* initscripts or equivalent, + instead of calling them directly. @@ -7769,17 +7741,11 @@ test -f program-executed-later-in-script || exit 0 - Most packages will simply need to change: - /etc/init.d/<package> - <action> in their postinst - and prerm scripts to: + Most packages will simply use: - if which invoke-rc.d >/dev/null 2>&1; then invoke-rc.d package <action> - else - /etc/init.d/package <action> - fi + in their postinst and prerm scripts. @@ -7798,226 +7764,19 @@ test -f program-executed-later-in-script || exit 0 - Boot-time initialization - - -There used to be another directory, /etc/rc.boot, -which contained scripts which were run once per machine -boot. This has been deprecated in favour of links from -/etc/rcS.d to files in /etc/init.d as -described in . Packages must not -place files in /etc/rc.boot. - - - - Example An example on which you can base your /etc/init.d scripts is found in /etc
Bug#809637: debian/copyright checks fail on upstream filenames containing blanks
Hello Russ, On Wed, Aug 02, 2017 at 11:54:52AM -0700, Russ Allbery wrote: > I like solution (a), honestly. I think we could just add backslash as an > escape character that escapes anything other than a newline and have the > problem basically go away. It would require a new version of the spec, > though, since it's not backward compatible (although I doubt many files > contained literal backslashes). Okay. > Line-based lists is much less backward-compatible, since we break > every debian/copyright file that uses space-separated lists, which is > much more common than having whitespace in filenames. My suggestion was that the Files: field could be /either/ a line-based list or a space-separated list -- is there something that would break? -- Sean Whitton signature.asc Description: PGP signature
Bug#839172: TC decision regarding #741573 menu policy not reflected yet
control: tag -1 +patch Hello tech-ctte, On Thu, Aug 03, 2017 at 08:53:09AM +0200, Didier 'OdyX' Raboud wrote: > So yes, point 2 corresponds to your: > > - delete that paragraph > > - add a new paragraph saying "if there is a desktop file, there should > > be no menu file" > [...] > That said, now that thanks to new forces, the process seems vivid and strong > again, it does indeed make sense to reassign that to Policy. I'm hereby doing > this, marking the TC as "affected". We'd still be happy to help on the > wording, ideally during DebConf! Here is my proposed patch to policy. Since the TC has made a decision, it doesn't make sense to seek seconds for this change, in the usual way. So instead I'd like to see "seconds" from at least three TC members confirming that this patch is sufficient to close this bug: diff --git a/policy.xml b/policy.xml index 3daa532..934a85b 100644 --- a/policy.xml +++ b/policy.xml @@ -8990,14 +8990,8 @@ Reloading description configuration...done. receive extra contributions such as translations. -Packages can, to be compatible with Debian additions to some -window managers that do not support the FreeDesktop standard, also -provide a Debian menu file, following the -Debian menu policy, which can be found in the -menu-policy files in the -debian-policy package. It is also available -from the Debian web mirrors at https://www.debian.org/doc/packaging-manuals/menu-policy/";>https://www.debian.org/doc/packaging-manuals/menu-policy/. +If a package installs a FreeDesktop desktop entries, it must +not also install a Debian menu entry. -- Sean Whitton signature.asc Description: PGP signature
Bug#835451: debian-policy: Building as root should be discouraged
control: tag -1 +patch Hello Santiago, Mike, On Wed, Aug 02, 2017 at 07:15:28PM +0200, Santiago Vila wrote: > Yes, indeed! Great, I'm happy we figured that out. I believe that my previous patch does indeed answer the concern you've raised. So once again, I'm seeking seconds for that patch. On Wed, Aug 02, 2017 at 07:52:35PM +, Mike Gabriel wrote: > Then my suggestion (as discussed here in DebCamp) would be to rephrase that > paragraph rather then removing it entirely. > > What needs to be said is that if you have a package that builds the software > multiple times (e.g. once against gtk2, next against gtk3), you need to > define each of the build processes as build-a, build-b, etc. > > These build sub-targets need to be called from the build target and _must_ > _not_ be called from the binary target. This is a much bigger change than my proposal. In addition to the requirement that the build-a and build-b targets don't require root privs, it also requires that they be dependencies of the build target, or be invoked by that target. Since the permission to have an empty build target has been in policy for a long time, imposing this requirement would make a lot of packages buggy. Changes to policy are not meant to do this. By contrast, my patch reflects a consensus that we can be confident already exists. -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Returning to the requirement that Uploaders: contain humans
On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote: > Please be more thoughtful about the consequences of such changes to policy. > > This would not be "a purely informative change". > > Your suggested wording has the potential to create a HUGE amount of tensions. You're right. After sending my patch I realised that it contains the word "should", which is a magic word in policy, imposing a normative requirement. This was not intended. My intended meaning: it is already best practice that *other team members* should orphan a package if they know that no-one in the team is actively taking care of it *according to their judgement of 'actively'*. Would you agree that this is already established best practice? > And it does not even help with the problem Tobias raised: > > When a maintainer retires or is declared MIA by the MIA team according > to the MIA process, how can you *find* all teams and team-maintained > packages where this maintainer was the only or last active team member > when there is no Uploaders: field? I'll reply to this when replying to Tobias' remarks. -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Returning to the requirement that Uploaders: contain humans
Hello Tobias, Thank you for writing about this bug from the MIA team's perspective, which is very relevant to resolving this. On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote: > Some remarks / questions I do not see adressed: > - If you have not a name on some task human nature tends toward that nonone > feels responsible at all. Like the German (fun) expansion of TEAM: Toll, Ein > Anderer Machts (Great, someone else it taking care) In most teams, this happens anyway -- I would take this as an argument against team maintenance more generally. > - MANY team homepages are not updated or do not even exist. I think before > droping the requirement to have human uploaders this needs to be fixed by > policy and it must be RC(?) bug if the team homepage is > outdated/absent/inaccurate. The infomation about the teams *must* be in a way > that it can be easily found/parsed. > - There is currently no way to map a person to a team or to map a team to a > list of members -- if you need accurary. This is especially true for teams > that are smaller. - - When someon is going e.g MIA, we need to know which > teams are involved to trigger them. For teams on alioth, would you find the list of team members on the alioth project insufficient? I agree this doesn't help with teams that do not use alioth but are based around a mailing list. As Adrian said, it's not clear what an alternative to Uploaders would be for this purpose. But I'm not sure that Uploaders is much use, either, because in so many teams it's simply not kept up-to-date. > - Not in all teams it is working tha everyone is looking at every package. > During the lipng transistion I filed many bugs on team-managed packages which > were never answered Right, but having some random team members listed in Uploaders: doesn't help. > - We have already the problem about "partially MIA" -- people holding several > pacakgages but neglecting several of them. Currently we have no real measures > of taking care of the neglected one, MIA team wise. This will be amplified > when there is no human responsible person named. Could you explain further how this would amplify the problem? I agree that this is a serious problem, but I don't see how this change would amplify it. -- Sean Whitton signature.asc Description: PGP signature
Bug#839172: TC decision regarding #741573 menu policy not reflected yet
On Thu, Aug 03, 2017 at 05:51:27PM +0200, Philip Hands wrote: > You appear to have a singular/plural mismatch with: > > installs a FreeDesktop desktop entries > > I guess that should instead be: > > installs FreeDesktop desktop entries > > (or perhaps it should be singular throughout, I'm not sure) Ooops, I meant singular throughout. > P.S. Just in case this is an oversight, rather than an intentional > change: > > Shouldn't "desktop entry" and "Debian menu entry" be somehow > emphasised, to make it clear that there is a reference back to the > earlier definition? > > If you meant to get rid of that, no problem. Sorry, I'm not sure what you mean. Are you referring to the paragraph I deleted? -- Sean Whitton signature.asc Description: PGP signature
Bug#839172: TC decision regarding #741573 menu policy not reflected yet
On Thu, Aug 03, 2017 at 05:51:27PM +0200, Philip Hands wrote: > P.S. Just in case this is an oversight, rather than an intentional > change: > > Shouldn't "desktop entry" and "Debian menu entry" be somehow > emphasised, to make it clear that there is a reference back to the > earlier definition? > > If you meant to get rid of that, no problem. Ah, sorry, I see what you mean now. I think it makes sense to get rid of it: IME, when emphasis is used in defining a term, it is not repeated when the term is later used. Do I have your approval for the patch, with the plural/singular fixed? -- Sean Whitton signature.asc Description: PGP signature
Commits fixing #835520 delete some sections
Hello, I just pushed commits fixing #835520; I am currently working on the upgrading checklist entry. These commits entirely delete some sections. Do we need to update references, or is it okay to have the old numbers in section id fields, with docbook renumbering the sections in the output formats? Please let me know how this has been handled previously. -- Sean Whitton signature.asc Description: PGP signature
Bug#835520: Seconding nine patches & seeking seconds for two more
On Thu, Aug 03, 2017 at 10:31:43PM +0200, Andreas Henriksson wrote: > What I tried to do was to update the description to "current" *sysvinit* > standards. (Where "current" means several releases ago. Don't remember > when we made insserv/startpar non-optional in Debian but it was > definitely pre-jessie.) > While at it I also tried to make it more init system agnostic. > > In other words I tried to focus on what the (original) bug title was: > getting rid of the harmful parts. > > There was no focus on systemd really, but unfortunately it ended up > unavoidable to mention anyway. > > > It's absolutely not to be considered to be up to speed with systemd! > Debian policy IMHO needs alot of work still to catch up with the current > systemd best practises. I think another (or several) bug reports should > be opened if you really intend to undertake documenting (debians > interactions with) systemd. Agreed. After applying the patches I realised that there is plenty more work to be done, but I had lost track of exactly what your intention was. I've changed it to: "Make section 9 agnostic between Debian's init systems" Please feel free to improve on this, and thank you very much for your patches. -- Sean Whitton signature.asc Description: PGP signature
Bug#809637: debian/copyright checks fail on upstream filenames containing blanks
Hello Mike, On Thu, Aug 03, 2017 at 03:09:30PM +, Mike Gabriel wrote: > How would differentiate between a blank in a file name and a blank as a > separator? If you needed blanks in filenames, you'd use a line-based list. -- Sean Whitton signature.asc Description: PGP signature
Bug#835451: debian-policy: Building as root should be discouraged
On Thu, Aug 03, 2017 at 03:43:56PM +, Mike Gabriel wrote: > I am not saying that the build target must not be empty. I can be empty but > the build-a ... build-n dependecies have to be moved away from the binary > target and have to be made dependencies of the build target (which can only > have deps but no own instructions). > > And if that makes packages buggy, then they are actually quite buggy, > because the build-a ... build-n get executed in a fakeroot concept by design > of dpkg-buildpackage. And IMHO this should definitely be avoided. Just to be clear, I do agree with you that this situation where they are deps of the binary target is bad. Interested to hear what Santiago thinks. -- Sean Whitton signature.asc Description: PGP signature
Re: Commits fixing #835520 delete some sections
On Thu, Aug 03, 2017 at 03:38:47PM -0700, Russ Allbery wrote: > Previously, we've always kept tombstone sections that just say "this > section has been deleted" so that the sections aren't renumbered. > Otherwise, we have to update the section numbers in upgrading-checklist > (and possibly invalidate other external references). > > I'm not wedded to that as the best way of doing this; just not sure what > would be better. Thanks. Fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#839172: TC decision regarding #741573 menu policy not reflected yet
control: tag -1 +pending Hello Didier, On Fri, Aug 04, 2017 at 11:22:28AM +0200, Didier 'OdyX' Raboud wrote: > I now gathered some old memories and remembered that there was indeed a bug > about this that got stalled: #707851 (which was the TC bug). See from message > #475 (September 2015), where I tried to push a wording quite similar to yours > to Policy: > > > +Applications that are registred in the desktop menu shall not also > > +provide a Debian menu file for the same application. > [...] > So… I'm fine with your wording, but thought it'd be useful to point at the > previous discussion about this very subject. Thank you for digging this up! I have no desire to argue in favour of either your patch or mine, but since mine has been okayed by three TC members in this bug, in the interests of getting this bug closed, I've gone ahead and applied it. -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Extract recent uploaders from d/changelog
Package: tracker.debian.org Severity: wishlist On Thu, Aug 03 2017, Holger Levsen wrote: > Then, Tobias has a point, knowing which team members uploaded a package is > useful. So I have a simple proposal to achieve that: make tracker.d.o > show the last 10 uploaders for a given package (based on UDD), just like it > parses the Uploaders: field from the packages now. Such a feature would move this discussion forward, so I'm submitting it as a feature request. I think that the logic in who-uploads(1) is probably insufficient; parsing d/changelog would catch people actually /contributing/ to the package, not just those who signed the uploads. -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Returning to the requirement that Uploaders: contain humans
Hello, On Fri, Aug 04 2017, Adrian Bunk wrote: > Autogenerating Uploaders like GNOME does [1] would be an alternative > approach. > > [1] > https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/ I don't understand this suggestion. If it can be automatically generated, just generate it when you need it -- why store it in the source package? -- Sean Whitton signature.asc Description: PGP signature
Bug#798476: Bug#870788: Extract recent uploaders from d/changelog
Hello, On Sat, Aug 05 2017, Adrian Bunk wrote: > I assume you are thinking of parsing the [ name ] syntax used by many > teams. Yes. > Note that a prerequisite for such debian/changelog parsing would be > that policy sets strict syntax and semantics requirements. No, we do not need to block such a feature that would work for 90% of packages until we have a policy about the [ name ] syntax. It can begin as a useful heuristic. -- Sean Whitton signature.asc Description: PGP signature
Bug#299007: Transitioning perms of /usr/local
control: retitle -1 Transitioning perms of /usr/local Hello Santiago, The TC decision in #484841 is not yet reflected in Policy. We could close the bug by simply dropping the requirement that /usr/local be group-writeable by staff, but Russ says that you would like your transition plan to be documented in Policy. Is this still true? Would you be able to propose a patch against the Policy git repo as it currently stands? Thanks! -- Sean Whitton signature.asc Description: PGP signature
Re: Upstream Tarball Signature Files
Hello, On Mon, Aug 07 2017, Paul Hardy wrote: > The version of lintian now in testing, 2.5.52, introduces a new error > (not just a warning) for missing ".asc" signature files. The relevant > changelog entry is > > + Added: >... - orig-tarball-missing-upstream-signature > > A missing ".orig.tar.*.asc" file now produces a lintian error (not > just a warning). This is a known bug in the current version of Lintian. > Also, where signature files are desired, I think it would be > beneficial to also accept binary ".sig" files as an alternative to > ".asc" files, for example as produced with "gpg -b". > > This is especially beneficial if any requirement for a signature file > is a goal for upstream sources. As one example, GNU Project files on > the GNU FTP repository are uploaded with corresponding ".sig" files. > It would be redundant to also require ".asc" signature files for those > packages. > > It is possible to fake out lintian by taking a binary ".sig" file and > changing its extension to ".asc", but I think that is sub-optimal. > > Making changes to debian-policy (if deemed appropriate) to allow > upstream binary signature files would affect at least lintian, > dpkg-dev, uscan, and Debian maintainer guides. This sounds like a new policy bug to be filed :) -- Sean Whitton signature.asc Description: PGP signature
proofreading the rST conversion
Hello, Russ and I are working to convert Policy to rST in the rst-conversion branch. Please help us proofread chapters for conversion errors! Use gobby to claim a chapter you'll work on (Teams/Policy subdir). The sooner we finish the proofreading, the sooner we can start applying patches to policy again -- please avoid committing to master in the interim. -- Sean Whitton signature.asc Description: PGP signature
Bug#587279: Clarify restrictions on main to non-free dependencies
On Sun, Jun 25, 2017 at 02:43:36PM -0700, Russ Allbery wrote: > diff --git a/policy.xml b/policy.xml > index 7ba5fc0..daf4c3c 100644 > --- a/policy.xml > +++ b/policy.xml > @@ -595,7 +595,9 @@ >Build-Depends, >Build-Depends-Indep, or >Build-Depends-Arch relationship on a > - non-main package), > + non-main package) unless that package > + is only listed as a non-default alternative for a package in > + main, > > > Seconded. -- Sean Whitton signature.asc Description: PGP signature
rst conversion: multi-file or single file?
Hello, We have a choice between having all of policy in one file (single-file), or one file per chapter (multi-file). Single-file blocker: sphinx does not expect this, and thus chapter and section numbering is broken. Multi-file blocker: plain text output needs to be concatenated into one file, but doing this programatically requires some parsing of index.rst I think that the former blocker is much, much harder to solve -- we'd be swimming upstream. So I think we should just take a shot at writing the concatenation script. We can try to contact sphinx upstream but it might take some weeks. Any objections/alternatives? -- Sean Whitton signature.asc Description: PGP signature
Bug#567033: Merging
control: forcemerge 787816 -1 Hello, The latest version of the FHS does not have /usr/games, so merging this with the bug about updating our FHS version. -- Sean Whitton signature.asc Description: PGP signature
Bug#588085: Done in a recent release
Version: 4.0.1.0 We believe that this was fixed in the most recent release of Policy. -- Sean Whitton signature.asc Description: PGP signature
Re: rst conversion: multi-file or single file?
On Fri, Aug 11 2017, Hideki Yamane wrote: > On Thu, 10 Aug 2017 09:03:54 -0700 > Sean Whitton wrote: >> We can try to contact sphinx upstream but it might take some weeks. > > And it should be filed as issue if we want such feature to put it into > upstream > https://github.com/sphinx-doc/sphinx/issues Done: https://github.com/sphinx-doc/sphinx/issues/3994 In the meantime, we're going with the multi-file conversion and using a script to join the plain text files, which shouldn't be too awful to maintain the short-term. -- Sean Whitton signature.asc Description: PGP signature
Bug#218893: Done in a recent release
Hello,
On Fri, Aug 11 2017, Bill Allombert wrote:
> On Fri, Aug 11, 2017 at 07:53:51AM -0700, Sean Whitton wrote:
>> Version: 3.9.4.0
>>
>> We believe this was fixed in a recent release.
>
> What make you believe that ?
From the changelog:
* build-arch and build-indep are now mandatory targets in
* debian/rules,
implementing the Technical Committee ruling in #629385. Wording
review by Jonathan Nieder, Jakub Wilk, and Roger Leigh. (Closes:
#374029)
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#844431: Reproducibility in Policy
control: user debian-pol...@packages.debian.org control: usertag = normative proposal Hello, Proposal: This is what Holger and I think we should add to Policy, after readability tweaks: Packages should build reproducibly, which for purposes of this document means that given - a version of a source package unpacked at a given path; - a set of versions of installed build-dependencies; and - a build architecture, repeatedly building the source package on the architecture with those versions of the build dependencies installed will produce bit-for-bit identical binary packages. Explanation: The definition from the reproducible builds group[1] says: A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts. The relevant attributes of the build environment, the build instructions and the source code as well as the expected reproducible artifacts are defined by ... distributors. i.e. Debian has to define the build environment, source code and build instructions. I think that my wording defines these as Debian currently understands them. Later, we could narrow the definition of build environment by adding more constraints, but we're not there yet. [1] https://reproducible-builds.org/docs/definition/ -- Sean Whitton signature.asc Description: PGP signature
Bug#844431: Revised patch: seeking seconds
control: tag -1 +patch This patch incorporates the feedback given on the proposal I sent yesterday, both in this bug and in person from Russ and Holger (thank you to all). I am seeking formal seconds for this patch, from any DD. In particular: - for now, we only require reproducibility when the set of environment variable values set is exactly the same This is because - the reproducible builds team aren't yet totally clear on the variables that they think may be allowed to vary - we should wait until .buildinfo is properly documented in policy, and then we can refer to that file - we don't require reproducibility when build paths vary This is because - since there is not a consensus on whether we should require this, and there is strong consensus on the requirement of reproducibility if the path does /not/ vary, this issue should not block this change. We should open a separate bug against debian-policy diff --git a/policy/ch-source.rst b/policy/ch-source.rst index 127b125..cc4b020 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or build system (for example, a package that builds the same source multiple times to generate different binary packages). +Reproducibility +--- + +Packages should build reproducibly, which for the purposes of this +document [#]_ means that given + +- a version of a source package unpacked at a given path; +- a set of versions of installed build dependencies; +- a set of environment variable values; and +- a build architecture, + +repeatedly building the source package on any machine of the same +architecture with those versions of the build dependencies installed +and exactly those environment variable values set will produce +bit-for-bit identical binary packages. + .. [#] See the file ``upgrading-checklist`` for information about policy which has changed between different versions of this document. @@ -790,3 +806,7 @@ generate different binary packages). often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code. + +.. [#] + This is Debian's precisification of the `reproducible-builds.org + definition <https://reproducible-builds.org/docs/definition/>`_. -- Sean Whitton signature.asc Description: PGP signature
Bug#844431: Revised patch: seeking seconds
Hello, On Sat, Aug 12 2017, Russ Allbery wrote: > I suspect we want to say build and host architecture for right now. > (Maybe we can later aspire to making the build architecture not > matter.) On Sat, Aug 12 2017, Ximin Luo wrote: > To echo dkg and others' comments, it would be nice if we could add > here: > > +Packages are encouraged to produce bit-for-bit identical binary > packages even +if most environment variables and build paths are > varied. This is technically +more difficult at the time of writing, > but it is intended that this stricter +definition would replace the > above one, when appropriate in the future. Here is an updated patch addressing these. I reworded it to use 'recommended' and changed the tone to better suit policy. Thank you Ximin, Russ and Johannes! > "precisification" -> "more precise version" Our definition is not actually a /version/ of the reproducible-builds.org definition -- that would imply that our definition could replace the reproducible-builds.org definition, like upgrading a package. 'precisification' means roughly "filling out the missing specification when it is appropriate to fill it out", which is what the r-p.org definition instructs distributors to do. diff --git a/policy/ch-source.rst b/policy/ch-source.rst index 127b125..6e32870 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for example, a package that builds the same source multiple times to generate different binary packages). +Reproducibility +--- + +Packages should build reproducibly, which for the purposes of this +document [#]_ means that given + +- a version of a source package unpacked at a given path; +- a set of versions of installed build dependencies; +- a set of environment variable values; +- a build architecture; and +- a host architecture, + +repeatedly building the source package for the build architecture on +any machine of the host architecture with those versions of the build +dependencies installed and exactly those environment variable values +set will produce bit-for-bit identical binary packages. + +It is recommended that packages produce bit-for-bit identical binaries +even if most environment variables and build paths are varied. It is +intended for this stricter standard to replace the above when it is +easier for packages to meet it. + .. [#] See the file ``upgrading-checklist`` for information about policy which has changed between different versions of this document. @@ -790,3 +812,7 @@ generate different binary packages). often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code. + +.. [#] + This is Debian's precisification of the `reproducible-builds.org + definition <https://reproducible-builds.org/docs/definition/>`_. -- Sean Whitton signature.asc Description: PGP signature
Bug#844431: Revised patch: seeking seconds
On Sat, Aug 12 2017, Ximin Luo wrote: > Thanks! Seconded. Just to be clear, we are waiting on one more second for the version that refers to build and target architecture. -- Sean Whitton
Bug#844431: Revised patch: seeking seconds
Hello, On Tue, Aug 15 2017, Russ Allbery wrote: > Adrian Bunk writes: > >> Future policy versions might change this definition, but whatever >> latest policy states has to be the definition used by both packages >> and the reproducible builds team. > >> Another example is that a package that is reproducible according to >> the policy definition must not show up as non-reproducible in >> tracker/DDPO based on results from the reproducible infrastructure. > > This seems really inflexible and unnecessarily absolutist. I don't > agree with taking this approach. > > The point of adding this definition to Policy is that we're setting a > new minimum bar for packages in Debian to meet. Right. More generally, the only thing that this new section of policy constrains is the severities that may be used when filing bugs. This is how policy changes are meant to work -- they control bug severities against packages, not what appears on tracking web pages. -- Sean Whitton signature.asc Description: PGP signature
Bug#844431: Revised patch: seeking seconds
On Wed, Aug 16 2017, Adrian Bunk wrote: > This is about the reproducible builds team not using policy as a stick > for claiming a bar higher than what policy actually defines. > > Is it really allowed to claim that a package is not reproducible, > when it actually is reproducible according to policy? Yes, if your bug is of 'wishlist' severity. -- Sean Whitton signature.asc Description: PGP signature
Bug#872587: debian-policy: please document "Important: yes"
Hello Adam, Thank you for filing this bug. On Fri, Aug 18 2017, Adam Borowski wrote: > On the other hand, dpkg does not know the field. It won't say a word upon > removal, and dpkg-gencontrol silently removes it. > [...] > Thus, some Policy guidance would be nice. Is it legal to use "Important: > yes" at this moment? It wouldn't be up to policy whether it's legal. We document fields in policy once they are already in use in the archive. Do you have any idea how long we can expect to wait until dpkg supports the field? I would suggest that we wait until dpkg has defined behaviour for the field, as it will make documenting it much easier. It will also allow us to be more confident that there is no serious disagreement about the purpose of the field. I couldn't find a bug against dpkg, but if there is one, it should probably be set to block this bug. -- Sean Whitton signature.asc Description: PGP signature
FYI: updates to the policy changes process
Hello, I'm about to push two changes to the process: 1. deprecate the 'issue' usertag Russ and I don't think this tag was giving us much value, and applying or removing it was busywork. In particular, it is usually very clear whether an issue is a policy matter, so bugs can be simply closed, or moved to the 'discussion' phase. In the rare case that it's not clear whether the bug is a policy matter, it can remain unclassified. 2. add usage of the 'moreinfo' tag Quoting from the process document: The Policy delegates are unable to determine whether the bug is really a Policy matter, or judge that there are missing details that would prevent a fruitful discussion (and may result in a confused and unhelpful discussion). Policy delegates ask the original submitter to provide the missing details. Others are asked to refrain from discussing whatever they take the issue to be, limiting their postings to attempts to supply the missing details. What needs to happen next: Submitter (or someone else) provides the requested information within 30 days, or the bug is closed. The majority of bugs will skip this stage. -- Sean Whitton signature.asc Description: PGP signature
FYI: tools/policy-bug-report enhancements
Hello, I've enhanced Russ's tools/policy-bug-report script to display - bugs that need someone to write a patch - bugs that need seconds - bugs tagged 'pending' This is in response to Solveig's suggestion at our BoF to post progress updates to a blog that's syndicated to Planet Debian. So indeed, I'll be posting the output of this script to my blog shortly. -- Sean Whitton signature.asc Description: PGP signature
Bug#872665: lintian: tag metadata tracking releases of Debian Policy
Package: lintian Version: 2.5.52 Severity: wishlist Dear maintainers, At the Debian Policy BoF at DebConf17, it was suggested that Lintian start tracking metadata that connects up Lintian tags and releases of Debian Policy. Looking at my notes from the BoF, there are two types of metadata that could be useful: 1. tag metadata indicating the release of policy that added the requirement or recommendation checked by the tag For example, a Lintian tag emitted when a package installs both a menu entry and a desktop entry would have '4.0.1' for the value of this piece of metadata. That's because policy 4.0.1 introduced the requirement that a package not install both a menu entry and a desktop entry. 2. for each Lintian release, a list of policy versions such that for each version V, if the Standards-Version of a package is the version of policy immediately prior to V and the package is Lintian clean, the Standards-Version may be bumped to V It should be clear how (2) is useful to package maintainers: if their package has Standards-Version 4.0.0, the package is Lintian clean under the latest release of Lintian and the list of versions in (2) for the latest release of Lintian includes 4.0.1, they may bump their Standards-Version to 4.0.1 without working through the upgrading checklist. (1) is useful for constructing (2): we can compare the list of tags which have 4.0.1 as their value for (1) to the upgrading checklist for policy release 4.0.1, and if each item in the list is covered by a tag, we may add 4.0.1 to (2) for the next release of Lintian. We would expect this metadata to be quite incomplete, both because it is time-consuming to compile and because not all new policy requirements can be checked by Lintian tags. This incompleteness would not prevent the metadata from being useful to maintainers where it does exist. There are also questions about whether to include recommendations (usually Lintian info/pedantic tags) in this, or just requirements. The latter probably makes more sense since maintainers bump standards-version based on requirements that they have satisfied, not recommendations. Thanks for considering these suggestions! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.29-4 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.18.24 ii file 1:5.31-1 ii gettext 0.19.8.1-2+b1 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.32+b2 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b2 ii libdpkg-perl 1.18.24 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.0-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.72-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.63-2+b2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.26.0-5 ii t1utils 1.40-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.24 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.46-1 -- no debconf information -- Sean Whitton signature.asc Description: PGP signature
FYI: annotating the upgrading checklist with Lintian tags
Hello, Following up on another suggestion from our BoF at DebConf17, I've added to the "About the checklist" section of the upgrading checklist a convention for indicating that a Lintian tags exists to cover a new policy requirement. Simply add the Lintian tag in square brackets at the end of the upgrading checklist entry. -- Sean Whitton signature.asc Description: PGP signature
Bug#749826: Documenting `Multi-Arch: foreign`
Hello Helmut, I spoke to Russ and we're both of the view that we should document multiarch piecemeal. Let's begin by getting a definition of the Multi-Arch: field into ch. 5 of policy. I have pushed a new branch to the Debian policy repo named bug749826-spwhitton. On that branch I've committed a slightly reworked form of your draft text.[1] Please review the diff. Here are some comments/issues: - I substantially shortened your text. Let me know if you think I went too far. - Previously I was worried about defining 'interface' but I've found another place where policy uses this word without defining it, and I don't think it needs to be changed in either place. - I couldn't figure out how to include this text, because I didn't understand it: For instance, using dpkg --print-architecture can be used to emit the native architecture even though dpkg is marked Multi-Arch: foreign. Similarly, calling pkg-config (without a prefix) will behave differently on different architectures as its search path is architecture-dependent even thoug pkg-config is marked Multi-Arch: foreign. Are you saying that packages that depend or implicitly depend on dpkg or pkg-config cannot be Multi-arch: foreign, although dpkg and pkg-config themselves are Multi-arch: foreign? Why are dpkg and pkg-config Multi-arch: foreign, if they provide these architecture-dependent interfaces? - I didn't include your TODO about README.multiarch; let me know whether you have a more concrete idea about the purpose of that file - after we've got text documenting the other possible values of the Multi-Arch: field, we might want to promote the list of things to consider out of the Multi-Arch: foreign subsubsection. It should become clear once we've got that other text together. Thank you again for your work so far. [1] https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign -- Sean Whitton signature.asc Description: PGP signature
Bug#630174: debian-policy: forbid installation into /lib64
control: tag -1 -patch +pending I too second the following change proposed by Bill: > diff --git a/policy.sgml b/policy.sgml > index 404dc73..f9fdbf7 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -6955,12 +6955,13 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) >character. > > > > > - The requirement for amd64 to use /lib64 > - for 64 bit binaries is removed. > + The requirement for amd64 to use /lib64 for > + 64 bit binaries is removed. Only the dynamic linker is > + allowed to use this directory. > > > > >The requirement for object files, internal binaries, and > @@ -6983,10 +6984,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) > use in cross-installation of library packages from other > architectures, as part of multiarch. > > > > + No package for a 64 bit architecture may install files > + in /usr/lib64/ or in a subdirectory of it. > + > + >The requirement for C and C++ headers files to be >accessible through the search path >/usr/include/ is amended, permitting files to > be accessible through the search path >/usr/include/triplet where -- Sean Whitton signature.asc Description: PGP signature
Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field
Thank you for the new patch, Ben. Comments: - please move the License-Grant field to the end of the list of fields to avoid any renumbering - please strip the rewordings that you've made to other parts of the document, so this patch addresses this bug alone. If you want to make those changes, please file separate 'informative' bugs against debian-policy; these do not need to be seconded and are applied at the discretion of the policy editors. - I think you've used too many spaces to indent the License-Grant text in the examples. Shouldn't it be just one space? - since the field is optional, I don't think we should modify every example to include License-Grant. Perhaps consider reducing the number of times you add it? - note that this bug doesn't apply to policy's HEAD anymore because we've switched to rST; it would be nice if you could rebase but I will happily do this on your behalf as I was partly responsible for the switch -- Sean Whitton signature.asc Description: PGP signature
Bug#648271: [debian-policy] 11.8.3 "Packages providing a terminal emulator" says xterm passes -e option straight to exec
control: tag -1 -patch +pending On Sun, Dec 25, 2011 at 02:52:11AM -0600, Jonathan Nieder wrote: > Support the command-line option "-e ", which creates a new > terminal window and runs the specified command. may be > multiple arguments, which form the argument list to the executed > program. In other words, the behavior is as though the arguments > were passed directly to execvp, bypassing the shell. (xterm's > behavior of falling back on using the shell if -e had a single > argument and exec failed is permissible but not required.) Seconded. -- Sean Whitton signature.asc Description: PGP signature
Bug#786470: debian-policy: [copyright-format] Add an optional “License-Grant” field
On Tue, Aug 22 2017, Ben Finney wrote: > On 20-Aug-2017, Sean Whitton wrote: > >> - note that this bug doesn't apply to policy's HEAD anymore because >> we've switched to rST > > Did you find a conflict? I have pulled the latest HEAD (commit hash > f0f316c879a7e60e), and the ‘./copyright-format-1.0.xml’ remains the > only source document of the “Machine-readable debian/copyright file” > specification. Sorry, I forgot that we haven't actually converted that file. -- Sean Whitton signature.asc Description: PGP signature
Bug#872868: debian-policy: section numbers missing
control: retitle -1 Plain text output format lacks section numbering Hello Adam, On Tue, Aug 22 2017, Adam Borowski wrote: > I'm afraid that the new upload of the policy doesn't include section numbers > in the text -- neither in the TOC nor in the body. As that's how we usually > refer to parts of the Policy, that makes any such references impossible. The PDF, HTML, info and ePub output formats have section numbering. The plain text format doesn't yet, mainly because it's put together with a local hack -- Sphinx generates one plain text file for each chapter, but we want a single policy.txt. We are waiting on better upstream support. In the meantime, you might consider using the info output format. -- Sean Whitton signature.asc Description: PGP signature
Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7
control: tag -1 +patch On Wed, Aug 01, 2012 at 08:07:01AM +0900, Charles Plessy wrote: > Otherwise, how about something along these lines: [...] Commenting on Charles' patch, I think that it would be clearer to have the 'should' and 'must' requirements in separate sentences. Thus I am seeking seconds for the following patch: diff --git a/policy/ch-source.rst b/policy/ch-source.rst index f706a13..89b355a 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -99,10 +99,11 @@ later reconfigure the package without losing the changes you made. Debian changelog: ``debian/changelog`` -- -Changes in the Debian version of the package should be briefly explained -in the Debian changelog file ``debian/changelog``. [#]_ This includes -modifications made in the Debian package compared to the upstream one as -well as other changes and updates to the package. [#]_ +Every source package must include the Debian changelog file, +``debian/changelog``. Changes in the Debian version of the package +should be briefly explained in this file. [#]_ This includes +modifications made in the Debian package compared to the upstream one +as well as other changes and updates to the package. [#]_ The format of the ``debian/changelog`` allows the package building tools to discover which version of the package is being built and find out -- Sean Whitton signature.asc Description: PGP signature
Bug#872900: debian-policy: Very generic info file name
Hello, On Tue, Aug 22 2017, Russ Allbery wrote: >> So while using it I noticed that it has been installed with an >> extremely generic name, for something that is a global resource. I >> think it should be renamed to debian-policy. > > Ack, yes, this is my fault. Will fix. Whoever fixes this will need to rename all the images to have a debian-policy- prefix. This is a convention when you install images into /usr/share/info. -- Sean Whitton signature.asc Description: PGP signature
Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7
control: tag -1 +pending Hello, On Tue, Aug 22 2017, Mattia Rizzolo wrote: > LGTM, seconded. Applied, thanks. > That said, I'd expect the upgrade-checklist to say that this change is > about clarifying that debian/copyright must exist (where before it was > "fine" not existing). Not sure what you're asking. Let me know if what I just pushed could be better. -- Sean Whitton signature.asc Description: PGP signature
Bug#872896: debian-policy: An html.tar.gz has leaked into the .deb?
Hello Guillem, On Tue, Aug 22 2017, Guillem Jover wrote: > It seems that an html.tar.gz has leaked (?) into the .deb, which > contains the single single html file plus ancillary files. It is > not clear whether this is an intentional change as it's not listed > on the changelog. It looks at least a bit redundant. Hmm, I thought that it was needed as it is offered for download on www.debian.org. Russ, can you remember how that download link worked previously? -- Sean Whitton signature.asc Description: PGP signature
Bug#872895: debian-policy: Split html for policy lost
Hello Guillem, On Tue, Aug 22 2017, Guillem Jover wrote: > This version has lost the distinction between a single policy html and > the one with different files per chapter. This will break links. This was intentional. The single page output is much more useful to casual readers wanting to look something up. I think that maybe we should reassign this bug to www.debian.org to request rewriting of the old URIs? -- Sean Whitton signature.asc Description: PGP signature
Re: policy 4.1.0 HTML doc is not fully uploaded to www.debian.org site
Hello Hideki, On Tue, Aug 22 2017, Hideki Yamane wrote: > Thanks for uploading policy version 4.1.0, but it is not fully uploaded > to the site, seems that only index.html is done. For example, > https://www.debian.org/doc/debian-policy/_static/nature.css doesn't exist. I get 403 not 404; I think it's a .htaccess issue on the www team's side. Perhaps you could file a bug against www.debian.org. -- Sean Whitton signature.asc Description: PGP signature
Bug#872893: debian-policy: Chapters, sections, appendices and numbering
control: tag -1 +moreinfo Hello Guillem, On Tue, Aug 22 2017, Guillem Jover wrote: > At least on the PDF output, the section numbers are wrong, as there > are now two chapters that include the old sections. Could you explain "two chapters that include the old sections", please? Or just say which sections are wrong. We tried hard to avoid this, so it's definitely a bug. > The appendices are also not easily distinguishable from the other > sections as they also use numbers intead of say letters. This is a limitation of Sphinx. We aren't going to fix it unless a new feature arrives from upstream. -- Sean Whitton signature.asc Description: PGP signature
Bug#872895: debian-policy: Split html for policy lost
Hello Jonathan, On Tue, Aug 22 2017, Jonathan Nieder wrote: > I don't completely understand. The old rendering had both single page > and multi-page versions. If I understand what you're saying, it is a > reason that the single-page version is useful, but why does that > preclude also providing the multi-page rendering? Ah, sorry, I think there are two bugs here: - it would be nice to include the multi-page rendering in the package - since we're publishing only the single-page version on www.debian.org, we need to rewrite the links -- Sean Whitton signature.asc Description: PGP signature
Bug#872944: www.debian.org: Debian Policy Manual not fully published
Package: www.debian.org Severity: important Hello webmasters, The Debian Policy Manual just changed its HTML output and while the HTML has published, the CSS and included images have not. Looking at [1], the CSS and included images should have been published because they're still installed to /usr/share/doc/debian-policy/policy.html/. So I think this is a problem on your end rather than ours. Please do reassign this bug if I'm wrong about that, and thanks in advance for your help. [1] https://anonscm.debian.org/cgit/debwww/cron.git/tree/parts/7doc -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Sean Whitton signature.asc Description: PGP signature
Bug#872895: debian-policy: Split html for policy lost
control: retitle -1 Include multi-page HTML in package ^ see below for explanation Hello, On Tue, Aug 22 2017, Mattia Rizzolo wrote: > On Tue, Aug 22, 2017 at 12:10:36PM -0700, Sean Whitton wrote: >> - it would be nice to include the multi-page rendering in the package > > More than nice, please. I don't really deal with huge single-page > documents. Besides you wrote: >> The single page output is much more useful to casual readers wanting >> to look something up > I deem this completely subjective, please don't assume such assertion as > facts. Also, I don't consider myself a "causual reader" and when I want > to read something up I know what's the name of the paragrah, pick it > from the index and then head to the relevant, single page. Right, indeed, you're not a casual reader, and we would expect you to have the Debian package installed. I think the web version should be tailored for people coming from outside the project who don't know that such a package exists. For them, it's easier to have a single page. This is subjective but that doesn't preclude me making a judgement about what most people would prefer, based on my experience. >> - since we're publishing only the single-page version on >> www.debian.org, we need to rewrite the links > > Please do publish both. On Tue, Aug 22 2017, Guillem Jover wrote: > I guess there are two problems here, one is indeed completely losing > the multi-page rendering from the package. The other is the default > change in the web site. IMO the best solution, and what is customary, > is to present both (or more) rendering and let the user select: > > [HTML one-page] [HTML multi-page] [PDF] [EPUB] So you'd like https://www.debian.org/doc/debian-policy/ to be a menu? I think that those who want this should file a bug against www.debian.org. It's not really in our purview, since we don't maintain the script that maintains the /doc/ directory. Hence I'm retitling this bug to the part that is the policy editors' responsibility. -- Sean Whitton signature.asc Description: PGP signature
Bug#872893: debian-policy: Chapters, sections, appendices and numbering
On Tue, Aug 22 2017, Guillem Jover wrote: > Take section «10.9.1. The use of dpkg-statoverride», this is correct > on the HTML output and info file, on the PDF it's a section w/o a > number inside §2.10.9. I've not checked the EPUB file. Thanks! > And I've just noticed on the info files it's just worse as they do not > get their section numbers reset so they keep incrementing from the > last chapter index. For example «Binary packages (…)» used to be > appendix B, now it's 2, but on the info file it's 14. Okay, that sounds like a bug -- thanks. -- Sean Whitton signature.asc Description: PGP signature
