So will test be grandfathered?
Manoj suggested this language for 10.1: > -- > 10.1 > > Except for the following shell builtins, additional commands provided > by a Debian shell installed in /bin/sh shall be considered to have the > same status as executables in the filesystem for the purpose of name > conflicts with other packages. As a result, they must either provide > the same functionality as the other program or else discuss with the > other maintainer and debian-devel which one should be renamed. > > > Note: > A Posix-conformant shell is allowed to build in *anything*, and if > it's not a Posix-specified utility that's being built in, then it can > have *any behavior whatsoever*. The presence of two commands with > conflicting behaviour adds an unacceptable uncertainty when scripts > are executed, and this has to be resolved. > -- Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > What we do still need is the list of grandfathered builtins. While we wait for the official list, can we at least assume that "test" will be grandfathered, and consequently that "-a" and "-o" should be avoided? -- Thomas Hood
Re: So will test be grandfathered?
I wrote (on debian-devel): > While we wait for the official list, can we at least assume that > "test" will be grandfathered, and consequently that "-a" and "-o" > should be avoided? Oops -- I meant to send this to debian-policy. The broader context of my question was bug #267142 "debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)". Please follow up to debian-policy. -- Thomas Hood
Re: Introducing pmount in Debian / New plugdev group
On Tue, 09 Nov 2004 18:50:39 +0100, Martin Pitt wrote: > However, I was not satisfied with this solution because of several > reasons: [Several excellent reasons] > So the Ubuntu approach is a bit different: we let hal run as normal > user, do not modify /etc/fstab at all and instead use a program > called 'pmount' (policy mount) that allows normal users to mount > removable devices without an /etc/fstab entries. All sounds good. Have you heard that mount's upstream is looking for someone to adopt mount (and the rest of util-linux)? Interested? -- Thomas Hood
Re: Linux Core Consortium
On Sun, 12 Dec 2004 18:40:07 +0100, Joey Hess wrote: > Andrew Suffield wrote: >> > http://wiki.debian.net/index.cgi?ReleaseProposals >> >> Every single one of these falls into one of these four groups: > > Please note the "wiki" in the URL and the "edit page" button on the > page. Inspired by A.S.'s comment I've just sorted the proposals into four groups, though not exactly the ones he defined. -- Thomas Hood
Re: removing in postrm rc*.d symlinks that I did not create
It has been suggested that you install symlinks[*] but provide an /etc/default/foo file with an environment variable that forcibly disables the service when set to "off" or whatever, and that the initscript be written so that it overrides this forced disabling when run from the command line. Of course this can be made to work but it is a bad hack. Bad because it doesn't use Debian's standard mechanism for configuring services. The idea behind initscripts is that they do what they are told when they are run. sysv-rc and file-rc implement two different schemes for determining when they are run and with what arguments. I don't see why people keep trying to undermine the standard mechanism. Under the circumstances you describe it is reasonable to refrain from installing symlinks[*] in runlevel directories. I think you are justified in deleting the symlinks on purge too, so I suggest you simply override lintian and linda. [*] (or do the file-rc equivalent, which happens automatically if file-rc is installed because you use update-rc.d) -- Thomas Hood
Re: How to ensure packages generated from -source are installable?
On Sun, 02 Jan 2005 04:20:04 +0100, William Ballard wrote: > Kernel module source packages generated Debian packages which may not be > installable. For instance, alsa-source does not depend on alsa-base, > but the generated alsa-modules does. ndiswrapper-source does the same > with ndiswrapper-utils. Right. Do you regard this as a problem? > Is there a flag to dpkg to refuse to install unless dependencies are > met? I am not sure what you mean. That is dpkg's default behavior. > What ends up happening now is the package ends up installing broken. I am not sure what you mean by this. Here is what happens when I install an alsa-modules package in the absence of alsa-base: [EMAIL PROTECTED]:/usr/src$ sudo dpkg -i alsa-modules-2.4.27-1-686_1.0.7-3~unreleased1+10.00.Custom_i386.deb Selecting previously deselected package alsa-modules-2.4.27-1-686. (Reading database ... 192428 files and directories currently installed.) Unpacking alsa-modules-2.4.27-1-686 (from alsa-modules-2.4.27-1-686_1.0.7-3~unreleased1+10.00.Custom_i386.deb) ... dpkg: dependency problems prevent configuration of alsa-modules-2.4.27-1-686: alsa-modules-2.4.27-1-686 depends on alsa-base (>= 1.0.1-1); however: Package alsa-base is not installed. dpkg: error processing alsa-modules-2.4.27-1-686 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: alsa-modules-2.4.27-1-686 If you are complaining about the fact that dpkg leaves behind unpacked files when it aborts then I suggest you file a bug report against dpkg. This can then be merged with #15162 and the twelve reports already merged with it which complain about dpkg leaving behind unpacked files in various other circumstances. > The generalized form of this question is how does one deal with > missing dependencies when using dpkg and not apt. One downloads the missing packages and dpkg --install's them. BTW have you tried module-assistant? -- Thomas Hood
Re: please post listing and status of NEW queue
On Sat, 12 Feb 2005 01:20:13 +0100, Anibal Monsalve Salazar wrote: > http://qa.debian.org/~anibal/debian-NEW.html > > The above page is based on previous work done by Peter Reinholdtsen. > > It still work in progress. > > Any input is welcome. Thanks for providing this page. It would be nice if there were a "status" field that showed whether or not an ftp master had looked at the package and, if so, what his opinion of the package was. E.g., * new * looks OK * needs investigation I don't know whether or not ftp masters would be willing to make use of such a feature, though. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 12 Feb 2005 01:20:13 +0100, Anibal Monsalve Salazar wrote: > Any input is welcome. It would be nice if the page indicated which of the binary packages is new. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 2005-02-12 at 18:59 -0600, David Moreno Garza wrote: > On Sat, 2005-02-12 at 22:52 +0100, Thomas Hood wrote: > > It would be nice if the page indicated which of the binary packages is new. > > The binary column indicates those created within the source package. > Every source package on the summary is new, that's why it is on the NEW > queue. Not every source package is new to the archive. Some of the source packages are already present in the archive but are in the queue because they contain binary packages that are not already present in the archive. It would be nice if the page indicated which of the _binary_ packages is new. -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, 13 Feb 2005 13:30:11 +0100, Steinar H. Gunderson wrote: > Current d-i writes the following line to the beginning of /etc/hosts: > >127.0.0.1localhost.localdomain localhost This is correct. > Traditionally, this confuses some programs; at least pvm used to have > problems with this, and I'm fairly sure cfengine2 doesn't like it either What problems? If there are problems then they probably arise from a faulty _combination_ of /etc/hosts, hostname, /etc/nsswitch.conf and /etc/resolv.conf settings. > so we've changed to > >127.0.0.1. localhost > > However, now we've suddenly discovered that _other_ programs get confused by > this! So revert the change? > In particular, if you use an NFSv4-patched mount, it does a > gethostname() and resolves that, which returns 127.0.0.1, which in turn makes > it happily use that as a client identifier to the remote server. (This breaks > when two or more such clients connect, obviously.) Make your /etc/hosts look like this: 127.0.0.1localhost.localdomain localhost w.x.y.z . Make w.x.y.z either the permanent IP address of your machine's permanently connected network adapter, or, if it does not have one of those, "127.0.1.1". -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Sun, 06 Mar 2005 00:20:13 +0100, Paul Hampson wrote: > Hmm. I would think that the better solution (the less surprising > solution) would be to leave out the ALSA modules from the Debian > kernel package, since we have a seperate package of ALSA modules > which _does_ depend on alsa-base. That's not a bad idea. We already have the problem that the ALSA drivers in the kernel-image packages are out of date relative to the ALSA libraries in alsa-lib. (Currently, the drivers in kernel-image-2.6.8 are version 1.0.4 but alsa-lib in sarge is version 1.0.8.) Omitting the ALSA drivers from kernel-image packages would solve this problem by forcing people to install up-to-date alsa-modules packages. On Fri, 04 Mar 2005 20:20:10 +0100, Josselin Mouette wrote: > As long as the linux26 installation ends up with both sound modules > loaded, that's a bug that needs to be fixed, though. Another option > would be to put the alsa modules in separate packages, just like pcmcia > modules. There already exist separate alsa modules packages. Currently we only build them for 2.4 kernels, though. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 13:50:10 +0100, Josselin Mouette wrote: > Without alsa-base installed, hotplug and discover will load both > modules, resulting in various disasters depending on the hardware. It's > not because things work with your setup that they are suitable for a > stable Debian release. Actually, this isn't true for 2.6 kernels. By default, discover loads ALSA modules into 2.6 kernels. The alsa-base/alsa-utils duo still has its uses, though, even if you are running 2.6. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switchconf: Orphaning or removing?
On Wed, 09 Mar 2005 12:40:15 +0100, martin f krafft wrote: > I think switchconf is nice because it ties in well with guessnet, > and because it's lean and mean and does exactly what it should, no > more and no less. I agree that switchconf should be kept around so long as there is nothing else in Debian that provides the same functionality. laptop-net also contains a configuration file switching mechanism. I believe that Chris Hanson (laptop-net's author) was once thinking of repackaging this separately from laptop-net. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 00:10:12 +0100, Christoph Hellwig wrote: > It's not a depency in any way. I play sound just fine with OSS drivers > without the ALSA mess getting in my way anywhere. On Mon, 07 Mar 2005 13:50:10 +0100, Josselin Mouette wrote: > Without alsa-base installed, hotplug and discover will load both > modules, resulting in various disasters depending on the hardware. It's > not because things work with your setup that they are suitable for a > stable Debian release. In theory I guess there should be an oss package that was the homologue of the alsa-base package. It would include files that would blacklist ALSA modules, just as alsa-base blacklists OSS modules. These packages would Conflict with each other and 2.6 kernel-image packages would Depend on their disjunction. An alternative is to drop ALSA modules from the 2.6 kernel-image packages. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: > Actually, the proposed solution that raised some approval was to split > out the ALSA modules, just like the pcmcia modules. I raised this idea on #debian-kernel and it was shot down.[0] [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html As one of the ALSA maintainers, I have done what I can about this problem. People who want to use ALSA can install alsa-base which blacklists OSS modules. If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a problem because in that case nothing enforces the mutual exclusion of OSS and ALSA modules. If linux26 doesn't install alsa-base then perhaps it should do so. Even better, possibly, would be to give the user a choice between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; if she chooses OSS then she gets the (currently nonexistent) "oss" package which blacklists ALSA modules. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 02:50:04 +0100, Steve Langasek wrote: > Considering you're talking about solutions that require updates to > kernel-image packages *anyway*, why has no one suggested adding the > necessary blacklist entries to these packages? k-i packages aren't the right place to put the blacklists because more than one of them can be installed at once. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 01:10:12 +0100, Josselin Mouette wrote: > Davide, would you agree with making gnome-media depend on something like > "alsa-base | kernel-image-2.4", to ensure sound is working properly upon > installation? I don't see why gnome-media should be involved. This problem has nothing specifically to do with GNOME. Also, the dependency you suggest would prevent people who install non-Debian 2.4 kernels from using OSS. Here is another idea. We create a new binary package "sound-system-chooser" which contains blacklists for both OSS and ALSA and provides a debconf interface that the administrator can use to disable either or both of the sound systems. Blacklists would be removed from alsa-base. k-i 2.6 and alsa-base would both Depend on sound-system-chooser. This would solve another problem with the current alsa-base, viz., that removing it isn't enough to enable OSS again -- alsa-base has to be purged in order to remove the hotplug blacklist file that it contains. sound-system-chooser could be generated from the alsa-driver source package. Anyone see anything wrong with this idea? P.S. I apologize for all my non-threading posts on this topic. My webmain interface apparently doesn't support In-Reply-To headers. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stateless linux in Debian
I am interested in this subject. http://panopticon.csustan.edu/thood/readonly-root.html -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 22:00:15 +0100, Thomas Hood wrote: > Here is another idea. We create a new binary package > "sound-system-chooser" which contains blacklists for both OSS and ALSA and > provides a debconf interface that the administrator can use to disable > either or both of the sound systems. Blacklists would be removed from > alsa-base. k-i 2.6 and alsa-base would both Depend on > sound-system-chooser. This would solve another problem with the current > alsa-base, viz., that removing it isn't enough to enable OSS again -- > alsa-base has to be purged in order to remove the hotplug blacklist file > that it contains. sound-system-chooser could be generated from > the alsa-driver source package. I have implemented this in alsa-driver, calling the new binary package 'sound-base'. One runs "dpkg-reconfigure sound-base" to change sound system. Josselin Mouette (and any other interested parties): Please test! http://www.aglu.demon.nl/alsa/ -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#272066: Patch?
debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories. The function already refrains from deleting directories.
Any objections? Please reply to [EMAIL PROTECTED], not to the list.
Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
>
> --- /etc/init.d/bootclean.sh 2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>
> [ "$VERBOSE" != no ] && echo -n " /var/run"
> ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
> -exec rm -f -- {} \; )
> rm -f /var/run/.clean
> set -o noclobber
"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to use lsb init-functions
In trying to convert the initscripts in the "initscripts" package to use the logging functions in /lib/lsb/init-functions I have run into some problems. Currently there are two sets of functions intended to implement the several kinds of messages normally output by Debian and Ubuntu initscripts. The first is for reporting the starting and stopping of services: log_daemon_msg "Foo" "bar" ; log_progress_msg "baz" ; log_end_msg 0 Debian: Foo: bar baz. Ubuntu: * Foo bar [ ok ] The second is for reporting actions to be taken: log_action_msg "Foo" Debian: Foo. Ubuntu: * Foo The third is for reporting actions to be taken and their completion: log_action_begin_msg "Foo" ; log_action_cont_msg "bar" ; log_action_end_msg 0 Debian: Foo...bar...done. Ubuntu: * Foo... * bar... [ ok ] In addition there is a function for reporting success: log_success_msg "Foo" Debian:Foo Ubuntu:* Foo one for reporting failure: log_failure_msg "Foo" Debian:* Foo [asterisk is red] Ubuntu:* Foo [asterisk is red] and a function for warning: log_warning_msg "Foo" Debian:* Foo [asterisk is amber] Ubuntu:* Foo [asterisk is amber] Finally there is a log_begin_msg which seems to be obsolete. Now my question. Suppose I have a script that does something and I want to do the following: * Report that foo will be done * Do foo * Report that foo has now been done I am supposed to do: log_action_begin_msg "Will do foo" foo log_action_end_msg $? But the problem is that foo may produce output and this will break up the nice single-line format. I don't mind deverting stdout to /dev/null, but I am reluctant to divert stderr to /dev/null and error messages will also break up formatting: Debian:Foo...ERROR failed. [in red] Ubuntu:* Foo... ERROR [fail][in red] It seems that in many cases we will have to adopt the following schema: log_action_msg "Will do foo" if foo ; then log_success_msg "Done foo." ; else log_failure_msg "Foo failed." ; fi Is this what I should do, or is there another solution I am overlooking; or do we need more functions; or does the whole system need to be reworked? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Not delete symlinks to directories in /var/run/ ?
[Please forgive the duplicate, but I first sent this with a useless
Subject line.]
debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories. The function already refrains from deleting directories.
Any objections? Please reply to [EMAIL PROTECTED], not to the list.
Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
>
> --- /etc/init.d/bootclean.sh 2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>
> [ "$VERBOSE" != no ] && echo -n " /var/run"
> ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
> -exec rm -f -- {} \; )
> rm -f /var/run/.clean
> set -o noclobber
"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ALSA packager needed
The ALSA packaging team needs help. We really need someone with expertise in programming for the ALSA library. If you are able to help us, please contact us at [EMAIL PROTECTED] -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Co-maintainers sought
I seek co-maintainers for: mwavem thinkpad, tpctl resolvconf -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ALSA packager needed
First, thanks to those who responded to my earlier call. In addition to people knowledgeable about the ALSA userspace library I would like to find someone willing to help maintain the driver side. ALSA drivers are included in Linux 2.6, but we still ship an alsa-source package for use with Linux 2.4 and for those who want the very latest drivers on 2.6. When upstream makes a new release we make a new release of alsa-source, which along with linux-sound-base and alsa-base is generated from the alsa-driver source package. Updating the Debian packaging at such times is fairly easy, but it does involve some work. There is a new upstream release candidate out now (1.0.11rc1) and I would like to take the opportunity to go through the process with the new volunteer. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please test new sysvinit, sysv-rc, initscripts
A new version of sysvinit (binary packages sysvinit, sysv-rc and initscripts)
has
just been uploaded to experimental. The reason for sending it to experimental
is
that a large number of changes were made, thus increasing the probability of
errors.
And errors in sysvinit can be especially troublesome to users. We would like
the
release to get some testing by people who know what to do if things go wrong.
If
you can, please give us a hand and install version 2.86.ds1-7.
After installation you should have a tmpfs mounted on /run. This has been
created
for the use of that handful of packages that need a place to store run time
state
files independently of networking. Recently mentioned as needing such a
location
was the bootchart package. Ifupdown and resolvconf can use it too, instead of
/dev/shm/.
After rebooting you should have logs of the fsck runs in
/var/log/fsck/check{root,fs}.
You should have a rotated /var/log/dmesg, and /var/log/boot if you are using
bootlogd.
Please check /etc/motd. Is this now a symlink to /var/run/motd and are its
contents
correct?
Try switching to runlevel 1. Does this work as expected?
Now shut down. Any problems?
Boot with INIT_VERBOSE=yes kernel parameter. Is the boot more verbose?
Any glitches in any of the messages?
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Anthony Towns wrote: > is there any possibility > of putting it under /lib/run or /boot/early-writable-fs instead of > introducing a new directory on / that's of very limited use? That is certainly possible, but I don't see anything wrong with putting it at the top level either. FWIW I asked Chris Yeoh for his opinion on the name and he said that /run sounded preferable to both /etc/run and /lib/run. > Huh? URL? I'm surprised there isn't at least a pro-forma objection to > creating a new directory in /. The main condition is that we have good reasons for adding it. Also, its use should be restricted to Debian "infrastructure" packages until such time as the directory gets officially recognized by the FHS. > > I do not count "It's ugly!" as a strong reason. > > You should; especially since it seems solvable by hiding it in /lib > alongside /lib/modules. The problem is that some people find /lib/run uglier than /run. ;) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Anthony Towns: > Mmm; privately asking someone who works on the FHS is a different thing > to asking on the FHS lists, or actually talking to our users. True. > Claiming support from the FHS guys on the basis of a conversation with > Chris doesn't seem appropriate; anymore than "-policy support" would be an > appropriate claim if Manoj had said it looked okay. Agreed. Fortunately, I didn't claim that. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Anthony Towns wrote: > A possible concern is people seeing /run and thinking "ah, there's a > directory I can use for stuff", and having it be used instead of > /var/run or $TMPDIR or /var/lib or /var/cache for things it's not > appropriate for. I think that everyone agrees that /run is to be used only for those very few purposes for which /var/run cannot be used. If there are worries about abuse then I would suggest the addition of a sentence to Policy forbidding such abuse. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Steve Langasek wrote: > Are there really any init scripts that need to write out data prior > to checkroot.sh (the point at which /run would be writeable by > default on the rootfs)? Well, it would be nice if fsck logs could be stored in /run until /var/log/ is available for writing. It would be nice if mtab could be kept in /run so that it could be written to as filesystems are being mounted. Currently these sorts of things are delayed using one trick or another. > by constraining the actual *implementation* of /run (barring ugly > hacking of the init scripts), you've made the system less suitable > for a third use case: > > - memory is at a premium, disk is not Tmpfs memory can be swapped out, so is this even a hypothetical problem? > [...] the point is that design-wise, there's simply no reason > to make the choice for the user of *what* is mounted on /run, only > to specify that *something* must be (and that it must be writable); One advantage to supporting only tmpfs on /run is that the assumption can then be made that the hierarchy is empty at boot; there are no stale files and no cleaning has to be done. If there are reasons why some users would not want to put a tmpfs at /run (which there may well be, although I haven't heard them yet) then we can of course support this. Then either initscripts will have to clean the directory or programs using it will have to contend with stale files. Cleaning cannot occur until the filesystem underlying /run is mounted read-write and programs must not use /run before the cleaning has been completed; it would probably be easier to drop the cleanliness-at-boot guarantee and let programs clean out their own stale files. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test the new sysvinit
So, has anyone tested the new packages? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
Anthony Towns:
> Sorry, I was paraphrasing above. The actual definition is "Essential
> shared libraries and kernel modules", and "The /lib directory contains
> those shared library images needed to boot the system and run the
> commands in the root filesystem, ie. by binaries in /bin and /sbin."
>
> Shared library image seems a pretty clear reference to .so files, and
> binaries is usually used to talk about ELF executables as opposed to
> scripts ("executables" being the general term).
>
> /lib is the right place for the above, and the FHS's too-limited
> definition is wrong. To my mind, /lib also seems the right place for a
> /run directory.
>
> Note the definition for /usr/lib is "Libraries for programming and
> packages" and "/usr/lib includes object files, libraries, and internal
> binaries that are not intended to be executed directly by users or
> shell scripts." and /var/lib is "Variable state information" and "This
> hierarchy holds state information pertaining to an application or the
> system. State information is data that programs modify while they run,
> and that pertains to one specific host."
>
> Combining these two, and adding the "...needed to boot the system"
> qualifier seems like it would perfectly cover the above requirements
> and /run.
Let me see if I have understood the argument. Let's call the new
directory 'R' for now.
/lib is, like R, a directory required for programs needed
to boot the system and run commands in the root filesystem;
and /var/lib is, like R, a place where data is stored.
We just heard "lib" twice! So /lib is the right place for R.
I don't think that an argument from the meaning of "lib" can get
much traction because /lib, /usr/lib and /var/lib are so different.
(I'll guess that these differences are there because:
* /usr/lib contained both application code and application data
in the old days;
* When application data was removed from /usr/lib it was placed
in /var/lib, which missed the opportunity to choose a more
appropriate name such as '/var/data';
* When /usr/share was split out of /usr/lib, no /share was split
out of /lib. So whereas scripts can be kept out of /usr/lib,
they can't be kept out of /lib because there is no better
place to put them if they have to be on the root filesystem.)
But there are problems with this particular argument as I have
paraphrased it (probably distorting it). First, if we accept the
reasoning steps then the conclusion ought to be that the right value
for R is "/lib/lib". What went wrong? Well, first, we missed the
fact that /lib isn't the only directory required for programs needed
to boot the system and run commands on the root filesystem; /sbin
and /bin and sometimes other top-level directories are also required.
So if we add _another_ directory with the same supporting role as
them then it should be, like them, in the root directory. Hence R
should be /. Second, we missed the fact that the
function of R is more analogous to /var/run than to /var/lib, and so
should have a basename of 'run' rather than 'lib'. Hence R should
be /run.
Briefly, if R is like /var/run except that it supports programs
needed to boot the system and run commands on the root filesystem,
then it should be another "run" directory, but at the top level.
Here's another possible argument:
Putting R in /lib spoils the otherwise read-only
character of that directory.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Anthony Towns wrote: > Developers have been known not to be completely familiar with policy, > but it's admins and upstream programmers that I'm particularly > thinking of. I don't see any problems arising from rampant /run use by _admins_. They are always free to do what they want with their systems. As for upstream programmers, most of them can't use /run because their software doesn't run with root privileges. Others can only use /run insofar as Debian and admins let them do so. So this brings us back to policy. I don't think that Debian would ever be accused of lacking zeal in enforcing its Policy. :) Cheers, -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/run vs. /lib/run
Any other defenders of /lib/run? Of /run? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
> Heh. You know, you could've just said "Yes, my heart is set on /run" > right at the start and saved us all a lot of trouble... Let's just say that you aren't doing very well at reading my heart. :) Here's what I think about /run, or rather, R: * A tmpfs R elegantly solves a handful of tricky problems. * There are no good technical reasons not to implement R. * There is no FHS prohibition of R. * Other proposed solutions are technically inferior, mostly because they are more complex. * Various locations for R are possible and the choice ultimately rests on aesthetic considerations about which people disagree. Since the choice of location isn't that important, I'd have no objection to putting R at /lib/run if there were something like a consensus in favor of that location. > So why don't we go with [making the technical changes necessary to > ensure /var is mounted early]? Thomas? > > Here are the cases: [...] > For (d) and (e) you need special handling; using /run as a tmpfs and > setting up /var/run -> /run symlinks on both / and /var. That's pretty > special handling [...] This is where I stop and ask why we would impose such a maintenance burden on ourselves when there is an alternative that does not impose such a burden. The answer, I take it, is that the handful of programs, H, that would use R can then use /var/run instead. The burden on H's maintainers of knowing that their programs face special storage problems is shifted onto the sysvinit maintainers and admins who have to ensure that writable space is shoved under /var/run by the time any of the H tries to write there. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
Gabor Gombas wrote: > ... I'd like to have a check for /run (or /lib/run or whatever) > being empty at the end of the boot process The new mountvirtfs prints such warnings for all the "virtual" filesystems. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
> > Tmpfs memory can be swapped out, so is this even a hypothetical > > problem? > > Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out. > > That still leaves the question of just which features we want to require > from our non-Linux kernels for basic operation, I guess. Yes, I don't know what problems would arise in non-Linux Debians. Both the Hurd and FreeBSD do have "memory" filesystems (tmpfs and mfs, respectively), but know more about this I do not. > Sounds to me like this will play havoc with idempotence of init > scripts; anyway, why would "mount /run and clean it" be anything > less than an atomic operation from the viewpoint of other init > scripts? If /run is on the root filesystem then it is mounted long before it can be cleaned (after S10checkroot.sh). If /run is a separate filesystem then, yes, it can be cleaned immediately after it is mounted (after S35mountall.sh). -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
First, thanks to Lars for drawing our attention to an important topic and for taking an initiative that is long overdue. Lars, I agree fully with what you say. When it comes to team maintenance I would go even further than you do. You say: > Mandatory teams for packages seems ridiculous to me. > Lots of packages are so small that having to arrange a > team for them, even if it is only the effort to set up > and subscribe to a team mailing list, is wasteful. Not > everyone likes to work in a close team, either, and we > shouldn't exclude them. I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. Second, putting packages in the custody of a team makes it easy for a tired maintainer to relinquish control. If the team works via an alioth project then there are many benefits. Code is kept under version control and thus backed up; the change history can be easily viewed by anyone; the mailing list becomes an easily browsed history of package development. Team maintainership is working very well for some other distributions. I would support requiring team maintainership because TM will be beneficial in almost all cases and making it a requirement it cuts off a lot of useless discussion. There are several packages in Debian that are notoriously undermaintained and whose maintainers have mused from time to time about getting help, but haven't bothered to do it. They should be forced to get help, or to give up maintaining those packages. Consistent with this view, I have just created teams for all my packages even though most of them are mature. I am glad to have the help; having new people to work with has given me some new ideas. Combined with the principle of non-responsibility (constitution §2.1), the institution of exclusive solitary package ownership has made some Debian packages into bastions of untended bugs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
I wrote: > I don't think that it is ridiculous to require that every package have > a team behind it---i.e., at least two maintainers. First, if someone > can't find ONE other person willing to be named as a co-maintainer of > a given package then I would seriously doubt that that package (or > that person) is an asset to Debian. Erinn Clark wrote: > There are plenty of people who are maintaining packages alone > that are doing an excellent job True. However, the issue in question is whether or not it would be better if they maintained in teams. > Forcing team maintenance on people would result in very few > technical enhancements for such maintainers How do you know? I would expect most packages to benefit. Every person brings different expertise to the table. > It just seems to me like telling responsible DDs who've done a > stellar job that they need a babysitter is a bit... insulting. This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Erinn Clark wrote: > For maintainers who are doing a lot of good work, there's simply not > enough to justify more people. Once there's already a certain level of > efficiency, adding another person is not going to increase it, and will > likely decrease it. I can't see the point of enforcing this as a rule, There is a point if it helps more than it hurts. That is how rules have to be judged. Now, you might say that rules are stupid and those people who need help should just go and get it. But experience has shown that, too often, they don't. How much would this rule "hurt" those lone ranger maintainers you are talking about, the ones who package everything perfectly and cannot possibly do any better? It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. But when Lone falls off his horse he'll be glad that Tonto is nearby. In other words, this rule can have only positive effects. :) > > This is not a fair characterization of what the introduction of > > a two-maintainer rule would be doing. No one should be insulted > > by general rule changes designed to make Debian work better. > > Bureaucracy is often designed to do lots of things "better" and it often > doesn't achieve them. It creates needless hassle, more 'paperwork', and > has very few benefits besides making people feel like they've done > something useful when they haven't. You are saying that requiring people to find co-maintainers is "bureaucracy"? Someone I know well recently got co-maintainers for three of his packages by posting a single message to debian-devel. That's less of a burden than that imposed by many another Debian rule. Fortunately for your position, it probably won't take arguments to kill this idea. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Andrew Suffield wrote: > Cute theory, gaping hole. Making a group of people responsible for > something, rather than a single person, means that they can all spend > all their time passing the buck and hoping that one of the others > takes care of it, with the result that nobody does. This is a legitimate objection. I was assuming that the main reason for undermaintenance is lack of time and reluctance to give up control, rather than lack of motivation. If the problem is lack of motivation, and the chief motivator is a sense of responsibility, then you don't want to diffuse that. > We would all be much worse off with the abolition of individual > responsibility. The constitution already abolished it -- at least, if you interpret article 2.1 the way some people have. Maybe it would be useful to reinforce a sense of responsibility in Debian. > If I were feeling in a conspiracy-theorist mood then > I'd suggest that those who are promoting team maintainance are trying > to gain power while evading responsibility. Well, you do suggest it here. And what you suggest makes no sense, so let's not rule out the possibility that you are in fact paranoid. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Since I contributed to taking the thread off on a particular tangent I feel I should try to bring it back to its original topic, which is an important one. I would like to hear some discussion about whether or not the quality of Debian is high enough; and if it is not high enough, what can be done to improve it? Lars's headings were: A) Prevent bugs from happening in the first place B) Find and report bugs C) Fix bugs that have been reported D) Prevent bugs from entering the archive Automated testing of program functionality Let's take quality assurance seriously Under most of these topics Lars discussed automated testing. Are there objections to Lars's concrete proposals (e.g., standardization on a way to invoke package specific tests)? Are there other ideas? Should Debian do more auditing, for example? For C, Lars discussed different degrees of shift from solitary toward collective maintainership. In the sequel opinions were emphatically expressed that such a shift is not necessarily a good thing. The question remains whether better quality can be realized by changing the organization in some way. Perhaps not. Then what other things can be done to help individual maintainers fix more bugs and fix them better? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New experimental sysvinit
A new version of sysvinit is being prepared for release to experimental. 1. We'll omit /run from this since debate about it continues unabated. 2. One thing I would like to do in this release is to remove the dynamically created/deleted /etc/login file from the root filesystem. It is proposed that initscripts create and delete a flag file in /var/lib/initscripts/ and that /etc/nologin become a symbolic link to /var/lib/initscripts/nologin. Then the administrator then has these options: No-login mode at boot until boot complete: DELAYLOGIN=yes No-login mode never: DELAYLOGIN=no No-login mode always: rm -f /etc/nologin ; :> /etc/nologin Anyone see any problems with this scheme? Any better ideas? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New experimental sysvinit
(Improved version, sans confusing typo.) A new version of sysvinit is being prepared for release to experimental. 1. We'll omit /run from this since debate about it continues unabated. 2. One thing I would like to do in this release is to remove the dynamically created/deleted /etc/nologin file from the root filesystem. It is proposed that initscripts create and delete the nologin flag file in /var/lib/initscripts/ and that /etc/nologin become a symbolic link to /var/lib/initscripts/nologin. Then the administrator then has these options: No-login mode at boot until boot complete: DELAYLOGIN=yes No-login mode never: rm -f /var/lib/initscripts/nologin ; DELAYLOGIN=no No-login mode always: touch /var/lib/initscripts/nologin ; DELAYLOGIN=no Anyone see any problems with this scheme? Any better ideas? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
Henrique de Moraes Holschuh wrote: > How well that works with /var in a separate partition? It should work fine because S55bootmisc.sh runs after S45mountnfs.sh. -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
> And that is probably not what I would expect. What about doing something > like this... > > NOLOGIN=boot nologin exists during boot > NOLOGIN=alwaysnologin always exists > NOLOGIN=never nologin never exists That would be fine if we were adding a new feature, but I am trying to modify an existing feature (to make it compatible with a read-only root filesystem) without altering its behavior any more than necessary. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
> A new version of sysvinit is being prepared for release to experimental. OK, sysvinit 2.86.ds1-8 is now in incoming. TIA for testing it. ;) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package dependencies due to documentation relationships?
In #303948 it is requested that coreutils Suggest: glibc-doc on the grounds that documentation in the former links to documentation in the latter. I have seen other requests of this kind and I have never been sure how these situations are supposed to be handled. Are there policies or recommendations about how documentation relationships should be reflected in package dependencies? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Joseph Michael Smidt wrote: > I believe the greatest barrier the Debian Project has in preventing > widespread > contributions from greater numbers of volunteers is a psychological barrier. > I have > personally introduced Debian to several of my friends and always emphasize > the idea > that they too can contribute to the great cause whether by documentation, > translation > or adopting a package, etc... Universally they are excited, desire to try it > out, > then come back having read what it takes to be a Debian Developer and are > overwhelmed. They then begin searching out other open source projects where > it seems > psychologically they will be able to be more of an assistance. They are right: most probably they will find it easier to make contributions to other projects. What is missing from your message is the argument why this should be changed. Would it in fact be a good thing if your friends devoted their time to Debian rather than to those other projects? It is not obvious to me that that would be better. The "great cause" is the free software movement as a whole. Within that movement there should be room for different kinds of projects, including exclusive hobby clubs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Andreas Schuldei wrote: > we need to promote the easy entry points to contributing to debian more > prominently > and should hide the "how to become a DD" in comparison. we should leave that > option > for the ones that want to contribute above average. If there is any truth to what Joseph Michael Smidt originally said: > 1.)All people psychologically want to feel important and that they are an > official > part of an organization. I feel there should be an official title for all > contributers so they feel like they are part of the community, not just a > pion until > they get official developer status. then it might help to reword several pages at debian.org so that they are more inclusive. Rename "Developers' Corner" to "Contributors' Corner". Under "The People" write "This is a comprehensive listing of all the Debian _maintainers_ accompanied with a list of packages they maintain", instead of "...developers..." (which would also be more accurate since non-DD maintainers are already listed). And so on. Reword with the principle in mind that there are many contributors to Debian who are not Debian Developers®. -- Thomas Hood
Re: How to Increase Contributions from Volunteers
Andreas Schuldei wrote: > we need to promote the easy entry points to contributing to debian > more prominently and should hide the "how to become a DD" in > comparison. Manoj Srivastava wrote: > What on earth for? Andreas Schuldei wrote: > [...] people who want to help/contribute seem to be > turned away by the burecratic nature of the NM process with its > long waiting periods. People who want to contribute without that > process need to find a way to do that easily and effectively, > without spending too much time to find where they can do that. > [...] > Manoj, i think you are trying to polarize the discussion. I think that the discussion is already polarized; there is obviously a sharp difference of view. The disagreement is reflected in the inconsistency between the existence of "easy entry points", which you favor. and the whole philosophy behind the NM process, which was presumably favored by those who set up that process. You seem to be assuming that Debian should encourage people to contribute, whereas the NM process was deliberately set up to discourage applicants. You assume that applicants are scarce, but the assumption behind NM is that there are more than enough. You assume that newcomers can be given the benefit of the doubt, whereas the assumption behind NM is that newcomers should not be trusted until they have endured trials. You assume that contributors are different, but the assumption behind NM is that developers all need to learn the same skills. You assume that people can learn as they go, but NM insists that applicants learn everything up front. If there are "easy entry points" in Debian which allow non-DDs to do the same work as DDs then I can see why a defender of the current NM process would regard those points as weaknesses in Debian's defenses, which should be closed rather than advertized. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Anthony Towns: > Anyway, the real point of replying was for me to have some fun playing > (what I'll hereby dub) the false dichotomy game. That's where you take > a set of contradictory statements, and setup reasonable scenarios where, > in fact, both alternatives are true simultaneously. I'd call it the "obscure the point game", because the pairs of statements were meant to illustrate a difference in attitude, not a set of absolute contradictions. But I think you know that. Because you are really playing another game, which I'll dub "the innuendo game". -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
Would it be useful if the initscript that clears /var/run also created a directory hierarchy under /var/run? (There are different ways of implementing thus, but we can talk about details if this feature is deemed worthwhile.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: Bug#344758: init.d script should create /var/run/dirmngr
The submitter of #344758 wrote: > The script should create /var/run/dirmngr to allow users to map their > /var/run to a temporary filesystem like tmpfs. Thanks. Peter Eisentraut wrote: > What do you think about this request? It seems reasonable, but I think if > this should be supported, there ought to be a general policy (formal or > informal) on it because I think many other init scripts will suffer from > similar problems. A program that needs to put files into a subdirectory of /var/run/ should create the required subdirectory itself at run time. This can be done by an initscript or by the program itself if it runs as root. Remember ownership and permissions. [ ! -d /var/run/foo ] && mkdir --mode=755 /var/run/foo && chown foouser:foogroup /var/run/foo Do this no sooner than /etc/rcS.d/S47 and no later than when the dir is needed. :) As pointed out by Peter Samuelson, this dir should be removed by the postrm on purge. I would advise not including /var/run/foo in the package since it is superfluous and its presence could hide a bug in your directory-creation code. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Steve Langasek wrote: > FWIW, here's what I see in practice. We have Ubuntu saying that they > give back to Debian; and then we have a fairly large divergence > between what Debian has in unstable and what's going into the next > Ubuntu release, with IME very little patch submission to the Debian > BTS, plus particular individuals who are working diligently to make > sure their own Ubuntu changes get integrated effectively into Debian. I don't think that patches-submitted-to-the-BTS is a good way to measure how much Ubuntu is contributing to Debian. Ubuntu's patches are readily available: http://people.ubuntulinux.org/~scott/patches/ If they were submitted to the BTS then that would just create more work for the Debian maintainer as well as for the Ubuntu maintainer, since the former would have to tag the report and ensure it gets closed on the next upload, etc. Yes, it might be more helpful than the current breakdown of patches into "changelog" and "packaging" components if there was a further breakdown into parts suitable for Debian and parts not suitable for Debian. However, to perform this breakdown would be for Ubuntu developers to make judgments about what is suitable for Debian, and I am sure that such judgments would provoke negative reactions from Debian developers. So I think that it is up to Debian maintainers to review the Ubuntu patches from time to time and to backport what appears to be suitable for Debian. I agree that it would be nice if Ubuntu developers tried to get their changes into sid. It is certainly not their responsibility to do so, but in my experience Ubuntu developers have been very cooperative when they have been approached. So I don't see a big problem. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
John Hasler wrote: > I can't see how putting up patches on a Web site is better than > (or even as good as) filing bug reports. The web site requires less labor to maintain than hundreds of bug reports. > Again, why should Ubuntu's patches be handled any differently than > those of other users? In short: because Ubuntu isn't just another user, but a whole distribution. cobaco wrote: > So how is it the Debian maintainers responsibility to go hunting for > usefull patches? I did not say that it is a DD's responsibility to go hunting for patches. As is well known, Debian developers don't have responsibilities (Constitution article 2.1). However, if a particular Debian Developer feels motivated to improve his package then he'd be well advised to examine what Ubuntu has done to it. Transfer of information requires two parties: a provider and a recipient. Ubuntu, the provider, has published its changes. The transfer can only be completed when the receiver is ready to receive, but this is not always the condition of Debian maintainers. So it is efficient if the transfer take place on the initiative of the latter. Once he or she is ready, he or she doesn't have to "hunt", because the patches are all at a known location. http://people.ubuntulinux.org/~scott/patches/ > Ah, here we come to the heart of the problem: "when they have been > approached", this clearly points to the fact that the initiative > for synchronization between ubuntu and debian lies with Debian not > Ubuntu (by and large, some exceptions have been mentioned). Right. > In the mean while Ubuntu proudly calls "ubuntu gives things back", > whereas in reality we mostly have a situation of "ubuntu will help > debian maintainers that want to take things back" I don't see a profound difference between "helping to take" and "giving". Perhaps what you want is "giving on a silver platter"? > -> It's this misrepresentation of where (most of) the initiative lies > which pisses people off. I think that people are pissed off for other reasons. (But I admit that I can only speculate. I can't read people's hearts and minds.) Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I doubt it. [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29 there's a claim that "they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system." -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Theodore Ts'o wrote: > I looked at the patches for e2fsprogs, and I have to conclude that > unfortunately, they patches are worse than useless. It's not clear > exactly what is being diffed against what, but if I had to guess it's > a diff of Debian stable or Debian testing versus the latest in Ubuntu > unstable --- or whatever is their development branch. I have encountered that problem too---sometimes the patches are diffs against the wrong version. > And on _top_ of that, we have all sorts of gratuitous autotools changes. I can't comment on your package. I have seen changes in some packages that looked gratuitious, but then I have been comforted by the thought that the perpetrators of gratuitous changes are the ones who have to pay the price for it, because they have to carry such changes forward. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New experimental sysvinit
sysvinit 2.86.ds1-10 is now in incoming. Along with udev 0.080-1 this should fix the problem (/dev/pts not mounted early enough) that kept some people from using bootlogd. Beyond that, it is the latest of a string of experimental releases. The sysvinit team is hoping that it is not too far off base in regarding this to be a candidate for release to unstable. Again, TIA for testing it. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Steve Langasek wrote: > Given that python-minimal is Essential: yes in Ubuntu, the *only* > use for this package in Debian (given that there would be no > packages in the wild that depend on it -- the definition of Essential > is that you don't need to depend on it) is if we make it Essential: yes > as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, and obtaining this benefit does not require that python-minimal be Essential: yes in Debian. In any case I am hoping to see python-minimal included in Debian. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
> beside the fact that I find useful to name eth0 the realtek and eth1 the > other, there is a casuality in the naming process that I cannot remove If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? What I mean by 'races' are sequences like these: * Kernel creates eth0 * Userspace notices eth0, looks at its properties, and... * Kernel creates eth1 * ...tries to rename it to 'eth1', but that name is taken -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
> In any case I am hoping to see python-minimal included in Debian. I now see that it is already in sid. :) $ apt-cache madison python-minimal python-minimal |2.3.5-5 | http://ftp.nl.debian.org sid/main Packages -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Md wrote: > SuSE uses some scripts to handle persistent interface names > [...] I had no time yet to investigate the details. I just looked at the "rename_netiface" script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name Now "trying several times", etc., may work, but it's a kludge. There are sound ways of resolving contention for a shared resource. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman wrote: > The compromise we struck with upstream was that we would not give > the user a system with a "broken" Python. So upstream objects to the separate packaging of python-minimal unless all of python is installed when python-minimal is installed (which in Ubuntu's case is: always) unless the user takes special action to prevent this. Hmm. Given that Debian does not have python in base and that some Debian packagers would like to make use of python-minimal, and Debian presumably does not want to make python-minimal Essential: yes, I'd suggest that a different way be sought for satisfying upstream. I'll assume that python2.4-minimal Recommending: python2.4 won't be enough. How about this? The current python2.4-minimal package contains /usr/bin/python2.4. We would move this to /usr/lib/python2.4/interpreter so that it is no longer present on the standard search path. The full python2.4 package would contain a symlink /usr/bin/python2.4 -> /usr/lib/python2.4/interpreter to make the interpreter available on the path. python-minimal Depends on python2.4-minimal and contains the symlink /usr/bin/python -> /usr/bin/python2.4. In addition it would contain the symlink /usr/lib/python/interpreter -> /usr/lib/python2.4/interpreter. Packages that currently Depend on python but use only minimal functionality could Depend on python-minimal but they would have to run python using /usr/lib/python/interpreter. The stripped down python interpreter would be "hidden" from command-line users but would still be available for use by packaged programs. Thomas Bushnell wrote: > Ok, but now I'm confused: why is python-minimal needed in Essential? > Why not simply depend on it straightforwardly? http://marc.theaimsgroup.com/?l=debian-devel&m=113768382100129&w=2 -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
I wrote: > Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. > Would everyone be happy then? I doubt it. > > [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29 > there's a claim that "they send their bugfixes to the Debian developers > responsible for that package in debian and record the patch URL in the > debian bug system." Looking at that page today I see that it has changed. It seems to be more accurate now, though I didn't keep a copy of the old text with which I could compare what is written now: > Ubuntu and Debian are distinct but parallel and closely linked > systems. The Ubuntu project seeks to complement the Debian project in > the following areas: > [...] > When a bug is reported in the Debian bug tracking system and then later > fixed in Ubuntu, the fixes are communicated back directly to the Debian > developers responsible for that package in Debian and record the patch > URL in the debian bug system. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Frank_Küster wrote: > That sounds good, but wouldn't it be even better to have a symlink > /usr/bin/debpython-minimal or so, pointing to the interpreter? Then one > could still replace the interpreter by something else (by putting it > into /usr/local/bin), for example in order to debug a particularly weird > problem in a config script? Or python-minimal could just provide /usr/bin/python-minimal. Then programs with minimal requirements would have #!/usr/bin/python-minimal and their packages would Depend on python-minimal, whereas normal python programs would have #!/usr/bin/python and would Depend on python. Behind the scenes /usr/bin/python would be a symlink to python-minimal but users wouldn't have to know this. The interpreter could even be modified so that it allows only modules from the minimal set to be imported, when run as /usr/bin/python-minimal. Thus if upstream's concern is that users not have a stripped down python, then Debian provides a stripped down "python-minimal" instead. -- Thomas Hood
GPL version option
Now that a draft of GPL version 3 has been published it seems appropriate to examine what the implications would be for current licensees of GPL'd software. For many licensees it will have implications because the software is licensed under the GPL with a "version option". The text of the GPL itself includes this section: > 9. The Free Software Foundation may publish revised and/or new versions > of the General Public License from time to time. Such new versions will > be similar in spirit to the present version, but may differ in detail to > address new problems or concerns. > > Each version is given a distinguishing version number. If the Program > specifies a version number of this License which applies to it and "any > later version", you have the option of following the terms and conditions > either of that version or of any later version published by the Free > Software Foundation. If the Program does not specify a version number of > this License, you may choose any version ever published by the Free Software > Foundation. Actual source files contain text like this (with version option): This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. but some of them contain text like this (without version option): This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 dated June, 1991. I had never paid much attention to this before and to my surprise I found several source files that _I_ had written which lacked the version option. When I examined other source files I found a bit of a mess. Several debian/copyright files contained "without option" texts whereas the source files themselves contains "with option" texts. These had to be corrected. My guess is that there may be other packages out there that need to be reviewed with respect to the granting or non-granting of the GPL version option. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
Peter Samuelson wrote: > That's a bug, IMO - they should mkdir -p in their init scripts if > necessary. It's not like that's hard to do. Tim Cutts wrote: > [...] In my case I was mounting /var/run > and /var/lock as tmpfs filesystems all the time to reduce hard disk > access on a machine that was running all the time. Ubuntu is already mounting tmpfs's on /var/lock and /var/run. It's a reasonable thing to do and we should support it. That means that packages using these directories should create any subdirectories they need. Don't forget to set ownership and permissions. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: conffile purging and maintainer scripts
Roger Leigh wrote:
> Until last month, dpkg "forgot" about conffiles which were removed or
> moved on package upgrade. As a consequence, maintainers had to
> remember to purge these conffiles "by hand" in the package postrm
> script.
I just want to highlight the word "these" above in order to reduce the
possibility of confusion.
Postrms should not delete files that are currently conffiles of the package.
dpkg takes care of deleting such files at the right time.
If a file /etc/foo was formerly a conffile of the package but no longer is so
then /etc/foo should be dealt with in the preinst or postinst. ("Dealing with
it" has to take into account both the old and the new behavior of dpkg with
respect to disappearing conffiles. I speak vaguely here because I haven't
looked into the new behavior.) If it isn't dealt with there then it might be
appropriate to delete it in the postrm, but not if there is reason to suspect
that some other package is now using /etc/foo.
> 1) sarge -> etch upgrades
> -
>
> In order to handle upgrades from sarge correctly, maintainers will
> still have to manually remove conffiles in their maintainer scripts
> until at least etch+1 by my reckoning. Is this correct?
Again, postrms should not remove files that are currently conffiles.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu Patches
> http://people.ubuntu.com/~scott/patches/ Thanks, that is very useful. I see that Ubuntu has done a lot of work to make initscripts send output through lsb printing functions. Are there any plans for Debian to adopt these changes? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If Debian's too radical for you... [was: NEW handling: About rejects, and kernels]
On Thu, 24 Mar 2005 08:50:16 +0100, Marc Haber wrote: > Is it as easy to participate with Ubuntu as it is with Debian? In some respects it is easier. For one thing you can become a maintainer there without going through an NM ordeal. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Should Debian use lsb init-functions?
> Changes: > lsb (2.0-6) unstable; urgency=low > . >* Create lsb package in binary-indep step. (Closes: #297788) >* Merge /lib/lsb/init-functions from Ubuntu. >* Split /lib/lsb/init-functions into arch-all lsb-base package; this > functionality is thus available for use by other, non-LSB packages. >* Update README.Debian. Should Debian initscripts use lsb init-functions? It would probably be best if this were decided at the project level. -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Who uses libasound2-plugins?
Does anyone use the libasound2-plugins package? If so, how? -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init.d script dependencies for etch?
On Fri, 01 Apr 2005 16:50:20 +0200, martin f krafft wrote: > I think we need to establish a header format policy, and I suggest > something similar to debian/control, e.g. > > #!/bin/sh -e > # init.d script for sshd > # > #% Depends: network, iptables > # > > if "$1" ... This has been standardized by LSB: http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html This is not to say that I like the idea of magic comment headers. > I would prefer this over e.g. starting all init.d scripts at once > and letting each call its dependencies. This would be very hard to > implement efficiently. I missed the beginning of this conversation. I hope it has been said that the first thing we should do is investigate the several dependency-base init systems that are already out there. (There are earlier threads about this.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to handle unreproducible RC bugs when the submitter is MIA?
> Severity: grave > Justification: renders package unusable At http://www.debian.org/Bugs/Developer#severities, "grave" is glossed as: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. I interpret "users" here as "all users" because the "important" severity is glossed as: has a major effect on the usability of a package, without rendering it completely unusable to everyone which seems to be meant to contrast with "grave". That is, if the package isn't unusable by everyone (if the bug only affects some users) then the bug is not grave. If the bug is unreproducible then it can't be the case that the package is unusable to everyone. So I'd say that a downgrade is justified. Of course, I may be misinterpreting the severity tags. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to handle unreproducible RC bugs when the submitter is MIA?
On Fri, 2005-04-01 at 22:22 +0200, Frank Küster wrote: > (bugs in maintainer scripts are a policy violation) I don't recall policy saying that maintainer scripts "must" be entirely bug free. Obviously they _should_ be bug free, but bugs in maintainer scripts aren't always RC. -- Thomas Hood <[EMAIL PROTECTED]>
Re: init.d script dependencies for etch?
On Fri, 01 Apr 2005 20:40:08 +0200, Bastian Blank wrote: > | need clock hostname > | provide logger I take it that this is Richard Gooch's simpleinit system as furnished in util-linux. http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ Before commenting, people should go and read about the several free init systems available out there. There's also runit, minit, etc. There have been other threads on debian-devel about this issue, e.g.: http://lists.debian.org/debian-devel/2004/08/msg01393.html http://lists.debian.org/debian-devel/2003/10/msg01078.html http://lists.debian.org/debian-devel/2004/06/msg01445.html http://lists.debian.org/debian-devel/2003/11/msg01695.html http://lists.debian.org/debian-devel/2003/09/msg01359.html http://lists.debian.org/debian-devel/2003/01/msg01898.html -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init.d script dependencies for etch?
Apparently Gentoo is using simpleinit. Anyone know what the other distros are using? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
On Sat, 16 Apr 2005 01:10:10 +0200, Adrian Bunk wrote: > Debian's steps of moving more and more things into non-free forces many > users to use non-free who wouldn't do otherwise. > > Is this effect really wanted? Obviously not. One effect that is wanted is for users to have access to an archive that wholly conforms to the DFSG, robustly interpreted. Another goal is to encourage authors to license works compatible with the DFSG, robustly interpreted. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
I have been looking at the lsb init functions and am beginning to feel that they are a bad idea. * Converting to lsb init function requires modifying every initscript in Debian. * Every initscript has to read in a file containing a set of function definitions, some/most of which the initscript does not use. * The lsb functions don't handle all the kinds of output currently produced by initscripts. * Success/failure status has to be signalled using a special function, whereas this information is (or should be) already available as the exit status of the initscript. I think it would be better if we simply made rc capture initscripts' standard output (and exit status) and formatted it in such a way that bootup messages were prettier. -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote: > Completely MIA maintainers are one part of the problem. > > But then there's the class of maintainers who manage to upload a new > upstream version and perhaps fix some RC bugs every few months but are > not able to properly handle all bugs in their packages. In part this is a consequence of scarce manpower. In part it is a consequence of the institution of package ownership and other organisational flaws. If you agree with this diagnosis then I am curious to know which of the following you plan to do. 1. continue to participate in the Debian project despite its dysfunctional organisation; 2. push for changes to the organisation; 3. participate in another project instead. (There are other possibilities, of course.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhcp-client package in sarge
On Fri, 03 Jun 2005 09:00:28 +0200, Nicolas Kreft wrote: > Is it for a special reason that the default dhcp-client > in sarge is ancient (version 2.0pl5)? Some years ago when the release of sarge was supposed to be imminent it was decided not to adopt dhcp3 as the default because there wouldn't be enough time to adjust to it before the release. Then the release was delayed for a couple of years; meanwhile the maintainers of dhcp and dhcp3 have been busy with other things. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, 07 Jun 2005 01:10:15 +0200, Javier Fernández-Sanguino Peña wrote: > Ok, so sarge has been released! We should all thank the Release Team for > their hard work in putting this major release together. Yes. Thanks to everyone involved for the many, many hours they devoted to getting sarge into shape. > So, without further delay, here's my "Etch-wishlist", it's [based] on > some of the things I've personally worked on and would like to keep > working on for etch. Debian needs to make a release plan. The plan should establish a target release date for etch. Projects on the TODO-for-etch list must then be projects that can be completed within the allotted time. A choice has to be made early on whether to go for a short-term bugfix release or for a longer-term restructuring release. Respective development times would be, say, six months versus eighteen months. I hope that the DPL will get involved in this debate and steer it toward a firm decision. To begin with we can all go back and review: http://wiki.debian.net/index.cgi?ReleaseProposals -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, 07 Jun 2005 10:10:13 +0200, David Goodenough wrote: > Another item that might be worth considering for laptops is a networking > equivalent of the pmount group. People in these groups would be allowed > to edit the network files (in particular /etc/network/interfaces) and bring > interfaces up and down. http://people.redhat.com/dcbw/NetworkManager/ -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313369: RFH: mwavem -- Mwave/ACP modem support software
Package: wnpp Severity: normal I request assistance with maintaining the mwavem package. I own a ThinkPad 600 with an Mwave modem inside and I use this to test the mwavem packages that I prepare. However, I do not use the machine on a daily basis. If possible I would like help from someone who does use mwavem regularly. The package description is: The Mwave modem support software implements a Hayes-compatible V.90 modem in the 3780i Mwave/ACP DSP chip which is built in to several discontinued IBM ThinkPad laptop computers, including the ThinkPad 600, 600E and 770 models. . In addition to the programs included in this package, a driver is required for the Mwave device. Source code for the driver, built as a module called 'mwave.o' or 'mwave.ko', is included in the latest 2.4 and 2.6 Linux kernel sources. To build the module, set "ACP/Mwave Modem support" to "m" at kernel configuration time. This module must be loaded before the Mwavem modem support program can be started. . This package is in the non-free section of the archive because it contains program binaries for the 3780i chip that have been furnished by IBM without source code. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (800, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
Goswin von Brederlow wrote: > More usefull is probably a new type 'needs to run but can be > configured without'. The effect would be just like Depends except > that cycles can be safely broken at that point. For symmetry you might want to call the dependency you describe 'Post-Depends'. X Pre-Depends: Y = X unpack needs Y config'ed X Depends: Y = X config needs Y config'ed X Post-Pepends: Y = X runneeds Y config'ed To break a cyclical Dependency, one of the Depends in the cycle could be weakened to a Post-Depends; then dpkg would know to configure the Depended-upon package before configuring the other (merely Post-Depended-upon) package. I agree that mutual dependencies can be appropriate when two packages work closely together. An example is a program that consists of both binaries and scripts which run one another in complex ways and the scripts and data have been split off into a separate Arch: all package. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
If Debian continues to use the Release When Ready strategy then I would suggest that the number of the next release be its ordinal in the historical sequence of releases, which is 9 by my reckoning (buzz, rex, bo, hamm, slink, potato, woody, sarge, etch). I see no basis for distinguishing some Debian releases as "minor" ones. Every release is major. If Debian simply _must_ have decimal points in its release numbers then I'd suggest replacing the 'r' in update version numbers with '.'. Thus 9.1 would be the number of the first etch update. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
On Sun, 10 Jul 2005 01:57:54 -0400, Nathanael Nerode wrote: > I suggested "Debian IV" Are release numbers really needed? Why not do away with them altogether? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
Nigel Jones wrote: On 10/07/05, Thomas Hood <[EMAIL PROTECTED]> wrote: Are release numbers really needed? Why not do away with them altogether? you mean, just stick with code names? That wouldn't exactly work, Debian's apt/dpkg basicly relies on release numbers, how else can it easily and quickly realize that apache2-2.0.40 is older than apache2-2.0.50? I was obviously referring to the numbers assigned to releases of the operating system, not to releases of individual packages. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
Jaldhar H. Vyas wrote: There are some strange people in the world who consider toy names frivolous and not grown up. But they can be mollified with sober, professional release numbers. Another advantage is that numbers come in an order and thereby indicate which release came before which. Among numbers, integers describe this order most clearly. :) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317892: ITP: bum -- tool to manage boot scripts
On Tue, 12 Jul 2005 11:15:42 +0200, Federico Di Gregorio wrote: > Boot-Up Manager is a graphical tool to allow easy configuration > of init services in user and system runlevels, as far as changing > Start/Stop services priority. Consulting the documentation... > 1. Activate a de-activated script. > BUM will create a standard S20 symlink in directories > related to runlevel 2,3,4 and 5 and will remove any > Kxx symlink in the same directories. Further it > creates K20 in runlevel 0,1 and 6 directories. It > also checks that the script "executable" and, if needed, will > change it so that it is. > > 2. Deactivate an activated script. > BUM will remove any Sxx symlink. > Very nice program, but the behavior described here is incorrect. In order to deactivate the service, bum should install a Kxx symlink. Testing confirms that bum fails to do this. Without a K symlink in the directory for the current runlevel, when the service's package is upgraded, the service will be started in the postinst even though it is configured to be deactivated. This issue has been discussed before and I believe that there is a good consensus about it now. Bum's current behavior leaves deactivated services in a floating state and Debian does not at present correctly support services left in the floating state. (See #243159.) You will need to choose an appropriate sequence number for the K symlink. I suggest: If there is a K symlink in another directory then use its sequence number; otherwise use an old K sequence number stored in database; otherwise use 100 minus the S sequence number. You may want to look at the source code of sysv-rc-conf too. Among the runlevel editors currently in Debian it sucks the least. Wishlist item: Grep the postinst files in order to obtain the "factory default" sequence numbers and implement a "restore factory default sequence numbers" feature. See my last comment in #183460. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dicussion about patches ... ignoring patches make motivation to provide them fall
Russ Allbery wrote: > Whenever this topic comes up on debian-devel, the conversation seems to > focus on the small minority of maintainers who don't respond to bugs, are > still active on their packages, resist any attempt at co-maintainership, > and can't be dealt with through the MIA process. Yes, these are the most frustrating cases. > Such people, to the > extent that they exist, are frustrating; they're also such a small > minority of the problem that if they were all we had to worry about, > Debian would be in awesome shape. > [...] > If you run into a maintainer who doesn't want your help, move on and try > another maintainer. It might not be so simple. Suppose I have taken it upon myself to push change Foo through Debian. The Foo project requires cooperation from several DDs and at the beginning I can't tell whether I will get that cooperation from all of them. After having devoted many hours to project Foo and after the passage of some months I find that progress is blocked by needed changes to package P. I write to the maintainer of P but get no reply. After repeating this a few times I (finally!) get a message from the P maintainer... about his having more important things to do than deal with my patch. Time goes by and the patch is never spoken of again. Of course I move on and do something else. But I have wasted a lot of time, Foo never gets done, and I have learned not to undertake any more projects like Foo in the future. Not within Debian, anyway. Purely hypothetical case, but it could happen. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dicussion about patches ... ignoring patches make motivation to provide them fall
Me: > [In the hypothetical case] I write to the maintainer > of P but get no reply. After repeating this a few times I (finally!) > get a message from the P maintainer... about his having more important > things to do than deal with my patch. [...] Frans Pop: > Alternative conclusion to this saga... > I discuss on d-devel if the Foo project is a worthwhile goal and how I've > gotten stuck. There is general agreement that Foo is worth pushing for > the next release. I ask for a review of/help with my patches to the > packages that block progress, deal with the comments that come back and > NMU them (after mailing the maintainer one last time). [...] Right. Either way, the maintainer's failure to respond to my messages ends up costing me a lot of time. The prospect of this is likely to have a negative impact on my motivation to undertake project Foo in the first place. This was the contention expressed in the Subject line and is the only point I would want to support. Svenl originally claimed that ignoring patches is an act of "contempt", but I would certainly not go that far. Yes, responding to a request would be regarded as elementary politeness in some spheres, but Debian's social norms are not the same as those of everyday life. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
Jérôme Warnier wrote: > But [packaging] is not my main contribution to Debian, I propose patches and > close bugs for many packages I personally use or need for customers, and > this is not recognized currently as sufficient for becoming a DD... and > I'm not the only one. and later wrote: > So, how can I apply for DDship while doing the things I'm best at? Obviously you can't, currently. You aren't the first to see a potential problem with the current equation of DD'ship with Debian project membership. It's hard to predict whether this will ever change. If you think that it should change then nothing is stopping you from making the suggestion here. It's up to the members to decide whether they want to implement such change, though. (It's a bit of a catch-22, since existing members are less likely to see the exclusivity of Debian as a problem. However, you always have the option of participating in some other project, such as Ubuntu, which does recognize contributions other than package maintenance.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
Petter wrote: > I have not confirmed that this procedure will work, but here is my > suggestions anyway. > > - The Alioth system administrators have asked for help several times. > Get in touch with them and check what exactly they need help with. > Do a good job helping them, and prove that way your abilities as a > system administrator. Next, contact the new maintainer frontdesk > and ask how the NM process fit your skill set and interest, and go > through the process to become a official Debian Developer. Given that it takes up to two years to process an applicant answering standard questions from templates, how long is it likely to take to process someone through a custom process? Possibly less time if the applicant doesn't get hung up on difficult questions, but probably more; and the customization won't scale. And can we be sure that the applicant will be subjected to pointless busywork this way (to test his tolerance for Debian's institution of people carelessly wasting one another's time)? Another thing: According to my AM, the applicant's prior work can't be used to prove his competence because the Front Desk and the DAM can't be bothered to look at that work. How do we ensure that applicants on the "custom" track will be subjected to similar obtuseness? Perhaps there should be a checklist to ensure a level playing field. [] Find something that he doesn't know and tell him to go away if he doesn't know it [] Ignore the applicant's past work in Debian [] Make the applicant rephrase "§6.4: Summary of ways maintainer scripts are called" in his own words [] Make the applicant wait for months for no particular reason [] Blame the applicant for above delays Seriously though, Jerome, I'd advise you not to get your hopes up too high. Here's the experience of Debian's newest DD: Received application2004-04-21 > [...] > Application Manager recommends to DAM Approved on 2004-07-12 > FD checks completeness of report Approved on 2006-02-21 by Marc > Brockschmidt (he) > DAM Approval Approved on 2006-03-20 by Joerg Jaspert > (joerg) -- Thomas Hood
Interim maintainer needed for thinkpad and tpctl
I plan to cease maintaining the thinkpad and tpctl Debian packages very soon. Martin Krafft kindly agreed to take them over, but he will only be able to start work at the end of May. A new version of the thinkpad package needs to be uploaded soon in order to close a bug that is rated severity: critical. Therefore I am seeking an interim maintainer of thinkpad and tpctl, preferably someone who would like to carry on as co-maintainer with Martin. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, 23 Jan 2005 03:00:27 +0100, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. apt-get install sysv-rc-conf. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, 23 Jan 2005 10:40:08 +0100, Marc Haber wrote in part: > Ihave a number of server packages installed on my > personal laptop for the sake of having the docs with me. I am, > however, fine with using update-rc.d or $EDITOR /etc/runlevel.conf[1] > to accomplish this. In some cases this might be grounds for wishing that the docs be split off into a separate package. Another solution is to "dpkg -x" the package into the directory of your choice and to peruse the docs in there. Of course, neither of these is completely convenient. If one really wants the package to be installed but deactivated then he can install it and disable it using sysv-rc-conf. I agree that sysv-rc-conf leaves something to be desired. It would really be much better if there were a reliable way of restoring a service's runlevel settings to their "factory defaults" -- i.e. to what the package postinst set them to. This could be implemented by changing update-rc.d so that it recorded these settings somewhere; the information could later be used to restore the service's runlevel settings to their factory defaults. I have written about this in #183460 and #237379. This feature is also needed so that maintainer scripts can change runlevel configuration iff they haven't been changed by the user. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Archive maintainers: Please relocate tpctl package
The tpctl packages still haven't been relocated. Is there some holdup? Thomas On Mon, 28 Aug, 2000 at 21:49:04 +0100, Adrian Bridgett wrote: > On Sat, Aug 26, 2000 at 12:04:32 +1200 (+), Michael Beattie wrote: > > On Fri, Aug 25, 2000 at 04:21:21PM -0400, Thomas Hood wrote: > > > Hi. > > > > > > Can someone please move the tpctl debs to the correct location > > > in the archives? Or if this can't be done, can I have an > > > explanation why? > > > > It can be done. I will do it in a couple of hours. the proper place for this > > type of message is a bug against ftp.debian.org. > > and there has been one filed for months now. I won't complain - at least > not until I get ADSL and so can offer to help out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Archive maintainers: Please relocate tpctl package
> On Tue, Sep 05, 2000 at 05:05:35PM -0400, Thomas Hood wrote: > > The tpctl packages still haven't been relocated. Is there > > some holdup? Michael Beattie wrote: > Time. sorry, I'll take a look this afternoon. I see you've done it! Thanks. Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Update re: read-only root filesystem
Some progress has been made toward the goal of making Debian easier to use with a read-only root filesystem. Action has been taken to remove variable files from /etc/, or at least to make it possible to do so locally, in the following packages: cupsys, laptop-net, pppconfig, sysvinit. Packages that still employ variable files in /etc/ include: mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux. Fortunately, some of the files can be replaced by symlinks. See my README file at http://panopticon.csustan.edu/thood/readonly-root.html for (incomplete) information. Many thanks to the maintainers who have been supporting this effort. -- Thomas Hood
