Re: localhost.localdomain

[Pierre Machard]

On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > "localdomain" is not a registered top-level domain and hopefully never
> > will be, so it is safe to use locally as it won't cause communication
> > problems.
> 
> It is not safe to use unregistered domains. and I dont see a reason for
> .localdmain at all.

IIRC The main reason was described in #247734

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Josselin Mouette]

Le jeudi 06 octobre 2005 à 08:33 +0200, Aurelien Jarno a écrit :
> Christoph Martin a écrit :
> > Changes: 
> >  openssl (0.9.8-1) unstable; urgency=low
> >  .
> >* New upstream release (closes: #311826)
> 
> The following list of packages needs to be rebuild, otherwise some of 
> the binary packages they built will be uninstallable after today mirror 
> push. Maybe bug reports has to be filled?
[snip]

Furthermore, as OpenSSL symbols aren't versioned, this will lead to
random crashes if a binary ends up being linked to both version, won't
it?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Marco d'Itri]

On Oct 06, Aurelien Jarno <[EMAIL PROTECTED]> wrote:

> The following list of packages needs to be rebuild, otherwise some of 
> the binary packages they built will be uninstallable after today mirror 
> push. Maybe bug reports has to be filled?
308 bugs are too many.
Starting from next week send a few warning emails to the maintainers,
then we will see.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Peter Samuelson]

[Benjamin Seidenberg]
> I agree. I think that there should be a way to use apt to install a
> .deb with automatic dependency handling (in fact when I first began
> using debian I tried several times to install a .deb using apt). I
> don't know why this functionality was never written. It seems to be
> fairly trivial.

I heard apt-rpm has it.  It does seem simple and useful.  Meanwhile,
since Pre-Depends are used so rarely, just do this:

  dpkg --unpack filename.deb
  apt-get -f install

apt installs the dependencies, then configures the package.  So long as
you don't have unsatisfied pre-depends, and the package doesn't
Conflict with anything on your system (or, of course, vice versa),
it'll work perfectly.

Peter


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am Do den  6. Okt 2005 um  9:10 schrieb Pierre Machard:
> IIRC The main reason was described in #247734

The only reason I find is that RedHat use it. But RedHat shouldn't be
debians requirement of quality. It should be other way around. RedHat is
such a buggy distribution. And it gets more and more worse every
upgrade.

.localdomain is such a peace of shit which only makes troubles. So
please hold the high quality of debian and do not polute it with such
grab.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0TXpJ+OKpjRpO3lAQKXDQgAlbwriA493n0nz2bokES+vU5/k9rwvHPI
68xXHcidn7n0iidB1vDpcRnwA/NrSjZ4Wym6IiQTT2tGbDv5Ot3bv+6pmNvWviGf
GblGGbXwNpvjMhyPORLS9Mg8yqjxFukzKdBlnju5B+JnlqiT0bxiTx67h+wnInZy
62jNLnnXiG7AMPW3hQkTGObzu6NZBOVBA2djHfo7ScSsdEuPPoDORFA+LCrf83CE
/VS9EFoqk4zpI4UPl1CaXmX3C10W6L6nkddgGd0NyqLjKMJ+LpmARVcxnk+uCqEy
5a3YZyWetY0nm/4CEk03BlR4RJP02pyP0t9KiBcUmsDVLsfbYt5hNw==
=nUuy
-END PGP SIGNATURE-


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

Re: new source package producing "old" deb's is not regarded as NEW

[Frank Küster]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> As it happens, due to some changes in the details of the override file
> handling, new source package names will soon make the package go to NEW too,
> even though there already exists a binary package by that name. That the new
> source package name already exists as binary package name is quite
> exceptional, but in this case indeed it matters.

Thank you.  I think these "changes in the details" do the right thing.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Eduard Bloch]

#include 
* Joe Smith [Wed, Oct 05 2005, 08:22:48PM]:
> >I wonder why nobody did implement that feature before. I imagine
> >(without knowing much about APT's internals), the pseudocode would look
> >like that:
> >
> >- install command gets the list
> >- if the package does not exist in the cache and the given string is a
> >  file, then:
> >  - read the metadata of this package
> >  - creating a virtual sources set containing that package and inject
> >   it somewhere in APTs graph representation. The access method
> >would be "file:", and it should get the highest possible priority
> >(at least higher than any seen priority)
> >  - install the prerequisites and then the package with the usual
> >   methods
> >  fi
> 
> would it not be simpler to have have apt just ask dpkg what the 
> dependencies of the passed .deb are and then install the dependencies (and 
> their dependecies) and then just pass the deb directly to dpkg?

Hehe, it was my first thought about a possible solution, howerver: 
You also need the Conflicts string. And while the dependencies/conflicts
are beeing installed, there may appear a constellation where the new
package must be installed during the upgrade. And how would resolve that
situation then?

Eduard.
-- 
Letzte Worte eines Fallschirmspringers bevor er in Bodennebel eintaucht:
  "Die Wolke nehme ich noch mit."


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

Bug#332412: Subject: ITP: shanty -- makes a whopping great postscript file from an image and some text

[Jorge Salamero Sanz]

Package: wnpp
Owner: Jorge Salamero Sanz <[EMAIL PROTECTED]>
Severity: wishlist


* Package name: shanty
  Version : 3
  Upstream Author : Duncan Martin <[EMAIL PROTECTED]>
* URL : http://www.codebunny.org/coding/shanty/
* License : BSD
  Description : makes a whopping great postscript file from an image and 
some text

 Shanty takes a text file and an image (PNG or JPG) and creates a PostScript
 file where one pixel in the image becomes one character in the PostScript.
 You can use it for making posters with the source and logo of your favourite
 opensource project or with the letter and a photograph of your favourite 
group.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Partnership between Our Sites

[replicahause]

Dear webmaster,

I looked at your website - http://lists.debian.org - and I really
liked to be your partner.

I own a site - http://www.replicahause.com- . Since our sites are
not competitive with each other. So, I would like to propose a
link exchange partnership with your site.

My site gets a lot of traffic every day, so a link from my site
to your site will bring in a decent amount of traffic to your
site.

Also, as you probably already know, it will improve the link
popularity and the search engine ranking of your site.

I have already added a link to your site from my site at

http://www.replicahause.com/shopping1.html

I have used the following Title and Description for your site:

Title: Debian Mailing Lists -- Index
Description: Debian Mailing Lists -- Index

I would really appreciate it if you could add a link to my site
in return.

Please use the following information for the link:

Title: Rolex Replica Watches at ReplicaHause.com.
Description: Rolex replica watches, replica rolex watches, fake
rolex watches, replica rolex daytona, replica rolex submariner at
lowest prices
URL: http://www.replicahause.com

Here's the HTML source code that you can copy and paste in your
site:
http://www.replicahause.com";>Rolex Replica Watches at
ReplicaHause.com. - Rolex replica watches, replica rolex
watches, fake rolex watches, replica rolex daytona, replica rolex
submariner at lowest prices

If you link back to me, I will be happy to put your website at
the top of my links page (along with other sites that link back
to me).

If you want me to make any changes to the Title or Description of
your link in my site, or if you have any questions about my
proposal, please feel free to send me an email.

I look forward to hearing from you soon.

Best Regards,

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> .localdomain is such a peace of shit which only makes troubles. So
Please explain which troubles.

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRP57FGfw2OHuP7ERAkZRAJ9DqA/m17uX1aH9bvapR6JVWDnfYgCghyYs
j7aAgYW87Caonmw/uI+0LyI=
=rn9l
-END PGP SIGNATURE-


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

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Marco,

Am Do den  6. Okt 2005 um 12:37 schrieb Marco d'Itri:
> > .localdomain is such a peace of shit which only makes troubles. So
> Please explain which troubles.

I cannot specify it. But I remember that I did search for problemes in
the past long time to find a error. And it was an entry of
localhost.localdomain in a /etc/hosts. Maybe it was PVM or MySQL or
other. I'm not sure.

If you think for localhost you will never anticipate that it is called
localhost.localdomain on one system. The Phrase "localhost" is for
historical reasons such often used in scripts and programms. It whould
create many manyears of troubleshooting putting this .localdomain on the
end.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0UN4Z+OKpjRpO3lAQKwpQf+P0oEJyklcLU+htTuTXg/9KSbqxQl3CtN
1cbcwWacwmhZsHBfsMSBCEheKUFEXl2ZYsG1xOeOQabCk56MdBgSB8OGETBoZI+y
SKlIpAlLpfW+2GzHBHEDukGksk9b2p5Hzk9uNkAI8guHsAHk65loAg99y0w5LmoH
mdXlbgr9vKfYNyiyMbsrpZu8YDitmO9GQkGigm18gEFCdUWHm20G7yUbXH+XIFZ2
VURIHR8uu3kaMzJOneYh0PdxO22eKvNUEgyFWvowDjPodbzLdU6ddl63EIipB4wV
Qygamc+wavijiGHrcvK5tzQ2yAeoddNNcIk48wfpXfoRiuJNdMD4zA==
=oLvm
-END PGP SIGNATURE-


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

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> Am Do den  6. Okt 2005 um 12:37 schrieb Marco d'Itri:
> > > .localdomain is such a peace of shit which only makes troubles. So
> > Please explain which troubles.
> I cannot specify it. But I remember that I did search for problemes in
In other words, you don't know and are just handwaving. Next?

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRQ8iFGfw2OHuP7ERApM3AKCCGy0jpyKaCHimIfTwXQtOiXnwPgCfU0yn
lSNqR02tM/ZFhRWkFTln6wk=
=1GG+
-END PGP SIGNATURE-


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

alternative for pdf-viewer

[Steffen Joeris]

Hi

Is it possible to get an alternative for a pdf-viewer, so that you can 
choose /etc/alternatives/pdf-viewer in the code and this will link to a free 
viewer, e.g. kghostview or gpdf?

Greetings
Steffen


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

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marco,

unfortunality your mail address is not valid so I answer you here.

Am Do den  6. Okt 2005 um 13:48 schrieb Marco d'Itri:
> In other words, you don't know and are just handwaving. Next?

No, I just do not remember which software it was. I absolutely remember
THAT it was a problem with localhost.localdomain and THAT it takes me
long time to debug.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0US3J+OKpjRpO3lAQKm/Qf8CvgeZAZ3wcOkaNZKxDCGcYqBqpc/8GlN
pzdtTE91XcVve4vMri2BIITJru/ch86D8lGWTpYB1AJRSaFnSX2VpMtoRYUFlwkJ
75fYuhy47iJI11+kLhYgtjMb3j69i1oM9tWMxoZmvudygnR13U7FoOXn0K2Sh0OY
7m5dC4KUPxz66+Yxw9TBEI8NflKa3Wa165jCV5juGhpZefzUsEwKZYXJsdhVyFW2
97KQ9Qsp+XgAwqQko8FDCQu/aXmNyWblPfbFzXMY2YlNZ0r+vJLNrVJoRA29JqVK
MgF+f0Y482unI8f04ntxuak7XZBbg+wIP7rhU7n1kBcmbJUhgpil/w==
=uOnq
-END PGP SIGNATURE-


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

Re: localhost.localdomain

[Marco d'Itri]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> unfortunality your mail address is not valid so I answer you here.
My email address is perfectly valid, it's your system which is
misconfigured:

Oct  6 13:42:11 picard postfix/smtpd[4344]: NOQUEUE: reject: RCPT from 
static-195-068.catv.glattnet.ch[80.242.195.68]: 554 : Helo command 
rejected: unqualified HELO hostname; from=<[EMAIL PROTECTED]> to=<[EMAIL 
PROTECTED]> proto=ESMTP helo=

> No, I just do not remember which software it was. I absolutely remember
> THAT it was a problem with localhost.localdomain and THAT it takes me
> long time to debug.
So you know about an unspecified issue with an unspecified program.
It's not much to argue that the current behaviour is broken.

- -- 
ciao,
Marco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRRY1FGfw2OHuP7ERAl/5AJ919fsQCh6fdK1hJvqR51O/dUc03wCfYl4E
2oZhNKKt3X69uJQmd+bUvAE=
=tOXX
-END PGP SIGNATURE-


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

Re: localhost.localdomain

[Wouter Verhelst]

On Thu, Oct 06, 2005 at 02:04:44PM +0200, Klaus Ethgen wrote:
> Hi Marco,
> 
> unfortunality your mail address is not valid so I answer you here.
> 
> Am Do den  6. Okt 2005 um 13:48 schrieb Marco d'Itri:
> > In other words, you don't know and are just handwaving. Next?
> 
> No, I just do not remember which software it was. I absolutely remember
> THAT it was a problem with localhost.localdomain and THAT it takes me
> long time to debug.

That's not helpful.

Problems can have many causes. One of them may be that
localhost.localdomain is unexpected; another may be that the software
you were using is buggy, or misconfigured. Also, it could be that the
problem you experienced back then has been fixed in the mean time.

There's only one way to be sure, and that is to examine the problem in
detail. If it is clear from your example that localhost.localdomain does
indeed cause many problems, we could consider not using it by default
anymore. However, if we find that the problem is just a bug, it would be
better to fix it rather than removing something which many people expect
to be there.

Since you're not providing details, however, this isn't possible, and
the only sensible course of action is to ignore your claims.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: alternative for pdf-viewer

[Frank Küster]

Steffen Joeris <[EMAIL PROTECTED]> wrote:

> Hi
>
> Is it possible to get an alternative for a pdf-viewer, so that you can 
> choose /etc/alternatives/pdf-viewer in the code and this will link to a free 
> viewer, e.g. kghostview or gpdf?

Can't you just use "see $filename" and rely on the mailcap entry?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: localhost.localdomain

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Am Do den  6. Okt 2005 um 14:22 schrieb Wouter Verhelst:
> That's not helpful.

True. Thats the reason why I give more helpfull information too in the
first mail.

> indeed cause many problems, we could consider not using it by default
> anymore. However, if we find that the problem is just a bug, it would be
> better to fix it rather than removing something which many people expect
> to be there.

But why changing "localhost" to "localhost.localdomain" only for the
reason that RedHat doing it? There was everythink OK with the proven
"localhost"-entry. No problemes was encounted with it. The problemes was
at first encounted when changing this localhost entry. It is absolutely
irrelevant if the problemes are exactely specified or not. The point is
that localhost.localdomain MAKES problemes. And it is nothing what makes
sense either.

> Since you're not providing details, however, this isn't possible, and
> the only sensible course of action is to ignore your claims.

Just do what you whant with it. I do not whant to fight. I know how to
edit /etc/hosts. But why the hell should there be so many traps for
users who do not know.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ0Ub05+OKpjRpO3lAQJh1AgAibpUAgROgm+C+2IoqxztMaV4nuNU2y1N
pnNisnml740mjTOW3mNj2ow46lguEWytW/gGDq0AVrKA8+ULEO8Z5u/evpbHL1Ny
oSCizcMCXcRyk1FT1WOxzzisFoUZ9+g6WPCs8CPRZ6l6ld4KJH/5BdFT32k9R8F0
zh3cQCT7XVYq6fzynadM0ZwjJ9GpBiVz/eO/ULou/U2LtEDBWmNyh+Xd+PAzbaXm
0dIPTx+EQIW9G2THpx91LR/YjyRD6X/soTYgoQ9G9K2Oi5IvxfymrTfylBsWrHZF
02u2Sqmt4pBXnPCuY0DiCMfDOZIH0iNJfpuA69yPe3N/O+6OB3sU8w==
=GdtM
-END PGP SIGNATURE-


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

Re: alternative for pdf-viewer

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please avoid cross-posting.

And if you do it anyway, then make sure to indicate a single list to
continue discussion.

As your question is not specific to the development of Linux for
schools, I propose to post replies only on -devel.


Kind regards,

 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRRfzn7DbMsAkQLgRAn69AJ9seoAp4YNWIl82AjIFW0kSdn12RQCghXC7
03vjPTSB0CHLgEKyu/t84cA=
=FBHf
-END PGP SIGNATURE-

Re: localhost.localdomain

[Steve Greenland]

On 06-Oct-05, 07:22 (CDT), Wouter Verhelst <[EMAIL PROTECTED]> wrote: 
> On Thu, Oct 06, 2005 at 02:04:44PM +0200, Klaus Ethgen wrote:
> Problems can have many causes. One of them may be that
> localhost.localdomain is unexpected; another may be that the software
> you were using is buggy, or misconfigured. Also, it could be that the
> problem you experienced back then has been fixed in the mean time.

When proposing a variation from long-standing historical practice,
shouldn't the onus be on the on making the change? What problem does
'localhost.localdomain' solve? Why is is better than just 'localhost',
which has been common practice for oh, what, 20+ years?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

applet showing the current XkbLayout

[gustavo halperin]

Hello



I'm using enlightenment without KDE and without Gnome. My XFree86 is 
configured with three keyboard layout:

  
Option 
"XkbLayout" "es,il,us"

  
Option 
"XkbOptions"    "grp:shift_toggle"

My question is how I can cache when ever the keyboard Layout change and 
which one is the current, this in order

to write an applet for enlightenment and X showing an ensign of the current 
country Layout.



Thank you in advance



 Gustavo Halperin

When is the C++ transition needed?

[Henning Makholm]

I notice that the newest upload of pstoedit has reverted the C++
transition name change; instead of libpstoedit0c2 sid now contains
libpstoedit0, as in sarge.

However, the library exports things with interfaces such as

#ifdef __cplusplus
extern "C" DLLEXPORT
int pstoeditwithghostscript(int argc,
const char *
const argv[],
ostream& errstream,
const DescriptionRegister* const pushinsPtr=0
);
#endif

Does this not need transitioning for the ABI change?

For example, if an existing client program passes a subclass of
libstdc++5's ostream as the 'errstream' parameter, will the libstdc++6
version of libpstoedit0 know how to call its methods correctly?

If the answer is, "don't fear, this will actually work", then where is
that documented?  And shouldn't the reasoning be referenced from the
pstoedit changelog, anyway?

-- 
Henning Makholm  "So you're nostalgic for a whole two-month period?"


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

Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Hi everyone!

I know the copying conditions of IETF RFC's has been a concern for
Debian in the past, and that the RFCs has been removed from the
official archive (?), so I thought this would be of some interest to
you.  I am trying to influence the IETF to change the copying
conditions on RFCs to make them more free software friendly.

I explain the current problems, and I try to put together a proposed
update, and I have a petition online at:

http://josefsson.org/bcp78broken/

If you support this effort, or want to help, please sign the petition
or lend me some help!  Help with drafting the new license terms is
especially needed.

If the entire Debian organization want to support this effort, that
would be excellent, but just having a few Debian developers sign it
would help.

Thanks,
Simon


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Jonas Meurer]

On 06/10/2005 Aurelien Jarno wrote:
> Christoph Martin a écrit :
> >Changes: 
> > openssl (0.9.8-1) unstable; urgency=low
> > .
> >   * New upstream release (closes: #311826)
> 
> The following list of packages needs to be rebuild, otherwise some of 
> the binary packages they built will be uninstallable after today mirror 
> push. Maybe bug reports has to be filled?
> 
> conserver

this package does not exist in debian

> ldmud

that one exists only in stable and oldstable

here's the list of all packages except these two sorted by maintainers,
thanks to dd-list from devscripts:


Laszlo Boszormenyi (GCS) <[EMAIL PROTECTED]>
   neon

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier
   pure-ftpd

Richard A Nelson (Rick) <[EMAIL PROTECTED]>
   sendmail

Eric Schwartz (Skif) <[EMAIL PROTECTED]>
   yaz

Davide Puricelli (evo) <[EMAIL PROTECTED]>
   xchat

Jacek �liwerski (rzyjontko) <[EMAIL PROTECTED]>
   elmo

Stefan Alfredsson <[EMAIL PROTECTED]>
   monit

Russ Allbery <[EMAIL PROTECTED]>
   webauth

Domenico Andreoli <[EMAIL PROTECTED]>
   curl
   libapache-mod-ssl
   tclcurl

Richard Atterer <[EMAIL PROTECTED]>
   jigdo
   w3c-libwww

SZALAY Attila <[EMAIL PROTECTED]>
   libzorpll
   zorp

Julien BLACHE <[EMAIL PROTECTED]>
   d4x

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   libofx

Miros/law L. Baran <[EMAIL PROTECTED]>
   epic4

Dima Barsky <[EMAIL PROTECTED]>
   cyrus-sasl2
   m2crypto

Brian Bassett <[EMAIL PROTECTED]>
   entity

Dave Beckett <[EMAIL PROTECTED]>
   raptor
   rasqal
   redland
   redland-bindings

Ian Beckwith <[EMAIL PROTECTED]>
   netkit-telnet-ssl

Luciano Bello <[EMAIL PROTECTED]>
   davfs2

John V. Belmonte <[EMAIL PROTECTED]>
   xmlsec1

Hilko Bengen <[EMAIL PROTECTED]>
   nail

Michael Biebl <[EMAIL PROTECTED]>
   kdesvn
   partimage

Bastian Blank <[EMAIL PROTECTED]>
   omniorb4

Blars Blarson <[EMAIL PROTECTED]>
   suck

Eduard Bloch <[EMAIL PROTECTED]>
   encfs

Phil Blundell <[EMAIL PROTECTED]>
   dillo

Regis Boudin <[EMAIL PROTECTED]>
   tellico

Nicolas Boullis <[EMAIL PROTECTED]>
   isync

Jeremy T. Bouse <[EMAIL PROTECTED]>
   fwbuilder
   libesmtp
   libfwbuilder
   libgcgi

Ludovic Brenta <[EMAIL PROTECTED]>
   libaws

Ben Burton <[EMAIL PROTECTED]>
   kdesdk

Petr Cech <[EMAIL PROTECTED]>
   pavuk

Christopher L Cheney <[EMAIL PROTECTED]>
   vorbis-tools

Pierre Chifflier <[EMAIL PROTECTED]>
   newpki-client
   newpki-lib
   newpki-server

Russell Coker <[EMAIL PROTECTED]>
   postal

Jamin W. Collins <[EMAIL PROTECTED]>
   jabber
   jabber-jud
   jabber-muc
   jabber-yahoo

Eric Cooper <[EMAIL PROTECTED]>
   approx

Julien Danjou <[EMAIL PROTECTED]>
   telak

Frederik Dannemare <[EMAIL PROTECTED]>
   clamcour

LI Daobing <[EMAIL PROTECTED]>
   qterm

Debian Apache Maintainers 
   apache
   apache2

Debian OpenOffice Team 
   neon0.23

Debian Qt/KDE Maintainers 
   kdebase
   kdenetwork

Murat Demirten <[EMAIL PROTECTED]>
   ettercap
   sim

Grzegorz Prokopski (Debian Developer) <[EMAIL PROTECTED]>
   opendchub

Jean-Francois Dive <[EMAIL PROTECTED]>
   isakmpd

Eric Dorland <[EMAIL PROTECTED]>
   opensc

Paul Dwerryhouse <[EMAIL PROTECTED]>
   kannel

Dirk Eddelbuettel <[EMAIL PROTECTED]>
   linuxtrade

Peter Eisentraut <[EMAIL PROTECTED]>
   licq

Rene Engelhard <[EMAIL PROTECTED]>
   aria

Raphael Enrici <[EMAIL PROTECTED]>
   pgadmin3

Carey Evans <[EMAIL PROTECTED]>
   tn5250

Eric Evans <[EMAIL PROTECTED]>
   xsupplicant

Peter Van Eynde <[EMAIL PROTECTED]>
   cl-ssl

Tomas Fasth <[EMAIL PROTECTED]>
   rdesktop

Duncan Findlay <[EMAIL PROTECTED]>
   spamassassin

José Fonseca <[EMAIL PROTECTED]>
   esmtp

Romain Francoise <[EMAIL PROTECTED]>
   tcpdump

Jochen Friedrich <[EMAIL PROTECTED]>
   net-snmp
   ucd-snmp

Wilmer van der Gaast <[EMAIL PROTECTED]>
   ctrlproxy

Hector Garcia <[EMAIL PROTECTED]>
   zmailer

David Moreno Garza <[EMAIL PROTECTED]>
   xmms

RISKO Gergely <[EMAIL PROTECTED]>
   starttls

Daniel Glassey <[EMAIL PROTECTED]>
   bibletime
   gnomesword
   sword

Henning Glawe <[EMAIL PROTECTED]>
   libgwenhywfar

Francois-Denis Gonthier <[EMAIL PROTECTED]>
   erlang

Stephen Gran <[EMAIL PROTECTED]>
   clamav

Debian Perl Group <[EMAIL PROTECTED]>
   libwww-curl-perl

Yu Guanghui <[EMAIL PROTECTED]>
   qpopper

Marc Haber <[EMAIL PROTECTED]>
   rageircd

Fredrik Hallenberg <[EMAIL PROTECTED]>
   asmail

Chris Halls <[EMAIL PROTECTED]>
   ayttm

Chris Hanson <[EMAIL PROTECTED]>
   mit-scheme

Sam Hartman <[EMAIL PROTECTED]>
   openssh-krb5

Peter Hawkins <[EMAIL PROTECTED]>
   python-ldap

Adam Heath <[EMAIL PROTECTED]>
   xen

Tollef Fog Heen <[EMAIL PROTECTED]>
   cfengine

Dan Helfman <[EMAIL PROTECTED]>
   libnet-tclink-perl
   php4-tclink
   python-tclink

Gregor Hoffleit <[EMAIL PROTECTED]>
   python2.1

Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
   cyrus21-imapd
   hplip

Simon Horman <[EMAIL PROTECTED]>
   heartbeat
   heartbeat-2
   perdition

Alex Hudson <[EMAIL PROTECTED]>
   hula

Philipp Hug <[EMAIL PROTECTED]>
   mnogosearch

Re: localhost.localdomain

[Stefano Zacchiroli]

On Thu, Oct 06, 2005 at 01:43:29PM +0200, Klaus Ethgen wrote:
> I cannot specify it. But I remember that I did search for problemes in
> the past long time to find a error. And it was an entry of
> localhost.localdomain in a /etc/hosts. Maybe it was PVM or MySQL or
> other. I'm not sure.

IIRC leafnode complains about "localhost.localdomain" refusing to suck
news unless you manually specify a domainname in its configuration file.
Maybe you remember that trouble?

Still, I've ever considered that an issue with leafnode, not of
"localhost.localdomain".

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: localhost.localdomain

[John Hasler]

Klaus Ethgen writes:
> Thats the reason why I give more helpfull information too in the first
> mail.

You haven't given enough information.

> But why changing "localhost" to "localhost.localdomain"...

It wasn't changed.  "localhost.localdomain" was _added_.  "localhost" is
still there.

> There was everythink OK with the proven "localhost"-entry. No problemes
> was encounted with it.

There were problems that the addition of "localhost.localdomain" were
intended to solve.  You may not have personally experienced them but many
others did.

> It is absolutely irrelevant if the problemes are exactely specified or
> not.

If the addition of "localhost.localdomain" caused you a problem we need to
know exactly what it was so that we can fix it.
-- 
John Hasler


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

Re: dh_libtool proposal (-dev dependencies on -dev from libtool)

[Stephen Frost]

* Peter Samuelson ([EMAIL PROTECTED]) wrote:
> I'd argue to go one step further and invent a virtual package like
> 'no-static-link-support' (well, a shorter name would be better) and
> generate each dependency on "libfoo-dev | no-static-link-support".
> Then I can install one little equivs package to prevent installing a
> bunch of -dev packages I don't need.
> 
> But maybe that's just me.

It's not just you, but unfortuately libtool breaks when a .la file goes
missing.  It seems to me that's the main issue, and that should be
fixed.  Once that's fixed the need for the dependencies actually goes
away entirely.  The .la files aren't needed for doing shared libraries
and in general (and this is true for many non-libtool-using things) we
don't include static library dependencies in the Depends.  libtool does
actually survive just fine if the first-level .la files go missing in
fact, as I recall, it's the ones below that which cause it to break,
even for shared linking when none of them are needed at all anyway. :/

In the end I think this is a bad idea and we should instead focus and
spend time on fixing the actual problem than trying to build some hack
around it.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 06, 2005 at 07:31:37AM -0500, Steve Greenland wrote:

> When proposing a variation from long-standing historical practice,
> shouldn't the onus be on the on making the change? What problem does
> 'localhost.localdomain' solve? Why is is better than just 'localhost',
> which has been common practice for oh, what, 20+ years?

It's being long-standing does not mean it's correct. I started looking
for any standards or RFCs that require that the address 127.0.0.1 should
resolve to "localhost" but I could only find some recommendations for
DNS administrators, and _nothing_ about /etc/hosts. Therefore I'd be
inclined to say that if an application does not accept 127.0.0.1 being
resolved to e.g. "foo" then it is is broken, and this is not changed by
the fact that it has been broken for 20+ years.

There are other long-standing misunderstanding in network setup (just
think about the stupidity of "hostname --fqdn"). Let's fix the bugs in
the applications instead of religiously following bad assumptions made
in the past.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Marco d'Itri wrote:
> On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:
> > .localdomain is such a peace of shit which only makes troubles. So
> Please explain which troubles.

Some programs will try to solve the reverse for 127.0.0.1, during normal
operations (not to verify WHAT 127.0.0.1 points to, but because it is doing
reverse DNS for every connection, and one just came over lo).  

Some of these programs, due to utter braindamage, special-case the string
"localhost".  Change that, and they break.  Mysql is the highest profile
case, apparently.

Still, WHAT does a canonical name of localhost.localdomain. for 127.0.0.1
brings us?  It is completely useless, it adds no extra functionality over a
plain canonical name of "localhost".  And it breaks badly designed
applications.  While it pains me to say so (I absolutely *loathe* bad
design), reverting that completely useless change looks like a very good
idea to me.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Gabor Gombas wrote:
> It's being long-standing does not mean it's correct. I started looking

But it means it is a de-facto standard, which it *is*.  Every *nix system I
have mucked around with in the last five years, with the exception of a few
Linux distributions, uses plain "localhost".

> DNS administrators, and _nothing_ about /etc/hosts. Therefore I'd be

/etc/hosts is a local implementation detail, it won't make it to RFCs while
there is still a bit of sanity in the world.  It is probably in a POSIX-like
standard, though.

> inclined to say that if an application does not accept 127.0.0.1 being
> resolved to e.g. "foo" then it is is broken, and this is not changed by
> the fact that it has been broken for 20+ years.

That is correct, yes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, John Hasler wrote:
> > But why changing "localhost" to "localhost.localdomain"...
> 
> It wasn't changed.  "localhost.localdomain" was _added_.  "localhost" is
> still there.

The first entry is the canonical name, and it is what the reverse maps to.
So yes, it WAS changed, and very much so.

> There were problems that the addition of "localhost.localdomain" were
> intended to solve.  You may not have personally experienced them but many
> others did.

Now, that is interesting.  Which problems?  I honestly don't know of any.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: dh_libtool proposal (-dev dependencies on -dev from libtool)

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Stephen Frost wrote:
> don't include static library dependencies in the Depends.  libtool does
> actually survive just fine if the first-level .la files go missing in

Correct.

> fact, as I recall, it's the ones below that which cause it to break,
> even for shared linking when none of them are needed at all anyway. :/

Which is clearly a hideous bug, and upstream acknowledges this.

> In the end I think this is a bad idea and we should instead focus and
> spend time on fixing the actual problem than trying to build some hack
> around it.

Seconded. No dh_libtool, please.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: dh_libtool proposal (-dev dependencies on -dev from libtool)

[Jay Berkenbilt]

Hello all.  I've read enough of this thread to be convinced that
dh_libtool is not a good idea and not worth pursuing.  Thanks for all
the insightful comments.

Perhaps a lintian check, as suggested by Joey Hess in the bug 192008
would be better, or perhaps we should just focus energies on fixing
the underlying problem as many suggested.

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>


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

Re: localhost.localdomain

[Steve Greenland]

On 06-Oct-05, 08:25 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: 
> 
> It's being long-standing does not mean it's correct.

No, but it doesn't make changing it correct, either.

Again: what actual technical problem is solved by
'localhost.localdomain"? Is solving that problem worth the potential
breakage of existing code that assumes gethostbyaddr(127.0.0.1) ==
"localhost". Note that I'm not arguing such code is correct, but I don't
see the need to pointlessly break it.

There are lots of long-standing characteristics of Unix systems that
are not required by RFCs or Posix standards, yet we don't go about
arbitrarily changing them.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Aurelien Jarno wrote:
> The following list of packages needs to be rebuild, otherwise some of 
> the binary packages they built will be uninstallable after today mirror 
> push. Maybe bug reports has to be filled?

Next time, please give us at least a three-days advance warning...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Henrique de Moraes Holschuh]

Is there any chances of versioning openssl symbols properly?

I am not asking for 0.9.7 and 0.9.8 to coexist (although versioned symbols
would make that trivial), but PLEASE version the symbols.

Suggested version tag:  OPENSSL_0_9_8

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[sean finney]

On Thu, Oct 06, 2005 at 08:33:19AM +0200, Aurelien Jarno wrote:
> Christoph Martin a écrit :
> >Changes: 
> > openssl (0.9.8-1) unstable; urgency=low
> > .
> >   * New upstream release (closes: #311826)
> 
> The following list of packages needs to be rebuild, otherwise some of 
> the binary packages they built will be uninstallable after today mirror 
> push. Maybe bug reports has to be filled?

this seems to me like something that would qualify as a "significant
transition", and i'm wondering why this was not announced ahead of time?
i don't think it's good practice to upload anything that breaks over
300 packages in debian without at least some preliminary
announcement/discussion.

and furthermore, there are some of us who have been quietly waiting for
things to settle down from the previous major transitions before doing
our own, at the request of the release team.


sean

ps - i'd also like to second the request for symbol versioning.

-- 


signature.asc
Description: Digital signature

Re: alternative for pdf-viewer

[Hamish Moffatt]

On Thu, Oct 06, 2005 at 02:32:53PM +0200, Frank Küster wrote:
> Steffen Joeris <[EMAIL PROTECTED]> wrote:
> > Is it possible to get an alternative for a pdf-viewer, so that you can 
> > choose /etc/alternatives/pdf-viewer in the code and this will link to a 
> > free 
> > viewer, e.g. kghostview or gpdf?
> 
> Can't you just use "see $filename" and rely on the mailcap entry?

That's my suggestion too.

There's a whacky bug report against Xpdf about this (#257651).
I still don't know what to do with it.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: localhost.localdomain

[John Hasler]

I wrote:
> It wasn't changed.  "localhost.localdomain" was _added_.  "localhost" is
> still there.

Henrique de Moraes Holschuh writes:
> The first entry is the canonical name, and it is what the reverse maps
> to.  So yes, it WAS changed, and very much so.

The OP seemed to me to be implying that "localhost" had been deleted and
replaced by "localhost.localdomain".

> Now, that is interesting.  Which problems?  I honestly don't know of any.

Read the discussion in the bug report.  I think "localhost.localdomain" is
ugly, but adding it seems much more feasible than fixing all the broken
software.
-- 
John Hasler


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Frank Küster]

sean finney <[EMAIL PROTECTED]> wrote:

> and furthermore, there are some of us who have been quietly waiting for
> things to settle down from the previous major transitions before doing
> our own, at the request of the release team.

I'm only following d-d-a, -private, and -devel, but that only partly,
and *I* have not yet read anywhere that transitions are allowed again at
all.  If they are and I had known, it would have saved me quite some
work... 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> > > "localdomain" is not a registered top-level domain and hopefully never
> > > will be, so it is safe to use locally as it won't cause communication
> > > problems.
> > 
> > It is not safe to use unregistered domains. and I dont see a reason for
> > .localdmain at all.
> 
> IIRC The main reason was described in #247734

ARGH!

If that bug was the reason why the localhost entry in /etc/hosts was
changed, then please fix it right back to what it was.

The localhost.localdomain stuff appeared from nowhere in an email by Pierre
Machard during the discursion, and stayed on all other examples while people
tried to fix an issue (which has a fucking old proper solution, which is to
use another loopback IP and if needed, another lo alias) that had nothing to
do with it.

Pierre, WHY do you need localhost.localdomain? That is NOT clear in the bug
report.  And the rest of the bug report is about another issue completely,
dealing with people not being able to grasp the idea that if you need a
canonical hostname other than localhost, you need another interface (which
can be "lo" just as well, but give it another IP).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, John Hasler wrote:
> Read the discussion in the bug report.  I think "localhost.localdomain" is

I did. "localhost.localdomain" solved no problems, it was not even related
to the problem they were trying to fix, and it certainly is not part of the
best compromise solution (add another IP to loopback and use that for the
canonical hostname).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Alastair McKinstry wrote:
> On Thu, 2005-10-06 at 11:24 -0300, Henrique de Moraes Holschuh wrote:
> > Is there any chances of versioning openssl symbols properly?
> > 
> > I am not asking for 0.9.7 and 0.9.8 to coexist (although versioned symbols
> > would make that trivial), but PLEASE version the symbols.
> > 
> > Suggested version tag:  OPENSSL_0_9_8
> 
> minor point, but in the name of consistency could we use version tags of
> the form OPENSSL_0.9.8, matching e.g. GLIBC_2.0 , etc. 

Sure.  As long as it is versioned and the version changes with the ABI, I
will be very happy :-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Alastair McKinstry]

On Thu, 2005-10-06 at 11:24 -0300, Henrique de Moraes Holschuh wrote:
> Is there any chances of versioning openssl symbols properly?
> 
> I am not asking for 0.9.7 and 0.9.8 to coexist (although versioned symbols
> would make that trivial), but PLEASE version the symbols.
> 
> Suggested version tag:  OPENSSL_0_9_8


minor point, but in the name of consistency could we use version tags of
the form OPENSSL_0.9.8, matching e.g. GLIBC_2.0 , etc. 

Regards
Alastair

> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> 
> 


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

Re: alternative for pdf-viewer

[Frank Küster]

Hamish Moffatt <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 06, 2005 at 02:32:53PM +0200, Frank Küster wrote:
>> Steffen Joeris <[EMAIL PROTECTED]> wrote:
>> > Is it possible to get an alternative for a pdf-viewer, so that you can 
>> > choose /etc/alternatives/pdf-viewer in the code and this will link to a 
>> > free 
>> > viewer, e.g. kghostview or gpdf?
>> 
>> Can't you just use "see $filename" and rely on the mailcap entry?
>
> That's my suggestion too.
>
> There's a whacky bug report against Xpdf about this (#257651).
> I still don't know what to do with it.

If using mailcap.order is indeed "quite tricky for most people" as the
submitter writes, maybe it would be better to implement some interactive
frontend frontend¹ for mailcap.order.  This would solve the problem
generally, not only for pdf files, and fix or prevent similar bugs for
other types of files.

Regards, Frank

¹it would parse /etc/mailcap and/or /usr/lib/mime/ and generate a list
of MIME types with their associated programs, allow to select one of
them to take priority, and create the mailcap.order file accordingly

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [051006 17:13]:
> sean finney <[EMAIL PROTECTED]> wrote:
> 
> > and furthermore, there are some of us who have been quietly waiting for
> > things to settle down from the previous major transitions before doing
> > our own, at the request of the release team.
> 
> I'm only following d-d-a, -private, and -devel, but that only partly,
> and *I* have not yet read anywhere that transitions are allowed again at
> all.  If they are and I had known, it would have saved me quite some
> work... 

You are right - as so often.

People are still required to speak with the release team first. But some
people prefer to make all of our life harder then necessary.

Please again: If someone wants to make any transition, please speak
*first* with the release team. Do not just assume you can upload just
anything. We really want to finish the c++-abi-transition first.



Cheers,
Andi


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Josselin Mouette wrote:
> Furthermore, as OpenSSL symbols aren't versioned, this will lead to
> random crashes if a binary ends up being linked to both version, won't
> it?

Oh crap!

OpenSSL *must* version its symbols, it is the kind of lib that ends up
linked to libs that end up linked into other libs or even worse, end up in
nsswitch modules and thus shadow-linked to every dang thing in the system.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: When is the C++ transition needed?

[Brian M. Carlson]

On Thursday 06 October 2005 12:45, Henning Makholm wrote:
> I notice that the newest upload of pstoedit has reverted the C++
> transition name change; instead of libpstoedit0c2 sid now contains
> libpstoedit0, as in sarge.

This is, IMHO, incorrect.

> However, the library exports things with interfaces such as
>
> #ifdef __cplusplus
> extern "C" DLLEXPORT
> int pstoeditwithghostscript(int argc,
> const char *
> const argv[],
> ostream& errstream,

You must not pass by reference with an extern "C" declaration, because C 
doesn't support that.

> const DescriptionRegister* const pushinsPtr=0

You also must not use default parameters, as C does not support that.  The 
alternative implementation with one less/one more parameter would also not 
work because C does not mangle names.

> );
> #endif
>
> Does this not need transitioning for the ABI change?

It does need transitioning.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)


pgpKMO1eXO7Hs.pgp
Description: PGP signature

Re: When is the C++ transition needed?

[Olaf van der Spek]

On 10/6/05, Brian M. Carlson <[EMAIL PROTECTED]> wrote:
> On Thursday 06 October 2005 12:45, Henning Makholm wrote:
> > I notice that the newest upload of pstoedit has reverted the C++
> > transition name change; instead of libpstoedit0c2 sid now contains
> > libpstoedit0, as in sarge.
>
> This is, IMHO, incorrect.
>
> > However, the library exports things with interfaces such as
> >
> > #ifdef __cplusplus
> > extern "C" DLLEXPORT
> > int pstoeditwithghostscript(int argc,
> > const char *
> > const argv[],
> > ostream& errstream,
>
> You must not pass by reference with an extern "C" declaration, because C
> doesn't support that.

ostream sounds like C++ too.

Re: localhost.localdomain

[Pierre Machard]

Hi,

On Thu, Oct 06, 2005 at 12:24:12PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Pierre Machard wrote:
> > On Sat, Sep 24, 2005 at 08:33:25PM +0200, Bernd Eckenfels wrote:
> > > In article <[EMAIL PROTECTED]> you wrote:
> > > > "localdomain" is not a registered top-level domain and hopefully never
> > > > will be, so it is safe to use locally as it won't cause communication
> > > > problems.
> > > 
> > > It is not safe to use unregistered domains. and I dont see a reason for
> > > .localdmain at all.
> > 
> > IIRC The main reason was described in #247734
> 
> ARGH!
> 
> If that bug was the reason why the localhost entry in /etc/hosts was
> changed, then please fix it right back to what it was.
> 
> The localhost.localdomain stuff appeared from nowhere in an email by Pierre
> Machard during the discursion, and stayed on all other examples while people
> tried to fix an issue (which has a fucking old proper solution, which is to
> use another loopback IP and if needed, another lo alias) that had nothing to
> do with it.

I can not remember precisely. I think that at that time I was testing the
debian-installer and I saw it was taken a long while to boot. I saw
that my system had no FQDN (hostname -f). When you add .localdomain, the
FQDN is complete and it helps to solve timeout in several application.

Anyway I do not understand why this issue is a problem since we
simply add an alias to localhost. Nobody say  that we will remove 
localhost and exchange it by localhost.localdomain.

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Joey Hess]

Jonas Meurer wrote:
> > conserver
> 
> this package does not exist in debian

It's in non-free

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Joe Smith]

"Eduard Bloch" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



would it not be simpler to have have apt just ask dpkg what the
dependencies of the passed .deb are and then install the dependencies 
(and

their dependecies) and then just pass the deb directly to dpkg?


Hehe, it was my first thought about a possible solution, howerver:
You also need the Conflicts string. And while the dependencies/conflicts
are beeing installed, there may appear a constellation where the new
package must be installed during the upgrade. And how would resolve that
situation then?

Very good point, however one slight problem: if the package needs to be 
installed as a dependency of itself directly or indirectly then there is a 
circular dependecy which as we know is a bad thing. In fact I'm a little 
surprised that dependencies are not treated like predepends are, as that 
would prevent circular dependencies. As they are a bad thing, such a system 
seems like a good idea.


I do however ack the potential for problems with 'conflicts', although I'm 
not sure that that is really a big deal, as installing the dependencies by 
hand, and then dpkg -i would also have the conflicts situation. 




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

Re: localhost.localdomain

[Russ Allbery]

Marco d'Itri <[EMAIL PROTECTED]> writes:
> On Oct 06, Klaus Ethgen <[EMAIL PROTECTED]> wrote:

>> .localdomain is such a peace of shit which only makes troubles. So

> Please explain which troubles.

See the news.software.nntp traffic with people having strange problems
with pathnames and message ID generation because of .localdomain.  There
have been a few separate cases of that over the past year or so.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Effort to change IETF's copying conditions for RFCs

[Florian Weimer]

* Simon Josefsson:

> I explain the current problems, and I try to put together a proposed
> update, and I have a petition online at:
>
> http://josefsson.org/bcp78broken/

Very nice, thanks.

I think you might get broader support in the vendor community if you
make the license for modified copying non-copyleft.


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

Re: localhost.localdomain

[Gabor Gombas]

On Thu, Oct 06, 2005 at 07:44:42PM +0200, Pierre Machard wrote:

> I can not remember precisely. I think that at that time I was testing the
> debian-installer and I saw it was taken a long while to boot. I saw
> that my system had no FQDN (hostname -f). When you add .localdomain, the
> FQDN is complete and it helps to solve timeout in several application.

So it was just papering over a real bug, namely the existence of the
"-f" option of hostname. "hostname -f" assumes that the hostname (as
returned by gethostname(3)) has something to do with networking, which
is false. It also assumes that the system has just one IP address with
one FQDN which is also false.

This is a perfect example of a long-standing assumption that was wrong
from the start but tended to work in the past when the wast majority of
computers had really just one network interface with one IP address, and
the few machines having multiple NICs/multiple IP addresses had good
sysadmins who could deal with the breakage caused by this assumption.

Nowadays even desktop boards start to come with multiple NICs on-board
so this "one IP - one FQDN" assumption must be stopped. "hostname -f"
must be killed, and everything that uses it must be fixed. Well, it may
take some time to sort out all the details, there are a _lot_ of broken
programs out there...

> Anyway I do not understand why this issue is a problem since we
> simply add an alias to localhost. Nobody say  that we will remove 
> localhost and exchange it by localhost.localdomain.

Broken software compares reverse_lookup({127.0.0.1}) with the string
"localhost" and is surprised when it gets FALSE due to the reverse
lookup returning "localhost.localdomain" instead of just "localhost".

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> Anyway I do not understand why this issue is a problem since we

Because instead of doing this:

127.0.0.1 localost localhost.localdomain

It was done like this:

127.0.0.1 localhost.localdomain localhost

Thus changing the canonical name of the loopback interface.  PLEASE do not
do this unless you have *extremely* good reasons to do so.  An untracked DNS
timeout is definately not one.  If you can still reproduce the problem, we
can work on tracking that thing down without the localhost.localdomain.

Add a new loopback interface (say, 127.0.0.2) and name it however you want.
That will not break anything at all, and it allows you to name your system
in whatever way you might want.  This is what d-i should be doing, it is the
maximum compatibility path.

You don't even need to add a new interface if you use iproute instead of
outdated ifconfig crap, and you might get away without even that much (but I
wouldn't try it, I don't think trying to bind a socket to an IP that is not
local (even if it pings because of lo and the /8 netmask) is a very safe
thing to do).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Marco d'Itri]

On Oct 06, Russ Allbery <[EMAIL PROTECTED]> wrote:

> See the news.software.nntp traffic with people having strange problems
> with pathnames and message ID generation because of .localdomain.  There
> have been a few separate cases of that over the past year or so.
Not relevant. They would have the same problems with 127.0.0.1 = localhost.

(Not that I'm arguing either way, anyway.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Marco d'Itri]

On Oct 06, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> Because instead of doing this:
> 
> 127.0.0.1 localost localhost.localdomain
> 
> It was done like this:
> 
> 127.0.0.1 localhost.localdomain localhost
> 
> Thus changing the canonical name of the loopback interface.  PLEASE do not
> do this unless you have *extremely* good reasons to do so.  An untracked DNS
Agreed.

Another point is that it would be bad to have 127.0.0.1 resolve
differently in /etc/hosts and DNS (we ship a 127.in-addr.arpa zone).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Pierre Machard]

On Thu, Oct 06, 2005 at 03:23:45PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Pierre Machard wrote:
> > Anyway I do not understand why this issue is a problem since we
> 
> Because instead of doing this:
> 
> 127.0.0.1 localost localhost.localdomain
> 
> It was done like this:
> 
> 127.0.0.1 localhost.localdomain localhost
> 
> Thus changing the canonical name of the loopback interface.  PLEASE do not
> do this unless you have *extremely* good reasons to do so.  An untracked DNS
> timeout is definately not one.  If you can still reproduce the problem, we
> can work on tracking that thing down without the localhost.localdomain.

The fact is that nobody complained about that... and my bug was
repported more than one year and a half ago. Plus It was disscussed on 
debian-devel. Please do not argue with me!

I do not pretend that I know anything in name resolution, however I
proposed something that worked on my system. It was widely discussed. I
joined this current thread to show people who do not read -devel every day 
that we have already talk about it. Nothing more, nothing less.

Please have a look at:
http://lists.debian.org/debian-devel/2004/06/thrd2.html
Subject: /etc/hosts: Two lines with the same IP address? by Thomas Hood

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: localhost.localdomain

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I can not remember precisely. I think that at that time I was testing the
> debian-installer and I saw it was taken a long while to boot. I saw
> that my system had no FQDN (hostname -f). When you add .localdomain, the
> FQDN is complete and it helps to solve timeout in several application.

Nope, hostname is not responsible for this.

Yes you need to configure the FQDN in hosts, but not with the 127.0.0.1
entry. And hostname should also never return this stupid dummy FQDN (however
it does not avoid to do so).

> Anyway I do not understand why this issue is a problem since we
> simply add an alias to localhost.

The problem is that it is the _first_ alias.

Gruss
Bernd


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

Re: When is the C++ transition needed?

[Daniel Jacobowitz]

On Thu, Oct 06, 2005 at 05:35:34PM +, Brian M. Carlson wrote:
> On Thursday 06 October 2005 12:45, Henning Makholm wrote:
> > I notice that the newest upload of pstoedit has reverted the C++
> > transition name change; instead of libpstoedit0c2 sid now contains
> > libpstoedit0, as in sarge.
> 
> This is, IMHO, incorrect.
> 
> > However, the library exports things with interfaces such as
> >
> > #ifdef __cplusplus
> > extern "C" DLLEXPORT
> > int pstoeditwithghostscript(int argc,
> > const char *
> > const argv[],
> > ostream& errstream,
> 
> You must not pass by reference with an extern "C" declaration, because C 
> doesn't support that.

Why not?  An extern C definition doesn't mean that it needs to be
usable from C.  It just means to use the C calling convention.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: localhost.localdomain

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> Because instead of doing this:
> 
> 127.0.0.1 localost localhost.localdomain
> 
> It was done like this:
> 
> 127.0.0.1 localhost.localdomain localhost
>
> Thus changing the canonical name of the loopback interface.  PLEASE do not
> do this unless you have *extremely* good reasons to do so.  An untracked DNS
> timeout is definately not one.  If you can still reproduce the problem, we
> can work on tracking that thing down without the localhost.localdomain.

FWIW, it was done as a result of bug #247734, which includes details on
how every possible choice seems to break something and the reasoning
that led to the current choice.

> Add a new loopback interface (say, 127.0.0.2) and name it however you want.
> That will not break anything at all, and it allows you to name your system
> in whatever way you might want.  This is what d-i should be doing, it is the
> maximum compatibility path.

Already done:

netcfg (1.13) unstable; urgency=low

  [ Thomas Hood ]
  * If there is no permanent IP address with which the system hostname
(i.e., that which is returned by the "hostname" command) can be
associated in /etc/hosts then associate it with address 127.0.1.1
rather than 127.0.0.1.  Associating the system hostname with the
latter had the unwanted effect of making 'localhost.localdomain'
the canonical hostname associated with the system hostname.
That is, 'hostname --fqdn' returned 'localhost.localdomain'.
(Closes: #316099)
Programs that access local services at the IP address obtained by
resolving the system hostname SHOULD NOT DO THIS, but those that
do so will not be disappointed: most services that listen locally
listen on all 127/8 addresses, not just on 127.0.0.1.

 -- Frans Pop <[EMAIL PROTECTED]>  Fri, 19 Aug 2005 21:08:39 +0200

-- 
see shy jo


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Russ Allbery]

Marco d'Itri <[EMAIL PROTECTED]> writes:
> On Oct 06, Russ Allbery <[EMAIL PROTECTED]> wrote:

>> See the news.software.nntp traffic with people having strange problems
>> with pathnames and message ID generation because of .localdomain.
>> There have been a few separate cases of that over the past year or so.

> Not relevant. They would have the same problems with 127.0.0.1 = localhost.

No, they won't, because INN ignores hostnames that do not contain a period
for the purposes of generating external identifiers, specifically to keep
from using things like localhost or other unqualified names that aren't
globally unique.  Adding the pointless .localdomain thing breaks that sort
of simple sanity check.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Pierre Machard wrote:
> The fact is that nobody complained about that... and my bug was

Now we are :)

> repported more than one year and a half ago. Plus It was disscussed on 
> debian-devel. Please do not argue with me!

It is nothing personal... it is just that your email was the first one
mentioning the .localdomain thing, I wanted to know why you needed it.

Heck, I had never noticed that all my new sarge installs had this broken
thing in them (but now I will have to quadruple-check mysql to make sure it
is not doing something idiotic behind my back.  I am pleasantly surprised
that it did not go up in flames, so maybe they fixed their localhost
braindamage).

> proposed something that worked on my system. It was widely discussed. I
> joined this current thread to show people who do not read -devel every day 
> that we have already talk about it. Nothing more, nothing less.

It was useful, at least now we know the history of the change, and thus we
can deal better with it.  Thanks.

> Please have a look at:
> http://lists.debian.org/debian-devel/2004/06/thrd2.html
> Subject: /etc/hosts: Two lines with the same IP address? by Thomas Hood

With a subject line like that, I certain would never expect it to be related
to 127.0.0.1 canonical naming... no wonder I never noticed the thread.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Joey Hess wrote:
> FWIW, it was done as a result of bug #247734, which includes details on
> how every possible choice seems to break something and the reasoning
> that led to the current choice.

I read that bug report VERY carefully. Twice. There is *nothing* there that
seems to have been fixed/addressed by .localdomain, except maybe a DNS
timeout in Pierre's machine.  Everything else deals with the hostname.

Or am I getting confused and d-i uses localhost.localdomain as the default
hostname, and say, if I had told it that my machine is named "twerk", domain
"foo.bar" I would get a

127.0.0.1 twerk.foo.bar twerk localhost

entry in /etc/hosts?

That would explain a lot...  but still make such a "fix" quite a bad idea.

> Programs that access local services at the IP address obtained by
> resolving the system hostname SHOULD NOT DO THIS, but those that
> do so will not be disappointed: most services that listen locally
> listen on all 127/8 addresses, not just on 127.0.0.1.

This could cause trouble that is easily avoided by actually adding an extra
loopback address to lo (or a lo:1 alias if you have to use ifconfig) of
127.0.1.1.  This is harmless and could be added statically and
unconditionally to /etc/network/interfaces.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Christoph Martin]

Andreas Barth schrieb:
> * Frank Küster ([EMAIL PROTECTED]) [051006 17:13]:
> 
>>sean finney <[EMAIL PROTECTED]> wrote:
>>
>>
>>>and furthermore, there are some of us who have been quietly waiting for
>>>things to settle down from the previous major transitions before doing
>>>our own, at the request of the release team.
>>
>>I'm only following d-d-a, -private, and -devel, but that only partly,
>>and *I* have not yet read anywhere that transitions are allowed again at
>>all.  If they are and I had known, it would have saved me quite some
>>work... 
> 
> You are right - as so often.
> 
> People are still required to speak with the release team first. But some
> people prefer to make all of our life harder then necessary.
> 
> Please again: If someone wants to make any transition, please speak
> *first* with the release team. Do not just assume you can upload just
> anything. We really want to finish the c++-abi-transition first.

Sorry for that. I missed the message about not doing library
transitions. My fault. But I also do not really understand why so many
packages need to be rebuild since libssl0.9.7 will be in the archive
too. We had the same scheme with libssl0.9.6 and libssl0.9.7. Sarge
released with some packages still linked against libssl0.9.6. Only the
new to build packages link against the new library.

I however understand the problem with different libraries linked against
different versions of openssl. But I don't think that versioning the
symbols in Debian alone would be such a good idea. Than we would be
incompatible with other distributions. All LSB connected distros should
do it the same way.

Release team: If you think it would be the right thing to remove openssl
0.9.8 from sid, feel free to do it. I did the update, because a lot of
people bugged me about the new version and upstream only recommends this
version. It also closes a grave security bug.

Christoph



-- 

Christoph Martin, EDV der Verwaltung, Uni-Mainz, Germany
 Internet-Mail:  [EMAIL PROTECTED]
  Telefon: +49-6131-3926337



signature.asc
Description: OpenPGP digital signature

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 03:17:53PM +0200, Stefano Zacchiroli wrote:

> IIRC leafnode complains about "localhost.localdomain" refusing to suck
> news unless you manually specify a domainname in its configuration file.
> Maybe you remember that trouble?

> Still, I've ever considered that an issue with leafnode, not of
> "localhost.localdomain".

It's complaining because upstream wishes to strongly encourage users to
configure things so that they have a globally unique hostname part to
message IDs that are generated by Leafnode in order to minimise the risk
of collisions.  It will do the same thing for a few other things that
look like default or incomplete configurations.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Bug#332498: RFH: openssl -- Secure Socket Layer (SSL) binary and related cryptographic tools

[Christoph Martin]

Package: wnpp
Severity: normal


I request assistance with maintaining the openssl package.

I am currently the only maintainer, but this package really needs a
team to work on it. Too many packages depend on the library which
therefore has priority important.

The package description is:
 This package contains the openssl binary and related tools.
 .
 It is part of the OpenSSL implementation of SSL.
 .
 You need it to perform certain cryptographic actions like:
  o  Creation of RSA, DH and DSA Key Parameters
  o  Creation of X.509 Certificates, CSRs and CRLs
  o  Calculation of Message Digests
  o  Encryption and Decryption with Ciphers
  o  SSL/TLS Client and Server Tests
  o  Handling of S/MIME signed or encrypted Mail

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (99, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: localhost.localdomain

[Stefano Zacchiroli]

On Thu, Oct 06, 2005 at 09:38:03PM +0100, Mark Brown wrote:
> It's complaining because upstream wishes to strongly encourage users to
> configure things so that they have a globally unique hostname part to
> message IDs that are generated by Leafnode in order to minimise the risk

IMHO is too much to inhibit the use of the program as a whole just to
minimize the collision risk, a warning would have been enough. But we
are getting OT(hread) here ...

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 05:02:55PM -0300, Henrique de Moraes Holschuh wrote:

> Or am I getting confused and d-i uses localhost.localdomain as the default
> hostname, and say, if I had told it that my machine is named "twerk", domain
> "foo.bar" I would get a

> 127.0.0.1 twerk.foo.bar twerk localhost

> entry in /etc/hosts?

> That would explain a lot...  but still make such a "fix" quite a bad idea.

There was certainly a problem at one point where attempting to
cannoicalise the hostname of a freshly installed system would result in
a localhost address.  That was fixed prior to the sarge release and IIRC
the localhost.localdomain thing was already there before this was fixed,
though I've not checked.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: localhost.localdomain

[Mark Brown]

On Thu, Oct 06, 2005 at 10:41:13PM +0200, Stefano Zacchiroli wrote:
> On Thu, Oct 06, 2005 at 09:38:03PM +0100, Mark Brown wrote:

> > It's complaining because upstream wishes to strongly encourage users to
> > configure things so that they have a globally unique hostname part to
> > message IDs that are generated by Leafnode in order to minimise the risk

> IMHO is too much to inhibit the use of the program as a whole just to
> minimize the collision risk, a warning would have been enough. But we
> are getting OT(hread) here ...

I don't believe I indicated anything except the views of upstream there.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Jeroen van Wolffelaar]

On Thu, Oct 06, 2005 at 10:20:12PM +0200, Christoph Martin wrote:
> a lot of people bugged me about the new version and upstream only recommends
> this version. It also closes a grave security bug.

Hm, that wasn't listed in the changelog. Anyway, there hasn't been a security
advisory about openssl recently, did you backport a patch to the sarge version
(and prefereably also, to the woody version) and informed the security team? I
noticed you just requested help for maintaining openssl, so I can imagine that
it's been hard to find to come up with a patch, but it would at least be
beneficial to at least document such security issues, by informing security
team, filing an RC bug on your own package, and mentioning the CVE ID (or at
the very least, a short description of the bug fixed) in your changelog entry.

Thanks,
--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: localhost.localdomain

[John Hasler]

Russ Allbery writes:
> No, they won't, because INN ignores hostnames that do not contain a
> period for the purposes of generating external identifiers, specifically
> to keep from using things like localhost or other unqualified names that
> aren't globally unique.

Relying on hostnames either with or without periods for uniqueness is both
broken and unnecessary.
-- 
John Hasler


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

Re: localhost.localdomain

[John Hasler]

Stefano Zacchiroli writes:
> IMHO is too much to inhibit the use of the program as a whole just to
> minimize the collision risk, a warning would have been enough.

Particularly considering that there are better ways to assure the
uniqueness of message-ids anyway.
-- 
John Hasler


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

Re: localhost.localdomain

[Russ Allbery]

John Hasler <[EMAIL PROTECTED]> writes:
> Russ Allbery writes:

>> No, they won't, because INN ignores hostnames that do not contain a
>> period for the purposes of generating external identifiers,
>> specifically to keep from using things like localhost or other
>> unqualified names that aren't globally unique.

> Relying on hostnames either with or without periods for uniqueness is
> both broken and unnecessary.

Would you like to propose an alternate approach that satisfies all of the
constraints that INN is operating under?  Presumably, given that you feel
capable of expressing this strong of an opinion, you already know what all
of those constraints are and are already familiar with the issues.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Bug#332498: RFH: openssl -- Secure Socket Layer (SSL) binary and related cryptographic tools

[Kurt Roeckx]

On Thu, Oct 06, 2005 at 10:07:01PM +0200, Christoph Martin wrote:
> Package: wnpp
> Severity: normal
> 
> 
> I request assistance with maintaining the openssl package.
> 
> I am currently the only maintainer, but this package really needs a
> team to work on it. Too many packages depend on the library which
> therefore has priority important.

I'm willing to co-maintain this.


Kurt


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Moritz Muehlenhoff]

In linux.debian.devel, you wrote:
>> a lot of people bugged me about the new version and upstream only recommends
>> this version. It also closes a grave security bug.
>
> Hm, that wasn't listed in the changelog. Anyway, there hasn't been a security
> advisory about openssl recently, did you backport a patch to the sarge version
> (and prefereably also, to the woody version) and informed the security team?

Christoph is probably referring to CAN-2005-2946 and bug #314465, which is about
the fact that MD5 is the default digest algo in openssl.
This bug has an inflated severity, it's not overly urgent. There have been 
several
collision attacks on MD5 (i.e. you can create a foo/bar pair, which share a
common hash), but no second preimage attacks have been demonstrated so
far (i.e. creating a bar, which shares a hash with a given foo).
Several exploits have been derived from the basic collision attacks, though, 
(google
for Kaminski or Daum/Lucks for some cool demonstrations), but it's not as grave
as it might appear. Upgrading to SHA-1 is still a good idea, of course, but no
need to break things more than necessary.

Cheers,
Moritz


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

Re: localhost.localdomain

[Wesley J. Landaker]

On Thursday 06 October 2005 14:02, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Oct 2005, Joey Hess wrote:
> > FWIW, it was done as a result of bug #247734, which includes details on
> > how every possible choice seems to break something and the reasoning
> > that led to the current choice.
>
> I read that bug report VERY carefully. Twice. There is *nothing* there
> that seems to have been fixed/addressed by .localdomain, except maybe a
> DNS timeout in Pierre's machine.  Everything else deals with the
> hostname.

FWIW, I completely agree with Henrique here (and pretty much in all past 
messages in this thread)--I also read that bug report VERY carefully, and I 
do not see how adding .localdomain had anything to do with the resolution 
of that bug.

I believe that localhost.localdomain should be removed, as it is both 
unnecessary and arbitrary.

> Or am I getting confused and d-i uses localhost.localdomain as the
> default hostname, and say, if I had told it that my machine is named
> "twerk", domain "foo.bar" I would get a
>
> 127.0.0.1 twerk.foo.bar twerk localhost
>
> entry in /etc/hosts?
>
> That would explain a lot...  but still make such a "fix" quite a bad
> idea.

No, on all of my sarge and sid machines the entry looked like:

127.0.0.1 localhost.localdomain localhost foobar

Where foobar was the name I gave during the install process.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpBYGTLWzRBg.pgp
Description: PGP signature

Re: Effort to change IETF's copying conditions for RFCs

[Wesley J. Landaker]

On Thursday 06 October 2005 06:57, Simon Josefsson wrote:
> Hi everyone!
>
> I know the copying conditions of IETF RFC's has been a concern for
> Debian in the past, and that the RFCs has been removed from the
> official archive (?), so I thought this would be of some interest to
> you.  I am trying to influence the IETF to change the copying
> conditions on RFCs to make them more free software friendly.

This would be great to get this clarified, as I believe the RFCs were always 
intended to be available for unlimited distribution. I totally support 
lobbying to get the the IETF to make it clear. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgp6JtxZjRsmR.pgp
Description: PGP signature

Re: Effort to change IETF's copying conditions for RFCs

[Russ Allbery]

Wesley J Landaker <[EMAIL PROTECTED]> writes:
> On Thursday 06 October 2005 06:57, Simon Josefsson wrote:

>> I know the copying conditions of IETF RFC's has been a concern for
>> Debian in the past, and that the RFCs has been removed from the
>> official archive (?),

If they haven't been yet, they will have to be for etch, at least all of
the RFCs that are under the standard IETF IPR policy.  They don't allow
modification and redistribution of modified versions, and therefore do not
meet DFSG#3.

>> so I thought this would be of some interest to you.  I am trying to
>> influence the IETF to change the copying conditions on RFCs to make
>> them more free software friendly.

> This would be great to get this clarified, as I believe the RFCs were
> always intended to be available for unlimited distribution. I totally
> support lobbying to get the the IETF to make it clear. =)

Unlimited distribution isn't the problem.  Modification and redistribution
of modified versions is the problem, and that restriction was apparently
intentional.  So unfortunately, it's more than just a matter of getting
the IETF to be clearer.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Best practices for kernel modules

[Russ Allbery]

Hello all,

I'm one of the maintainers of OpenAFS, a distributed file system whose
client involves a kernel module.  Currently, the OpenAFS package builds an
openafs-modules-source package but doesn't build any binary module
packages, so each user has to build their own kernel modules with
make-kpkg, module-assistant, or some other tool.

There are two bugs against the OpenAFS package, one requesting prebuilt
modules (Bug#224527) and one requesting that modules be automatically
rebuilt when the kernel is upgraded (Bug#168852).  I'm not sure how to
deal with these issues.  I'd love to get some feedback on what the current
best practices are for packaging kernel modules.

My understanding from recent discussion is that building kernel modules
separately from the source package is a very bad idea for security reasons
(it means that the security team can't easily rebuild all the derived
packages starting from the source package).  Presumably that means that if
we wanted to include pre-built kernel module packages in Debian, the
openafs source package would need to build-depend on the appropriate
kernel build machinery and build binary module packages as part of its
normal build process.  I can do this, but it also seems like a great way
to generate new package names with nearly every upload (thus resulting in
a lot of ftp-master work) and I have no idea how to handle all the
different kernel varients, particularly on non-x86 architectures.

The request for automatic builds of new modules when the kernel is
upgraded doesn't really sound like it should be the responsbility of each
separate kernel module provider, but instead should be handled by some
sort of general infrastructure and hook system.  I think this is basically
the thrust of Bug#303636 and Bug#299727 against module-assistant.

I don't really want to just leave these bugs open against OpenAFS without
some idea of how they might be resolved.  My inclination at the moment is
to close the second bug on the grounds that the openafs package isn't
where this problem should be solved and refer the reporter to the
module-assistant wishlist bugs.  For the request for pre-build modules in
Debian, I'd love to have a best practices justification for taking some
specific approach with it (even if that approach is to document that
pre-build modules will not be provided and close the bug pointing to that
documentation).

Any advice, suggestions, or pointers to best practices would be greatly
appreciated.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Daniel Burrows]

On Thu, Oct 06, 2005 at 01:50:26PM -0400, Joe Smith <[EMAIL PROTECTED]> was 
heard to say:
> "Eduard Bloch" <[EMAIL PROTECTED]> wrote in message 
> >Hehe, it was my first thought about a possible solution, howerver:
> >You also need the Conflicts string. And while the dependencies/conflicts
> >are beeing installed, there may appear a constellation where the new
> >package must be installed during the upgrade. And how would resolve that
> >situation then?
> >
> Very good point, however one slight problem: if the package needs to be 
> installed as a dependency of itself directly or indirectly then there is a 
> circular dependecy which as we know is a bad thing. In fact I'm a little 
> surprised that dependencies are not treated like predepends are, as that 
> would prevent circular dependencies. As they are a bad thing, such a system 
> seems like a good idea.
> 
> I do however ack the potential for problems with 'conflicts', although I'm 
> not sure that that is really a big deal, as installing the dependencies by 
> hand, and then dpkg -i would also have the conflicts situation. 

  The thing is that if you import the package into the apt universe, you
might (very often will) be able to resolve the conflicts cleanly before
you try to install the package, without having to do anything
particularly hacky.  Another thing to consider is what happens if the
user wants to install several .deb files at once, esp. if some of these
depend upon each other and are available in the repository under older
(incompatible/conflicting) versions.

  You might be able to make it work, but it seems much better from a
design point of view to do all this work in the apt layer, so you don't
end up with lots of redundant (and probably subtly different/broken)
code to do what apt already does.

  Daniel


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

Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages

[Daniel Burrows]

On Tue, Oct 04, 2005 at 01:10:42PM +0200, Eduard Bloch wrote:
> #include 
> * Josselin Mouette [Tue, Oct 04 2005, 10:10:22AM]:
> 
> > > Far too often people (read: newbies) get confused when they can't get
> > > *insert favorite package manager* to install the .deb's they've just
> > > downloaded. With DebInstaller installation is simply a double click
> > > away.  No fancy features, just a small dialog that ask for the sudo 
> > > password
> > > and if you really want to install.
> > 
> > Which toolkit does it use?
> > Does it pull dependencies using APT as well? That feature has been
> > missing in APT for a long time.
> 
> I wonder why nobody did implement that feature before. I imagine
> (without knowing much about APT's internals), the pseudocode would look
> like that:

  I suspect the main thing is that parsing .deb(5) files looks rather
annoying.  Not hard necessarily, but annoying enough that it's easy
to find more important things to work on ;-).

  Daniel


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Anthony DeRobertis]

Moritz Muehlenhoff wrote:
> Upgrading to SHA-1 is still a good idea, of course,

Correct me if I'm wrong, but haven't there been collision attacks on
SHA-1, too?


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

Re: When is the C++ transition needed?

[Nathanael Nerode]

Brian Carlson wrote:
>> You must not pass by reference with an extern "C" declaration, because C 
>> doesn't support that.
Dan Jacobowitz wrote:
>Why not?  An extern C definition doesn't mean that it needs to be
>usable from C.  It just means to use the C calling convention.
Perhaps because there is no C calling convention for passing by reference?  
How to pass arguments is part of the calling convention.  :-P  You can pass 
C++-only objects, certainly, but you have to be able to pass them in a way 
which is understood in the C calling convention.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:
> But I don't think that versioning the
>symbols in Debian alone would be such a good idea. Than we would be
>incompatible with other distributions.
Well, only in one direction if I remember my versioning rules correctly.
Consider the following cases:
* binary built against unversioned libssl from other distro, running with 
versioned libssl on Debian
Breaks because it can't find the symbols.
* binary built against versioned libssl on Debian, running with unversioned 
libssl on other distro
Works, because if it can't find a versioned symbol, it tries the unversioned 
symbol.

This can be fixed even more by keeping available one version of libssl with 
unversioned symbols, and versioning the symbols on all other versions.  Then 
binaries from other distros will work as long as the unversioned-symbol 
version is available (and compatible, of course).

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Russ Allbery]

Nathanael Nerode <[EMAIL PROTECTED]> writes:

> Well, only in one direction if I remember my versioning rules correctly.
> Consider the following cases:

> * binary built against unversioned libssl from other distro, running with 
> versioned libssl on Debian
> Breaks because it can't find the symbols.

At least in my testing, binaries built against an unversioned library work
fine with a versioned library.  Maybe I wasn't testing properly?

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

gnome-1 transition

[Thomas Bushnell BSG]

A few weeks ago, libpng10-0 was removed from the archive.  A
consequence of this was that all gnome-1 packages (and there are a
number still around) instantly became FTBFS.

I am now the de-facto gnome-1 tsar, but I don't intend to do much
other than keep things limping along.  I am doing this because
gnucash, an important package IMHO, and which I maintain, requires
gnome-1 for the time being.

The gnome-1 core libraries have now been uploaded in versions that use
libpng12-0 instead of libpng10-0.  They are still working their way
through the autobuilders, at different rates on different archs.

Packages which link against gnome-1 core libraries should now rebuild,
and specify versioned dependencies against the new uploads when they
become available.  The relevant versions to depend on are as follows
(these are the source package names):

libgnome 1.4.2-24
gnome-print 0.37-10
bonobo 1.0.22-5
libcapplet 1:1.5.11-11
gtkhtml 1.1.10-8
libglade 1:0.17-4
gal 0.24-4
guppi 0.40.3-15

In addition, if you use any of the imlib or gdk-imlib packages, you
need the new versions (which have a new source package name):

imlib1-dev -> imlib11-dev
gdk-imlib1-dev -> gdk-imlib11-dev

Please recompile and upload packages which you maintain as these
versions become available on the arch you use for development work.
When you have recompiled, please *check* to make sure that the only
libpng linked into your package is libpng12-0, and that no imlib1
(only imlib11) packages are linked in.  (The best course is to have
none of the old -dev libraries even installed when you build.)

I apologize for this happening while we're trying to get the C++
transition completed.  It was not my choice to drop libpng10-0; I'm
only trying to patch things back together as expeditiously as possible
after that happened.

Once all the new libraries are available on the most common archs, I'm
going to propose a mass-bug-filing to request recompilation on those
packages that still need it, so that the old libpng10-0 and imlib1
binary libraries can be deleted from unstable.

Thomas


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

Re: Packages that need to be rebuilt agaisnt libssl0.9.8

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Russ Allbery wrote:
> At least in my testing, binaries built against an unversioned library work
> fine with a versioned library.  Maybe I wasn't testing properly?

You are correct, they work just fine.  DEPENDING on the version of ld.so,
you might get a helpful warning, but that's about it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Effort to change IETF's copying conditions for RFCs

[Henrique de Moraes Holschuh]

On Thu, 06 Oct 2005, Russ Allbery wrote:
> Unlimited distribution isn't the problem.  Modification and redistribution
> of modified versions is the problem, and that restriction was apparently

If the IETF allows modified versions that are *RENAMED*, then it would meet
the DFSG.  They can even restrict the renaming to "something that makes it
clear that this is not an RFC, STD, "...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: localhost.localdomain

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> So it was just papering over a real bug, namely the existence of the
> "-f" option of hostname. "hostname -f" assumes that the hostname (as
> returned by gethostname(3)) has something to do with networking, which
> is false. It also assumes that the system has just one IP address with
> one FQDN which is also false.

Those asumptions are not false, they are what they are: asumptions. If you
dont want to configure your system that way, just dont use it.

Gruss
Bernd


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

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> Ok, after a quick googling I found that this bug has already been
> reported for MySQL: http://bugs.mysql.com/11822 and is fixed in
> MySQL 5.0.11. So if it bothers you, you should upgrade.

Changing the canonical name of localhost is an arbitrary change that
breaks more than MySQL. It also violates the principle of least
astonishment.

  "We've changed something, we're not sure why, but it breaks MySQL.
  If it bothers you, you should upgrade MySQL"

Nah, I don't think that is what we want to tell our users.

-- 
Stig Sandbeck Mathisen


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

Re: localhost.localdomain

[Stig Sandbeck Mathisen]

Pierre Machard <[EMAIL PROTECTED]> writes:

> Anyway I do not understand why this issue is a problem since we
> simply add an alias to localhost. Nobody say that we will remove
> localhost and exchange it by localhost.localdomain.

If what you wanted to do was to add an alias, you should have read the
documentation on how to add an alias without changing the canonical
hostname for 127.0.0.1.  This documentation is available in hosts(5).

# This manual page describes the format of the /etc/hosts file.  This
# file is a simple text file that associates IP addresses with
# hostnames, one line per IP address. For each host a single line
# should be present with the following information:
#
# IP_address canonical_hostname aliases

Changing the canonical hostname changes the output of everything that
resolves IP address, including "lsof" and "netstat".

Any script or program dependent on this output need to be checked and
possibly changed if it is to behave as it should.  This includes local
scripts created by our users.

It should also be consistent with bind9, and I do _not_ think that
changing bind is the correct way to do things.


iostat:~# getent hosts 127.0.0.1
127.0.0.1   localhost.localdomain localhost iostat

iostat:~# dig -x 127.0.0.1 @localhost

; <<>> DiG 9.2.4 <<>> -x 127.0.0.1 @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11671
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 604800  IN  PTR localhost.

;; AUTHORITY SECTION:
127.in-addr.arpa.   604800  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.  604800  IN  A   127.0.0.1

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Fri Oct  7 07:19:19 2005
;; MSG SIZE  rcvd: 93


-- 
Stig Sandbeck Mathisen


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

Re: localhost.localdomain

[Lionel Elie Mamane]

On Thu, Oct 06, 2005 at 03:25:15PM +0200, Gabor Gombas wrote:
> On Thu, Oct 06, 2005 at 07:31:37AM -0500, Steve Greenland wrote:

>> When proposing a variation from long-standing historical practice,
>> shouldn't the onus be on the on making the change? What problem does
>> 'localhost.localdomain' solve? Why is is better than just 'localhost',
>> which has been common practice for oh, what, 20+ years?

> It's being long-standing does not mean it's correct. I started
> looking for any standards or RFCs that require that the address
> 127.0.0.1 should resolve to "localhost" but I could only find some
> recommendations for DNS administrators, and _nothing_ about
> /etc/hosts.

Having the DNS and /etc/hosts give different results is asking for
trouble. RFC 1912 says that this discussion was had in the past and
the conclusion was "localhost.".

-- 
Lionel


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

Re: Effort to change IETF's copying conditions for RFCs

[Russ Allbery]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> On Thu, 06 Oct 2005, Russ Allbery wrote:

>> Unlimited distribution isn't the problem.  Modification and
>> redistribution of modified versions is the problem, and that
>> restriction was apparently

> If the IETF allows modified versions that are *RENAMED*, then it would
> meet the DFSG.  They can even restrict the renaming to "something that
> makes it clear that this is not an RFC, STD,  here>"...

Right, I know.  Apparently it was intentional on the part of the IETF to
not even allow that.  Don't look at me; I think it's a stupid decision.

I'm not saying we can't get them to change it, or that we shouldn't try,
or anything else that discouraging.  I'm just saying that it isn't solely
a misunderstanding or lack of clarity; there really is an underlying
disagreement here.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Effort to change IETF's copying conditions for RFCs

[Paul TBBle Hampson]

On Thu, Oct 06, 2005 at 11:16:03PM -0700, Russ Allbery wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>> On Thu, 06 Oct 2005, Russ Allbery wrote:

>>> Unlimited distribution isn't the problem.  Modification and
>>> redistribution of modified versions is the problem, and that
>>> restriction was apparently

>> If the IETF allows modified versions that are *RENAMED*, then it would
>> meet the DFSG.  They can even restrict the renaming to "something that
>> makes it clear that this is not an RFC, STD, > here>"...

> Right, I know.  Apparently it was intentional on the part of the IETF to
> not even allow that.  Don't look at me; I think it's a stupid decision.

> I'm not saying we can't get them to change it, or that we shouldn't try,
> or anything else that discouraging.  I'm just saying that it isn't solely
> a misunderstanding or lack of clarity; there really is an underlying
> disagreement here.

If the IETF doesn't even want people distributing modified, clearly
indicated derived works, then how do people work on 'bis' versions of
RFCs? eg. 2326bis, 'draft-ietf-mmusic-rfc2326bis-02.txt' is the old
version I have lying around here now, which is clearly a derived work of
RFC2326.

Of course, this might be an IETF document, and _they_ are free to modify
their own documents. I don't know that much about the IETF's processes,
but it seems that denying the right to derive works from IETF standards
documents is counterproductive, while restricting the naming of derived
works to avoid confusion is understandable.

Then again, do we want people forking RFCs? ^_^

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgp0nfZEkKo0C.pgp
Description: PGP signature

Work-needing packages report for Oct 7, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 188 (new: 3)
Total number of packages offered up for adoption: 87 (new: 11)
Total number of packages requested help for: 20 (new: 3)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   gal (#331112), orphaned 5 days ago

   heaplayers (#332536), orphaned today
 Description: high-performance memory allocators

   libhoard (#332538), orphaned today
 Description: fast memory allocation library

185 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   epos (#332233), offered yesterday
 Description: Text-to-speech system

   intlfonts (#332234), offered yesterday
 Description: International fonts for X
 Reverse Depends: cpanel

   libhtml-tokeparser-simple-perl (#331105), offered 5 days ago
 Description: Perl module used to tokenize HTML documents

   liblingua-en-numbers-ordinate-perl (#331095), offered 5 days ago
 Description: Perl module to convert from cardinal numbers to ordinal
 numbers

   liblingua-preferred-perl (#331096), offered 5 days ago
 Description: Perl module which allows language content negotiation

   liblog-tracemessages-perl (#331097), offered 5 days ago
 Description: Perl module to allow for trace messages in Perl code
 Reverse Depends: liblingua-preferred-perl

   libsort-versions-perl (#331098), offered 5 days ago
 Description: Perl module for sorting of revision (and similar)
 numbers
 Reverse Depends: libmodule-packaged-perl libparse-cpan-packages-perl
 libcss-tiny-perl

   libsub-override-perl (#331099), offered 5 days ago
 Description: Perl module used to temporarily override subroutines

   phalanx (#332232), offered yesterday
 Description: Chess playing program

   rocks (#330953), offered 6 days ago
 Description: Make network sockets reliable in a transparent way

   xmltv (#331108), offered 5 days ago
 Description: Functionality related to the XMLTV file format for TV
 listings
 Reverse Depends: xmltv freeguide xmltv-util xmltv-gui

76 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] fetchmail (#331642), requested 2 days ago
 Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail

[NEW] gutenbrowser (#331203), requested 4 days ago
 Description: Project Gutenberg Etext reader

[NEW] openssl (#332498), requested today
 Description: Secure Socket Layer (SSL) binary and related
 cryptographic tools
 Reverse Depends: libgnustep-base1.10-dev dovecot-common stone
 openssl apache-ssl webmin libsylpheed-claws-gtk2-dev courier-ssl
 libwww-ssl-dev libnessus-dev libsylpheed-claws-dev dsniff
 libssl0.9.8 ultrapossum-tls uw-imapd php4-dev openswan
 apache2-common jabber-dev libapache-mod-ssl schooltool mzscheme
 libneon23-dev libssl-ocaml-dev cl-ssl libcurl3-dev libssl-dev pkcipe
 nessusd heartbeat-2 libomniorb4-dev libopenh323-dev libpt-dev
 kerberos4kth-dev libace-dev libpq-dev libneon24-dev ftpd-ssl pyca
 stunnel4 cipe-source libmultisync-plugin-syncml ejabberd
 courier-imap-ssl aolserver4-nsopenssl pantomime-dev libzorpll-dev
 usermin xmms-dev nagios-plugins kdelibs4-dev php5-dev stunnel
 sslwrap bincimap libyaz-dev tinyca ca-certificates libopensc1-dev
 libgadu-dev httping libsnmp9-dev libc-client-dev libaws-dev ipopd
 libssl0.9.8-dbg schoolbell skyutils-dev telnetd-ssl libclamav-dev
 apache2-threaded-dev apache2-prefork-dev partimage-server
 libxmlsec1-dev ssl-cert

   aboot (#315592), requested 105 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot

   athcool (#278442), requested 345 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#321654), requested 61 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit

   dselect (#282283), requested 320 days ago
 Description: a user tool to manage Debian packages

   grub (#248397), requested 514 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
 grub-splashimages

   gtkpod (#319711), requested 74 days ago
 Description: manage songs and playlis