Re: possible bug in gettext (autotools?) or in some packages

2001-05-03 Thread Henrique M Holschuh
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

Re: debbugs can now send bug mails to someone different than the maintainer

2001-05-01 Thread Henrique M Holschuh
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

Re: debbugs can now send bug mails to someone different than the maintainer

2001-04-30 Thread Henrique M Holschuh
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

Re: RFC: English translation list

2001-04-29 Thread Henrique M Holschuh
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

Re: ITP: tads

2001-01-09 Thread Henrique M Holschuh
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

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

2001-01-06 Thread Henrique M Holschuh
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

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

2001-01-06 Thread Henrique M Holschuh
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

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

2001-01-06 Thread Henrique M Holschuh
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

Re: Linux Progress Patch for Debian available!

2000-12-31 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start (2)

2000-09-14 Thread Henrique M Holschuh
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

RFC: fix for daemon start (2)

2000-09-13 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start (2)

2000-09-13 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-11 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-11 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-10 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-10 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-10 Thread Henrique M Holschuh
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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-10 Thread Henrique M Holschuh
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

RFC: fix for daemon start on package install/upgrade out-of-runlevel

2000-09-09 Thread Henrique M. Holschuh
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

Re: Debian, daemons and runlevels (was: Re: X and runlevels)

2000-09-07 Thread Henrique M Holschuh
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

Re: Debian, daemons and runlevels (was: Re: X and runlevels)

2000-09-07 Thread Henrique M Holschuh
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

Re: debhelper or fakeroot problem?

2000-09-06 Thread Henrique M Holschuh
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

Re: X and runlevels

2000-09-05 Thread Henrique M Holschuh
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

Debian, daemons and runlevels (was: Re: X and runlevels)

2000-09-04 Thread Henrique M Holschuh
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

Re: xpdf-i obseleted by xpdf

2000-08-20 Thread Henrique M Holschuh
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

Re: RBL report..

2000-03-26 Thread Henrique M Holschuh
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.

Re: Proposed documentation/script changes for potato (ntp/chrony/util-linux)

2000-03-22 Thread Henrique M Holschuh
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