Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks

El 15/4/24 a las 22:26, Bill Allombert escribió: On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: Package: base-files Version: 12.4+deb12u1 Followup-For: Bug #1039979 Control: tags -1 patch I attach a pat

Re: base-files: /var/run and /var/lock should not be absolute symlinks

reassign 1039979 debian-policy thanks Dear Policy editors: In this bug I'm asked to make /var/run and /var/lock symlinks to be relative. Maybe it's the right thing to do, but last time I tried to do that, this is what happened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345 [ Summar

Re: Does iproute2 moving config files to /usr/lib violate section 10.7.2?

El 17/9/23 a las 0:12, Daniel Gröber escribió: Sam, Russ, Bill, Thanks for your input. To be quite frank I still don't see how the interpretation of allowing configuration files outside of /etc can be supported based on the policy text. Hello. I apologize for not having read the discussion in

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

I wrote: I believe that by choosing the wording appropriately, we can still keep this desired property of Policy while still not mandating any given implementation. Sorry, that was terribly worded. I meant that we can avoid the hassle of documenting everything dh_installsystemd does and at the

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

El 10/9/23 a las 4:09, Russ Allbery escribió: I therefore would like to propose a first: I think Policy should simply say that any package that provides a system service should use debhelper and rely on dh_installsystemd to put the appropriate commands in its maintainer scripts. (We can then dis

Bug#1029831: debian-policy: Make required packages build-essential

El 28/1/23 a las 14:07, Ansgar escribió: +--- | The required packages are called build-essential, and include packages | with Priority "required" and additional packages. An informational | list of additional packages can be found in | /usr/share/doc/build-essential/list (which is contained in th

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 17:45, Julien Cristau escribió: Like I said in the debootstrap bug, I believe we should treat a case where a package is Priority: required but not actually required by the Essential set as a bug in package priorities, and neither debootstrap nor policy need to change. I take you

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 19:28, Sam Hartman escribió: "Santiago" == Santiago Vila writes: Santiago> I think you can't really estimate such thing. You seem to Santiago> imply that we have been allowing packages with missing Santiago> build-dependencies for a l

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 19:54, Bill Allombert escribió: BTW: Today I reported that kodi did not build without tzdata. But in the end this was not a missing build-dependency of kodi, but a missing *binary* dependency of one of the build-dependencies of kodi. So is there a service that detect such miss

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 18:23, Sam Hartman escribió: I think that the cost of going and adding all the build-depends on required-but-not-build-essential is not worth what I estimate we'd gain from having this extra information. I think you can't really estimate such thing. You seem to imply that we hav

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 17:16, Russ Allbery escribió: But if you are building new Debian packages, by definition you are not in a tiny minimal system case. build-essential is already somewhat arbitrary and chosen for convenience (most packages do not require a C++ compiler). Why not expand build-essent

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

El 4/1/23 a las 2:32, Sam Hartman escribió: "Santiago" == Santiago Vila writes: Santiago> As an example, packages tzdata, mount or e2fsprogs are not Santiago> build-essential and afaik have not been for a long time, Santiago> but there are still people who be

Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential

Package: debian-policy Version: 4.6.2.0 Severity: wishlist Hello. This is an attempt to put the basis for fixing this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 As an example, packages tzdata, mount or e2fsprogs are not build-essential and afaik have not been for a long time,

Bug#950440: debian-policy: Confusing conflation of Essential:yes w/ Priority:required

El 18/12/22 a las 15:34, Chris Hofstaedtler escribió: Package: mawk Version: 1.3.4.20200120-3.1 Priority: required base-files Pre-Depends awk, mawk Provides awk Could become Priority: optional? I can answer for that one. A long time ago, we decided to ensure that some implementation of awk was

Re: Bug#1009343: please consider adding Boost-1.0 and Expat to /usr/share/common-licenses

reassign 1009343 debian-policy thanks El 12/4/22 a las 5:41, Daniel Kahn Gillmor escribió: Package: base-files Severity: wishlist Version: 12.2 Expat and Boost-1.0 are both fairly common licenses in debian. I believe they are both well-defined, stable, and reasonably well-understood variants o

Re: Bug#1013195: base-files: Please add AGPL-3 license

reassign 1013195 debian-policy thanks El 18/6/22 a las 23:45, Salvo 'LtWorf' Tomaselli escribió: Package: base-files Version: 12.2 Severity: normal X-Debbugs-Cc: tipos...@tiscali.it Dear Maintainer, AGPL-3 license is not present in the base files. This forces me to include verbatim the very lo

Re: Bug#924094: base-files: Missing Artistic-2.0 in /usr/share/common-licenses/

reassign 924094 debian-policy thanks El 9/3/19 a las 15:13, Steffen Moeller escribió: Package: base-files Version: 10.1 Severity: normal Dear Maintainer, * What led up to the situation? I was packaging a tool with that license without shipping it. * What outcome did you expect instea

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote: > Since dpkg will not prevent upgrading of other packages while an > ``essential`` package is in an unconfigured state, all ``essential`` > packages must supply all of their core functionality even when > -unconfigured. If the packa

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote: > Since dpkg will not prevent upgrading of other packages while an > ``essential`` package is in an unconfigured state, all ``essential`` > packages must supply all of their core functionality even when > -unconfigured. If the packa

Bug#924401: base-files fails postinst when base-passwd is unpacked

> > In a practical level, because you already see what happens when > > you configure any package which uses users defined in /etc/passwd > > without a minimal /etc/passwd in place. Again in a practical level, > > once we know it, we can't pretend that we don't know it. > > That's what the tradi

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Thu, Mar 14, 2019 at 10:37:46AM +, Simon McVittie wrote: > On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote: > > The reason I'm often asked to add hacks to base-files.postinst is only > > that base-files is usually configured in the second place > > I t

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Thu, Mar 14, 2019 at 07:50:27AM +0100, Johannes Schauer wrote: > I agree that we should not expect maintainers to write numeric user and group > ids into their maintainer scripts. This is not only hard to write but also > hard > to read and maintain. In my opinion, using numeric ids should onl

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote: > I'm not advocating for doing "hacks here and there so that bootstrapping tools > work properly" as you put it but that we think about the question of whether > maybe there is a better way to populate an empty directory with softwa

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Tue, Mar 12, 2019 at 07:30:21PM +0100, Helmut Grohne wrote: > > Do any of them still don't know that base-passwd should be configured > > first because otherwise any other package using root (be it base-files > > or any other) will fail? I think this was already settled in the last > > discussi

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote: > Package: base-passwd,base-files,debian-policy > > Debian policy section 3.8 says: > > | Essential is defined as the minimal set of functionality that must be > | available and usable on the system at all times, even when packages >

Bug#924401: base-files fails postinst when base-passwd is unpacked

On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote: > Package: base-passwd,base-files,debian-policy > > Debian policy section 3.8 says: > > | Essential is defined as the minimal set of functionality that must be > | available and usable on the system at all times, even when packages >

Bug#824495: debian-policy: Source packages "can" declare relationships

On Thu, Nov 08, 2018 at 02:51:55PM +, Ian Jackson wrote: > [...] Looks ok at first read, maybe a little bit too much normative. One minor comment: > (i) a failure of the build, in which case the additional packages > MUST be declared in Build-Conflicts); As we talked before, that's

Bug#824495: debian-policy: Source packages "can" declare relationships

On Sat, Nov 03, 2018 at 03:42:20PM -0700, Russ Allbery wrote: > In a way, I don't think this goes far enough. Build-Conflicting with > something installed by debhelper would be incredibly painful and would > basically require the package be built in a chroot. I'm not sure what do you mean by "pa

Bug#824495: debian-policy: Source packages "can" declare relationships

> > While we are at it, I understand, because it would involve a huge > > amount of computation to determine, that we can't test every package > > against every other binary package to discover undeclared > > build-conflicts. > > Well, indeed. In fact, this is the reason why I don't see how we co

Re: base-files - please consider adding /usr/share/common-licenses/Unicode-Data

reassign 910548 debian-policy thanks On Sun, 7 Oct 2018, Paul Hardy wrote: > Package: base-files > Severity: wishlist > Tags: patch > > Hello, > > I recently formatted the Unicode Data license for the d/copyright file > of a Debian package that I created. I thought I would offer it to > Debian

Bug#299007: Transitioning perms of /usr/local

This would be a "pseudo-patch": Replace this: The "/usr/local" directory itself and all the subdirectories created by the package should (by default) have permissions 2775 (group- writable and set-group-id) and be owned by "root:staff". by this: The "/usr/local" directory itself and all the sub

Bug#299007: Transitioning perms of /usr/local

Hello Debian Policy people. This is to tell you that I've finally changed base-files in unstable to not create /etc/staff-group-for-usr-local anymore on new installs, following the TC decision about this in Bug #484841 and the transition plan explained in the file /etc/staff-group-for-usr-local it

Re: Bug #882628: base-files: Please ship CC0 in /usr/share/common-licences

reassign 882628 debian-policy thanks Dear Nicolas: The file /usr/share/doc/base-files/FAQ contains the rationale for this reassign. Please read it. Thanks.

Bug#299007: Transitioning perms of /usr/local

On Sun, Aug 06, 2017 at 08:03:23AM -0700, Sean Whitton wrote: > control: retitle -1 Transitioning perms of /usr/local > > Hello Santiago, > > The TC decision in #484841 is not yet reflected in Policy. > > We could close the bug by simply dropping the requirement that > /usr/local be group-writea

Bug#835451: debian-policy: Building as root should be discouraged

On Fri, Aug 04, 2017 at 03:42:34PM -0400, Sean Whitton wrote: > On Thu, Aug 03, 2017 at 03:43:56PM +, Mike Gabriel wrote: > > I am not saying that the build target must not be empty. I can be empty but > > the build-a ... build-n dependecies have to be moved away from the binary > > target and

Bug#835451: debian-policy: Building as root should be discouraged

On Wed, Aug 02, 2017 at 10:52:59AM -0400, Sean Whitton wrote: > control: tag -1 -patch > > Hello again Santiago, > > Some of us here at DebCamp have been reading your message and we're > still not sure of your intention. > > On Thu, Aug 25, 2016 at 09:41:26

Bug#835452: debian-policy: Deprecating dependency of "binary" on "build"

Package: debian-policy Version: 3.9.8 Severity: wishlist Greetings. Debian Policy 4.9 says: Both binary-* targets should depend on the build target, or on the appropriate build-arch or build-indep target, if provided, so that the package is built if it has not been already. I don't see the

Bug#835451: debian-policy: Building as root should be discouraged

Package: debian-policy Version: 3.9.8 Greetings. Debian Policy 4.9 says: For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the build target does not make much sense. For these packages it is good enough to provide two (or

Bug#824495: debian-policy: Source packages "can" declare relationships

Package: debian-policy Severity: wishlist Hello. Policy 7.7 says: (Bold in "can" is mine) Source packages that require certain binary packages to be installed or absent at the time of building the package *can* declare relationships to those binary packages. I interpret this "can" in the

Re: debian/copyright in source package

On Wed, Aug 26, 2015 at 11:14:48PM +0200, Thorsten Alteholz wrote: > On Tue, 25 Aug 2015, Santiago Vila wrote: > >Not having a debian/copyright file in the source package does not > >affect usability of the package in *any* way. > > If it is not possible to add the

Re: debian/copyright in source package

On Sun, 23 Aug 2015, Thorsten Alteholz wrote: > But policy says that there "should" be such a copyright file. Violating such a > clause is at least an important bug. I guess you refer to policy when it says that we could match "must" with "serious" and "should" with "important". However, the BTS

Re: debian/copyright in source package

On Thu, 20 Aug 2015, Charles Plessy wrote: > Dear Santiago and everybody, > > how about the following ? (in section 4.5) > > [...] Yes, please. Seconded. Would be nice to add some sort of rationale to policy.

Re: debian/copyright in source package

[ Dropping CC for Simon and Russ because I know for sure they are in -policy ]. On Sun, Aug 16, 2015 at 06:23:52PM +0200, Thorsten Alteholz wrote: > But what shall be the source for this generation? I was basically doing "cat debian/copyright.in LICENSE" Not anything AI-style, and not trying t

Re: debian/copyright in source package

> >2. Why would policy say "should" instead of "must", if we then do not > >allow for exceptions? (packages generating copyright file at build time). > > This is not my area, but why should there be an exception? To allow for the file to be automatically generated at build time, which in turn avo

debian/copyright in source package

Hello. I received two bugs about a missing debian/copyright in source package (the copyright file is generated at build time). Questions: 1. This seems a mass-bug filing, which last time I checked it is something that "should not be done" before asking in -devel. Did I miss the announcement abou

Re: Timezone name in Debian changelog format

On Fri, Jun 26, 2015 at 04:40:58AM +0200, Guillem Jover wrote: > So given that the timezone name has never been accepted, many > time-parsing functions ignore it, it is redundant, declared obsolete > by RFC5322 and Debian policy dropped an explicit reference to it due > to bug 569174. I'd say we sh

Bug#746514: Autoreconf during build

+ If your package includes the scripts config.sub and + config.guess, you should arrange for the versions + provided by the package autotools-dev be used + instead (see autotools-dev documentation for + details how to achieve that). This ensures that th

Bug#784248: developers-reference: wheezy is Debian 7 (7.0 is only the first release)

Package: developers-reference Version: 3.4.14 Tags: patch While we are at it, Debian 7 is preferred over Debian 7.0 if we refer to wheezy during all its lifetime, including all the point releases. Patch follows (to be applied after the previous one). diff --git a/developers-reference-3.4.14/pkgs

Bug#784244: developers-reference: suffix +deb8u1 is for stable uploads, even if they are not a NMU

Package: developers-reference Version: 3.4.14 Tags: patch The way I read the IRC logs in Bug#685646, suffixes like +deb8u1 are the preferred version numbering scheme for any upload to stable, regardless of them being Non Maintainer Uploads or Maintainer Uploads. The current text says "NMU" which

Bug#759260: [summary] Bug#759260: removal of the Extra priority.

On Tue, 18 Nov 2014, Charles Plessy wrote: > Le Mon, Nov 17, 2014 at 03:55:26PM +0100, Santiago Vila a écrit : > Hi Santiago, > > practically speaking, how do you or others use the Optional priority > to check that a package is not directly or transitively conflicting > wi

Re: Bug#758234: transitive dependencies

On Sat, Nov 15, 2014 at 04:31:37PM +, Simon McVittie wrote: > For the reasons Matthias and I have outlined, I think the current rules > are both unnecessary and harmful. Automating an unnecessary and harmful > thing does not make it any more necessary, or less harmful. My proposal would be to

Bug#759260: removal of the Extra priority.

Hmm. We drop things when we clearly see they have no purpose, or we see they are harmful. For example, some people claim that the rule about priorities and dependencies is actively harmful, and I think they have a point indeed. In this case, however, I fail to see the rationale for actually *drop

Bug#759260: [summary] Bug#759260: removal of the Extra priority.

On Mon, Nov 17, 2014 at 10:48:15PM +0900, Charles Plessy wrote: > One of the potential uses of the Extra priority was to allow for > co-installing all packages down to the Optional priority. However, > this goal is not seem realistic anymore given the current size of > the Debian archive, and inde

Bug#758234: transitive dependencies

On Sat, Nov 15, 2014 at 09:09:06AM +0100, Matthias Urlichs wrote: > If I read #759260 correctly, Gerrit Pape objected > to allowing depending on lower-priority packages and said that the current > "file a bug and raise the priority" process is just fine. However, IMHO it > clearly is, not because

Re: Bug#758234: it's actively harmful

On Wed, Oct 29, 2014 at 07:30:57PM +0100, Matthias Urlichs wrote: > That's obvious. What is not so obvious, to me, is why we would still > want the current policy in the first place, given that everything(?) > is resolved via dependencies these days. Maybe because current policy allows one to take

Re: Bug#758234: it's actively harmful

On Wed, Oct 29, 2014 at 01:30:55PM +, Simon McVittie wrote: > On 29/10/14 12:41, Santiago Vila wrote: > > If we are going to take that route, we might just make all libraries > > optional as a general rule. > > That seems reasonable to me, with the possible exception o

Re: Bug#758234: it's actively harmful

On Thu, Oct 23, 2014 at 03:04:43AM +0200, Adam Borowski wrote: > can't even be detected via automated means. Why not? -- 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.or

Re: Bug#758234: it's actively harmful

On Thu, Oct 23, 2014 at 01:37:11PM +0100, Simon McVittie wrote: > I agree with your analysis, although perhaps not the wording. Maybe > something like: > > # The priority of a package should be based on the functionality > # of the package itself, and not on whether high-priority packages > # depe

Re: Policy regarding /etc/profile.d

On Wed, Oct 15, 2014 at 11:20:21AM +0100, Simon McVittie wrote: > On 15/10/14 00:17, Santiago Vila wrote: > > Do we need a paragraph in policy saying explicitly "you should not use > > profile.d"? > > For some packages, like bash-completion and > packagekit-com

Policy regarding /etc/profile.d

Hello. For a lot of time, I was reluctant to modify /etc/profile to support /etc/profile.d because my understanding of policy, namely this: A program must not depend on environment variables to get reasonable defaults. (That's because these environment variables would

Bug#299007: Group staff in /usr/local: Moving forward

Hi. If the only thing we need here is a transition plan, here we go: I propose the following plan to change the *default* behaviour of group staff and /usr/local at the same time we completely keep backwards compatibility with already installed systems. First we modify base-files to do this: *

Re: Bug#621462: base-files: missing AGPL-3 license

reassign 621462 debian-policy thanks On Thu, 7 Apr 2011, onlyjob wrote: > Package: base-files > Version: 6.0squeeze1 > Severity: wishlist > Tags: patch > > AGPL-3 missing from /usr/share/common-licenses The debian policy group decides about this, not me (please read base-files FAQ). Reassigning

Re: Bug#620674: base-files: Please include the text of the Open Font License (OFL) in /usr/share/common-licenses

reassign 620674 debian-policy thanks On Sun, 3 Apr 2011, Christian Perrier wrote: > Package: base-files > Version: 6.1 > Severity: normal > > The Open Font License is quite universally considered as meeting the > DFSG. Indeed, several font packages in Debian main provide fonts > distributed unde

Re: Bug#608324: please add Affero license to /usr/share/common-licenses

reassign 608324 debian-policy thanks On Wed, 29 Dec 2010, Ana Guerrero wrote: > Package: base-files > Version: 6.0 > Severity: wishlist > > Hi, > > I have seen you did recently an update of the licenses from > http://ftp.gnu.org/gnu/Licenses/ but you did not include the Affero > license http://

Bug#436105: suggestion to add GPL-1 as a common licence

On Tue, 29 Jun 2010, Russ Allbery wrote: > Russ Allbery writes: > > > I therefore propose adding GPL version 1 to the list of licenses said by > > Policy to be in common-licenses and asking Santiago to include a copy in > > base-files. I'm not including a diff since it would just create merge >

Bug#284340: Please remove reference to UC in BSD license

On Sat, 12 Jun 2010, Russ Allbery wrote: > Russ Allbery writes: > > > 2. Apply the patch to Policy included below, which removes this license > >from the list of licenses we tell people to reference from > >/usr/share/common-licenses and explains why. > > This patch has now been merged

Bug#436105: suggestion to add GPL-1 as a common licence

On Thu, 10 Jun 2010, Russ Allbery wrote: > Given that, while I'm very sympathetic to Santiago's argument, I also > think that we should be able to represent in packages their upstream > licensing statement and not be implicitly relicensing them under later > versions of the GPL, and without includ

Bug#582495: debian-policy: extend UID range of user accounts

Hmm, I see this is already reported as Bug#161912. However, this report includes a patch :-) Feel free to merge them anyway. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.

Bug#582495: debian-policy: extend UID range of user accounts

Package: debian-policy Version: 3.8.4.0 Severity: wishlist On Thu, 20 May 2010, Roger Leigh wrote: > On 20/05/2010 20:43, Steve Langasek wrote: > > I don't think it's practical to ever get rid of the legacy UID range > > fragmentation in the 16-bit space. Better would be to plan a transition to

Re: Bug#569219: Document transitional and meta-packages

On Wed, 10 Feb 2010, Luca Falavigna wrote: > Package: developers-reference > Version: 3.4.3 > Severity: wishlist > Tags: patch > > We have several meta-packages and transitional packages in the archive, some > of them do not document that anywhere in their description. > > Users should be given

Re: Bug#565884: Please include CeCILL* licenses in common-licenses

reassign 565884 debian-policy thanks On Tue, 19 Jan 2010, Thibaut Paumard wrote: > Package: base-files > Version: 5.0.0 > Severity: wishlist > > Hi, > > there is a growing body of packages (or at least files) under [1]CeCILL > license in the archive. The CeCILL licenses are wordy and the proje

Re: Bug#541703: base-files: Please include FreeBSD license

reassign 541703 debian-policy thanks In this bug, I'm asked to include the FreeBSD license (which is not exactly the same as the BSD license) into common-licenses. As usual, I delegate this decision to the policy group (hence the reassign). [ IMHO, the proposed license is so small that we don't

Re: Bug#538392: group staff: moving forward

On Tue, 11 Aug 2009, Don Armstrong wrote: > On Tue, 11 Aug 2009, Santiago Vila wrote: > > Could we please move the default to 755, not 2775, like every other > > "normal" directory in Debian? There is little point in keeping those > > directories world-writable if

Re: Bug#538392: group staff: moving forward

Could we please move the default to 755, not 2775, like every other "normal" directory in Debian? There is little point in keeping those directories world-writable if they stop being owned by group staff. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsub

Bug#477990: Remove non-conflicting requirement in optional; relax dependencies

On Fri, 25 Apr 2008, Don Armstrong wrote: Package: debian-policy Version: 3.7.3.0 Severity: wishlist User: [EMAIL PROTECTED] UserTags: discussion Tag: patch The requirement of optional packages not to conflict with eachother and not to depend on essential packages are outdated, and appear to st

Bug#291460: Inclusion of Apache Software License versions in /usr/share/common-licenses

On Sun, 16 Mar 2008, Russ Allbery wrote: > Russ Allbery <[EMAIL PROTECTED]> writes: > > > I have gotten no further feedback on this proposal. I would like to > > resolve this bug for the next Policy release one way or the other. > > Could others reading the Policy list please express an opinion

Re: Bug#458385: New version of Artistic License

reassign 458385 debian-policy thanks On Sun, 30 Dec 2007, Allison Randal wrote: > Package: base-files > Version: 4.0.1 > Severity: wishlist > > I'd like to request the addition of the file: > > > > as "Artistic-2" in /usr/share/

Re: Bug#436105: suggestion to add GPL-1 as a common licence

reassign 436105 debian-policy thanks On Sun, 5 Aug 2007, Sam Hocevar wrote: > Package: base-files > Version: 4.0.0 > Severity: wishlist > >There are still many packages that mention the GPL version 1 in their > copyright file (around 350). Many Perl packages, but also Perl itself > and wides

Re: Bug#435476: base-files: add MIT License as a common license

reassign 435476 debian-policy thanks On Wed, 1 Aug 2007, Carl Fürstenberg wrote: > Package: base-files > Version: 4.0.0 > Severity: wishlist > > I've seen plenty of instances of the usage of MIT License. Wouldn't it > be optimal to include it as a common license? Maybe, or maybe not. I prefer t

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

On Sat, 28 Jul 2007, Florian Weimer wrote: > * Russ Allbery: > > > Andreas Barth <[EMAIL PROTECTED]> writes: > >> * Florian Weimer ([EMAIL PROTECTED]) [070630 10:16]: > > > >>> But do we really want to license everything which is "GPL version 2 or > >>> later" under the GPL version 3? > > > >>> An

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

On Sat, 30 Jun 2007, Florian Weimer wrote: > * Santiago Vila: > > > + file. Packages should not refer to GPL and LGPL symlinks in > > + that directory since different, incompatible versions of these > > + licenses have been published by the

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

On Sat, 30 Jun 2007, Robert Millan wrote: > On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote: > > + file. Packages should not refer to GPL and LGPL symlinks in > > + that directory since different, incompatible versions of these > > +

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

+ file. Packages should not refer to GPL and LGPL symlinks in + that directory since different, incompatible versions of these + licenses have been published by the Free Software Foundation, + hence using the symlinks could lead to ambiguity. I disagree with this.

Bug#431109: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

> This proposal does essentialy two things: > > - Disambiguate GPL/LGPL versioning requirement by extending it to any DFSG > compatible version the FSF may publish. > > - Deprecate use of symlinks, since they're a source of problems (as exposed > by GPLv3, see http://lists.debian.org/debi

Launch of GNU GPLv3

FYI: The FSF will release the GNU GPL version 3 this Friday. See: http://lists.gnu.org/archive/html/info-gnu/2007-06/msg00013.html Before anybody submits a bug report against base-files: Is there an official statement from Debian about the DFSG-free status of GPLv3? I would like to put it in com

Bug#420701: debian-policy: GFDL is now in common-licenses

Package: debian-policy Version: 3.7.2.2 base-files_4.0.0, just uploaded for unstable, has now the GFDL in common-licenses (as both GFDL-1.2 and a symlink GFDL -> GFDL-1.2). Therefore, the paragraph in policy saying "Note that the GFDL is new here, and the license file may not yet be in place in"

Re: Bug#401173: base-file: include GFDL and more licences in /usr/share/common-licenses/

reassign 401173 debian-policy thanks Note to the submitter: This bug does not belong to base-files. Please read base-files FAQ! On Fri, 1 Dec 2006, Jari Aalto wrote: > Package: base-files > Version: 4 > Severity: normal > > The list of licenses is limited in: > > $ ls -1 /usr/share/common

Re: Bug#381729: Artistic licence

reassign 381729 debian-policy severity 381729 wishlist thanks Licenses in /usr/share/common-licenses are added or removed if the debian-policy group says they should be added or removed, as this is definitely something I don't want to decide as base-files maintainer. Please see "Why isn't license

Bug#348336: improve section on shared config files

On Mon, 30 Jan 2006, cobaco (aka Bart Cornelis) wrote: > On Sunday 29 January 2006 02:36, Santiago Vila wrote: > > +Sometimes two or more packgages need to be able to modify > > the +same configuration file. One such case is were related > > packages

Bug#348336: improve section on shared config files

+Sometimes two or more packgages need to be able to modify the +same configuration file. One such case is were related packages +share a configuration file (e.g. bash and other bourn compatible +shells share /etc/profile). You are implicitly saying t

Bug#299007: base-files: Insecure PATH

On Wed, 16 Mar 2005, Brendan O'Dea wrote: > On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: > >In this report, the submitter complains about /usr/local/bin being in > >the PATH by default at the same time directories under /usr/local are > >root:sta

Bug#299007: base-files: Insecure PATH

On Fri, 11 Mar 2005, Bill Allombert wrote: > On Fri, Mar 11, 2005 at 01:39:28PM +0100, Santiago Vila wrote: > > In this report, the submitter complains about /usr/local/bin being in > > the PATH by default at the same time directories under /usr/local are > > root:staff an

Bug#299007: base-files: Insecure PATH

In this report, the submitter complains about /usr/local/bin being in the PATH by default at the same time directories under /usr/local are root:staff and world-writable. His complain is based on the existence of become-any-group-but-root bugs. If this is a bug at all, I think we should probably d

Re: shell script sniplets in /usr/bin?

On Sun, 30 Jan 2005, Goswin von Brederlow wrote: > Where do you want to put gettext.sh? Once in every gettext-base or > only once in gettext-base-common? I don't know, maybe in the same package as GNU.Gettext.dll :-) (which is to say: first things first, before that there will be C# support) Is

Re: shell script sniplets in /usr/bin?

On Sun, 30 Jan 2005, sean finney wrote: > think about the purpose path is supposed to serve. the bash man page > says PATH is "The search path for commands". it mentions nothing of > shell scripts to be included/sourced. This is from bash(1): . filename [arguments] source filename [

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005, Bill Allombert wrote: > On Mon, Jan 24, 2005 at 02:13:07PM +0100, Santiago Vila wrote: > > On Mon, 24 Jan 2005, Bill Allombert wrote: > > > > > On Mon, Jan 24, 2005 at 01:25:44PM +0100, Santiago Vila wrote: > > > > On Mon, 24 J

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005, Bill Allombert wrote: > On Mon, Jan 24, 2005 at 01:25:44PM +0100, Santiago Vila wrote: > > On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote: > > Yes, I understand that, and I mostly agree. Now please write a lintian > > warning for PT_GNU_STACK. Mass bug

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005, Bill Allombert wrote: > On Mon, Jan 24, 2005 at 01:25:44PM +0100, Santiago Vila wrote: > > On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote: > > Yes, I understand that, and I mostly agree. Now please write a lintian > > warning for PT_GNU_STACK. Mass bug

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote: > On Mon, Jan 24, 2005 at 01:46:30AM +0100, Santiago Vila wrote: > > That's the correct explanation, yes. It has never been a bug to build > > a package using stable if the dependencies are compatible with the > > one

Bug#291631: cmp/diff/etc. lack PT_GNU_STACK header

On Mon, 24 Jan 2005 [EMAIL PROTECTED] wrote: > I made a statistic on my machine: > 1341 are '-' and 76 are '?' so less than 1% has the problem. > > More importantly, there are all binaries that have been build a long > time ago, with the exception of diffutils and rcs binaries. > > Since diffuti

  1   2   3   4   5   6   >