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. attempt to paraphrase /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. /attempt to paraphrase 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 /something. 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-develm=113768382100129w=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: 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
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]
Re: esound with libasound2
It would be useful if someone would package the current esound program. The esound package maintainer has clearly expressed his lack of interest in doing so. esound2 anyone? -- Thomas Hood [EMAIL PROTECTED]
Re: apt_preferences man page
Because this matter was mentioned in the 26 November Debian Weekly News, it seems appropriate to post an update. Susan Kleinmann took the bull by the horns and rewrote the page from scratch. I have proposed some revisions and hopefully we'll have a finished product soon. I append the latest version I have, in the hopes that people will point out any remaining errors. -- Thomas Hood APT_PREFERENCES(5) APT_PREFERENCES(5) NAME apt_preferences - Preference control file for APT DESCRIPTION The APT preferences file /etc/apt/preferences can be used to control which version of a package will be selected for installation. Several versions of a package may be available for instal lation when the sources.list(5) file contains references to more than one release (for example, stable and test ing), and several instances of the same version of a pack age may be available when the file contains references to more than one download site for a particular release. APT assigns a priority to each instance that is available. (In what follows, an instance will be an instance of a package that is available according to sources.list(5).) Subject to dependency constraints, apt-get installs the instance with the highest priority. The APT preferences file overrides the priorities that APT assigns to package instances by default, thus giving the user control over which one is selected. APT'S DEFAULT PRIORITY ASSIGNMENTS If there is no preferences file, or if there is no entry in the file that applies to a particular instance, then the priority assigned to an instance is the priority assigned to the release to which that instance belongs. It is possible to single out a release, called the target release, which receives a higher priority than other releases. The target release can be set on the apt-get command line or in the APT configuration file /etc/apt/apt.conf. For example, # Command to install the version of some-pkg from the testing release apt-get install -t testing some-pkg # Configuration setting to make stable the target release APT::Default-Release stable; If a target release has been specified, then APT uses the following algorithm to set the priorities of the instances of a package. Assign: priority 100 to the instance of a package that is already installed (if any). priority 500 to the instances of a package that are not installed and do not belong to the target release. priority 990 to the instances of a package that are not installed and belong to the target release. If no target release has been specified, then APT simply assigns priority 100 to all installed package instances and priority 500 to all uninstalled package instances. APT then applies the following rules to determine which instance of a package to install: · Never downgrade an installed package unless the priority of an available instance of the package exceeds 1000. (Note that none of APT's default priorities exceeds this threshold; such high priorities can only be set in the preferences file.) · Always install or upgrade to the highest priority instance of a package. · If two or more instances of a package have the same pri ority, install or upgrade to the most recent one. In a typical situation, the installed instance of a pack age (priority 100) is not as recent as one of the instances available from the sites and releases listed in the sources.list(5) file (priority 500 or 990). Then the package will be upgraded with the command: apt-get install or apt-get dist-upgrade. Rarely, the installed instance of a package is more recent than any of the other available instances. This package will not be downgraded. Sometimes the installed instance of a package is more recent than the version belonging to the target release, but not as recent as a version belonging to some other release. Such a package will indeed be upgraded, because at least one of the available instances has a higher pri ority than the installed instance. THE EFFECT OF APT PREFERENCES The APT preferences file allows the system administrator to customize priorities. The preferences file consists of one or more multi-line records separated by blank lines. Records can have one of two forms: · The first
Re: apt_preferences man page
(In reply to Travis Crump) Hello, and thanks for the feedback. I think that the original is right. It speaks of the priority assigned to an instance of a package (i.e., a particular version of that package coming from a particular source). So although coreutils (the package) is assigned three different priorities, one instance of coreutils (4.5.3-4 from http.us.debian.org) is assigned priority 70, another (4.5.2-1 from http.us.debian.org) is assigned priority 700, while the installed instance (also version 4.5.2-1) is assigned priority 100. It is also necessary to add the and not installed clause for obvious reasons. I have another question about the man page draft, though. Do we use the word 'release' where we should use the word 'distribution'? -- Thomas Travis Crump wrote: Thomas Hood wrote: If a target release has been specified, then APT uses the following algorithm to set the priorities of the instances of a package. Assign: priority 100 to the instance of a package that is already installed (if any). priority 500 to the instances of a package that are not installed and do not belong to the target release. priority 990 to the instances of a package that are not installed and belong to the target release. Is this right? Shouldn't it be something to the effect: priority 100 to the instance of a package that is already installed (if any). priority 500 to the instances of a package that are available in an archive but do not belong to the target release. priority 990 to the instances of a package that belong to the target release. For instance, taking a random package: [EMAIL PROTECTED]:~$ apt-cache policy coreutils coreutils: Installed: 4.5.2-1 Candidate: 4.5.2-1 Version Table: 4.5.3-4 0 70 http://http.us.debian.org unstable/main Packages *** 4.5.2-1 0 700 http://http.us.debian.org testing/main Packages 100 /var/lib/dpkg/status 4.5.2-1 gets both the 100 for being installed and the 700 for belonging to the testing release. There are other places in the man page that use this language as well.
Re: /run and read-only /etc
On Wed, 2003-04-09 at 20:22, Jeremy Jackson wrote: Clearly what is needed here is an API for resolver updates [...] What you describe is roughly what I wrote up in my last TODO message. In Debian, there should possibly be a policy decided upon. (what the dir is, what API is, etc) I don't immediately see why the resolver management scheme has to be written up in policy. It concerns only a small set of packages. The APM subsystem uses a similar scheme (/etc/apm/apmd_proxy, /etc/apm/event.d, etc.) but is nowhere mentioned in policy. Eventually, however, there will have to be policy that forbids routinely writing to files in /etc/. And there will have to be a FHS change to allow for /run/. -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
/run/ that are not just variable and unshareable but also local -- i.e., they must be writable independently of network connectivity. Because /var/ is sometimes remote, the new directory will not be based in /var/; instead it will be based in the root directory. Hence, '/run/'. Problematic passages in the FHS v.2.2 = 2. Since / contains both variable and static data, it needs to be mounted read-write. Surely it isn't mandatory to mount / read-write. If there is no need to write to / then / can be mounted read-only. 3.1 Software must never create or require special files or sub- directories in the root directory. We are not software, so it might be that this restriction does not apply. If the restriction does apply, then the argument is that adding /run is technically justified and the FHS must be changed to allow it. 5.1 Everything that once went into /usr/ that is written to during system operation (as opposed to installation and software maintenance) must be in /var/. Nothing we are planning to put in /run/ was ever in /usr/. 5.2 [/var/]run/ : Data relevant to running processes This seems to rule out using /var/run/ for storing state information between invocations of a program. But we do want to store this sort of state information in /run/; so this would seem to imply that 'run' is not an appropriate name for the new directory. However, 5.13 says that This directory [viz., /var/run/] contains system information data describing the system since it was booted. This is less restrictive than the earlier description and is quite compatible with how we propose to use /run/. I think we can assume that the important difference of /var/run/ from /var/lib/ is not that it contains information relevant to running processes, but that it is cleaned out at boot time and is not necessarily backed up. -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
On Sat, 2003-04-12 at 23:56, Herbert Xu wrote: * Change /sbin/pump to: * Store PID in /run, not in /var/run I won't debate whether this is true in general, bug it is certainly unnecessary in the case of pump. I have specifically added code to deal with the inability to write to /var/run by making pump fall back to using TCP sockets. Unnecessary; but would using /run for the pidfile be a better (e.g., simpler) solution? If not then do you think the TCP-socket approach is the way to deal with every program that writes a pidfile when /var/ may be absent? -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
On Sat, 2003-04-12 at 10:12, Anthony DeRobertis wrote: On Wed, 2003-04-09 at 14:17, Thomas Hood wrote: * ppp * Change /usr/sbin/pppd to: * Store PID in /run/, not in /var/run/ Why? Is the goal to make PPP-mounter /var to work?! I suppose someone might want to mount /var/ across a ppp link. If we are making the other changes then we might as well make this one too, unless there is absolutely no point in doing so (... because it is impossible to mount /var/ across a ppp link for some reason I am overlooking?). If so, pppd has to be moved to /sbin. Well, /usr/ could be local but /var/ remote. The proposed new directory is for files similar to those in /var/run/ that are not just variable and unshareable but also local -- i.e., they must be writable independently of network connectivity. No, they must be on the root file system, like /bin and /sbin. Remember the root FS can be network mounted, e.g., over NFS. How about this then: The proposed new directory is for files that serve similar purposes to those in /var/run and that are not just variable and unshareable but also available early enough to be used by programs in /sbin and /bin. -- Thomas Hood [EMAIL PROTECTED]
Re: Nameserver-pushing mechanism
On Sat, 2003-04-12 at 02:34, Jeremie Koenig wrote: Sounds quite good. But I have a suggestion about going one step further: include the whole thing into ifupdown. [...] In the following, where you write '/etc/resolv-update.d' I guess you meant to say '/etc/network/resolv-update.d' since /etc/network is where ifupdown stores its configuration files. Underlying programs to configure interfaces (dhcpcd, pppd, ...) would put their resolv.conf data in /run/network/resolv.d/interface. They have no need to call any script to do the update, ifupdown manages it itself. [...] To change my suggestion into yours: * Move files from /run/resolver/interfaces/ to /run/network/resolv.d/ * Move files from /etc/resolver/update.d to /etc/network/resolv-update.d * Make the latter scripts get their resolv.conf data from stdin instead of from the /run/network/resolv.d/* files * Rename /etc/init.d/resolver reload to push-resolvers * Make ifupdown call push-resolvers instead of using a script in /etc/network/if-up.d. The only significant difference is that you would put everything in the ifupdown package. Why do that? We will also need that ifupdown waits until ppp/dhcp has finished before exiting. This has to be done someday, anyway. /run makes it possible, since we can create, for instance, a /run/network/pid.ppp0 file to be killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown. I don't understand this. Why do you want ifupdown not to exit until while ppp or dhclient are running? if(up|down) wasn't designed to run as a daemon. Cheers -- Thomas Hood [EMAIL PROTECTED]
Re: Nameserver-pushing mechanism
On Sun, 2003-04-13 at 19:25, Jeremie Koenig wrote: * Make the latter scripts get their resolv.conf data from stdin instead of from the /run/network/resolv.d/* files This is important. It must be possible to control which nameservers go to which recipient script. For instance bind mustn't be fed with himself, but must be fed to others. In my proposal, /etc/init.d/resolver reload generates /run/resolv.conf, so this isn't an problem. Sending the resolv.conf data through a pipe makes it only slightly (if at all) easier to write the update script, and it elides information (viz., the interface with which the nameserver is associated) for which the script could have some use. [...] the idea was not just putting everything into the ifupdown package, but integrating it to the ifupdown mechanism. Yes, it is a good idea to integrate resolver updating closely with ifupdown. I am not sure it is appropriate to use ifupdown directories, though, as if we were extending ifupdown proper. The resolver is not part of ifupdown. Having the nameserver list as a part of each interface's configuration may be useful/handy/logical. I think this part of your proposal can be regarded as a wish for ifupdown to be extended so that one can specify nameservers for each logical interface. Listed nameservers would be added through the resolver update mechanism that we will be providing. Good idea for the future; I've added it to the TODO list. Sorry, I was unclear. I meant that ifup should wait until the interface is effectively brought up before exiting. In the case of ppp (I don't know about dhcp), ifupdown just launches pppd, then exit. OK, comprendo. Ifup should wait for success (SIGHUP) or failure (pppd dies). This way it can know the status of the interface better, and full configuration or failure to configure is made when ifup exits. Yes, ifupdown should handle interface-up failures better than it does. There are several bug reports open about this already, e.g., #82339 and those merged with it. And yes, in order to check for ppp's success ifup would have to wait for some signal from ppp. You might want to file a wish for this, including your SIGHUP idea or a patch if you have one. Perhaps a wish should be filed against ppp too, because the basic problem is that pon doesn't wait to see if the interface comes up successfully. In any case, this functionality is absent from the present ppp and ifupdown and may continue to be absent for a long time. Therefore, we have to make the resolver update stuff work with ifupdown in its present form. That means adding scripts to the /etc/ppp/ip-(up|down).d/ and /etc/network/if-(up|down).d/ dirs. If ifupdown is enhanced so that (as mentioned above) it * waits to see if pppd succeeds, and * handles nameserver addition on ifup, deletion on ifdown, then the scripts can be eliminated. -- Thomas Hood [EMAIL PROTECTED]
Re: Nameserver-pushing mechanism
Proposal: Implementation steps for dynamic resolver configuration
Assuming that it is impossible to update networking daemons and
DNS caches simultaneously with providing the infrastructure for
dynamic resolver configuration, we need a plan for doing it in
stages.
Each of the following steps should be completed before the next
one is taken.
* Modified sysvinit package creates /run/
* New resolver package includes /etc/init.d/resolver which
generates /run/resolv.conf from /run/resolver/interface/*
and does a run-parts on /etc/resolver/update.d/
* Networking daemon packages and ifupdown provide dynamic
nameserver data in /run/resolver/interface/IFACE (in
resolv.conf format) and call /etc/init.d/resolver reload
on interface up, but continue to futz with /etc/resolv.conf
as they do now
* Modified bind package provides /etc/resolver/update.d/bind
which generates a new named.conf forwarders{} fragment.
On installation, the package optionally sets up named.conf
to include this fragment. Likewise for other DNS caches.
* Modified resolver package depends on the latter versions
of the networking daemon packages and ifupdown. On
installation, optionally changes /etc/resolv.conf into a
symlink to /run/resolv.conf
* Modified networking daemon packages depend on the latter
version of resolver and no longer futz with /etc/resolv.conf
Does this look reasonable?
--
Thomas Hood [EMAIL PROTECTED]
Re: Nameserver-pushing mechanism
On Mon, 2003-04-14 at 20:08, Keegan Quinn wrote: If we're going to have /run/resolver, why not use /run/resolver/resolv.conf? Fine with me. Any objections? -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
On 8 April 2003 Marco d'Itri [EMAIL PROTECTED] wrote:
On Apr 07, Thomas Hood [EMAIL PROTECTED] wrote:
A difficulty is that only a whole options { ... };
statement can be included from the named configuration file,
not just the forwarders { ... }; statement inside it.
You can include a file even inside the options keyword.
On 8 April 2003 Anthony DeRobertis [EMAIL PROTECTED] wrote:
Just tested it (with a different option than forwarders) and it
seems you can certainly use
include file;
inside of options { ... }.
Unfortunately you seem to be wrong, at least with regard to
bind version 1:8.3.4-4. If named.conf (or named.conf.options)
contains:
options {
directory /var/cache/bind;
include /run/bind/named.forwarders;
};
and /run/bind/named.forwarders contains (with a real address
in place of aa.bb.cc.dd):
forwarders {
aa.bb.cc.dd;
};
then an error message is printed in the syslog on named reload:
Apr 15 20:34:24 thanatos named[25582]: /etc/bind/named.conf:23:
syntax error near include
whereas if /etc/bind/named.conf contains:
options {
directory /var/cache/bind;
forwarders {
aa.bb.cc.dd;
};
};
then there is no error message. It seems that the documentation is
telling the truth when it says (/usr/share/doc/bind/html/include.html):
The include statement inserts the specified file
at the point that the include statement is encountered.
It cannot be used within another statement, though,
so a line such as
acl internal_hosts { include internal_hosts.acl; };
is not allowed.
Were the two of you running a different version of bind?
On 8 April I wrote:
I'm glad to hear this because it means that one could
include a file containing only the forwarders { }
statement.
I'm now disappointed to discover that this is not possible.
--
Thomas Hood [EMAIL PROTECTED]
Re: stop the manage with debconf madness
On Thu, 2003-04-17 at 01:08, Colin Walters wrote: I just installed laptop-net, becuase it looked similar to something I'd like to work on. You might want to look at ifupdown-roaming too http://panopticon.csustan.edu/thood/ifupdown-roaming.html -- Thomas Hood [EMAIL PROTECTED]
Re: If Debian decides that the Gnu Free Doc License is not free...
[Subject line shortened and cc: list cut down] On Mon, 2003-04-21 at 08:08, Hans Reiser wrote: I find it unspeakably ingrateful to Stallman that some of you begrudge him his right to express his (discomforting to some) views to all who use his software, and to ensure that they are not removed by those suits who are discomforted. I, for one, am not ungrateful for the contributions that Richard Stallman and you -- Hans Reiser -- have made. If, however, you are saying that Debian can only use your work on the condition that Debian becomes your mouthpiece, then I find that an unacceptable demand. No gratitude is due for software that comes with such conditions attached. Such a tainted offer should be politely declined. (By the way, I don't think that suits have a lot of influence over what happens in Debian. Debian developers are concerned, above all, with making a free operating system.) As far as I am concerned, I have no desire to have ReiserFS distributed for free by anyone who removes the GNU manifesto or similar expressions from Stallman's work (or my own) and redistributes it. It is simply a matter of respect that is due the author. Respect is due; but it is up to Debian to decide how to show respect. The central question is this. If you are not satisfied by Debian's show of respect, what are you going to do about it? Consistently with freedom you can write to the Debian maintainer, complain on a mailing list, and so on. Fine. Hopefully an accommodation can be found. If, on the other hand, you assert a legal right to be shown respect in a way that you determine, then it becomes clear that your work is not DFSG-free and so not distributable by Debian. ReiserFS will be converting to the Gnu Free Doc License for its documentation. I look forward to the release of GPL V3 which will hopefully cover fair crediting of code as well as documentation, and stem this rising tide of plagiarism and political bowlderization by distros. I think it is altogether reasonable to require that the authors of software be credited. However, it must be up to Debian to decide how to give that credit. Bowlderization is the removal of content from works. The issue there is freedom of speech, not software freedom. Free speech is indeed important in all areas of life. Debian should not interfere with anyone's freedom of speech. Notwithstanding this, Debian's role is not that of soapbox for politically active programmers. So, while Debian might choose to distribute this or that text (unbowlderized!) as a service to its users, IMHO it should not under any circumstances allow itself to be *compelled* to distribute any text verbatim, no matter how attractive the software to which that text is attached. An exception is made for license texts. DFSG 4 determines how far Debian can go to accommodate an author's demand that his or her code be distributed unchanged. Yes, Debian will agree to distribute the original code, but only if the code can be patched for building. So, in the case of mkreiserfs: Yes, Debian will agree to distribute the original code with its excessively verbose credits message, but only if the message can be omitted from the running program. Out of respect for the authors, Debian should also include the message in the doc directory and under --version. But if I were the maintainer I wouldn't go any further than that. I want the same visibility of credits for reiserfs that movies give for their actors. I don't want the distro choosing how they are displayed because some distros do things like create boot time splash screens that tell about themselves instead of the authors, and so I have to say that their track record demonstrates that they cannot be trusted with that task. I think the authors should be the ones to decide how to list the credits. Any end user should of course be free to delete all the credits he wants to. It is becoming clearer that your software is not DFSG-free. -- Thomas Hood [EMAIL PROTECTED]
/run/, resolvconf and read-only root
/interface/lo and run update-resolver * dnscache * Something similar 3. Read-only / == If / is to be mounted read-only in normal use, files that are modified in normal use cannot be stored in /etc/. TODO, wishes filed * sysvinit #150355: Move motd to /var/lib/ #188087 [DONE in 2.85-1]: Eliminate ioctl.save * util-linux #156489 [PENDING?]: Move adjtime out of /etc/ * ppp #187756: Tolerate read-only /etc/ * pppconfig #187810 [PENDING?]: Support read-only /etc/ #187651: Make resolv.conf futzing optional * cupsys #187954 [PENDING]: Move printcap.cups under /var/ TODO * ppp * Change /usr/sbin/pppd to: * Store pidfile in /run/, not in /var/run/ * dhcp3-client * Change /sbin/dhclient to: * By default, store pidfile in /run/, not in /var/run/ * ifupdown * Store ifstate in /run/network/, not in /etc/network/ * diskless tools * Fix * sysvinit * Add support for mounting / read-only. * Add support for mounting /run/ as a separate filesystem. * The patches in #30446 and #186892 should be reviewed in implementing this. WONTDO * linuxlogo #187953 [REJECTED?]: Do not store linuxlogo files in /etc/. The administrator will have to deal with linuxlogo files. -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
Jamie Wilkinson wrote: That is right! The core of the matter is not whether filesystems need to be mounted over the network or not, but whether the parts of the filesystem you are attempting to write to are on the root filesystem or not. The essence of /run/ had better not include that it be a directory on the root filesystem, because the current proposal is that it be possible for /run/ to be a RAM-based filesystem on systems with read-only root media. [... in another message:] Thus we don't need to compare /run to /var/run, but make /run available for the same purposes of the entirety of /var but only in the case that a required subdirectory of /var doesn't exist. I balk at this. IMHO we should call the new directory '/run/' if and only if we are going to use it for the same purposes for which we use /var/run/. If the new directory is to be a whole parallel local var hierarchy then we should call it something like '/lvar/'. However, I don't think we need a whole parallel local var. This works for the case that some programs need a /var/run and some need a /var/state and some need a /var/lib for their file; /var/state/ is deprecated. Files stored in the proposed new directory will be lost on reboot, so it is not suited to be a lib directory. there will be so few programs actually using /run that there is no need to separate /run into further subdirectories for each of the /var subdirectories. /var/ contains thirteen subdirectories on my system. For which of these is a guaranteed-to-be-local variant needed? So far, a case has been made only for run. With thanks for your /run/ patches... -- Thomas Hood [EMAIL PROTECTED]
Re: /run/, resolvconf and read-only root
On Mon, 2003-04-28 at 00:01, Sam Hartman wrote: 1) Why are people mounting root read-only? Frank (Not his real name) has a machine with a local read-only boot medium and a network connection but no local hard disk. Jane finds it nice that her /etc/ hierarchy changes only when she administers her machine, not during normal use, and that /run/ contains information only relevant to the current boot session. This makes it easier for her to make and keep track of her backups. George mounts /etc/ read-only because it seems like this ought to increase the security of his system. 2) When root is read-only, what information is variable and what information should be immutable? The distinction between variable and non-variable is drawn by the FHS. It was the basis for splitting /var out of /usr. Why is this a reasonable categorization? It is reasonable to distinguish between variable and non-variable files because the distinction makes it possible to segregate the different sorts of files into different filesystems which may be then be handled differently -- e.g., stored on different sorts of media. 3) What information needs to go in /var vs /run? Because /var can be an NFS mount, some programs (e.g., networking daemons) necessarily run before /var is available. Those that need to store state in a run directory will use /run/. All others must use /var/run/. I will follow any related changes to policy to the best of my ability. OK, but we should not wait for policy to change before implementing this. -- Thomas Hood [EMAIL PROTECTED]
Re: /run and read-only /etc
On Mon, 2003-04-28 at 18:30, [EMAIL PROTECTED] wrote: I don't like the idea of having multiple files to turn off logins. (I can't log into my system, and /etc/nologin doesn't exist! What? didn't you know about this *other* file?) I also don't want to solve this with a symlink. Yes, let's try to depend as little as possible on symlink solutions. It seems reasonable to me that if logins can be locked out either variably (by a program) or non-variably (by the administrator) -- each way independently of the other -- then each should have its own key to the lock. Of course there are many ways to implement a shared lock. I would favor (even though it's weird from the pan-unix admin point of view) just deprecating /etc/nologin in favor of something more sensible. So you would prefer it if /etc/nologin were simply replaced by, e.g., /run/nologin? It would also be nice to have some blessing of /run in the policy first, but that doesn't seem terribly likely. What is more important for now is whether there is broad enough agreement with the reasoning behind /run/. These are not strongly held positions. Please do try to convince me to be less of an obstruction I don't have strong views about the fate of nologin either... except that it should not be in /etc. Perhaps Jamie Wilkinson will have more to say on this subject. -- Thomas Hood [EMAIL PROTECTED]
Re: Bug#191036: create /run for programs that run before /var is mounted
I agree with Manoj when he says: I think it is premature to [r]atify into policy an action that has not been fully decided upon, and has not yet had all the kinks ironed out [...] However, there does need to be some discussion of what properties /run/ will have. Early in the debian-devel discussion it was suggested that /run/ be required to be RAM-based, that it be initialised with a skeleton, etc. As the discussion went on there seemed to be agreement that /run/'s properties should be determined by the problem it is solving, namely, the problem of there being nowhere to store runtime state prior to the availability of /var/run/ on a system that mounts /var/ from the network. To solve this problem, /run/ needs to be available locally so that it can be mounted early, probably by /etc/rcS.d/S35mountall.sh . I would argue that for the present /run/ should be so defined, and otherwise should be implemented as simply as possible. Proposed list of properties of /run/: * Available and empty after /etc/rcS.d/S35mountall.sh runs * No skeleton * Files stored in /run/ are not reaped * A program should *only* use /run/ if it *must* do so because it has to store something before /var/run/ becomes available on systems that mount /var/ over NFS. -- Thomas Hood [EMAIL PROTECTED]
Re: /run/, resolvconf and read-only root
Whether we end up with /run/, resolvconf and read-only root depends a lot on whether the maintainers of the affected packages support the project. So far the response has not been positive. Here is a quick summary for the packages that were on my TODO list. Creating /run/ base-files Change policy first pamNot convinced; wait and see login Perhaps; change policy first sysvinit (no reply) util-linux (no reply) Implementing variable resolver configuration pump OK ppp(no reply) pppconfig (no reply) ifupdown Don't bother me Moving variable files out of /etc/ cupsys OK util-linux Looks OK sysvinit (no reply) ppp(no reply) pppconfig (no reply) linuxlogo No + sarcasm -- Thomas Hood [EMAIL PROTECTED]
Re: /run/, resolvconf and read-only root
On Wed, 2003-04-30 at 15:13, Arthur de Jong wrote: I think it should be possible for any program that writes to /etc (it it cannot use /var) either to be configurable to store it's data somewhere else or use a symlink to store the data somwhere else (e.g. /proc/flashrom or /nfsmounteddiskbutnotroot or other unusual place). I think that should be the first step in tris transition. Would you find /etc/run/ more acceptable? I haven't seen a very good description of /run yet and I'm not completely sure that something like a place to write files to when you can't write to /var yet is useful. This is not a useful description because /var may be mounted at different times on different systems (e.g. nfs mounted /var vs localy mounted /var). The description does not have to be much more specific than that in order to guarantee that /run/ solves the problem, which is that there are certain programs pre-required for networking which, ipso facto, cannot use network-mounted filesystems to store their state. Is /run/ useful? It solves the problem. Of course, it is not the only possible solution to the problem. If you wish, you can regard /run/ as an interim solution, to be used until such time as programs are rewritten to make /run/ no longer necessary. -- Thomas Hood [EMAIL PROTECTED]
Re: /run/, resolvconf and read-only root
[/run/ and] read-only root ~~ The /run/ idea is shelved, unless someone wants to take up the torch for it. Run-time state files moved out of /etc/ will have to go into /var/run/. The program, therefore, is: 1. Wherever possible, state files in /etc/ should be eliminated or moved to /var/run/. 2. If the latter cannot be done then programs should at least support the file being replaced by a symlink to a location outside of /etc/. There has been some progress on #1. For example, ioctl.save has ceased to be, and printcap.cups is now kept in /var/run/cups/ . Some files can be dealt with in way #2; for example, ifstate. A summary of progress to date be found in the README file at: http://panopticon.csustan.edu/thood/readonly-root.html resolvconf ~~ The resolvconf initiative is now being hosted on alioth. The name of the project is update-resolv. http://alioth.debian.org/projects/update-resolv/ Interested parties are invited to subscribe to the update-resolv-devel mailing list and to examine the latest release of the resolvconf package. (The current release is 0.6.) -- Thomas Hood [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
Re: Update re: read-only root filesystem
On Sun, 2003-06-22 at 01:02, Xavier Roche wrote: There are other problems : for example it seems that the system changes the /dev/ttyXX or /dev/pts/XX ownership depending on who is being logged in.. To tell the truth, I didn't realize that so many files in /dev/ were being fiddled. Obviously, one solution to the problem is to have a separate writable /dev/ filesystem, e.g., devfs. The question is: Should we concede that a separate /dev/ fs is required for running with a read-only root filesystem, or should we take steps to eliminate fiddling with /dev/ files? I haven't looked into this question at all, since I have been satisfied with devfs. Is there a list of devices that are supposed to change (rights/ownership) during time? Look in the SE Linux packages for this kind of information. And should I fill a BTS for the /etc/init.d/sysklogd bogus with read-only /dev problem anyway? It is worth filing a report to ask that the script not try to change the permissions and ownership of the pipe if it is not necessary to do so, and that it tolerate failure. I'll file it. -- Thomas
Re: Update re: read-only root filesystem
On Sun, 2003-06-22 at 11:52, Xavier Roche wrote: Another remark for the HOWTO : mounting /tmp in tmpfs (since 2.4.1 ?) allows you not to resevre space for /tmp on a specific partition Remark added. The question is: Should we concede that a separate /dev/ fs is required for running with a read-only root filesystem Dunno.. shall we consider devfs and tmpfs as standard (which is IMHO a good idea) for future releases? No need. It is sufficient that /tmp/ and /dev/ be separate, writable, filesystems. It is a local decision whether to make these tmpfs and devfs, respectively. -- Thomas
Resolvconf -- a package to manage /etc/resolv.conf
these packages for use with resolvconf. I hope that in the fullness of time, seamless resolvconf support will be added to these packages too. In general, any package that currently overwrites /etc/resolv.conf can be adapted to work with resolvconf while preserving backward compatibility by introducing a code fragment like the following. if [ -x /sbin/resolvconf ] ; then if [ $DIRECTION = up ] ; then echo -n $RESOLVINFO | /sbin/resolvconf -a $IFACE else /sbin/resolvconf -d $IFACE fi else (... existing resolv.conf cleverness ...) fi Credit ~~ The basic idea for resolvconf originally came from Emile van Bergen. I claim any braindamage in the implementation as my own. Status ~~ Resolvconf is ready for consideration and experimental use. Get it in the resolvconf section of the update-resolv project at alioth. http://alioth.debian.org/projects/update-resolv N.B. If you have an earlier version of resolvconf installed on your system then you must PURGE that version before installing this one; otherwise obsolete configuration files might be left around. Feedback about the package is welcome. Please let me know about any other packages that should be made to work with resolvconf. Future ~~ * Before entering the Debian archive it would be nice if resolvconf were supported by all packages that currently futz with /etc/resolv.conf, including pump and bind. * The scripts in /etc/resolvconf/update.d/ should go into the packages of the same names. -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sat, 2003-07-05 at 22:40, Simon Hürlimann wrote: I'd prefer update-resolv like update-alternatives update-initrd update-catalog update-ispell-dictionary update-default-aspell update-menus update-default-ispell update-mime to name just a few. Resolvconf isn't really comparable to the update-* utilities. Unlike them, resolvconf takes information on its standard input. And unlike them, it run during normal use of the machine, not at administration time. The update-* programs usually modify files in /etc/, whereas one of the reasons for creating resolvconf is to avoid modifying files in /etc/. -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, 2003-07-06 at 01:00, Goswin Brederlow wrote: You should think of a mechanism for daemons to get notified about changes in resolv.conf. There is already such a mechanism. See below. Like providing a function to register a script and a list of arguments (like the PID of the program to notify). Whenever the resolv.conf changes all currently registered scripts would be called with their respective arguments. The simplest form would be: resolv.conf-register /etc/init.d/squid reload That would make squid to reload its config each time a nameserver is added or removed. Currently, scripts in /etc/resolvconf/update.d/ get run when resolver information changes. So, would it suffice to create /etc/resolvconf/update.d/squid containing the following? #!/bin/sh /etc/init.d/squid reload -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, 2003-07-06 at 01:32, Marco d'Itri wrote: On Jul 05, Thomas Hood [EMAIL PROTECTED] wrote: * Before entering the Debian archive it would be nice if resolvconf were supported by all packages that currently futz with /etc/resolv.conf, including pump and bind. If you mean that if should be mandatory to install this package on every name server, then it would not be nice at all. No, I meant that before entering the Debian archive it would be nice if resolvconf were supported by all packages that currently futz with /etc/resolv.conf, including pump and bind. -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, 2003-07-06 at 12:13, Thomas Hood wrote: No, I meant that before entering the Debian archive it would be nice if resolvconf were supported by all packages that currently futz with /etc/resolv.conf, including pump and bind. Which other packages? I guess I need to explain more clearly. First. Currently, making certain packages work with resolvconf requires some manual changes to configuration files. The changes are not large: just adding a couple of lines to initscripts and such. Still, I think it would be nice if such packages worked with resolvconf -- if resolvconf happens to be installed -- without requiring any manual changes. I won't explain here how this can be done; please see the announcement and bug reports #194204 and #199255 for details. At the moment, the only packages I know of that need some adaptation are pump and bind. There are probably others. Someone has mentioned squid, so I will investigate squid later today, but at first glance it looks as if no changes to squid will be required. Second, resolvconf's usefulness in allowing the relocation of variable files out of /etc/ will be greatest if packages that currently write resolver information into files in /etc/ , such as pump, are changed so that when resolvconf is installed they send that information to resolvconf instead. Again, please see #194204. My aim is not to make resolvconf mandatory; it is to have packages work properly with resolvconf *if* resolvconf is installed. When resolvconf is not installed, other packages should continue to do what they did before. -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, 2003-07-06 at 12:42, Eduard Bloch wrote: Please, would you consider to add another feature: priorising some entries depending on the source. That means: pppoeconf's and pppconfig's script run the tool with parameter --class dialup, dhcp clients with --class dynamic and the default class would be static. In some config file, the user defines that dialup gets priority one, dynamic two and static three (for example), and resolvconf merges the existing dns entries in the appropriate order. Let me start by saying that resolv.conf is generated by /etc/resolvconf/update.d/libc , which, being a conffile, can be customized by the admin. Your idea strikes me as a good one. It would add some complexity to the system, but it would provide more information for /etc/resolvconf/update.d/libc to use when it generates the resolv.conf file. Currently the script discriminates only on the basis of interface type (i.e., lo, ppp or eth). However, I would only want to add this feature if we were certain that it was needed. -- Thomas Hood
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, 2003-07-06 at 01:52, Nick Phillips wrote: Actually I think the simplest form would be to have /etc/resolvconf/notify.d and run all scripts in there at the relevant times, with any necessary arguments (which would be standard). Please take a look at how resolvconf runs the scripts in /etc/resolvconf/update.d/ and let me know if you think anything else is needed. Alioth was down for a while but I just checked and the deb is once again available (in the resolvconf section of the update-resolv project). http://alioth.debian.org/project/showfiles.php?group_id=1227 -- Thomas
Re: Juridical prosecution
On Mon, 2003-07-07 at 09:48, Andreas Tille wrote: On Sun, 6 Jul 2003, Branden Robinson wrote: And the cluelessness Oscar this year goes too... Mr Sobek But the competition is always so fierce, and the year isn't over yet... But I wonder if some clever person might just fake cluelessness to grab the price. How to distinguish those people? If it is a cluelessness _Oscar_, then presumably it is an award for faking it; no? Beware, this might be my own attempt to win. -- Thomas Hood
Resolvconf 0.28
I wrote: Currently, scripts in /etc/resolvconf/update.d/ get run when resolver information changes. So, would it suffice to create /etc/resolvconf/update.d/squid containing the following? #!/bin/sh /etc/init.d/squid reload As of resolvconf 0.28, such scripts should be placed in /etc/resolvconf/update-libc.d/ . Resolvconf needs more testing. Get the .deb in the resolvconf section of the update-resolv project at alioth: http://alioth.debian.org/projects/update-resolv/ If you have comments, please send them to me; and join the update-resolv-devel mailing list also at alioth. -- Thomas Hood
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 08:47, Andreas Metzler wrote: It really sucks to handle this if you want/need to get rid of it (if it is unmodified) not only on purge but on upgrades. - You'll need if [ $1 = configure ] \ dpkg --compare-versions $2 le-nl 1.2.3 \ [ -e /etc/foo ] \ [ `md5sum /etc/foo | cut -d\ -f1` = 6bea09fbb18e4676012105fa5fc726c6 ] then echo Removing orphaned unmodified configfile /etc/foo 12 rm /etc/foo fi In a discussion that followed from this thread off-list, some people agreed that the administrator should be asked what he or she wants to do with an obsolete conffile. The conffile should not be deleted silently because other packages may be using the file. Here is how I see it. On install of the new version of foo which lacks the former foo conffile /etc/foo.conf, * dpkg informs the user that /etc/foo.conf is no longer a conffile of foo; * dpkg says whether or not /etc/foo.conf was changed from the original; * dpkg offers to display the file, to start a shell so that the user can check things out, or to do one of three things to the file: * leave the file as it is (= the current behavior), * delete the file (= the default if the file has not been changed), or, * rename the file to /etc/foo.conf.dpkg-old (= the default if the file has been changed) -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 14:53, Stephen Frost wrote: * Thomas Hood ([EMAIL PROTECTED]) wrote: Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. The maintainer should really know. The maintainer is more likely to know than the user in many cases. I think it would be worthwhile for policy to be modified to require notification when a sharing of this kind happens. I know that I'd expect someone to tell me if they're using a conffile from my package. If this were required in policy, then there ought to be an easy way to comply. We could allow packages to list Conffiles that are not shipped with the package; these would have to be included in some package upon which the dependent package Depends. That would give dpkg the information it needs to decide whether it is OK to delete the conffile when foo abandons it. If bar listed foo.conf as a conffile, then bar could inherit the file when foo abandoned it. Perhaps that could be made to work, but it would be complex, and dpkg is already beyond the capacity of Debian to maintain properly. -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
Permitted or not, lots of packages do it. 32 on my system. Just try doing this on your own system: grep 'rm -rf' /var/lib/dpkg/info/* | grep /etc A lot of packages put configuration files into directories that belong to other packages. Maintainers of such packages should make sure that the host package's postrm doesn't wipe out their configuration files on purge. -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
On Fri, 2003-07-25 at 07:59, Manoj Srivastava wrote: Umm. apt allows you to determine reverse depends. From there there is an easy hop to sending email to ask the develoeprsa in question; or to exaimine a package to look at its conffiles. This doesn't solve the problem of the dependent package being broken by the removal of the conffile upon which it has been depending. A _new_ version of the dependent package may have been released to the archive, but this is not the version that the victim has installed on his computer. Nick Phillips made a good point, however, when he said that conffiles are no different from other files in this respect. If bar depends on foo, then bar might be broken if _any_ file is removed from foo. Yet we do not do anything special when foo version 2.0 lacks an ordinary file that was contained in foo version 1.0. So we should not do anything special for conffiles either but (as Manoj Srivastava says) we should rely on communication among maintainers to avoid problems. Conffiles are different in one respect, which that is that they can be locally modified. When a conffile is to be overwritten and it has been modified, the user is asked for permission and the old version is backed up as *.dpkg-old. So when a conffile is to be deleted and it has been modified, the user should be asked for permission and the file renamed to *.dpkg-old (or *.dpkg-orphaned). Agree? -- Thomas
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
Re: 1. dpkg -L 2. conffiles belonging to the package 3. configuration files other than conffiles belonging to the package 4. package's log output, cached compiled versions of conffiles, etc. 5. user data created using the package On Fri, 2003-07-25 at 09:01, Manoj Srivastava wrote: Here is my suggestion for how purge should be handled. Purge would delete #1 through #4 _and_ everything in /var/lib/pckg/. User data created using the package [#5] must then not be stored in /var/lib/pckg/ but somewhere else, e.g., in someone's home directory. Dosemu, for example, could store the not-to-be-purged DOS image in user dosemu's home dir. umm, no. Postgres should certainly not try and store the database under /home; since the DB can grow huge. It would be awfully convenient if packages could do a rm -rf /var/lib/pckg/ on purge, but we know this deletes things in some cases that should not be deleted. So I am proposing that rm -rf /var/lib/pckg/ always be permitted, and that any data that is not to be deleted on purge be stored elsewhere. I don't say where else it _should_ be stored. Perhaps postgres data could be stored in another subdirectory of /var/lib/, e.g., /var/lib/postgres-data/ . That understood, is the proposal sound? -- Thomas
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
On Fri, 2003-07-25 at 11:19, Manoj Srivastava wrote: Not really. Why do we need this overly micromanaging rule in policy? As long as it understood that user data is not to be deleted, why can't I put user data in /var/lib/pkg/ if I so desire, as long as I take care to not rm -rf that dir? That's fine. The original complaint [1] was that dosemu purged user data. At some stage it was suggested [2] that packages should not delete entire directories indiscriminately. I replied [3] that packages be allowed to delete at least /var/lib/pkg/ . You are right that we should not _require_ any package to delete its /var/lib/pkg/ . What I am more concerned about is configuration file directories. A lot of packages delete /etc/ trees on purge. Earlier I was thinking that Debian should have a policy forbidding that, but now think that existing policy may be sufficient. Under current policy, a package can delete /etc/foo only if no other package uses /etc/foo to store configuration files. If another package does use /etc/foo to store configuration files then deleting those files would violate 10.7.3 and 10.7.4 . [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=201023 [2] http://marc.theaimsgroup.com/?l=debian-develm=105827881413400w=2 http://marc.theaimsgroup.com/?l=debian-develm=105833979508949w=2 [3] http://marc.theaimsgroup.com/?l=debian-develm=105878073004572w=2 -- Thomas
Re: unicode
On Fri, 2003-07-25 at 11:20, Colin Watson wrote: On Fri, Jul 25, 2003 at 10:04:26AM +0100, David Pashley wrote: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. In groff \- is a dash, - is a hyphen. People need to use the right one. If you have other problems let me know, since I'm not aware of any in unstable right now. In unicode, there are at least these: ASCII hyphen- (0x2D) hyphen (0x2010) non-breaking hyphen (0x2011) subtraction sign (0x2212) en dash (0x2013) em dash (0x2014) horizontal bar (0x2015) -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
On Fri, 2003-07-25 at 11:21, Manoj Srivastava wrote: On 25 Jul 2003 09:20:20 +0200, Thomas Hood [EMAIL PROTECTED] said: Conffiles are different in one respect, which that is that they can be locally modified. When a conffile is to be overwritten and it has been modified, the user is asked for permission and the old version is backed up as *.dpkg-old. So when a conffile is to be deleted and it has been modified, the user should be asked for permission and the file renamed to *.dpkg-old (or *.dpkg-orphaned). Agree? No. Since this scenario only happens when the conffile is going to be ignored anyway, why do I want to have an locally modified version lying around by default? If the conffile is unmodified it is removed. If it has been modified then the default option (of the two presented to the user) would be to rename the file. If you are asking why there should be a backup, then notice that the same question can be asked about any backup file. Perhaps you are thinking that no backup is needed because foo no longer lists foo.conf as a conffile. But it is quite easy to imagine circumstances in which the admin might want to look in the old conffile. Perhaps he will need the values in it when he uses foo's fancy new debconf-driven configuration scheme. :) So why rename the file at all? Because the *.dpkg-old suffix will deactivate the file if it is in a run-parts directory and will generally make it clear that the file is no longer in use. -- Thomas Hood
Re: Interesting problem in timezoneconf package
On Sun, 2003-07-27 at 12:44, Colin Watson wrote: I tested this before posting. No, -e is a little more forgiving than that, as stated in bash(1): -e Exit immediately if a simple command (see SHELL GRAMMAR above) exits with a non-zero status. The shell does not exit if the command that fails is part of an until or while loop, part of an if statement, part of a or || list, or if the command's return value is being inverted via !. A trap on ERR, if set, is executed before the shell exits. I just tested this too, because I thought that one had to do [ $CTL != yes ] || takeaction rather than [ $CTL = yes ] takeaction when -e was set in order to avoid immediate exit on the failure of the $CTL=yes test. Experiments prove that neither of these causes immediate exit, even though the second one does have a nonzero status when $CTL != yes. -- Thomas
Bug#203131: ITP: resolvconf -- Nameserver information manager
Package: wnpp Version: unavailable; reported 2003-07-27 Severity: wishlist * Package name: resolvconf Version : 0.31 Upstream Author : Thomas Hood [EMAIL PROTECTED] * URL : http://alioth.debian.org/projects/update-resolv * License : GPL Description : Nameserver information manager Simon Kelley [EMAIL PROTECTED] has agreed to co-maintain this package with me (Thomas Hood [EMAIL PROTECTED]). (Longer Description) Resolvconf is a framework for keeping track of the system's information about currently available nameservers. It sets itself up as the intermediary between programs that control network interfaces and supply nameserver information, and applications that need nameserver information. . This package contains hook scripts that cause resolvconf to collect resolver information from the PPP daemon, DHCP clients and ifupdown. It also contains update scripts that provide this information in the required format to the libc resolver and bind. Other packages such as dnsmasq and laptop-net also include hooks and update scripts for integration with the resolvconf system. (Announcement) Summary ~~~ Resolvconf is a proposed standard framework for updating the system's information about currently available nameservers. Most importantly, it manages /etc/resolv.conf , but it does a bit more than that. Background and rationale During the long discussion on debian-devel about making it possible to mount the root filesystem read-only, it was pointed out that one of variable files standing in the way is the libc resolver configuration file, /etc/resolv.conf . Several programs modify this file as network interfaces are brought up and down. This situation is undesirable not only because it stands in the way of a read-only rootfs but also because it prevents the user from running more than one configurer at a time: the second process would overwrite the first process's changes to resolv.conf. The latter problem could be addressed by making configurers cooperate somehow; but this would not meet another major need: the need to supply resolver information to DNS cache programs such as named and dnsmasq. Various packages have addressed these issues, but only partially and idiosyncratically. Resolvconf aims to solve the problem simply and completely. Resolvconf ~~ /sbin/resolvconf is a short sh script which I have packaged together with some hook scripts in a package also called 'resolvconf'. Resolvconf mediates between programs that supply resolver information (mainly interface configurers) and those that consume resolver information (the libc resolver and DNS caches). Please read the package README file for detailed information. Here is a summary of how resolvconf works. Usage ~ Interface configurers send resolver information to resolvconf in the format of the familiar /etc/resolv.conf file. Thus, for example, a program that has configured interface $IFACE would do the following after generating a resolv.conf file named 'new-resolv.conf'. resolvconf -a $IFACE new-resolv.conf This command updates the resolver information related to interface $IFACE. Any information previously sent for this interface is overwritten. On bringing the interface down, the configurer would do the following. resolvconf -d $IFACE For another example, a proxy script for pppd could forward to resolvconf the resolver information that is made available to ip-up.d/ and ip-down.d/ scripts in environment variables DNS1, etc. echo nameserver $DNS1 | resolvconf -a $IFACE These are just examples. Appropriate hook scripts are included in the resolvconf package for ppp, dhcp3-client and ifupdown (for static inet ifaces). Support for other configurers including dhcpcd and laptop-net has been added to scripts belonging to those packages. /sbin/resolvconf stores the information sent to it and then runs the scripts in /etc/resolvconf/update.d/ . One of the latter generates the libc resolver configuration file. Another generates the options portion of the BIND named configuration file, containing a forwarders statement listing available nameserver forwarders. (This allows named effectively to be used as a DNS cache on a system whose network environment varies, e.g., on a laptop.) Another generates a list of forwarders for dnsmasq to use. Any other program that needs to take action when resolver information is updated could likewise employ a script in /etc/resolvconf/update.d/ . The generation of the resolv.conf file (actually stored at /var/run/resolvconf/resolv.conf , to which /etc/resolv.conf is to be symlinked) can be controlled by the admin by editing /etc/resolvconf/update.d/libc . Different strategies can be implemented: e.g., one possible strategy would be to put only the most recently provided information into resolv.conf . The current default strategy is to put *all* available resolver information
