Re: possible bug in gettext (autotools?) or in some packages
Yo KoV, On Thu, 03 May 2001, Gustavo Noronha Silva wrote: I noticed while creating a package for a gettext enabled program, that make install was installing the .mo file as progname@INSTOBJEXT@ Well, file important bugs against those packages, telling them to fix their packages to refresh and use the debian-provided gettext instead of keeping the cruft from upstream around. Any Debian developer that needs to do this and doesn't know how, please feel free to contact me. I had a lot of misadventures with gettext lately in fetchmail, so I'm currently well-versed in the topic. I just changed po/Makefile.in.in to match: INSTOBJEXT=.mo instead of INSTOBJEXT= @INSTOBJEXT@ INSTOBJEXT doesn't even exist anymore in gettext 0.10.37... but I don't think that's clean enough... You're right. It isn't :) comments? Try installing the sid gettext package, and running gettextize -c -f in the broken package's top source directory (don't forget to run aclocal, autoheader and autoconf to rebuild the configure script using the updated gettext macros, or else all hell breaks loose). It just might fix the whole crap in one go, if the makefiles are sane. Be warned that the new gettext does not tolerate much of the broken crap people sometimes toss into .po files as the old one did (which is a Good Thing, btw). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpVpTCqFe86B.pgp Description: PGP signature
Re: debbugs can now send bug mails to someone different than the maintainer
On Tue, 01 May 2001, Brian May wrote: Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes: Henrique Fetchmail is not the best tool for dealing with the Henrique Debian developer mail accounts, plain and simple. Why not? Because there isn't a IMAP or POP3 server at the other side... and using shell scripts is easier and faster when doing BSMTP-style delivery over an ssh tunnel. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpgmOoKHUYP9.pgp Description: PGP signature
Re: debbugs can now send bug mails to someone different than the maintainer
On Mon, 30 Apr 2001, Rahul Jain wrote: On Mon, Apr 30, 2001 at 09:06:01PM -0400, Matt Zimmerman wrote: The client side of fetchmail will (by default) feed each message into your local MTA for delivery, but you'll have to figure a way to get the mail into it from the remote mailbox without IMAP or POP services (which I don't think master provides). I think someone was working on ETRN recently, which is also supported by fetchmail... hrm... having fetchmail ssh in and grab the mail directly from the spool would be kind of cool... :) Well, I am the fetchmail maintainer and I use a non-fetchmail based (but ssh and cron-based) solution. Make of that what you will. I think you could also ask Branden what he thinks of using fetchmail to get mail from master.d.o... he should have some colorful thoughts on the issue, I believe :-P Why, he might even have wounded my feelings when he made those comments in IRC, were I already NOT using fetchmail to get mail from master.d.o ;-) Fetchmail is not the best tool for dealing with the Debian developer mail accounts, plain and simple. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpPLl7yfxK6Q.pgp Description: PGP signature
Re: RFC: English translation list
On Sun, 29 Apr 2001, Joey Hess wrote: What I am proposing is a new list, similar in scope to the other l10n lists, where developers can bring text they need a clean English version of (be the original in some other language, or their best try in English), and get a good English translation back. I think that would be a very good idea. I've found myself needing grammar help from time to time (and I am also known to do terrible things to prepositions :P), and I'm sure many other non-native English speakers find themselves in such trouble often. Also, I've seen very criptic/bogus text in package descriptions, README files and manpages... and I'm not even that good at English, so I'm pretty sure I didn't notice half of them. A central place to exert some help in that area would benefit Debian, I think. I'm offline so I'm not sure what a proper list name would be, probably either debian-english or debian-i18n-english, or debian-l10n-english or whatever parallels the other lists for other language translations. I'd prefer -18n-english or -10n-english, to avoid a dangerous parallel to the various debian-language lists used for user support. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: ITP: tads
On Tue, 09 Jan 2001, Daniel Schepler wrote: I'm planning to package TADS, which is a system for writing or playing text games similar to the Z-code system (inform, xzip/frotz/etc). The license is non-free. You should probably package the runtime and the compiler in separate binary packages... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
This is my answer to a private mail (it seems...) I don't want to talk about these in private. Please note the reason why I carried this bug report to the list. Well, sorry but now you're in MY non-permanent (YET) shitlist for violating netiquette, and I'll have to acknowledge that Branden Was Right (tm) about you. Hint: next time, ASK FOR PERMISSION FIRST before you do a public posting of private email. Geez. You'd have gotten it, but it is a matter of principle to ask first. On Sat, Jan 06, 2001 at 02:59:31PM -0200, Henrique de Moraes Holschuh wrote: You've already gotten into Branden's permanent shitlist. Please be more reserved on ANYTHING you do that might even remotely involve his packages, ok? We don't need him going psycothic again. Branden, please understand this for what it is meant: Branden does not like to be poked. He seems to like even less to be poked by you. Please don't poke him, he'll bite back and we get to watch the fallout. What is this supposed to mean? There are many users here suffering from this problem since this is a multi-user system and none of them have the time to learn the peculiarities of x. They, and I, just want to use this stuff and I moved the system to unstable because it seemed we needed some of the bug fixes... It means your X *may* be configured not to allow anyone but root to execute the wrapper. Check the damn Xwrapper.config file. I even said that over private mail to be nicer and not bother this list with yet another redudant reply... The Xrapper.config issue has been documented in a number of bug reports (search the BTS), and probably many -user and -devel posts (search the list archives, mind the sometimes quirky search engine). of a particular developer. On the contrary, every developer should be required to deal with every bug report in an objective manner. [*] Which I think is the Most developers (if not all of them) deal with bug reports in an objective manner, or don't deal with them at all (because they're MIA or are very short on time). Okay, i'll check that. Hadn't found that myself. Thanks. I'm downgrading X now, but I might need this information. FYI I'm running up-to-date sid X packages here, and they seem to work just fine. This was discussed in d-user, d-devel and numerous bug reports to the point that Branden would go Overfiend on *anyone* asking it again. I've never seen this mentioned, nor is it written down anywhere and I don't think that mailing search stuff really works... And I wouldn't think I'd be That mailing search stuff has some weird problems, yes. As for not being written down anywhere, the postinst asks you about it. I think there is a manpage for Xwrappers.config, but it's not installed in my system. able to find it with this much info (i can't start x as a user). Point me to an FAQ, and I will understand it then. I thought this might be some Hmm... why didn't you look at what X asks during configure phase, as well as the files in /etc/X11? That's usually a very good first check before posting a question. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpiFdiMiBngq.pgp Description: PGP signature
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
On Sat, 06 Jan 2001, Eray Ozkural wrote: On Sat, Jan 06, 2001 at 04:39:43PM -0200, Henrique M Holschuh wrote: Branden, please understand this for what it is meant: Branden does not like to be poked. He seems to like even less to be poked by you. Please don't poke him, he'll bite back and we get to watch the fallout. Great kiss ass. Flamewar taken to private mail. Move along people, there's nothing to see here (I hope, that is). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpEW4AvZmpdc.pgp Description: PGP signature
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Hi Erik! On Sat, 06 Jan 2001, Erik Hollensbe wrote: I don't quite get this... This list is moderated. Is it not too much for Not that I know of. I have a hard time finding the logic in wasting your time complaing about how your time is being wasted. What does this solve? Humans are hardly logic beings. And you're right, it does solve nothing, which is probably the reason why a lot of people do it at least once :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Linux Progress Patch for Debian available!
On Sun, 31 Dec 2000, Erik wrote: On Sun, Dec 31, 2000 at 09:16:33PM +0100, Bernd Eckenfels wrote: That patch has the ability for startup scripts to display messages to the screen (for such things as Initializing network, Initializing Sound, etc. I dont see why the same thing couldn't be used by the kernel drivers. It can be done. Just keep dumping the kernel ringbuffer (the same one accessed by dmesg) in a smart (and continuous) way while the system boots. Apparently the Progress Patch can't go in debian unless the above hack is included and made mandatory in the Debian packaging of the patch. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: RFC: fix for daemon start (2)
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote: I like it, but why not fold this functionality in update-rc.d itself? update-rc.d --query ? And why not define update-rc.d --list as well.. Well, for starters I don't grok perl, and I wasn't about to let that little detail stop me from writing the sample code :-) Also, update-rc.d and initscriptquery don't share much in the way of common code, I think. I don't see any major advantages in merging the two, not to mention that it would generate a new interface for update-rc.d... By keeping the two scripts separate, we avoid increasing the complexity of update-rc.d and we also keep the two interfaces independent of each other. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpkHs9pOdebR.pgp Description: PGP signature
RFC: fix for daemon start (2)
Hello everyone, Here's an updated version of the RFC text, as well as a new version of the initscriptquery reference script. The fragments.sh script is included just for completeness, and was not modified. Changelog: * fixed typos, updated documentation to an assertive tone * addressed rcS.d issue (I received no comments on this one, BTW) * handle multiple links per runlevel nicely * detect and block attempt to run initscriptquery at runlevel 0 or 6 * address pre-depends/depends issue Another small RFC dealing with administrative policy enforcement on the start of initscripts will be sent in a few days. Due to the design of initscriptquery, such policy enforcement could be done without any additional changes to other packages. There are no technical issues left for initscriptquery that I know of. It should be now in its nearly final state. RFC: Fix for initscripts being run out of their intended runlevel by package scripts (during package installs and upgrades). Interface proposal for /usr/sbin/initscriptquery script: Assumptions: Debian uses only sysvinit-compatible initscripts, stored in /etc/init.d/ (currently true for debian, file-rc uses the same /etc/init.d/ scripts as sysvinit does). The unique identifier for an initscript is the initscript ID required by the update-rc.d command. Documented Command Line Interface: /usr/sbin/initscriptquery [-q] initscript ID -q : Run initscriptquery in silent mode, errors are NOT reported to stderr initscript ID: the update-rc.d identifier for the initscript Future versions to this script MUST be fully backwards compatible. Documented behaviour of the initscriptquery script: stdin shall not be used (it is NOT an interactive script) stdout shall be used only to output usage information. stderr shall be used to output all error messages. Exit status codes: 0 - the initscript is allowed to be started 1 - the initscript is NOT allowed be started 2 - initscript ID unknown 3 - initscript ID known, but behaviour is undefined 4 - syntax error =5 - other error (usually means inconsistency in the underlining initscript subsystem) Verbose description of the exit status codes: 0 - the initscript is allowed to be started sysvinit meaning: There is a non-dangling, executable S?? link in the rc?.d directory for the given script ID and current runlevel. Also, no other administrative reasons for not starting the init scripts exist. NOTE: If an initscript would be started at the S runlevel, it is assumed that this should be true for all runlevels that don't actually stop the initscript as well. Desired behaviour: Call /etc/init.d/initscript as you'd have done before the advent of initscriptquery 1 - the initscript is NOT allowed be started sysvinit meaning: There is a non-dangling, executable K?? link (and no S?? link) in the rc?.d directory for the given script ID and current runlevel. Or, an administrative reason prohibits starting the initscript. Desired behaviour: Do not run the initscript. If the daemon is running, assume it's because the user started it manually and would like it to be left alone (feel free to issue a warning, though). 2 - initscript ID unknown sysvinit meaning: There isn't a normal file with the name matching initscript ID in /etc/init.d/ (note that the existence of a S??initscriptID link/file is NOT enough, as we are constrained to the same namespace used by update-rc.d). This might happen if update-rc.d fails, if you forget to run update-rc.d BEFORE initscriptquery in the package scripts, or if the user removed the /etc/init.d/ script. Desired behaviour: Do whatever is appropriate for your package. Unless -q was given, initscriptquery will have already printed a warning to stderr. The calling script might want to try to start the script anyway (which will probably fail, BTW). 3 - initscript ID known, but behaviour is undefined sysvinit meaning: No S?? or K?? link in the proper rc?.d directory for the given initscript ID was found, but a /etc/init.d/ file for the given initscript iD does exist. Desired behaviour: For non-daemon-starting initscripts, it is undefined. Do whatever is *safer* for your package (start it anyway, do nothing, or stop it). Never start a daemon which isn't already running if you receive this status code. You can either restart the daemon, stop the daemon, or do nothing. WARNING: don't use /etc/init.d/initscript restart for this operation unless the initscript is under your control, and known not to start a daemon which was not running. 4 - Syntax error
Re: RFC: fix for daemon start (2)
On Wed, 13 Sep 2000, Florian Lohoff wrote: I would like to have an addition to the initscriptquery which is something i have been waiting for long. I am interested in this because i am doing automated installations into a chroot environment. In this case i am possibly running in the right runlevel but i still dont want to have Daemons to be startet. So i would like to have a possibility to override the initscriptquery decision or more or less set an env var saying DPKG_NOSTARTDAEMONS=1 or something like this. This issue falls under the soon-to-be-posted-to-debian-devel RFC for local administrative control of initscript starts. It allows you to do the above, yes. It's just that I didn't write the code yet, and I *know* the issue can start a flame war if I don't use severe helpings of flame-retardants like posting the code up front (so that people can actually look at it, and notice it will not do any weird crap to their systems, especially if they DON'T want such administrative control in their machine). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpyZQg3NlSmP.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Mon, 11 Sep 2000, Herbert Xu wrote: On Sun, Sep 10, 2000 at 09:19:10AM -0300, Henrique M Holschuh wrote: On Sun, 10 Sep 2000, Herbert Xu wrote: Which is why it should only be killed in prerm/preinst. Which makes all the supposed simple restart solution for the runlevel problem fail in _all_ cases. Thank you for reminding me of the prerm issue, nearly all daemon-providing packages stop the daemon in prerm. All of these packages would have to stop doing this (at least on upgrades) for a restart solution to the runlevel problem to work. Huh? If what you want is an only start this in runlevel X,Y,Z, then this certainly can be done with stopping the daemon in prerm, and restarting it in postinst if we're in the correct runlevel. Hmm, we have a communications breakdown here :-) What I mean is: 1. using a initscriptquery-type strategy, you CAN safely stop the daemon wherever you whish, including in prerm. The daemon will be started again (which I don't call restarted :-) -- I reserve that for stop a running daemon and start it again immediactly) if you're in the correct runlevel. and 2. If you're going to use 'pidof'/ps/grep-style strategies to detect if you're in the current runlevel, it won't work correctly always. Also, it will fail if you stop the daemon in the prerm (and in other circunstances as well). Therefore, 3. initscriptquery-type strategies are better, as they allow you to keep stopping your daemons in prerm. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgp2EkW8872iq.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sun, 10 Sep 2000, Ingo Saitz wrote: On Sun, Sep 10, 2000 at 09:19:10AM -0300, Henrique M Holschuh wrote: BTW, on an unrelated note, a ps | grep solution *MUST* deal with the following possible scenarios, [...] 3. Multiple instances of daemon (and you want to kill only the one you started -- never seen anyone need this, though, as daemons like apache have better ways to detect the right daemon to kill... so _maybe_ this special case can be ignored) No, please don't! Ssh makes use of it by starting on sshd daemon, which listens on port 22 and forks another instance for each incoming connection. If you would kill all sshd processes you immediatly loose your existing ssh connection, which is bad, if you start the upgrade remote via ssh. Must deal with doesn't mean do it always. It means can be told to do it in such a way :-) Besides, 2. and 3. are mutually exclusive anyway, you will need a command line switch or something else to select which kind of behaviour you need. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpthuba2HboY.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sat, 09 Sep 2000, Robert D. Hilliard wrote: daemon is running, and only restart it if it found it was running? Because if the user removes but not purges a package, all the configuration data related to initscripts is kept. The daemon is not running, but the runlevel restrictions must still be upheld (and stop-start-daemon cannot and should not have to know about this). I hope you agree that such a partial fix is undesirable when a complete one is available. There would only be a problem in the rare case in which the sysadm had set up a daemon to run only in some run levels, then removed the package containing the daemon, then reinstalled it and expected it to resume its former behavior. I think it is unreasonable Yes. My point exactly: It doesn't work for all cases, and it's no simpler than the complete fix. You have to take into account that you cannot stop daemons in your preinst anymore for the restart trick to work, and now you need to always differentiate upgrades from installs in your postinst. It requires far more extensive changes to the packages than adding the call to a initscriptquery script. More trouble for less results IMHO. to make the packaging system system jump through hoops to save the sysadm from fixing it manually in this rare case. The packaging system doesn't go through any more hoops than what's expected of it: to obey the runlevels (if you tell me it is not expected to obey the runlevels, I'll ask you why and where is it documented, and where's the polite warning it should issue. I clearly told the system not to start that daemon in that runlevel). The added complexity on the average packager is to copy-and-paste a small, easily understood, easy to debug script. Someone went to a lot of trouble to set up the update-rc.d system. Thanks to that, Debian's init script system is quite enjoyable to set up, and keep control of. It doesn't try to do things behind your back. It doesn't change your settings without warning. IMHO we should finish the job update-rc.d started, and close -completely- the last hole in the whole scheme. There is no *need* to let the packaging system start daemons behind your back. Also, although I didn't want even to broach the subject yet, a initscriptquery-type solution allows for easy deployment of a _completely optional_ (as in install an optional package implementing the stuff if you want it) local policy to control the starting of daemons. I know some people want this, I've read at least one request for it. And it would be completely transparent to the packaging system (it's a small change done to the initscriptquery script) and to the packages themselves. I fear that detecting when a daemon is running in a generic way is not always easy (I'll only know when I try to do it). Creating a generic check-daemon-state script so as to make it easier for our initscripts to conform to the LSB requirements of a status command is still in my todo list, but at a rather low priority. ps ax|grep daemon-name|grep -v grep works for me. It won't work for all cases. Actually, it's extremely easy to break. I know someone will post a far better regexpr sooner or later on this thread, though... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpZBjTVu5bb1.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sun, 10 Sep 2000, Herbert Xu wrote: Brendan O'Dea [EMAIL PROTECTED] wrote: This unfortunately doesn't work if you are trying to kill the previous version of a daemon in the postinst of a package, as the binary will have changed. Which is why it should only be killed in prerm/preinst. Which makes all the supposed simple restart solution for the runlevel problem fail in _all_ cases. Thank you for reminding me of the prerm issue, nearly all daemon-providing packages stop the daemon in prerm. All of these packages would have to stop doing this (at least on upgrades) for a restart solution to the runlevel problem to work. BTW, on an unrelated note, a ps | grep solution *MUST* deal with the following possible scenarios, and have ZERO error rate (otherwise you'll be sending SIGTERM/SIGKILL to the wrong process, as root. This is simply unacceptable): 1. Swapped out daemons 2. Multiple instances of daemon (and you want to kill all, not just the first one -- this is common) 3. Multiple instances of daemon (and you want to kill only the one you started -- never seen anyone need this, though, as daemons like apache have better ways to detect the right daemon to kill... so _maybe_ this special case can be ignored) 4. Other processes in the ps listing which contains daemon as a substring, e.g.: a vi /etc/daemon, or a daemon substring in another program name or parameter. I haven't read the pidof code, but I will assume it can handle all of the above. If it doesn't, pidof needs to be fixed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpkjSBvLz0UI.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sun, 10 Sep 2000, Colin Watson wrote: [EMAIL PROTECTED] (Henrique M. Holschuh) wrote: ISSUE: Is there a need for pre-depends? A package which needs a future version of the initsciptquery interface would need to pre-depends: sysvinit (=someversion) | filerc (=someversion). How is this done for update-rc.d ? If you're using initscriptquery in your postinst (as more or less anyone who uses it will be?) then you only need an ordinary dependency. If you say so. I'm not that familiar with dpkg, and I was afraid a simple depends: would not insure the initscripquery-providing versions of sysvinit and file-rc would have been installed AND configured before the postinst for the packcage is called during a massive install run... so I asked about pre-depends. :-) I don't know if this comes under the administrative reasons which you asked us to ignore for now :), but recently I was upgrading my work box [...] With initscriptquery as it stands, I would at least have a common hook which I could hack to stop any of them being started; I could perhaps have pretended I was in runlevel 1 or something. I don't doubt you'll provide a cleaner solution in your local policy RFC, but I would certainly like to see the current system implemented for woody. That would be RCS branch 1.3.0.x of the script ;-) I have two possible solutions, and both are clean and quite safe (and they also do not change the behaviour of the system one iota by default, so people who think they're useless don't have a reason to oppose them. They wouldn't even be installed in their system). 1. Call a standard script in initscriptquery IF it is installed (if [ -x...), and only return a exit status code of 1 (start daemon) if this script allows it. This is the same way the cron and anacron packages deal with each other, and it's IMHO better than solution 2 below. I have code implementing the hook for this, but it's trivial to add anyway. Packages that want to implement these local policy controls, simply provide this script. A trivial version of the local policy script only needs a /etc/ config file for it to grep for initscript ID. 2. Use dpkg-divert to install your own particular version of initscriptquery and plug the administrative stuff in there. This requires a sysvinit and file-rc versions of the new script. On the other hand, the only way to forbid this solution to be applied is by policy. It has zero-impact, zero traces in a system it's not installed. So as not to bug the maintainers even more, the local admin script is not able to differentiate installs of upgrades, BTW. This CAN be fixed, but it would require all calls to initscriptquery to differentiate between the two, and that would be not very nice to ask of everybody. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpoWbdCsumqp.pgp Description: PGP signature
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sun, 10 Sep 2000, Henrique M Holschuh wrote: -x...), and only return a exit status code of 1 (start daemon) if this That should be exit status code 0, of course. Oh well... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpUIQTZ5cjqk.pgp Description: PGP signature
RFC: fix for daemon start on package install/upgrade out-of-runlevel
Hello debs,
This is a request for comments (and enhancements ;-) ) for a possible
solution to an annoying bug (for those it hits) we currently have: daemons
are started during package installs/upgrades regardless of the current
runlevel.
This behaviour can be fixed, and the fix is not overly complex. In this RFC,
I propose a solution including example code. However, the complete solution
requires policy that mandates the fix to be applied to all affected
packages.
I humbly request your input on this issue, and suggest a fix for this
problem (not necessarily the fix outlined in this RFC) to be considered a
goal for woody.
THE PROBLEM: During (non-first) installs and upgrades, init scripts are run
regardless of the current runlevel. Debian tries to respect the local
administrator's wishes through the update-rc.d script, but falls short when
it comes to start daemons only at the correct runlevels.
EXAMPLE: User sets up his runlevels 2 and 3 so as not to start the nfs
server in runlevel 2, and to start it in runlevel 3. The system is set to
runlevel 2, the nfs daemon isn't running. The user runs apt-get
dist-upgrade, and a new version of the nfs server is installed. The postinst
script starts the nfs server daemon, even though the current runlevel
clearly prohibits this. (BTW: this is an example, I didn't check if the nfs
server package has some sort of unusual postinst which does not start the
server if it's not runing on upgrades).
THE PROPOSED SOLUTION: A new program (/usr/sbin/initscriptquery) will be
provided by the sysvinit (base) and file-rc (optional) packages. This
program will be used by all packages which provide an init script (with the
possible exception of rcS.d scripts, see the Issues section) to verify if
they are supposed to run an init script in the current runlevel or not
(during both installs and upgrades).
The proposed /usr/sbin/initscriptquery script:
--
Assumptions:
Debian uses only sysvinit-compatible init scripts, stored in /etc/init.d/
(currently true for debian, file-rc uses the same /etc/init.d/ scripts as
sysvinit does).
The unique identifier for an init script is the init script ID required by
the update-rc.d command.
Design goals:
1. Downgrade to the current (but broken) behaviour if the fix is not fully
available in the host system.
2. Default behaviour should match the current one for Debian as well as
possible, with the exception that daemons are NOT started out of their
intended runlevels.
Documented Command Line Interface:
/usr/sbin/initscriptquery [-q] init script ID
-q : Run initscriptquery in silent mode, errors are NOT reported to stderr
init script ID: the update-rd.d identifier for the init script
Future versions to this script MUST be fully backwards compatible.
Documented behaviour of the initscriptquery script:
stdin shall not be used (it is NOT an interactive script)
stdout shall be used only to output usage information.
stderr shall be used to output all error messages.
Exit status codes:
0 - the init script is allowed to be started
1 - the init script is NOT allowed be started
2 - init script ID unknown
3 - init script ID known, but behaviour is undefined
4 - syntax error
=5 - other error (usually means inconsistency in the underlining
init script subsystem)
Verbose description of the exit status codes:
0 - the init script is allowed to be started
sysvinit meaning: There is a non-dangling, executable S?? link in
the rc?.d directory for the given script ID and current runlevel.
Also, no other administrative reasons for not starting the init
scripts exist. {currently not implemented, a separate RFC will
address this, ignore it for now *please*}
Desired behaviour: Call /etc/init.d/initscript as you'd have done
before the advent of initscriptquery
1 - the init script is NOT allowed be started
sysvinit meaning: There is a non-dangling, executable K?? link (and
no S?? link) in the rc?.d directory for the given script ID and
current runlevel.
Or, an administrative reason prohibits starting the init script.
{currently not implemented, a separate RFC will address this, ignore
it for now *please*}
Desired behaviour: Do not run the init script. If the daemon is
running, assume it's because the user started it manually and would
like it to be left alone (feel free to issue a warning, though).
2 - init script ID unknown
sysvinit meaning: There isn't a normal file with the name matching
init script ID in /etc/init.d/ (note that the existence of a
S??initscriptID link/file is NOT enough, as we are constrained to
the same namespace used by update-rc.d).
This might happen if update-rc.d fails, if you forget to run
update-rc.d BEFORE
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Thu, 07 Sep 2000, Craig Sanders wrote: On Mon, Sep 04, 2000 at 10:28:20AM -0300, Henrique M Holschuh wrote: I was going to tack this sooner or later (the trust us, we KNOW you want the daemons to start always current state of almost all daemon packages annoys me to no end, and from past flamewars I know I'm not the only one), I think I even warned a few newbies in -user two days ago about this :-) it is a reasonable assumption to make - if someone installs a package Yes, it is. But it is just that: an assumption. That's all we can do right now for package installs, and it CAN be argued that it's all we should ever do in package installs. My current issue is with package upgrades. So, please, let's not even get into the 'start daemons at package install' issue right now. Let me tack the upgrade problem first, and when that's done and ready (please note I didn't say accepted), we can move to the install problem and we can argue all you want about it. Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. If you call the script which addresses the upgrade issue during installs as well, it won't malfunction (this is a design requirement), and you can share the same code for upgrades and installs. It *could* be used to avoid starting a daemon during installs if extended to do so, but it doesn't _have_ to. The solution is to *force* all daemon packages to never start a daemon out of its intended runlevel, be it during first install or upgrades (I think this probably requires a policy change). I'd even say this should be a goal for woody, unless we're going to try to get woody out of the door very fast. this sounds bloody annoying. If everyone had to write a lot of complicated code to get this to work, I'd agree with you. As it stands, I'm writing all the code needed for sysvinit, and I could even try to do the same for file-rc after the sysvinit code is ready, tested, published to -devel and ripped to shreds. A *design* goal in this stuff is that: If you do nothing to the defaults, the system will act just like it does today. In *all* cases, even the highly unlikely ones such as no init system at all being installed. You as a maintainer will have to add something that boils down to: ... update-rc.d foo bar foobar barfoo +if canIstartTheDaemonPlease daemonname; then + /etc/init.d/daemoname start +fi ... After all error checking is stripped off. if you don't want a service to start, then don't install the package. simple, really. As I said, let's leave that issue alone for now, please. [...] no package manager can read your mind. you're still going to have to do It doesn't need to, I consider the start on upgrade as it stands a bug because the system can detect what it should do, unless I am overlooking something... which is why I'm trying to get the code done and working before posting anything else to -devel. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpT619SC1RjZ.pgp Description: PGP signature
Re: Debian, daemons and runlevels (was: Re: X and runlevels)
On Wed, 06 Sep 2000, Henrique M Holschuh wrote: Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. Damn, I should have said Starting a daemon in a upgrade while the system... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpixNxrN6eTz.pgp Description: PGP signature
Re: debhelper or fakeroot problem?
On Wed, 06 Sep 2000, Atsuhito Kohda wrote: dpkg-shlibdeps: warning: unable to find dependency information for shared library /usr/lib/libfakeroot/libfakeroot (soname 0, path /usr/lib/libfakeroot/libfakeroot.so.0, dependency field Depends) [...] What is the problem and is there anyone who encountered the same problem? It happens here everytime as well, but I simply ignore it, as no bogus information (dependency) on libfakeroot is being inserted anyway. I don't know if there's a way to shut dpkg-shlibdeps up AND cause it to still NOT include any bogus dependencys on libfakeroot. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpPRGTDFSXdA.pgp Description: PGP signature
Re: X and runlevels
On Mon, 04 Sep 2000, Branden Robinson wrote: On Mon, Sep 04, 2000 at 10:32:07AM +0200, Per Lundberg wrote: How come Debian don't have a non-X runlevel, like some other distributions, in the default configuration? I think this would be pretty convenient. Because no one has ever bothered to write a runlevel policy. Well, we might end up inheriting the one from LSB if Debian decides to try to follow as much as possible of it, but it's not like we need to get concerned with implementing it yet. What we must ensure is that Debian will work right with whatever runlevel scheme the local administrator comes up with and sets the system up with. After this is done, implementing whatever runlevel policy we want is a simple matter of a mass change of the update-rc.d invocations in a great deal of packages ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpL68Tmp4HFg.pgp Description: PGP signature
Debian, daemons and runlevels (was: Re: X and runlevels)
On Mon, 04 Sep 2000, Paul Slootman wrote: On Mon 04 Sep 2000, Ethan Benson wrote: It's unfortunate that there's no easy way to find the current runlevel (the usual who -r from Solaris etc. doesn't work), otherwise this piece of code could be used: RL=`who -r` if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then /etc/rc$RC.d/S??$PKGNAME start fi That's ignoring file-rc, unfortunately. Is there an easy way of determining whether a certain init.d script should be started in the current runlevel that works also with file-rc ? I was going to tack this sooner or later (the trust us, we KNOW you want the daemons to start always current state of almost all daemon packages annoys me to no end, and from past flamewars I know I'm not the only one), I think I even warned a few newbies in -user two days ago about this :-) The solution is to *force* all daemon packages to never start a daemon out of its intended runlevel, be it during first install or upgrades (I think this probably requires a policy change). I'd even say this should be a goal for woody, unless we're going to try to get woody out of the door very fast. This would be managed through a simple (for sysvinit. I don't believe it'd be very complex for file-rc either, but I didn't check), standard script/program added to the sysvinit and file-rc packages (and any other future packages of the same sort) which allows a script to query if a certain init.d script should be started [in the current runlevel]. This assumes that the name of a daemon's init.d file is the generic ID for that daemon, but this is the current policy for Debian anyway (it's what you feed to update-rc.d). I should check if the LSB tries to do something like this in a non-braindamaged way, too... just in case. This could (IMHO should, but lets not go there) be expanded later to allow the administrator a bit more control over daemons being started on first install (before he reviewed config files, for example). As long as update-rc.d is called before running this script during package installs and upgrades, it would setup the default runlevels the daemon is supposed to run on. There would be no changes in behaviour of a standard debian install. Any comments? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgp2EXPfRW4Wu.pgp Description: PGP signature
Re: xpdf-i obseleted by xpdf
On Sun, 20 Aug 2000, Hamish Moffatt wrote: xpdf already conflicts and replaces xpdf-i. Am I correct in saying that there's no way I can cause an automatic upgrade from xpdf-i to xpdf? Hmm... I'll take the oportunity to ask an old doubt of mine: Will it work if xpdf-i is made an empty package which depends on xpdf, and its description is changed so as to explain the user that she should purge xpdf-i ? (xpdf still conflicts with xpdf-i). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgp15ks3douR4.pgp Description: PGP signature
Re: RBL report..
On Sun, 26 Mar 2000, Joseph Carter wrote: On Sun, Mar 26, 2000 at 04:00:54PM +0200, Nils Jeppe wrote: Given every report I've heard to the contrary, I'm not sure I believe that. I've also been told that there are cases where their tests produce false positives. This used to be true. The new tests won't false-positive anymore. I don't see how you can create a false positive on a relay test. Either the message gets through, and you're an open relay, or it doesn't, and you're fine. It's quite simple, really. Or it appears to have been accepted and goes nowhere. I've seen a setup or two like this specifically for the purposes of tracking who was trying to use the relay... The failure in a test is now triggered (AFAIK) by the _receipt_ of the probe message in the _target_ address. This allows for no false-positives by the test suite. ORBS is the only thing which is capable of keeping the spam low enough to be acceptable in my home account :-( It doesn't help that spammers have haversted the debian BTS (either the WWW pages or the ML, I don't know) for addresses to spam, either. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Proposed documentation/script changes for potato (ntp/chrony/util-linux)
On Tue, 21 Mar 2000, [EMAIL PROTECTED] wrote: On Mon, Jan 31, 2000 at 01:56:54AM -0200, Henrique M Holschuh wrote: I don't read debian-devel frequently, so I just caught up on all this discussion, however I did file one of the bugs about this. Thank you for taking on this issue! I have one problem: Someone still needs to get the hands dirty and do some coding for it to be effective, though. To set the date/time of the system, just use the standard UNIX date facilities (such as date) This advice ignores the admonitions I've read in many places that one should never adjust the system clock discontinuously, especially not backwards. Do you have any thoughts on this? Setting the clock backwards is always a pain (it screws up log timestamps, for one), wether you do it continuously or not. I really wish all logging was done in UTC, at least the timestamps wouldn't repeat themselves when leaving daylight savings time. As for stepping the clock forward, I've seen it cause all sort of weirdness (e.g.: activating X screensavers :-) ), however I've never seen any really hazardous effects (e.g.: hardware failures), at least not in Linux. My system does clock stepping every boot (ntpdate -b), and ntp actually causes the clock to step sometimes when the syncronization is lost. So far, nothing complained too loudly about it... The truth is that we have to choose between the lesser of two evils, and stepping the clock seems to be the lesser one here (as opposed to completely hosing the system time because the user doesn't know how to deal with the two clocks and /etc/init.d/hwclock.sh during shutdown). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
