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
Hi
its fine, go for it.
--
bye, Joerg
signature.asc
Description: PGP signature
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
oth
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 Debian systems the ful
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 cu
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
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
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
> 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 thre
> 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
>> 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 nowada
> The list of all sections is defined in policy:
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
> As for descriptions of each of those, you could use:
> http://packages.debian.org/unstable/
> But there are 2 additional entries in the second list:
> base
> debian-
>> * 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 "p
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 writes:
>> We require, and have seen nothing to convince us o
>>> 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
>>
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 ofte
>> 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 no
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 change
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
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 f
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 fro
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
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
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 pe
>> 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
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 opini
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
Snow-Man: Please don't talk to me. You have demonstra
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 vulnerab
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
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 NE
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
[..] trying to avoid extra dependencies on gnumeric is like trying to
plug one hole in the t
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 all
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 rec
33 matches
Mail list logo
