On Wed, 28 Mar 2007, Manoj Srivastava wrote:
On Wed, 28 Mar 2007 12:52:33 -0300, Henrique de Moraes Holschuh
[EMAIL PROTECTED] said:
You do not handle signing subkeys?
What makes you think that? Any key that is used needs to be
in the debian keyring, is all.
I just checked
Hi John!
On Mon, 26 Mar 2007, John Goerzen wrote:
On Mon, Mar 26, 2007 at 08:28:02PM +0200, Bastian Blank wrote:
On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote:
Sure, but hotpluggable PCI(e) interfaces are the exception, not the
norm. It seems wrong to optimize for this
On Thu, 01 Mar 2007, Nikita V. Youshchenko wrote:
Sorry Marco, but it is not valid to close a bug report that describes an
existing issue only because you don't like the solution suggested by the
submitter.
Agreed, actually. But this is bigger than udev, it probably belongs in
general, and
On Fri, 02 Mar 2007, Nikita V. Youshchenko wrote:
The issue I'm talking about (lots of error messages while udev init.d
script is running) happens in the current sequential boot procedure.
Udev runs at early userspace.
It is caused by udev trying to resolve groups such as fuse, that (a) are
On Mon, 12 Feb 2007, Steffen Moeller wrote:
While at the moment that I have just passed TasksSkills II, I consider this
to be possible but rather unlikely szenario. However, I presume that in about
20-30 years from now when I got older this may well be true. What do we have
then - quantum
On Sun, 11 Feb 2007, Mike Hommey wrote:
A probable reason is that the NM process is getting tougher and/or that
some developpers didn't even pass an NM process...
Then we are better off without them. I can understandy anyone trying to
avoid NM in the grounds that it is a hassle (as in they'd
On Sun, 11 Feb 2007, Yves-Alexis Perez wrote:
On dim, 2007-02-11 at 15:35 -0600, Manoj Srivastava wrote:
an active DD should
not be afraid of passing something we ask of every new developer?
On dim, 2007-02-11 at 22:49 +0100, Mike Hommey wrote:
A probable reason is that the NM process is
On Fri, 09 Feb 2007, David Härdeman wrote:
On Thu, Feb 08, 2007, David Härdeman wrote:
dmsetup / cryptsetup both fail to create a mapping on top of a raid
device (/dev/md0 in this case).
I don't know where the error lies, but I created two loop devices loop0
and loop1, added them to
On Mon, 05 Feb 2007, Loïc Minier wrote:
Yes, but it would need to be of low priority and the default would need
to be to add the entries in nsswitch.conf. I think it would be more
I think I'd rather have it medium or high, with a default to *disabled*.
Yes, the normal would be Low, but I do
On Sat, 03 Feb 2007, Russell Coker wrote:
One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you
have
You need to enable PAE (64GB support) to access the NX bit on ia32, which is
even worse, and that's the reason why my 1GB laptop has a PAE kernel :(
Another is the fact
On Sun, 04 Feb 2007, Russell Coker wrote:
On Sunday 04 February 2007 01:20, Henrique de Moraes Holschuh [EMAIL
PROTECTED]
wrote:
On Sat, 03 Feb 2007, Russell Coker wrote:
One that springs to mind is CONFIG_HIGHMEM4G, it seems only useful if you
have
You need to enable PAE (64GB
On Mon, 01 Jan 2007, Josselin Mouette wrote:
Ledger is an accounting tool with the moxie to exist. It provides no
bells or whistles, and returns the user to the days before user
interfaces were even a twinkling in their father's CRT. What it does
offer is a double-entry accounting ledger
On Thu, 21 Dec 2006, Thomas Bushnell BSG wrote:
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote:
To conclude, the support of multiple python versions is not meant at
all as an excuse for lazy debian maintainers depending on python for
not following upstream python development.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 18 Dec 2006 10:27:31 -0200
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 1.6.10-3
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 403551
Changes:
amavisd-new (1:2.4.2-6) unstable; urgency=high
.
* [l10n] Add pt_BR
On Fri, 08 Dec 2006, Daniel Baumann wrote:
You can find the packages at
http://debian.die-welt.net/pool/main/tp-smapi/ - I would love to see
much feedback, because this is my first real packaging attemt (but
neither lintian nor linda do complain).
If you're looking for a sponsor, I can
On Mon, 27 Nov 2006, Andreas Fester wrote:
I experienced the same some time ago and worked it around
by temporarily switching to a different mirror. It then succeeded,
and afterwards I could again switch to my usual mirror.
But, yesterday I had the same issue in my i386 chroot, so the issue
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 398978
Changes:
amavisd-new (1:2.4.2-5) unstable; urgency=high
.
* Update Brian May's
On Sat, 18 Nov 2006, Loïc Minier wrote:
xfsprogs-2.8.16 (30 October 2006)
- Fix up an endian problem for nlink setting in phase 7 for xfs_repair.
Likely a grave bug on some archs.
xfsprogs-2.8.15 (19 October 2006)
- Fix up nlink checks and repairs in phase 7 for xfs_repair.
On Sun, 12 Nov 2006, Julian Gilbey wrote:
http://bugs.debian.org/397925). So the only thing within my ability
is to change the devscripts bts command so that it behaves in the way
it used to before the BTS change.
Could you make it configurable? I like the show unstable bugs behaviour
far
On Thu, 09 Nov 2006, Michael Biebl wrote:
If this two is true (and I think so) then you couldn't install the old
ssh package and the new one. So how can you do this?
If the new package has a Replaces: old_package, it will *take over*
the conflicting config_files from the old package [1].
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 395456 396348 397456 397502 397503
Changes:
amavisd-new (1:2.4.2-4) unstable; urgency=high
On Thu, 02 Nov 2006, Goswin von Brederlow wrote:
Steinar H. Gunderson [EMAIL PROTECTED] writes:
It has recently come to my attention that nfs-utils (which is priority
standard) cannot depend on ucf, since ucf is of priority optional.
I can only see four solutions for this:
a) Ignore
On Tue, 31 Oct 2006, Alex Pennace wrote:
I'm surprised your report missed one of the most established
configuration symlinks of them all: /etc/localtime. I'm pointing that
out in particular because it has been around for as long as I can
remember, and serves its configuration function by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 28 Oct 2006 09:14:09 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 1.6.10-2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh
Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
hpijs - HP Linux Printing and Imaging - gs IJS driver (hpijs)
hpijs-ppds - HP Linux Printing and Imaging - HPIJS PPD files
hplip - HP Linux Printing and Imaging System (HPLIP)
hplip-data - HP
: 2.1.18-5
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
cyrus21-admin - Cyrus mail system (administration tool)
cyrus21-clients - Cyrus mail system (test clients)
cyrus21
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 392852
Changes:
amavisd-new (1:2.4.2-3) unstable; urgency=high
.
* Work around adduser
On Thu, 12 Oct 2006, Jurij Smakov wrote:
It was pointed out to me, that even the scripts starting with S are
called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc.
However, the reason why it is implemented that way is still not clear.
Braindamage inherited from SysV.
--
One
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 16 Jun 2006 14:34:43 -0300
Source: fcron
Binary: fcron
Architecture: source i386
Version: 3.0.1-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 12 Oct 2006 09:51:21 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20060920.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 386366 389871 390391
Changes:
amavisd-new (1:2.4.2-2) unstable; urgency=medium
On Tue, 10 Oct 2006, Reinhard Tartler wrote:
/var/{run,lock} could be mounted as tmpfs in early userspace. Other
distributions are already doing this, and a few weeks ago, there was
discussion about doing this in debian as well.
For various reasons, Debian will go with /lib/init/rw as the
On Mon, 09 Oct 2006, Gabor Gombas wrote:
On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote:
No wrappers for the single most critical binary in a Unix system after the
libc. Sorry.
Right. How about upstart not providing a /sbin/init binary at all, but
instead
On Mon, 09 Oct 2006, Oleksandr Moskalenko wrote:
According to the chapter 3.3 of the Dev. reference the GR calls for votes
should've been sent to the debian-devel-announce, but in reality they weren't.
They *were* sent to the d-d-a mailinglist, check the archives.
--
One disk to rule them
On Sun, 08 Oct 2006, Hendrik Sattler wrote:
I propose another solution. Introduce init-common with wrappers:
No wrappers for the single most critical binary in a Unix system after the
libc. Sorry.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the
: 2.1.18-4
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
cyrus21-admin - Cyrus mail system (administration tool)
cyrus21-clients - Cyrus mail system (test clients)
cyrus21
On Sun, 17 Sep 2006, Mario 'BitKoenig' Holbe wrote:
cons, and issues and difficulties... would it probably make sense to
split the discussion about /var/x being able to be tmpfs'ed out and just
choose another location for the intended place-to-store-things-while-
nothing-else-is-mounted-rw?
On Wed, 13 Sep 2006, Peter Samuelson wrote:
That raises a philosophical question:
If a bug was in a prerm script in unstable for 7 days, but never
appeared in stable or testing, should we include cruft in present and
future prerm versions to work around it?
Or, put another way: a prerm is
On Tue, 05 Sep 2006, martin f krafft wrote:
Here is the list of packages that depend on sysvinit. For packages
marked with (*), I already have the maintainers' consent.
sysv-rc-conf
This one needs to depend on sysv-like link farm functionality (as opposed
to, say, file-rc style). If
On Tue, 05 Sep 2006, Mark Brown wrote:
invoke-rc.d. IIRC doing something more obvious caused upgrade issues at
the time due to issues with having both sysv-rc and file-rc.
invoke-rc.d was added to sysv-rc and file-rc at almost the same time, we
didn't botch THAT transition at all, thank you
On Tue, 05 Sep 2006, Henrique de Moraes Holschuh wrote:
system since stable. Any initscript package that does not provide
invoke-rc.d (and doesn't piggyback on the one from sysvinit or file-rc) has
I do mean init script subsystem package, of course. Not regular packages
that have initscripts
On Tue, 05 Sep 2006, Mark Brown wrote:
On Tue, Sep 05, 2006 at 10:28:43AM -0300, Henrique de Moraes Holschuh wrote:
On Tue, 05 Sep 2006, Mark Brown wrote:
invoke-rc.d. IIRC doing something more obvious caused upgrade issues at
the time due to issues with having both sysv-rc and file-rc
On Tue, 05 Sep 2006, martin f krafft wrote:
also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2006.09.05.1526
+0200]:
This one needs to depend on sysv-like link farm functionality (as
opposed to, say, file-rc style). If upstart provides symlinks,
then we need a virtual package
On Tue, 05 Sep 2006, martin f krafft wrote:
also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2006.09.05.1614
+0200]:
invoke-rc.d is a maintainer script compatibility layer to
interface to the initscript subsystem (that happens to guarantee
some functionality that some initscript
de Moraes Holschuh [EMAIL PROTECTED]
Description:
openmsx- the MSX emulator that aims for perfection
openmsx-data - datafiles for openMSX, an MSX emulator
Changes:
openmsx (0.6.1-3.1) unstable; urgency=low
.
* NMU
* Upload with maintainer field fixed to Joost's name. Damn pbuilder
On Tue, 15 Aug 2006, Stuart Anderson wrote:
This is actually a common setup when using amavis-ng, spamassasin and
And also the *recommended* setup for amavisd-new. But don't confuse two MTA
*paths* with two MTAs. A single MTA can handle the pre-filter and
post-filter paths just fine, if it is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 15 Aug 2006 00:35:27 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 1.6.7-2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 10 Aug 2006 12:13:13 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20060702.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 10 Aug 2006 12:40:29 -0300
Source: freepats
Binary: freepats
Architecture: source all
Version: 20060219-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 373136 373159 373206 376465 381243
Changes:
amavisd-new (1:2.4.2-1) unstable; urgency=low
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 9 Aug 2006 12:01:45 -0300
Source: xpp
Binary: xpp
Architecture: source i386
Version: 1.5-5
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes Holschuh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 9 Aug 2006 12:37:44 -0300
Source: xpp
Binary: xpp
Architecture: source i386
Version: 1.5-cvs20050828-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique de Moraes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 9 Aug 2006 14:26:00 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 1.6.7-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh
On Tue, 01 Aug 2006, John Goerzen wrote:
Darcs has a nice way of pushing patches via e-mail, with GPG signatures
even. These can be processed in an automated way on the server,
verified against, for instance, the Debian keyring, and then applied to
the repository.
Which would also be a far
On Fri, 28 Jul 2006, Josselin Mouette wrote:
Debian is a volunteer organisation. No one here is willing to implement
all stupid ideas we receive, and believe me, we receive a lot of them.
Some of us are not willing to do anything, even when the ideas are not
stupid. And they are a problem for
On Fri, 28 Jul 2006, Steve Kemp wrote:
Neither Ubuntu nor Debian do anything special to get hardware support
that is provided by the kernel proper and tools that neither group
created.
AFAIK Ubuntu has a far less conservative approach to kernel patching than
Debian. So yes, they might
On Fri, 28 Jul 2006, martin f krafft wrote:
also sprach Matthew Garrett [EMAIL PROTECTED] [2006.07.28.1737 +0100]:
If Debian had slightly less of a culture of Keep your hands off
my package, I'd do it here instead.
I've been thinking about this a lot for the past week.
Is there any way
On Tue, 11 Jul 2006, Thomas Bushnell BSG wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
I don't think I understand just what you're saying. Can you spell out
the details for me?
Does the second email I sent (with the missing stuff) provides the
clarification you asked for?
It distresses me that I have said twice now that a
On Mon, 10 Jul 2006, Adrian von Bidder wrote:
On Monday 10 July 2006 02:17, Matthew R. Dempsky wrote:
On Sun, Jul 09, 2006 at 05:02:39PM -0700, Thomas Bushnell BSG wrote:
Another problem is with hosts that do not accept a message from an MTA
unless that MTA is willing to accept replies.
On Mon, 10 Jul 2006, Thomas Bushnell BSG wrote:
martin f krafft [EMAIL PROTECTED] writes:
That's better than not greylisting anyone. Nobody is trying to
design the perfect spam filter. We just want to reduce spam on
debian.org.
A perfect spam filter is one which catches all spam and
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
It assumes, for example, that the remote MTA will use the same IP
address each time it sends the message. If the remote MTA is a big
The earlier *implementations* of greylisting did that, true. They were
simple-minded at best.
server farm, with
On Sun, 09 Jul 2006, Thomas Bushnell BSG wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
You can, for example, use dynamic IP supersets to do the greylisting
triplet match. Now the problem is a matter of creating the supersets in a
way to not break incoming email from outgoing
On Mon, 10 Jul 2006, Henrique de Moraes Holschuh wrote:
Is there a way of doing this which doesn't require you to know in
advance the setup of remote networks and such? Does it scale?
Yes. The most absurd way is to consider every non-stolen, valid for the
public Internet IPv4 netblock
On Mon, 03 Jul 2006, Brian May wrote:
I don't expect such a system to implement virtual hosting without
system administrator intervention, but a naming convention for the files
We must make this intervention easy, but other than that...
that supports virtual hosts would be even better IMHO,
-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Description:
amavisd-new - Interface between MTA and virus scanner/content filters
amavisd-new-milter - Interface between sendmail-milter and amavisd-new
Closes: 367807 372122
Changes:
amavisd-new (1:2.4.1-1) unstable; urgency=low
.
* New upstream
On Wed, 07 Jun 2006, Gordon Grubert wrote:
I have a file server running on Sarge AMD64 connected
with a 1GBit interface to a GBit uplink off the switch.
Do not think that this sounds like a common problem. It isn't!!!
...
The most interesting fact is, that I obtain about 10MB/s with
my
On Wed, 07 Jun 2006, Thomas Bushnell BSG wrote:
I have always thought that when bug X is blocking bug Y, the severity
of bug X should be at least as big as the severity of bug Y.
I have recently been told by a maintainer that my logic in this regard
is faulty. Is it?
Depends on how you are
On Tue, 06 Jun 2006, Mike Hommey wrote:
Could you tell us what kind of harm can do a hidden empty file in /usr ?
It flags alarms, it is obscure, and generally it is bad form to have hidden
files anywhere but under user homes anyway. There certainly is no excuse to
have anything hidden inside
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 12 May 2006 23:40:38 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 0.9.11-2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 11 May 2006 12:56:38 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip hplip-doc hplip-dbg
Architecture: source all i386
Version: 0.9.11-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh
On Sat, 27 May 2006, sean finney wrote:
it also seems like later versions of libtool ( sarge) are able to
work around this problem, but specifying this in the build-depends makes
things a bit harder for backporting to sarge. also, people will continue
Backporting using backported build-time
On Thu, 25 May 2006, Enrico Zini wrote:
This prompts me that we should probably be taking trusted notes of birth
dates and birth places, because it's hard to physically trace one person
down just given his or her name.
At this point, it would be best to have all DDs actually enter into legally
On Fri, 26 May 2006, David Moreno Garza wrote:
That's illegal actually. It is quite often to get your passport sealed
I have no idea about illegal (it might well be against some international
treaty, however), but it is very dangerous for you not to have your passport
stamped. There are very
On Sat, 27 May 2006, Penny Leach wrote:
struck me as a little bit silly. Penny is clearly short for Penelope.
Only if you are reasonably well acquinted with the English language and
usual english names and nicknames.
Perhaps this was my bad when I made the key displayed a lack of foresight.
On Thu, 25 May 2006, Manoj Srivastava wrote:
It has come to my attention that Martin Kraff used an
unofficial, and easily forge-able, identity device at a large key
[...]
Should you not have *signed* a message of this sort? I certainly won't do
anything until I know for sure it came
On Thu, 25 May 2006, Marco d'Itri wrote:
On May 24, Reid Priedhorsky [EMAIL PROTECTED] wrote:
So, does anybody mind if I remove depmod from the module-init-tools init
script?
What would happen to people who don't use the Debian kernel packages? In
make install already runs depmod.
my
On Tue, 23 May 2006, Michael Prokop wrote:
way of life, I'd just like to make sure that removing packages
always works.
If you are going to ignore a failing initscript in order to remove a
package, and that leaves a daemon running, then expect to get a very nasty
bug report...
--
One disk
On Tue, 23 May 2006, Michael Prokop wrote:
Yes, for sure. But IMO it's the initscript which should make sure
that the daemon is stopped when running the stop-rule.
Most try, to the point of doing a kill -9 if the daemon doesn't go away
easily. But if it doesn't die even with a kill -9 (say,
On Tue, 23 May 2006, Russ Allbery wrote:
I'd really rather stick with the upstream name, particularly since this is
Why not ask upstream WHY they are misnaming the library? libxml-security-c++
is a perfectly ok and valid name...
--
One disk to rule them all, One disk to find them. One disk
On Tue, 23 May 2006, Florian Weimer wrote:
I suppose it would be preferable to fix the stop target of the init
There is nothing preferable about it. Stop targets *are* to exit with
status 0 if the service is already stopped.
The fact that Debian policy still has this as a should clause is just
On Tue, 23 May 2006, Francesco P. Lovergine wrote:
Unfortunately sometimes the daemon does not stop for an error in the
maintainer script and that prevents upgrading for ever, even when
the package has been corrected. BTW, it seems a lack in the policy
to specify how the maintainers scripts
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh
On Thu, 18 May 2006, Goswin von Brederlow wrote:
No, you sounded like you wanted to enforce the installation of an MTA
on every system and only support that (since all systems would have
one why bother with anything else?).
Drop the only and change that to by default always, and you will have
On Thu, 18 May 2006, martin f krafft wrote:
Also, what you are saying leads me to believe that you would want me
to document *all* important changes, whether respective Debian bugs
existed or not. NEWS.Debian is clearly a better method for such
Many important changes do not modify the intended
On Thu, 18 May 2006, Florent Bayle wrote:
Why no managing /bin/sh link with update-alternatives ?
Because it is essential.
--
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
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh. Anything
else?
Are you prepared to put your life on the line that the alternatives system
will never, ever leave
On Wed, 17 May 2006, Goswin von Brederlow wrote:
which results in smtphost bugs.debian.org in the conffile. Maybe the
default to the MTA question could be N instead.
An open outgoing port 25 is commonly blocked by default anywhere you have
non-incompetent network management, unless you are on
On Wed, 17 May 2006, Lionel Elie Mamane wrote:
On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote:
An open outgoing port 25 is commonly blocked by default anywhere you
have non-incompetent network management, unless you are on the
business of selling full internet
On Wed, 17 May 2006, Goswin von Brederlow wrote:
You mean connection from random user ports to destination port 25?
Yes.
If you are at a place where that is the case then you should have an
IT team or admin that will tell you what smtp host to use or even
install your system.
We do. So
On Wed, 17 May 2006, Ron Johnson wrote:
It blocks *incoming* port 25 traffic for well understood reasons.
Yes, purely commercial reasons.
I never knew, though that it also blocks all *outgoing* smtp
traffic except to it's own servers. Maybe to Winbots from emailing
files back home?
Yes, to
On Wed, 17 May 2006, martin f krafft wrote:
Mh. I don't want to (re)start a flamewar, but my take is that
changelog.Debian documents changes I've made, and the upstream
changelog documents the changes they've made. I acknowledge these
changes by closing the bugs, and if you care how it got
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote:
The terms arch and os represent the Architecture and Operating System
as defined and provided by config.guess.
Well, config.sub is the one whose function is to provide canonical
names, config.guess might not do so for one reason or another (but it
On Sat, 06 May 2006, Anthony DeRobertis wrote:
older machines) but also with amd64 (which I doubt there are any 64mb
AMD64 systems) and ia64 (which I very much doubt there are any 64mb
Which have BIG caches, and thus might get sensible speedups if -Os manages
to make the entire thing fit inside
On Wed, 03 May 2006, Rogério Brito wrote:
One way to mitigate the memory consumption is to, among other things,
compile packages with optimization of GCC set to -Os, instead of -O2,
What -Os is likely to give you is much better cache locality, which might
make the code run that much faster on
On Wed, 26 Apr 2006, Robert Collins wrote:
Wearing my upstream hat, I'd like to see squid3 packages that *do not*
conflict or replace squid packages in a release.
Squid3 has many features that are simply not available to squid 2.5, and
I think parallel installs are really quite reasonable.
On Tue, 25 Apr 2006, Bernhard R. Link wrote:
For me a changed .orig.tar.gz means I no longer can easily verify what
exactly is changed. So I have to not only to download the original
This is a bug. debian/copyright might be in the diff, but it still needs to
describe all changes to upstream.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 24 Apr 2006 12:57:59 -0300
Source: hplip
Binary: hpijs hplip-data hpijs-ppds hplip
Architecture: source i386 all
Version: 0.9.10-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 19 Apr 2006 15:05:56 -0300
Source: mime-tools
Binary: libmime-perl
Architecture: source all
Version: 5.420-0.1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Changed-By: Henrique
801 - 900 of 1562 matches
Mail list logo
