Bug#955005: Its fine

On 15734 March 1977, Joerg Jaspert wrote: its fine, go for it. So, whatever, for the policy foo, the patch as presented earlier in this bug is seconded, go for it, commit, change the policy. -- bye, Joerg signature.asc Description: PGP signature

Bug#955005: Its fine

Hi its fine, go for it. -- bye, Joerg signature.asc Description: PGP signature

Re: Bits from the DPL (April 2019)

On 15389 March 1977, Sean Whitton wrote: Thus, it would be something of a layering violation if the normative part of Policy were to require or recommend using a particular tool to implement its other normative content. Perhaps, though, there's no way for Debian to implement such a change

Bug#883950: [INPUT REQUIRED] Re: Bug#883950: debian-policy: allow specifying common licenses with only the identifier

On 14900 March 1977, Markus Koschany wrote: > Allow the use of the short-license identifier only in the form: > Files: foo.bar > Copyright: 2017, Smith > License: [GPL-2+] > without the extra standalone paragraph which will mean exactly the > same as > License: GPL-2+ > On

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

On 14717 March 1977, Andreas Henriksson wrote: > Can't help but wonder why not just remove the "extra" (and mentioning it > as deprecated in upgrade notes) rather than explicitly documenting it as > deprecated. I guess keeping it around is useful to avoid people > mass-bug-filing RC-bugs for all

Bug#679326: debian-policy: DMUA should covered more explicitly

On 12987 March 1977, Russ Allbery wrote: now that the implementation changed (http://lists.debian.org/87vcf6lbw4@deep-thought.43-1.org), I propose the following patch to obsolete the DM-Upload-Allowed field. This patch creates a new subsection for obsoleted fields. Alternatively we can

Bug#679326: debian-policy: DMUA should covered more explicitly

On 12890 March 1977, Axel Beckert wrote: the policy currently doesn't explain all aspects and especially not all restrictions of the DM-Upload-Allowed field usage. Not that the implementation WILL change. And I see no reason to explain the implementation inside policy. -- bye, Joerg Some AM

Bug#671503: general: APT repository format is not documented

On 12836 March 1977, David Kalnischkies wrote: I would personal tend toward ftp-master to be the authority with reference implementation being dak, but they have no public mailinglist and dak isn't used by all derivatives… debian-dak@lists.d.o On 12836 March 1977, Russ Allbery wrote: I

Re: [proposal] remove the requirement to compress documentation

There's more than just my /usr. This system runs off a 160GB SSD, so 500MB is more like 0.5% of the available storage space here. 160GB is in the low end of the available storage of modern systems, and probably (gut feeling) about average of systems bought in the past few years (my

Bug#581011: Maintainer/Uploaders nomenclature

1) The Maintainer field can contain only ONE contributor, whereas there may be several to the package. 2) The Uploaders field can contain several people, whereas - technically - there can be only one uploader. You see this term to limited to the actual upload happening. Uploaders are those

Bug#577666: debian-policy: Section list missing: base debian-installer

No. base is dead, there is no base. I now remember you there were announcement ... Funny thing is that it points only to: vmelilo (1.5.4) [debports] Linux kernel boot loader for m68k VME processor boards. This is strange. No, just the ports archive having an outdated and nowadays

Re: does /var/games have to be deleted on purge? (if it's empty..)

* Whether it makes sense given Debian semantics or not, users just don't expect removing packages to, from their perspective, destroy data. Other distributions don't seem to do this. We are talking about purging, not removal, thus I consider this argument invalid. I expect purge to

Re: Sponsorship requirements and copyright files

First, let me apologize for my last mail in this thread, it had been a little too rude/harsh/direct. My fault, sorry. (We all should calm down, flaming won't help) On 11696 March 1977, Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: We require, and have seen nothing to convince us

Re: Sponsorship requirements and copyright files

The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as

Bug#487201: MPL-license

On 11440 March 1977, Russ Allbery wrote: By pure numbers, that's not a sufficient number of packages to warrant inclusion in common-licenses according to the criteria previously discussed here. (I think it falls short by hundreds.) From experience in NEW the MPL is unfortunately used often

Bug#484511: Urgencies should all be lower case

But I might look at patches changing it (or better, bzr trees ready to merge), if someone really wants it changed. Patch attached. I can also create a bzr repository if that's helpful. For the future - yes please. Including a changelog entry. I also added a fix for logging that I'm not

Bug#484511: Urgencies should all be lower case

On 11408 March 1977, Joey Hess wrote: The code in dak, in the current form, is there since 2002-02-13, when jennifer (today process_unchecked) got added to the repository. Most probably something similar existed in the code before this. Its also nearly unchanged since then, with changes being

Bug#484511: Urgencies should all be lower case

On 11407 March 1977, Russ Allbery wrote: You make it sound like it's an ASN.1 encoder or something. If Joerg says that he absolutely won't change dak, I wont change it. But I might look at patches changing it (or better, bzr trees ready to merge), if someone really wants it changed. Why

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

On 11274 March 1977, Ian Jackson wrote: ---+++--- If the Maintainer address points to a mailing list then that list must be configured to accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes mail from the BTS, all mails from the

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

On 11274 March 1977, Bernd Zeimetz wrote: ---+++--- If the Maintainer address points to a mailing list then that list must be configured to accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes mail from the BTS, all mails from the

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

On 11260 March 1977, Lucas Nussbaum wrote: ---+++--- If the Maintainer address points to a mailing list then that list must be configured to accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes mail from the BTS, all mails from the

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

Package: debian-policy Severity: normal Hi I think policy should include some words on the usage of Mailinglists as a Maintainer: address. The current 3.3 The maintainer of a package reads ------ Every package must have a Debian maintainer (the maintainer may be one person or a group of

Bug#459868: debian-policy: Definition of Maintainer: when using a mailing list

On 11259 March 1977, Raphael Hertzog wrote: On Wed, 09 Jan 2008, Joerg Jaspert wrote: ---+++--- If the Maintainer address points to a mailing list then that list must be configured to accept mail from those role accounts in Debian used to send automated mails regarding the package

Bug#114920: [PROPOSAL] remove foolish consistency in perl module names

Packages which contain perl modules should provide virtual packages that correspond to the primary module or modules in the package. The naming convention is that for module 'Foo::Bar', the package should provide 'libfoo-bar-perl'. This may be used as the package's name if

Re: First draft of review of policy must usage

On 10818 March 1977, Luk Claes wrote: Can everyone please focus on the release and discuss things that don't help to release on December 4th at all till after that date? No, the release is no reason to stop everything else. -- bye Joerg exa Snow-Man: Please don't talk to me. You have

Re: Policy delegation

On 10818 March 1977, Michael Meskes wrote: On Wed, Oct 25, 2006 at 11:29:48AM +1000, Anthony Towns wrote: I'm withdrawing the Package Policy Committee delegation made by Branden in June last year, in: ... Would you care to tell us why? Simple to answer - Manoj has a different opinion about

Bug#392362: [PROPOSAL] Add should not embed code from other packages

On 10804 March 1977, Neil McGovern wrote: Title:Embedding code provided in other packages Synopsis: Packages should not include or embed code that is available in other packages. Rationale:If a package contains embeded code, it becomes vulnerable

Re: Are packages allowed to ship files in /srv?

On 10723 March 1977, Russ Allbery wrote: Are Debian packages allowed to ship files in /srv? (Not just create a structure in /srv in postinst of an initial install, or point default configuration files at /srv, but actually ship files in subdirectories of /srv?) The relevant rationale in the

Re: Including more licenses in 12.5

On 10690 March 1977, Manoj Srivastava wrote: How about including more licenses in the list in 12.5 (and at the same time adding them to base-files). How many packages are there under this license? I have no numbers. I just proposed those two licenses because I see them often in NEW.

Including more licenses in 12.5

Hi How about including more licenses in the list in 12.5 (and at the same time adding them to base-files). Good candidates, IMO, are: The python license, the ZPL, the ruby license. -- bye Joerg elmo [..] trying to avoid extra dependencies on gnumeric is like trying to plug one hole in

Bug#39830: [AMENDMENT]: get rid of undocumented(7) symlinks

Manoj Srivastava [EMAIL PROTECTED] writes: + There should be a manual page at least for every program. If + no manual page is available, this is considered as a bug and + should be reported to the Debian Bug Tracking System (the + maintainer of the package is allowed

Re: /usr/doc

Joey Hess [EMAIL PROTECTED] writes: So would anyone murder me if the code in debhelper to make postinst scripts manage /usr/doc links just went missing? This would of course cause the link to go away when packages were upgraded to versions built with the new debhelper. Since we'll be