Bug#587377: debian-policy: Decide on arbitrary file/path names limit

Sean Finney wrote: > Back when I was doing the conffile stuff I recall seeing hardcoded 256 > character limits within dpkg in the archive handling stuff. "path_quote_filename(buf, fname, 256)" and %.255s get used to display filenames to the user, but I think anything lower level having that limit

Re: Bug#609160: debian-policy: include DEP5

Russ Allbery wrote: > This should already be there to handle the debconf spec, which is already > in Policy and already written in Docbook. Ah, debconf_spec/Makefile. Thanks, and sorry I missed this before. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

Aaron M. Ucko wrote: > As I recall, I was running reiser3 at the time. Thanks. To summarize: A lintian-clean Debian package failed to unpack with ENAMETOOLONG. Setting maximum lengths for paths and filenames in data.tar.gz in policy could prevent future mistakes of this kind, without making dpk

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

Bill Allombert wrote: > On Wed, Mar 02, 2011 at 10:17:32PM -0600, Jonathan Nieder wrote: >> Another question: is Debian policy the right place to make a decisions >> like this? Ideally these maxima would be set using some cross-distro >> standard like POSIX or the FHS. Sadl

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

Bill Allombert wrote: > Not really; the packager might not be able to change the filename without > breaking either > FHS compliance, the interface or compatibility with upstream. Ah, now I think I understand a bit better. FHS compliance sounds like a red herring to me. Does the FHS mandate

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

tags 587377 + wontfix quit Sean Finney wrote: > On Thu, 2011-03-03 at 15:58 -0600, Jonathan Nieder wrote: >> * how many characters of grace area can tools like dpkg-divert feel >>free to use? > > I don't think tools should be like "whoa, i think this filename

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

Bill Allombert wrote: > To give an example: Debian policy mandates that the file > /usr/share/doc//changelog.Debian.gz > exists. > Now perl subpolicy mandate that the perl module > Foo::Bar::Baz::Qux::Quux::Quuux::Qx > whic live in /usr/share/perl5/Foo/Bar/Baz/Qux/Quux/Quuux/Qx > be pa

Bug#616465: debian-policy: description file in each system directory

Hi Sergey! sergey wrote: > What do you think about placing README in each system directory? I think the idea is interesting but agree with Steve that policy is not the best way to move it forward. Packages already can put README files in particularly mysterious directories, and I don't see a co

Bug#616457: debian-policy: always write version of Debian in documentation at the beginning

Hi again, sergey wrote: > It is like bad tradition now: many documentation do not contain information > about > Debian version. It is very strange for me. How can be authors 100% sure > that their documentation is absolutely correct for all Debian versions, > from 1.1 or older to the current?

Bug#613946: debian-policy: anchor issues in HTML version

, I didn't know about that page. I agree that it's not worth spending time on other aspects. So please feel free to ignore the rest of this message. ;-) > On Tue, Mar 01, 2011 at 10:24:05PM -0600, Jonathan Nieder wrote: >> retitle -1 debiandoc2html: titles should not have

Bug#504880: Disambiguate "installed" for packages

Russ Allbery wrote: > Does that look okay? Yes, the version in branch 504880-rra looks good to me (with one tweak: --- a/policy.sgml +++ b/policy.sgml @@ -4027,5 +4027,5 @@ fi in postrm purges the debconf configuration for the package if debconf

Bug#587279: debian-policy: clarify wording of parenthetical in section 2.2.1

forcemerge 587279 616462 quit Hi Marvin, Marvin Renich wrote: > to > > ...the packages in main > >• must not require a package outside of main for compilation or > execution (thus, all declared "Depends", "Recommends", and > "Build-Depends" relationships must be satisfiable with on

Bug#587991: perl-policy: /etc/perl missing from Module Path

Hi, Ansgar Burchardt noticed: > perl/5.8.0-7 added /etc/perl to @INC: > > * Prepend /etc/perl to @INC to provide a standard location for > configuration modules: > > But this addition has never been documented in the Debian Perl Policy. Russ Allbery wrote: > Good point. Here's updated pr

Bug#23712: conflicting packages with the same conffile

Raphael Hertzog wrote: > On Sat, 21 Aug 2010, Russ Allbery wrote: >> Hm. All the words that I had intended to be there are there. I clearly >> need to rephrase it somehow, though, if it's not clear. How about: >> >> When two packages both declare the same conffile, they may >> see left-

Bug#403649: debian-policy: Should clarify package availability in "postrm remove"

forcemerge 504880 403649 quit Hi Frank, Frank Küster wrote: > Current Policy says: > > , 7.2 Binary Dependencies > | The Depends field should also be used if the postinst, prerm or > | postrm scripts require the package to be present in order to > | run. Note, however, that the postrm cannot

Bug#556015: Clarify requirements for copyright file

tags 556015 - patch quit Hi, Russ Allbery wrote: > Here's a patch that is explicit about the required dependencies and > discourages the last case. Does this look good to everyone? I'm missing some background but hopefully that's all right. Quick comments. > +++ b/policy.sgml > @@ -573,10 +5

Bug#556015: Clarify requirements for copyright file

Hi Russ, Russ Allbery wrote: > Right, this was the reason why I hadn't committed anything yet. We have > to decide whether we're going to prohibit arch:any -> arch:all links > completely to ensure that the binNMU changelog entries are visible. My > inclination is to do so, and hence drop this w

Bug#591791: extend init.d policy to permit upstart jobs and describe their use

Hi, Steve Langasek wrote: > Sorry this has taken so long; I spun my wheels on it > for some time because I couldn't quite accept that there were so few > additional requirements that needed to be specified here! Thanks for your work. :) [...] > + tasks at boot time. However, any packa

Bug#591791: extend init.d policy to permit upstart jobs and describe their use

Bill Allombert wrote: > On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: >> Maybe policy could allow (but discourage) packages that only support >> some non-Sys-V init system as long as they include a dependency >> indicating so? > > This would be a ter

Bug#616465: debian-policy: description file in each system directory

Hi Sergey, sergey wrote: > Does Debian policy can recommend something (including READMEs)? Or policy can > only > force something, no recommendations is possible? Policy sets rules that make sure the system works well. These can be hard requirements (generally using the word "must"), which cor

Bug#593177: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

Hi, Steve Langasek wrote: > So in this case the pre-dependency > should *not* be set, as it only serves to complicate the upgrade path. I think this example might deserve a closer look. Documentating the required dpkg version seems useful for backporters and others who would use the package in

Bug#616465: debian-policy: description file in each system directory

(-cc: Steve since he is already subscribed to -policy) Hi Sergey, sergey wrote: > I agree that it is a good place for proposals like mine. > But making long well-developed draft and "driving" it - this is > mostly operating system developer's task, not users one. > I think that Debian should have

Bug#593177: Clarify when dependencies of pre-dependencies are satisfied

(switching topics; sorry for the cognitive dissonance) Steve Langasek wrote: > Taken in sum, there is a cost to that documentation. Thanks for a nice summary. > On Sat, Mar 05, 2011 at 06:26:27PM -0600, Jonathan Nieder wrote: >> Bug#593177 brings the possibility of change. In

Bug#619275: Perl Policy change to document major version upgrade trigger

Dominic Hargreaves wrote: > A not-so-recent bug report, #230308, raised the issue of how a long-running > program which would be broken (until restart) by a major Perl package upgrade > (eg from 5.10 to 5.12) could be notified of such a restart. There was a rough > consensus on that bug report tha

debian policy: please discourage overly strict run-time version checks

reassign 528453 debian-policy 3.9.1.0 severity 528453 wishlist retitle 528453 debian policy: please discourage overly strict run-time version checks tags 528453 - wontfix quit Hi, Jörg Sommer wrote: > Jonathan Nieder hat am Fri 01. Jan, 10:42 (+) geschrieben: >> Jörg Sommer wrote:

Bug#528453: debian policy: please discourage overly strict run-time version checks

(culled cc list) Bill Allombert wrote: > Another similar warning: the dynamic loader sometime output a warning > "symbol xxx size has changed, consider relinking" > when a library is updated to a new minor version. > (It was libreadline in etch IIRC). Right, that sounds like a bug. > While I agr

Bug#619284: Chapter 7.7 of the Policy disagrees with reality

forcemerge 604397 619284 quit Hi, Robert Luberda wrote: > reassign 619284 debian-policy (For the future: please remember that debbugs does not automatically cc your message to the package you are reassigning to.) > I implemented a work-around in ispell 3.3.02-3, so the bug no longer > affects

Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions

Steve Langasek wrote: > If I understand the current policy process, this has met the necessary > number of sign-offs (proposer + 2 seconds == 3 sign-offs), so marking as > 'seconded'. Yes, and the change sounds good to me. Thanks. > Is there a policy czar available to confirm this and maybe to

Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions

Steve Langasek wrote: > http://wiki.debian.org/Multiarch/Bootstrapping > > The current ld.so doesn't yet know about the final path (on i386), so > libraries can't switch to using it or they'll fail to be found by the > runtime linker. > > Since we don't want to wait until the next release cycle

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

Package: debian-policy Version: 3.9.1.0 Raphael Hertzog wrote[1]: > It has been discussed on -release, not on -devel: > http://lists.debian.org/debian-release/2011/02/threads.html#00381 > > (I don't think it matters much given that all important stakeholders where > involved) No strong objection

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

Raphael Hertzog wrote: > That's why it was discussed there. Otherwise it might well be the case > that it would have been discussed on -devel. Wait, how is that relevant at all? Is the point that the policy manual is saying what you should do in the default case, and this is a special one? The

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

Raphael Hertzog wrote: > The reason > we request peer review of Pre-Depends is that they have a cost and should > not be abused. Okay. That's not what policy §3.5 says; it does not say Pre-Depends should or must be peer-reviewed or that one should examine all aspects when adding them but simply

Bug#620109: Policy §3.5 (on Pre-Depends) does not reflect actual practice

Steve Langasek wrote: > 1. get more eyeballs on the proposed change, to spot problems which the > added pre-dep may cause > > 2. inform the wider Debian developer community about the change, so they > can factor it into any plans they have for changing their *own* package > relations

Re: BTS cleaning, seconded patches, and conversion of the Policy to DocBook.

Hi Charles, Charles Plessy wrote: > I am reading http://wiki.debian.org/PolicyChangesProcess and > http://wiki.debian.org/Teams/Policy to see how I can help to go forward with > the Policy bugs. Not only for the patches that I sent in 2010 and 2011, but > more in general for all the patches that

Bug#619186: Fix multiarch FHS exception for i386 in light of recent discussions

user debian-pol...@packages.debian.org tags 619186 = usertags 619186 = normative seconded quit Steve Langasek wrote: > On Tue, Mar 29, 2011 at 05:21:59PM -0500, Jonathan Nieder wrote: >> Steve Langasek wrote: >>> If you think this is important to document in policy anywa

Bug#598645: cleanup: dike non-policy

user debian-pol...@packages.debian.org package debian-policy tags 598645 - patch retitle 598645 cleanup: move text out of appendices usertags 598645 = informative issue quit Hi Brian, Brian Ryans wrote: > I'd been looking into this for quite a bit, and I'm at an impasse: I > can't seem to determ

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Raphael Hertzog wrote: > On Sun, 03 Apr 2011, Russ Allbery wrote: >> My inclination is to second this, but I want to make sure that we've >> answered your and Julien's objections first. > > And for complete reference, dpkg accepts those version in > /var/lib/dpkg/status (so that dpkg still works f

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Russ Allbery wrote: > Raphael Hertzog writes: >> it's trivial to add a leading 0. > > We could recommend that explicitly if it would help. It would be my > recommendation even without the restriction on version numbers, since > alphanumerics would sort after any numbers, so you'd need an epoch >

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Russ Allbery wrote: > I think this is an interesting conversation, but so far as I can tell it's > not particularly relevant to Policy. There are no such packages with > those version numbers currently in Debian, so Policy can simply say that > there will never be in the future either and be done

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Russ Allbery wrote: > Jonathan Nieder writes: >> What about previously-in-archive packages? > > Are there any of significance? I don't know. The example I gave was from a dpkg bug report, and I don't know if it was contrived or not (one would have to ask the subm

Bug#620566: dpkg: "version number does not start with digit" is in contrast to policy

Russ Allbery wrote: > Jonathan Nieder writes: >> What about previously-in-archive packages? > > Are there any of significance? Ah, I forgot to say: I think changing this to a "must" with advice to add a 0 when the upstream version does not start with a number would be

[PATCH] upgrading-checklist in present tense?

Hi, A tiny nitpick: I found it jarring when the upgrading-checklist switched from past tense to present tense. I suppose it is because I kept finding myself switching context when reading it: unlike a changelog, which paraphrases a patch that will command the code to change, the upgrading checkli

Re: [PATCH] upgrading-checklist in present tense?

Russ Allbery wrote: > Alternately, if we're going to standardize on past tense, we should > probably go ahead and fix everything back to 3.8.0 or so, which seems to > be when I started introducing present tense. (It looks like Manoj was > using past tense.) Here's a rough patch on top to do that

Bug#621050: Document dependencies needed to use multiarch paths

Package: debian-policy Version: 3.9.1.0 Severity: wishlist User: debian-pol...@packages.debian.org Usertags: informative Steve Langasek wrote[1]: > Since we don't want to wait until the next release cycle before being able > to proceed to step 5, this does mean that a transitional dependency is >

[PATCH v2] upgrading-checklist in present tense?

Russ Allbery wrote: > Looking back at older entries, the ones I wrote for previous releases are > also in present tense. Could we standardize in that direction instead? I can understand the temptation. I might be the only one that is tempted to read the changes as commands directed to the packa

Re: [PATCH v2] upgrading-checklist in present tense?

Russ Allbery wrote: > Given that, and given that the preponderance of entries are either factual > statements about the contents of Policy or instructions to the packager, > how about this patch instead? Perfect. :) Thanks. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org wi

Bug#623291: Clarify that dependency loops involving relations like Suggests are ok

Package: debian-policy Version: 3.9.2.0 Severity: minor Hi, >From [1]: > Wouldn't that create a circular dependency? > pcscd Depends: libpcsclite1 > libpcsclite1 Suggests: pcscd > > I fixed a similar problem in #612972 a few weeks ago. It seems that policy uses the term dependency for all packa

Bug#175064: DocBook XML conversion is read with this script

Hi Osamu, Osamu Aoki wrote: > By extracting attached file into source and running "make", it will do > the magic of converting to DocBok XML and then to PDF etc. > (Need the sid version of the latest debiandoc-sgml) Very neat. I also had to install dblatex. I like the separation between automa

Bug#175064: DocBook XML conversion is read with this script

Hi again, Osamu Aoki wrote: > I was lazy to copy that kind of script to the makefile. You can find it > in maint-guide subversion. Okay, will take a look. > On Mon, Apr 25, 2011 at 05:25:31AM -0500, Jonathan Nieder wrote: >> . The lack of indentation in the source is ni

Bug#621833: System users: removing them

(culled cc list of a few people I know read -devel) Roger Leigh wrote: > Given the need to consider unlocking as well as locking, I'm not sure > it's worth adding special support to deluser: the typical logic used > to create the user will be insufficient to unlock, so it's no less > the effort to

Bug#628515: recommending verbose build logs

Some notes for completeness. Matthias Klose wrote: > - cmake: VERBOSE=1 (?) Yes, or "cmake -DCMAKE_VERBOSE_MAKEFILE=1" at configure time. > - automake: V=1 As KiBi mentioned, --disable-silent-rules at configure time works, too. > - linux kernel: V=1 The KBUILD_VERBOSE environment variable

Bug#628540: [copyright-format] URI to SPDX license list.

Charles Plessy wrote: > --- a/copyright-format/copyright-format.xml > +++ b/copyright-format/copyright-format.xml > @@ -558,8 +558,7 @@ License: MPL-1.1 > > > Currently, the full text of the licenses is only available in the > -url="http://spdx.org/wiki/working-v

Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)

Hi Jérémy, Jérémy Lal wrote: > Some clarifications : > * setting up the fastcgi process itself is specific for each case, > so it's the responsibility of the "client" package to declare what it > depends on > (php5-cgi, libfcgi-ruby, ...). > * most, if not all, servers provide a way to spawn

Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)

Hi again, Jonathan Nieder wrote: > Jérémy Lal wrote: >> Some clarifications : >> * setting up the fastcgi process itself is specific for each case, >> so it's the responsibility of the "client" package to declare what it >> depends on >> (php

Bug#604397: debian-policy: require build-arch and build-indep targets

Steve Langasek wrote: > I don't think a policy "should" actually moves us down that road, because > there's no actual penalty for not complying. The issue is *not* that > maintainers don't, in general, implement this target (in fact, it's been > around forever in the dh_make templates), As a cou

Bug#604397: debian-policy: require build-arch and build-indep targets

after your advice, make-first-existing-target seems like a much better idea (because simpler and sufficient). > On Fri, Jun 03, 2011 at 11:32:13PM -0500, Jonathan Nieder wrote: >> Thanks much! If you'd like, I can try out the two patches from >> Bug#598534 and send a comparison the

Re: [RFC] Skipping new-prerm failed-upgrade?

Hi Raphael, Raphael Hertzog wrote: > 1/ I'd argue that in the case of downgrade, dpkg should not try to run >the failed-upgrade fallback because there's no way the oldest version >can be aware of how to work-around a problem in a prerm script of a >newer version that did not exist at

Re: [RFC] Skipping new-prerm failed-upgrade?

Raphael Hertzog wrote: > -maintainer_script_alternative(pkg, PRERMFILE, "pre-removal", cidir, > cidirrest, > - "upgrade", "failed-upgrade"); > +if (versioncompare(&pkg->available.version, > + &pkg->installed.version) > 0) /* Upgrade *

Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means

Hi Nicholas, Nicholas Bamber wrote: > As far as I know the license data in debian/copyright states what > license Debian is distributing the package under. Section 1.2 "Copyright information" says: Every package must be accompanied by a verbatim copy of its copyright information

Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means

Hi, Nicholas Bamber wrote: > The package maintainer wants the following stanza > > Copyright: (C) 1995-1998, 2000, 2003-2008 Free Software Foundation, Inc. > License: GFDL-1.1+ > Permission is granted to copy, distribute and/or modify this document > under the terms of the GNU Free Documentati

Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means

Steve Langasek wrote: > On Fri, Jul 15, 2011 at 02:14:09PM -0500, Jonathan Nieder wrote: >> While there's been some debate before about what "verbatim" means, I >> suspect that most would agree that, for example, changing "1.1 or >> later" to "1.

Bug#634192: Section is suggested explaining the debian/symbols file

Hi, Innocent De Marchi wrote: > I think it would be nice to add a section for packaging libraryes > (explaining the use of the debian/symbols). Documenting the format of the symbols control file (i.e., dpkg-gensymbols output) in policy sounds like a good idea indeed. Currently section 8.1 "Run-t

Bug#634192: Section is suggested explaining the debian/symbols file

forcemerge 571776 634192 quit Innocent De Marchi wrote: > I think it would be nice to add a section for packaging libraryes > (explaining the use of the debian/symbols). See also . Since documenting the symbols file format would be the bulk of that work, I'm mergi

Bug#457364: debian-policy: please reserve part of the package namespace for cross compilation

Hi Simon, Simon Richter wrote: > Proposed text (to be appended to 5.6.7): > > Names ending in "-cross" that have at least two dashes overall are > reserved for cross compilation support, and should not be used directly. A lot has changed since this proposal, and I am uninformed, hence curious: d

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

Hi Axel, Axel Beckert wrote: > Policy 9.1.1 states: "The location of all installed files and > directories must comply with the Filesystem Hierarchy Standard (FHS) > [...]". [...] > I therefore suggest to rephrase this sentence as follows: > > "The location of all installed files and directories,

Bug#609160: debian-policy: include DEP5

Steve Langasek wrote: > I think there are significant language > bugs in the current draft that should be fixed before this is ready to be > adopted as a standard. Could you list some? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsu

Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions

Hi, Ximin Luo wrote: > I don't think disk space is an issue these days I think that's the real point of disagreement here, for what it's worth. common-licenses is part of base-files, which is included on every Debian installation. Some do need to be small. (No opinion on whether the MPL shoul

Bug#609160: debian-policy: include DEP5

Hi, Lars Wirzenius wrote: > After the policy team takes over maintenance of the DEP5 spec, > you can use the policy process to suggest changes to it. The DEP5 spec is already in the policy repo. Is there any reason not to move to that way of working now (which does not imply anything about when

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

Hi Carl, Carl Fürstenberg wrote: > Per resolution of bug #639997 I would like to ask for clarification of > section 9.9 in the polcy regarding environmental variables, and if it > implicitly excludes "global" environmental variables like PATH, or if > all programs must include themself a sensible

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

Jonathan Nieder wrote: > See /usr/bin/iceweasel for an example Scratch that --- iceweasel can be run directly nowadays as "/usr/lib/iceweasel/firefox-bin". I should have said "see pre-2010 mozilla for an example involving LD_LIBRARY_PATH". https://bugzilla.mozilla.org

Bug#609162: debian-policy: package names with dots/periods ('.') and crontab files: packagers beware

(bcc: cron maintainers, request-tracker3.8 maintainers, debianutils maintainers, jtmd) Hi, Karl E. Jorgensen noticed that the current advice for naming files in cron.d breaks for packages with a dot in their name and proposed a small policy change to fix that. Seconds? Objections? The proposed

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

Colin Watson wrote: > Yes. How about: > > diff --git a/policy.sgml b/policy.sgml > index bb424ed..3a8bd90 100644 > --- a/policy.sgml > +++ b/policy.sgml > @@ -7449,8 +7449,8 @@ Reloading description configuration...done. > Environment variables > > > - A program must not depe

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

Tollef Fog Heen wrote: > ]] Steve Langasek > | How do we square that with the FHS, then? The FHS says: > | > | If directories /lib or /usr/lib exist, the equivalent > | directories must also exist in /usr/local. > | > | That seems to require /usr/local/lib64 even if we *don't* include > | /u

Bug#172436: BROWSER and sensible-browser standardization

Hi Russ, This question came up recently on the git mailing list in the context of "git web--browse" (a backend used by git instaweb and some other commands). It would have been nice to have clear advice in Debian policy to guide what we should do. >From the point of view of improving upstream pr

Bug#172436: BROWSER and sensible-browser standardization

Jonathan Nieder wrote: > 1. For desktop apps, recommend unconditional use of xdg-open. > > 2. For everyone else: [...] > c. For non-desktop apps lacking support for the BROWSER variable, >recommend unconditional use of xdg-open (for the same reason). Gah, for &

Bug#644230: debian-policy: Please change virtual package name for Japanese fonts

Nobuhiro Iwamatsu wrote: > There are ttf-japanese-mincho and ttf-japanese-gothic in the virtual package > of font packages for Japanese now. > By the Fonts team, we are switching over from ttf- to fonts- by ackage file > name now. > To this shift, I suggest that I change the virtual package > fro

Bug#644230: debian-policy: Please change virtual package name for Japanese fonts

Nobuhiro Iwamatsu wrote: > And most application works for the cause by setting of fontconfig. > This work does not depend on ttf-japanese-{gothic,mincho}. Ah, sounds like the answer is that one should use "sans" and "serif", then. :) Now that I check, it looks like currently each package that Pr

Bug#591791: extend init.d policy to permit upstart jobs and describe their use

Hi, Steve Langasek wrote: > On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: >> Maybe policy could allow (but discourage) packages that only support >> some non-Sys-V init system as long as they include a dependency >> indicating so? > > I don't th

Bug#591791: extend init.d policy to permit upstart jobs and describe their use

Jonathan Nieder wrote: > In an ideal world, (i) would be enough [since it determines the > behavior] and packagers could experiment Just to be clear: I was reading from the point of view of what a packager of an ordinary daemon needs to do. But the requirements on init systems are imp

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

Hi Charles et al, Charles Plessy wrote: > thanks a lot Justin for the proofreading. Thanks for making it happen! > I read it in details and agree with > all the changes you propose. I therefore propose to the debian-policy team to > apply your patch. I agree --- after a careful look, I didn't

Bug#633797: copyright-format: "with exception" underspecified

Charles Plessy wrote: > I looked at how my favorite parser, config-edit, is doing with exceptions, and > if I add a ‘OpenSSL and Font’ or an ‘OpenSSL, Font’ exception, it stops with > error at loading… As a workaround, "with exception" might work, making this "GPL-2+ with OpenSSL exception with

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

Steve Langasek wrote: > I think merging such changes (which at a glance appear to include arbitrary > preferences of word choice) is a waste of everyone's time and I'm inclined > to ignore this altogether in favor of working on the real problems with the > text. So, to be clear, does that mean th

Bug#633797: copyright-format: "with exception" underspecified

Steve Langasek wrote: > However, the history of the draft shows that people are concerned > about knowing whether *specific* common exceptions are in effect Good point. For example, the "GPL-2 with OpenSSL exception" and "OpenSSL" licenses are compatible, while GPL-2 and the OpenSSL licenses are

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

Hi, Ximin Luo wrote: > When packaging mozilla extensions I ran some problems with DEP5. I talked this > issue over on #645696 which eventually resulted in encouragement to move > forward > with a proposal for a change to be made. I think this report contains multiple proposals. Let me try to s

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

Ximin Luo wrote: > On 21/11/11 23:21, Jonathan Nieder wrote: >> Files: * >> Copyright: - etc >> License: GPL-2+ >> >> License: GPL-2 >> etc [...] >> Files: * >> Copyright: - etc >> L

Bug#649674: [copyright-format] Proofreading of the examples.

Hi, Charles Plessy wrote: > Example 1: missing opening bracket in the fourth paragraph. Sure (missing "[" before "LICENSE TEXT]"). > Example 3: missing license short name for debian/* files. > Example 4: missing license short name for debian/* files. True. A previous version of the format inc

Re: Bug#649674: [copyright-format] Proofreading of the examples.

(-cc: the bug, since I am veering off topic) Charles Plessy wrote: > (In > particular, the discussion in #649530 highlights that some of the examples are > very artificial and turn quickly into cornercases in the real life, because > the > GPL and the MPL feature edited notices where the name of

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

Hi, Charles Plessy wrote: > --- a/copyright-format/copyright-format.xml > +++ b/copyright-format/copyright-format.xml > @@ -172,11 +172,13 @@ > Paragraphs > >There are three kinds of paragraphs: the first one is called the > - header paragraph. > + header paragraph, s

Bug#462996: Bug#649674: [copyright-format] Proofreading of the examples.

Charles Plessy wrote: > Le Tue, Nov 22, 2011 at 08:58:30PM -0600, Jonathan Nieder a écrit : >> Unless the license itself has some relevant requirement on >> distribution of binaries, nothing mentioned above (except maybe the >> “verbatim”) requires the license headers fr

Bug#628515: recommending verbose build logs

Hi Matthias, Matthias Klose wrote: > It's always interesting to look at build logs, or to receive bug reports of > the form > > CC > > > or > > CCLD > > > without knowing how the compiler or the linker were called. Maybe it is > convenient for a package maintainer watching the build s

Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means

Hi Charles, Charles Plessy wrote: > this summer you have submitted a bug against the Debian policy, about “what > the > license information in the copyright file actually means”. After reading > again > the whole discussion, my feeling is that much of the answer would be actually > be given by

Bug#628515: recommending verbose build logs

Jakub Wilk wrote: > * Jonathan Nieder , 2011-11-26, 18:37: [...] >> I do not suspect there is a >> consensus for this. > > Why do you think there is not? I was guessing, it seems incorrectly, based on the lack of seconds or other discussion on this policy proposal. >

Bug#628515: recommending verbose build logs

Hi Charles, Charles Plessy wrote: > I think that the best way to see which of verbose or noverbose is to be chosen > would be to go through the soft release goal or release recommendation that > Matthias advocated. Once the mayonnaise thickens (once the recommendation is > followed), then it wil

Bug#628515: recommending verbose build logs

Charles Plessy wrote: > it seems to me that the best way to materialise a consensus for a release goal > is to actually get it listed in http://release.debian.org/wheezy/goals.txt and > have the work started. This will protect the Policy from documenting options > that are not implemented. In li

RFC: Policy process considered harmful

Disclaimer: the below is a half-baked long-term proposal for a process change. If you're wondering about how to do useful work today, please ignore it. But comments welcome. Hi, My experience has been that the policy process works pretty well when a policy delegate is involved in the discussion

Bug#628515: recommending verbose build logs

Raphael Hertzog wrote: > For reference dpkg supports "DEB_BUILD_OPTIONS=maintainer-build" [...] > I also think that it would be more convenient to have the buildd set the > verbose mode and others to have the silent rules by default but I don't > think this is going to take traction. We have quite

Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified

Charles Plessy wrote: > Would you or somebody eles mind if I close this bug report ? I would mind. The current wording implies that installing a non-public library directly under /usr/lib/x86_64-linux-gnu/ is fine, which is clearly wrong. Regards, Jonathan -- To UNSUBSCRIBE, email

Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified

clone 636383 -1 retitle -1 policy: replace "/usr/lib" by some expression that encompasses multiarch directories, too quit Charles Plessy wrote: > How about the attached patch ? Do you think it is clear enough that > /usr/lib/triplet is not allowed ? Technically it never says so, but I think it

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

Package: debian-policy Version: 3.9.2.0 Severity: wishlist X-Debbugs-Cc: Reuben Thomas , xt...@packages.debian.org, kt...@packages.debian.org, x...@packages.debian.org, mlt...@packages.debian.org Hi, Reuben Thomas reported[1]: > Please set eightBitInput: false by default so that, as in konsole

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

Russ Allbery wrote: > My initial reaction is that I want to see a more compelling justification > for standardizing anything here. I don't think it's any more or less confusing than delete-versus- backspace behavior. For an example of what went wrong in the past that prompted me to suggest addin

<    1   2   3   4   5   >