On 2012-07-26 03:58:33 +0900, Miles Bader wrote:
Vincent Lefevre vinc...@vinc17.net writes:
So... these functions were made almost an order of magnitude slower
in the (overwhelmingly) common case, in order to handle rare and
exceptional cases...?
This depends on the processor. You
On 2012-07-25 21:28:16 +0100, Neil Williams wrote:
On Wed, 25 Jul 2012 21:58:20 +0200
Svante Signell svante.sign...@telia.com wrote:
Is emacs24 going to be the default package for Wheezy?
emacs24 is not in Wheezy yet and has been uploaded to sid since the
automatic freeze exception was
On 2012-07-26 13:33:46 +0900, Miles Bader wrote:
Vincent Lefevre vinc...@vinc17.net writes:
I think that there could be an optimization like that in
fesetround() too.
Do you think it's worth proposing this to the glibc people?
Yes, since this makes the code much faster on some processors
On 2012-07-26 10:50:52 +0200, Svante Signell wrote:
On Thu, 2012-07-26 at 02:39 +0200, Vincent Lefevre wrote:
emacs23 doesn't have RC issues, but bug 608417 is close to one. This
bug is worse that I expected in the first place. I got corrupted files
several times without noticing
On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
An ENABLE switch does more than just disabling the run-at-boot state of
an initscript. While I can buy the argument that some packages should
not start *at boot* by default,
The problem is not just at boot, but also when pacakges are
On 2012-07-30 10:50:17 +0100, Lars Wirzenius wrote:
I'm writing this on a machine running squeeze, so this may be a bit
different in later versions, but here's the snippet:
if [ -x /etc/init.d/rsync ]; then
if dpkg --compare-versions $oldversion lt 3.0.7-2; then
On 2012-07-30 12:01:08 +0200, Jonas Smedegaard wrote:
On 12-07-30 at 12:37pm, Andrei POPESCU wrote:
I'd say there is a need for:
1. a system-wide setting to start daemons or not on boot/upgrades/etc.
2. a blacklist - daemons listed here should not start no matter what
3. a whitelist -
On 2012-08-08 13:38:36 +0200, Alberto Fuentes wrote:
[extra non usuful comments]
Those commands without root permissions are not dangerous. ifconfig seems
the most obvious that a non expert would want to run. ipconfig/ifconfig eth0
are easy to run/remember.
ip addr show eth0 is not. ip has
On 2012-08-08 14:38:44 +0100, Roger Leigh wrote:
Normal users do not need to know or care about these tools.
For some of them, they do. Normal users don't need most programs
installed in /usr/bin, so let's split this directory? :)
Only admins use them, or tools that set things up on behalf of
On 2012-08-08 22:01:37 +0800, Thomas Goirand wrote:
On 08/08/2012 09:11 PM, Vincent Lefevre wrote:
And ip is not standard (not present on every Linux systems), whereas
I don't know any system without ifconfig.
Then, what do you use to list multiple IPs on a single interface?
ifconfig
On 2012-08-08 22:09:27 +0800, Thomas Goirand wrote:
What would be the point, for example, to have these
accessible to the user:
- depmod/insmod/etc.
- swapon/swapoff
- agetty
- init
- etc.
One (perhaps minor) point would be to get basic documentation, e.g.
depmod --help
There is no
On 2012-08-20 13:08:53 +0200, Bjørn Mork wrote:
Why do you install gnome-core if you don't want the resulting
package mess?
If it isn't that important, I think the word essential shouldn't
be used.
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated
On 2012-08-24 15:03:49 +0100, Ben Hutchings wrote:
On Fri, 2012-08-24 at 10:44 +0200, Andrew Shadura wrote:
Hello,
On Mon, 20 Aug 2012 14:51:27 +0100
Ben Hutchings b...@decadent.org.uk wrote:
What I mean is that this still happens:
# ifup eth0
...
# ifconfig eth0 down
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is:
Can it be exectued/interpreted directly or by some interpreter? Then
application/*
Or compiled executed, I suppose.
But what if the intent is to display the source
On 2012-08-28 04:32:18 +0200, Christoph Anton Mitterer wrote:
On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
Now obviously there's a small border; I guess IETF's idea is:
Can it be exectued/interpreted directly
On 2012-08-28 12:05:26 +0200, Adam Borowski wrote:
On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
We know some packages are better to use gzip, but it's an
exception. Using xz is best choice for rest 99.99% of packages.
We can deal with such exception by specifying gzip
On 2012-08-28 11:43:32 +0100, Ian Jackson wrote:
Christoph Anton Mitterer writes (Re: About the media types text/x-php and
text/x-php-source):
On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
There are a fair number
of email clients out there that, rightly or wrongly, will not
On 2012-08-28 12:36:22 +0100, Ian Jackson wrote:
Vincent Lefevre writes (Re: About the media types text/x-php and
text/x-php-source):
Now, the sender could also provide a charset with
application/*, in which case the recipient client should know
that this is necessarily text
On 2012-08-28 14:49:53 +0200, Christoph Anton Mitterer wrote:
Ian,...
Again, AFAIU, IETF nor the RFCs do consider the MIME types as way to
determine what the sender/creator intends the recipient to do with it.
Perhaps it would be more clear like that: one may want to consider
a script as a
On 2012-08-28 15:53:51 +0200, Christoph Anton Mitterer wrote:
On Tue, 2012-08-28 at 15:20 +0200, Vincent Lefevre wrote:
Perhaps it would be more clear like that: one may want to consider
a script as a program/application that can be executed, in which
case application/* should be used
On 2012-08-28 16:19:29 +0100, Ian Jackson wrote:
*.php files should be recognised as text/x-php or text/x-php-source by
our mime types file.
If Apache (or some other webserver) wants to automatically execute
*.php files (whether the url referring to foo.php is is
http://example.com/foo.php
On 2012-08-28 22:41:38 +0300, Serge wrote:
All connections I can think of belong to one of two categories:
1. Permanent connections. Those are setup-and-forget connections.
Typical for servers and wired desktops. Can be managed with ifupdown.
2. Temporary connections. Those are
On 2012-08-29 19:17:36 +0800, Paul Wise wrote:
On Wed, Aug 29, 2012 at 5:46 PM, Vincent Lefevre wrote:
There's also usbnet, which is used when I connect my Nokia N900 to
my laptop. There must also be a fixed setup, but I haven't found a
solution to recognize my N900 with ifupdown (the MAC
On 2012-08-28 18:03:02 +0200, Christoph Anton Mitterer wrote:
On Tue, 2012-08-28 at 15:37 +0100, Ian Jackson wrote:
Then if there is a charset parameter, with a value that refers to
some known text character set, I think that one can assume that
the contents are encoded with this
On 2012-11-09 14:36:24 +0200, Riku Voipio wrote:
On Sun, Nov 04, 2012 at 12:03:37PM +0100, Karol Szkudlarek wrote:
[...]
and about touchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238
[...]
Perhaps we should stop pretending Linux runs on any random hardware, and
tell
On 2012-11-11 21:27:19 +0100, Karol Szkudlarek wrote:
Do you tried nvidia close drivers or nouveau (in the aspect
suspend/resume)?!
Only nouveau (to avoid tainted kernels in particular). But I had
problems with the Nvidia proprietary drivers in the past.
At least the following bug has been
On 2012-11-12 21:52:41 +0100, Karol Szkudlarek wrote:
(BTW, I plan to purchase a Lemote YeeLoong 8101B, which has only
GNU/Linux support, but haven't had news from the vendor yet.)
I've heard some time ago about Lemote laptops (aka Stallman
recommendations!) its worth attention but they have
On 2012-11-13 13:23:48 +0100, Karol Szkudlarek wrote:
It would be interesting to know which Debian developers have
which laptops. Bugs appearing on these laptops might be fixed
more easily. At least it would allow bugs to be checked and
possibly reproduced more easily.
I'm wondering whether
On 2012-11-14 08:44:58 +0100, Karol Szkudlarek wrote:
I have the same card and I can tell you that the nouveau driver is
broken with it. See the bug mentioned above:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464
According to point 6 of
On 2012-11-15 00:15:06 +, Dmitrijs Ledkovs wrote:
Also XML is not diff-able easily, which is usual for tree-like structures.
If you mean diff-able for the human, then it depends on the complexity
of the data. I have no problems with mine. wdiff can help.
But what I really like with XML is
On 2012-11-26 07:27:08 +0900, Norbert Preining wrote:
Ever heard of
grep, sed, awk,
all these nice things that make your life happy.
These tools are broken when dealing with multibyte characters.
For instance, with:
foo = aéb
a grep 'a.b' file will find nothing in the C locale.
On 2012-11-26 20:32:17 +0100, olivier sallou wrote:
XML is nice for internal config, message/config exchanges, etc... help with
its structure and its DTD to force/help understanding the schema.
BUT definitely not useable by an end user for end-user config. It is very
hard to read (opening an
On 2012-11-28 11:47:38 +0100, Adam Borowski wrote:
Let's give it a test, this mail should be signed:
From blahhityblah Fri Jul 8 12:08:34 2011
From foobarbaz Fri Jul 8 12:08:34 2011
From quux Fri Jul 8 12:08:34 2011
If the signature is invalid, your setup is broken.
Even users of
On 2012-11-29 01:50:55 +0100, Christoph Anton Mitterer wrote:
It's like a serious flaw would have been found in gzip and people would
say... oh don't complain... there's already the much better/newer bzip2
or xz.
There's a major difference. mbox is buggy by design. Even though
mboxrd attempts
On 2012-11-29 01:28:37 +0100, Christoph Anton Mitterer wrote:
But it also has disadvantages to the mbox formats which may be crucial
for some people:
- wasting a lot of storage, which can be significant even if you use
small file systems block sizes...
This is a problem with the file system,
On 2012-11-29 01:39:57 +0100, Christoph Anton Mitterer wrote:
On Wed, 2012-11-28 at 16:01 +0100, Vincent Lefevre wrote:
Even users of mboxo shouldn't even have a problem because in your
message the F of the From line is encoded in quoted-printable:
| =46rom blahhityblah Fri Jul 8 12:08
On 2012-11-29 01:49:55 +0100, Christoph Anton Mitterer wrote:
On Wed, 2012-11-28 at 22:06 +, Darren Salt wrote:
It would make sense to have that enabled by default, and to ensure
that all software in Debian which produces MIME quoted-printable
does this, or at least can do this.
I
On 2012-11-29 15:30:47 +0100, Christoph Anton Mitterer wrote:
On Thu, 2012-11-29 at 15:20 +0100, Vincent Lefevre wrote:
Now, I would say that in general, the wasted space is small compared
to large attachments. And if you have only text and care about disk
space, you should consider
On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote:
On Mon, Nov 26, 2012 at 05:00:14PM +0100, Vincent Lefevre wrote:
On 2012-11-26 07:27:08 +0900, Norbert Preining wrote:
Ever heard of
grep, sed, awk,
all these nice things that make your life happy.
These tools are broken
On 2012-11-29 06:43:06 +, Ian Campbell wrote:
On Wed, 2012-11-28 at 16:06 -0500, Nikolaus Rath wrote:
Darren Salt lists...@moreofthesa.me.uk writes:
(Oops. Failed first time.)
Having just viewed the raw text of my message (as sent), there's one other
little wrinkle which I
On 2012-11-29 16:16:25 +0100, Adam Borowski wrote:
*cough* btrfs -ocompress=lzo. Small files are packed inline in metadata
blocks, and you get compression you wanted. Using lzo is faster than no
compression for most loads, adding negligible cost for incompressible data
(especially if not all
On 2012-11-29 21:33:37 +0600, Andrey Rahmatullin wrote:
On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
The default .subversion/config file is a piece of documentation, not a
configuration file. I agree that there's far too much noise in there.
However, that's not a flaw
On 2012-11-29 18:08:05 +0100, Adam Borowski wrote:
On Thu, Nov 29, 2012 at 04:23:03PM +0100, Vincent Lefevre wrote:
On 2012-11-29 15:46:35 +0100, Wouter Verhelst wrote:
But it will in a UTF8 locale,
Unfortunately the C locale is the only really portable one.
Debian's glibc has C.UTF
On 2012-11-29 21:25:50 +0100, Stig Sandbeck Mathisen wrote:
So to keep everyone equally happy, we need:
config
![CDATA[
[section1]
key1=val1
key2=val2
key3=♬♫♩♩♫
[section2]
foo=bar
]]
/config
Structure _and_ readability.
No, you don't have the structure from the XML point of
On 2012-11-29 08:37:19 -0800, Kelly Clowers wrote:
On Thu, Nov 29, 2012 at 7:23 AM, Vincent Lefevre vinc...@vinc17.net wrote:
And interfaces in various programming languages?
http://search.cpan.org/~shlomif/Config-IniFiles-2.78/lib/Config/IniFiles.pm
At least for Perl, I can't see anything
On 2012-12-01 10:16:54 +0100, Wouter Verhelst wrote:
On Fri, Nov 30, 2012 at 02:18:04AM +0100, Vincent Lefevre wrote:
At least for Perl, I can't see anything related to validation.
That's because validating an ini file is trivially easy:
the line is a comment line, which must start
On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote:
On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote:
On 2012-12-01 10:16:54 +0100, Wouter Verhelst wrote:
On Fri, Nov 30, 2012 at 02:18:04AM +0100, Vincent Lefevre wrote:
At least for Perl, I can't see anything related
On 2012-12-03 14:05:49 +0700, Ivan Shmakov wrote:
On the second sight, the difference between, e. g.:
a
b
cd/c
ef/e
/b
g
hi/h
/g
/a
and, e. g.:
[a.b]
c = d
e = f
[a.g]
h = i
is mostly superficial.
There may be a difference at the API
Sorry for replying so late, but I disagree...
On 2012-12-26 03:03:57 +0100, Timo Weingärtner wrote:
2012-12-26, 02:22:45 Cyril Brulebois wrote:
Timo Weingärtner t...@tiwe.de (26/12/2012):
bash, zsh, posh output 121
busybox sh, dash, (m)ksh output 122
checkbashisms doesn't
On 2013-01-23 20:45:49 -0800, Russ Allbery wrote:
Adam Borowski kilob...@angband.pl writes:
There are two ways to design a system:
* a monolithic well-integrated system, granting features and efficiency at
the cost of portability and hackability
* the traditional Unix way, with a
On 2013-03-31 23:20:23 +0100, Neil Williams wrote:
The length of the freeze is not the fault of the release team.
The length of the freeze is down to all of the contributors to Debian
not fixing enough RC bugs - I count myself in that, I've managed to get
massively less done for this release
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote:
This is indeed Debian’s problem and needs discussion, but the roots lie
in upstreams. It mostly comes down to the fact that upstreams of a
growing number of projects are not able to synchronize their releases so
that a single set of
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed,
Problem is: until you freeze, new RC bugs keep getting introduced.
But I would say, not many
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
Having latest upstream versions easily available to users is important
for the development of many projects,
That's what experimental is for.
There are various problems with
On 2013-04-02 14:17:17 +0100, Neil Williams wrote:
The release happens when (almost) all RC bugs are fixed, the freeze is
to allow the existing bugs to be fixed whilst *protecting* the other
packages from breakage caused by new software being uploaded.
You can still fix bugs while new software
On 2013-04-02 15:23:18 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit :
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote:
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit :
I disagree. If the freeze occurred only once (almost) all
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
That is not how it actually works out. Policy changes are made which
require old packages to build with new flags, compilers and toolchain
packages get upgraded and introduce new failure modes, QA tools improve
and catch more corner cases.
On 2013-04-02 13:37:59 -0500, Peter Samuelson wrote:
[Vincent Lefevre]
I disagree. If the freeze occurred only once (almost) all RC bugs
were fixed, there would be (almost) no delay. I suspect that the
length of the freeze is due to the fact that the freeze occurred
while too many RC bugs
On 2013-04-02 09:50:23 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
There are various problems with experimental, in particular dependencies
are not necessarily listed,
Huh? I have no clue what you could possibly be talking about, unless
you're just saying
On 2013-04-02 21:53:08 +0200, Philipp Kern wrote:
Vincent,
am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben:
I don't think that the status even of a big package like iceweasel
is satisfactory.
I pretty much agree. But what's the problem here? That xulrunner and
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
On 2013-04-02 14:29:46 +0100, Neil Williams wrote:
That is not how it actually works out. Policy changes are made which
require old packages to build with new flags, compilers and toolchain
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote:
Just to expand slightly on this, the problem you're both poking at is
that during a freeze, our incentives are directed towards fixing RC bugs
(because then we can release, which means we can then do what we prefer
to, which (as you can see
On 2013-04-03 20:14:32 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote:
In general, bug-fix releases (which are also blocked by the freeze)
don't introduce new bugs.
Case in point:
http://www.h-online.com/open/news/item/Security-updates-break
On 2013-04-03 20:17:47 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote:
I pretty much agree. But what's the problem here? That xulrunner and
iceweasel have rdeps in the archive that aren't necessarily
compatible with a new version of iceweasel
On 2013-04-04 16:23:33 +0200, Philipp Kern wrote:
On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote:
It seems that most reverse dependencies for iceweasel are l10n
packages and extensions, so that one can consider them as part
of the upgrade. The remaining dependencies seem
On 2013-04-04 21:08:45 +0200, Philipp Kern wrote:
On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote:
I wonder whether there are packaged extensions […]
So you didn't actually look. EOT from me, it's wasting my time.
Sorry, I meant why instead of whether. As I've said in my
On 2013-04-15 15:31:38 +0100, Neil McGovern wrote:
On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote:
So, transitions could be avoided in a social way. No need for a freeze.
Let's see how well that works - look at the very first message in this
thread.
My point
On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote:
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote:
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote:
Oh, that's a good point. Yes, I hadn't thought about that specific case
for testing ABI breakage in
On 2013-05-07 00:52:03 +0800, Thomas Goirand wrote:
On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote:
The usually come only with a default config which may not be hardened
enough for the local system, and that short time may already be enough
for an attacker to attack.
If the default
On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote:
On May 06, Christoph Anton Mitterer cales...@scientia.net wrote:
1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
default on the network (unless loopback only) shouldn't be started per
default, after being installed.
On 2013-05-09 00:25:06 +0200, Jakub Wilk wrote:
Let me try to explain where the difference lies. Consider the following
sequences of uploads:
foo_4
foo_5
foo_1:4
foo_1:6
bar_4
bar_5
bar_5really4
bar_6
Two kind of bugs in (build-)dependencies on these packages could happen:
1)
On 2013-05-10 14:57:46 +0200, Piotr Ożarowski wrote:
[Charles Plessy, 2013-05-09]
For a large number of packages if not all, we should allow the
package maintainers to manually migrate their packages to Testing during the
Freeze, within boundaries set on debian-devel-announce by
On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote:
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing epoch separator
char : by @ in the filenames for example?
Why not keep the usual : escaping as in
On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote:
On 05/07/2013 04:11 AM, Vincent Lefevre wrote:
This doesn't make any sense. What is installed is a package, not
a service. There are packages, like rsync, that provide more than
a service, e.g. a client and a daemon. What if the user wants
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
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
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
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
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
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 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
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
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
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
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
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 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 2013-05-22 15:39:00 +0200, Bernd Schubert wrote:
On 05/22/2013 04:50 AM, Uoti Urpala wrote:
Lucas Nussbaum wrote:
I went through the various init systems threads again during the last
few days. My understanding of the consensus so far is the following:
- Both systemd and upstart bring
On 2013-05-27 09:04:53 +0200, Ondřej Surý wrote:
I think I have never said the word abuse, just tiresome. The I see a
warning from ucf, let's fill a bug on php5-common finally overflew my cup
of patience (what is the correct english idiom for this?).
If you think you are distracted by some bug
On 2013-05-31 08:52:37 +, Raphael Geissert wrote:
Russ Allbery rra at debian.org writes:
[...]
This would *enable* users to install software from backports if it either
didn't exist in stable at all or if they explicitly requested it from
backports, but would not install such software
On 2013-05-28 13:05:25 +0200, Josselin Mouette wrote:
Le mardi 28 mai 2013 à 12:13 +0200, Adam Borowski a écrit :
Being able to send outgoing mail, and to handle local (such as
SMTP rejects or notifications from system daemons) seems plenty
useful to me.
Most clients (apart maybe from
On 2013-05-30 13:59:09 -0700, Russ Allbery wrote:
Also, determining which flags to pass to the daemon from some other
configuration file, which is a common use of /etc/default files, is a hack
to work around the fact that an init script is not really user-editable.
We therefore move the parts
On 2013-06-02 11:10:34 -0700, Russ Allbery wrote:
Michael Biebl bi...@debian.org writes:
Am 02.06.2013 18:59, schrieb Russ Allbery:
There's really no reason to have something like an /etc/default setting
for that, the way there is for the rsyncd init script. You can just
edit that
I reported a bug involving private data disclosure, more precisely,
on some network, when printing a file with CUPS 1.6, the file is
printed on a wrong printer[*]. The bug severity was downgraded to
important (i.e. non-RC), despite the obvious security problem. The
given reason was that this kind
On 2013-06-10 15:05:05 +0100, Jonathan Dowland wrote:
It's amazing how much simpler Debian life becomes if one simply ignores
bug severities entirely. Of course harder to do nearer to release, but
we live in a time of relative luxury right now…
This is important for apt-listbugs, which takes
On 2013-06-10 15:11:26 +0100, Ian Jackson wrote:
I agree with you that that bug is a potential security vulnerability.
I think the maintainer adopted an overly-close and legalistic reading
of the bug severity guidelines. On the other hand I think the
maintainer makes good points about the
On 2013-06-10 17:16:12 +0200, Cyril Brulebois wrote:
Since you seem concerned about apt-listbugs, make it support listing
security bugs (optionally with a given severity threshold, so as to
ignore minor or normal bug reports tagged security), and there you go.
[ From a quick look at the
On 2013-06-10 23:28:28 +0600, Andrey Rahmatullin wrote:
On Mon, Jun 10, 2013 at 04:15:27PM +0200, Vincent Lefevre wrote:
This is important for apt-listbugs, which takes into account RC bugs by
default
Which too is not ideal: for example, I don't think users should care about
such RC bugs
101 - 200 of 399 matches
Mail list logo
