Bug#651035: please decide how terminals should report Alt+letter combinations

Russ Allbery wrote: > Jonathan Nieder writes: >> 1. Applications should all behave the same way wrt handling of the >> Meta key in terminals. Advertising the smm capability makes that >> basically impossible. > > Basically, I'm dubious the ga

Bug#651035: please decide how terminals should report Alt+letter combinations

Russ Allbery wrote: > Note that I'm not arguing against changing things in xterm, particularly > in conjunction with upstream. Just that I'm not sure it's worth writing a > policy about this, rather than making decisions specifically about the > xterm package to make it work better, better serve

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Charles Plessy wrote: > I would like to re-frame the discussion and remind that [...] > In the case of the (L)GPL, it is common practice to use the license notices as > found in headers of files as if they were the actual license text. For what it's worth, I disagree, while I agree with Ximin Luo

Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.

Hi, I wrote: > You didn't introduce it, but I think the phrase starting with > "similarly to" here is problematic, since it makes the spec harder for > people outside Debian to understand and use, without adding much > clarity to compensate for that. Could we remove it? [... and another wording

Bug#462996: About FTP Masters requirements for Debian copyright files.

Charles Plessy wrote: > Some licenses include a template for “notices” (GPL), “exhibits” (MPL), etc., > also called “headers” or “boilerplates”. [...] > More in details, one of the questions was to know if > the reason for reproducing them is to include the disclaimer of wa

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Ximin Luo wrote: > On 12/12/11 01:19, Jonathan Nieder wrote: >> Perhaps a source of confusion is something Joerg wrote five years >> ago[1]: [...] >> I continue to believe that what he meant is that such pre-made license >> headers are good at covering their bases

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Steve Langasek wrote: > I disagree strongly. The cost of giving maintainers *different* ways to > represent the license status is much higher than the cost of requiring > maintainers to separately reproduce license headers for components that are > GPL-2 licensed vs. GPL-2+. Reading this in the

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Steve Langasek wrote: > I think this is perfectly valid: > > Files: * > Copyright: The Man in the Moon, 2007 > License: GPL-2+ with OpenSSL exception > > License: GPL-2+ with OpenSSL exception > This program is free software [...] as a special exception, [...] > On Debian systems, [...] > > Perh

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Ximin Luo wrote: > the current DEP5 supports this and has it as an explicit example. Relevant wording: Section "Paragraphs", subsection "Stand-alone License Paragraph" says: Where a set of files are dual (tri, etc) licensed, or when the same license occurs multiple times, you ca

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Ximin Luo wrote: > OK, understood. I will take a look at creating a patch for > copyright-format.xml > like you did. However, I think I would prefer using an explicit grammar > instead > (e.g. the sort that programming language specifications use), because that > leads to clearer thinking and le

Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

Russ Allbery wrote: > I propose the attached patch to address all of those issues. Seconds or > further discussion? Looks good to me. (Well, one nit: the log message says custom environment variables (not, say, PATH) where I think the intent is something like custom environme

Bug#621050: Document dependencies needed to use multiarch paths

Russ Allbery wrote: > Could you prepare an updated patch? Here's one. --- policy.sgml |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/policy.sgml b/policy.sgml index 4aeae363..0ca925e0 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6214,6 +6214,14 @@ install -m644

Bug#648271: [debian-policy] 11.8.3 "Packages providing a terminal emulator" says xterm passes -e option straight to exec

Filipus Klutiero wrote: > Le 2011-12-24 19:16, Russ Allbery a écrit : >> x-terminal-emulator -e vi 'some file' >> >> and know that it works. If you don't use exec, it won't. > > I don't see why exec would be necessary. As long as the emulator supports > being given any simple command as its -

Bug#106073: recommend to install documentation into /usr/share/doc//

Hi, Russ Allbery wrote: > * Some reorganization and wording tweaks to hopefully make things clearer. Alas, there's a lot of this --- enough that I wish this had been prepared as a multiple-patch series, with for example whitespace-only changes split out. Oh, well. Onward. :) [...] > --- a/pol

Bug#654958: debian-policy: Document VCS fields.

Hi Charles, Charles Plessy wrote: > + > + Vcs-arch, Vcs-bzr (Bazaar), Vcs-cvs, > + Vcs-darcs, Vcs-git, Vcs-hg > + (Mercurial), Vcs-mtn (Monotone), Vcs-svn > + (Subversion) > + > + > + > + S

Bug#654958: debian-policy: Document VCS fields.

Russ Allbery wrote: > Also, for a Git repository, what do you do if the Debian packaging isn't > on the master branch? For example, for packages for which I'm also > upstream, I do upstream development on the master branch and Debian > packaging on a separate debian branch. I wonder if something

Bug#654958: debian-policy: Document VCS fields.

Russ Allbery wrote: > Maybe we should just > document them as they are and be explicit about the limitations, saying > things like: > > The information in the Vcs-* header should be sufficient to locate the > repository used for packaging and

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

Russ Allbery wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -3211,6 +3211,40 @@ Package: libc6 [...] > + upstream_version or debian_verison > + numbers ending in +nmu followed by a number > + indicate an NMU. Either this convention or the convention > +

Bug#654958: debian-policy: Document VCS fields.

Charles Plessy wrote: > For Git, as discussed in this thread, it is not possible to specify the branch > in the URL. I hope that it will be possible one day Git URLs deliberately represent a repository, not a branch. That is because branches and repositories for a package are simply different n

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

Russ Allbery wrote: > I updated this some more (mostly by adding back in the language > that Charles had originally to be clearer; he understood the issue better > than I did!). Looks good to me. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "un

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

Russ Allbery wrote: > A scheme that would always satisfy this would be to use + > for stable/security updates where is the Debian version being > targeted similar to how that's done for backports (so 50 for lenny or 60 > for squeeze), and is some letter between b and n. (Alternately, > we could

Bug#654958: debian-policy: Document VCS fields.

Steve Langasek wrote: > Yes. By the nature of svn, the Vcs-Svn URI always unambiguously refers to a > single branch ("trunk" is a branch). FWIW, I would be happy to see at least that documented. (It would provide a reason to propose this change in the eglibc package. :)) -- To UNSUBSCRIBE,

Bug#595652: please clarify how packages configuring a db should behave if no db is available

Hi, Holger Levsen wrote: > Hi, > > any news on how to solve this issue? > > Anything I could do? Sure. Could you give a summary of the discussion, what options we should be choosing among in clarifying or changing policy, and the advantages or disadvantages of each option? Thanks much for your

Bug#628515: recommending verbose build logs

Russ Allbery wrote: > What should we do about cases where the upstream build system makes it > difficult to override the verbosity? In other words, is this a place > where we should push Debian package maintainers to actually fix the > upstream build system to make build logs verbose even if upst

Bug#656569: debian-policy: Mandorary Testsuite or Demo requirement for all Libraries.

Hi, Off-topic, but in hope of chiseling away at the problem to make what remains a little simpler: oiaohm wrote: > Yes libogre contains quite a decent > testsuite that basically is not provided even in the source debs due to > license > issue blocking i

Bug#656595: debian-policy: Mandatory provide of testsuites or demos for libraries

merge 656595 656569 quit Hi again, ohm wrote: > [Subject: debian-policy: Mandatory provide of testsuites or demos for > libraries] You already reported this. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@list

Re: multiarch standard path

Hi Bill, Bill Allombert wrote: > When multiarch was introduced, it was implied that a tool to query the > multiarch would be standardised. However unless I missed need, no such > tool exist yet. This is problematic when building older version of software. > with legacy build systems that needs t

Bug#656998: gcc --help: please document the -print-multiarch option

Package: gcc-4.7 Version: 4.7-20120112-1 Severity: important Tags: patch Hi Matthias, Bill Allombert wrote: > On Fri, Jan 20, 2012 at 03:45:34PM -0600, Jonathan Nieder wrote: >> I believe "gcc -print-multiarch" is supposed to do that. >> >> $ gcc -m32 -pri

Bug#658009: debian-policy: dpkg-buildpackage -rroot-command out of date

Sam Morris wrote: > C.1.2 says: > > If no root-command is supplied then dpkg-buildpackage will take > no special action to gain root privilege, so that for most > packages it will have to be invoked as root to start with. > > This is wrong according to the dpkg-buildpackage man p

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

Hi, Charles Plessy wrote: > since §4.9.1's object is to document the DEB_BUILD_OPTIONS, I would find it a > bit dry to only provide an example that works through a tool that is not > mentionned or explained anywhere else in the Policy (see > http://bugs.debian.org/578597). > I therfore propose t

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Hi Charles, Charles Plessy wrote: > For other points, for instance that stand-alone license sections can also > accept short names accompanied by their license exception, a clarification > would not hurt; but I do not consider this a blocking problem. I believe this should be a blocker --- it is

Bug#648387: [copyright-format] English proofreading.

Hi Charles, Charles Plessy wrote: > here is an update of the English proofreading (attached as a patch). Looks good to me. [...] > - "Another kind of list value has one value per line". Not > straightforward... Doesn't seem so bad. How would you propose rewording it? > - "the Copyright f

Bug#648387: [copyright-format] English proofreading.

Justin B Rye wrote: >> Charles Plessy wrote: >>> - "Another kind of list value has one value per line". Not >>> straightforward... [...] > Shouldn't it be "Another type of list has one value per line"? The > values don't have one value per line - they only have one line each. Makes sense. I

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Charles Plessy wrote: > would the following changes solve the problem with license exceptions ? Here's some tweaks for application on top. With these tweaks, I'm happy with it. copyright-format/copyright-format.xml | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff -

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Charles Plessy wrote: > Le Wed, Feb 08, 2012 at 06:15:55PM -0600, Jonathan Nieder a écrit : >> >> Remaining lines: if left blank here, the file >> -must include one or more> +must include a > linkend="stand-alone-licens

Re: DEP-5: Updates from a general editing pass

Hi Russ, Thanks very much for an overall pleasant policy release. Only nitpicks below. Russ Allbery wrote: > +++ b/copyright-format/copyright-format.xml [...] > @@ -81,9 +84,9 @@ >no way to know how much of Debian should be stripped from such a > system. > > > - Even w

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -7188,6 +7188,74 @@ Reloading description configuration...done. [...] > + > +Because packages shipping upstart jobs may be installed on > +systems that are not using upstart, maintainer scripts mus

Bug#490604: debian-policy: please don't state that scripts working under dash are 'probably' policy-compliant

Russ Allbery wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -7968,10 +7968,12 @@ fname () { [...] > - as its interpreter. If your script works with dash > - (originally called ash), it probably complies with > - the above requirements, but if you are in doubt, use > -

Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files

Russ Allbery wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -6169,11 +6169,11 @@ install -m644 debian/shlibs.package > debian/package/DEBIAN/ > File System Structure > > > - The location of all installed files and directories must > - comply with the Filesy

Re: DEP-5: Updates from a general editing pass

Russ Allbery wrote: > Here's the patch I applied. Looks good. Thanks. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227094548.GG10740@burratino

Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files

Russ Allbery wrote: > I guess the concern is that you feel this language implies that packages > aren't allowed to support non-FHS configuration? Would this be better? > > The location of all files and directories must comply with the > Filesystem Hierarchy Standard (FHS), ver

Bug#638060: debian-policy: §9.1.1: FHS should also be a "must" for generated files

Russ Allbery wrote: > Jonathan Nieder writes: >> Russ Allbery wrote: >>> I guess the concern is that you feel this language implies that packages >>> aren't allowed to support non-FHS configuration? Would this be better? >>> >>> The loca

Bug#490604: debian-policy: please don't state that scripts working under dash are 'probably' policy-compliant

Russ Allbery wrote: > I think checkbashisms and posh are an improvement over just suggesting > bash (and checkbashisms, in particular, is much easier to use), so my > inclination is to stick with the new wording and leave the further details > for other tools. I assume by 'bash' you mean 'dash' a

Bug#661816: debian-policy: Do not call update-mime directly, since it is triggered by Dpkg.

Hi Charles, Charles Plessy wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -7378,24 +7378,10 @@ Reloading description configuration...done. > The mime-support package provides the > update-mime program which allows packages to > register programs that can show, compose

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Hi Michael, Michael Biebl wrote: > As I've already mentioned before, I don't like the approach, that any > init script should use something like: > >> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart >> then >> exit 1 >> fi > > It seems much more sensible to me, to m

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Russ Allbery wrote: > This probably should already be a Policy violation, saying that they > should use invoke-rc.d instead. Is there any drawback to them using > invoke-rc.d? Yes, I think there is a drawback. Forgetting about upstart and systemd for the moment, if I use "/etc/init.d/ start" or

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

reload daemon configuration Example for context: http://bugs.debian.org/445203#50 Which points to: http://bugs.debian.org/588085 > Jonathan Nieder writes: >> Another downside is that invoke-rc.d is Debian-specific. > > So are the network hooks under discussion. I thin

Bug#571776: document symbols

Russ Allbery wrote: > I'm therefore including here the complete > SGML source of that section not in diff format, followed by the diff of > everything *outside* of that section. I think this will be easier to > review. Thanks! I would have preferred a diff since it

Bug#571776: document symbols

Julien Cristau wrote: > On Mon, Mar 19, 2012 at 17:26:04 -0500, Jonathan Nieder wrote: >> What about libraries like glib (assuming one only uses old symbols) >> that are never supposed to change soname? > > What about them? I wanted to make sure that forbidding hard-coded de

Bug#663930: debian-policy: New virtual package for naming spec compliant icon themes

Fernando Lemos wrote: > It's been 15 days, though, and nobody reacted to the initial message > posted to debian-devel... Should I try to "bump" the debian-devel > discussion, or can we safely assume nobody objects to the proposal? Based on the discussion on debian-desktop, I think there is a cons

Bug#491318: init scripts "should" support start/stop/restart/force-reload - why not "must"? (Re: ditto)

Hi, Josip Rodin wrote: > I also think this "should" might as well be changed into a "must" these > days, because the ambiguity is allowing corner cases - I recently heard that > mcollective doesn't support a "restart" action, rather it does "stop" then > "start" when you tell it to restart someth

Re: multiarch tuples are not documented/defined

reassign 664257 debian-policy 3.9.3.1 affects 664257 = tags 664257 = upstream quit Goswin von Brederlow wrote: > It is a bug in Debian: The multiarch tuples are not documented/defined > in Debian. Fine, reassigning to policy. Never say I didn't do anything for you... :) Policy maintainers, see

Bug#664257: multiarch tuples are not documented/defined

Hi Russ et al, The patch below documents the Architecture field. It doesn't cover architecture tuples yet, but presumably once the description of architectures is in good shape it would not be hard to add a mapping from Debian arches to pathnames to section 9.1.5. Some concerns: - what should

Bug#664257: multiarch tuples are not documented/defined

Goswin von Brederlow wrote: > Clearly I'm not the person to convince others to add multiarch tupples > to their specs. I don't see why or why not. But it isn't really about convincing --- I'd be hard pressed to find someone who _doesn't_ want this stuff documented better. -- To UNSUBSCRIBE,

Request for policy interpretation: procedure and possible outcomes for naming conflicts

Hi policy editors, In the discussion at [1], Pat wrote to the DPL asking for some mediation in figuring out what should happen to the "node" command name. No one has offered that mediation (the ctte presumably could do it if asked) but I mentioned that there seems to have been some uncertainty ab

Re: Request for policy interpretation: procedure and possible outcomes for naming conflicts

Bill Allombert wrote: > On Wed, May 02, 2012 at 02:12:22PM -0500, Jonathan Nieder wrote: >> Policy also states that different packages must not install commands >> with different functionality with the same name. > > Such packages would have to Conflicts anyway, and

Re: Request for policy interpretation: procedure and possible outcomes for naming conflicts

Russ Allbery wrote: > I don't know what to say to this, since this question seems exceedingly > strange to me. The way we maintain Policy is by consensus, so if a > consensus develops around a solution, the answer is obviously yes? Or, > perhaps, the answer is obviously no since the same consens

Bug#671507: debian-policy: policy section 7.4 conflicts with section 10.1

Carsten Hey wrote: > * Patrick Ouellette [2012-05-04 13:38 -0400]: >> If you read the entire section 7.4 is seems entirely reasonable to >> create a package with an executable name that already exists in Debian >> with a package conflicts tag if the two executables have different >> functionality.

Bug#671503: APT repository format is not documented

Michal Suchanek wrote: > The sources.list is *the* file that specifies where to look for > repositories, even for non-apt clients. dselect uses a different format for /var/lib/dpkg/cmethopt and /var/lib/dpkg//*. Most of the other non-apt package managers I know are apt clones. If I remember cor

Bug#676561: debian-policy: Please clarify important restriction on use of /run

Hi Roger, Roger Leigh wrote: > It's come to my attention that some developers are using /run > without a versioned initscripts dependency, which will break > upgrades from squeeze. Thanks. This requirement does seem worth documenting. [...] > --- a/policy.sgml > +++ b/policy.sgml > @@ -6281,6

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

Charles Plessy wrote: > My personal opinion is that it is best to focus the Debian copyright file > on the goal of respecting licenses and the copyright law, and to leave > to the upstream documentation the difficult task of stating who is author > and who is not. Just like naming the location fr

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

Charles Plessy wrote: > Nevertheless, listing the original authors does not give an accurate > information about who currently develops a program, and who to contact. If "original" means "upstream of Debian" (i.e., "where does this code originate from?"), then it gives exactly that. As you might

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

Russ Allbery wrote: > Would one list bug-gnu-ut...@gnu.org? That's the most useful contact > point (and we have a copyright-format field for that), but it's not in any > real sense the "author." Sure it is --- it's the contact point for the people who create the code that goes into the upstream

Bug#654958: debian-policy: Document VCS fields.

Hi Charles, Charles Plessy wrote: > Would the following patch be acceptable now ? Getting a lot closer. Some questions: [...] > +++ b/policy.sgml [...] > @@ -3737,6 +3739,42 @@ Checksums-Sha256: > details. > > > + > + > + Version Control System (VCS) fields

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

Russ Allbery wrote: > Policy 12.5 says: > > In addition, the copyright file must say where the upstream sources > (if any) were obtained, and should name the original authors. > > The last part is not at all clear. Prior to a recent conversation on > debian-mentors, I had always assumed t

Bug#678607: debian-policy: "original authors" in 12.5 is unclear

Bart Martens wrote: > Some readers may argue that an "upstream contact" may not be an "author" if > he/she maintains the upstream software only by accepting patches created by > others. If so, won't that be a problem everywhere else in policy that refers to upstream authors? For example in secti

Streamlining the policy process

Hi Russ, Russ Allbery wrote[1]: > Every time I've tried to streamline the process, someone equally upset > rips me a new one for changing the Policy rules without consulting the > project sufficiently. The last time I raised the topic[2], I was told that what is stalling most policy bugs is a la

Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general

Hi, In July, 2008, Raphael Geissert wrote: > As demonstrated by the following trivia[1], and also mentioned by SUSv3, the > echo built-in varies from implementation to implementation and thus should be > discouraged. [...] > + o='Foo:\n\tI do not like bar!!\n\nBar:\n\tI do not like you either'

Bug#486453: Policy 8.2 suggests libraryname-tools, but not libraryname-utils

Hi, Policy says: > Run-time support programs that use the shared library but are not > required for the library to function or files used by the shared > library that can be used by any version of the shared library > package should instead be put in a separate package. This package > might typic

Bug#452393: [PROPOSAL] clarify overstep between "required" and "important" priorities

Hi Robert, In 2007, Robert Millan wrote: > In the definition of priorities, "required" and "important" seem to collide > with each other. In particular, the part of "required" that reads: > > "Packages which are necessary for the proper functioning of the system" > > with the part of "importan

Bug#654958: debian-policy: Document VCS fields.

Charles Plessy wrote: > Would the following patch be acceptable now ? My feedback got no replies, so I can only assume that everyone was so awestruck by the suggestions that they were lost for words. Here's an updated patch. Improvements welcome. Looking forward to your thoughts, Jonathan From

Bug#648271: [debian-policy] 11.8.3 "Packages providing a terminal emulator" says xterm passes -e option straight to exec

Hi terminal emulator authors (in bcc), There is a policy proposal to clarify what x-terminal-emulator -e does when there is one argument and when there are many arguments. Currently policy says: | To be an `x-terminal-emulator', a program must: |* Be able to emulate a DEC VT100 te

Bug#641153: document Built-Using field for binary packages

Hi, Jakub Wilk wrote: > * Charles Plessy , 2011-12-30, 15:39: >>+ A Build-Using field must list the corresponding source >>+ package for any such binary package incorporated during the build > > s/Build-/Built-/ > >>+ The archive software might reject packages that refer to >>

Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

Hi, Russ Allbery wrote: > I propose the attached patch to address all of those issues. Seconds or > further discussion? [...] > policy.sgml | 24 ++-- > 1 files changed, 10 insertions(+), 14 deletions(-) What happened to this proposal? Does it need attention from any par

Bug#571776: document symbols

Jonathan Nieder wrote: > I'll reply with an interdiff relative to the last version of the > patch. Here it is. Subject: Clarifications to symbols and shlibs policy subject/verb agreement: s/provide/provides/ Packages with libraries or binaries linking to a shared library must use

Bug#452393: [PROPOSAL] clarify overstep between "required" and "important" priorities

Charles Plessy wrote: > Given that the Priority field in the debian source control file is used only > once, when the package is first uploaded to the Debian archive, deprecating > either the required or important priority would not render packages buggy just > for that fact. Are you referring to

Bug#452393: [PROPOSAL] clarify overstep between "required" and "important" priorities

Charles Plessy wrote: > Le Tue, Jul 10, 2012 at 01:20:19PM -0500, Jonathan Nieder a écrit : >> Charles Plessy wrote: >>> deprecating >>> either the required or important priority would not render packages b

Bug#452393: [PROPOSAL] clarify overstep between "required" and "important" priorities

Julien Cristau wrote: > - debconf-i18n, liblocale-gettext-perl, libtext-charwidth-perl, > libtext-iconv-perl, libtext-wrapi18n-perl: since debconf 1.5.39 -i18n > is only a Recommends. Could probably be downgraded to important? I think so. [1] has some context. > - mawk: one of the alternat

Bug#654958: debian-policy: Document VCS fields.

Russ Allbery wrote: > Maybe we should instead say something like: > > ...and should be sufficient to locate the repository used for > packaging. Ideally, it also locates the branch used for development > of new Debian packages. With s/new Debian packages/new versions of the Debian pa

Bug#670429: debian-policy: section tasks is missing

Hi, Charles Plessy wrote: > thank you for your report. Indeed, the section 'tasks' is missing. > > I have reviewed the current list, and in addition to 'tasks' missing, I found > that it was not perfectly sorted in alphabetical order. [...] > --- a/policy.sgml > +++ b/policy.sgml > @@ -714,21 +7

Bug#654958: debian-policy: Document VCS fields.

Hi Bernhard, Bernhard R. Link wrote: >> + In the case of Git, the value consists of a URL, optionally >> + followed by the word -b and the name of a branch in >> + the indicated repository, following the syntax of the >> + git clone command. If

Bug#273093: Unpredictable behavior when two packages want to divert the same file

Hi, In 2004, Frank Küster wrote: > And while we're at it, and a copy goes to debian-policy@l.d.o, > > , > | You should not use `dpkg-divert' on a file belonging to another > | package without consulting the maintainer of that package first. > ` > > Not only that a warning about

Re: tracking packages using (temporary) work-arounds to build

Hi, In 2011, Matthias Klose wrote: > Some packages use work-arounds to prevent build failures, because > these expose bugs in the build tools; these work-arounds are usually > not reverted, and not tracked, or badly tracked (changelogs > commenting on "new version of gcc"). > > These work-arounds

Bug#682282: Please document syntax of Vcs-Cvs field

Package: debian-policy Version: 3.9.3.1 Severity: wishlist Control: block -1 by 654958 X-Debbugs-Cc: "Bernhard R. Link" , c...@packages.debian.org Hi, Bernhard R. Link wrote[1]: >> + >> + The field name identifies the VCS. The field's value uses the >> + ver

Re: tracking packages using (temporary) work-arounds to build

Bill Allombert wrote: > What developers would really need is an easy way to apply patches selectively > on the > version of gcc used. Don't the __GNUC__ and __GNUC_MINOR__ preprocessor symbols work for that? Curious, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org

Re: tracking packages using (temporary) work-arounds to build

Bill Allombert wrote: >> In 2011, Matthias Klose wrote: >>> Some packages use work-arounds to prevent build failures, because >>> these expose bugs in the build tools; these work-arounds are usually >>> not reverted, and not tracked, or badly tracked (changelogs >>> commenting on "new version of g

Bug#374029: Build-Depends{,-Indep} as defined is not useful and not followed

Russ Allbery wrote: > The following patch implements the decision of the Debian Technical > Committee in #629385 to make build-arch and build-indep mandatory. Please > review. Looks good to me. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject

Bug#571776: document symbols

Russ Allbery wrote: > Okay, once more for the win. Hoorah! :) I don't see any problems in the normative content, so I'd second this if I could. Cosmetic nits (patch below): [...] > +++ b/policy.sgml [...] > @@ -5633,17 +5634,29 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) [...] >

Bug#571776: document symbols

Russ Allbery wrote: > Let's go with 1:1.2.3.3.dfsg in the example to show the common case > instead of the unusual case. I've applied this: Thanks. Looks good. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@list

Bug#533287: debian-policy: please clarify 10.7.4

Hi, In 2009, Colin Watson wrote: > /etc/kernel-img.conf is a weird case. To start with, it's initially > created by the installer (base-installer) and the update-grub line is > added by another part of the installer (grub-installer). Obviously the > installer can't own a configuration file perman

Bug#661816: debian-policy: Do not call update-mime directly, since it is triggered by Dpkg.

Hi, Charles Plessy wrote: > Le Thu, Mar 01, 2012 at 08:42:57AM -0600, Jonathan Nieder a écrit : >> If my package generates its mailcap file on the fly in postinst, what command >> should it run to make sure it gets used? Is >> >> dpkg-trigger --no-await --by

Bug#533287: [PATCH v2] Only the owner of a configuration file should modify it

Policy §10.7.4 explains: If it is desirable for [...] packages to share a configuration file and for all of the related packages to be able to modify that configuration file, then the following should be done: [...] ii. The owning package should also provide a program that the other pac

Bug#533287: [PATCH v2] Only the owner of a configuration file should modify it

Russ Allbery wrote: > We may have existing special cases where we've ignored this problem for > reasons of expediency, but I don't think that's a good reason to water > down the requirement globally. Thanks. How about this? My impression is that this "must" has been treated as a "should" in pra

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > If I understand the policy process correctly, the N=3 requirement for > patches includes the submitter; so with two other seconds, I think this is > ready to go. There was an objection from Michael Biebl and quite a bit of discussion after those seconds which touched on im

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

Steve Langasek wrote: > The current patch is the one at > . Thanks! Here's a copy for reference. I take it from the rest of your reply that you still second it. (I haven't carefully reviewed the patch or later discussion yet myself.)

Bug#686143: FHS requirements on "essential" binaries cannot be well defined at distro level

Hi, Russ Allbery wrote: > Your original problem, that there are packages with binaries in /bin that > use libraries in /usr/lib, is unsolved, but is also unaddressable within > Debian in the form of a bug against general. This isn't a problem with > your methodology so much as a problem with Deb

Bug#374029: Build-Depends{,-Indep} as defined is not useful and not followed

Hi, Bill Allombert wrote: > + This split allows binary-only builds to not install the > + dependencies required for the build-indep > + target and skip any resource-intensive build tasks that > + are only required when building archi

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

Hi, In 2006, Martin Zobel-Helas wrote: > during the last months i had to review several packages. Quite a number > of packages were not buildable two times (eg. "unrepresentable changes > to source"). Most of these packages used svn-buildpackage or > cvs-buildpackage. This bug is quite annoying a

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

Bernhard R. Link wrote: > * Jonathan Nieder [120911 05:45]: >> The requirements in policy for >> "debian/rules clean" are very stringent --- to avoid the >> "unrepresentable changes" it would be enough to _remove_ the mo

Bug#397939: clean rule behavior underspecified and inconsistent with common practice

Henrique de Moraes Holschuh wrote: > Still, if any of you would like to do it, please wait a bit. Let's release > Wheezy first. I agree that we should not upload any change along these lines to policy in the near future. I disagree that we should not find a consensus about correct behavior and

<    1   2   3   4   5   >