Re: Bug#401452: Standardize syntax of the name in the Maintainer control field

Hi! On Fri, 2025-06-13 at 19:12:54 +0200, Bill Allombert wrote: > Do you have a list of all tools and services that assume that Maintainer is a > single email address ? Before that, I consider any changes to be dangerous. Yes, changing this before every major parser has been updated, or at least

Processed: Re: Bug#1091868: debian-policy: Document Git-Tag-Tagger and Git-Tag-Info fields

Processing control commands: > tag -1 + pending Bug #1091868 [debian-policy] debian-policy: Document Git-Tag-Tagger and Git-Tag-Info fields Added tag(s) pending. -- 1091868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091868 Debian Bug Tracking System Contact ow...@bugs.debian.org with p

Processed: Re: Bug#1107137: Distinguish "native source packsge" from "native version number"

Processing control commands: > tags -1 patch Bug #1107137 [src:debian-policy] debian-policy: Assumed need to adapt to no longer meaningful nativeness concept Added tag(s) patch. -- 1107137: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107137 Debian Bug Tracking System Contact ow...@bugs.d

Re: Bug#1104854: binNMUs can cause ma-same violations in eg manpages

On Wed, 07 May 2025 at 13:48:19 +0100, Ian Jackson wrote: Rebuilds are arch-specific, so the binNMU number can vary across architectures, just as the bdate can: https://packages.debian.org/sid/libopts25-dev They can, but according to the rules applied by dpkg/apt for multiarch, instances of th

Re: Bug#1104643: Don't consider tests during build that can use internet if available as rc buggy

On Mon, May 05, 2025 at 11:19:09AM +0200, Bill Allombert wrote: Current policy text says: > Except for packages in the non-free archive with the Autobuild control field unset or set to no, > required targets must not attempt network access, except, via the loopback interface, > to services on th

Re: Bug#1103770: kitty: Does not accept -name command line option

Regarding the following, written by "Bill Allombert" on 2025-04-23 at 22:45 Uhr +0200: ...but you reported a bug that suggest some package were calling x-terminal-emulator with -name which is not supported ? My scripts all do. No package in Debian I know of. -- .''`. martin f. krafft : :'

Re: Bug#1103770: kitty: Does not accept -name command line option

On Wed, Apr 23, 2025 at 06:04:53PM +0200, martin f krafft wrote: > Regarding the following, written by "Simon McVittie" on 2025-04-23 at 16:46 > Uhr +0100: > > If the maintainers of kitty don't want to add a -name option, then I > > think this should be closed as "won't fix". Policy is clear about

Re: Bug#1103770: kitty: Does not accept -name command line option

Control: tags -1 wontfix Control: close -1 Thanks a lot Simon. I'm closing the bug as such then. Best, Nilesh

Re: Bug#1103770: kitty: Does not accept -name command line option

Regarding the following, written by "Simon McVittie" on 2025-04-23 at 16:46 Uhr +0100: If the maintainers of kitty don't want to add a -name option, then I think this should be closed as "won't fix". Policy is clear about the requirements for a terminal to be available via the x-terminal-emula

Re: Bug#1103770: kitty: Does not accept -name command line option

Some missing context here is the original bug report from martin f krafft: Unfortunately, Kitty does not accept the `-name` command-line option, and instead spews and error message. This is a problem when it is used as a drop-in to `x-terminal-emulator`, which sometimes gets passed the `-name`

Re: Bug#1103770: Does not accept -name command line option

On 23 April 2025 7:36:44 pm IST, martin f krafft wrote: >Regarding the following, written by "Nilesh Patra" on 2025-04-22 at 17:59 Uhr >+0530: >> As per upstream we need to use "xdg-terminal-exec". However, I could not >> find an alternative system by that name yet in Debian. > >To be honest, I

Re: Invalid sequences in https://www.debian.org/doc/debian-policy/policy.txt

On Sat, 12 Apr 2025 at 21:02:14 +0200, Jérémy Lal wrote: Le sam. 12 avr. 2025 à 13:27, Bill Allombert <[1]ballo...@debian.org> a écrit : On Fri, Apr 11, 2025 at 07:21:47PM -0700, pF arQon wrote: > I can't infer the cause from the end result, but the supposed-plain-text > document has nu

Re: Invalid sequences in https://www.debian.org/doc/debian-policy/policy.txt

Le sam. 12 avr. 2025 à 13:27, Bill Allombert a écrit : > On Fri, Apr 11, 2025 at 07:21:47PM -0700, pF arQon wrote: > > I can't infer the cause from the end result, but the supposed-plain-text > > document has numerous instances of Apple Quotes in it, which obviously > > aren't valid in either ASC

Re: Invalid sequences in https://www.debian.org/doc/debian-policy/policy.txt

On Fri, Apr 11, 2025 at 07:21:47PM -0700, pF arQon wrote: > I can't infer the cause from the end result, but the supposed-plain-text > document has numerous instances of Apple Quotes in it, which obviously > aren't valid in either ASCII or any other non-MBCS encoding. This includes > many forms of

Re: Invalid sequences in https://www.debian.org/doc/debian-policy/policy.txt

On Fri, Apr 11, 2025 at 7:52 PM Sean Whitton wrote: > I don't mind downgrading the plain text export to plain ASCII if someone > would like to provide a patch to configure Sphinx to do that, and also a > diff to prove that it doesn't spoil any examples anywhere. Spoilage risk is implicitly ~non

Re: Invalid sequences in https://www.debian.org/doc/debian-policy/policy.txt

Hello, A lot of us use the plain text version, but we open it in text editors which support Unicode. I don't mind downgrading the plain text export to plain ASCII if someone would like to provide a patch to configure Sphinx to do that, and also a diff to prove that it doesn't spoil any examples a

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

Some suggestions > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst > @@ -152,6 +152,8 @@ The fields in the binary package stanzas are: > > - :ref:`Package-Type ` > > +- :ref:`Build-Profiles ` > + > The syntax and semantics of the fields are described below. > > T

Re: Bug#749826: Documenting `Multi-Arch: foreign`

lear what is meant here > + > +``Multi-Arch: same`` > + > + > +Multiple binary packages with the same name and version may be installed > +concurrently if all of them carry this header valued ``same``. another "header"? do you just mean "if all o

Processed: Re: Bug#1100632: debian-policy: document subuids

Processing control commands: > tag -1 + pending Bug #1100632 [debian-policy] debian-policy: document subuids Added tag(s) pending. -- 1100632: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100632 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Hello, On Mon 03 Mar 2025 at 08:55pm +01, Niels Thykier wrote: > As for the RC'ness of this bug, I have downgraded the bug to normal as you > saw above. I am doing that since the Release Team are the final arbiter of > which bugs are release critical (and not Debian Policy). It's a little

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

On Mon, Mar 03, 2025 at 08:55:38PM +0100, Niels Thykier wrote: > Control: severity -1 normal > > When Guillem and I analyzed the numbers in November, we concluded we could > remove fakeroot from 10 000 packages while only having to fix about 250 > packages. That is, only 2.5% of the packages would

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Control: severity -1 normal Hi Thorsten As you can see, I have downgraded the bug to normal. I will come back to my reasons for that below, but I would like to start elsewhere first. Thorsten Glaser: > On Fri, 14 Feb 2025, Guillem Jover wrote: > [...] Yes, I know. I’m sorry for having a life

Re: Debian Policy 4.7.1.0 and program names

Chris Hofstaedtler wrote: > Nevertheless I think the generic text is a good idea. After all, > what good is having programs with the same name in /usr/bin and > /usr/games. Agreed. Program name conflicts are a problem, whether between /usr/bin and /usr/sbin, or between /usr/bin and /usr/games. >

Re: Debian Policy 4.7.1.0 and program names

Hi Sean, I'm not subscribed, so please Cc me in replies. On Tue, Feb 25, 2025 at 06:37:19PM +0800, Sean Whitton wrote: > On Thu 20 Feb 2025 at 11:13am +01, Vincent Lefevre wrote: > > > What about existing packages with the same program name? > > > > For instance, > > > > https://packages.debian.

Re: Debian Policy 4.7.1.0 and program names

Hi Sean, hi everyone! Am 25.02.25 um 13:43 schrieb Chris Hofstaedtler: Nevertheless I think the generic text is a good idea. After all, what good is having programs with the same name in /usr/bin and /usr/games. For completeness sake I want to mention that we discussed this issue on #debian-

Re: Debian Policy 4.7.1.0 and program names

* Bill Allombert [250225 14:26]: > On Tue, Feb 25, 2025 at 01:11:51PM +0100, Chris Hofstaedtler wrote: > > I would propose the following: > > > > 1) for trixie, recognise that this is not an RC bug or anything. > > > > 2) for forky, try to merge /usr/games into /usr/bin. > > What is the rationa

Re: Re: Debian Policy 4.7.1.0 and program names

On Tue, Feb 25, 2025 at 01:11:51PM +0100, Chris Hofstaedtler wrote: > Hi, > > > Thanks for the raising this, Vincent, and for the analysis, > > Michael. > > > It sounds like we might need an exception for /usr/games. > > I want to say that /usr/games was not on my radar when I suggested > the po

Re: Re: Debian Policy 4.7.1.0 and program names

On Tue, 25 Feb 2025 at 13:11:51 +0100, Chris Hofstaedtler wrote: > I think (again without having checked) FHS previously had a strong > opinion on /usr/games, but no longer does. In FHS 3.0, having > /usr/games is optional. This has been discussed previously (probably several times), including htt

Re: Debian Policy 4.7.1.0 and program names

[resending to everyone] Hi, * Sean Whitton [250225 13:15]: > Thanks for the raising this, Vincent, and for the analysis, > Michael. > It sounds like we might need an exception for /usr/games. I want to say that /usr/games was not on my radar when I suggested the policy change. I think (but did

+1 (Was: Re: Re: Debian Policy 4.7.1.0 and program names)

signature.asc Description: PGP signature

Re: Re: Debian Policy 4.7.1.0 and program names

Hi, > Thanks for the raising this, Vincent, and for the analysis, > Michael. > It sounds like we might need an exception for /usr/games. I want to say that /usr/games was not on my radar when I suggested the policy change. I think (but did not check the history now) that the initial point was le

Re: Debian Policy 4.7.1.0 and program names

[changing mailing list] Hello, On Thu 20 Feb 2025 at 11:13am +01, Vincent Lefevre wrote: > What about existing packages with the same program name? > > For instance, > > https://packages.debian.org/sid/amd64/lam4-dev/filelist has > /usr/bin/hcc > > and > > https://packages.debian.org/sid/amd64/u

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

On Fri, 14 Feb 2025, Guillem Jover wrote: >> >This bug does not count as RC just because Debian upload bureaucracy >> >hasn't been performed yet. >> >> If packagers cannot rely on Policy to give correct information, what >> *can* they rely on? > >This is not how Debian Policy has ever worked. By t

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

On Fri, 2025-02-14 at 01:02:26 +0100, Thorsten Glaser wrote: > On Fri, 14 Feb 2025, Sean Whitton wrote: > >Policy has to go through binary-NEW in order to be released. So there > > Technicalities. Not really, no. > >This bug does not count as RC just because Debian upload bureaucracy > >hasn't

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

On Fri, 14 Feb 2025, Sean Whitton wrote: >Policy has to go through binary-NEW in order to be released. So there Technicalities. >isn't a quick fix here. Not looking for one. dpkg should revert this until then. >This bug does not count as RC just because Debian upload bureaucracy >hasn't been

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Hello, On Thu 13 Feb 2025 at 11:57pm +01, Thorsten Glaser wrote: > severity 1095791 serious > thanks > > On Thu, 13 Feb 2025, Guillem Jover wrote: > >>> >From what I can tell from other mails, I believe the package in >>> question is openjdk-8 (unstable only); see bug #1095746. >> >>Ah, thanks fo

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

severity 1095791 serious thanks On Thu, 13 Feb 2025, Guillem Jover wrote: >> >From what I can tell from other mails, I believe the package in >> question is openjdk-8 (unstable only); see bug #1095746. > >Ah, thanks for the context. In that case, going by that bug report, it >looks like openjdk-8

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Hi Guillem, On Thu, Feb 13, 2025 at 10:50:39AM +0100, Guillem Jover wrote: > On Wed, 2025-02-12 at 04:16:29 +0100, Thorsten Glaser wrote: > > dpkg 1.22.13 implemented a backwards-incompatible change, > > violating Policy (which states the default value is most > > certainly *not* “no”) and breakin

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Hi! On Thu, 2025-02-13 at 12:34:52 +0100, Chris Hofstaedtler wrote: > On Thu, Feb 13, 2025 at 10:50:39AM +0100, Guillem Jover wrote: > > On Wed, 2025-02-12 at 04:16:29 +0100, Thorsten Glaser wrote: > > > dpkg 1.22.13 implemented a backwards-incompatible change, > > > violating Policy (which states

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

Control: severity -1 normal Hi! On Wed, 2025-02-12 at 04:16:29 +0100, Thorsten Glaser wrote: > Source: dpkg > Version: 1.22.13 > Severity: serious > Justification: Policy §5.6.31 > X-Debbugs-Cc: t...@mirbsd.de > dpkg 1.22.13 implemented a backwards-incompatible change, > violating Policy (which

Re: Bug#1095791: dpkg: incompatible and Policy-violating R³ default change breaks packages’ builds

On Wed, 12 Feb 2025 04:16:29 +0100 (CET) Thorsten Glaser wrote: Source: dpkg Version: 1.22.13 Severity: serious Justification: Policy §5.6.31 X-Debbugs-Cc: t...@mirbsd.de dpkg 1.22.13 implemented a backwards-incompatible change, violating Policy (which states the default value is most certainly

Processed: Re: Bug#1084924: Call for votes

Processing control commands: > reassign 1084924 debian-policy Bug #1084924 [tech-ctte] The system-log-daemon virtual package Bug reassigned from package 'tech-ctte' to 'debian-policy'. Ignoring request to alter found versions of bug #1084924 to the same values previously set Ignoring request to a

Re: Converting and unifying policy into a single formatting language?

Hello, On Sat 25 Jan 2025 at 06:52pm +01, Guillem Jover wrote: >> Hmm. Do we actually have any duplicate filenames? > > Not currently, but we'll do. For the documents that are currently > split in chapters on output, we'd have ch1, ch2, and index duplicates: > > $ dpkg -L debian-policy | grep

Re: Converting and unifying policy into a single formatting language?

Hi! On Sat, 2025-01-25 at 12:29:56 +, Sean Whitton wrote: > On Sat 25 Jan 2025 at 12:11pm +01, Guillem Jover wrote: > > This multitude of formatting languages has bothered me for a while, > > every time I take a peek at the sources. :) So this time around I > > pondered how hard could it be to

Re: Bug#1094145: debian-policy: Remove or significantly minimize manual page requirement

Jeremy Bícha writes: > The manpage does not really have useful content. as a user i both agree and disagree with this: i agree that documentation is not very good, but i disagree that nothing would be better than something. Even if people dont use man themselves, the man-page online is often the

Re: Converting and unifying policy into a single formatting language?

Hello, On Sat 25 Jan 2025 at 12:11pm +01, Guillem Jover wrote: > This multitude of formatting languages has bothered me for a while, > every time I take a peek at the sources. :) So this time around I > pondered how hard could it be to do that unification, and started > looking into this, which d

Processed: Re: Processed (with 1 error): Re: Bug#1093000: release-notes: mouseover over tables makes it hard to read

Processing commands for cont...@bugs.debian.org: > clone 1093000 -1 Bug #1093000 [release-notes] release-notes: mouseover over tables makes it hard to read Bug 1093000 cloned as bug 1093117 > reassign -1 src:developers-reference Bug #1093117 [release-notes] release-notes: mouseover over tables ma

Processed: Re: Bug#1089110: [PATCH] Document that packages cannot require man / info / locale files

Processing control commands: > tag -1 + pending Bug #1089110 [debian-policy] [PATCH] Document that packages cannot require man / info / locale files Added tag(s) pending. -- 1089110: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089110 Debian Bug Tracking System Contact ow...@bugs.debian.o

Re: Bug#1089110: [PATCH] Document that packages cannot require man / info / locale files

Sean Whitton wrote: > On Sat 07 Dec 2024 at 04:45pm -08, Josh Triplett wrote: > > Anecdata aside, one other way to evaluate this is to look at the type of > > files packages store under /usr/share/locale. > > > > A look at the Contents file gives a complete list of what types of files > > packages

Processed: Re: Bug#1088443: debian-policy: Recommend Debian package version format when upstream has no releases

Processing control commands: > reassign -1 src:developers-reference Bug #1088443 [debian-policy] debian-policy: Recommend Debian package version format when upstream has no releases Bug reassigned from package 'debian-policy' to 'src:developers-reference'. Ignoring request to alter found versions

Processed: Re: Bug#1088443: debian-policy: Recommend Debian package version format when upstream has no releases

Processing control commands: > reassign -1 developers-reference Bug #1088443 [src:developers-reference] debian-policy: Recommend Debian package version format when upstream has no releases Bug reassigned from package 'src:developers-reference' to 'developers-reference'. Ignoring request to alter

Re: Bug#1088443: debian-policy: Recommend Debian package version format when upstream has no releases

On Sun, Dec 01, 2024 at 09:44:17PM -0800, Otto Kekäläinen wrote: > My intent here was to suggest specifically that the version of form > 0.0~git20130606.b00ec39-1 would be elevated as the Policy recommended > form, as it makes sense and is already most popular. For the record, I assume it's most p

Processed: Re: Bug#1079967: should policy and dpkg agree on allowed versions?

Processing control commands: > reassign -1 debian-policy Bug #1079967 [dpkg-dev,debian-policy] should policy and dpkg agree on allowed versions? Bug reassigned from package 'dpkg-dev,debian-policy' to 'debian-policy'. Ignoring request to alter found versions of bug #1079967 to the same values pr

Re: Debian Technical Committee article

Hello, On Wed 14 Aug 2024 at 06:10am -07, Jake Edge wrote: > i am always loath to add a link into a quote, since we generally do not > speak that way :) That's a good thought, thanks! -- Sean Whitton signature.asc Description: PGP signature

Re: on the formal significance of vetoing something

On Wed, Aug 14, 2024 at 05:04:41PM +, Holger Levsen wrote: > hi & just for context, though my question is NOT about this case: > > On Wed, Aug 14, 2024 at 05:11:21PM +0200, Helmut Grohne wrote: > > [...] I note that if > > our proposed change #somebug to the Debian policy that has received six

Re: on the formal significance of vetoing something

On Wed, Aug 14, 2024 at 10:19:08AM -0700, Russ Allbery wrote: > > I wonder if such a veto has any formal effect? > It doesn't. [..] > > IOW, anyone can veto anything, but a veto as such has no power on its > > own, right? > > Correct. The Policy Editors are responsible for judging consensus. We

Re: on the formal significance of vetoing something

Holger Levsen writes: > hi & just for context, though my question is NOT about this case: > On Wed, Aug 14, 2024 at 05:11:21PM +0200, Helmut Grohne wrote: >> [...] I note that if our proposed change #somebug to the Debian policy >> that has received six seconds and one veto comes into effect >

Re: Debian Technical Committee article

Hi Sean, On 2024 Aug 14 at 12:41:51 +0800 Sean Whitton wrote: > Hello Jake et al., > > I am humbled by your excellent write-up of the TC talk at DebConf. [1] > Thank you! I am thinking we might add a link to the article to our > recruitment mail, especially with how effectively you discuss ho

Processed: Re: Bug#1078505: developers-reference: document corner case of debian version and rational

Processing commands for cont...@bugs.debian.org: > severity 1078505 wishlist Bug #1078505 [developers-reference] developers-reference: document corner case of debian version and rational Severity set to 'wishlist' from 'important' > thanks Stopping processing here. Please contact me if you need

Processed: Re: developers-reference: issue with sidebar in singlehtml variant on small screens

Processing control commands: > reassign -1 src:sphinx-rtd-theme Bug #1075914 [developers-reference] developers-reference: issue with sidebar in singlehtml variant on small screens Bug reassigned from package 'developers-reference' to 'src:sphinx-rtd-theme'. No longer marked as found in versions d

Processed: Re: Bug#1075914: Acknowledgement (developers-reference: issue with sidebar in singlehtml variant on small screens)

Processing control commands: > forwarded -1 https://github.com/readthedocs/sphinx_rtd_theme/issues/880 Bug #1075914 [developers-reference] developers-reference: issue with sidebar in singlehtml variant on small screens Set Bug forwarded-to-address to 'https://github.com/readthedocs/sphinx_rtd_th

Processed: Re: Bug#1074014: encode mandatory merged-/usr into policy

Processing control commands: > tags -1 + patch Bug #1074014 [debian-policy] encode mandatory merged-/usr into policy Added tag(s) patch. -- 1074014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074014 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Re: Bug#1074014: encode mandatory merged-/usr into policy

Control: tags -1 + patch Editors, if tagging + patch is not appropriate, my apologies. On Fri, Jun 21, 2024 at 08:27:56PM +0200, Helmut Grohne wrote: > For these reasons, I propose changing section 10.1 and encoding the > avoidance of symlink vs directory conflicts into policy. To get a > discuss

Processed: Re: Bug#1074083: create .../man/man/

Processing control commands: > reassign -1 debian-policy Bug #1074083 [man-db] create .../man/man/ Bug reassigned from package 'man-db' to 'debian-policy'. No longer marked as found in versions man-db/2.12.1-2. Ignoring request to alter fixed versions of bug #1074083 to the same values previously

Re: Why do we have both locales/ and policy/locale/ ?

gt; msgfmt --output=/dev/null --statistics $po > done > > vs > > for po in locales/ja/LC_MESSAGES/*.po; do > echo "== $po ==" > msgfmt --output=/dev/null --statistics $po > done > > In addition, re-running the above msgfmt with --check, and

Re: Why do we have both locales/ and policy/locale/ ?

ESSAGES/*.po; do echo "== $po ==" msgfmt --output=/dev/null --statistics $po done In addition, re-running the above msgfmt with --check, and also running «i18nspector **/*.po», both emit multiple things that could be fixed, or improved. Thanks, Guillem

Processed: Re: Bug#1069934: 4.9.2. The dak ls utility should mention rmadison

Processing control commands: > severity -1 wishlist Bug #1069934 [developers-reference] 4.9.2. The dak ls utility should mention rmadison Severity set to 'wishlist' from 'normal' -- 1069934: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069934 Debian Bug Tracking System Contact ow...@bugs.

Re: single-page html of debian-policy to be revived?

On Sat, Apr 27, 2024 at 10:15:19AM +0100, Sean Whitton wrote: > Hello, > > On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote: > > > On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > >> ... but if dev-ref is already shipping both, maybe singlepage is indeed > >> usable these day

Re: single-page html of debian-policy to be revived?

Hello, On Mon 15 Apr 2024 at 09:59am GMT, Holger Levsen wrote: > On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: >> ... but if dev-ref is already shipping both, maybe singlepage is indeed >> usable these days ... > > I think it is. > >> > Could the Policy Editors team check, if ever

Processed: Re: base-files: /var/run and /var/lock should not be absolute symlinks

Processing commands for cont...@bugs.debian.org: > reassign 1039979 debian-policy Bug #1039979 [base-files] base-files: /var/run and /var/lock should not be absolute symlinks Bug reassigned from package 'base-files' to 'debian-policy'. No longer marked as found in versions base-files/12.4 and ba

Re: base-files: /var/run and /var/lock should not be absolute symlinks

reassign 1039979 debian-policy thanks Dear Policy editors: In this bug I'm asked to make /var/run and /var/lock symlinks to be relative. Maybe it's the right thing to do, but last time I tried to do that, this is what happened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345 [ Summar

Re: single-page html of debian-policy to be revived?

On Sun, Apr 14, 2024 at 08:43:51PM +0800, Sean Whitton wrote: > ... but if dev-ref is already shipping both, maybe singlepage is indeed > usable these days ... I think it is. > > Could the Policy Editors team check, if everything is fine now, and if > > this should be published again? > > At lea

Re: single-page html of debian-policy to be revived?

Hello, On Sun 14 Apr 2024 at 01:57pm +02, Holger Wansing wrote: > 1. > Currently, the package does not ship this version. So this would have to > be re-added there. The changelog for 4.2.0.0 says * Stop installing policy-1.html because Sphinx's singlehtml output is too bu

Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

Hello, On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote: > On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: >> A single page html may be an additional option but there's already the >> single page txt version and the PDF. That's sufficient and I see no >> need in providing more

Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote: > A single page html may be an additional option but there's already the > single page txt version and the PDF. That's sufficient and I see no > need in providing more formats of this manual. > > Therefore we can close this and I will c

Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

Currently we have a working solution using js and providing multi page html. That's a good solution which is already available. > I did not go deeper into this scenario, I just found > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877337 > which includes a forward-backword-forwar

Re: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

Hi, Bill Allombert wrote (Wed, 10 Apr 2024 22:24:20 +0200): > On Wed, Apr 10, 2024 at 09:33:50PM +0200, Holger Wansing wrote: > > Hello www team and debian-policy editor team, > > > > Note: apparently we have no alternative beside js, if we want full-text > > search for html output (single-pag

Re: Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

> On Wed, 10 Apr 2024 21:33:50 +0200, Holger Wansing > said: > The second javascript functionality is the full-text search. > Please note, that I made use of javascript by intend, despite of this bug > requesting to remove all js functionality. Hi holger, in the past we

Re: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors

Hello www team and debian-policy editor team, in-line with activating the new html theme on our website I also worked on the javascript front: to make the html theme work on small screens (smartphones) the readthedocs.org theme relies on javascript functionality, to display a sidebar with the ta

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

Hello, On Tue 02 Apr 2024 at 04:18pm +01, Josh Triplett wrote: > Sean Whitton wrote: >> On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote: >> > 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 he

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

Josh Triplett writes: > Nonetheless, if the Policy editors are opposed to documenting something > despite it being collectively known to be the case, and do not feel that > any possible wording change would change that position, then I will not > push for it further. I have already suggested a w

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

Sean Whitton wrote: > On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote: > > 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." > > This was basically my concern.

Re: Move "ITP" from Wiki into the Dev Ref

Dear Andrey, you make it hard. On 2024-03-29 16:16 Andrey Rakhmatullin wrote: > Can you please open it? It's a devref section about ITP. I know. I opened it. What I need is the opinion or better a decision and an action of an experience Debian person if the TODO ("! this page should be merged

Re: Move "ITP" from Wiki into the Dev Ref

Dear Andrey, thanks for the reply. What is the answer? It was just a link. Kind Christian On 2024-03-29 15:05 Andrey Rakhmatullin wrote: > On Fri, Mar 29, 2024 at 09:34:27AM +, c.bu...@posteo.jp wrote: > > Dear Team, > > > > My apologize for contacting you this way. I couldn't find an > >

Re: Move "ITP" from Wiki into the Dev Ref

On Fri, Mar 29, 2024 at 11:14:27AM +, c.bu...@posteo.jp wrote: > Dear Andrey, > > thanks for the reply. What is the answer? It was just a link. Can you please open it? It's a devref section about ITP. > On 2024-03-29 15:05 Andrey Rakhmatullin wrote: > > On Fri, Mar 29, 2024 at 09:34:27AM +0

Re: Move "ITP" from Wiki into the Dev Ref

On Fri, Mar 29, 2024 at 09:34:27AM +, c.bu...@posteo.jp wrote: > Dear Team, > > My apologize for contacting you this way. I couldn't find an > appropriate mailing list. > > I would like to point you to an wiki related bug ticket in context of > your Developers Reference. > >

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

Sean Whitton wrote: > On Sun 17 Sep 2023 at 10:52am -07, Russ Allbery wrote: > > So far as I can tell, the only important part is that the directory > > be registered in tmpfiles.d (or a service unit) so that it can be > > recreated when needed. > > Something which I don't think has been mentioned

Processed: Re: Bug#915583: about html_static_path

Processing control commands: > tag -1 + pending Bug #915583 [debian-policy] debian-policy: More attractive sphinx theme, please Added tag(s) pending. -- 915583: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915583 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#968226: Move documentation of Build-Depends alternative selection out of footnote

Processing control commands: > tag -1 + pending Bug #968226 [debian-policy] Move documentation of Build-Depends alternative selection out of footnote Added tag(s) pending. -- 968226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968226 Debian Bug Tracking System Contact ow...@bugs.debian.or

Processed: Re: Bug#1058589: developers-reference: please mention urgency=critical/emergency for completeness

Processing control commands: > reopen -1 Bug #1058589 {Done: Holger Levsen } [src:developers-reference] developers-reference: please mention urgency=critical/emergency for completeness Bug reopened Ignoring request to alter fixed versions of bug #1058589 to the same values previously set > reas

Processed: Re: Bug#1053305 Fw: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ examples suffer escape damage

Processing control commands: > tags -1 + patch Bug #1053305 [debian-policy] Fw: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ examples suffer escape damage Added tag(s) patch. -- 1053305: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053305 Debian Bug Tracking System

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

On Sun, 17 Sep 2023 at 02:03:52 +0200, Santiago Vila wrote: > If the files are intended to be modified "in place" by the > system admin, we call them configuration files (and we try hard > to put them in /etc). If they are not intended to be modified by > the system admin, we don't call them config

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

On Sun, Sep 17, 2023 at 12:12:18AM +0200, Daniel Gröber wrote: > Sam, Russ, Bill, > > Thanks for your input. To be quite frank I still don't see how the > interpretation of allowing configuration files outside of /etc can be > supported based on the policy text. > > Ultimately I'm just concerned

Re: Bug#915583: debian sphinx styling: second attempt

RL writes: > http://stephane.yaal.fr/tmp/release-notes/issues.html#grub-no-longer-runs-os-prober-by-default > the '# dpkg-reconfigure ' is shown as a shell-comment, but is > meant to be a command-to-run-as-root (i remember this being discussed on > the previous version on the release-notes list,

Re: Bug#915583: debian sphinx styling: second attempt

Stéphane Blondon writes: > - for (draft sphinx) release-notes: > http://stephane.yaal.fr/tmp/release-notes/ > > What do you think about it? commenting on the release-notes, but i expect applies to policy too: looks awesome - imo it is now even better-looking than the docbook verison in the t

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

El 17/9/23 a las 0:12, Daniel Gröber escribió: Sam, Russ, Bill, Thanks for your input. To be quite frank I still don't see how the interpretation of allowing configuration files outside of /etc can be supported based on the policy text. Hello. I apologize for not having read the discussion in

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

Daniel Gröber writes: > Ultimately I'm just concerned about the UX aspects of admins suddenly > having to go hunting for config files all over their system when > packages start implementing this config-in-/usr business en mass. I think the expectation is that you read the documentation of the p

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

Sam, Russ, Bill, Thanks for your input. To be quite frank I still don't see how the interpretation of allowing configuration files outside of /etc can be supported based on the policy text. Ultimately I'm just concerned about the UX aspects of admins suddenly having to go hunting for config files

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

Processing control commands: > unblock 1051371 by 1050001 Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters 1051371 was not blocked by any bugs. 1051371 was not blocking any bugs. Removed blocking bug(s) of 1051371: 1050001 -- 1051371: https://bugs.debian.org/cgi-bin/bug

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

Processing control commands: > unblock 1051371 by 1050001 Bug #1051371 [debian-policy] Post-/usr-merge paths for script interpreters 1051371 was blocked by: 1050001 1051371 was not blocking any bugs. Removed blocking bug(s) of 1051371: 1050001 -- 1050001: https://bugs.debian.org/cgi-bin/bugrepor

  1   2   3   4   5   6   7   8   9   10   >