On 2013-05-19 09:17:31 +0200, Jean-Christophe Dubacq wrote:
Le 16/05/2013 08:43, Vincent Lefevre a écrit :
On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote:
No. Your server comes unconfigured, you do configure it while the other
is still working, and then you stop the service on
That reminds me. Is there a way to get blhc to tell me *which* line in a
build log makes it think that compiler flags are hidden?
I agree that would be really useful
https://buildd.debian.org/~brlink/packages/r/remctl.html is reporting that
the compiler flags are hidden. So far as I know,
Le 16/05/2013 08:43, Vincent Lefevre a écrit :
On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote:
No. Your server comes unconfigured, you do configure it while the other
is still working, and then you stop the service on the first, finish
syncing the mailboxes, switch the MX record,
On Sb, 18 mai 13, 14:55:46, Charles Plessy wrote:
Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit :
Andrei POPESCU wrote:
Andreas Beckmann wrote:
now might be the right time to start a discussion about release goals
for jessie.
How about setting default umask for
On 16-05-13 21:27, Clint Byrum wrote:
Excerpts from Wouter Verhelst's message of 2013-05-14 03:22:14 -0700:
On 13-05-13 05:59, Mark Symonds wrote:
Can we keep the distribution simple enough for nearly anyone to understand?
No.
The goal of Debian is not to be simple. While we should
On 2013-05-18 14:55:46 +0900, Charles Plessy wrote:
http://wiki.debian.org/umask
It says:
An umask of 022 gives write permission to the other group members.
Is it true?
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog:
On Sb, 18 mai 13, 10:33:54, Vincent Lefevre wrote:
On 2013-05-18 14:55:46 +0900, Charles Plessy wrote:
http://wiki.debian.org/umask
It says:
An umask of 022 gives write permission to the other group members.
Is it true?
Probably a typo, fixed.
Kind regards,
Andrei
--
On Tue, 14 May 2013 17:37:59 +0100, Wookey woo...@wookware.org wrote:
+++ Stephen Kitt [2013-05-13 19:26 +0200]:
Yes, but that's not the problem. Take the premise that the target
directory structure is as described above, so most library development
packages ship as many headers as possible
On Fri, 17 May 2013 13:42:30 +0200, Holger Levsen
hol...@layer-acht.org wrote:
On Freitag, 17. Mai 2013, Marc Haber wrote:
We're going to have a TC decision or a GR about this anyway.
why do you think so?
Because I think that a decision of this magnitude should not be taken
by a single
On Mon, 13 May 2013 02:31:02 +0200, m...@linux.it (Marco d'Itri) wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev
depend on either upstart or systemd.
I would rather not be the one who will choose which one of them, so
I hope that we will get to a consensus about
Hi Marc,
On Freitag, 17. Mai 2013, Marc Haber wrote:
We're going to have a TC decision or a GR about this anyway.
why do you think so?
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote:
Shells suitable for /bin/sh are currently bash, dash, mksh.
I forgot about that (partly because of workarounds), but due to the
SIGINT problem, I think that *currently*, among these 3 shells, bash
is the most suitable one, and mksh is a bit
Andrei POPESCU wrote:
Andreas Beckmann wrote:
now might be the right time to start a discussion about release goals
for jessie.
How about setting default umask for users (uid = 1000) to 002?
+1. It would be a useful default.
Bob
signature.asc
Description: Digital signature
Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit :
Andrei POPESCU wrote:
Andreas Beckmann wrote:
now might be the right time to start a discussion about release goals
for jessie.
How about setting default umask for users (uid = 1000) to 002?
+1. It would be a useful
On Sun, May 12, 2013 at 05:06:26PM +0200, Matthias Klose wrote:
Am 12.05.2013 16:18, schrieb Daniel Schepler:
Maybe we could have a release goal of dropping as many lib32* and lib64*
packages as possible in favor of multi-arch. (And also as many package
dependencies on libc6-[i386|amd64]
On Sun, May 12, 2013 at 12:17:06PM +0200, Vincent Lefevre wrote:
On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote:
Now please, do the same reasoning with some other services,
like Apache, pure-ftpd, or bind, and explain to me why you would
like to have these installed, but not working.
On Lu, 06 mai 13, 14:49:57, Andreas Beckmann wrote:
Hi,
now might be the right time to start a discussion about release goals
for jessie.
How about setting default umask for users (uid = 1000) to 002?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions
On Wed, May 15, 2013 at 09:43:02PM +0200, Christoph Biedl wrote:
Christoph Anton Mitterer wrote...
2) No more packages that bypass the package management system and secure
apt:
a) There are still several (typically non-free) packages which download
stuff from the web, install or at
On Sat, May 11, 2013 at 05:29:45PM +0200, Sven Joachim wrote:
On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote:
While that might be of some interest the real goal of the change was
to be able to have more than *2* packages provide /bin/sh.
Currently, due to the totaly screwed up
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote:
+++ Steve Langasek [2013-05-11 09:33 -0700]:
On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
While that might be of some interest the real goal of the change was
to be able to have more than *2* packages
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote:
On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote:
Being able to choose between two entirely different desktop
environments, with different user experiences, is a good thing.
Being able to choose between two /bin/sh
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote:
+++ Steve Langasek [2013-05-11 09:33 -0700]:
On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
While that might be of some interest the real goal of the change was
to be able to have more than *2* packages
Hi Thorsten
On 11-05-13 20:26, Thorsten Glaser wrote:
Steve Langasek vorlon at debian.org writes:
This is not a sensible goal. Choice of /bin/sh should *not* be the goal,
the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
for *everyone*.
Sure. We just disagree
On 15-05-13 17:39, Thorsten Glaser wrote:
As for your requests of data: I do not provide them. As I said above,
I’m pushing for freedom of choice, not switching the default; of course
I’d be happy with the latter, even more so actually, but it must be a
thing not driven by me;
I see.
In that
On 13-05-13 06:16, Paul Wise wrote:
On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote:
I don't know about you, but I find it quite reassuring to be able to
confirm that the first half of an install is going pretty well when I
get to see the useless dummy page from Apache. I'd imagine
Thomas Goirand z...@debian.org writes:
Now please, do the same reasoning with some other services,
like Apache, pure-ftpd, or bind, and explain to me why you would
like to have these installed, but not working.
As a developer I have often found use for having Apache installed, just
so I can
On Wed, May 15, 2013 at 03:39:54PM +, Thorsten Glaser wrote:
As for your requests of data: I do not provide them. As I said above,
I???m pushing for freedom of choice, not switching the default; of course
I???d be happy with the latter, even more so actually, but it must be a
thing not
On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote:
No. Your server comes unconfigured, you do configure it while the other
is still working, and then you stop the service on the first, finish
syncing the mailboxes, switch the MX record, and then you can go to
rest.
This is not
Excerpts from Wouter Verhelst's message of 2013-05-14 03:22:14 -0700:
On 13-05-13 05:59, Mark Symonds wrote:
Can we keep the distribution simple enough for nearly anyone to understand?
No.
The goal of Debian is not to be simple. While we should document
things as much as possible so
Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb:
Another thing: Hardening already has been a release goal but there
still are packages around without.
Agreed. I made a concentrated effort for Wheezy by submitting lots of
patches for crucial packages and the general adoption among
Moritz Mühlenhoff j...@inutil.org writes:
Agreed. I made a concentrated effort for Wheezy by submitting lots of
patches for crucial packages and the general adoption among maintainers
is increasing. Also, Simon Ruderich's blhc tool has been very useful and
hardening checks are now also part
On Tue, May 7, 2013 at 4:23 PM, Thorsten Glaser t...@debian.org wrote:
Andreas Beckmann anbe at debian.org writes:
now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
* Resolve that /bin/sh issue (see
]] brian m. carlson
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as
]] brian m. carlson
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
On 05/15/2013 02:16 AM, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
Helmut Grohne helmut at subdivi.de writes:
What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway? It was ???suddenly??? in
Debian after having been used in Ubuntu,
Le mardi 14 mai 2013 à 23:26 +, brian m. carlson a écrit :
For better or for worse, sysvinit provides a lot of modularity. systemd
provides none of that modularity
Maybe you should read a bit about systemd before saying such nonsense.
The real-world systemd (not the imaginary software you
On Sat, May 11, 2013 at 06:26:40PM +, Thorsten Glaser wrote:
Oh, sorry, I forgot, you work for Canonical (which totally explains some
of your writings in the other eMail too, which I’m not going to comment
on). Of course, for *buntu people it’s not about choice.
I think you are totally out
On 2013-05-15 01:00:37 +0800, Thomas Goirand wrote:
On 05/13/2013 07:08 PM, Vincent Lefevre wrote:
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
This can be fine for some daemons/servers. For instance, for a web
server, displaying a
Russ Allbery rra at debian.org writes:
The cvs package went down the debconf path, and it never failed to annoy
me. When I installed the cvs package to get the cvs command-line client
to access remote CVS repositories, it asked me where I wanted to create a
Or even automatically created one,
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote:
Shells suitable for /bin/sh are currently bash, dash, mksh.
[...]
I have no idea whether yash or zsh can be made suitable, but I think
both could, if the maintainers and possibly upstream are interested.
Though zsh has an option to emulate
Jonathan Dowland jmtd at debian.org writes:
I think you are totally out of order, here. You could equally be
criticised
of having your judgement clouded by your involvement with MirOS. That
would
I admit being biased for that very reason. And that’s also the reason
I try to push for freedom of
On 05/14/2013 06:07 PM, Philip Hands wrote:
He missed the fact that you were contrasting one non-crashing init, that
is capable of restarting dead services, with another non-crashing
init setup that is not able to do so (without help).
Oh, indeed I missed that point! Thanks Phil.
Thomas
--
On 05/15/2013 05:52 AM, Vincent Bernat wrote:
I have still hard time to consider that you absolutely did not mention
something related to a bootloader.
I believe Phil Hands explained better than I would
what I tried to explain.
On 05/15/2013 05:52 AM, Vincent Bernat wrote:
Like in the previous
Am 15.05.2013 02:12, schrieb Michael Biebl:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet
Le 15/05/2013 16:40, Vincent Lefevre a écrit :
Here this is more than a mail server being down. It is a domain
without a MX; doesn't this mean a direct reject? Actually removing
the MX pointer wouldn't be OK, as the client may look at the A record
instead, which can't be removed without
Christoph Anton Mitterer wrote...
2) No more packages that bypass the package management system and secure
apt:
a) There are still several (typically non-free) packages which download
stuff from the web, install or at least un-tar it somwhere without
checking any integrity information that
Another thing: Hardening already has been a release goal but there
still are packages around without.
After having seen the proctetion catching a programming bug I think
more importance should be put on that, either by considering all
packages rc-buggy that should be built with hardening wrappers
On Wed, May 15, 2013 at 05:33:44PM +0200, Vincent Lefevre wrote:
Though zsh has an option to emulate sh, it may still not be completely
compatible. Upstream fixes incompatibilities when it is easy. But some
incompatibilities may remain. If sh needs special multibyte (UTF-8)
support for some
On 05/13/2013 06:05 AM, Josselin Mouette wrote:
Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit :
With all due respect, this might be utter bullshit, but is at least
[citation needed]. I have yet to see a failing pid 1 (be that sysv,
upstart or systemd). Acquiring data on failure
Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit :
On 05/13/2013 06:05 AM, Josselin Mouette wrote:
Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
something important crashes. On a production server, if apache crashes
and fails to reload properly because
Helmut Grohne helmut at subdivi.de writes:
What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway? It was “suddenly“ in
Debian after having been used in Ubuntu, but… there never was an
evaluation of shells.
I still believe the
On 05/14/2013 04:51 PM, Josselin Mouette wrote:
Yes of course, because a different init system will magically make your
other disk bootable.
This is absolutely *NOT* what I said. Nothing in my message
compares this or that init system. I just replied that when you
have apache, it's easier to
Josselin Mouette j...@debian.org writes:
Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit :
On 05/13/2013 06:05 AM, Josselin Mouette wrote:
Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
something important crashes. On a production server, if apache
On 13-05-13 05:59, Mark Symonds wrote:
Can we keep the distribution simple enough for nearly anyone to understand?
No.
The goal of Debian is not to be simple. While we should document
things as much as possible so that the interested can learn how things
work, in no case should we ever avoid
Quoting Wouter Verhelst (2013-05-14 12:22:14)
On 13-05-13 05:59, Mark Symonds wrote:
Can we keep the distribution simple enough for nearly anyone to
understand?
No.
The goal of Debian is not to be simple. While we should document
things as much as possible so that the interested can
On Tue, May 7, 2013 at 9:06 AM, Thijs Kinkhorst th...@debian.org wrote:
I suggest that you file a bug against php5 with suggested changes and we can
discuss the pros and cons of each for jessie.
And I must add that I consider very rude to push your (sometimes
extreme, sometimes very usefull)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote:
...
forcing the rest of the world to conform to our worldview. One
desktop environment, and an awful one at that, dictating the
init system we use is a complete farce. Debian is a lot bigger
than GNOME, and if we have to, I'd
On Tue, 2013-05-14 at 08:59 +, Thorsten Glaser wrote:
Helmut Grohne helmut at subdivi.de writes:
What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway? It was “suddenly“ in
Debian after having been used in Ubuntu, but… there
On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote:
On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow goswin-...@web.de
wrote:
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
The big issue which crops up then isn't so much the directory structure's
impact
Paul Wise wrote:
Probably the rsync package should just ask you via debconf if you want
to serve any directories and what their names and paths should be.
Since most folks who have rsync installed don't need rsyncd, the
default would be to not setup anything.
No, it should not. 60 packages
+++ Stephen Kitt [2013-05-13 19:26 +0200]:
Yes, but that's not the problem. Take the premise that the target directory
structure is as described above, so most library development packages ship as
many headers as possible in /usr/include. For now we'll assume all
mingw-w64-...-dev headers are
On 05/13/2013 07:08 PM, Vincent Lefevre wrote:
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
This can be fine for some daemons/servers. For instance, for a web
server, displaying a default web page is harmless. But what about a
mail server?
Philip Hands wrote:
Vincent Lefevre writes:
I agree for these services (though Apache is useless after just
being installed, as one just has a dummy web page).
I don't know about you, but I find it quite reassuring to be able to
confirm that the first half of an install is going pretty
Joey Hess jo...@debian.org writes:
Paul Wise wrote:
Probably the rsync package should just ask you via debconf if you want
to serve any directories and what their names and paths should be.
Since most folks who have rsync installed don't need rsyncd, the
default would be to not setup
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
Helmut Grohne helmut at subdivi.de writes:
What are the benefits of using shells other than dash for /bin/sh? (as
Why does dash get special treatment, anyway?
Because /bin/sh is special under Debian policy, as an essential
❦ 14 mai 2013 11:54 CEST, Thomas Goirand z...@debian.org :
Yes of course, because a different init system will magically make your
other disk bootable.
This is absolutely *NOT* what I said. Nothing in my message
compares this or that init system. I just replied that when you
have apache,
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet to
see a use case where it is not better.
It is not better if you don't want proprietary
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet to
see a use case where it is not better.
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet to
see a use case where it is not better.
On 05/15/2013 02:16 AM, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have
And, when it comes to processing, binary data is actually *easier* to
process. Everyone who has ever written a text parser themselves will
agree.
I guess everyone who has used grep, tr, sed and so on will disagree?
--
Salvo Tomaselli
http://web.student.chalmers.se/~saltom/
--
To
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
On 05/15/2013 02:16 AM, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it.
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
Am 15.05.2013 01:26, schrieb brian m. carlson:
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other
❦ 11 mai 2013 22:08 CEST, Josselin Mouette j...@debian.org :
I can't agree with having no choice with regard to init. We aren't
all using GNOME, and Debian is used in an extremely diverse set of
fields for a multitude of different purposes. No one init is
appropriate for all of these
On Du, 12 mai 13, 20:31:08, John Paul Adrian Glaubitz wrote:
The difference between a shell and an init system is that the former
is directly exposed to the user while the latter will only be
visible to developers and admins most of the time. It makes sense to
be able to customize your user
On Mon, May 13, 2013 at 02:31:02AM +0200, Marco d'Itri wrote:
On May 13, Holger Levsen hol...@layer-acht.org wrote:
actually, while it has been brought up as a theoretical/wrong argument,
that
we cannot switch our linux installation ship with $this init system, while
the
kfreebsd
Paul Wise p...@debian.org writes:
On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote:
I don't know about you, but I find it quite reassuring to be able to
confirm that the first half of an install is going pretty well when I
get to see the useless dummy page from Apache. I'd imagine
On Mon, May 13, 2013 at 5:20 PM, Philip Hands wrote:
It looks to me as though your apache and rsyncd suggestions are straying
into the forbidden territory of using debconf as a registry.
I didn't advocate storing such info in debconf.
PS: I'm subscribed.
--
bye,
pabs
Marco d'Itri m...@linux.it writes:
On May 13, Holger Levsen hol...@layer-acht.org wrote:
actually, while it has been brought up as a theoretical/wrong argument, that
we cannot switch our linux installation ship with $this init system, while
the
kfreebsd port uses $that init system, I'd
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
I agree for these services (though Apache is useless after just
being installed, as one just has a dummy web page).
So useful, since you can then put files into the docroot and serve those
files.
But the admin
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not working by default, and loses
mail, the daemon shouldn't be enabled by default.
IIRC,
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
This can be fine for some daemons/servers. For instance, for a web
server, displaying a default web page is harmless. But what about a
mail server? Any default config would probably lead to
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
I agree for these services (though Apache is useless after just
being installed, as one just has a dummy web page).
So useful, since you can then put files into the
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not working by default, and loses
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
But not for postfix, which can reject mail by default without an
initial configuration. Since it is not
On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
My only use of Apache on some machine is because of sensord. But
it may happen that in a few months, I would no longer need sensord
and may remove the package. In this case, it would make sense to
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
So you configured it through debconf, in a non-default way, and it
refused mails according to how you configured it.
AFAIK, debconf is the *only* choice.
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
So you configured it through debconf, in a non-default way, and it
refused mails according to how you configured it.
AFAIK,
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
No, it does not, since the default configuration («Local only»)
sets
This is not the default configuration, just the default choice (it
is not written Default
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
My only use of Apache on some machine is because of sensord. But
it may happen that in a few months, I would no longer need sensord
and may remove the
On 2013-05-12 21:31, m...@linux.it wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make
udev
depend on either upstart or systemd.
do you have a link to a presentation, blog post, or whatever explaining
the rationale behind this?
i didn't found anything on FOSDEM
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
Yes, but similarly, there's no way to do this automatically.
apt-get autoremove is automatic, or if you want that earlier you could
remove sensord using aptitude which will automatically remove unused
dependencies.
There's also a problem
On 2013-05-13 08:48:33 -0400, The Wanderer wrote:
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
No, it does not, since the default configuration («Local only»)
sets
This is not the default configuration, just
On 2013-05-13 14:37:28 +0100, Philip Hands wrote:
Vincent Lefevre vinc...@vinc17.net writes:
There's also a problem that the man pages are in the package:
$ dpkg -L apache2.2-common | grep /man/
/usr/share/man/man8
/usr/share/man/man8/apache2.8.gz
/usr/share/man/man8/a2ensite.8.gz
On 2013-05-13 16:26:58 +0200, Vincent Lefevre wrote:
One could imagine the same thing but with testing directories...
Something like in the /etc/default/ file:
test -f some_dir || ENABLED=0
But this method needs an ENABLED variable!
Actually, that would be more like
ENABLED=0
test -f
On Mon, May 13, 2013 at 12:05:59AM +0200, Josselin Mouette wrote:
Having a rock-stable PID 1 is nice and all, but it doesn???t help you if
something important crashes. On a production server, if apache crashes
and fails to reload properly because the scripts don???t get the ordering
right, it
On 2013-05-13 21:42:20 +0800, Paul Wise wrote:
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
Yes, but similarly, there's no way to do this automatically.
apt-get autoremove is automatic, or if you want that earlier you could
remove sensord using aptitude which will automatically
Le lundi 13 mai 2013 15:37:28, Philip Hands a écrit :
If you must see the man page from a particular package:
dget apache2.2-common
mkdir -p ./tmp/apache2.2-common
dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common
JTYI, you could also use debman -p apache2.2-common
On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow goswin-...@web.de
wrote:
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
The big issue which crops up then isn't so much the directory structure's
impact on the build process, but rather its impact on the packaging
On May 13, gustavo panizzo gfa g...@zumbi.com.ar wrote:
On 2013-05-12 21:31, m...@linux.it wrote:
Maybe kfreebsd will do, but as I explained at FOSDEM I plan to
make udev depend on either upstart or systemd.
do you have a link to a presentation, blog post, or whatever
explaining the
1 - 100 of 221 matches
Mail list logo
