Re: weird font corruption caused by scrolling

enshot, 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

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

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 wo

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

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 das

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

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

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

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. Should

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

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:

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

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

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

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&

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

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- > &

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

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

.desktop files of GNOME apps and path to these applications

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 foll

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

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 > || > || me

Shouldn't tar 1.20-1 be in testing?

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 t

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

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 a

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

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/hostna

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

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" ca

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

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 /

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

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

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

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 acc

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

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

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

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 get

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

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. &

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

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 (f

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

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

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

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 d

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

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 host

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

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 >

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

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

Re: Removing the manpage requirement for GUI programs?

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 c

Re: Removing the manpage requirement for GUI programs?

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 applicati

Re: Removing the manpage requirement for GUI programs?

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 f

Re: Removing the manpage requirement for GUI programs?

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:

Re: Removing the manpage requirement for GUI programs?

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 repor

Re: Removing the manpage requirement for GUI programs?

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 f

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?

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 st

Re: RFH: bashisms in configure script

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

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

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.freedes

Re: 38

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 consec

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

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

Re: Make Unicode bugs release critical?

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 >

Re: Make Unicode bugs release critical?

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 tim

Re: Make Unicode bugs release critical?

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: > > > > > Howeve

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

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/li

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

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% accessibl

Re: OT: Python

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. p

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

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 stdou

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

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 vali

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

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 defa

Re: HTTPS everywhere!

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 po

Re: HTTPS everywhere!

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

copyright file and non-secure URL's

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 whe

Re: Solutions for the Apache upgrade hell

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 u

Re: Solutions for the Apache upgrade hell

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 r

Re: Solutions for the Apache upgrade hell

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-upgr

Re: Solutions for the Apache upgrade hell

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

Re: Solutions for the Apache upgrade hell

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 n

Re: Solutions for the Apache upgrade hell

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 nu

aptitude / package purged

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 to

Re: Solutions for the Apache upgrade hell

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 "

Re: Solutions for the Apache upgrade hell

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 b

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

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,

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

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

Re: Solutions for the Apache upgrade hell

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

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)

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 "H

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

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

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

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&#

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

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

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-

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

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, >

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

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. > > b

Re: binary data file and endianness and multiarch

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-

Re: switching from exim to postfix

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 clea

Re: switching from exim to postfix

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

Re: switching from exim to postfix

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: > >> > >> &

Re: Moving /tmp to tmpfs makes it useful

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 d

Re: Moving /tmp to tmpfs makes it useless

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 #6

Re: Starting services automatically after install

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 mus

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

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

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

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

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

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 t

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

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

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

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 b

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

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 > > metho

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

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

Re: glibc very old

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"

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

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

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

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 enabli

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

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 pr

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

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. > >

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

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/defaul

Re: glibc very old

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 w

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

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: > > > > >

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

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 scri

Re: glibc very old

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...? > > > >

Re: emacs23 and/or emacs24 in Wheezy?

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 do

Re: glibc very old

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 s

Re: emacs23 and/or emacs24 in Wheezy?

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

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

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 insta

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

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 >

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

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 wh

  1   2   3   4   5   >