Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

> "Aurelien" == Aurelien Jarno writes: Aurelien> If we go that route, here is a proposed alternative patch: Aurelien> --- a/policy/ch-source.rst Aurelien> +++ b/policy/ch-source.rst Aurelien> @@ -338,7 +338,8 @@ Aurelien> For example, the build target should pass

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

> "Josh" == Josh Triplett writes: I tend to agree with Sean that your rationale is not convincing. It sounds like you want to use policy as a stick to hit people over the head and say "policy is not a stick." I get the impression that you are trying to shift the status quo somehow, and

Bug#1064454: debian-policy: Restrict deb822 field names more

> "Niels" == Niels Thykier writes: Niels> Simon Josefsson: >> Would it make sense to change this to use an inclusive list of >> permitted characters instead? How about checking the field names >> that is in use today, and construct a regexp of permitted symbols >> out of

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Sean" == Sean Whitton writes: Sean> In general, I agree with Santiago. I find Policy's current Sean> scope and working process effective, and not especially Sean> ambiguous. I think everyone should read it during the NM Sean> process, if not sooner. Sean> Russ has

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

> "Guillem" == Guillem Jover writes: Guillem> At least the dpkg behavior seems entirely Guillem> correct to me and required for safe upgrades ( Can you help me understand the sentence above? Where is the case where this behavior is needed for safe upgrades? (I am asking out of

Bug#915583: debian sphinx styling: second attempt

>>>>> "Stéphane" == Stéphane Blondon writes: Stéphane> Le ven. 3 nov. 2023 à 15:43, Sam Hartman Stéphane> a écrit : >> >>>>> "Sean" == Sean Whitton writes: >> >> I'm happy to t

Bug#915583: debian sphinx styling: second attempt

> "Sean" == Sean Whitton writes: Sean> - it would be good to do some accessibility testing of some Sean> kind, at least with screenreaders. But maybe the fact that Sean> you've based your theme on an existing, popular Sphinx theme Sean> means this is covered? I'm happy to

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

> "Luca" == Luca Boccassi writes: Luca> Aside from more practical considerations, shipping /var Luca> content in packages is problematic because it's supposed to be Luca> local variable data, I agree with the above. Luca> that can be removed without breaking a Luca>

Bug#1051371: Post-/usr-merge paths for script interpreters

> "Luca" == Luca Boccassi writes: Luca> On Wed, 13 Sept 2023 at 04:48, Russ Allbery wrote: >> >> Control: retitle -1 Post-/usr-merge paths for script interpreters >> >> Simon pointed out that this bug is not yet ready to act on, which >> was very helpful. Thank

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

> "Daniel" == Daniel Gröber writes: >> Any configuration files created or used by your package must >> reside in /etc. It's fine for packages to store defaults outside of /etc. But that 's only true if you can override those defaults by placing a file in /etc.

Bug#1051371: Post-/usr-merge paths for script interpreters

> "Russ" == Russ Allbery writes: Russ> with a narrower issue). Several other people were, I think, Russ> arguing for (a), but I'm not sure if they would continue to do Russ> so when it's put in these terms. It's hard for me to express what I was advocating for in the terms you

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

> "Russ" == Russ Allbery writes: I don't know if this needs seconds, but I reviewed all the text and it looks good. If seconds are required, I second. signature.asc Description: PGP signature

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Bill" == Bill Allombert writes: Bill> But we do: we support debhelper 13.11.4 and debhelper 13.11.6. Bill> Even if we support a single implementation, we still need to Bill> know what is expected of it. At that level, I think the answer is roughly that if you call

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Santiago" == Santiago Vila writes: Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió: >> I therefore would like to propose a first: I think Policy should >> simply say that any package that provides a system service should >> use debhelper and rely on

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

> "Russ" == Russ Allbery writes: Russ> I therefore would like to propose a first: I think Policy Russ> should simply say that any package that provides a system Russ> service should use debhelper and rely on dh_installsystemd to Russ> put the appropriate commands in its

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

> "Luca" == Luca Boccassi writes: Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery wrote: >> >> Russ Allbery writes: >> >> > -If a service unit is not present, ``systemd`` uses dependency >> information > -contained within the init scripts and symlinks in >>

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

> "Luca" == Luca Boccassi writes: Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie wrote: >> >> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote: >> > Luca, am I right that service directories are specific to, >> well, services? > If so, what would you

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

> "Russ" == Russ Allbery writes: Russ> Here is an updated proposed change for this bug, incorporating Russ> Guillem's suggestions. It is ready for seconds. Russ> -- Russ Allbery (r...@debian.org) Russ> I have reviewed the patch; I support

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

> "Luca" == Luca Boccassi writes: Luca> Secondly, and less importantly, while I appreciate it's not Luca> how you handle policy changes, the way the rest of the Luca> distribution works is by 'building consensus' on mailing Luca> lists. Now I don't particularly like it, but it

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

> "Bill" == Bill Allombert writes: Bill> I would. Having two paths for the same thing is a technical Bill> debt going forward. I think the TC has made it clear we're committed to usrmerge at this point, and I think that one of the drivers behind usrmerge is that we gain more from

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

>>>>> "Ansgar" == Ansgar writes: Ansgar> On Wed, 2023-09-06 at 16:51 -0600, Sam Hartman wrote: >> > > > > > "Luca" == Luca Boccassi writes:     >> Luca> /bin/sh is not universally compatible with non-Linux OSes.

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

> "Luca" == Luca Boccassi writes: Luca> How would such a change look like? I looked at your patch. In most of the cases you are changing non-normative language. That is, parts of policy that do not create a requirement. For example: >Scripts may assume that "/bin/sh" implements the

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

> "Luca" == Luca Boccassi writes: Luca> /bin/sh is not universally compatible with non-Linux OSes. I claim it is more compatible. Luca> Also I thought that policy should not be used to beat other Luca> developers (it is because of this) and it should reflect the Luca>

Bug#1051371: debian-policy: stop referring to legacy filesystem paths for script interpreters

> "Luca" == Luca Boccassi writes: Luca> Debian only supports merged-usr since Bookworm. We should Luca> update policy to reference /usr/bin/sh and similar paths to Luca> describe recommended shebangs for scripts. I do not support this change. /bin/sh should still be the

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

> "Luca" == Luca Boccassi writes: >> I consider this proposal to be premature. Policy should document Luca> current >> practice, and I do not think this proposal does that. For what it's worth, I agree with Luca that we are ready for a change to document that service units need

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

> "Luca" == Luca Boccassi writes: Luca> It has come to my attention that there is one package in Luca> Debian using dpkg-divert to mask a systemd configuration file Luca> (an udev rule). Speaking as one of the maintainers, both Luca> upstream and downstream, I find this

Re: nocheck (don't run) vs nodoc (don't build)

>>>>> "Sean" == Sean Whitton writes: Sean> Hello, Sean> On Wed 26 Apr 2023 at 04:48PM -06, Sam Hartman wrote: >> I guess that's consistent with RFC 2119. And RFC 2119 SHOULD >> means that the requirement is RECOMMENDED, and an

Re: nocheck (don't run) vs nodoc (don't build)

> "Simon" == Simon McVittie writes: Simon> On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote: >> Policy 4.9.1 states that (emphases mine): * "[nocheck] says not >> to *run* any build-time test suite" * "[nodoc] says to skip any >> *build* steps" >> >> My

Re: 6.1.3. Multiple binary packages question

> "Kristian" == Kristian Penno writes: Kristian> source package is referenced. The lyx source package uses Kristian> some shell commands to move files around in the rules Kristian> file. Is this preferred to using debhelper Kristian> .install files? No. If .install files

Bug#801065: Documenting how to not fail postinst on service fails to start

> "Wouter" == Wouter Verhelst writes: Wouter> On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote: >> > > > - the service fails to start in the postinst. >> >> This implies that "the service is running" is part of "the >> service is configured", which is where

Bug#801065: Documenting how to not fail postinst on service fails to start

The TC bug is 904558. Busy with day job now.

Bug#801065: Documenting how to not fail postinst on service fails to start

> "Holger" == Holger Levsen writes: Holger> I do agree with that. I'm more against a general Holger> recommendation, depending on the circumstances, it's the Holger> right thing to do. My recollection is this came before the TC, but I'm blanking on the bug number. But it seems

Bug#801065: Documenting how to not fail postinst on service fails to start

> "Holger" == Holger Levsen writes: Holger> I don't think there has been consent on the issue, thus I'm Holger> tagging it moreinfo. My reading of the TC and debian-devel discussion was that this was at least a reasonable thing for maintainers to do, and whether it should be done

Bug#1029831: debian-policy: Make required packages build-essential

Ansgar> +--- | The required packages are called build-essential, and Ansgar> an informational | list can be found in Ansgar> /usr/share/doc/build-essential/list (which is | contained in Ansgar> the build-essential package). +---[ Section 4.2 ] Ansgar> to something like

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

> "Santiago" == Santiago Vila writes: Santiago> I think you can't really estimate such thing. You seem to Santiago> imply that we have been allowing packages with missing Santiago> build-dependencies for a long time, but that's not Santiago> accurate. The *buildds* have been

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

> "Santiago" == Santiago Vila writes: Santiago> A minimal build essential set provides and generates Santiago> useful information that a build essential set which is not Santiago> so minimal does not provide. Santiago> For example, some packages have unit tests which depend

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

> "Santiago" == Santiago Vila writes: Santiago> As an example, packages tzdata, mount or e2fsprogs are not Santiago> build-essential and afaik have not been for a long time, Santiago> but there are still people who believe that they are Santiago> build-essential for the mere

Re: Idea for Policy expert reviewer list

> "Russ" == Russ Allbery writes: Russ> What do people think? Helpful innovation, or just extra Russ> bookkeeping that isn't worth the effort? If people do think Russ> this is a good idea, I'll bring it up on debian-devel for Russ> further discussion (and then, if we adopted

Bug#970234: consider dropping "No hard links in source packages"

>>>>> "Russ" == Russ Allbery writes: Russ> Sam Hartman writes: >> I think that hard links in a source package are fine provided >> that breaking the hard links would not either break the build or >> provide an unreasonable

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

> "Bill" == Bill Allombert writes: Bill> What if the user change their CPU afterward ? This should Bill> probably be tested at boot time instead. There was a long thread on debian-devel about the potential issues with isa-support:

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

roucaries> No the problem is not probing the cpu/cpuinfo... Well, if the CPU info could be probed from shell, I'd argue that's better than unpacking a binary. roucaries> The problem is the base64 encoded binary. Why is this bad. I agree that it is esthetically displeasing, but *in

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

> "Bastien" == Bastien Roucariès writes: Bastien> I will like to stress that this kind of stuff is bad: Bastien> https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec- Bastien> support.preinst.in#L10 How would you do better in that instance? I think everyone

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

> "Holger" == Holger Levsen writes: Holger> On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote: >> > Even if that consensus does not exist, there is probably >> consensus > that native packages are a poor match for large >> packages (because of > the inefficiency

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

>>>>> "Sean" == Sean Whitton writes: Sean> On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote: >> Sean Whitton (2021-08-12): >>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote: >>> >>> >

Re: Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

> "Cyril" == Cyril Brulebois writes: Cyril> Hi, Felix Lechner (2021-07-26): Cyril> cc-ing debian-policy@ for some possible feedback. Cyril> I'm not sure why we should be spending time tracking down Cyril> Policy changes in (source for) udeb packages… so adding then

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

> "Sean" == Sean Whitton writes: Sean> Hello, Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote: >> To be clear, my understanding of the advocacy of using non-native >> packages is primarily about their impact on *Debian* workflows >> (being able to base

Bug#944920: Revise terminology used to specify requirements

> "Russ" == Russ Allbery writes: Russ> Russ Allbery writes: >> In attempting to revise recent GRs to use the same terminology as >> Policy, I got frustrated again by the lack of precision of our >> current language. This is an attempt to make a minor >> improvement. It

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

> "Russ" == Russ Allbery writes: Russ> Hi Sam, Russ> Thanks for the review! There's now a newer version of this Russ> diff adjusted for a flaw that Simon pointed out. It's Russ> sufficiently different from the original diff that I don't Russ> want to count seconds for

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

I do not support advising against using native packages with our current tooling. My issue is that for some work flows generating and keeping up with the upstream tarballs significantly increases the frustration of packaging and and brings doing a package update across a pain threshhold that

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

> "Russ" == Russ Allbery writes: Russ> Here is an updated diff that documents the most Russ> well-understood version conventions in the Debian archive. Russ> More could certainly be added; this is just a first start that Russ> addresses this specific bug. Russ> This

Bug#975250: clarify gathering together of copyright information

> "Bill" == Bill Allombert writes: Bill> Let us be honest with ourselves: what matter for most purpose Bill> is the position of the ftp-master team that processes the NEW Bill> queue. What policy says is secondary. I absolutely agree we should coordinate appropriately with the

Bug#975250: clarify gathering together of copyright information

> "Russ" == Russ Allbery writes: Russ> That said, I tend to be hyper-conservative and nit-picky about Russ> things like this, accurately representing copyright years Russ> isn't in my top thousand things I want people to work on in Russ> Debian, and I'm highly dubious that it

Bug#975250: clarify gathering together of copyright information

Here's my take on the discussion so far. And I want to stress that I am not a policy editor, and to the extent that they read the discusssion differently than I do, their reading controls. * Russ and I would be willing to accept either outcome--either you can collapse years or you cannot. *

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

> "Ansgar" == Ansgar writes: Ansgar> using other choices of "Rules-Requires-Root" than "no" and Ansgar> "binary-targets". The query [1] found two uses: Can you help me understand how options other than binary-targets or no were supposed to work/what they make possible? I have

Bug#975250: clarify gathering together of copyright information

I'd like to see people chime in who have not participated in the discussion yet. I prefer your original text but we'd need to get support for it. It sounds like we're fairly evenly split among the current participants in the issue. --Sam

Bug#975250: clarify gathering together of copyright information

> "Russ" == Russ Allbery writes: Russ> Marc Haber writes: Russ> The years are an annoying bit of pedantry. The short version Russ> is that US copyright law requires a year in the notice, and Russ> that year is supposed to represent a year in which a Russ> copyrightable

Bug#954794: New packages must not declare themselves Essential

> "Bill" == Bill Allombert writes: >> I'd propose that as a first step we change that to >> >> Packages are not required to declare any dependencies they have >> on other packages which are marked Essential (see below), but are >> permitted to do so even if they do not

Bug#970234: consider dropping "No hard links in source packages"

> "Bill" == Bill Allombert writes: Bill> I am pretty sure we were concerned about source packages being Bill> unpackable on non Debian systems, though. And I think we probably still are. I was trying to capture the concerns there in the part of my message you trimmed. My

Bug#970234: consider dropping "No hard links in source packages"

> "Giacomo" == Giacomo Catenazzi writes: Giacomo> The rationale was probably similar so symlinks: they may Giacomo> fail across different filesystems, and we supported to have Giacomo> e.g. / /usr /usr/share /usr/local /var (and various /var/*) Giacomo> /home /tmp /boot etc

Bug#954794: New packages must not declare themselves Essential

> "Josh" == Josh Triplett writes: Josh> Long-term, I'd like to see that happen. But I'm a huge fan of Josh> incremental steps; defining the problem as "eliminate Josh> Essential" makes it both difficult enough and controversial Josh> enough to make it unlikely to happen at

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable

I'm ignoring the case where capabilities are dropped in my analysis. I've long valued that Debian does not mark file paths as readonly and would not support this change. I've worked on other Unix distributions that did this, and I found that it decreased the quality of life of the sysadmin

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

I strongly agree with Ian in this matter. I think there are at least two cases where this issue comes up and is importand, 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

Bug#955005: Relax requirements to copy copyright notices into d/copyright

No, I missed this. We're on the same page.

Bug#954794: New packages must not declare themselves Essential

> "Bill" == Bill Allombert writes: Bill> But is it an actual problem ? Do we see packages marked Bill> Essential: yes by mistake ? I think Josh's analysis brought up some important points for me that I did not consider before and that need to be considered making decisions in the

Bug#954794: New packages must not declare themselves Essential

I concur with the comments raised so far. I think it would be great to do a better job of outlining the problems with essential packages in debian-policy. I don't understand why we would tie our hands though. A consensus of debian-devel seems adequate to consider those issues and evaluate them.

Bug#955005: Relax requirements to copy copyright notices into d/copyright

I think there is another use of debian/copyright beyond just documenting what ends up in the binaries. I think that if I read debian/copyright in a source package, I should expect to understand the licenses I need to comply with when dealing with the source package. So for example if the package

Bug#950994: Discourage package in contrib to install the real program via another package manager

I'll note there's another case where this could be valuable. If there is an installer in contrib, you can express dependencies on the package being available in Debian. Depending on how that installer works, you may not be able to express dependencies on the installed version in Debian. I think

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

> "Sean" == Sean Whitton writes: Sean> Encouragement is still normative, so if we're going to encourage it, Sean> it would be better to say /when/ it's encouraged and when it's not. I think it should be encouraged when there is not a good reason to do otherwise. I think the most

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

> "Russ" == Russ Allbery writes: Russ> Ah, hm, yes, that's a good point that I didn't notice when copying that Russ> Policy recommendation over from the recommendations on init scripts. Russ> The obvious concern here is that multiple packages could use the same Russ>

Bug#940144: developers-reference: document self-service givebacks in wanna-build section

> "Philipp" == Philipp Kern writes: Philipp> I'm told it was broken by the upgrade of Apache - apparently it can no Philipp> longer do per path client certificate authentication. There is a Philipp> pending RT ticket from DSA to fix that but I don't think there is Philipp>

Bug#948115: Revise init script Policy based on GR result

Russ said off-list he was ready for seconds. I second his patch with the status being encouraged rather than recommended change. In seconding, my primary review criteria was whether I thought the change accurately reflected what the GR conclusion was. --Sam signature.asc Description: PGP

Re: Guidance on solving the username namespacing problem

> "Philipp" == Philipp Kern writes: Philipp> I tried to raise this issue in [2] a year ago, but I think I don't know Philipp> how to even start drafting a policy snippet about this. Would it be Philipp> sufficient to just mandate "In order to avoid collisions with accounts

Bug#948115: Revise init script Policy based on GR result

I've reviewed your patch. It looks good. One minor suggestion: +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should +be supported by all init scripts. Supporting ``status`` is recommended but +not required. The ``reload`` and ``try-restart`` options are optional. How about

Bug#944920: Revise terminology used to specify requirements

Russ, I've reviewed your new patch. I haven't been participating in this discussion before, but I think it is fair to say that I have significant experience with these sorts of normative language discussions and Debian policy in general. I agree with all your changes (with one question below).

Re: Proposal for next steps for systemd-related policy

> "Sean" == Sean Whitton writes: Sean> Hello Russ, Sean> On Sun 29 Dec 2019 at 10:47am -08, Russ Allbery wrote: >> This is a tentative proposal for next steps from a Policy standpoint given >> the result of . I thought it >>

Bug#930666: Please document consensus on use of dh sequencer

My second still applies to the following diff; I agree this is consistent with the discussion so far. diff --git a/policy/ch-source.rst b/policy/ch-source.rst index ee9270d..93beb4a 100644 --- a/policy/ch-source.rst +++ b/policy/ch-source.rst @@ -259,13 +259,33 @@ files, sockets or setuid or

Bug#930666: Please document consensus on use of dh sequencer

I believe that both Russ's text and Sean's revised text capture the project level discussions. I also believe that given those discussions the issues are well understood enough for us to move forward relatively quickly if new issues are not raised here. I believe that Russ has adequately

Bug#930666: Please document consensus on use of dh sequencer

> "Sean" == Sean Whitton writes: Sean> Let me try to express what I think the problem is. What the Sean> first sentence says, given the equivalence of RECOMMENDED and Sean> SHOULD noted above, is "you should use dh unless there is a Sean> reason not to use dh". Sean>

Bug#930666: Please document consensus on use of dh sequencer

package: debian-policy Dear policy team: I just published a consensus call on a discussion we had to canvas the project on the use of Debhelper's dh sequencer. https://lists.debian.org/msgid-search/tslmuif7pwy@suchdamage.org I'd like to ask the policy editors to facilitate using the normal

Re: Thinking about Delegating Decisions about Policy

>>>>> "Sean" == Sean Whitton writes: Sean> Hello Sam, Sean> On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote: >> What are people's thoughts about this? >> >> Will this approach work for the TC and policy editors?

Re: Managing Frozen text when the TC Decides Policy

>>>>> "Sean" == Sean Whitton writes: Sean> Hello Sam, Sean> On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote: >> I agree that it would generally be unfortunate if we had policy >> text that could not be changed by the policy proce

Re: Bits from the DPL (April 2019)

> "Bill" == Bill Allombert writes: Bill> For package where upstream do not use the autotools, using dh Bill> can be quite inconvenient compared to plain debhelper. Bill> Cheers, -- Bill. I've started the discussion on debian-devel about whether we want to recommend/require dh.

Re: Bits from the DPL (April 2019)

>>>>> "Bill" == Bill Allombert writes: Bill> On Sun, May 12, 2019 at 08:36:16AM -0400, Sam Hartman wrote: >> >> Now given our community it's entirely possible that the question >> of whether it's a layering violation in our exi

Re: Bits from the DPL (April 2019)

>>>>> "Sean" == Sean Whitton writes: Sean> Hello, Sean> On Tue 30 Apr 2019 at 09:28AM -04, Sam Hartman wrote: >> I plan to start with the question of preferring dh as a package >> build tool. https://trends.debian.net/ has already ad

Managing Frozen text when the TC Decides Policy

I'm not really sure that the point you bring up is all that related to the question I was asking. But I think the point you bring up is important and I hope relatively easy to solve, so let's discuss it and try to solve it. > "Bill" == Bill Allombert writes: Bill> In my view it is

Thinking about Delegating Decisions about Policy

In my platform, one of the things I focused on is trying to drive the decision process forward. I imagine it won't be uncommon to get to a point where the right next step is to develop technical or non-technical policy about something. I'd like to focus in this message about what I as DPL do

Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful

package: debian-policy severity: normal Hi. As part of reviewing an issue for the technical committee, I just read policy section 9.3 in its entirety. Section 9.3.1 really seems to be showing its age. That section covers runlevels and the sequencing numbers after S and K in rc.d links without

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

> "Guillem" == Guillem Jover writes: >> I agree that it would be the easier way and I also tried building >> packages with patched GCC 5 setting PIE as default with success, >> but we have a CTTE decision which says that we should set >> hardening flags

Re: Bug#802501: init script failures during postinst and related scripts

> "Daniel" == Daniel Pocock writes: I agree. I think Henrique's advice is correct as far as it goes. However as a distribution, I think we should explicitly encourage people to consider the consequences on dist-upgrade and other operations. For some daemons, where the

Bug#707851: Debian Menu Systems : Implementation of the TC decision

>>>>> "Wouter" == Wouter Verhelst <w...@uter.be> writes: Wouter> On Tue, Oct 13, 2015 at 07:56:03AM -0400, Sam Hartman wrote: >> >>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes: >>

Re: Next update of the Policy ?

> "Bill" == Bill Allombert writes: Bill> On Sun, Oct 04, 2015 at 12:07:02AM +0200, Bill Allombert wrote: >> The GIT repository is only a tool for the policy editors. Due to >> the decentralized nature of GIT, anybody can clone it anyway and >> send a pull

Bug#707851: Debian Menu Systems : Implementation of the TC decision

> "Wouter" == Wouter Verhelst writes: Wouter> So, I'm with Guillem on this one. Wouter> But _forbidding_ maintainers who want to from shipping a Wouter> second file, if that somehow makes the experience of menu Wouter> users better than what the fdo menu

Bug#707851: Debian Menu Systems : Implementation of the TC decision

> "Didier" == Didier 'OdyX' Raboud writes: Didier> Le mardi, 13 octobre 2015, 08.55:07 Wouter Verhelst a écrit Didier> : >> But _forbidding_ maintainers who want to from shipping a second >> file, if that somehow makes the experience of menu users better

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

> "Marvin" == Marvin Renich writes: Marvin> As discussed on debian-devel starting at [1], I would like a Marvin> comment added to Section 6.4 "Best practices for maintainer Marvin> scripts" that recommends preventing the postinst script from Marvin> returning

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

> "Russ" == Russ Allbery writes: Yeah, but there's a significant factor that reduces things somewhat. In the past, /etc/init.d/foo failing would often cause postinst to break. However, in the past, there were a lot of failures that were not detected by the init.d script. We

Re: Next update of the Policy ?

> "Bill" == Bill Allombert writes: Bill> seems to have decided that the menu policy discussion Bill> should take precedence over over issues (multiarch, systemd, Bill> etc.) that are much more important. Hi. I do expect to see the part of the menu policy

Re: Bug#707851: Debian Menu Systems : Implementation of the TC decision

that sort of connection and growth. I am disappointed when I think about that. Sam hartman Debian Developer

Bug#792853: debian-policy: please disallow colons in upstream_version

>>>>> "Guillem" == Guillem Jover <guil...@debian.org> writes: Guillem> Hi! Guillem> On Mon, 2015-09-28 at 09:21:04 -0400, Sam Hartman wrote: >> >>>>> "Charles" == Charles Plessy <ple...@debian.org> writes:

Bug#792853: debian-policy: please disallow colons in upstream_version

> "Charles" == Charles Plessy writes: Charles> Le Thu, Sep 24, 2015 at 03:17:30PM +0200, Jakub Wilk a Charles> écrit : >> * Charles Plessy , 2015-09-24, 21:53: >- >> : ~ (full stop, plus, hyphen, colon, >+ >> : ~ (full stop, plus,

Bug#707851: Debian Menu Systems : Implementation of the TC decision

>>>>> "Charles" == Charles Plessy <ple...@debian.org> writes: Charles> Le Mon, Sep 21, 2015 at 11:27:53AM -0400, Sam Hartman a Charles> écrit : >> Hi. I've been debating how to respond to the shall vs must >> thing. The sho

  1   2   >