Bug#944920: Revise terminology used to specify requirements
On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote: > +The Release Team may, at their discretion, downgrade a Policy requirement > +to a Policy recommendation for a given release of the Debian distribution. > +This may be done for only a specific package or for the archive as a > +whole. This provision is intended to provide flexibility to balance the > +quality standards of the distribution against the release schedule and the > +importance of making a stable release. I don't think this aligns to the current release team practice, which provides a canonical list of points that are considered policy requirements:[1] | The purpose of this document is to be a correct, complete and canonical | list of issues that merit a "serious" bug under the clause "a severe | violation of Debian policy". Bastian [1]: https://release.debian.org/bullseye/rc_policy.txt -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Bug#942051: debian-policy: [4.9] requirement to write only to /tmp, /var/tmp, ${TMPDIR} is too strict
On Wed, Oct 09, 2019 at 05:51:53PM +0200, Ansgar Burchardt wrote: > While checking the upgrade checklist I noticed this new requirement: > +--- > | 4.9 > |Required targets must not write outside of the unpacked source > |package tree, except for TMPDIR, /tmp and /var/tmp. > +--- > The wording is a bit too strict and should be relaxed. There are > other paths that should be fine to be written to during the build > process, for example /dev/shm, /run/lock[1], or possibly anything > below /proc/ for processes spawned by the build process. Why do you think package builds should be allowed to use /run/lock? It records system state. The use of /dev/shm is an implementation detail of the shm implementation in libc. I don't think using the shm stuff counts as writing. If you take the strict approach, then writing to stdout and stderr would be forbidden as well. Regards, Bastian -- Ahead warp factor one, Mr. Sulu.
Re: Bug#919507: Reboot required patch for Debian policy
On Thu, Jan 17, 2019 at 09:10:16AM -0600, Karl O. Pinc wrote: > Documents /var/run/reboot-required and > /var/run/reboot-required.pkgs. /var/run is not longer a thing, so: s#/var## Bastian -- Pain is a thing of the mind. The mind can be controlled. -- Spock, "Operation -- Annihilate!" stardate 3287.2
Re: Bug#776413: The priority of the ed package
Hi On Tue, Oct 16, 2018 at 11:49:58AM +0100, Ian Jackson wrote: > This makes it sound theoretical, or a question of breaking people's > `finger macros'. That is indeed annoying. But there is a much more > serious practical point, which Paul Hardy touches on. How many people are using "ed" and not for example the still installed "ex"? Even historic documents (https://twitter.com/0xUID/status/1051208357850345472) only list ex for that purpose. > There are still situations, even in modern systems, where the terminal > connection is limited to a serial line or equivalent. In that > situation full-screen editors tend to malfunction because they do not > know the screen size (or, sometimes, terminal type). Serial lines have absolutely no problem with vim or similar stuff. ANSI command sequences work on all of them. You may need to restrict yourself to 80x25. There is exactly one exception: a 3215 terminal on a s390 vm. > Conversely, ed works perfectly. It can also be used as a pager (since > less doesn't work properly either). We have "more". Bastian -- Dismissed. That's a Star Fleet expression for, "Get out." -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud"
Re: Bug#905817: UID range of DyanmicUser overlaps with existing definitions in debian-policy
On Sat, Sep 15, 2018 at 08:47:19AM -0700, Sean Whitton wrote: > > The overlapping ranges are: > > 6-64999: > > Globally allocated by the Debian project, but only created on demand. > > The ids are allocated centrally and statically, but the actual accounts > > are only created on users’ systems on demand. How many UID in this range are actually allocated right now? As the allocations are static, we can shrink the range without producing further problems. > > There is also: > > 65536-4294967293: > > Dynamically allocated user accounts. By default adduser will not > > allocate UIDs and GIDs in this range, to ease compatibility with legacy > > systems where uid_t is still 16 bits. This range is now used in other ways and is not longer general available for user accounts. systemd-nspawn uses them, but in the meantime each local user is also assigned a range in /etc/subuid and /etc/subgid. Due to this all, uids for normal system operation must fit into the range 0-65534. Regards, Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Re: Javascript team policy and rejection of node-three binary package
On Tue, Mar 06, 2018 at 02:12:52PM +, Ian Jackson wrote:
> Pirate Praveen writes ("Javascript team policy and rejection of node-three
> binary package"):
> > 1. Node.js has standard locations for discovering installed packages
> > which is different from browser targeted javascript libraries.
> > Node.js expects pure js modules to be installed at /usr/lib/nodejs but
> > javascript libraries are installed at /usr/share/javascript
> This is not an argument in favour of separate packages AFAICT ?
No, it is not.
> > 2. Dependency on nodejs is required only during build or when other
> > Node.js modules depend on it. a browser targeted library does not need
> > to depend on nodejs package.
> This could be solved by dropping the nodejs dependency from all the
> nodejs module packages and requiring top-level applications to depend
> on nodejs.
And what problem would arise from this dependency? What does it break,
so it _must_ not exist?
Bastian
--
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, "Obsession", stardate 3620.7
Bug#872587: debian-policy: please document "Important: yes"
On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote: > Do you have any idea how long we can expect to wait until dpkg supports > the field? I would suggest that we wait until dpkg has defined > behaviour for the field, as it will make documenting it much easier. It > will also allow us to be more confident that there is no serious > disagreement about the purpose of the field. If he just want to use the field, no change to dpkg is necessary. dpkg supports user defined fields since at least 15 years, when d-i started to rely on them. See deb-src-control(5) for information. Bastian -- Fascinating, a totally parochial attitude. -- Spock, "Metamorphosis", stardate 3219.8
Bug#765499: Patch to make policy document 32-bit uids
On Thu, Jan 22, 2015 at 04:44:22PM +, Matthew Vernon wrote: Here's a patch to document the 32-bit nature of UIDs, in line with Ben's suggestion (which seems sound to me). I miss the special case of 32-bit wide -2, aka nobody as used by nfs. It should be reserved at least. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, Obsession, stardate 3620.7 -- 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/20150125132706.ga11...@mail.waldi.eu.org
Re: Policy §10.5 and .jar file noticeable exception
On Wed, Jul 24, 2013 at 03:55:38PM +0300, Eugene Zhukov wrote: I encountered a Lintian warning executable-not-elf-or-script with one of my packages and then I learned about outstanding Lintian-debian-policy bug #539315. How about fixing the policy by adding an exception for .jar files? How do you execute .jar files? binfmt-misc on Linux? On kFreeBSD? Bastian PS: I used binfmt-misc a long time ago to execute mpeg 1 layer 3 audio files. -- If I can have honesty, it's easier to overlook mistakes. -- Kirk, Space Seed, stardate 3141.9 -- 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/20130726094918.ga22...@mail.waldi.eu.org
Re: License statement of the debconf specification
On Sat, Mar 03, 2012 at 10:45:39AM -0400, Joey Hess wrote: Russ Allbery wrote: 3. Neither the name of the Debian Project nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. Clause 3 is the advertising clause, isn't it? The license statement explicitly says without that clause. So, the license in debconf's own copyright file would seem most appropriate. Nope. Clause 3 of the original BSD license is the advertising clause: | All advertising materials mentioning features or use of this software | must display the following acknowledgement: “This product includes | software developed by the University of California, Berkeley and its | contributors.” Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 -- 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/20120303153911.ga28...@wavehammer.waldi.eu.org
Re: New field Package-List in .dsc
On Thu, Mar 24, 2011 at 04:25:46PM +0100, Raphael Hertzog wrote: First line is always the source entry. Do you want this constraint part of the definition or a implementation detail? Bastian -- No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, Spock's Brain, stardate 5431.6 -- 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/20110326091131.ga19...@wavehammer.waldi.eu.org
Re: Bug#619131: New field Package-List in .dsc
On Sat, Mar 26, 2011 at 09:52:38AM +0100, Raphael Hertzog wrote: On Thu, 24 Mar 2011, Russ Allbery wrote: The missing architecture was my immediate thought as well, since for a moment I thought ftp-master might need it, but then I realized that the override settings are arch: all. So I'm ambivalent. But apparently the wanna-build team would like to have this information as well (to know which source packages build arch: all packages). So I'm going to add it and I'll follow you advice of replacing spaces by commas. That way we still have the possibility to add supplementary columns in the future if needed. On second thought, I think it is time to make this a key-value list instead of bare values. Then we can add or remove values without disrupting other users of the infos. Also a vendor may explicitely add new values if they think they need it. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- 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/20110326092019.gb19...@wavehammer.waldi.eu.org
Re: New field Package-List in .dsc
On Thu, Mar 24, 2011 at 03:14:00PM +0100, Raphael Hertzog wrote: It looks like this: Package-List: src:dpkg admin required Is there a reason for not listing the type explicit for every entry? Something like this: dpkg source admin required dpkg deb admin required dselect udeb admin optional Bastian -- The face of war has never changed. Surely it is more logical to heal than to kill. -- Surak of Vulcan, The Savage Curtain, stardate 5906.5 -- 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/20110325212405.ga10...@wavehammer.waldi.eu.org
Re: Bug#582495: debian-policy: extend UID range of user accounts
On Fri, May 21, 2010 at 01:27:38PM -0700, Steve Langasek wrote: Does anyone think there's a need for another reserved ID range somewhere above 16 bits to replace this one? Well, we could just reserve the upper half of the 32 bit space (and document 2^32-2 as (NFS) nobody and 2^32-1 as don't use at the same time. Bastian -- Immortality consists largely of boredom. -- Zefrem Cochrane, Metamorphosis, stardate 3219.8 -- 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/20100524112301.ga15...@wavehammer.waldi.eu.org
Bug#562506: init scripts should not use set -e
On Mon, Dec 28, 2009 at 03:44:53PM -0800, Russ Allbery wrote: That seems reasonable, although I think we should also point out the problems with using set -e when starting a daemon, namely that you need to be sure to wrap the start-stop-daemon invocation in a conditional so that you can properly report errors, rather than just letting the init script die. set -e produces problems like this: #546743. Bastian -- He's dead, Jim. -- McCoy, The Devil in the Dark, stardate 3196.1 -- 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/20100227122054.ga10...@wavehammer.waldi.eu.org
Re: [PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
On Sun, Nov 22, 2009 at 02:58:30PM -0600, Steve Langasek wrote: Wouldn't it make more sense to expose this as a subdirectory of /sys rather than /lib, since this appears to be a kernel interface? /sys/security is the mount point for securityfs, which is used by the whole bunch of small security modules (not selinux and smack). 3) The default for fedora, gentoo, and Debian has been /selinux Where does Red Hat place theirs? Fedora is Red Hat. Bastian -- Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: I created a elaborate test case tos ee if we are in a chroot, if not if /proc/1 is actually /sbin/init, and that telinit exists (example below). Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Does this need discussion? Yes, it is highly sysvinit and Linux specific. Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 10:40:56AM +0100, Bastian Blank wrote: On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: I created a elaborate test case tos ee if we are in a chroot, if not if /proc/1 is actually /sbin/init, and that telinit exists (example below). Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Oh, and this could be made even easier by defining file-based triggers in the package providing init instead of doing it in all the dependencies. Bastian -- Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Even if the security system has changed? I dont't think so (better safe than sorry). Which security system? Is there a list of packages trying to reexec init? The listed bugs only show libsepol and libselinux, both do nothing in respect of that. Selinux can only be activated on boot anyway. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, Obsession, stardate 3620.7 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 11:22:35AM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. Even if the security system has changed? I dont't think so (better safe than sorry). Which security system? Is there a list of packages trying to reexec init? The listed bugs only show libsepol and libselinux, both do nothing in respect of that. So far, I hav not needed to. But I can see where there is a major change in libselinux (we are at the same soname so far, so this has not happened), and the new libselinux is needed to not have people bypass init.d's security setup by exploiting a bug in the old system (perhaps a change is needed in libselinux/libsepol to even load new policy). If that happens, not being able to re-exec init can be grounds for a failure to boot (as it is now if you enable selinux and init can't load policy). Reexec init is only needed to make it change the security domain of itself. Rules reload would be done somewhere else. Selinux can only be activated on boot anyway. What does this have to do with the price of rice in china? The scenario of interest is a system with selinux enabled and in enforcing, and a upgrade of security libraries (and policy, perhaps). Policy is not coupled with init or the libs. This is a problem between the kernel and the policy tools. I still don't see what you want to tell me. Bastian -- Witch! Witch! They'll burn ya! -- Hag, Tomorrow is Yesterday, stardate unknown -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 07:23:12AM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: Oh, and this could be made even easier by defining file-based triggers in the package providing init instead of doing it in all the dependencies. In which case it definitely deserves discussion, some coordination, and perhaps a policy proposal, as well as a more generic solution. Which files would we be triggering on? The used libs. Bastian -- Landru! Guide us! -- A Beta 3-oid, The Return of the Archons, stardate 3157.4 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 01:28:33PM -0500, Manoj Srivastava wrote: On Mon, Oct 26 2009, Bastian Blank wrote: Policy is not coupled with init or the libs. This is a problem between the kernel and the policy tools. This is not totally true: init loads the initial policy, and that means that linking with new versions of selinux libs makes a difference at startup. It is, however, irrelevant for upgrades -- We are currently speaking about upgrades. And I doubt that init have the permission to load the policy again after transiting away from the initial startup role. Which is why currently, as I have said before, re-execing init is opportunistic. This may or may not be the case in the future. No. It is not. All the re-exec init calles are only to start it with new libs and there is no change visible for that role. Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, Wolf in the Fold, stardate 3615.4 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS
On Wed, Mar 07, 2007 at 06:08:52PM +0100, Lucas Nussbaum wrote: Bug #209008 proposed to have a common interface to tell packages to do parallel building (make -j). You can't set a generic value. For example: A machine with 6 cpus but only 256MiB ram. Building glibc with -j6 is no problem. Building gcj-* with -j6 is not possible. Bastian -- You're dead, Jim. -- McCoy, Amok Time, stardate 3372.7 signature.asc Description: Digital signature
Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 04:36:08PM +0200, Wouter Verhelst wrote: It has come to my attention that the gem package is currently built using 'make -j 4', to have four compiler processes running at the same time. This is a bit troublesome for the poor m68k buildd, which is now suffering under High Load And Constant Swapping (HLACS). DoS against the buildd? I was going to file a flaming bug of severity 'serious', quoting the relevant paragraph from Policy which forbids such behaviour, except it's not there. Well, at least I can't find it... There is none. But you may consider it as an attack against the infrastructure. Bastian -- There is an order of things in this universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 signature.asc Description: Digital signature
Re: Should we allow packages to depend on packages with lower priority values?
On Mon, Dec 08, 2003 at 03:17:19PM +0100, Marc Haber wrote: I don't see other reasons behind the requirement, but am of course open to arguments. Did I overlook something? We work on dependency resolving while bootstraping the system. parsing the whole Packages files needs at least 6mb additional memory at this time. bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 signature.asc Description: Digital signature
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Fri, Jun 06, 2003 at 12:39:45PM -0700, Chris Waters wrote: And since we do make mistakes here, and since any change can cause a ripple-effect, making other packages suddenly violate this clause, and since violations of this are both quite harmless and hard-to-spot, how about we change it to not be a must? Then the ftp-masters can still try to ensure that it holds true, but people won't freak out about it. it will break the ability to just use packages with priority = standard and try to install one of them. bastian -- Murder is contrary to the laws of man and God. -- M-5 Computer, The Ultimate Computer, stardate 4731.3 pgpRLnwQxiMVl.pgp Description: PGP signature
