Bug#910783: Remove doc-base recommendation
On 2018-10-12 10:16, Bill Allombert wrote:
On Thu, Oct 11, 2018 at 01:04:52PM +0100, Ian Jackson wrote:
Andrey Rahmatullin writes ("Bug#910783: Remove doc-base
recommendation"):
> Package: debian-policy
> Version: 4.2.1.2
> Severity: normal
>
> It seems to me that the consensus is that doc-base is not actually useful and
> so 9.10. Registering Documents using doc-base can be dropped.
>
> lintian has an I: possible-documentation-but-no-doc-base-registration tag,
with
> 1872 emitted currently:
https://lintian.debian.org/tags/possible-documentation-
> but-no-doc-base-registration.html
>
I suggest that instead of abandoning it, we should bump the lintian
message to a warning.
Is not I: (info) even lower priority than W: (warning) ?
I do not think it is displayed by default:
from lintian(1):
-I, --display-info
Display informational ("I:") tags as well. They are
normally suppressed.
I believe you've misunderstood - Ian is suggesting *raising* the level
of the tag, not lowering it.
Regards,
Adam
Bug#908933: debian-policy: typo in document in section 3.4 page no 15 line number 16 needs improvement.
On Sun, 2018-09-16 at 14:01 +0530, Jaikumar Sharma wrote: > debian-policy has typo under section 3.4 The description of the > package page no.15 and line number 16 has following text which needs > improvement in spelling of 'administratrivia' . > ** text from policy** > Copyright statements and other administrivia should not be included > either (that is what > the copyright file is for). Are you sure? I've always known the shorter spelling and a random online sample of sources that agree gives: - https://www.thefreedictionary.com/administrivia - https://www.merriam-webster.com/dictionary/administrivia - https://en.wiktionary.org/wiki/administrivia - https://www.urbandictionary.com/define.php?term=administrivia (not that authoritative a source, admittedly :P) - https://en.oxforddictionaries.com/definition/administrivia - http://www.yourdictionary.com/administrivia Some of those note administratrivia as an alternative, but that certainly doesn't make the use of administrivia incorrect. Regards, Adam (Not a Policy editor)
Re: Bug#908155: Coordination with upstream developers not universally applied
On Fri, 2018-09-07 at 18:42 +0200, Thorsten Glaser wrote: > Short answer (slightly drunk and short on time), more later: > > On Fri, 7 Sep 2018, Ian Jackson wrote: > > > In some packages this will not be possible at least for some bug > > reports. You've seen the poor quality and hard-to-follow-up bug > > […] > > Yes, but that does not mean we should make it permitted by the rules > to slack in that “duty”. An arguably small point, but the Developer's Reference is explicitly *not* "the rules". Its own scope statement makes this clear: Furthermore, this document is not an expression of formal policy. It contains documentation for the Debian system and generally agreed-upon best practices. Thus, it is not what is called a ``normative'' document. Regards, Adam
Bug#907915: developers-reference: language in manual
On 2018-09-04 03:52, Paul Hardy wrote: With Debian presenting itself as a distribution suitable for children in educational environments, please consider removing the "f-bombs" in this package. As a fundamental document in Debian, it is something that should be acceptable for school children to read so adding an "offensive" tag to the package will not be enough to remedy the situation. There are three such occurrences: * Section 5.13.2.1 Out-of-date: please find another term for "architectures that don't keep up", and modify the update_out.py mentioned in that section accordingly. * 5.13.2.4 Influence of packaging in testing: same comment; please use another term for such architectures. For the record, "the update_out.py mentioned" is britney, i.e. the testing migration scripts. The name of the variable mentioned above was changed in production nearly two years ago - see https://salsa.debian.org/release-team/britney2/commit/fe7cc466e18b77493d5b4dade14e5e7a50055680 - so both of these occurences can be resolved by simply updating the documentation to match reality. Regards, Adam
Bug#864615: please update version of posix standard for scripts (section 10.4)
On Sat, 2017-10-14 at 11:30 -0700, Sean Whitton wrote: > control: tag -1 +moreinfo > > Hello Ralf, > > On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote: > > section 10.4 says: > > > > Scripts may assume that /bin/sh implements the SUSv3 Shell > > Command > > Language ... > > > > This version of the standard is so outdated that it isn't even any > > longer available on the opengroup web site. Really? http://pubs.opengroup.org/onlinepubs/009695399/ is still there, and indeed referenced from https://en.wikipedia.org/wiki/Single_UNIX_Sp ecification > > The latest version of the > > standard is 4.2 (published in 2016), earlier versions currently > > available on the opengroup site are 4 (from 2008) and 4.1 (from > > 2013). > > Please consider updating the policy. > > I found the 2016 edition of version 4 of the SUS,[1] but what makes > you think that is version 4.2? I couldn't find that version number > anywhere. If they've changed their versioning scheme, maybe Policy > needs to use the expression "SUSv4 (2016 edition)"? The 2016 edition is Technical Corrigendum 2. I'm not sure that it's conventional to use versioning such as 4.2 in such cases, however. I'd expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition; the latter seems to be more common. Regards, Adam
Bug#878033: developers-reference: typos, etc.
On 2017-10-09 14:02, Paul Hardy wrote: I gave unifont 1:10.0.04-1 an urgency of low, and yet it migrated to testing after 5 days. That was in July. I have only used "urgency=medium" since then. It sounds like whatever happened was temporary. Ah. Looking at that a bit further, that was due to unifont 1:10.0.03-1 (uploaded to experimental) having urgency "medium" and the version in testing being 1:10.0.02-1 at the time; the net urgency was therefore "medium". That's due to the way urgency stickiness works - see #831699 and the dak bug blocking it. Regards, Adam
Bug#878033: developers-reference: typos, etc.
On 2017-10-08 23:51, Paul Hardy wrote: Section 5.13.2: low priority packages no longer wait 10 days to migrate to testing; they wait 5 days now. If this is a permanent change, I would update this section. What makes you think that? The live configuration for britney has: MINDAYS_LOW = 10 MINDAYS_MEDIUM= 5 MINDAYS_HIGH = 2 and from excuses wdm (1.28-20 to 1.28-21) Migration status: WAITING: Waiting for test results, another package or too young (no action required now - check later) Maintainer: Axel Beckert Too young, only 0 of 10 days old and indeed +wdm (1.28-21) unstable; urgency=low Regards, Adam
Bug#850289: debian-policy: Patch so that there is an Example section in manual pages
On Thu, 2017-01-05 at 23:50 +0530, shirish शिरीष wrote: > Package: debian-policy > Version: 3.9.8.0 > Tags: patch > Severity: wishlist > > Dear Maintainer, > As shared in #850171 it would be nice if we have Example section in > manpages. This would be especially useful for non-technical users and > a step towards making Debian a truly Universal Operating System. Why is this a new bug and not simply sent to #850171? Regards, Adam
Bug#845715: debian-policy: Please document that packages are not allowed to write outside their source directories
On Sat, 2016-11-26 at 03:34 +, Johannes Schauer wrote: > + None of the required targets must attempt to write outside of the You either mean "The required targets must not attempt" or "None of the required targets may attempt"; the current wording means "None of the required targets is required to attempt". Based on confusion I've seen before from non-native speakers regarding the use of "may" in such constructions (despite being perfectly reasonable English), I'd suggest the former wording. > + source package package directory tree. An exception to this rule is > + the use of /tmp which is permitted as long as temporary > + files are deleted and not re-used by subsequent execution of the > + target. This is to prevent that source package builds create and > + depend on state from the outside and thus affect multiple > independent "This restriction is intended to prevent source package builds creating or depending on state outside of themselves and thus ..."? > + rebuilds. Most notably, none of the required targets must attempt to > + write into $HOME. This wants re-wording similarly to the first sentence. Regards, Adam
Bug#831047: debian-policy: two Debian Policy versions were released, but not announced on d-devel-announce
On 2016-07-14 9:22, Bill Allombert wrote: On Wed, Jul 13, 2016 at 11:33:00PM +0200, Francesco Poli (wintermute) wrote: I found the announce [2] of version 3.9.7.0, but it was apparently sent to debian-devel@l.d.o, rather than to debian-devel-announce@l.d.o ! [2] https://lists.debian.org/debian-devel/2016/02/msg00016.html As you can see it was sent to debian-devel-announce and signed. I have no idea why it did not reached debian-devel-announce, maybe because I failed to remove the In-reply-to field. That would indeed do it - mails to dda that appear to be replies are automatically redirected to -devel (as they're most commonly the result of someone hitting reply-all on a dda post). Regards, Adam
Bug#807742: developer-reference: Italian Translation
On Tue, 2016-04-19 at 20:24 +0200, Pierangelo Mancusi wrote: > Dear Maintainer, > > count_month=4; The last upload of developers-reference was before you submitted your translation (of what wasn't even the current version at the time), so grumbling once a month that it's not been included is unlikely to help. Regards, Adam
Bug#776557: debian-policy: Please clarify 2.5 'unix heritage = important'
On 2015-01-29 16:55, Matthias Urlichs wrote: Hi, Bill Allombert: [...] - by apt-get: the pdiff system use ed scripts which I assume has a dependency on ed. apt uses an internal implementation. Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f643acd45bbd1c5c64dc499b837ad...@mail.adsl.funky-badger.org
Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files
On Thu, 2013-10-10 at 12:13 +0200, Dominick Grift wrote: Let's not compare init scripts with dpkg scripts. The issue at hand here is that dpkg, and dpkg scripts do not install files with the correct context. So far as I can tell, that's very much _not_ the issue at hand. This bug is precisely about files created outside of the packaging system, not by it. init scripts are a common creator of such files (e.g. state in /run) but scripts downloading files from external locations are another; for example, see the bug marked as being blocked by this one. On a related note, dpkg script is not a term generally used within Debian. Are you referring to what we'd call maintainer scripts? (Pre/post removal/installation scripts.) As a Fedora user, i am not very familiar with dpkg, That much is clear. :-) but i can tell you that rpm, and the rpm script mechanism are SELinux aware. A quick grep of dpkg's source code will demonstrate that this is also the case for dpkg. A small bit of archaeology leads to 2005-06-11 Manoj Srivastava sriva...@debian.org * lib/star.c (ExtractFile, SetModes): If dpkg is compiled with SELinux, test once whether SELinux is enabled on the system. If it is enabled, find out the security context of the file from its path and either set what we think it should be or let the default security context for the process be applied. Regards, Adam -- 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/1381431927.19154.28.ca...@jacala.jungle.funky-badger.org
Bug#704657: debian/rules: Inconsistent required targets
On 04.04.2013 08:23, Philipp Hahn wrote: According to the lintian description in http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html build-arch and build-indep should be added to the paragraph above as required targets. The URL you quoted says that the targets are _recommended_ and will be required by policy in the future. I'm not sure how that equates to them being /currently/ required? Regards, Adam -- 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/82246d9d2ebf185125274e76e8abc...@mail.adsl.funky-badger.org
Bug#704657: debian/rules: Inconsistent required targets
On 04.04.2013 09:04, Bill Allombert wrote: On Thu, Apr 04, 2013 at 09:23:07AM +0200, Philipp Hahn wrote: Package: debian-policy Severity: normal Quoting from http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules The following targets are required... : clean, binary, binary-arch, binary-indep, build. ... build (required) build-arch (required), build-indep (required) According to the lintian description in http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html build-arch and build-indep should be added to the paragraph above as required targets. Lintian is wrong: afaics, lintian is perfectly correct; the submitter's reading of the quoted page is in error. The tag name and description both say recommended and I don't see anything in the description which suggests they are required. the official policy is the one written in debian-policy not in the lintian code. And lintian isn't attempting to claim otherwise. Regards, Adam -- 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/a236d40b782031d56eabd81fa214a...@mail.adsl.funky-badger.org
Bug#703022: debian-policy: Appendix G: Diversion example faulty (doesn't work for conffiles)
On 14.03.2013 17:34, Russ Allbery wrote: The last time I looked at this (which was several years ago), diverting conffiles had enough problems that it was tempting to just say that it didn't work reliably. I wonder if we should explicitly recommend against diverting conffiles, or if some of those problems have been cleaned up. fwiw, Policy 10.7.4 does say [t]wo packages that specify the same file as a conffile must conflict. [...] Neither alternatives nor diversions are likely to be appropriate in this case; in particular, dpkg does not handle diverted conffiles well but it's possibly not so easy to spot. Regards, Adam -- 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/d7a4e556618f666ef9a3a5b7f8223...@mail.adsl.funky-badger.org
Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements
On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote: On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: Oh, yes, I misunderstood that too. How about: These maintainer scripts must not call the upstart prgnstart/prgn, prgnrestart/prgn, prgnreload/prgn, or prgnstop/prgn interfaces directly. which uses the same term (interfaces) that is used for calling invoke-rc.d and update-rc.d? Looks good to me. Attached. Seconded. Regards, Adam -- 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/1331924957.28016.2.ca...@jacala.jungle.funky-badger.org
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Thu, 2009-06-04 at 14:14 +0200, Bill Allombert wrote: Consider this example: the safe printf way to do echo $BAR is printf %s\n $BAR (in case BAR hold a value like BAR=%s a) So printf is slightly unwiedly to use and it can create format string attack. It does, however, have the advantage of working if BAR contains -E. (This isn't a contrived example, it's why I recently changed the parsing of DEBUILD_LINTIAN_OPTS to use printf rather than echo; if there's a sane way of printing -E using echo I'd love to know what it is). Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture in *.dsc files
On Wed, 2009-05-27 at 11:19 -0700, Russ Allbery wrote:
Well, but that doesn't answer the more fundamental question. What does
an Architecture field like:
i386 amd64 all
in a *.dsc file mean? Currently, Policy is silent here.
That the binary packages referenced by the .dsc file include at least
one package that has Architecture: i386, at least one that has
Architecture: amd64 and at least one that has Architecture: all.
Can any ever appear in combination with architectures (if, for
example, the package builds some binary packages only on some
architectures and others on all architectures)?
From dpkg's point-of-view, the answer here appears to be no. The patch
introducing the feature includes this hunk:
+if (grep($_ eq 'any', @sourcearch)) {
+ # If we encounter one any then the other arches become insignificant.
+ @sourcearch = ('any');
+}
+$fields-{'Architecture'}= join(' ',@sourcearch);
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian.debian.org update plan?
On Thu, 2009-04-09 at 15:10 +0900, Hideki Yamane wrote: Just a question, how's about update lintian.d.o plan? Now it complains 3.8.1 is newer policy or so... ;) There's an update run currently in progress. We were hoping it might have finished by now, but it isn't quite there yet. Hopefully it won't be too much longer - it's currently at package 36,842 of 38,093 (source and binary packages) and processing binary packages with names starting x. Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523348: debian-policy: upgrading-checklist states policy 3.8.1.0 as unreleased
package debian-policy forcemerge 519706 523348 thanks Hi, Philipp Huebner wrote: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz still states policy 3.8.1.0 as unreleased, which is confusing to read while lintian already complains that 3.8.0 is outdated. This has already been reported (as #519706) and will be fixed in the next Policy release. Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 2009-02-12 at 19:35 +, Mark Hymers wrote: In gmane.linux.debian.devel.policy, you wrote: I think it's worth mentioning in the policy footnote that the Debian archive doesn't (well, won't, to be entirely accurate) support the feature and removing the suggestion that there is a frozen distribution. As such, I'd be quite happy with Colin's suggested patch. I should also clarify that we might support it at the moment, but I've no idea if it actually works. It seems that we can either 1) make sure it works or 2) drop it from being supported (although as people have said, just in the debian-specific case). Either of these is fine by me, but relying on something which hasn't been tested for 5 years is probably not that sensible. My opinion should be obvious by now, but for the record I'd vote for option two. I can't see any merit in maintaining support for it in Debian and officially killing it removes any expectation that it might work. Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Fri, 2009-02-13 at 19:20 -0800, Russ Allbery wrote: Here's a proposed patch that limits the footnote to only discussing the values that go into *.changes files, removes extraneous information about the relative risk of unstable vs. testing, and mentions the other values commonly seen in the Distribution field for Debian packages. I also lifted the note that the Debian archive software doesn't support multiple distributions into the main text instead of a footnote, since it isn't just informative information. [...] + The emtesting/em distribution, which cannot be + uploaded to directly, normally receives its packages + from the emunstable/em distribution after a short + time lag. However sometimes, such as during release + freezes before a new stable release or when a problem + in the emtesting/em distribution requires fixing + before the emunstable/em version can migrate, + direct uploads to emtesting/em are useful. This + distribution value is used for those exceptions. That section sounds slightly strange to me. It starts by saying that one cannot upload directly to testing, and finishes by indicating that a distribution of t-p-u is used to upload directly to testing. Maybe something like + before the emunstable/em version can migrate, + direct updates to a package in emtesting/em are useful. + This distribution value is used for these exceptions, + after approval from the release managers. ? [...] + emstable-security/em and emtesting-securityem ^ / The rest looks good to me; thanks. Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Sat, 2009-02-14 at 12:19 -0800, Russ Allbery wrote: I now have: + The emtesting/em distribution normally receives + its packages via the emunstable/em distribution + after a short time lag. However sometimes, such as + during release freezes before a new stable release or + when a problem in the emtesting/em distribution + requires fixing before the emunstable/em version + can migrate, direct updates to a package in + emtesting/em are useful. This distribution value + is used for those exceptions, after approval from the + release managers. for that paragraph. Does that look better? Yep, that all looks good to me; thanks. Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Sat, 2009-02-14 at 22:59 +0100, Kurt Roeckx wrote: As far as I know, the archive maps uploads to testing to testing-proposed-updates, and so both end up in t-p-u. That's correct. The s-p-u and t-p-u uploads I've made for devscripts all had either stable or testing in the changelog. Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multipledistributions
Colin Watson wrote, Thursday, February 12, 2009 10:47 AM For Debian's archive, I think this change is entirely reasonable. However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). [...] You should list emall/em distributions that the - package should be installed into. + package should be installed into. Note, however, that + the Debian archive only supports listing a single + distribution. Yeah, I'd be happy with that. Thanks, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, 2009-02-12 at 19:11 +0100, Bill Allombert wrote: I agree that dak not currently supporting multiple-distribution upload is not a reason to change policy about the format of the .changes files, since this is well supported by dpkg and other tools and can be useful with other upload queues. Yep, I've been more than convinced on that score by various replies already. Furthermore, generally, dak behaviour is not documented in Policy, but rather in the Developers reference and this suggest that this changes be documented there. I think it's worth mentioning in the policy footnote that the Debian archive doesn't (well, won't, to be entirely accurate) support the feature and removing the suggestion that there is a frozen distribution. As such, I'd be quite happy with Colin's suggested patch. Cheers, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
Package: debian-policy Version: 3.8.1.0 Severity: wishlist Hi, The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. I propose the following patch, against current git (I also took the opportunity to fold the old frozen distribution information into the testing section): diff --git a/policy.sgml b/policy.sgml index 36f51aa..66466c8 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3058,10 +3058,9 @@ Package: libc6 p In a file.changes/file file or parsed changelog output - this contains the (space-separated) name(s) of the - distribution(s) where this version of the package should - be installed. Valid distributions are determined by the - archive maintainers.footnote + this contains the name of the distribution where this version + of the package should be installed. Valid distributions are + determined by the archive maintainers.footnote Current distribution names are: taglist compact=compact tagemstable/em/tag @@ -3096,10 +3095,7 @@ Package: libc6 than unstable, but still risky. It is not possible to upload packages directly to emtesting/em. - /item - tagemfrozen/em/tag - item From time to time, the emtesting/em distribution enters a state of code-freeze in anticipation of release as a emstable/em @@ -3123,11 +3119,6 @@ Package: libc6 /taglist p - You should list emall/em distributions that the - package should be installed into. - /p - - p More information is available in the Debian Developer's Reference, section The Debian archive. /p Regards, Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: horizontal line in footnote #29
On Mon, 2008-12-29 at 10:30 -0800, Russ Allbery wrote: Ronny Standtke ronny.stand...@gmx.net writes: I just noticed that there is a horizontal line in footnote #29 which probably does not belong there: http://www.debian.org/doc/debian-policy/footnotes.html#f29 Huh, there is indeed, but I'm not sure why. Those pages are generated from DebianDoc-SGML source and there isn't anything strange that I can see about the SGML source: [...] I assume it must be a bug in debiandoc-sgml, but it's a very strange one. I'll file a bug against that package. fwiw, wrapping the paragraph in a section removes the line (although isn't an ideal solution). Adam -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#484511: Urgencies should all be lower case
On Sat, 2008-06-07 at 22:40 -0700, Russ Allbery wrote: [...] With this patch applied, I think that these bugs are now moot, but I wanted to check before closing them. Is there any further work required in britney to treat urgencies as case-insensitive, or does the change in the log file written by dak solve that problem as well? As I understand it, the change in dak means that the first time britney is aware of the packages urgency it will already have been lower-cased. Whilst britney still handles urgencies internally in a case-sensitive manner, it should never be receiving an initial urgency for a package which isn't in lower case. Assuming that I haven't missed anything above then I personally have no objections to closing the bugs. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Taking manoj's advice for how to get a practice inplace
Hi, Osamu Aoki wrote: [...] Dan, I know you are frequent BTS reporter. So I expect you to know better than newbie reporter. Please do not use bts command for this kind of situation. Please make sure to get full information to the package owner. I had to dig into bts web site. This is not nice and waist everyone's time. Not disagreeing with any of the above, but to correct a factual issue - please don't blame bts for people failing to include information in mails, particularly mails they sent directly. As can be seen from viewing either the headers or body of Dan's reassignment, the mail *was* *not* sent by bts - it's missing the X-BTS-Version header, the fairly tell-tale subject header and the automatically generated by bts comment in the body. A recent version of bts would also have added a Cc to [EMAIL PROTECTED] to the mail to control. As I said, I don't disagree with the sentiment, I just don't like seeing people or tools being blamed for things they weren't involved in :-) Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473439: debian-policy: Debian Policy inconsistent with Developer's Reference
On Sun, 2008-03-30 at 11:30 -0700, Russ Allbery wrote: Meike Reichle [EMAIL PROTECTED] writes: When doing my NM I noticed an inconsistency between the Debian Policy and the Developer's Reference concerning the use of the terms section and category. [...] The control field for specifying admin, net, utils, etc. is Section, so I think Policy wins here and main, contrib, and non-free should be called categories. For what it's worth, and possibly to add more confusion, dak uses the term component in this case. Adam
Re: should executables be permitted to update themselves?
On Sun, 2007-01-14 at 11:23 +0100, Marc Haber wrote: On Sun, Jan 14, 2007 at 12:26:15AM -0500, Michael Gilbert wrote: is there a policy on whether an executable is permitted to update itself? i personally believe that in order to maintain the security of the system, apt and apt alone should be used to install software updates. recently i submitted a bug on azureus about how it should not urge users to install updates outside of apt (http://bugs.debian.org/405997), which was quickly closed by the maintainer. jftr, the bug was not closed, but tagged wontfix. It was definitely closed: From: Shaun Jackman [EMAIL PROTECTED] To: Michael Gilbert [EMAIL PROTECTED], [EMAIL PROTECTED] The maintainer's attempt to tag it wontfix doesn't appear to have succeeded, most likely due to forgetting to CC control@ Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369912: debian-policy: 2.2 should be named 'categories'
On Friday, June 02, 2006 7:53 AM, Thomas Weber [EMAIL PROTECTED] wrote: [...] Policy's table of contents currently reads: 2.2. Sections 2.2.1. The main category 2.2.2. The contrib category 2.2.3. The non-free category 2.3. Copyright considerations 2.4. Sections where 2.4 are dpkg's sections. Thus, I suggest that 2.2 is changed to categories. If you're going to do that (and I'm certainly not objecting), it's probably worth tidying up the terminology used in 2.2 and 2.4 (and the introduction to section 2, in fact). What 2.2 and 2.4 refer to as categories are components as far as apt and dak (and therefore the Debian archive) are concerned. 2.4 also contains The `Section' field should be of the form: * _section_ if the package is in the _main_ category, * _segment/section_ if the package is in the _contrib_ or _non-free_ distribution areas. using category, segmentand distribution area to refer to the same thing within a single paragraph. The introduction to section 2 also uses both category and distribution area. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [bug] references to dpkg-shlibdeps should be dh_shlibdeps
On Friday, March 31, 2006 1:39 PM, Jari Aalto [EMAIL PROTECTED] wrote: Section: 8.6.2 How to use dpkg-shlibdeps and the shlibs files ! Put a call to dpkg-shlibdeps into your debian/rules file. If your package contains only compiled binaries and libraries (but no scripts), you can use a command such as: ! dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ debian/tmp/usr/lib/* [...] I believe the (!) lines should refer to dh_shlibdeps instead. Please check the policy manual for similar errors. I believe you're mistaken. The dpkg-shlibdeps in the first line is a hyperlink to section C.1.4, which describes dpkg-shlibdeps. Use of debhelper is not required in order to build packages, and documentation of such use does not belong in the policy manual. Similarly: [EMAIL PROTECTED]:~$ dpkg -S /usr/bin/dpkg-shlibdeps dpkg-dev: /usr/bin/dpkg-shlibdeps c.f. dpkg-shlibdeps(1) / dpkg-source(1). Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344158: The FHS is from 2000 and should be updated
package debian-policy
severity 344158 wishlist
merge 344158 230217
thanks
On Tuesday, December 20, 2005 2:17 PM, Michelle Konzack
[EMAIL PROTECTED] wrote:
Package: debian-policy
Version: 3.6.1.1
Severity: normal
Error description:
The Filesystem Hierarchy Standard in
/usr/share/doc/debian-policy/fhs/fhs.html/
should be updated to reflect the major changes to /sys, /srv, /media
The expanded version in that folder is indeed an older version (2.1).
/usr/share/doc/debian-policy/fhs-2.3.{html,pdf.gz,ps.gz,txt.gz} however are,
as their name suggests, version 2.3 of the standard, which is current.
The most likely reason for this arrangement is that Policy currently
requires adherence to version 2.1. There are already bugs open requesting
this to be updated, so I'm merging this.
Regards,
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
