Re: weird font corruption caused by scrolling

[Vincent Lefevre]

On 2004-09-19 12:05:40 +0300, Ismail Donmez wrote:
> I can also reproduce this bug on Sid and Slackware 10 . So this is a
> mozilla bug I am sure.

I'm also seeing this problem, just after switching from Mozilla to
Firefox *with a different configuration* (for the moment). In the
screenshot, the text look smaller, but sometimes a line is clearly
missing (for instance, when this is the top line). There had been
a discussion in French here:

    From: Vincent Lefevre <[EMAIL PROTECTED]>
Newsgroups: fr.comp.infosystemes.www.navigateurs
Subject: Re: IE et le png
Date: Fri, 11 Apr 2003 00:25:57 + (UTC)
Message-ID: <[EMAIL PROTECTED]>

and in the followups. The workaround (which has worked very well
with Mozilla): set browser.display.screen_resolution to 96; this
value is OK for me, other values may work too.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Switching /bin/sh to dash without dash essential

[Vincent Lefevre]

On 2009-07-24 15:49:15 +, brian m. carlson wrote:
> On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote:
> > zsh has also historically been fairly buggy in corner cases as
> > /bin/sh and requires explicit commands to make it
> > Bourne-compatible. Autoconf has had to add a bunch of workarounds
> > for zsh as sh that I'm sure most of our shell scripts don't have.
> 
> Actually, if it's invoked as /bin/sh, it is supposed to be
> Bourne-compatible.

I suppose that (both of) you mean POSIX-compatible (as there are
differences between the traditional Bourne shell and POSIX shells).

>  That's my experience with the current version:
> 
>   lakeview ok % emulate; /bin/sh -c emulate
>   zsh
>   sh
> 
> I don't know what other versions do.  I'm working on finding bugs with
> zsh as /bin/sh; see #510358.  If anyone knows about a good /bin/sh
> (POSIX, XSI, or Debian) testsuite, please let me know off-list.

I've also reported a number of zsh POSIX-compatibility bugs. There
are still differences between shells concerning "set -e" [*], and
AFAIK, POSIX hasn't been made clear yet. I wonder how this is dealt
with in the switch from bash to dash for /bin/sh.

[*] See http://www.in-ulm.de/~mascheck/various/set-e/

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching /bin/sh to dash without dash essential

[Vincent Lefevre]

On 2009-07-25 09:53:06 +0200, Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 10:38:51AM -0500, Manoj Srivastava wrote:
> > On Fri, Jul 24 2009, Steve Langasek wrote:
> > > What's the advantage of having it be zsh? Is zsh faster than
> > > dash? Or is the only savings the elimination of the 84k dash
> > > binary from /bin?
> 
> > It allows all the #!/bin/sh scripts that us zsh-isms to run.
> 
> They can already be run under #!/bin/zsh. Why would we want to tie
> our hands even further as a distribution by putting ourselves in the
> position of having end users deploying /bin/sh scripts that require
> zsh, *in addition* to the end users who already deploy /bin/sh
> scripts that require bash?

I don't know what Manoj had in mind exactly, but he hasn't said that
zsh would be required. Think about something like that:

#!/bin/sh
if test -n "$ZSH_VERSION"; then
  foo="$HOME:t"
else
  foo="..."  <- slower version for generic POSIX shells
fi

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-28 14:34:39 +1100, Brian May wrote:
> Also, FQDNs are really not applicable to, say laptops, which
> frequently change from one network to another. Or some desktops
> even. I notice on this Ubuntu laptop `hostname` == `hostname -f`
> perhaps for this reason.

FQDNs are also applicable to laptops, as the FQDN can be used to
generate the right part of the Message-Id, for instance. Just make
sure that it identifies the machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-27 14:22:53 -0800, Steve Langasek wrote:
> No, the hostname should be set on a *separate* line, mapped to 127.0.1.1,
> as we've been doing for years now.  Setting an equivalence between localhost
> and the hostname causes all manner of problems due to hostname
> canonicalization.

Shouldn't this be described in the hosts(5) man page?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-28 12:52:12 -0800, Steve Langasek wrote:
> That would seem to fit with the rest of the page. I guess a bug
> report is in order?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562890

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-28 23:41:38 +, Sam Morris wrote:
> Details in . I 
> do wonder, however, why the system hostname has to appear in /etc/hosts 
> at all? Programs that want to find it out can read /etc/hostname 
> directly, after all. And wtf is 'localdomain' for, anyway?

Programs may need the FQDN, even without any network connection (for
instance, even local mail messages should have a Message-Id). And
/etc/hostname doesn't necessarily contain the FQDN.

Also, it is required that the FQDN be resolvable (but I wonder whether
this is useful in practice).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 00:21:45 +, Sam Morris wrote:
> On Tue, 29 Dec 2009 01:03:12 +0100, Vincent Lefevre wrote:
> > Programs may need the FQDN, even without any network connection (for
> > instance, even local mail messages should have a Message-Id). And
> > /etc/hostname doesn't necessarily contain the FQDN.
> 
> Hm, but shouldn't they use another method to get it? My laptop has no 
> FQDN when it is not connected to a network, and even when it is, it has 

I think this is bad (POSIX seems to assume that all machines have
a FQDN).

> never, to my knowledge, had a fully qualified name that could be resolved 
> to find out its network address.

The goal of the FQDN is not to find "its network address" (which
is rather meaningless, because a network address is related to a
network interface, not to the machine). Having the FQDN resolved
to 127.0.1.1 on the machine is fine.

> Conversely, I have used servers that had multiple network interfaces, 
> some of which even have multiple network addresses assigned to them. 
> 'hostname -f' did not yield a sensible result on a couple of these 
> systems.

What do you mean by "sensible result"? I think you're assuming too
much concerning "hostname -f".

> What would a hypothetical host that only had IPv6 connectivity do?

You still have the IPv4 loopback.

> We certainly don't have a line analogous to the '127.0.1.1' hack in
> /etc/ hosts for ipv6, and I'm not even sure what such a line would
> look like, since ::1 has a /128 netmask.

Do you mean that you don't want to use IPv4 at all and that the
loopback interface only provides IPv6 addresses?

> As for mail, we already appear to have an /etc/mailname file for MTAs and 
> MUAs to use for finding out the 'canonical' name of the host for message-
> IDs and the like.

/etc/mailname doesn't seem to be specified by POSIX, so that I doubt
that all mail software uses it in practice (Mutt doesn't seem to use
it... its way to get the FQDN is currently buggy, but that's another
story).

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 01:47:40 +0100, Vincent Lefevre wrote:
> On 2009-12-29 00:21:45 +, Sam Morris wrote:
> > As for mail, we already appear to have an /etc/mailname file for MTAs and 
> > MUAs to use for finding out the 'canonical' name of the host for message-
> > IDs and the like.
> 
> /etc/mailname doesn't seem to be specified by POSIX, so that I doubt
> that all mail software uses it in practice (Mutt doesn't seem to use
> it... its way to get the FQDN is currently buggy, but that's another
> story).

BTW, the mailname(5) man page says:

The file contains only one line describing the fully qualified
   ^^^
domain name that the program wishing  to  get  the  mail  name
^^^
should use (that is, everything after the @).

So, that would define the FQDN of your machine, i.e. what
"hostname -f" should return.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-28 20:56:03 -0800, Steve Langasek wrote:
> On Tue, Dec 29, 2009 at 01:47:40AM +0100, Vincent Lefevre wrote:
> > > As for mail, we already appear to have an /etc/mailname file for MTAs and 
> > > MUAs to use for finding out the 'canonical' name of the host for message-
> > > IDs and the like.
> 
> > /etc/mailname doesn't seem to be specified by POSIX
> 
> Nope, it's specified in Debian policy (11.6).
> 
> > , so that I doubt that all mail software uses it in practice (Mutt doesn't
> > seem to use it...
> 
> That would be a bug, then.

Not all software is written for Debian. So, why?

Even if Debian has its own patches to match its policy, end users
are still allowed to compile software from upstream (this is what
I do for Mutt, because I have my own patches), and they expect
such software to work. So, if the admin of a Debian machine doesn't
configure a FQDN (so that the POSIX way to get it doesn't work)
just because there's a /etc/mailname already specifying the FQDN,
I won't be pleased.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

.desktop files of GNOME apps and path to these applications

[Vincent Lefevre]

Hi,

The .desktop file distributed with the evince package
(/usr/share/applications/evince.desktop) contains:

  Exec=evince %U

meaning that the user's $PATH is taken into account. In general,
taking $PATH into account is recommended, but IMHO, this should
not be the case here, because of the following points (related
to each other):

1. This .desktop file is a file associated with /usr/bin/evince
   (distributed in the same package...).

2. Taking the user's $PATH into account may have unexpected effects,
   such as running a different version of evince which may accept a
   different set of MIME types, or worse, running an evince program
   that has a completely different behavior: the user (who may be
   different from the administrator of the machine and may not know
   GNOME's evince) may have written a program called "evince" (FYI,
   this is a French word that means "oust") and installed it in his
   $HOME/bin directory.

3. In config files, $PATH is generally used when one doesn't know
   the location of the program, for flexibility, but this is not
   the case here (see point 1).

Here the choice of specifying an executable relative to $PATH should
only be a choice made by the user himself.

Other packages may be affected by the same problem.

Note that this is a followup to bug 488971:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488971

(With xulrunner-1.9-gnome-support, iceweasel announces e.g. xpdf,
but actually launches evince.)

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files of GNOME apps and path to these applications

[Vincent Lefevre]

On 2008-07-09 14:46:22 +0200, Vincent Zweije wrote:
> On Wed, Jul 09, 2008 at 01:14:25PM +0200, Vincent Lefevre wrote:
> ||  The .desktop file distributed with the evince package
> ||  (/usr/share/applications/evince.desktop) contains:
> ||
> ||Exec=evince %U
> ||
> ||  meaning that the user's $PATH is taken into account. In general,
> ||  taking $PATH into account is recommended, but IMHO, this should
> ||  not be the case here, because of the following points (related
> ||  to each other):
> ||
> ||  1. This .desktop file is a file associated with /usr/bin/evince
> || (distributed in the same package...).
> 
> NFS-mounted /home could be used on multiple computers, where the same
> (compatible) evince is installed at different locations.

You didn't read my mail. I'm talking about Debian's evince package,
for which evince is installed in /usr/bin. Also, the .desktop file
distributed with this package is not in /home, but in
/usr/share/applications/.

If the .desktop file is there to work also with other evince binaries
(installed elsewhere), then it shouldn't be distributed in the evince
package, but in a more general package for GNOME support. Indeed, if
the evince application is installed somewhere else and the user wants
to run this version, then he doesn't need the evince package.

> ||  3. In config files, $PATH is generally used when one doesn't know
> || the location of the program, for flexibility, but this is not
> || the case here (see point 1).
> 
> PATH is part of the environment. An eminent use of environment is to
> inform programs of precisely that: their environment, such as where
> other programs are to be found. Use it, that's what it's for.

Again you missed the point: it is useless here since the evince
provided by the evince package is in /usr/bin. If the user has an
evince installed somewhere else, see the above discussion.

> Not using PATH to locate programs would be an exception to this
> rule. You don't want exceptions, because it hampers the
> predictability of the system.

Depending on the environment makes the system less predictable.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Shouldn't tar 1.20-1 be in testing?

[Vincent Lefevre]

According to

  http://packages.qa.debian.org/t/tar.html

tar 1.20-1 entered unstable on 2008-04-17, so several months before the
freeze. And http://release.debian.org/migration/testing.pl?package=tar
gives no good reasons for which tar is not in testing yet:

  * trying to update tar from 1.19-3 to 1.20-1 (candidate is 109 days old)
  * tar is in freeze; contact debian-release if update is needed 

The first point isn't a reason at all. Concerning the second point,
tar 1.20-1 should have entered testing before the freeze.

If I understand correctly[*], tar 1.20-1 has been installed on every arch
since 2008-05-19.

[*] http://buildd.debian.org/pkg.cgi?pkg=tar

tar 1.20-1 contains an important addition: lzma support. And developers
are starting to use lzma-compressed tarballs instead of bzip2 (see e.g.
texinfo). Though there are workarounds, they have drawbacks, and it would
be quite annoying to have an obsolete version of tar in lenny.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#511522: general: Man pages should say what package a program belongs to

[Vincent Lefevre]

I'm not the bug reporter, but...

On 2009-01-11 20:21:59 +, Roger Leigh wrote:
> % dpkg -S /usr/bin/basename
> coreutils: /usr/bin/basename

This may be a bit more complex when the file is a symlink to an
alternative. Concerning the man pages, packages sometimes install
symlinks, and it isn't always easy to find what package installed
them, in particular when they became dangling symlinks due to some
bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 14:09:49 +0100, Jeremiah Foster wrote:
> On one of my machines apticron uses a call to hostname -f, which
> fails, while uname -n succeeds.

"uname -n" doesn't necessarily return the FQDN.

xvii% uname -n
xvii
xvii% hostname
xvii
xvii% hostname -f
xvii.vinc17.org
xvii% cat /etc/hostname 
xvii

Note in the hostname(1) man page:

  /etc/hostname This file should only contain the hostname and not the
  full FQDN.

> Perhaps it should be a bug to use hostname -f since it unreliable?

When the machine is correctly configured (i.e. really has a FQDN),
"hostname -f" is reliable. But note that this is Debian-specific.

FYI, here's how one can get the FQDN in Perl (gethostbyname is no
longer in POSIX, but it currently works in practice... or perhaps
"hostname" has something more reliable?):

#!/usr/bin/env perl

use strict;
use POSIX;

my $nodename = (POSIX::uname)[1];
print "Nodename: $nodename\n";
print "FQDN: ", (gethostbyname $nodename)[0], "\n";

(You would do the same thing in other languages: uname, then
gethostbyname.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 18:49:00 +0100, Gabor Gombas wrote:
> On Tue, Dec 29, 2009 at 02:52:44PM +0100, Vincent Lefevre wrote:
> > When the machine is correctly configured (i.e. really has a FQDN),
> > "hostname -f" is reliable.
> 
> No, it is not. "hostname -f" can return one value only, while a host may
> have dozens or hundreds of valid FQDNs.

Well, the node name is unique. From that, you'll obtain the FQDN with
either the obsolete function gethostbyname or the new POSIX function
getaddrinfo (by using the AI_CANONNAME flag). POSIX says:

  If the AI_CANONNAME flag is specified and the nodename argument is
  not null, the function shall attempt to determine the canonical name
  corresponding to nodename (for example, if nodename is an alias or
  shorthand notation for a complete name).

And here's what the getaddrinfo(3) man page says under Debian:

  If hints.ai_flags includes the AI_CANONNAME flag, then the ai_canonname
  field of the first of the addrinfo structures in the returned  list  is
  set to point to the official name of the host.

Then you need to configure your machine according to the spec, i.e.
you need a single FQDN / canonical name / official name of the host.

> Example: there is a router box called "gw" which has about a dozen
> addresses that resolve to "gw." for just as many domains. Some
> addresses even share the same NIC. Which FQDN should "hostname -f"
> display?

This doesn't really matter. The FQDN may also be another name, i.e.
the nodename may be something more meaningful than "gw".

But host names (like www.debian.org) can also resolve to several IP
addresses corresponding to different machines. So, make use that the
FQDN doesn't correspond to such a host name.

> Why that one, and not some other?

You should ask this question to those who configured such routers
(but this would be more a practical matter, as you may have plenty
of choices).

> I've submitted a patch for hostname (#562830) to add two new options:
> one that displays all IP addresses of the host, while the other displays
> all the FQDNs for those addresses.

A FQDN is not associated with an IP address, but with a host. You
cannot call them FQDN, which already has a well-established meaning.

If I understand correctly, you do a reverse DNS lookup. Now, I'm
wondering... Can a hostname obtained by reverse DNS lookup resolve
to different IP addresses?

> Neither relies on the value returned by gethostname(), so "the
> hostname must be an FQDN" misbelief together with any usage of
> "hostname -f" can die a silent death.

"hostname -f" just follows the POSIX notion of canonical name (a.k.a.
FQDN). So, I doubt it will die.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 17:44:31 +0100, Milan P. Stanic wrote:
> Mutt in testing/unstable use /etc/mailname.

But not the official Mutt version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 10:45:17 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > Even if Debian has its own patches to match its policy, end users are
> > still allowed to compile software from upstream (this is what I do for
> > Mutt, because I have my own patches), and they expect such software to
> > work.
> 
> If you expect the software you use to be properly integrated with the
> Debian system, you should use the Debian packages.  That's kind of the
> whole point of what we're all doing here.

When I compile Mutt or any other portable software (e.g. conforming to
POSIX), I don't mind if such software isn't integrated with the Debian
system. I just want it work according to the POSIX spec. If it doesn't
because the system configuration doesn't comply to POSIX, then the
system (configuration) is broken.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 14:18:47 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > When I compile Mutt or any other portable software (e.g. conforming to
> > POSIX), I don't mind if such software isn't integrated with the Debian
> > system. I just want it work according to the POSIX spec. If it doesn't
> > because the system configuration doesn't comply to POSIX, then the
> > system (configuration) is broken.
> 
> I don't think POSIX says what you think it says, but I could be wrong.
> Could you cite the exact section that says that systems are required by
> POSIX to be configured in the manner that you describe?

I haven't say anything about the configuration, just that POSIX says
that a system (locally identified by nodename) has a canonical name.

> getaddrinfo does not place such a restriction; AI_CANONNAME is
> allowed to fail.  Note the use of the word "attempt"

Yes, but a failure is something one can expect to happen under some
occasions, at least for remote hosts. This doesn't mean that hosts
don't have a canonical name, just that this canonical name couldn't
be determined.

For the local host, I would say that a failure is mostly due to a
configuration problem (unless a remote DNS is used, in which case
it may be down, and BTW, that's why I think it is a bad idea to use
one for something purely local). I'd say that making the request
fail on purpose is contrary to POSIX, and I find it not surprising
that software could fail to behave correctly because of that.

> and the note:
> 
> Since different implementations use different conceptual models, the
> terms ``canonical name'' and ``alias'' cannot be precisely defined for
> the general case. However, Domain Name System implementations are
> expected to interpret them as they are used in RFC 1034.
> 
> I don't believe there's any requirement anywhere in POSIX that the
> return value of uname -n be registered in DNS.

I haven't said that. And this is often not the case under Debian,
i.e. the FQDN is often obtained from /etc/hosts, which has the
precedence over DNS (see /etc/nsswitch.conf).

> In fact, the POSIX definition of the uname utility specifically
> says "the name of this node within an implementation-defined
> communications network." Implementation-defined means you cannot
> depend on it to be anything in particular without additional
> information about the implementation you're using.

This is implementation-defined, but still, the host has a canonical
name, that should be obtainable with getaddrinfo, as described.

BTW, Debian defines /etc/mailname as containing the FQDN. So,
this notion is explicitly defined on Debian, and one should
expect "hostname -f" to return the same name (according to its
documentation).

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-29 20:23:31 -0800, Russ Allbery wrote:
> I'm having a hard time figuring out what you think the canonical name of
> my laptop could possibly be, given that it has no static IP address and no
> DNS entry.

It doesn't need to have a static IP, nor a DNS entry.

> In practice, it's whatever arbitrary label that I gave it,

Yes, it may be arbitrary (the main goal being to identify the
machine).

> and none of these DNS-based resolution techniques are going to do
> you much good or give you any sort of consistent answer, if they
> work at all.

If it doesn't make sense (e.g., you can't connect to the machine
from the outside), they don't need to work... well, only locally,
but it has been said that 127.0.1.1 is typically used for that.

> I have no entry in /etc/hosts other than 127.0.0.1 and the corresponding
> IPv6 entries.  What could I possibly put in there?

As said by Steve Langasek in <2009122753.ga19...@dario.dodds.net>,
something of the form:

127.0.1.1 nodename.domainname

> > This is implementation-defined, but still, the host has a canonical
> > name, that should be obtainable with getaddrinfo, as described.
> 
> I don't see where you're finding any justification for that "should" in
> POSIX.

Otherwise this would be a failure, and failures are things that one
wants to avoid.

> > BTW, Debian defines /etc/mailname as containing the FQDN. So, this
> > notion is explicitly defined on Debian, and one should expect
> > "hostname -f" to return the same name (according to its
> > documentation).
> 
> No, it's not.  You have completely misunderstood the purpose of
> /etc/mailname.

No, this is what is documented. You should RTFM.

> If your package needs to know what hostname to use on (for example)
> outgoing news and mail messages which are generated locally, you
> should use the file /etc/mailname. It will contain the portion after
> the username and @ (at) sign for email addresses of users on the
> machine (followed by a newline).
> 
> So on my system, for instance, /etc/mailname is "stanford.edu,"
> because that's what goes on the RHS of e-mail addresses. Which, of
> course, is not the canonical name of my laptop.

"stanford.edu" is definitely wrong. First it's just a domain name, not
a FQDN (as required by the mailname(5) man page). This would meen that
two different machines could generate the same Message-Id; the right
part of "@" in a Message-Id should contain the hostname to avoid this
kind of problems. Moreover, concerning the e-mail addresses, root is
local to the machine, so that generating a mail from r...@stanford.edu
is incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-30 11:56:13 +0100, Gabor Gombas wrote:
> On Tue, Dec 29, 2009 at 10:31:25PM +0100, Vincent Lefevre wrote:
> > Then you need to configure your machine according to the spec, i.e.
> > you need a single FQDN / canonical name / official name of the host.
> 
> If getaddrinfo(AI_CANONNAME) fails, that is fully conformant with the
> spec you have quoted.

But that's a ***FAILURE***. Don't assume that things will work
perfectly in such a case.

> > > Example: there is a router box called "gw" which has about a dozen
> > > addresses that resolve to "gw." for just as many domains. Some
> > > addresses even share the same NIC. Which FQDN should "hostname -f"
> > > display?
> > 
> > This doesn't really matter. The FQDN may also be another name, i.e.
> > the nodename may be something more meaningful than "gw".
> 
> But it is not. This is a real world example. Reality does not match
> your dream world.

Could you please read again what I've written? I've said *may*.
"gw" is fine too, if you really want. No theoratical problem with
that.

> > You should ask this question to those who configured such routers
> > (but this would be more a practical matter, as you may have plenty
> > of choices).
> 
> _I_ did configure it. I _know_ that none of the addresses is more
> important than the other.

So what?

> And you know, if you do not pretend such silly things that a host should
> have just a single FQDN or that "hostname -f" should return anything
> meaningful, then the above configuration works flawlessly. Only if you
> start to pretend things that are simply not true you start having
> problems.

I'm not pretending, this is how it is. RTFM.

> > A FQDN is not associated with an IP address, but with a host. You
> > cannot call them FQDN, which already has a well-established meaning.
> 
> Now this is bullshit. FQDN is a term related to DNS.

Wrong. /etc/hosts (which is commonly used for the FQDN) has nothing to
do with DNS.

> An FQDN resolves to a set of resource records, which may be IPv4 or
> IPv6 addresses and a couple of other things, but definitely _NOT_
> hosts, as that term has no meaning for the DNS.

I've never said that a FQDN resolves to hosts.

> If the FQDN resolves to multiple IP addresses, then the very same FQDN
> can belong to multiple hosts simultaneously.

I'd say that's an incorrect configuration. Several mechanisms may fail
in such a case (e.g. Message-Id generation).

> Similarly, if a host has multiple IP addresses, then multiple FQDNs
> may point to it. You can even mix these:
> 
> - host1 has addresses 192.168.1.1 and 192.168.2.1
> - host2 has addresses 192.168.1.2 and 192.168.2.2
> - the DNS has the following records:
> 
>   service1.domain.IN  A   192.168.1.1
>   IN  A   192.168.1.2
>   service2.domain.IN  A   192.168.2.1
>   IN  A   192.168.2.2

One often uses CNAME for services, or the FQDN may be a bit more
hidden. For instance:

$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.227.106
www.l.google.com has address 209.85.227.147
www.l.google.com has address 209.85.227.99
www.l.google.com has address 209.85.227.103
www.l.google.com has address 209.85.227.104
www.l.google.com has address 209.85.227.105
$ host 209.85.227.106
106.227.85.209.in-addr.arpa domain name pointer wy-in-f106.1e100.net.
$ host 209.85.227.147
147.227.85.209.in-addr.arpa domain name pointer wy-in-f147.1e100.net.

and so on. (I'm not saying that wy-in-f106.1e100.net,
wy-in-f147.1e100.net and so on are the FQDN's of these hosts,
but this is probably the case.)

In your example, host1.domain and host2.domain could be the respective
FQDN's of these hosts, that could resolve as 127.0.1.1 locally on each
machine.

> > If I understand correctly, you do a reverse DNS lookup. Now, I'm
> > wondering... Can a hostname obtained by reverse DNS lookup resolve
> > to different IP addresses?
> 
> Of course it can.

So, this would mean that your new option --all-fqdns would lie,
as it could give IP's belonging to other machines.

> > "hostname -f" just follows the POSIX notion of canonical name (a.k.a.
> > FQDN). So, I doubt it will die.
> 
> Please quote the exact text from POSIX that says that
> 
> - there MUST be a canonical name,
> - and that name MUST be an FQDN.

For instance, under getnameinfo():

  The flags argument is a flag that changes the default actions of the
  function. By default the fully-qualified domain name (FQDN) for the
  host shall be returned, but:

This mean

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-30 15:31:12 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 29 Dec 2009, Vincent Lefevre wrote:
> > On 2009-12-29 17:44:31 +0100, Milan P. Stanic wrote:
> > > Mutt in testing/unstable use /etc/mailname.
> > 
> > But not the official Mutt version.
> 
> Who lets you configure the correct domain you want it to use for email
> addresses in its config files, although I don't recall if you can tell it
> what to use for message-ids.

Yes, that's what I had to do after reporting Mutt bug 3298 (Mutt has
its own buggy way to determine the FQDN: it uses /etc/resolv.conf
while /etc/hosts may have the precedence).

> Debian mutt will autoconfigure better, but that's it.
> 
> That said, the canonical name is required by POSIX, but POSIX (looking at
> SuSv3) doesn't require it to be unique, doesn't give it any application
> usage notes, and in fact doesn't even require it to be a FQDN (which is, in
> fact a pratical requirement of the stuff that uses the canonical name).

POSIX says:

  If the AI_CANONNAME flag is specified and the nodename argument is
  not null, the function shall attempt to determine the canonical name
  corresponding to nodename (for example, if nodename is an alias or
  shorthand notation for a complete name).
  ^^

So, it isn't intended to be a short name. As this is mostly
implementation defined, it may be difficult to be very accurate.

Also, otherwise, what would be the point of having a "canonical name"
in addition to a node name if there isn't any requirement?

> If you want proper message-ids, do it right and have a GUUID in it.

Perhaps, hoping that Message-Ids wouldn't be too long (I've seen
broken messages due to Message-Ids generated by Pine, related to
word-wrapping IIRC).

> If mutt depends on the result of gethostname() to be unique in the
> whole world to generate proper message-ids, it is broken.

Actually, there's a low probability of duplicates (but practically
possible) if many people use a broken FQDN such as "localhost".

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-30 11:54:57 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > "stanford.edu" is definitely wrong. First it's just a domain name, not a
> > FQDN (as required by the mailname(5) man page).
> 
> stanford.edu is an RFC 1035 FQDN.

RFC 1035 (from /usr/share/doc/RFC/links/rfc1035.txt.gz) doesn't define
what a FQDN is. It doesn't contain "FQDN", and the only occurrence of
"fully" and "qualified" is in "Gateways will also have host level
pointers at their fully qualified addresses.

FYI, here's what Wikipedia[*] (though not authoritative and sometimes
containing errors) says:

  For example, given a device with a local hostname myhost and a
  parent domain name example.com, the fully qualified domain name is
  written as myhost.example.com. This fully qualified domain name
  therefore uniquely identifies the host — while there may be many
  resources in the world called myhost, there is only one
  myhost.example.com.

[*] http://en.wikipedia.org/wiki/Fully_qualified_domain_name

> > This would meen that two different machines could generate the same
> > Message-Id; the right part of "@" in a Message-Id should contain the
> > hostname to avoid this kind of problems.
> 
> The term "message ID" appears nowhere in the description of /etc/mailname.
> Why do you think it's supposed to be used for generating message IDs?

Earlier in the discussion:

  "Anything mail related must use /etc/mailname if it needs something
   ^
  that can be translated to an IP address."

> It is specifically intended for generating e-mail addresses.

In such a case, "hostname -f" (or equivalent) is still useful to
generate message-ids. And the Debian mailname(5) man page doesn't
say e-mail addresses specifically.

> > Moreover, concerning the e-mail addresses, root is local to the machine,
> > so that generating a mail from r...@stanford.edu is incorrect.
> 
> You do not know either that root is local to my system or that
> r...@stanford.edu is incorrect for it.  Both of those are configuration
> *choices*, not requirements.

But r...@stanford.edu wouldn't be the same root. Perhaps the Debian
mailname(5) man page should make clear what is intended for local
users and use consistent terminology.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-30 15:33:05 -0200, Henrique de Moraes Holschuh wrote:
> Better correct myself here.  POSIX provides a way for apps to query the
> canonical host name, but DOES NOT REQUIRE IT TO BE A FQDN.
> 
> So, it provided the notion of a "special name", the canonical host name.
> 
> In practice, it has to be a FQDN, but that's due to bad usage by
> applications, not a POSIX (or SuSv3) requirement.

One problem is that it seems to be the only way to get the FQDN
of the host. FYI, I use the FQDN as a way to identify the hosts
(and a FQDN is more meaningful and probably more stable than an
arbitrary UUID).

But I don't know any software that tries to resolve the FQDN,
except broken MTAs that reject mail if they can't resolve the
FQDN, despite the fact that the client is on a private network.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-31 14:10:46 +0100, Mike Hommey wrote:
> On Thu, Dec 31, 2009 at 02:02:36PM +0100, Vincent Lefevre wrote:
> > POSIX says:
> > 
> >   If the AI_CANONNAME flag is specified and the nodename argument is
> >   not null, the function shall attempt to determine the canonical name
> >   corresponding to nodename (for example, if nodename is an alias or
> >   shorthand notation for a complete name).
> >   ^^
> > 
> > So, it isn't intended to be a short name. As this is mostly
> > implementation defined, it may be difficult to be very accurate.
> 
> Where does the above say it must be a FQDN ? It says that *for example*,
> *if* nodename is blah blah. So, what if the nodename is *not* that ?
> (which it is not on a lot of hosts)

If it is not that, it is the complete name. But since it is
implementation-defined, which Debian's document defines the
canonical name?

Do you suggest that getnameinfo() be used to get the FQDN?

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-31 16:35:58 +0100, Iustin Pop wrote:
> This is a personal opinion, but having the canonical name rely on
> “hostname --fqdn” is not a favorite of mine: hostname needs the resolver
> to be working and functioning (e.g. it talks to your nameservers if
> /etc/hosts doesn't contain your hostname/ip already).

Well, the practice, the FQDN is often available via /etc/hosts.

> IMHVO, this is a brittle setup and the FQDN should be available directly
> on the host, without external dependencies. Which is why I personally
> think the machine name (the one that the kernel knows) should hold the
> canonical name.

Either that, or having the FQDN in /etc/hosts. I don't see any problem
with that, excepts that iceweasel doesn't cope very well with this:

lrwxrwxrwx 1 vinc17 vinc17 15 2009-12-30 05:35:38 lock -> 127.0.1.1:+5537

I wonder why it doesn't use the FQDN. The IP addresse 127.0.1.1 is
incorrect when the directory is shared with other hosts.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-31 12:37:25 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > On 2009-12-30 11:54:57 -0800, Russ Allbery wrote:
> >> Vincent Lefevre  writes:
> 
> >>> "stanford.edu" is definitely wrong. First it's just a domain name, not a
> >>> FQDN (as required by the mailname(5) man page).
> 
> >> stanford.edu is an RFC 1035 FQDN.
> 
> > RFC 1035 (from /usr/share/doc/RFC/links/rfc1035.txt.gz) doesn't define
> > what a FQDN is. It doesn't contain "FQDN", and the only occurrence of
> > "fully" and "qualified" is in "Gateways will also have host level
> > pointers at their fully qualified addresses.
> 
> However, the other standards that do talk about FQDNs refer to RFC 1035
> for the definition.  See, for instance, RFC 5322.

RFC 5322 doesn't mention "FQDN", "fully" or "qualified" either!
Perhaps you meant RFC 5321, which uses "FQDN" with a different
meaning, and uses "primary host name" for what is a FQDN here.
RFC 5321 also says "In the EHLO command, the host sending the
command identifies itself", implying that what you give after EHLO
must be unique (otherwise that's no longer an identification).

> > FYI, here's what Wikipedia[*] (though not authoritative and sometimes
> > containing errors) says:
> 
> >   For example, given a device with a local hostname myhost and a
> >   parent domain name example.com, the fully qualified domain name is
> >   written as myhost.example.com. This fully qualified domain name
> >   therefore uniquely identifies the host — while there may be many
> >   resources in the world called myhost, there is only one
> >   myhost.example.com.
> 
> You're right, that's not authoritative and, in this case, is misleading.
> Nothing about an FDQN implies uniqueness.  Wikipedia is trying to get at
> the distinction between an unqualified name, which could duplicate many
> other unqualified names in other domains, and a fully-qualified name which
> has a single location in the DNS hierarchy.  However, an FQDN, despite
> living in one place in the DNS hierarchy, may refer to multiple separate
> systems (as it does for stanford.edu, time.stanford.edu, etc., all of
> which are FQDNs).

No, they are not FQDNs of the corresponding hosts. For instance,
time.stanford.edu resolves to 3 IP addresses (3 hosts, I suppose):

time.stanford.edu has address 171.64.7.105
time.stanford.edu has address 171.64.7.67
time.stanford.edu has address 204.63.224.70

xvii% host 171.64.7.105
105.7.64.171.in-addr.arpa domain name pointer time-a.Stanford.EDU.
xvii% host 171.64.7.67
67.7.64.171.in-addr.arpa domain name pointer time-b.Stanford.EDU.
xvii% host 204.63.224.70
70.224.63.204.in-addr.arpa domain name pointer time-c.Stanford.EDU.

The respective FQDN's of these hosts seem to be time-a.Stanford.EDU,
time-b.Stanford.EDU and time-c.Stanford.EDU, and they are unique:
they all resolve to a *single* IP address.

xvii% host time-a.Stanford.EDU
time-a.Stanford.EDU has address 171.64.7.105
xvii% host time-b.Stanford.EDU
time-b.Stanford.EDU has address 171.64.7.67
xvii% host time-c.Stanford.EDU
time-c.Stanford.EDU has address 204.63.224.70

Note: this is a heuristic only; the only way to be sure that they
are the FQDN's of the host (as returned by "hostname -f") is to
test on the machines themselves.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: where is /etc/hosts supposed to come from?

[Vincent Lefevre]

On 2009-12-31 14:34:34 -0800, Russ Allbery wrote:
> Uh, no.  That statement implies nothing of the sort; identification is not
> necessarily unique.

I suggest that you look in a dictionary.

> I've been participating in standardization of network protocols through
> the IETF for more than a decade now, and I've never seen someone use this
> definition of FQDN that you're using.  I'm quite confident that this is
> not the intented interpretation of the standards to which you're
> referring, in large part because I was participating in the mailing lists
> on which they were written.

This is not only me. "hostname -f" uses the same definition.

There's also the open problem of what "canonical name" means under
Debian / Linux. Some software also assumes the unicity of the FQDN
(under the "hostname -f" definition), and even the nodename (e.g.
that's procmail when storing mail in a Maildir mailbox).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-02-27 21:03:04 +0100, Josselin Mouette wrote:
> We are talking of programs that you will not have the idea to run with
> the command line unless you know what they do. Programs that are usually
> run through a graphical menu.

They are sometimes found by shell completion. Moreover, before creating
a shell alias or add a new program to my ~/bin, I run "which" first to
see if I'll override something, and if a program with the same name
already exists, I want to know what it does.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100228105321.ga13...@prunille.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-04 17:12:15 +0100, Bill Allombert wrote:
> On Thu, Mar 04, 2010 at 04:32:45PM +0100, Josselin Mouette wrote:
> > Because, of course, the user is too stupid to click the “Help” menu
> > inside the application.
> 
> Because the users have not yet decided if they want to start the application
> and they look to the manpage for guidance.

Yes, and for various reasons, it may happen that the application
doesn't start (e.g. due to incorrect environment), and the user
cannot look at the help from the menu to see what's wrong.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100305083004.ga13...@prunille.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-05 17:41:25 +, brian m. carlson wrote:
> Allowing "any format viewable in Debian" potentially requires the
> average user to install lots of random packages just to view basic
> documentation on invoking a program.  Also, providing, for example, PDF
> documentation as the sole form for a command line program is not
> particularly useful for a machine that doesn't have X installed.

Or accessed via ssh with a slow connection (I use that a lot).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100306001150.gb13...@prunille.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-05 11:04:48 +0100, Josselin Mouette wrote:
> Command-line switches are documented where you expect them to be
> documented: in command-line switches, with the standard --help option.

This is nonsense. Not all commands understand --help.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100306002127.gc13...@prunille.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-05 10:56:21 +0100, Daniel Leidert wrote:
> Of course it does not happen, that evolution crashes for specific
> mails and then keeps crashing on every new start, because it opens the
> same mail. The only way to fix this, is to start with a different
> component. Do you need the bug report #? So how do you access the
> help menu to get the switches?
> 
> JFTR: Yes, we are using the same distribution.

Another example:

xvii:~> gnucash
gnc.bin-Message: main: binreloc relocation support was disabled at configure 
time.

zsh: exit 1 gnucash

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100306002709.gd13...@prunille.vinc17.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Lefevre]

On 2010-03-10 13:52:15 +0100, Wouter Verhelst wrote:
> Or it might have a gzipped PDF file, which is even more annoying,
> for it requires me to copy, uncompress, read, remove the
> documentation.

zxpdf from xpdf-reader can handle it. But I wonder why the need for
two separate commands while the format can easily be detected.
I don't know how other PDF viewers handle compressed PDF files.

For the other points, I completely agree with you.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100310162854.ga23...@prunille.vinc17.org

Re: PDF is blocked for printing, etc. OK for acroread (it behaves as expected), but KPDF allows me to print it, even if it is protected! Why?

[Vincent Lefevre]

On 2010-04-19 18:05:30 -0500, Gunnar Wolf wrote:
> The reasons not to want a document printed are quite easy to
> understand, but the mechanism is flawed. Given the setting you
> mention, you can just slap a red banner stating "Confidential, do not
> print". If it is on a corporate setting, just state it as a policy -
> and if somebody fails to comply with the policy, there should be
> sanctions.

One sometimes tries to print PDF without reading them first. This
is not with a PDF viewer, more with a printing utility such as lpr,
though. At least such utilities should honor the printable flag (in
order to protect the *user* from doing something potentially bad),
overridable by an option.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100420101626.gb22...@prunille.vinc17.org

Re: RFH: bashisms in configure script

[Vincent Lefevre]

On 2010-05-26 00:18:23 +0200, David Weinehall wrote:
> You're getting things the wrong way around.  The version of dash that
> will be put in experimental will be the correct one, the one in unstable
> will be the crippled one.  The reason things fails isn't because of
> dash, but because of sloppy programming on behalf of people that still
> believe that bash is the say all and end all when it comes to shell
> scripts.

The problem is not programmers, but the system. It is well-known that
programmers make mistakes (FYI, == also comes from C/csh so that it is
easy to be wrong), and testing allows one to discover such mistakes.
But for that, one needs a POSIX-compliant /bin/sh with no extensions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529123206.ga15...@prunille.vinc17.org

Re: [RFC] removing xserver-xorg-video-nv from squeeze

[Vincent Lefevre]

On 2010-07-12 19:33:15 +0100, Julien Cristau wrote:
> We don't have nvidia hardware, so maybe our perception is flawed.  If
> people think we should keep that driver, please explain why.  If the
> reason is "nouveau doesn't work for me", we'll ignore your reply unless
> it comes with a bugs.freedesktop.org (or bugs.debian.org, if the bug is
> fixed in experimental but not in squeeze) bug number.

nouveau doesn't work for me and I've reported the bug two months ago:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581830
  https://bugs.freedesktop.org/show_bug.cgi?id=28140

No feedback from the developers. :(

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100721080434.ga1...@prunille.vinc17.org

Re: 38

[Vincent Lefevre]

On 2010-08-28 20:54:42 +1000, Brian May wrote:
> When the solution is easy I don't see why we don't just do it.
> 
> br...@andean:~$ i="cat's meow.tar.gz"
> br...@andean:~$ echo "`basename "$i" .tar.gz`"
> cat's meow
> 
> (yes, the nested quotes don't seem to matter)

They matter if you have consecutive spaces, for instance.
And this is not sufficient:

xvii:~> i="--foo  bar.tar.gz"
xvii:~> echo "`basename "$i" .tar.gz`"
basename: invalid option -- '-'
Try `basename --help' for more information.

You need:

xvii:~> echo "`basename -- "$i" .tar.gz`"
--foo  bar

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831082331.gb26...@prunille.vinc17.org

Re: there is /usr/lib64 symlink but no /usr/local/lib64

[Vincent Lefevre]

On 2011-02-04 19:02:33 +0100, Tollef Fog Heen wrote:
> ]] Yaroslav Halchenko 
> | /usr/lib64 -> /usr/lib
> 
> Not really, apart from some broken software  that will look for stuff
> there and be confused if it doesn't exist.  I think we should drop it.

Thanks would be a good thing. Otherwise users should either avoid
upstream GCC's or add similar symbolic links for every directory
(e.g. $HOME/lib64 -> $HOME/lib if the user installs software in
his home directory). FYI, here's the problem I had under Debian
because of this symbolic link:

  http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
  (and followups)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211125238.gg15...@prunille.vinc17.org

Re: Make Unicode bugs release critical?

[Vincent Lefevre]

On 2011-02-11 21:46:29 +0900, Norbert Preining wrote:
> On Fr, 11 Feb 2011, Roger Leigh wrote:
> > XeTeX and XeLaTeX allow native UTF-8 input.  Should be made the
> > default, IMO, given how obsolete and broken the "standard" TeX
> > encodings are.  Being able to write in actual text rather than
> 
> Please don't write rubbish if you don't know what you are talking about!!!
> 
> You have apparently no idea between input and font encoding.
> 
> LaTeX can easily useutf8 with the appropriate inputenc,

Which one???

FYI, utf8 is very incomplete and utf8x is broken (bug 601365).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211131843.gh15...@prunille.vinc17.org

Re: Make Unicode bugs release critical?

[Vincent Lefevre]

On 2011-02-11 15:33:49 +0500, Andrey Rahmatullin wrote:
> On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote:
> > > However, I'm curious: is there a lot of software that is broken with
> > > Unicode, particularly with the UTF-8 encoding? I can't remember anything
> > > much in recent times.
> > Mostly it is just the old stuff like
> >  - eterm, aterm
> >  - elvis
> >  - X tools from the basic package (xman, xmessage, xmore, ...)
> >  - TeX without additional packages
> - tr(1)

"less" has problems with new Unicode characters (bug 597918).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211133024.gi15...@prunille.vinc17.org

Re: Make Unicode bugs release critical?

[Vincent Lefevre]

On 2011-02-11 15:02:02 +0100, Adam Borowski wrote:
> On Fri, Feb 11, 2011 at 02:30:24PM +0100, Vincent Lefevre wrote:
> > On 2011-02-11 15:33:49 +0500, Andrey Rahmatullin wrote:
> > > On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote:
> > > > > However, I'm curious: is there a lot of software that is broken with
> > > > > Unicode, particularly with the UTF-8 encoding? I can't remember 
> > > > > anything
> > > > > much in recent times.
> > 
> > "less" has problems with new Unicode characters (bug 597918).
> 
> Unicode 6.0 came out in october 2010,

The character mentioned in my bug report (U+1E9F LATIN SMALL LETTER DELTA)
appeared in Unicode 5.1.0 (March 2008).

> well after Squeeze's freeze, so you can't expect support for new
> characters already.

Well, March 2008 was more than 1 year before Squeeze's freeze.

> There are in no fonts shipped with squeeze, so not recognizing the
> characters as valid is not a big problem.

Fonts containing the character in question are shipped with Squeeze:
the character appears correctly in xterm.

> Less shouldn't maintain a private copy of character properties if
> all that data is already present in libc

I agree.

> -- but guess what, wcwidth(0x1F4A9) and iswprint() don't know them
> too.

No problems with U+1E9F:

Property alnum : yes
Property alpha : yes
Property cntrl : no
Property digit : no
Property graph : yes
Property lower : yes
Property print : yes
Property punct : no
Property space : no
Property upper : no
Property xdigit: no
wcwidth = 1

So, if "less" were using libc, it wouldn't have any problem with
this character.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110211143511.gj15...@prunille.vinc17.org

Re: there is /usr/lib64 symlink but no /usr/local/lib64

[Vincent Lefevre]

On 2011-02-12 17:44:27 -0800, Steve Langasek wrote:
> How do we square that with the FHS, then?  The FHS says:
> 
>   If directories /lib or /usr/lib exist, the equivalent
>   directories must also exist in /usr/local.
> 
> That seems to require /usr/local/lib64 even if we *don't* include
> /usr/lib64, right?  Should we amend policy to take this exception to the
> FHS?  Please open a bug report on policy if you think we should.

What's important is consistency. The tools under Debian don't expect
libraries to be in **/lib64, but in **/lib.

> /me goes back to making lib64 obsolete ;)

Yes! :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215233512.gk15...@prunille.vinc17.org

Re: OT: Python (was: Make Unicode bugs release critical?)

[Vincent Lefevre]

On 2011-02-14 16:43:11 +, Ian Jackson wrote:
> When LC_CTYPE=en_GB.utf-8, programs which attempt to print unicode
> characters to stdout should use UTF-8.  That's what LC_TYPE means.

So, "cat", "grep", etc. are all broken. :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110216000107.gl15...@prunille.vinc17.org

Re: OT: Python

[Vincent Lefevre]

On 2011-02-14 13:11:04 -0800, Russ Allbery wrote:
> Perl is specifically documented to not do this for backward compatibility
> reasons.  In Perl, which is the one I know best, you are required to
> decode input and encode output if you want to have UTF-8 handling.

Or better, use the -C option.

perl -C -e 'print "\x{00a3}\n"'

will "work" under both UTF-8 and ISO-8859-1. Or you can force UTF-8 with:

perl -CSD -e 'print "\x{00a3}\n"'

You can also do that globally with the PERL_UNICODE environment variable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110216000924.gm15...@prunille.vinc17.org

Re: OT: Python (was: Make Unicode bugs release critical?)

[Vincent Lefevre]

On 2011-02-16 01:34:51 +0100, Adam Borowski wrote:
> On Wed, Feb 16, 2011 at 01:01:07AM +0100, Vincent Lefevre wrote:
> > On 2011-02-14 16:43:11 +, Ian Jackson wrote:
> > > When LC_CTYPE=en_GB.utf-8, programs which attempt to print unicode
> > > characters to stdout should use UTF-8.  That's what LC_TYPE means.
> > 
> > So, "cat", "grep", etc. are all broken. :)
> 
> How come?
> 
> "cat" will, for any valid UTF-8 character on input, print a valid UTF-8
> character on output.  For any valid ISO-8859-1 character on input, it will
> print a valid ISO-8859-1 character on output.

I was just commenting what Ian said. If there is a valid reason for
which "cat" may not produce UTF-8 in UTF-8 locales, this is also
true for "perl" or any other software.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110216004529.gn15...@prunille.vinc17.org

Bug#221988 (makeinfo --xml outputs non-well-formed XML) and my patch

[Vincent Lefevre]

I submitted a patch for the bug #221988. Does anyone know when it
will be considered? If this bug could be fixed in the Sarge release
(I don't know if this is possible), this would really be fine.

Thanks,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Vincent Lefevre]

On 2009-05-09 22:20:47 -0700, Steve Langasek wrote:
> According to popcon, only about 68% of Debian users have exim4
> installed, and 18% have postfix installed. I don't think that's much
> of a lead for exim4, considering most of the exim4 installs are
> probably due solely to its status as a default.

If you want a user point of view, I have exim4 on my Debian machines
because this is the default (at that time I didn't even know that
postfix existed) and I have postfix on my Mac OS X machine because
this is the default there.

I had to do some simple changes in the configuration for both, without
reading the *whole* documentation. And I found that much easier with
postfix.

I find exim4's config files rather obfuscated, and the relation between
"source" files and generated files is not clear; some config files are
not always taken into account because another one can override them
(things may have improved since, see bug 446367 for an example), user
changes are sometimes discarded by an upgrade, and so on... I don't
know how the postfix configuration is under Debian, though.

BTW, concerning the Bcc header, exim4 breaks the sendmail compatibility
whereas postfix is OK, IIRC.

I think that for my next Debian machine, I'll choose postfix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: HTTPS everywhere!

[Vincent Lefevre]

On 2014-06-17 13:20:59 +0100, Simon McVittie wrote:
> It should be possible to make a CA certificate that is only considered
> to be valid for the spi-inc.org and debian.org subtrees, and then trust
> the assertion that SPI control that certificate - but in widely-used
> applications, that isn't possible. If SPI can sign certificates for
> debian.org, then they can also sign certificates for my bank, and my
> browser will think those are just as valid.

I agree. However I don't think that the particular case of a
Debian Root CA would be a problem, since you must absolutely
trust it. If something bad happens at this level, this would
mean that downloaded packages from debian.org may actually
be compromised ones, and in such a case, your whose machine
should be regarded as compromised.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140618130058.ga17...@ypig.lip.ens-lyon.fr

Re: HTTPS everywhere!

[Vincent Lefevre]

On 2014-06-18 14:20:10 +1000, Russell Stuart wrote:
> So you need X.509 PKI (even with all its flaws) during that first
> contact.  But after you've sent them money or downloaded their software
> you have formed a trust relationship with whoever controls that cert far
> stronger than the assurances X.509 provides.  That is true in the
> positive sense if you receive your goods after paying, or the software
> you downloaded works well, or in the negative sense if the reverse
> happens.  Regardless, next time you deal with the entity that controls
> the www.shop.com cert, you now know far more about them than the X.509
> PKI does.
> 
> The bug is the current system forces you to reply on X.509 for all
> future contacts, even though you have much better source of trust.
> During that initial contact the protocol could have arranged for you to
> download a cert signed by the owners of shop.com themselves, so you
> could reply on it in the future instead of X.509.  Suddenly all X.509
> issues, like MITM attacks, disappear.

Well, since the Heartbleed bug, I wouldn't say that: the old private
key could have been compromised for whatever reason. At least you
need some 3rd party to check certificate revocation. But if it is
malicious, it could tell you that the certificate has been revoked
(even if it isn't), and you have the same problem as now... well,
almost. At least you can know that something has happened and you
can investigate.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140618132956.gb10...@ypig.lip.ens-lyon.fr

copyright file and non-secure URL's

[Vincent Lefevre]

The Debian Policy Manual on

  https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

says:

  12.5 Copyright information

  [...]

  In addition, the copyright file must say where the upstream sources
  (if any) were obtained, and should name the original authors.

But I wonder whether it is a good idea to promote only non-secure URL's
to the source (at least if there are no associated signtures), as some
packages do. One may also wonder whether the package maintainer has
used such a URL to download upstream's source. For instance, for libc6,
/usr/share/doc/libc6/copyright contains:


It was put together by the GNU Libc Maintainers 
from 


-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140618141019.ga21...@ypig.lip.ens-lyon.fr

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-13 13:17:24 +0200, Arno Töll wrote:
> Unfortunately it turns out, that /a lot/ of people use "aptitude
> --purge-unused safe-upgrade", or the apt equivalent "apt-get
> dist-upgrade --purge" which causes dpkg to purge the user's
> configuration, in particular enabled modules, during the upgrade
> because apache2.2-common disappears in that step. [...]

Is there any reason why apt-get/aptitude removes the config files
just after the package is removed, and not at the end of the upgrade
process? IMHO, doing the later is safer and would solve this problem
with Apache.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716094125.gb6...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-14 08:53:22 +, Thorsten Glaser wrote:
> But I normally use "apt-get --purge dist-upgrade" both to upgrade
> across distros and to stay within one distro (or sid), because
> otherwise I get issues:
> 
> * Running upgrade before dist-upgrade sometimes doesn't get the
>   dependencies right
> 
> * Running dist-upgrade without --purge will keep packages in 'rc'
>   state around, which a later APT call will not even recognise;
>   you need to manually "dpkg --purge pkg1 pkg2 ..." to get rid
>   of them

I do that too. I haven't seen any official documentation saying that
this is a bad thing to do.

Purging packages in 'rc' state later is not really an option, as I
sometimes want to keep the config files of some particular packages
that have been removed... unless APT can differentiate packages that
have manually been removed and those that have automatically been
removed during a dist-upgrade.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716093631.ga6...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-16 13:46:12 +0200, Guillem Jover wrote:
> On Wed, 2014-07-16 at 11:41:25 +0200, Vincent Lefevre wrote:
> > On 2014-07-13 13:17:24 +0200, Arno Töll wrote:
> > > Unfortunately it turns out, that /a lot/ of people use "aptitude
> > > --purge-unused safe-upgrade", or the apt equivalent "apt-get
> > > dist-upgrade --purge" which causes dpkg to purge the user's
> > > configuration, in particular enabled modules, during the upgrade
> > > because apache2.2-common disappears in that step. [...]
> > 
> > Is there any reason why apt-get/aptitude removes the config files
> > just after the package is removed, and not at the end of the upgrade
> > process? IMHO, doing the later is safer and would solve this problem
> > with Apache.
> 
> It just calls dpkg with --purge.

But what I meant is that it could do 2 passes: one without --purge,
and a second one with --purge on the removed packages. Or...

> Something that would also fix this issue (among other upgrade
> problems) is using dpkg “transactions”:
> 
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579790#82>

Yes!

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140717010710.ga26...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote:
> On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote:
> > I do that too. I haven't seen any official documentation saying that
> > this is a bad thing to do.
> 
> aptitude actively warns against it as highlighted in this thread.

Wrong! I purge removed packages almost all the time with aptitude,
and I've never seen any warning!

> Official documentation also doesn't say that running 'rm -rf
> --no-preserve-root /' is a bad thing,

Silly comparison. 'rm -rf --no-preserve-root /' does what it does:
remove everything. When I purge packages, I just expect config
files to be purged, not break the system!

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140717011735.gb26...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-17 03:21:28 +0200, Christian Hofstaedtler wrote:
> * Arno Töll  [140713 13:25]:
> > * Ignore the problem, and refer to the manpage of aptitude without
> > proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
> > NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING". The bad news is, we
> > can't tell this before it's too late, such as in a NEWS file - and we
> > know, everybody reads release notes too, right?
>  
> I'm expressing support for this, and/or your second option.
> Any non-trivial setup will need config changes anyway, and any sane
> person already uses version control for /etc + config management for
> such setups.

Actually the problem is not the data loss. The problem is the upgrade
failure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140717020211.gc26...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-17 15:44:18 +0200, Arno Töll wrote:
> On 17.07.2014 15:38, Christian Hofstaedtler wrote:
> > My understanding was that the new apache binaries would install new
> > config files, and it would then work? (With the correct
> > replaces/breaks/...)
> 
> Yes. However, Apache has a notable number of configuration files (not
> conffiles), namely symlinks from, e.g. mods-enabled to mods-available,
> resulting in the working configuration users would like to have.
> 
> These are being lost if and only if people use --purge during an upgrade
> as for today, and perhaps for the release unless I use either
> alternative highlighted initially.

Yes, and a consequence of this loss is that dpkg fails.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721185838.ga18...@xvii.vinc17.org

aptitude / package purged

[Vincent Lefevre]

On 2014-07-18 00:32:25 +0300, Andrei POPESCU wrote:
> On Jo, 17 iul 14, 03:17:35, Vincent Lefevre wrote:
> > On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote:
> > > On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote:
> > > > I do that too. I haven't seen any official documentation saying that
> > > > this is a bad thing to do.
> > > 
> > > aptitude actively warns against it as highlighted in this thread.
> > 
> > Wrong! I purge removed packages almost all the time with aptitude,
> > and I've never seen any warning!
> 
> From aptitude(8)
> 
>--purge-unused
>If Aptitude::Delete-Unused is set to “true” (its default), then 
>in addition to removing each package that is no longer required a  
>  
>by any installed package, aptitude will also purge them, removing 
>their configuration files and perhaps other important data. For 
>more information about which packages are considered to be
>“unused”, see the section “Managing Automatically Installed
>Packages” in the aptitude reference manual.  THIS OPTION CAN 
>CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE 
>DOING!

I do not use this option. So, there's no way to see this warning.

> Yes, this is probably not what you understood as "actively", but this 
> thread is also not about running 'aptitude purge', but 'full-upgrade', 
> and if you change the default...

I didn't change the default. I just purged the removed packages at the
same time as the upgrade (with '_').

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140721190326.gb18...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-22 22:10:07 +0200, Arno Töll wrote:
> On 21.07.2014 20:58, Vincent Lefevre wrote:
> > Yes, and a consequence of this loss is that dpkg fails.
> 
> dpkg does not at all fail. If anything dpkg errors out because Apache's
> maintainer script failed, because "invoke.rc-d apache2 restart" failed,
> because ... you guess it, somebody removed the .load symlinks we expect
> to be there.

I didn't say that this was dpkg's fault. Then, "errors out" and "fails"
are synonymous here. The error is fatal and the system is left in
an inconsistent state. The user must fix things manually then run
"apt-get install -f", hoping things are really fixed...

BTW, I'm wondering whether the fact that "invoke.rc-d apache2 restart"
fails should make the postinst script fail and affect the whole upgrade.
If the goal is to make the user notice that Apache doesn't run, this is
rather unnecessary: In any case, the user should test his web server
after an Apache upgrade (or other major upgrade in the system), even
when everything seems fine during the upgrade. This should be regarded
more as a "run-time" failure than an "install-time" failure.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722231930.ga3...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-23 01:19:01 +0200, Christian Hofstaedtler wrote:
> * Arno Töll  [140722 22:10]:
> > On 21.07.2014 20:58, Vincent Lefevre wrote:
> > > Yes, and a consequence of this loss is that dpkg fails.
> > 
> > dpkg does not at all fail. If anything dpkg errors out because Apache's
> > maintainer script failed, because "invoke.rc-d apache2 restart" failed,
> > because ... you guess it, somebody removed the .load symlinks we expect
> > to be there.
> 
> As a mere bystander I still don't really understand the underlying
> issue. You're basically saying that /some/ conffiles are kept, and
> others are purged and reinstalled?

The issue is that they are purged, but *not* reinstalled.

> Possible radical solution: abandon old apache binary package names
> [of those that ship conffiles], introduce a new set of names,
> Conflict/Break (but not Replace?) the old ones and have all modules
> depend on the new packages.
> 3rdparty module packages will then prevent upgrades or get
> deinstalled, and users get a fresh config that works, but may not do
> anything useful.

The issue is not with 3rd-party module packages (specifically),
but with the standard modules. And without these standard modules,
Apache cannot be started.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232912.gc3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!

The default (systemd-sysv) was just a poor choice from aptitude.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232452.gb3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:
> On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?
> > Well, because the new version of libpam-systemd, 208-6, now depends on
> > systemd-sysv rather than systemd-sysv | systemd-shim.
> 
> As you can see with this dependency, you just need to install
> systemd-shim. No need to install systemd-sysv!
> 
> The default (systemd-sysv) was just a poor choice from aptitude.

Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722233957.gd3...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-23 02:05:26 +0200, Arno Töll wrote:
> On 23.07.2014 01:19, Vincent Lefevre wrote:
> > BTW, I'm wondering whether the fact that "invoke.rc-d apache2 restart"
> > fails should make the postinst script fail and affect the whole upgrade.
> 
> It does actually as we fixed #716921 a while back.

OK, I forgot that (I solved the problem before this was fixed IIRC).

> > If the goal is to make the user notice that Apache doesn't run, this is
> > rather unnecessary: In any case, the user should test his web server
> > after an Apache upgrade (or other major upgrade in the system), even
> > when everything seems fine during the upgrade. This should be regarded
> > more as a "run-time" failure than an "install-time" failure.
> 
> ... which we do. Yet people, including you, blame us for that data loss
> as you start the (re-)server at runtime afterwards even though the
> installation completes.  :-)

Well, with the fix above, this is now a separate problem.
Unfortunately it seems that there are no really good solutions.
One can at least suppose that the user keeps backups, at least
before such a major upgrade. Now, thinking again about your
first mail:

> * Ignore the problem, and refer to the manpage of aptitude without
> proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
> NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING". The bad news is, we
> can't tell this before it's too late, such as in a NEWS file - and we
> know, everybody reads release notes too, right?

I don't understand that: Why is it too late? The NEWS.Debian file is
displayed by apt-listchanges *before* the user accepts the upgrade.
So, the user should be aware of the problem. If the user doesn't
read the NEWS.Debian file (which is there to present important
differences, regressions..., i.e. something that the user must
really know in general), then this is his fault.

Note: the NEWS.Debian part for apache2 2.4.1-1 is rather lengthy
(which is normal here). So, information related to data loss must
be put first, with a big WARNING, so that the user doesn't miss it.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723013341.ge3...@xvii.vinc17.org

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Vincent Lefevre]

On 2014-07-22 19:54:10 -0700, Russ Allbery wrote:
> logind is also not mandatory in Debian now.  It's just required, upstream,
> by all the major desktop environments.

Not just by all the major desktop environments. It is also needed
by hplip via dependencies[*], which is quite surprising for a
"HP Linux Printing and Imaging System".

[*] hplip -> policykit-1 -> libpam-systemd -> systemd

Or is there any abuse of a dependency here?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723224655.ga14...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> And we already concluded that you need to logout anyway, even with
> systemd-shim. A reboot and relogin isn't that much different from a
> users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725204345.ga15...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 23:04:55 +0200, Michael Biebl wrote:
> Am 25.07.2014 22:43, schrieb Vincent Lefevre:
> > On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> >> And we already concluded that you need to logout anyway, even with
> >> systemd-shim. A reboot and relogin isn't that much different from a
> >> users POV.
> > 
> > Screen sessions, SSH sessions and computation processes running in
> > background are lost after a reboot, not after a relogin.
> 
> You are doing a dist-upgrade while there are running computation
> processes? That sounds like a recipe for disaster.

I have a Debian/unstable desktop machine that permanently runs
computation processes, so yes. However I don't really mind if
they are aborted. I'm more annoyed when losing my screen and SSH
sessions (to the machine). Now, if this happens only once every
few months, that's OK.

What I really meant is that a reboot is quite different from a
relogin: I log out / in again quite often, and if I need a more
permanent session, I use screen.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725232526.ga5...@xvii.vinc17.org

Re: Bug#756172: ITP: ssh-cron -- cron-like job scheduler than handles ssh key passphrases

[Vincent Lefevre]

On 2014-07-27 11:39:58 +0200, Bastian Blank wrote:
> On Sun, Jul 27, 2014 at 06:57:24PM +1200, Chris Bannister wrote:
> > Presume you mean "... scheduler that handles ..."
> > It may even be "proper English" to say "... scheduler which handles ..."
> 
> We got the advice to always use "which" with comma and "that" without
> comma.  Especially for non-native speakers the number of variations with
> slightly different meaning gets too high.

Shouldn't there be a comma because it is a non-restrictive clause?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140727212621.ga32...@xvii.vinc17.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Vincent Lefevre]

On 2014-08-09 18:26:19 +0100, Kieran Kunhya wrote:
> We also use a fork specifically to work around very wasteful
> calculations in libswscale during 10-bit chroma conversion that
> involve multiplying a pixel by a 2^n value with 32-bit precision and
> then shifting that value down by n back to 16-bit precision (achieving
> nothing). The fix breaks other codepaths that we don't use but the
> performance gain is big enough to warrant a fork.

What is the performance gain?

I'm wondering what performance gain is important enough to justify a
fork in Debian. Well, not just a fork, just recompiling with static
linking can yield a significant improvement. For instance, I could
obtain up to a 37% gain with a static link against MPFR.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140811133947.ga16...@xvii.vinc17.org

Re: Bug#762839: bash without importing shell functions from the environment

[Vincent Lefevre]

On 2014-09-26 09:19:17 +0200, Samuel Thibault wrote:
> Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit :
> > Wasn't there some web server that used to put query script variables
> > into the environment of the CGI script?
> 
> Well, that ought to have been fixed a long time ago already,
> otherwise you could have injected all sorts of LD_*.

It depends on the environment variable names. Names with lowercase
characters, such as "exec", are safe, since for application usage
only[*]. Well... actually not with bash!

[*] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926083248.ga2...@xvii.vinc17.org

Re: Bug#762839: bash without importing shell functions from the environment

[Vincent Lefevre]

On 2014-09-26 10:33:20 +0200, Josselin Mouette wrote:
> Brian May  wrote: 
> No, I don't think that is the case. I believe sudo interprets
> those assignments itself (as also shown in man page), and  the
> error I got clearly shows this to be the case.
> 
> brian@aquitard:~$ sudo echo='() { /bin/echo bar; id; }'
>  ./test.sh
> sudo: sorry, you are not allowed to set the following
> environment variables: echo
> 
> My understanding is that sudo doesn't invoke any sort of shell
> unless you expressly tell it to do so.
> 
> 
> Does it also apply to variables that are part of env_keep in sudo?
> For example if you set TZ, PS1 or XAUTHORITY, which are preserved by
> default.

I'm not sure I understand your question. With CVE-2014-6271 fixed,
there are no problems, except for scripts that invoke TZ, PS1 or
XAUTHORITY as commands. This is rather unlikely, since commands
with uppercase letters are not so common (I just know GET, HEAD,
POST, and X).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140926085325.gb2...@xvii.vinc17.org

Re: binary data file and endianness and multiarch

[Vincent Lefevre]

On 2014-09-27 11:18:18 +0100, Jonathan Dowland wrote:
> > On 27 Sep 2014, at 10:36, Adam Borowski  wrote:
> > 
> > Except that the endianness war has been won by little-endian
> 
> And yet, network byte order remains big.

But does this matter in the context of these binary data files?

On 2014-09-27 13:06:56 +0200, Matthias Urlichs wrote:
> Jonathan Dowland:
> > It's less important which endian they pick, but that they pick one
> > and use it consistently across arches.
> > 
> The advantage of using big-endian data on a little-endian system is that
> you actually have a chance of finding mis-swapped and/or mis-sized items.

However, conversely, if little-endian data is chosen, you just need to
test on a big-endian system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927205834.ga24...@xvii.vinc17.org

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-01 18:55:20 +0300, Riku Voipio wrote:
> On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> > I think it would be useful to describe what issue(s) there are concerning 
> > 8BITMIME and why this is important.  I've found some information [1] about 
> > this, but it isn't clear what problems are actially *caused* by the lack of 
> > 8BITMIME support by default in Exim.  Is it just slow sending of outbound 
> > attachments?
> 
> It's both extra traffic (not that much if western encodings) and extra
> cpu work. In lesser annoyance, it means that you no longer can read
> mailbox files with non-mime capable readers (for example less) with ease,
> as there will be qp encodings here and there. People who only use english
> only hit the issue when having lines longer than 76 characters.

It might also affect spam detection.

Now, the main reason I dislike Exim is

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485751

Basically, when invoked as sendmail, Exim breaks the sendmail
compatibility by keeping the Bcc header, involving security
and/or privacy problems. And since this is by design, it won't
be fixed.

BTW, since it must accept 8-bit mail via this interface, it is
also broken as the mail may be sent to a MTA that doesn't announce
8BITMIME, since Exim doesn't know to do the conversion. :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502010917.ga5...@xvii.vinc17.org

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
> Hello,
> 
> On Wed, 2 May 2012 10:06:31 +0100
> Jon Dowland  wrote:
> 
> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> > > No it doesn't if 8BITMIME annouces are turned off!
> 
> > If exim receives an 8 bit mail, even if it hadn't announced 8BITMIME
> > in the EHLO response, it will relay that message verbatim to other
> > hosts.
> 
> But it won't receive it at all if the sender is standards-compliant.

True for SMTP. But what if exim received an 8-bit mail by another
mean (e.g. on the command line via the sendmail command)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503001506.gd5...@xvii.vinc17.org

Re: switching from exim to postfix

[Vincent Lefevre]

On 2012-05-02 20:23:41 -0400, Scott Kitterman wrote:
> Vincent Lefevre  wrote:
> >On 2012-05-02 15:00:36 +0200, Andrew Shadura wrote:
> >> Hello,
> >> 
> >> On Wed, 2 May 2012 10:06:31 +0100
> >> Jon Dowland  wrote:
> >> 
> >> > On Wed, May 02, 2012 at 08:44:12AM +0200, Andrew Shadura wrote:
> >> > > No it doesn't if 8BITMIME annouces are turned off!
> >> 
> >> > If exim receives an 8 bit mail, even if it hadn't announced
> >8BITMIME
> >> > in the EHLO response, it will relay that message verbatim to other
> >> > hosts.
> >> 
> >> But it won't receive it at all if the sender is standards-compliant.
> >
> >True for SMTP. But what if exim received an 8-bit mail by another
> >mean (e.g. on the command line via the sendmail command)?
> 
> Then it's irrelevant to the discussion. It's a local system issue
> and it's up to the local administrator. Internet standards have
> nothing to do with it.

Wrong. It's relevant in the sense that Exim will transmit the mail
to a remote MTA. If it doesn't do the 8-bit to 7-bit conversion if
the remote MTA doesn't announce 8BITMIME, then Exim is broken.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503004506.ga25...@xvii.vinc17.org

Re: Moving /tmp to tmpfs makes it useful

[Vincent Lefevre]

On 2012-05-25 14:49:14 +0100, Will Daniels wrote:
> On 25/05/12 13:52, Ted Ts'o wrote:
> >So what?  If you write to a normal file system, it goes into the page
> >cache, which is pretty much the same as writing into tmpfs.  In both
> >cases if you have swap configured, the data will get pushed to disk;
> 
> That's not at all the same, the page cache is more temporary, it's getting
> flushed to disk pretty quick if memory is tight (presumably) but in the same
> situation using tmpfs going to swap is surely going to be more disruptive?

Why wouldn't there be a FS option to have a different policy for
specific directories, like /tmp? e.g. avoid write-back to disk
except when needed (because of lack of RAM). In such a way, the
behavior would be similar to tmpfs, without the restriction on
the tmpfs size, i.e. this would be more flexible for the user.

BTW, I wish there were a document summarizing all these discussions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530113010.ga24...@xvii.vinc17.org

Re: Moving /tmp to tmpfs makes it useless

[Vincent Lefevre]

On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
> Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
> écrit : 
> > With "tmpfs on /tmp" you are breaking many applications that assume that
> > they have enough space to write on /tmp like the flash player ( see
> > Debian bug #666096 ) or cdrecord software ( see #665634 ).
> 
> Seriously, this is madness. You can’t expect to have “enough” space on
> *any* filesystem.

I think that the point is that in general, there is more space on
the local disk than on some tmpfs. What I mean is that if /tmp is
on the right partition on the disk, it will have more space than
any reasonable tmpfs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120530113506.gb24...@xvii.vinc17.org

Re: Starting services automatically after install

[Vincent Lefevre]

On 2012-06-03 08:21:34 +0200, Bernhard R. Link wrote:
> Try to see it from the other side: I don't understand why you would a
> like a service not started by default. The daemon is there to be run,
> so running it is the most sensible approach in almost all cases[1].

Well, a mail server daemon must not be run until it is completely
configured, in particular when manual configuration is needed,
e.g. to set up aliases and/or to check if some disk is mounted.
Otherwise this means that mail will be rejected. Because of that,
I potentially lost mail on an Ubuntu machine. But I think that
Debian has/had the same problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605115705.ga3...@xvii.vinc17.org

Have NetworkManager disabled by default when... (was: Recommends for metapackages)

[Vincent Lefevre]

On 2012-07-14 22:59:35 +0200, Tollef Fog Heen wrote:
> Due to those drawbacks, I've wondered why people don't just disable
> NetworkManager on their system instead of bothering with workarounds
> like the above or dpkg -P --force-depends and similar.

Sorry for being late in the discussion. I also think that having
NetworkManager disabled for those who do not want to use it is
a good solution. But I think that if other network configuration
packages (ifupdown, wicd) are already used when network-manager
is being installed, NetworkManager should be disabled by default,
or the choice should be given to the user after telling him what
is currently used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718121812.ga15...@ypig.lip.ens-lyon.fr

Re: Have NetworkManager disabled by default when... (was: Recommends for metapackages)

[Vincent Lefevre]

On 2012-07-18 15:01:43 +0200, Adam Borowski wrote:
> On Wed, Jul 18, 2012 at 02:18:12PM +0200, Vincent Lefevre wrote:
> > Sorry for being late in the discussion. I also think that having
> > NetworkManager disabled for those who do not want to use it is
> > a good solution. But I think that if other network configuration
> > packages (ifupdown, wicd) are already used when network-manager
> > is being installed, NetworkManager should be disabled by default,
> > or the choice should be given to the user after telling him what
> > is currently used.
> 
> ifupdown is always used, at least in some form (extreme embedded aside).

Well, /etc/network/interfaces could be checked to see if the
admin could have modified the default config (not sure whether
this is possible reliably or this can be a heuristic).

> wicd is used only on machines that use wifi, this excludes most desktops.

Still, the check would be useful on laptops where wicd is installed
and enabled (the user could have a default ifupdown config and wicd
enabled).

> So I'm afraid such a check would be mostly useless.
> 
> 
> A different idea would be to have NM configured by default to do what it can
> do well (wifi) and stay away from all other interfaces, but because it has
> thorough assumptions that it controls all of networking in the system, this
> is not a change that could realistically be done during freeze.

Agreed (but note that NM shouldn't do wifi if wicd is enabled).

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718133137.ga19...@ypig.lip.ens-lyon.fr

Re: Have NetworkManager disabled by default when... (was: Recommends for metapackages)

[Vincent Lefevre]

On 2012-07-18 21:32:31 +0100, Wookey wrote:
> +++ Andrei POPESCU [2012-07-18 20:56 +0300]:
> > One of the reasons I'm using network-manager instead of wicd or even 
> > plain ifupdown is the possibility to switch (more or less) seamlessly 
> > between wired and wifi.
> 
> wicd does this just fine too. Tell it to autoconnect to wired and
> selected wifi networks and it 'just works' (TM) for me. (wired at
> work, wireless at home, in the normal case). I find both daemons give a
> smooth experience for this usage (but wicd has the advantage of useful
> curses and cli interfaces).

One may want to use ifupdown for wired because it is more powerful
than wicd, thanks to the "mapping" stanza. In such a case, one needs
to disable wired completely in wicd, and then, I don't think it can
autoconnect to wifi only when there's no wired connection.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718234835.ga25...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> ENABLE/DISABLE switches are *ugly*,

I disagree. ENABLE/DISABLE switches have some advantages: they are
more readable than a set of symlinks, allow all the settings of some
service to be grouped in a single place, and can be managed more
easily by VCS software.

> as their effect is not limited to boottime changes. Especially in
> case of packages who ship with such a variable set to disable by
> default, this is very annoying.

The user may not want a service he didn't request or he hasn't
configured yet to be enabled by default. For instance, some packages
may be installed automatically (due to dependencies), or one may want
the client, but not the server. Such services should be disabled by
default.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120722115058.ga24...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-22 14:11:41 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> > I disagree. ENABLE/DISABLE switches have some advantages: they are
> > more readable than a set of symlinks, allow all the settings of some
> > service to be grouped in a single place, and can be managed more
> > easily by VCS software.
> 
> While this is true, it's not the way that sysvinit works.  Other
> systems such as systemd may provide such facilities natively, but
> initscripts do not.  If you're going to use sysvinit, then you
> should just use update-rc.d foo disable to disable it.

I don't think there's anything wrong with enhancing the way that
sysvinit works, as long as the user can still use the update-rc.d
method.

> > The user may not want a service he didn't request or he hasn't
> > configured yet to be enabled by default. For instance, some packages
> > may be installed automatically (due to dependencies), or one may want
> > the client, but not the server. Such services should be disabled by
> > default.
> 
> This is not the general consensus--by default daemons are started if
> the package is installed.  This has been already debated extensively
> many times over.  Irrespective of whether your personal opinion is
> that this is a good or bad thing, that's just the way it is at present.

You're wrong. This is not true for all packages. It seems that
it's up to the maintainer to choose whether the daemon is run
by default or not.

Anyway the Debian Policy Manual doesn't seem to
  * forbid ENABLE/DISABLE switches,
  * require that daemons should be run by default.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120722135313.ga14...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

Hi Michael,

On 2012-07-22 16:25:15 +0200, Michael Stapelberg wrote:
> Quoting Vincent Lefevre (2012-07-22 15:53:13)
> > I don't think there's anything wrong with enhancing the way that
> > sysvinit works, as long as the user can still use the update-rc.d
> > method.
> There is: update-rc.d is a defined interface which works with sysvinit
> and other init systems (soon). The ENABLE/DISABLE-mechanism is specific
> to only one init system and it’s not consistent between various
> packages.

OK, if Debian plans to support other init systems, that's fine.

> > Anyway the Debian Policy Manual doesn't seem to
> >   * forbid ENABLE/DISABLE switches,
> >   * require that daemons should be run by default.
> It doesn’t, but dh_installinit starts init scripts by default (which has
> no effect in case of ENABLE/DISABLE switches of course).

I don't understand what you mean here. For instance, in case of wicd,

# Automatically added by dh_installinit
if [ -x "/etc/init.d/wicd" ]; then
update-rc.d wicd defaults >/dev/null
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
invoke-rc.d wicd $_dh_action || exit $?
fi
# End automatically added section

and the switch will be honored.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723014144.ga7...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-22 16:40:48 +0200, Wouter Verhelst wrote:
> On Sun, Jul 22, 2012 at 01:50:58PM +0200, Vincent Lefevre wrote:
> > On 2012-07-22 11:43:14 +0200, Wouter Verhelst wrote:
> > > ENABLE/DISABLE switches are *ugly*,
> > 
> > I disagree. ENABLE/DISABLE switches have some advantages: they are
> > more readable than a set of symlinks,
> 
> That's just an opinion (one which I don't share)
> 
> > allow all the settings of some service to be grouped in a single
> > place,
> 
> No. On the contrary.
> 
> Services are currently configured in one or two places:
> - in /etc/rc*.d (whether they run or not)
> - in the service-specific configuration file (the behaviour of the
>   service)
> 
> /etc/default is a third place, not a "one and only" place. Using it to
> specify things like command-line parameters is probably fine. Using it
> to *override* some other configuration is stupid.

No, if the user chooses to deal with /etc/default/ file
only (and not with update-rc.d), he will need to look at only
one or two places instead of two or three. And options set in
/etc/default/ may already override other configuration,
so that if you want to make things more consistent, you should
get rid of /etc/default entirely.

> > and can be managed more easily by VCS software.
> 
> At least git supports symlinks just fine. Which VCS system are you using
> that doesn't? Sounds like you may just need to switch.

There are several problems. First the symlinks would need to be copied
to my own working copy. Now I could do that. Then Subversion won't
detect by itself files that have been added or removed. I need to tell
it explicitly, which is annoying, as this isn't done automatically.
But the main problem is the history. If there's only one file, I can
do, e.g. "svn log the_file". But if files (symlinks) are added or
removed, I can no longer get the log. Or I need to do that on the
parent directory, but I would also get the changes concerning the
other services, which is information I don't want.

> Additionally, personally I prefer using config management systems for
> that kind of thing.

I don't think they would do what I want, i.e. track config changes
on the system, either done by me or done automatically (more or less
what diffmon does, but diffmon cannot handle the rc*.d symlinks).

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723021906.gb7...@ypig.lip.ens-lyon.fr

Re: glibc very old

[Vincent Lefevre]

On 2012-07-23 14:49:35 +0900, Miles Bader wrote:
> Based on a glance at the source, it seems like the math libraries were
> changed in lots of little ways between 2.13 and 2.16 [and it looks
> like the FPU-twiddling that made expf slow in 2.13 has been _added_ to
> the generic version of the "exp" (double-precision) function, meaning
> it might actually be (much) _slower_ in 2.16 on ports without
> optimized implementations... :( ]

However (if this is the change I'm thinking of) this makes math functions
"correct" in directed rounding modes and potentially more secure.

By "correct", I mean that the result is somewhat acceptable (not that
the result is correctly rounded and the rounding direction is honored),
instead of getting completely wrong values or even a crash.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723123534.ga9...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre 
> 
> > OK, if Debian plans to support other init systems, that's fine.
> 
> It already does.

Not really, or at least not in a nice way, because sysvinit is
an essential package. Also, I don't see any init system that
provides the same feature as ENABLE/DISABLE (i.e. together with
other configuration options of the service, such as the port on
which the daemon will listen).

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723131006.gb9...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > so that if you want to make things more consistent, you should
> > get rid of /etc/default entirely.
> 
> /etc/default is used for a lot more than just enabling/disabling services,
> and it will not go away.

But with /etc/default, you can override options. For instance,
for sshd, the port can be provided either in /etc/ssh/sshd_config
or in /etc/default/ssh.

> Now, if you just mean removing enable/disable switches for initscripts from
> /etc/default/*, that should be doable with some effort.  And that's what
> this subthread is about.

No, I just mean that configuration of some service should be
in a limited number of places. But if you agree that it's fine
for /etc/default to override config setup somewhere else, then
there should not be any problem with ENABLE/DISABLE.

> > to my own working copy. Now I could do that. Then Subversion won't
> > detect by itself files that have been added or removed. I need to tell
> > it explicitly, which is annoying, as this isn't done automatically.
> > But the main problem is the history. If there's only one file, I can
> > do, e.g. "svn log the_file". But if files (symlinks) are added or
> > removed, I can no longer get the log. Or I need to do that on the
> 
> Use the right tool for the job.  SVN is crap for this particular use case,
> and any difficulties involving the use of svn to track /etc are irrelevant
> because it simply cannot be expected to work properly anyway.  Switch to
> etckeeper + git or something else that can version-control symlinks, owner
> and mode changes in an useful way (git itself is not enough, thus the use of
> etckeeper on top of git).

etckeeper is not the right tool because it will store private data
(e.g. passwords and private keys). I want to track only public data
and only files for which I have done a local modification.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723132629.gc9...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-23 15:26:29 +0200, Vincent Lefevre wrote:
> No, I just mean that configuration of some service should be
> in a limited number of places. But if you agree that it's fine
> for /etc/default to override config setup somewhere else, then
> there should not be any problem with ENABLE/DISABLE.

And something else that can be done via /etc/default is that one
can write comments (e.g. "Temporarily disabled because of bug..."),
something that cannot be done with "update-rc.d".

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723133633.ga11...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre 
> 
> > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre 
> > > 
> > > > OK, if Debian plans to support other init systems, that's fine.
> > > 
> > > It already does.
> > 
> > Not really, or at least not in a nice way, because sysvinit is
> > an essential package.
> 
> How is that relevant?  Don't we support pax just because tar is
> essential?

But installing pax won't remove tar, while...

# apt-get install -s upstart
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  libnih-dbus1 libnih1
The following packages will be REMOVED:
  sysvinit
The following NEW packages will be installed:
  libnih-dbus1 libnih1 upstart
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  sysvinit
0 upgraded, 3 newly installed, 1 to remove and 17 not upgraded.
Remv sysvinit [2.88dsf-28]
[...]

> > Also, I don't see any init system that provides the same feature as
> > ENABLE/DISABLE (i.e. together with other configuration options of the
> > service, such as the port on which the daemon will listen).
> 
> You might want to look again, then, there are multiple ways to disable a
> daemon using systemd units.

OK, the package description of systemd by mentioning the rcN.d links.
I had the impression they were still used.

Also, it seems that to disable a daemon using systemd units, one needs
these native files. But many packages don't provide them. So, real
systemd support isn't really there.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723222818.ga8...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-23 17:59:21 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> > No, I just mean that configuration of some service should be
> > in a limited number of places. But if you agree that it's fine
> > for /etc/default to override config setup somewhere else, then
> > there should not be any problem with ENABLE/DISABLE.
> 
> It's not compatible with init systems which do not use the init
> scripts directly, e.g. systemd.

I don't understand. If systemd does not use the init scripts directly,
how can it be aware of the way to start the daemon?

If you want an example, there's wicd-daemon, which just provides an
init script and has an ENABLE/DISABLE switch in /etc/default/wicd.

> A common interface for enabling/disabling is required, which can
> then do the system-specific thing for enabling/disabling. That
> should probably be update-rc.d (though the name is
> sysvinit-specific). Since we're going to be changing the update-rc.d
> interface in wheezy+1, maybe we could simply replace it with e.g.
> update-service and provide a compatibility wrapper. And we should
> ensure that all init systems provide add/remove/enable/disable
> actions. The stop|start actions are going to simply defer to the
> "defaults" action, and will ultimately go.

A common interface would be nice. But what if there are multiple
ways to disable a daemon (as mentioned by Tollef Fog Heen)? I think
that it should be flexible enough so that the user can choose.

IMHO it should also provide some logging mechanism for
add/remove/enable/disable actions.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120723225345.gb8...@ypig.lip.ens-lyon.fr

Re: glibc very old

[Vincent Lefevre]

On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre  writes:
> > By "correct", I mean that the result is somewhat acceptable (not
> > that the result is correctly rounded and the rounding direction is
> > honored), instead of getting completely wrong values or even a
> > crash.
> 
> But how often are directed rounding modes used?  Like 0.001% of the
> time?

They are not used often. However they must be correct.

> 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 should get a processor that
handles rounding-mode change in a better way (the slowdown
should not be noticeable when you  just run the program, without
looking at the exact running time).

> I can see that as an emergency workaround when the deadline is next
> week, but it seems kind of questionable as a general technique.
> 
> Is there no more sane method?
> 
> E.g.:
> 
>  (1) have the FPU-twiddling functions ( stuff?) set a global
>  flag "FPU_is_twiddled = 1;"
> 
>  (2) write these rounding-mode-sensitive functions like:
> 
>if (FPU_is_twiddled)
>  return slow_ass_FPU_twiddling_version ();
>/* ... otherwise fall through to normal fast code ... */

There's only one code, which is run in both cases. The difference
is that the rounding mode is set to FE_TONEAREST at the beginning
of the function and restored at the end of the function.

The only sensible change that can be done (without requiring the
compiler a choice based on the FENV_ACCESS pragma) is to test a
global (actually TLS) flag as you propose so that the instruction
to control the rounding mode is not used if the processor was
already in FE_TONEAREST. But note that this could actually be
slower with some processors: the processor already knows the
rounding mode it is running under, so that if the rounding mode
is not changed, the rounding-mode control instruction should be
no slower than no-op!

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724090651.ga6...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre 
> 
> > On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre 
> > > 
> > > > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > > > ]] Vincent Lefevre 
> > > > > 
> > > > > > OK, if Debian plans to support other init systems, that's fine.
> > > > > 
> > > > > It already does.
> > > > 
> > > > Not really, or at least not in a nice way, because sysvinit is
> > > > an essential package.
> > > 
> > > How is that relevant?  Don't we support pax just because tar is
> > > essential?
> > 
> > But installing pax won't remove tar, while...
> 
> I don't think it follows at all that because there are init systems
> which conflict with sysvinit, Debian does not support multiple init
> systems.

But in such a case, sysvinit shouldn't be an essential package (and
packages that need it should thus have an explicit dependency on it),
since it isn't really needed in a working Debian system. Otherwise,
if the user wants to use an init system that conflicts with sysvinit,
how do you know that he will not break his system (even if the new
init system is correctly configured)?

> > OK, the package description of systemd by mentioning the rcN.d links.
> > I had the impression they were still used.
> 
> They are, unless there are native service descriptions shipped.

If the package description had said that, it would have been
less confusing. It's strange for a package description to focus
on non-native features!

> > Also, it seems that to disable a daemon using systemd units, one needs
> > these native files. But many packages don't provide them. So, real
> > systemd support isn't really there.
> 
> You said «I don't see any init system that provides the same feature as
> ENABLE/DISABLE (i.e. together with other configuration options of the
> service, such as the port on which the daemon will listen).», you did
> not specify «without changing anything in the existing packages» og
> something similar.

Well, that was quite obvious to me. By init system support, I mean
that the init system should be provided as packages *and* that
packages providing a service should support the init system natively
(otherwise there isn't much point to switch to another init system).

> Also, to turn your argument on the head: many packages does not provide
> NO_START=1 in /etc/default, so real support for that isn't really there
> either.  On my system, it's about 8 of 103 init scripts, which is
> slightly higher than the ratio of packages shipping systemd service
> descriptions to packages shipping init scripts.  (58 / 1106 for .service
> files)

The only package for which I want to control whether the daemon is run
or not has such a switch (this is wicd-daemon). I don't (currently)
mind about the other packages. I just don't want this switch to
disappear, or wicd-daemon should provide a native systemd file to
start the daemon (which is not the case currently).

IMHO, for packages that provide such a switch, there should be no
requirement to abandon it without supporting the other init systems
first.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724093126.gb6...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

On 2012-07-24 12:26:33 +0200, Tollef Fog Heen wrote:
> > If the package description had said that, it would have been
> > less confusing. It's strange for a package description to focus
> > on non-native features!
> 
> I don't know what you mean by non-native features.  Support for SysV
> init scripts is native to systemd, but if there's both a sysvinit and a
> .service file providing the same service, the .service file takes
> precedence.  Similarly, if you have a .service file in
> /lib/systemd/system and one in /etc/systemd/system, the latter takes
> precedence.

I just mean that the systemd package description mentions the SysV
init scripts, but not the .service files. So, it was not clear that
systemd had its own files that could replace the SysV init scripts
completely.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724180423.ga3...@ypig.lip.ens-lyon.fr

Re: glibc very old

[Vincent Lefevre]

On 2012-07-26 03:58:33 +0900, Miles Bader wrote:
> Vincent Lefevre  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 should get a processor that
> > handles rounding-mode change in a better way (the slowdown should
> > not be noticeable when you just run the program, without looking at
> > the exact running time).
> 
> It's about 5 times slower on both phenom2 (AMD) and core2 (Intel)
> cpus I dunno if these are unusual.

I can reproduce a 3.4x slowdown with:

#include 
#include 
#include 
#include 
#pragma STDC FENV_ACCESS ON

int main (void)
{
  volatile double x = 1.0, y;
  int i;

  for (i = 0; i < 1; i++)
{
  fesetround (FE_TONEAREST);
  y = exp(x);
  fesetround (FE_TONEAREST);
}
  return y == 0.0;
}

and Debian's glibc and Intel Core 2 Duo. I'll try to have more
information about why the processor doesn't detect that the
rounding mode doesn't change.

But with:

#include 
#include 
#include 
#include 
#pragma STDC FENV_ACCESS ON

int main (void)
{
  volatile double x = 1.0, y;
  int i;

  for (i = 0; i < 1; i++)
{
  int r = fegetround();
  if (r != FE_TONEAREST)
fesetround (FE_TONEAREST);
  y = exp(x);
  if (r != FE_TONEAREST)
fesetround (r);
}
  return y == 0.0;
}

I only get a 9% slowdown. I suppose that withing glibc code, it can
be lower. The advantage of this method compared to remembering the
rounding mode in glibc is that it is 100% safe, in case the user or
some library bypasses the C libary to change the rounding mode.

I think that there could be an optimization like that in
fesetround() too.

> Ok, I guess there's no really guaranteed way to make it fast, so
> glibc's method (with arch-specific reimplementations for those cases
> where it proves to be slow) it is reasonable enough ...

Yes, the chosen method could depend on the processor.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120726002713.ga6...@xvii.vinc17.org

Re: emacs23 and/or emacs24 in Wheezy?

[Vincent Lefevre]

On 2012-07-25 21:28:16 +0100, Neil Williams wrote:
> On Wed, 25 Jul 2012 21:58:20 +0200
> Svante Signell  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 granted, so it does not have a free pass
> into Wheezy.

Note that emacs24 has a very annoying regression: bug 680933.
There is a patch, which works well for me. If emacs24 goes to
Wheezy, it should include this patch.

> emacs24 wouldn't seem to meet any of the criteria for a freeze
> exception and emacs23 currently doesn't have any RC issues in Wheezy,
> so there would be no particular reason to do anything with emacs24.

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 the problem because of this bug. And
it is fixed in emacs24.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120726003945.gb6...@xvii.vinc17.org

Re: glibc very old

[Vincent Lefevre]

On 2012-07-26 13:33:46 +0900, Miles Bader wrote:
> Vincent Lefevre  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,
I think it is. Then they'll have to decide what to do depending
on the processor (in particular on non-x86).

I've attached a new test program. It is also available here:

  http://www.vinc17.net/software/rndmode.c

It shows that this change would be useful on all the processors
I've tested: AMD Opteron, Intel Xeon, Intel Core2, POWER7. It
would be particularly important on Intel Core2 and, in a less
extent, AMD Opteron.

Summary of the results:

AMD Opteron 4.62s8.92s   4.72s
Intel Xeon X56503.22s4.69s   3.51s
Intel Xeon E55203.37s5.20s   3.66s
Intel Core2 Duo P8600   3.35s   11.77s   3.70s
POWER7  7.29s   11.16s   7.86s

1st timing: no calls to fegetround/fesetround.
2nd timing: fegetround/fesetround/fesetround to set and restore the RM.
3rd timing: fegetround with tests before fesetround, so that fesetround
doesn't need to be called.

This shows that the rounding mode test could be done in fesetround.
When the rounding mode really changes, this would just be a little
slower.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
/* $Id: rndmode.c 53564 2012-07-26 11:10:38Z vinc17/ypig $

Compare the timings with OPT = 0, 1 and 2 to measure the
fegetround/fesetround performance when the rounding mode
doesn't change. See thread:
  http://lists.debian.org/debian-devel/2012/07/msg00466.html
and in particular:
  http://lists.debian.org/debian-devel/2012/07/msg00747.html

Possible test:

for opt in 0 1 2
do
  gcc -O2 rndmode.c -o rndmode -lm -DOPT=$opt
  echo "OPT=$opt"
  for i in 0 1 2; do time ./rndmode; done
done

On a Debian/squeeze x86_64 Quad-Core AMD Opteron 8378 @ 2.40GHz machine
with libc6 2.11.3-3 and GCC 4.4.5: 4.62s / 8.92s / 4.72s

On a Debian/squeeze x86_64 Intel Xeon X5650 @ 2.67GHz machine
with libc6 2.11.3-3 and GCC 4.4.5: 3.22s / 4.69s / 3.51s

On a Debian/unstable x86_64 Intel Xeon E5520 @ 2.27GHz machine
with libc6 2.13-35 and GCC 4.7.1: 3.37s / 5.20s / 3.66s

On a Debian/unstable x86_64 Intel Core2 Duo P8600 @ 2.40GHz machine
with libc6 2.13-35 and GCC 4.7.1: 3.35s / 11.77s / 3.70s

On a Red Hat Fedora release 16 (Verne) POWER7 @ 3.55GHz machine
with glibc 2.14.90-24 and GCC 4.6.3: 7.29s / 11.16s / 7.86s
*/

#include 
#include 
#include 
#pragma STDC FENV_ACCESS ON

#ifndef N
#define N 1
#endif

int main (void)
{
  volatile double x = 1.0, y = 0.0;
  int i;

  for (i = 0; i < N; i++)
{
#if OPT
  int r = fegetround();
#if OPT > 1
  if (r != FE_TONEAREST)
#endif
fesetround (FE_TONEAREST);
#endif
  y += exp(x);
#if OPT
#if OPT > 1
  if (r != FE_TONEAREST)
#endif
fesetround (r);
#endif
}
  return y == 0.0;
}

Re: emacs23 and/or emacs24 in Wheezy?

[Vincent Lefevre]

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 the problem because of this bug. And
> > it is fixed in emacs24.
> 
> I've seen this problem several times too, but did not know there was a
> bug report and an upstream solution already. Does an upstream/backport
> patch for emacs23 exist? in case not the severity of that bug should be
> much higher than normal as it is now! I have had several files corrupted
> due to this bug (fortunately being able to recover them).

I don't know whether there is a patch for emacs23. If I understand
correctly, the change is quite large, but I'm not sure.

-- 
Vincent Lefèvre  - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120726114003.gd6...@xvii.vinc17.org

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

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 installed
(first install or upgrade).

> I do believe that whenever an initscript is called with the argument
> "start", it should bloody well start, and not exit after doing
> nothing because I haven't edited some scarcely related file
> somewhere.

As long as scripts are allowed to execute init scripts directly with
"start" or "restart" (see rsync postinst script, for instance), this
must not be the case. Otherwise there would be no means to disable a
daemon (uninstalling the package would not be a satisfactory solution
because the client may still be useful, such as with rsync).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120730091243.gg6...@xvii.vinc17.org

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

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
> update-rc.d -f rsync remove
> fi
> 
> update-rc.d rsync start 50 2 3 4 5 . >/dev/null
> if [ -x /usr/sbin/invoke-rc.d ]; then
> invoke-rc.d rsync restart
> else
> /etc/init.d/rsync restart
> fi
> fi
> 
> This invokes the service ("runs the init.d script") with invoke-rc.d, if
> available. The rsync postscript should not need to check for invoke-rc.d
> anymore, it's been available in a required package for a long time now,
> but it shouldn't matter, either.

It is currently required, but perhaps not in the future, with other
init systems. I suppose that there will be some document saying that
whatever init system is chosen, update-rc.d and invoke-rc.d must be
available.

IMHO, this is not "should not need to check" but "must not check",
because /usr/sbin/invoke-rc.d may not be there if the system is
broken, and in such a case, trying to start the daemon while the
user may have requested to disable it is bad for the security of
the system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120730101033.gh6...@xvii.vinc17.org

Re: solving the network-manager-in-gnome problem

[Vincent Lefevre]

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 - daemons listed here should start no matter what
> > 
> > This should satisfy all camps ;)
> 
> That should be simple to setup, as the infrastructure exist already: 
> policy.d.
> 
> What I do locally to suppress starting daemons inside chroots is use 
> policyrcd-script-zg2 and then add a [custom script]. That script should 
> be easily changed/extended e.g. using "run-parts --list", and either 
> published at our wiki or released in a package conflicting with 
> policyrcd-script-zg2.

There's a lack of documentation, with examples, e.g. on how to
blacklist a daemon.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120730101609.gi6...@xvii.vinc17.org