Bug#986320: Stronger advice on when to use native packages

Hi, Russ Allbery wrote: > Currently, Debian Policy is silent on when it's appropriate to use a > native package, but there may be a project consensus aganist using > native packages when the software has an existence outside of Debian. I agree about this (modulo the bits discussed elsewhere in

Bug#954794: New packages must not declare themselves Essential

Hi, Sean Whitton wrote: > On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote: > > On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote: >>> Could I ask you to explain your wanting to reduce the Essential set for >>> the sake of small installation size in more detail, including some >>>

Bug#954794: New packages must not declare themselves Essential

Javier Serrano Polo wrote: > On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder > wrote: >> Even so, some *rough* consensus on the plan is very useful for >> helping people evaluate that first step. > > Here is a rough plan: > >1. Policy: Packages should declar

Bug#954794: New packages must not declare themselves Essential

Josh Triplett wrote: > Jonathan Nieder wrote: >> Josh Triplett wrote: >>> This change does not propose eliminating the concept of Essential, nor >>> does it propose that any specific package become non-Essential. >> >> I think I'd be more support

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

Hi, Sam Hartman wrote: > I think there are at least two cases where this issue comes up and is > important, and where using a debian revision without separate upstream > tarballs is the right approach: > > 1) small packages currently maintained by the upstream maintainer where > debian revision

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

Niels Thykier wrote: > debhelper cannot see "inside" the upstream build system. If you modify > a .c file, debhelper won't notice and will currently just skip the > entire build. Alternatively, debhelper will have to invoke the build > system and rely on it to not be flawed. Yes, I think that

Bug#949007: debian-policy: Typo in example

Niels Thykier wrote: > In > https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi > we find the following example: > > """ > Examples of valid use of the gain root command: > > # sh-syntax (assumes set -e semantics for error handling) > $DEB_GAIN_ROOT_CMD some-cmd

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

Hi! Niels Thykier wrote: > I would like to propose that we drop or replace the following > recommendation in Policy: > > """ > When a package has a configuration and build routine which takes a > long time, or when the makefiles are poorly designed, or when build > needs to run clean first, it

Bug#932696: Please document Haskell team style Vcs-Git sytax

Russ Allbery wrote: > If you want to do what vcswatch is doing (analyze the current code > repository for Debian packaging for commits that haven't been uploaded), > and the team is, like Haskell, using a single repository for all the > packages, you need to be able to find that specific package

Bug#932696: Please document Haskell team style Vcs-Git sytax

Hi, Ian Jackson wrote: > Russ Allbery writes: >> So, maybe something like: >> >> -b [; = ...] >> >> to build off of what we already have? (With, obviously, a bunch of that >> syntax marked as optional.) If we ban "=" in , we can allow for >> to be optional but some other key/value pair

Bug#917995: debian-policy: drop section 1.6 Translations

Hi, Marc Haber wrote: > On Wed, Jan 02, 2019 at 12:29:50PM +0900, Ansgar Burchardt wrote: >> I hereby propose to drop section 1.6 Translations and the following >> sentence: "When translations of this document into languages other >> than English disagree with the English text, the English text

Bug#917431: debian-policy: virtual packages: logind, default-logind

Adam Borowski wrote: > logind: an org.freedesktop.login1 D-Bus API implementation > default-logind: distribution's default logind provider Seconded. I like this description because it doesn't make assumptions about how many logind implementions there are or which is the current default, which

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

Andreas Henriksson wrote: > It seems obvious to me that the above policy snippet was written in a > time when the universe revolved around sysvinit. In current day and age > sysvinit itself would be an "Alternate init system". We could update the > snippet to say that any package providing

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

Hi Russ, Russ Allbery wrote: > I'm looking for seconds for this patch to relax the current requirement > back to a should. [...] > --- a/perl-policy.xml > +++ b/perl-policy.xml > @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall" >Script Magic > > > -All packaged perl

Bug#907051: Say much more about vendoring of libraries

Hi, Arnaud Rebillout wrote: > During all this time when I was questioning myself on the reason to > un-bundle, the only official documentation I found was the short > paragraph in the Debian Policy [1], which is quite thin. Only now, > through the thread in debian-devel, I discover that there is

Bug#907051: Say much more about vendoring of libraries

Hi, Sean Whitton wrote: > On Thu 23 Aug 2018 at 12:27PM +0200, Alec Leamas wrote: >> https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries > > Thank you for sharing this link -- it seems like Fedora have thought > harder about this than we have, at

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

Hi, Dominic Hargreaves wrote: > On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote: >> I do feel like allowing either based on the whim of the packager is just >> kind of bad. It produces inconsistent behavior to no real benefit for >> anyone. If you install a Perl earlier in your

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi, Ian Jackson wrote: > Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): >> Currently, copyright-format >> 1.0 requires either that every License stanza in a Files paragraph contain >> some "license text" in the copyright-format

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Clément Hermann wrote: > On 03/08/2018 04:23, Sean Whitton wrote: > > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: >>> "as verbose as reasonably possible" seems incompatible with "maximally >>> verbose >>> output", at least in some cases (golang packages come to mind). >>>

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Sean Whitton wrote: > On Thu 02 Aug 2018 at 07:29PM -0700, Jonathan Nieder wrote: >> Thanks. Unfortunately, that wouldn't address Clément's concern about >> maximal verbosity (1) not being consistent with reasonableness and (2) >> not being concrete enough to easily

Bug#905453: debian-policy: Policy does not include a section on NEWS.Debian files

Hi Elana, Elana Hashman wrote: > NEWS.Debian files are listed in the "unofficial policy"[1] but not in > the official policy. > > It seems this was proposed in 2002[2], but in 2003, folks were > hesitant to "[get] this into policy until enough stuff uses it that we > can tell it works well". > >

Bug#905401: permit access to apt repositories during builds

Josh Triplett wrote: > Why don't we make a specific exception for d-i in the short term, in the > hopes that in the long term we'll have a way to handle dependencies on > sources Thanks, that makes a lot of sense to me. I retract my second in message #13, but I'd be happy to review a patch that

Bug#905401: permit access to apt repositories during builds

Ian Jackson wrote: > Jonathan Nieder writes ("Re: permit access to apt repositories during > builds"): >> My feeling is that this should be an outside-policy carveout, since it >> makes many applications (e.g., analyzing the build graph, especially >> when n

Bug#905401: permit access to apt repositories during builds

Hi, Ian Jackson wrote: > Apropos of discussion in #813471: > > Paul writes: >> In addition, d-i relies on access to the apt repo for the system. >> I can imagine other uses of that, so I added a carve-out for that. > > In general I think this should be done by saying that packages may > access

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

Hi, Simon McVittie wrote: > On Wed, 01 Aug 2018 at 19:23:09 -0700, Jonathan Nieder wrote: >> Simon McVittie wrote: >>> ( ) the full text of the license, *and* the license grant >>> (unless the license *is* the license grant, like BSD-style licenses) >>

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi, Markus Koschany wrote: > I personally dislike the trend in Debian to create more and more > complexity in our source packages. I find the Standards-Version field > unnecessary, VCS fields should not be part of a debian/control file, all > DFSG licenses approved by our ftp-team should be

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Sean Whitton wrote: > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: >> "as verbose as reasonably possible" seems incompatible with "maximally >> verbose >> output", at least in some cases (golang packages come to mind). >> >> Would it be possible to clarify this ? > > Yes. Let's

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Sean Whitton wrote: > On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote: >> Thanks for reporting. My understanding from >> https://bugs.debian.org/628515 is that the intention is >> >> - print out compiler driver command lines, so that compiler error

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

Hi, Clément Hermann wrote: > 4.9 states: > The package build should be as verbose as reasonably possible. > This means that ``debian/rules`` should pass to the commands it > invokes options that cause them to produce maximally verbose > output. > > "as verbose as reasonably

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

Hi, Markus Koschany wrote: > FYI: Here is what one of the ftp-masters, Jörg Jaspert, wrote in > response to my proposal to reduce boilerplate in debian/copyright. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883950#80 > > I believe it shows the generally tendency that they are in favor

Bug#904248: Add netbase to build-essential

Hi, Sean Whitton wrote: > On Wed 25 Jul 2018 at 09:14PM -0700, Jonathan Nieder wrote: >> Looks okay to me. As an alternative, we could encourage packages to >> add an explicit Build-Depends on netbase if they need this >> functionality. >> >> I think in the lo

Bug#904248: Add netbase to build-essential

Hi, Sean Whitton wrote: > Thank you for the discussion, Ian and Simon. Here is the beginnings of > a patch: > >> diff --git a/policy/ch-source.rst b/policy/ch-source.rst >> index 9e7d79c..f27226e 100644 >> --- a/policy/ch-source.rst >> +++ b/policy/ch-source.rst >> @@ -40,9 +40,15 @@ example,

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

Sean Whitton wrote: > On Wed 25 Jul 2018 at 07:01PM -0700, Jonathan Nieder wrote: >> I share gregor's discomfort: I don't think we've thought this through. > > I too want Policy to be as correct as possible, but this bug has been > open for ten years and one thing upon which

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

Hi, Sean Whitton wrote: > On Mon 23 Jul 2018 at 01:40PM +0200, gregor herrmann wrote: >> Let me see if I got this right, and apply it to the typical pkg-perl >> package: >> >> CPAN distributions usually contain no NEWS file, and do contain a >> Changes/ChangeLog/... file which is "an upstream

Bug#904608: Support specifying upstream VCS location in debian/control

Hi, Sean Whitton wrote: > On Wed 25 Jul 2018 at 05:14PM +0100, Iain Lane wrote: >> Some tools, like git-buildpackage, can support merging an upstream's >> version history into Debian packaging repositories. This enables more >> rich usage of (D)VCS when packaging - for example `git blame' works

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

Sean Whitton wrote: > On Sun 22 Jul 2018 at 11:12PM -0700, Jonathan Nieder wrote: > > > That would mean Recommends is effectively Depends. Is it really what you > > intend? > > I don't follow. > > My patch says that /some/ functionality might not work without the

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

Sean Whitton wrote: Seeking seconds: > > diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst > index 1eaa422..03f5918 100644 > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst > @@ -228,6 +228,10 @@ The meaning of the five dependency fields is as > follows:

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

Hi, Chris Lamb wrote: > Sean Whitton wrote: >> Either Policy should mandate this field, or it should not be a Lintian >> error when it is not present. > > Any update on this? It is somewhat tempting to re-assign this to Policy > alone until there is a resolution there. What say you? :)

Bug#515856: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Mon, Jul 02 2018, Jonathan Nieder wrote: >> I'm a bit confused: wasn't it already specified pretty precisely? > > Please take a look through the bug's discussion. It's explained why the > wording was not thought to be good enough. Thanks. This lo

Bug#515856: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Wed, Apr 11 2018, Russ Allbery wrote: >> I'm pretty reluctant to specify this sort of optional target that >> works differently in every package that uses it back in Policy because >> it's really not standardized, nor do I think it's possible to >> standardize. If

Bug#892142: debian-policy: update example to use default-mta instead of exim

onded: Holger Levsen <hol...@layer-acht.org> @@ -29,6 +30,10 @@ debian-policy (4.1.4.0) UNRELEASED; urgency=medium * Fix indentation of description of the clean target (Closes: #889960). Thanks Ferenc Wágner for the report. + [ Jonathan Nieder ] + * Use default-mta instead of exim in d

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Jonathan Nieder wrote: > Markus Koschany wrote: >> freeorion: [1] >> >> Rather sophisticated game GPL-2 licensed but with various contributions >> / incorporations under different licenses. So I can't just write Files: >> * -> GPL-2. I have to list a

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > freeorion: [1] > > Rather sophisticated game GPL-2 licensed but with various contributions > / incorporations under different licenses. So I can't just write Files: > * -> GPL-2. I have to list all licenses with separate paragraphs and > there is no way to change that

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Hi, Markus Koschany wrote: > I still have to quote license texts verbatim. The only > "advantage" of the old format is that I can format d/copyright more > freely but the same information must be present anyway. It is simply not > feasible to educate all upstreams in existence to

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > Am 28.12.2017 um 11:21 schrieb Bill Allombert: >> On Wed, Dec 27, 2017 at 01:56:44PM -0800, Russ Allbery wrote: >>> Jonathan Nieder <jrnie...@gmail.com> writes: >>>> Seconded. >>> >>> license-count says this makes sens

Bug#885219: /lib64 provision added in 9.1.1 prohibits multilib libc

Russ Allbery wrote: > Allow libc to install files in /lib64 > > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst > index 7d9e20a..d7c4956 100644 > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -35,7 +35,8 @@ Debian Policy. The following exceptions to the FHS apply:

Bug#688251: Built-Using description too aggressive

Hi, Sean Whitton wrote: > --- a/policy/ch-relationships.rst > +++ b/policy/ch-relationships.rst @@ -598,17 +598,26 @@ earlier for > binary packages) in order to invoke the targets in > Additional source packages used to build the binary - ``Built-Using`` >

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

Hi Markus, Markus Koschany wrote: > Am 16.12.2017 um 15:55 schrieb Sean Whitton: >> On Wed, Dec 13 2017, Markus Koschany wrote: >>> If the Policy editors cannot make a decision with regards to >>> debian/copyright then we should ask the DPL to seek legal advice and >>> when necessary start a GR

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Hi again, Markus Koschany wrote: > Let me try to explain it this way: Take src:ufoai-data or src:netbeans > for example. Both packages ship approximately a dozen different > licenses. I can't simply copy the upstream license because I have > to format it to make it copyright format 1.0

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Hi, Markus Koschany wrote: > I would like to argue that disk space is no longer an issue in 2017 and > people with special needs (embedded systems) will most likely remove > /usr/share/common-licenses anyway. I agree: space on installation media and network transfer time are more important than

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

Hi, Markus Koschany wrote: > Am 13.12.2017 um 19:10 schrieb Jonathan Nieder: >> Markus Koschany wrote: >>> License: AGPL-3.0 >>> Source: https://www.gnu.org/licenses/agpl-3.0.de.html >>> Example packages: >>> https://wiki.debian.org/DFSGLicenses#G

Bug#884227: debian-policy: please add zlib to common licenses

Markus Koschany wrote: > License: zlib > Source: https://opensource.org/licenses/Zlib > Example packages: > https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29 Hm. The license says 3. This notice may not be removed or altered from any source distribution. And part of

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: OFL-1.1 > Source: https://opensource.org/licenses/OFL-1.1 > Example

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: EPL-1.0 > Source: https://www.eclipse.org/legal/epl-v10.html > Example

Bug#884225: debian-policy: please add CC-BY-4.0 to common licenses

Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: CC-BY-4.0 > Source: https://creativecommons.org/licenses/by/4.0/ > Example

Bug#884224: ebian-policy: please add CC-BY-3.0 to common licenses

Hi, Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: CC-BY-3.0 > Source: https://creativecommons.org/licenses/by/3.0/ >

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

Hi, Markus Koschany wrote: > as discussed on debian-devel [1] I would like to request that more DFSG > licenses are added to /usr/share/common-licenses and that package > maintainers are allowed to reference them. > > License: AGPL-3.0 > Source: https://www.gnu.org/licenses/agpl-3.0.de.html >

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

Hi, Sean Whitton wrote: > On Thu, Nov 30 2017, Simon McVittie wrote: >> Other than that, seconded. I'm not sure whether this is necessarily >> how the autobuilders *should* work, but there's value in documenting >> how the autobuilders *do* work. > > Thank you for reviewing this bug. > > Since

Bug#459427: changelog vs. NEWS handling

Josh Triplett wrote: > On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert wrote: >> The fact that some upstream do not bother to ship useful changelog does >> not mean that all changelog are useless, and by removing them we >> discourage upstream of producing useful changelog.

Bug#459427: changelog vs. NEWS handling

Hi, gregor herrmann wrote: > From the Perl world, looking at roughly ~3400 packages I have locally > cloned: > > 28 have a NEWS file (most of them with a Gnome/GTK background), 1 > News, 1 news. > > 3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other > variations like

Bug#683495: Mandating use of /usr/bin/perl in Policy

Bill Allombert wrote: > On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote: >> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote: >>> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]: I am seeking seconds for the following patch to close this bug, which I

Bug#880992: debian-policy should not recommend running editor using absolute path

Hi, Sean Whitton wrote: > On Mon, Nov 06 2017, Jonathan Nieder wrote: >> Thus, every program that launches an editor or pager must use >> the EDITOR or PAGER environment variable to determine the editor >> or pager the user wishes to use. If these

Bug#878905: debian-policy: Document installability recommendations for dependency alternatives

Hi, Julian Andres Klode wrote: > APT's solver is greedy and sometimes has a hard time to recover from paths > that > don't work out in the end. We see this with opencv failing to build on > !linux-any > because: > > (1) dconf-service depends default-dbus-session-bus | dbus-session-bus > (2)

Bug#877697: ebian-policy: discourage using all 4 digits numbers in Standards-Version

Hi, Mattia Rizzolo wrote: > Policy § 5.6.11, after describing the meaning of the digits in the > policy version, reads: > > | Thus only the first three components of the policy version are > | significant in the Standards-Version control field, and so either > | these three components or all

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> C. You have transport-level integrity protection, e.g. by using a >> protocol like https:// or ssh:// with proper PKI. > > I think it's worth being honest with ourselves here that the prop

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: >> Russ Allbery wrote: >>> (That said, my understanding is that you don't get any meaningful >>> integrity protection for Git from using https over http.) >> >> As discussed elsewhe

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Jonathan Nieder wrote: > Russ Allbery wrote: >>> On Wed, Aug 23 2017, Russ Allbery wrote: >>>> --- a/policy/ch-controlfields.rst >>>> +++ b/policy/ch-controlfields.rst >>>> @@ -962,6 +962,10 @@ repository where the Debian source package is >>

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

Russ Allbery wrote: > Sean Whitton writes: >> On Wed, Aug 23 2017, Russ Allbery wrote: >>> --- a/policy/ch-controlfields.rst >>> +++ b/policy/ch-controlfields.rst >>> @@ -962,6 +962,10 @@ repository where the Debian source package is >>> developed. >>> >>> More

Bug#682347: mark 'editor' virtual package name as obsolete

Hi, Russ Allbery wrote: > +++ b/policy/ch-customized-programs.rst > @@ -93,19 +93,21 @@ page. [...] > -It is not required for a package to depend on ``editor`` and ``pager``, > -nor is it required for a package to provide such virtual > -packages. [#]_ > +Packages may assume that

Bug#872956: [debian-policy] warn about danger of pipe in shell snippet of makefile

Hi, Bastien ROUCARIÈS wrote: > set -e is not suffisant to detect error in pipe context > > cat nonexistant | sed s/some//g will hapilly return 0 and do not fail > > exec 3>&1; s=$(exec 4>&1 >&3; { cat nonexistant ; echo $? >&4; } | sed > s/some//g ) && exit $s > > this could be simplified by

Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7

Sean Whitton wrote: > 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

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

Hi, Russ Allbery wrote: > How does this look to everyone? Seconded, with or without the tweaks dkg suggested in https://bugs.debian.org/732445#68 Thanks, Jonathan > --- a/policy.xml > +++ b/policy.xml > @@ -2556,11 +2556,28 @@ endif > > > This is an optional, recommended

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

Hi, Ansgar Burchardt wrote: > as a more radical change one could also ask the question where to > maintain the maintainer information. Currently we handle this in the > source package via the Maintainer and Uploaders field, and via team > memberships. > > This has several limitations: for

Bug#757760: debian-policy: please document build profiles

Hi, Johannes Schauer wrote: > please document the new Build-Depends syntax and fields for build > profiles. The current write-up of the new syntax and fields for build > profiles lives at https://wiki.debian.org/BuildProfileSpec > > Please note, that the new Build-Depends syntax element is

Bug#758234: Allow packages to depend on packages of lower priority

Hi, Adam Borowski wrote: > What about this wording?: > > - Packages must not depend on packages with lower priority values (excluding > - build-time dependencies). In order to ensure this, the priorities of one > - or more packages may need to be adjusted. > + Packages' priorities should

Bug#568374: debian-policy: section "8.4 Development files" not explicit enough regarding libraryname[soversion]-dev

Emilio Pozuelo Monfort wrote: > On Tue, 27 Oct 2015 10:06:50 +0100 Ansgar Burchardt wrote: >> I suggest to change >> >> | If there are development files associated with a shared >> | library, the source package needs to generate a binary >> | development package named

Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all

Hi, Robert Luberda wrote: Please explicitly state in the Policy if linking /usr/share/doc/arch:any_package to ../arch:all_package (where arch:any_package and arch:all_package come from the same source package) is allowed or not. It currently is not allowed. [...] In my opinion, as I

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

Hi, Martin Carpenter wrote: 8.7 RUNPATH and RPATH Libraries and executables should not define RPATH or RUNPATH unless absolutely necessary. This part seems vague to me --- if a project relies on RUNPATH but could be modified to avoid relying on it, is today's use of RUNPATH absolutely

Bug#759260: removal of the Extra priority.

Bill Allombert wrote: On Mon, Nov 17, 2014 at 01:59:37PM -0800, Jonathan Nieder wrote: And received pushback from maintainers that don't understand what the field is for, are confused about having to maintain it in two places (debian

Bug#196367: removal of the Extra priority.

(+cc: bug#196367, which proposes documenting overrides as authoritative) Bill Allombert wrote: On Mon, Nov 17, 2014 at 02:29:46PM -0800, Jonathan Nieder wrote: Bill Allombert wrote: Did you try to report the bug directly to the ftp-masters ? If we decide that the ftp-masters are maintaining

Bug#759260: removal of the Extra priority.

Hi, Charles Plessy wrote: practically speaking, how do you or others use the Optional priority to check that a package is not directly or transitively conflicting with another package ? [...] Can you give concrete examples where the Extra priority has been instrumental for you as a user or

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files

Hi, Simon McVittie wrote: Some packages currently have stanzas like this in their copyright files: License: MPL-2.0 The complete text of the Mozilla Public License 2.0 can be found in the `MPL-2.0' file in the same directory as this file. It is not clear to me whether Debian

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files

Simon McVittie wrote: My understanding is that Markus' question in that thread was orthogonal: is the exact license grant really required, or is the license itself enough? (for terminology see my reply at https://lists.debian.org/debian-devel/2014/09/msg00708.html). I would also appreciate

Bug#758234: [PATCH] Remove priority extra, make all corresponding packages priority optional

Ansgar Burchardt wrote: Russ Allbery r...@debian.org writes: In some cases, it can change maintenance decisions. Does this differ much from packages being picked up by other commonly installed software? Say GNOME starting to depend on my small library which suddenly raises from ~100 to

Bug#758234: [PATCH v2] Remove priority extra, make all corresponding packages priority optional

Hi, Gerrit Pape wrote: --- a/policy.sgml +++ b/policy.sgml @@ -852,17 +852,7 @@ zope. install if you didn't know what it was and don't have specialized requirements. This is a much larger system and includes the X Window System, a full TeX -

Bug#759186: debian-policy: please consider adding nodoc as a possible value for DEB_BUILD_OPTIONS to policy

Hi, Johannes Schauer wrote: please consider adding nodoc as a possible DEB_BUILD_OPTIONS value to § 4.9.1 [1]. [...] When bootstrapping, a common approach is to do a build without documentation to be able to drop the build dependencies on documentation building tools. This is why the

Bug#759186: debian-policy: please consider adding nodoc as a possible value for DEB_BUILD_OPTIONS to policy

Johannes Schauer wrote: Quoting Jonathan Nieder (2014-08-25 20:35:34) Johannes Schauer wrote: When bootstrapping, a common approach is to do a build without documentation to be able to drop the build dependencies on documentation building tools. This is why the build profile name nodoc

Bug#759260: debian-policy: allow packages to depend on packages of lower priority

Hi, Charles Plessy wrote: Ansgar, you have written that you find the priority “extra” useful in some situations, but for me it is not clear if the uses cases are for human readability, or if it is to rely on that priority in automated processes. Could you give us details ? There is probably

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

Hi Russ, Russ Allbery wrote: Third, to address your concern about the process, what about consensus review on debian-devel for any change in priority to required or important (that is not a downgrade from required to important)? Consensus review isn't the best process, since sometimes it

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

Hi, Ansgar Burchardt wrote: I suggest to drop the following paragraph from 2.5: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. This

Bug#757274: devref: please point upstream to PTS subscription UI when forwarding bugs

Package: developers-reference Version: 3.4.13 An upstream package maintainer just gave the following suggestion: Given that it's so easy to subscribe to the PTS at qa.debian.org, why don't maintainers point that out to upstream when forwarding bugs? That way, if upstream wants to see reports

Bug#742756: multi-arch and system-dependent header files

Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -6955,50 +6955,61 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) [...] + The requirement for C and C++ headers files to be + accessible through the search path +

Bug#555980: debian-policy: No policy on statically linked binaries

Hi, Bill Allombert wrote: --- a/policy.sgml +++ b/policy.sgml @@ -8466,7 +8466,11 @@ fi renamed. If a consensus cannot be reached, emboth/em programs must be renamed. /p - + p + Binary executables must not be statically linked with the +

Bug#555980: debian-policy: No policy on statically linked binaries

Hi, Russ Allbery wrote: Usually I argue for relaxing it to a should. In this case, I think we can flesh out the exception somewhat better and preserve the must. Binary executables must not be statically linked with the GNU C library, since this prevents the binary from

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

Hi, Tollef Fog Heen wrote: Suggested change: --- /proc/self/fd/13 2011-02-13 09:12:50.142239544 +0100 +++ policy.sgml 2011-02-13 09:12:01.565231567 +0100 @@ -5993,6 +5993,13 @@ to get access to kernel information./footnote /p

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

Bill Allombert wrote: On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote: Thanks. Applied. Well, I was working on a patch that looks like: + The requirement for file/usr/local/liblt;qualgt;/file + to exist if file/liblt;qualgt/file

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

Bill Allombert wrote: On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: FWIW I don't mind if you tweak the wording. Unfortunately it's not just qual = 32 or 64[1]. Luckily the only ones that would be relevant the way Debian uses qual are qual = 32 (mips, tilegx) qual

Bug#685992: debian-policy: Document in the policy the way to properly set selinux labels on files and directories

Hi, Laurent Bigonville wrote: A maintainer script can for example call the restorecon(8) executable to achieve this: [ -x /sbin/restorecon ] /sbin/restorecon $myfile Should I do this for all files I create in maintainer scripts, or only those that someone who knows things :) has

Bug#737559: copyright-format: author != copyright, add an author field?

severity 737559 wishlist user debian-pol...@packages.debian.org usertags 737559 = normative issue quit Hi Daniel, Daniel Pocock wrote: Author and copyright holder are not always the same person/entity. [...] License: GPL2 Copyright: 2014, Acme, Inc http://acme.example.org Author: Bob,

Bug#694883: copyright-format: author != copyright, add an author field?

Just forwarding to bug#694883 (please clarify the recommended form for public domain files) for easy reference. Thanks, Jonathan ---BeginMessage--- On 03/02/14 20:55, Jonathan Nieder wrote: Daniel Pocock wrote: I've only come across one package which included public-domain material so far

  1   2   3   4   >