Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Thu, Sep 06, 2001 at 01:23:12PM +1000, Martijn van Oosterhout wrote:
> On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
> >With this the maintainers get some mails from the translator
> >project. More like now. Now we only at the start, now we don't make
> >a real review process. Now we have only 10 languages. 
> 
> I thought there was mention of translations mailing lists where all the
> translations are sent to in addition to the maintainer. I thought that was
> the review process.

yes and no.

Now all french translations are send to the debian-i10n-french ML ist.
Because of this we have more fr updates like de or pt_BR.

But after some time the ddts server will make a own review process. It
will send all finish translated description a second time to the
translators for a review.



Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Ja, aber der Bootvorgang ist doch so sch?n mit den Wolken und so. Das
st?rt meiner Meinung nach garnicht. (Martin Heinz zum Rebooten von M$-W)


pgpCOb2Lao7PM.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[David Starner]

On Thu, Sep 06, 2001 at 01:08:52AM +0200, [EMAIL PROTECTED] wrote:
> On Wed, 5 Sep 2001, Branden Robinson wrote:
> 
> > On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
> > >The maintainer need not do anything. Maybe he don't know the
> > >translation. The user only use this. This need only the
> > >translators.
> > 
> > While we're on the subject, can you get someone to translate your mails
> > into a comprehensible dialect of English?
> 
> Branden, please don't be rude.

True, Branden was rude. But the fact that grisu's emails are sometimes hard 
to understand has been a stumbling block for me; it would certainly help to
get a translator/editor for the full blown proposals.

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Martijn van Oosterhout]

On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
>With this the maintainers get some mails from the translator
>project. More like now. Now we only at the start, now we don't make
>a real review process. Now we have only 10 languages. 

I thought there was mention of translations mailing lists where all the
translations are sent to in addition to the maintainer. I thought that was
the review process.

After all, I don't really know enough Dutch to do a lot of translating work,
but I know easily enough to check other peoples translations.

-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.

ideas about how to package something

[Brandon L. Griffith]

Sorry for the vague Subject:
I maintain a package for OpenVerse http://www.openverse.org
as well I am one of the upstream contributors.
Anyhow, we have a slew of plugins available for OpenVerse. Some are as simple
as executing system commands from the chat window and some are as large as the
program itself, well almost. I'm wanting to package all of these up and was
wanting some input from other ppl on it.
Should I package each plugin seperately or make one large
openverse-plugins.deb? I can see pros and cons of each method, such as the
"dict" plugin requiring the dict program which in turn has its dependencies
and such. If I made one large deb then it would have alot of dependencies. But
if I made several small ones then there would be no problem there, except that
the entire deb for some of the smaller ones would be just a few kb in size.
Could someone else out there give me their opinion on this?
thanks

-- 
  .''`.
 : :' :Brandon L. Griffith  <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~brandon/
   `-  
Debian GNU/Linux   


pgpTKMF1G5xJa.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

> On 05-Sep-01, 18:14 (CDT), "Neil T. Spring" <[EMAIL PROTECTED]> wrote: 
> > 2. A configuration option, when you know concensus on this
> > list is that there will be none; and that the default will
> > be on.
> No, I don't think that's the concensus. I agree that the kernel package
> can't change another packages conffile, but that doesn't mean the issue
> cannot be worked around

Fair enough.  perhaps I was expressing my expectation
that if we asked Herbert, Craig, and Anthony, none of them
would add a configuration option.  Certainly not Herbert or
Craig (irrelevant to kernel-package and procps).

My point is: the maintainers have spoken.  If we're going
to make progress in helping users behind broken equipment,
we're going to have to find another way that doesn't offend
Herbert, Craig, and Anthony's sense of idealism.

> The problem is not Debian user's with broken equipment. The problem is
> that if any router between them and the target system is broken, they
> get screwed. What do you suggest they do? And before you say "contack the
> admin of the broken router", I suggest you try to

No.  Arbitrary routers along the packet's path are not
the problem.  See http://gtf.org/garzik/ecn/ 
Real routers in the middle of the network don't have time
to screw with the payload of an IP packet.

We're talking zealous firewalls, unpatched cisco local
director, and the Zyxel "router that zeroes TCP bits".
At the end hosts, we're talking about what nmap thinks
are old AIX and IRIX.

> a) find out who is responsible for an arbitrary router.

This is easy, as above; it's either your zyxel or the
server's cisco redirector, firewall, or operating system.

> b) find out how to contact said person.

Since (a) is easy, (b) is fairly easy.  webmaster@, root@,
[EMAIL PROTECTED]

> c) find out how far you get when you, internet newbie, try to tell them
> their equipment is broken.

(c) will be easy when corporate web servers that want
to sell you something realize that they're turning away
connections that might represent business.

I don't see what's so hard about a user writing
[EMAIL PROTECTED]:

 Hi, 
 I tried to access your webserver today and it said
 connection timed out.  I can connect to yahoo just fine.
 Is it because I'm using konqueror?  Please let me know
 when your web server is back up.

> It's simply not a realistic answer for most people (i.e. those without

I do not presume to say what most people would be capable
of doing.  It was your suggestion, not mine, that joe user
"contack the admin".  If they feel sufficiently capable,
great, everyone should at least try to submit bug reports.

If you feel it is your responsibility to make the
world safe for these users,  I suggest you take it upon
yourself to write the admins of webservers that don't
respond to ECN negotiating SYN packets as listed at:

http://www.aciri.org/tbit/ecn_test3A.html
(some of these may have been fixed since April)

-neil

Re: step by step HOWTO switch debian installation into utf-8

[Brian May]

> "Radovan" == Radovan Garabik <[EMAIL PROTECTED]> writes:

Radovan> it is LANGUAGE, and you have to set LANG to something
Radovan> (which will be ignored in this case, but has to be set).

Not only does it have to be set, but it looks like it can't be set to "C":

[776] [scrooge:bam] /usr/doc/libsasl-dev >export LANG=en_AU  
[778] [scrooge:bam] /usr/doc/libsasl-dev >LANGUAGE=en_AU ls --sss 
ls: unrecognized option `--sss'
Try `ls --help' for more information.
[779] [scrooge:bam] /usr/doc/libsasl-dev >LANGUAGE=en_AU:en_GB ls --sss
ls: unrecognised option `--sss'
Try `ls --help' for more information.

appears to work as I would expect (look at spelling of unrecognised),
but this doesn't:

[780] [scrooge:bam] /usr/doc/libsasl-dev >export LANG=C  
[781] [scrooge:bam] /usr/doc/libsasl-dev >LANGUAGE=en_AU ls --sss  
ls: unrecognized option `--sss'
Try `ls --help' for more information.
[782] [scrooge:bam] /usr/doc/libsasl-dev >LANGUAGE=en_AU:en_GB ls --sss
ls: unrecognized option `--sss'
Try `ls --help' for more information.
[783] [scrooge:bam] /usr/doc/libsasl-dev >LANGUAGE=en_GB ls --sss 
ls: unrecognized option `--sss'
Try `ls --help' for more information.
-- 
Brian May <[EMAIL PROTECTED]>

Re: reopening ECN bugreport/netbase

[Craig Sanders]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:

>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
> 
> to the kernel-image-2.4.x postinst.

no, this is broken and evil. kernel-image packages should NOT override
someone who chooses to have ECN enabled.

the problem is that recent kernel-images have ECN support compiled in.

they shouldn't.

the correct solution is to NOT compile ECN support into the distribution
kernels. that's a choice that should be left up to the individual system
admin - if they want it, they can compile a kernel to support it.


craig

-- 
craig sanders <[EMAIL PROTECTED]>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch

mac parts?

[Rick Younie]

Mike Shuey has donated a Mac Quadra 950 that's been pumping out
packages for a few months as bruno.fmepnet.org for the m68 port.
He has (most of) a similar machine that he can hook up next to it
that still needs a few gig narrow SCSI disk and matched sets of
30-pin ram.  If someone can loan some parts to the cause it will
speed up the process.  Mike's email is [EMAIL PROTECTED]

One of the m68k build daemons is awaiting a new connection,
another has chronic connectivity problems and a third is going
offline soon so this machine will likely be needed.

Rick
-- 

Re: sysctl should disable ECN by default

[Jaldhar H. Vyas]

On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:

> > > But tell me, in case there's an IMAP client that has some problems with
> > > the IMAP protocol. Should a Debian box by default *refuse* to talk
> > > to it or should the default be to try to talk to it (provided that it
> > > can)?
> >
> > Are you joking?  If someone filed a bug against my package saying I should
> > make changes to it to accomodate a broken client (equivalent: my IMAP server
> > sends back a valid IMAP response and this causes the client to segfault), I
> > would immediately close the bug with a smile and a have-a-nice-day.
>

It's funny you should bring this up because this is exactly what happened
yesterday.  Apparently the mail client in Mac OS X doesn't handle mailbox
subscriptions and changing the mailbox root like every other IMAP client
in existence can.  I was requested to make a change in the uw-imapd
package to accomodate this and I refused.  I'll make changes that will
help people with problems up to a point -- the point where it negatively
impacts other users.  I think most Debian developers feel the same way.

> Good for you. And the people that *need* a working server as in "it forks
> for *me*" will move on and ignore you. That's your choice. It's the choice
> Debian is making now.
>

Well that's their choice.  Sometimes you can't please everyone.  In this
case turning on ECN is the right thing to do.  Each user has to decide
whether they can deal with that or not.  Debians sole responsibility is to
see it is properly documented somewhere.  If people don't read the
documentation, we needn't waste any sympathy on them.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: reopening ECN bugreport/netbase

[Steve Greenland]

On 05-Sep-01, 18:14 (CDT), "Neil T. Spring" <[EMAIL PROTECTED]> wrote: 
> 2. A configuration option, when you know concensus on this
> list is that there will be none; and that the default will
> be on.

No, I don't think that's the concensus. I agree that the kernel package
can't change another packages conffile, but that doesn't mean the issue
cannot be worked around


> Debian users who have broken equipment will just have to
> be clueful enough to disable ECN if they find that their
> router violates RFC 791.  Help them have a clue.

The problem is not Debian user's with broken equipment. The problem is
that if any router between them and the target system is broken, they
get screwed. What do you suggest they do? And before you say "contack the
admin of the broken router", I suggest you try to

a) find out who is responsible for an arbitrary router.
b) find out how to contact said person.
c) find out how far you get when you, internet newbie, try to tell them
their equipment is broken.

It's simply not a realistic answer for most people (i.e. those without
existing contacts or a sufficiently high position/reputation.)

Steve

Bug#111386: ITP: mangoquest -- Pacman meets Doom

[Andrew Suffield]

Package: wnpp
Severity: wishlist

* Package name: mangoquest
* URL : http://mangoquest.sourceforge.net/
* License : GPL
  Description : Pacman meets Doom

Basically a pacman clone, but in the first person, and with a few
extra bits and pieces thrown in. Uses the SDL with GL.

(Level editor included)

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' : | Dept. of Computing,
 `. `'  | Imperial College,
   `-http://www.debian.org/ | London, UK


pgpqYfXCZlrSI.pgp
Description: PGP signature

Re: sysctl should disable ECN by default

[Steve Langasek]

On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:

> > Yes, quite frankly.  Personally, I use only Free Software and software
> > that runs on top of Free OSes.  Professionally, I work for an ISP, and
> > we expect our vendors to live up to the promises they make.

> If that's the case then shouldn't we disable all those kernel
> compatibility hacks by default? Don't tell me your machine is clean, and
> all those components are 100% protocol compliant.

Which other kernel compatibility hacks are in place to work around buggy,
non-compliant implementations of IETF standards?  It's one thing to include
code for compatibility with unusual BIOSes, controllers, etc., which are not
expected to conform with any standards other than electrical ones.  It's
another thing to include code for compatibility with routers that fail to
conform with open, published protocol standards that date back two decades.

An Internet router that can't follow the TCP/IP spec is no Internet router at
all, and vendors who sell such products under the pretense that they *are*
Internet routers are legally liable in most jurisdictions.


> please live up to your claim and sue Cisco for their bloody CiscoPPP which
> in the "early days" wouldn't allow you to connect a standard PPP device to
> it, will you?

Erm... why?  Just because we're assertive in protecting our investments
doesn't mean we're in the business of frivolously suing other companies.  Most
vendors we work with are also willing to work with us in order to resolve
technical deficiencies in their products.  On occasion, we've found vendors
who were not willing to work with us; in those cases, litigation was a logical
choice.

We don't use 'CiscoPPP', nor have we ever been negatively affected by such a
creature.  Suggesting that we should sue Cisco because somebody else has been
is just silly.


> Now let me tell you that possibly Zyxel is the biggest SOHO ISDN router
> vendor in Europe. So what?

And they haven't provided patches for their firmware?

And the ISPs that have customers using these routers haven't raised a stink
about it?

And the end-users who have these routers don't have class-action lawsuits as a
recourse?

And Debian therefore has a duty to pick up the slack on behalf of everyone
else who isn't taking responsibility for the problem?


> Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't
> have ISDN around.

Plenty of ISDN around -- no Zyxel.  (Less and less ISDN, for that matter,
which is wonderful in my opinion.)

Probably no Zyxel because they're as bad at creating a device that works with
US ISDN signalling standards as they are at creating a device that works with
IETF standards, perhaps?[1]


> But you can sure tell from my enthusiasm, and I'm no networking idiot,
> that I *do* feel strong about it and that's exactly because I had fun
> lately with it and I don't think it's necessary for everybody who happens
> to have the bad luck to find itself in the same position to forcibly
> repeat that lovely experience. And you can be certain that if the
> situation stays as it is, I will not be the last one.

And if the situation changed today, you /still/ would not be the last one,
because the adoption of ECN as a standard is still moving forward.  If, as
your message suggests, nothing is being done on a large scale about the
problems with this hardware, why would the situation be any different two
years from now when these same users can get out through their router fine,
but can't connect to half the websites on the planet because those websites
are now using ECN?

I sympathize with having to debug obscure network problems, and I agree that
we should not cause our users undue hardship.  But as others have suggested,
it's better to deal with this by documenting the problem instead of expecting
that turning ECN off will make the problem go away on its own.


> But tell me *one* thing:

>   Why is it so hard to change a few lines and have the default be
>   set to *off* and let whoever feels like it enable it?

Nothing difficult about it -- but it's still the maintainer's call whether or
not this should be done.  There are plenty of arguments both for and against
enabling ECN, and no amount of discussing them in debian-devel changes the
fact that it's the maintainer's decision to make.

Steve Langasek
postmodern programmer



[1] Don't think that I'm picking on Zyxel exclusively.  There are plenty of
US-made ISDN routers I would rather burn than use.  Zyxel just happens to be
this week's poster child for bad router vendors.

Re: reopening ECN bugreport/netbase

[Adam McKenna]

On Wed, Sep 05, 2001 at 03:19:01PM -0800, Ethan Benson wrote:
> On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote:
> > So since netbase does not want to be the proper place, a better
> > fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
> > use debconf with a default value of "0" and to inform/ask the user about
> > it when installing a new kernel.
> 
> and store/implement it where?  /etc/sysctl.conf is unacceptable as its
> a conffile belonging to procps.
> 
> and personally i don't want /etc/sysctl.conf to become another debconf
> [mis]managed config file.

I agree -- sysctl.conf should never be touched by the distribution -- it is
for local settings, specific to each machine, and there should never be a
chance that it could possibly be overwritten automatically, as that could
result in major breakage on some systems.

--Adam

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: reopening ECN bugreport/netbase

[Ethan Benson]

On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote:
> So since netbase does not want to be the proper place, a better
> fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
> use debconf with a default value of "0" and to inform/ask the user about
> it when installing a new kernel.

and store/implement it where?  /etc/sysctl.conf is unacceptable as its
a conffile belonging to procps.

and personally i don't want /etc/sysctl.conf to become another debconf
[mis]managed config file.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpWnoX2DI0RN.pgp
Description: PGP signature

Re: sysctl should disable ECN by default

[Steve Greenland]

On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh <[EMAIL PROTECTED]> 
wrote: 
> On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote:
> > 
> > But tell me *one* thing:
> > 
> > Why is it so hard to change a few lines and have the default be
> > set to *off* and let whoever feels like it enable it?
> 
> Because apparently Xu feels equally strong about not allowing someone else's
> irresponsability (the router firmware writer's) to force him to disable
> something he believes is right (or force him to change the default kernel
> behaviour against upstream wishes, or whatever) ?

1. The default kernel behavior is that ECN is completely disabled. 

2. While I happen to agree that ECN is a good thing, and that routers
that screw it up *are* broken and violating old RFCs (reserved is
reserved, not "let's zero it out 'cause we don't know what it means"), I
can't help but think that if someone's first experience with Debian is
that the network install fails silently because ECN is enabled and some
router between him and the archive is broken then we have failed to meet
our (implied?)commitment in the Social Contract. All the newbie is going
to know is that it doesn't work. Boy, I'm glad we've made our political
point.

3. ECN-broken routers are not equivalent to non-compliant IMAP
clients. I don't know about you, but I don't have control over the
path my packets take over the internet. If there's a broken router in
that path, there's not a whole lot I can do about it. And for that
matter, there are lots of clients and servers with code to accommodate
broken-but-popular servers and clients (respectively).

Steve

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[wouter]

On Wed, 5 Sep 2001, Branden Robinson wrote:

> On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
> >The maintainer need not do anything. Maybe he don't know the
> >translation. The user only use this. This need only the
> >translators.
> 
> While we're on the subject, can you get someone to translate your mails
> into a comprehensible dialect of English?

Branden, please don't be rude.

The very fact that grisu's English is not that good, explains why it's so
damn important to support translations.

-- 
wouter dot verhelst at advalvas in Belgium

This is Linux world. On a quiet day, you can hear Windows reboot.

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

Wow. Somebody makes a one line suggestion (which seems
like a good idea) and you twist it into:

1. An incorrect statement. "ecn is a routing
protocol." rotfl.  Find a computer science textbook before
you post to the list again.

2. A configuration option, when you know concensus on this
list is that there will be none; and that the default will
be on.

3. A statement that blames ECN, when the broken equipement
is your moronic Zyxel router.  The idiot user you're
designing the message for is just as likely to think that
ECN will cause his modem to explode.

C'mon. If you want a message, start with
Documentation/Configure.help.  If you really want to help,
pick a fight you stand a chance of winning and suggest
places for messages and documentation.

Debian users who have broken equipment will just have to
be clueful enough to disable ECN if they find that their
router violates RFC 791.  Help them have a clue.

-neil



On Wed, Sep 05, 2001 at 11:14:47PM +0200, T.Pospisek's MailLists wrote:
> On Wed, 5 Sep 2001, Remco van de Meent wrote:
> 
> > But anyway - I agree that Debian should not be too conservative with
> > regard to new networking technologies, so disabling ECN by default is
> > not something I'd like to see happen. Give the user some short
> > explanation and let him make the decision himself, I'd say.
> 
> OK. How exactly should this be worded:
> 
> "ECN is a routing protocol. Some equipment doesn't support ECN
>  yet. Switching it on can break your networking and it will make some
>  internet sites unreachable. If you want to disable ECN then select "No".
> 
>  Do you want to enable ECN: "Yes"  "No""
> 
> And the default will be on "Yes". Would you say "Yes"? Or how exaclty do
> you want to phrase this to let the user make an informed decison?
> 
> Moreover, what about bootfloppies. In case there will be bootfloppies, do
> you want to bother the user with such questions? Or do you want to
> have two versions of the kernel - one for the bootfloppies and one for
> the "maintree"?
> 
> And what is *exactly* the problem of displaying:
> 
>   "ECN Disabled - Edit /etc/network/options to enable it"
> 
> in the bootmessages and let the user switch it on if he wants?
> *t
> 
> 
>  Tomas Pospisek
>SourcePole   -  Linux & Open Source Solutions
>http://sourcepole.ch
>Elestastrasse 18, 7310 Bad Ragaz, Switzerland
>Tel: +41 (81) 330 77 11
> 
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: reopening ECN bugreport/netbase

[Ethan Benson]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> 
> ) then it's the kernel-image package that needs to make sure it's runing
> in a sane environment. So *please* can we add something like:
> 
>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
> 
> to the kernel-image-2.4.x postinst.

no you cannot.  that is a policy violation and will get a severity
serious bug report to have it removed if its ever added.

/etc/sysctl.conf is a conffile belonging to procps NO package may
modify it in maintainer scripts.  since sysctl will produce errors at
boot if this is added to the default sysctl.conf that is not
acceptable either.  

furthermore if you simply installed a 2.4 kernel but decided not to
boot it, or decided to go back to 2.2 you start getting errors at boot
again. 

since aj won't add anything to netbase the admin will simply have to
turn off ecn themselves. thats the only option.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgprCsGk5u9zP.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Remco van de Meent]

T.Pospisek's MailLists wrote:
> > But anyway - I agree that Debian should not be too conservative
> > with regard to new networking technologies, so disabling ECN by
> > default is not something I'd like to see happen. Give the user some
> > short explanation and let him make the decision himself, I'd say.
> 
> OK. How exactly should this be worded:

[...]

Well let's use the Linux kernel's description to start with:

CONFIG_INET_ECN
  Explicit Congestion Notification (ECN) allows routers to notify
  clients about network congestion, resulting in fewer dropped packets
  and increased network performance. This option adds ECN support to
  the Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn)
  which allows ECN support to be disabled at runtime.

  Note that, on the Internet, there are many broken firewalls which
  refuse connections from ECN-enabled machines, and it may be a while
  before these firewalls are fixed. Until then, to access a site behind
  such a firewall (some of which are major sites, at the time of this
  writing) you will have to disable this option, either by saying N now
  or by using the sysctl.

One of the strong points of Debian is that it leaves the user in
control of his system. That's the main reason I'm suggesting to leave
the decision whether or not to use ECN up to the user. 

> Moreover, what about bootfloppies. In case there will be
> bootfloppies, do you want to bother the user with such questions? Or
> do you want to have two versions of the kernel - one for the
> bootfloppies and one for the "maintree"?

I'm not familiar with bootfloppies internals. Is it possible to disable
ECN during initialization using sysctl in some way? It probably is...
just to be safe.

> And what is *exactly* the problem of displaying:
> 
>   "ECN Disabled - Edit /etc/network/options to enable it"
> 
> in the bootmessages and let the user switch it on if he wants?

It's just my opinion, but I feel that this is more conservative than we
necessarely have to be. Promoting superior technologies, when
available, is not helped with a conservative default, I think.

But then again, I can live with such a message, that's for sure ;-)

many ldconfig errors durring upgrade

[Bryan Andersen]

I'm getting these upgrade errors while doing a sid upgrade.
It seams to happen with many packages.

errors
Setting up eterm (0.9.1-0pre2001072201) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so

Setting up libgconf11 (1.0.4-2) ...
/sbin/ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
/sbin/ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so

Setting up exdbm (1.0b2-8) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so

Setting up gpsim (0.20.9-3) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
 
Setting up gpsim-logic (0.0.2-6) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
 
Setting up gpsim-lcd (0.1.1-6) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
 
Setting up gpsim-led (0.0.3-7) ...
ldconfig: Can't link /usr/lib//usr/lib/libelmme-iconv.so to
libelmme-iconv.so
ldconfig: Can't link /usr/lib//usr/lib/libelmme-base.so to
libelmme-base.so
end of errors

refference data:

$ ls -l /usr/lib/libelmme-iconv.so | colrm 12 36
-r--r--r--  15148 Sep  4 10:54 /usr/lib/libelmme-iconv.so

$ md5sum /usr/lib/libelmme-iconv.so
5d32d6d371a3acd5363d3d5699ed3d8c  /usr/lib/libelmme-iconv.so



$ ls -l /usr/lib/libelmme-base.so | colrm 12 36
-r--r--r-- 529394 Sep  4 10:54 /usr/lib/libelmme-base.so

$ md5sum /usr/lib/libelmme-base.so
2fabf8c41068a775da294ae663176384  /usr/lib/libelmme-base.so

-- 
|  Bryan Andersen   |   [EMAIL PROTECTED]   |   http://www.nerdvest.com   |
| Buzzwords are like annoying little flies that deserve to be swatted. |
|   -Bryan Andersen|

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Branden Robinson]

On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
>The maintainer need not do anything. Maybe he don't know the
>translation. The user only use this. This need only the
>translators.

While we're on the subject, can you get someone to translate your mails
into a comprehensible dialect of English?

-- 
G. Branden Robinson| One man's "magic" is another man's
Debian GNU/Linux   | engineering.  "Supernatural" is a
[EMAIL PROTECTED] | null word.
http://people.debian.org/~branden/ | -- Robert Heinlein


pgpX0kyKT5HN9.pgp
Description: PGP signature

Re: sysctl should disable ECN by default

[Henrique de Moraes Holschuh]

On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote:
> at least not consciously because I doubt anybody who's pro ECN in the
> kernel has had to debug a situtation such as described above.

Don't. You will lose.

> But you can sure tell from my enthusiasm, and I'm no networking idiot,
> that I *do* feel strong about it and that's exactly because I had fun
> lately with it and I don't think it's necessary for everybody who happens
> to have the bad luck to find itself in the same position to forcibly
> repeat that lovely experience. And you can be certain that if the
> situation stays as it is, I will not be the last one.
> 
> But tell me *one* thing:
> 
>   Why is it so hard to change a few lines and have the default be
>   set to *off* and let whoever feels like it enable it?

Because apparently Xu feels equally strong about not allowing someone else's
irresponsability (the router firmware writer's) to force him to disable
something he believes is right (or force him to change the default kernel
behaviour against upstream wishes, or whatever) ?

I think that, had you requested this as a DOCUMENTATION patch, and also for
a warning to be issued in the postinst, you'd not have met too much
resistance.

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

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Adam Heath]

On Wed, 5 Sep 2001, Wichert Akkerman wrote:

> Previously Nick Phillips wrote:
> > Well, shouldn't it? Wouldn't it make sense to have the translated 
> > description
> > in there rather than the original one?
>
> I actually makes more sense to remove even the english description
> from status to another location.

Note, that there is no reason dpkg could not be modified to read from multiple
status files.

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Remco van de Meent wrote:

> But anyway - I agree that Debian should not be too conservative with
> regard to new networking technologies, so disabling ECN by default is
> not something I'd like to see happen. Give the user some short
> explanation and let him make the decision himself, I'd say.

OK. How exactly should this be worded:

"ECN is a routing protocol. Some equipment doesn't support ECN
 yet. Switching it on can break your networking and it will make some
 internet sites unreachable. If you want to disable ECN then select "No".

 Do you want to enable ECN: "Yes"  "No""

And the default will be on "Yes". Would you say "Yes"? Or how exaclty do
you want to phrase this to let the user make an informed decison?

Moreover, what about bootfloppies. In case there will be bootfloppies, do
you want to bother the user with such questions? Or do you want to
have two versions of the kernel - one for the bootfloppies and one for
the "maintree"?

And what is *exactly* the problem of displaying:

"ECN Disabled - Edit /etc/network/options to enable it"

in the bootmessages and let the user switch it on if he wants?
*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: Hello

[Constantine Karastamatis]

> would even dare try it.  I have decided to offer windows and siding
> to you, at our basic cost.  In other words, I'm going to offer you
> windows and siding for no personal profit whatsoever!  This will

I am quite sorry, but I have no desire to install Windows. That is why I
use Linux. However, I have never heard of Siding - does it only work on
Windows - or is it platform independent?

Thank you,
Constantine

Re: sysctl should disable ECN by default

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Steve Langasek wrote:

> > Do *you* do that for all the things that don't work as they should?
>
> Yes, quite frankly.  Personally, I use only Free Software and software
> that runs on top of Free OSes.  Professionally, I work for an ISP, and
> we expect our vendors to live up to the promises they make.

If that's the case then shouldn't we disable all those kernel
compatibility hacks by default? Don't tell me your machine is clean, and
all those components are 100% protocol compliant.

Btw. since you are connected through alternet which servers you through
*Cisco* routers:

  tpo2:/home/tpo/# traceroute www.netexpress.net
  traceroute to shamu.netexpress.net (206.65.64.2), 30 hops max, 40 byte
  packets
  [...]
  12  netexpress-gw.customer.ALTER.NET (157.130.101.102) 187 ms 173 ms 187 ms
  13  shamu.netexpress.net (206.65.64.2)  174 ms  189 ms  170 ms
  tpo2:/home/tpo/# xprobe 157.130.101.102
  [...]
  FINAL:[ Cisco IOS 11.x-12.x ]

please live up to your claim and sue Cisco for their bloody CiscoPPP which
in the "early days" wouldn't allow you to connect a standard PPP device to
it, will you?

> At least this way, users who have broken routers will find out about the
> problem early, can easily disable the ECN behavior if they need to, and
> can set about finding a solution to the real problem.
[...]
> Professionally, I work for an ISP, and we expect

Yup. So did I. And that's why I was able to find out in the first place.
But let's see how "easy" that is. Please take an average Debian user. Give
it a machine that run's a 2.4 kernel behind an ECN-broken router and see
how long it takes for him to figure out what's wrong.

Or in other words, please take the same default install of Debian with a
2.4 kernel and then do this:

# find / -exec grep -i "ECN" \{\} \;

And tell me how many pointers to ECN you'll find. Easy?

> In addition, ECN provides some significant advantages for users who aren't
> afflicted with Zylex routers.

Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't
have ISDN around. Now let me tell you that possibly Zyxel is the biggest
SOHO ISDN router vendor in Europe. So what? At least it's a nice exercise
for the users isn't it? It gives them deep insight into networking. So in
the end you are doing a favour to everybody, right? Where is the
semi-professional network admin that hasn't wished his whole life through
to be able to spend two days debuging a newly arived Debian box that *as
only machine* in the whole LAN isn't able to route out?

> I don't dispute that there are many cases where software authors are willing
> to accomodate broken client / server behavior, whether their goal is market
> share or mind share.  I just disagree that authors/maintainers have any
> *obligation* to accomodate software or hardware which is not
> standards-conformant.
>
> The solutions proposed to date all seem to be either contrary to policy, or
> contrary to the wishes of the maintainers of the affected packages.  Under
> such circumstances, I don't see where there's cause for questioning the
> maintainers' decisions.

You are right. A package maintainer - even if it's a fundamental package
as dpkg or the kernel or whatever can go and screw his users. It's up to
him. I wouldn't go as far as saying that this is precisely happening here,
at least not consciously because I doubt anybody who's pro ECN in the
kernel has had to debug a situtation such as described above.

But you can sure tell from my enthusiasm, and I'm no networking idiot,
that I *do* feel strong about it and that's exactly because I had fun
lately with it and I don't think it's necessary for everybody who happens
to have the bad luck to find itself in the same position to forcibly
repeat that lovely experience. And you can be certain that if the
situation stays as it is, I will not be the last one.

But tell me *one* thing:

Why is it so hard to change a few lines and have the default be
set to *off* and let whoever feels like it enable it?

?!?!

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: funny idle time from time

[Norbert Veber]

On Sat, Sep 01, 2001 at 12:12:46PM +1000, Craig Sanders wrote:
> On Sat, Sep 01, 2001 at 11:35:05AM +1000, Brian May wrote:
> > Also, if a computer is running slowly, but top says the CPU has plenty
> > of idle time and free RAM, is there anyway I can find out what is
> > wrong?
> 
> most likely slow disks.

Your system is supposed to multitask regardless if your disks are slow or
not.  Unfortunatelly the default settings are quite conservative and give
very bad performance via older disks.

Try reading man hdparm.  The most useful setting is enabling DMA (which
needs additional kernel support for your chipset), there is also the unmask
irq setting which lets your machine (somehow) process other interrupts while
waiting for disk IO, and the 32-bit access.

This however can lead to data corruption on crappy hardware, so test
thoughtly before making the change long-term..

Thanks,

Norbert


pgpjGdxza4ltI.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Mark Brown]

On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:

>Sorry, but if some maintainers complain about this mails (without
>real work on there site) now, they don't make a good work in the
>future. 

To be honest, I find it more annoying getting form mails like the
notifications than to get mails which require some action on my part.

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


pgpGVGOrQc5Gi.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Remco van de Meent]

Eric Van Buggenhaut wrote:
> Routers aren't forced to support ECN (although it's in their
> interest) but they aren't allowed to drop ECN-flagged TCP packets.
> 
> If you can't access a site, *they* need to fix their buggy router to be
> ECN-tolerant. If they don't do so, they're violating RFC 793.
> 
> http://www.ietf.org/rfc/rfc793.txt?number=793

I wonder how an _IP_ layer protocol can break a _transport_ (TCP) layer
specification. Also, it is up to a router whether or not to drop
packets based on their contents. It's not something you can enforce.

But anyway - I agree that Debian should not be too conservative with
regard to new networking technologies, so disabling ECN by default is
not something I'd like to see happen. Give the user some short
explanation and let him make the decision himself, I'd say.


regards,
Remco.

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote:

> Routers aren't forced to support ECN (although it's in their interest) but 
> they
> aren't allowed to drop ECN-flagged TCP packets.
>
> If you can't access a site, *they* need to fix their buggy router to be
> ECN-tolerant. If they don't do so, they're violating RFC 793.

Well possibly you can just send a site that doesn't support ECN to where
the light don't shine.

But if *your* (as in your universities, your lan's, your workplace,
your client's etc.) router is broken then what?

Then you can not ignore it. But they can ignore *you*!

And there is equipment that *can not* be fixed (check the thread why not).

And so what do you expect a user (possibly a newby!!! mind you, there are
newbies that start with Debian) with a 2.4 Debian kernel to do? To start
debuging the network to find out what the hell is wrong? To look around
and think gee, all the machines around me are working *only mine* not.

What would *you* think at that moment? I would maybe think that the
networking card is broken. So you are telling me you want to send
(your!) Debian users runing around expecting them to go debug whatever
place they might find themselves at that moment?

Or do you expect to change the world to change at your will just because
Debian has decided to set a flag which is *off* by default?

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: new port: the never ending story

[Eric Van Buggenhaut]

On Mon, Sep 03, 2001 at 11:15:03AM +0200, A Mennucc1 wrote:
> 
> hi
> 
> 
>   --- still on the name
> 
> 
> let's start by a few quotations:
> 
> "an arch is an arch is an arch is an arch"
> 
> "an arch by any other name would work the same"
> 
> "shut up and show them the arch"
> 
> it: "l' arch e' l'apostrofo rosa fra le parole 'package' e '.deb'"
> en: "the arch is the pink apostrophe between 'package' and '.deb'"
> 
> what I mean is: is the name of the arch so so so so relevant?
> when we are sure that it makes reasonable sense, and that 
> it has no legal problems, doesnt this suffice?
> 

Please do your port, don't waste your energy in such futile debates :) If I'm
interested in the port, I don't give a shit to what name it'll have. I just
want it to *work*

Thanks.

-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Make money at home with your PC

[David]

I'll make you a promise. 
 
READ THIS E-MAIL TO THE END! 
 
- follow what it says to the letter - 
 
and you will not worry whether a RECESSION is coming or not, 
who is President, or whether you keep your current job 
or not. 
 
Yes, I know what you are thinking. I never responded 
to one of these before either. One day though, something 
just said "you throw away $25.00 going to a movie for 2
hours". "What the heck." Believe me, no matter where you 
believe "those feelings" come from, I thank goodness every 
day that I had that feeling.  I cannot imagine where I would 
be or what I would be doing had I not. 
 
AS SEEN ON NATIONAL TV:
 
Making MONEY every month from your home.
 
THANK'S TO THE COMPUTER AGE AND THE INTERNET !

JOIN THE RANKS OF THOSE MAKING SERIOUS MONEY AT HOME
 
Before you say ''Bull'', please read the following. 
This is the letter you have been hearing about on the news 
lately. Due to the popularity of this letter on the Internet, 
a national weekly news program recently devoted an entire 
show to the investigation of this program to see if it
really can make people money. The show also investigated 
whether or not the program was legal.
 
Their findings proved once and for all that there are 
''absolutely NO Laws prohibiting the participation in the 
program and if people can "follow the simple instruction" 
they are bound to make money with only $25 out of pocket cost''. 
 
DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING 
BETTER THAN EVER.
 
Read on.  It's true. Every word of it. It is legal simply 
because you are buying and selling something of value.
 
This is what one had to say: '' Thanks to this profitable 
opportunity". I was approached many times before but each 
time I passed on it. I am so glad I finally joined just to 
see what one could expect in return for the minimal effort 
and money required. To my astonishment, I received a total 
$610,470.00 in 21 weeks, with money still coming in''. 
Pam Hedland, 
Fort Lee, New Jersey.
==
Another said: "this program has been around for a long time 
but I neverbelieved in it. But one day when I received this 
again in the mail I decided to gamble my $25 on it. I 
followed the simple instructions and waited. 3 weeks later 
the money started to come in. First month I only made 
$240.00 but the next 2 months after that I made a total of 
$290,000.00. So far, in the past 8 months by re-entering 
the program, I have made over $710,000.00 and I am playing 
it again. The key to success in this program is to follow 
the simple steps and NOT change anything.'' 
 
More testimonials later but first, ===
 
 PRINT THIS NOW FOR YOUR FUTURE REFERENCE 

 
If you would like to make at least $500,000 every 4 to 5 
months easily and comfortably, please read the following...
THEN READ IT AGAIN and AGAIN!!!
 

 
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR 
FINANCIAL DREAMS WILL COME TRUE!
 
INSTRUCTIONS:
 
You will be buying 5 reports for $5 each, a total of $25.
 
=Order all 5 reports shown on the list below =
 
For each report, send $5 CASH, THE NAME & NUMBER OF THE 
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the 
person whose name appears ON THAT LIST next to the report. 
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT 
CORNER in case of any mail problems.
 
===WHEN YOU PLACE YOUR ORDER, MAKE SURE ===
===YOU ORDER EACH OF THE 5 REPORTS! ===
 
You will need all 5 reports so that you can save them on 
your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.
 
Within a few days you will receive, via e-mail, each of the 5 
reports from these 5 different individuals. Save them on your 
computer so they will be accessible for you to send to the 
1,000's of people who will order them from you. Also make a 
floppy of these reports and keep it on your desk in case
something happens to your computer.
 
IMPORTANT - DO NOT alter the names of the people who are listed 
next to each report, or their sequence on the list, in any way 
other than what is instructed below in step '' 1 through 6 '' 
or you will loose out on the majority of your profits. Once you 
understand the way this works, you will also see how it does not 
work if you change it. Remember, this method has been tested, and 
if you alter it, it will NOT work !!! 
 
People have tried to put their friends/relatives names on all five 
thinking they could get all the money. But it does not work this way. 
Believe us, some have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed.
Because if you do, it will not work for you. Remember, honesty reaps 
the reward!!!
 
This IS a legitimate BUSINESS. You are offering a product for sale and 
getting paid for it. Treat i

Re: "Folio" file types / AS Physics

[Constantine Karastamatis]

Hereward Cooper:

I think I found what you are looking for. It will not let you view it
directly, but it will let you convert it to html. It is called nse2html.
Since it is only 2k, I have attached a gzipped version. It seems that it
is in perl so I think just running it will work.

My source was
http://www.mathematik.uni-kl.de/ftp/pub/Sources/Network/html_converters/nse2html/

If you have any other question email me - not just the mailing list.

Constantine Evans



nse2html.pl.gz
Description: GNU Zip compressed data

Re: reopening ECN bugreport/netbase

[Peter S Galbraith]

I, for one, am very thankful for this thread.  I could no longer
connect to some sites which I used in daily work collaborations
for some time now.  Turns out it's since an upgrade from 2.2 to
2.4.  I have now disabled this option in the 2.4 kernel and now
connect again.

Thanks!

(Yes, it's info that users should be made aware of)

Peter

Re: Bug#111309: ITP: xtail -- like "tail -f", but works on truncated files, directories, more

[Eric Van Buggenhaut]

On Wed, Sep 05, 2001 at 03:00:08PM -0400, Roderick Schertler wrote:
> On Wed, 5 Sep 2001 20:44:29 +0200, Eric Van Buggenhaut <[EMAIL PROTECTED]> 
> said:
> >
> > Does 'x'tail mean it's a GUI app ?
> 
> Nope.


Do you want to go for another name then ? I find it quite confusing. mtail or
multitail might be clearer.

Thanks/

-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: sysctl should disable ECN by default

[Steve Langasek]

On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:

>>> The question is only if devices should be programmed in order to know
>>> the future and it's potential proposed stadards by the IETF. Mind you I
>>> don't know if the devices in question (websites, routers etc. droping ECN
>>> packets) *are* violating a standard that was current at *their* time. The
>>> routers in particular I think *are* wrong, since they are making decisions
>>> based on bits that at that time were reserved.

>> The devices in question *are* violating the standards that existed at the 
>> time
>> they were created.  The bits that they're fiddling with are *reserved*.  That
>> means "don't touch".  They were in violation of the TCP/IP protocol from day
>> one, it's just that it's only now that the IETF is making use of those bits,
>> /as is their right/, that the problem with this equipment has come to light.

> That's what I was saying wasn't I?

You appeared to be allowing the possibility that the manufacturers of these
devices were in the wrong.  I am stating that it is unequivocally so.  In
other words, the bug is theirs.  If the maintainers of the Debian packages in
question choose to accomodate routers that suffer from this bug, hooray for
them.  If they choose not to, hooray for them -- there is no great moral
imperative which requires them to go to lengths to work around the bugs of
proprietary vendors.

You may object that this contradicts the Social Contract, because our users
should be our priority.  But these routers are broken; ECN will become a
standard; and the affected parties will have to replace their routers with
something that works, sooner or later.  Is it more to our users' advantage in
the long term if we give them early warning that there is a problem, or if we
choose not to 'rock the boat' until it's too late and these same users wake up
one day to find themselves in a world where no operating system on the world
works with their router?

At least this way, users who have broken routers will find out about the
problem early, can easily disable the ECN behavior if they need to, and
can set about finding a solution to the real problem.

In addition, ECN provides some significant advantages for users who aren't
afflicted with Zylex routers.

> > > But tell me, in case there's an IMAP client that has some problems with
> > > the IMAP protocol. Should a Debian box by default *refuse* to talk
> > > to it or should the default be to try to talk to it (provided that it
> > > can)?

> > Are you joking?  If someone filed a bug against my package saying I should
> > make changes to it to accomodate a broken client (equivalent: my IMAP server
> > sends back a valid IMAP response and this causes the client to segfault), I
> > would immediately close the bug with a smile and a have-a-nice-day.

> Good for you. And the people that *need* a working server as in "it forks
> for *me*" will move on and ignore you. That's your choice. It's the choice
> Debian is making now.

> But if care about the real world you will see that the philosophy of most
> software isn't "I'm right have-a-nice-day" but let's have "something that
> works". Check the kernel. Check IMAP servers (that's why I was choosing
> this example), check well whatever, many things try to cooperate with
> broken stuff.

I don't dispute that there are many cases where software authors are willing
to accomodate broken client / server behavior, whether their goal is market
share or mind share.  I just disagree that authors/maintainers have any
*obligation* to accomodate software or hardware which is not
standards-conformant.

The solutions proposed to date all seem to be either contrary to policy, or
contrary to the wishes of the maintainers of the affected packages.  Under
such circumstances, I don't see where there's cause for questioning the
maintainers' decisions.


> >  c) sue the vendor for selling a product under false pretenses, with the
> > goal of achieving either a) or b) above.

> Do *you* do that for all the things that don't work as they should?

Yes, quite frankly.  Personally, I use only Free Software and software that
runs on top of Free OSes.  Professionally, I work for an ISP, and we expect
our vendors to live up to the promises they make.

> And even if, why should you force others to behave similary?

Me?  I'm not forcing anyone to do anything.  I'm merely pointing out that
users of broken equipment do have other recourses besides expecting Debian to
fix everything.

Steve Langasek
postmodern programmer

Re: sysctl should disable ECN by default

[Eric Van Buggenhaut]

On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
> 
> > Why should the default configuration be changed to account for the 
> > diminishing number of broken routers on the net?
> 
> >From a technical behavior, throwing away packets with unknown protocol
> flags is perfectly acceptable in any case and even reasonable in some
> environments.

No it's not, you're violating RFC 793.

-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Wed, Sep 05, 2001 at 09:13:00AM -0500, Branden Robinson wrote:
> On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote:
> > Do package descriptions change so regularly that translated descriptions
> > couldn't be submitted through the bug tracking system and included
> > in the next upload?
> 
> That doesn't serve the purpose of hijacking pieces of the maintainer's
> package away from him, which, as you'll note, is the foundational
> premise of Michael Bramer's entire proposal.
> 
> He doesn't want the maintainer involved at all, except to sit by
> helplessly and get flooded with emails notifying him that his package
> has been modified yet again.

sorry, branden.

 1.) you speak only about the 1. proposal
 2.) In the last proposal, I propose a way to include the translation
 in the package. This proposal has some improvments and is more
 exact.
 3.) I don't flooded the maintainer.
 4.) In this list and per PM I get some request about this mails. If I
 hadn't support this mails, some maintainers whould have wept.
 5.) I ask yesterday if we should stop this mails, and only some make this
 request. 
 6.) I and some other translators get some 'Thanks' after the
 notifcation mail. This is not wrong in all ways.
 7.) This notification mails are like the mails from the BTS or from
 katie
 8.) This mails are not helplessly. I know some translators, who get
 improvments from the maintainer. 
 9.) If you right and this mails are useless, we should put the
 maintainer out of the loop. But you are wrong. Some maintainers
 are very active and help the translators. 
10.) Make you the request to send this all to the BTS?

If we make the translations, we have two excesses:
 - we put the maintainer really in the loop (without a override file)

   With this the maintainers get some mails from the translator
   project. More like now. Now we only at the start, now we don't make
   a real review process. Now we have only 10 languages. 
   
   In this case the maintainer must make the whole work after the
   translation.

   Sorry, but if some maintainers complain about this mails (without
   real work on there site) now, they don't make a good work in the
   future. 

 - we put the maintainer out of the loop

   The maintainer need not do anything. Maybe he don't know the
   translation. The user only use this. This need only the
   translators.

I don't propose one of this excesses now. I post a proposal with both
sites. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
«Computers are like air conditioners -- they stop working properly if i
 you open WINDOWS»


pgppMJua4uT92.pgp
Description: PGP signature

Re: Translating Debian packages' descriptions

[Joey Hess]

Martin Quinson wrote:
> Ouch ! As translator, I can promise you that if Joey Hess had removed all my
> translation just because he added 'gnome' to the list of choices, he would
> had to search out another french translator !

Maybe I'd better start looking, because:

> PS: this perticular problem is fixed, since I updated the french
> translation. But the problem still exists for these languages: de, fi, gl,
> it, ja, ko, nl, pl, pt_br, ru, sv, zh_cn and zh_tw. 
> To whom should I send my translation bug reports ? ;)

debconf (1.0.00) unstable; urgency=low
...
- modifiying the debconf/frontend's template description, thus making
  all the translatione be out of date again, right as I release 1.0.
  Bleh. I was able to clean up the french template, but all the other
  translations of that template were too out of date to live, so I
  removed it from them.
...
 -- Joey Hess <[EMAIL PROTECTED]>  Tue, 28 Aug 2001 16:37:27 -0400

-- 
see shy jo

Re: Translating Debian packages' descriptions

[Joey Hess]

Raphael Hertzog wrote:
> Also, I like that we use the gettext mechanism because at least we
> have no translated description when it has been updated instead of
> an outdated description. Better have a correct english description
> than a wrong translated one. This problem is common with debconf 
> actually. [1]
> 
> Cheers,
> 
> [1] For example, using my "fr" environnment I could'n reconfigure
> debconf to use the Gnome frontend, it wasn't listed in the
> proposed choices because the french translation was outdated and
> didn't include the new Gnome frontend. The contrary can happen,
> a choice has been removed but my french translation does still
> propose it :(
> I should have submitted a bug about this so that we can find a
> solution for debconf ... 

Maybe you missed my mail in which I stated that now that someone had
bothered to tell me this was a problem, I could fix in it about oh, 10
minutes.

The only reason I have not yet is that debconf is currently frozen,
along with the rest of the base system.

-- 
see shy jo

Re: reopening ECN bugreport/netbase

[Eric Van Buggenhaut]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> On Wed, 5 Sep 2001, Anthony Towns wrote:
> 
> > severity 110892 wishlist
> > thanks
> >
> > On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > > # > > I don't know if this is the right place to assign the bug.
> >
> > It's not a bug at all really, and it's certainly not a "critical" one.
> 
> >From the docu:
> 
> critical   makes unrelated software on the system (or the whole system)
>break, [...]
> 
> This is *exacly* what happens after an update from a vanilla 2.2.x kernel
> to a 2.4. Some sites plain disapear from the internet, which is not a
> catastrophy. What's worse is that with some routers you will *completely*
> loose TCP network connectivity. If you happen to be using your box as a
> firewall it's the whole LAN that'll be dropped.
> 
> How does this differ from the phrasing ".. or the whole system) break"?
> Does there need some physical violence be involved to fullfill the
> requirements for a critical bugreport?
> 
> > If
> > you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> > to /etc/sysctl.conf (which is a much better place for such things than
> > /etc/network/options) and be done with it.
> 
> I couldn't care less about ECN or whatever acronym. The problem is that
> "the whole system) break"s. That's a problem. And this will happen at
> every single site that f.ex. is using an mildly old Zyxel router.

Routers aren't forced to support ECN (although it's in their interest) but they
aren't allowed to drop ECN-flagged TCP packets.

If you can't access a site, *they* need to fix their buggy router to be
ECN-tolerant. If they don't do so, they're violating RFC 793.

http://www.ietf.org/rfc/rfc793.txt?number=793


-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: step by step HOWTO switch debian installation into utf-8

[Henrique de Moraes Holschuh]

On Wed, 05 Sep 2001, Radovan Garabik wrote:
> I have however other problems with ttf fonts - they are 
> EXTREMELY slow. When I use arialuni.ttf (25MB font with the best
> unicode coverage) as main font in konqueror, just drawing a page
> in ASCII takes 2 minutes (PIII 600 MHz). During those 2
> minutes, X are unresponding, I cannot even switch to the console.
> Using fontserver at least allows me to switch to the console,
> and using -deferglyphs all helped a bit, but really only a bit.

Use the xfs-xtt font server (which does well with really big fonts, unlike
the xfsft crap), do not allow the X server to touch such heavy fonts.  Also,
setting deferglyphs=16 in both the X server and the font server might save
you a lot of grief.

> mode and console unusable. This does not seem to happen when I limit
> myself to non-UCS fonts.

Well, the UCS codepath is not as widely used and tested as the ISO-8859
ones; and CJK fonts (as well as unicode fonts, obviously) sometimes make
very have usage of features of the ttf spec that "easy" fonts will not
touch...

I repeat: do not allow the X server to even touch ttf fonts, or you risk
crashes. Use the xfs-xtt font server instead (at least, when it crashes, it
does not bring down the entire system... and you can have it in inittab or
something like that to kick the font server back online as soon as it
segfaults).

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

Re: 2.4 bootdisk for testing?

[Eduard Bloch]

#include 
T.Pospisek's MailLists wrote on Wed Sep 05, 2001 um 02:57:16PM:
> Make sure you have ECN disabled on those bootdisks otherwise some people
> will be finding out that to their surprise they are not able to download
> their packages via the network. See the recent ECN thread.

ROTFL. Look first who started the ECN thread ;)

Gruss/Regards,
Eduard.
-- 
!netgod:*! time flies when youre using linux
!doogie:*! yeah, infinite loops in 5 seconds.
!Teknix:*! has anyone re-tested that with 2.2.x ?
!netgod:*! yeah, 4 seconds now

Re: Bug#110892: reopening ECN bugreport/netbase

[Steve M. Robbins]

Hey Guys,

I think Anthony mistyped the bug# here.  This has nothing to do
with gdk-imlib1.

Cheers,
-Steve


On Wed, Sep 05, 2001 at 11:44:01PM +1000, Anthony Towns wrote:
> severity 110892 wishlist
> thanks
> 
> On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > # > > I don't know if this is the right place to assign the bug. 
> 
> It's not a bug at all really, and it's certainly not a "critical" one. If
> you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> to /etc/sysctl.conf (which is a much better place for such things than
> /etc/network/options) and be done with it. AFAIC, the default settings'll
> remain exactly as they are in the kernel.
> 
> Cheers,
> aj
> 
> -- 
> Anthony Towns <[EMAIL PROTECTED]> 
> I don't speak for anyone save myself. GPG signed mail preferred.
> 
> ``_Any_ increase in interface difficulty, in exchange for a benefit you
>   do not understand, cannot perceive, or don't care about, is too much.''
>   -- John S. Novak, III (The Humblest Man on the Net)



-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: sysctl should disable ECN by default

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Steve Langasek wrote:

> On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
>
> > On Wed, 5 Sep 2001, Guillaume Morin wrote:
>
> > > Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > > > From a technical behavior, throwing away packets with unknown protocol
> > > > flags is perfectly acceptable in any case and even reasonable in some
> > > > environments.
>
> > > I would not call reasonable dropping packets carrying bits of a protocol
> > > rated as Proposed Standard by IETF.
>
> > The question is only if devices should be programmed in order to know
> > the future and it's potential proposed stadards by the IETF. Mind you I
> > don't know if the devices in question (websites, routers etc. droping ECN
> > packets) *are* violating a standard that was current at *their* time. The
> > routers in particular I think *are* wrong, since they are making decisions
> > based on bits that at that time were reserved.
>
> The devices in question *are* violating the standards that existed at the time
> they were created.  The bits that they're fiddling with are *reserved*.  That
> means "don't touch".  They were in violation of the TCP/IP protocol from day
> one, it's just that it's only now that the IETF is making use of those bits,
> /as is their right/, that the problem with this equipment has come to light.

That's what I was saying wasn't I?

> > But tell me, in case there's an IMAP client that has some problems with
> > the IMAP protocol. Should a Debian box by default *refuse* to talk
> > to it or should the default be to try to talk to it (provided that it
> > can)?
>
> Are you joking?  If someone filed a bug against my package saying I should
> make changes to it to accomodate a broken client (equivalent: my IMAP server
> sends back a valid IMAP response and this causes the client to segfault), I
> would immediately close the bug with a smile and a have-a-nice-day.

Good for you. And the people that *need* a working server as in "it forks
for *me*" will move on and ignore you. That's your choice. It's the choice
Debian is making now.

But if care about the real world you will see that the philosophy of most
software isn't "I'm right have-a-nice-day" but let's have "something that
works". Check the kernel. Check IMAP servers (that's why I was choosing
this example), check well whatever, many things try to cooperate with
broken stuff.

> Anyone using such broken software should do the right thing, which is one of:
>
>  a) get a different IMAP client

If you have the choice. Which is an open question.

>  b) get an upgrade/fix for the IMAP client so that it's no longer broken.

If there is one. Which still is an open question.

>  c) sue the vendor for selling a product under false pretenses, with the
> goal of achieving either a) or b) above.

Do *you* do that for all the things that don't work as they should? And
even if, why should you force others to behave similary?

> The same applies to these POS Zylex routers.  There's no reason that Debian
> should be covering their asses when they refuse to provide firmware upgrades
> to their customers in a timely manner, especially when everyone else on the
> Internet has been ready to go with ECN for some time now.

There are a *lot* of places that are not reachable. "Everyone else"
doesn't reflect any reality.

But the question is if it's worth it for Debian to keep this anal "I am
right" position, just because of a flag, whose existence aparently doesn't
hurt people who're runing 2.2.x, which is *by default* disabled upstream
(take a second and ask yourself, why could this be?). What's certain is,
that it's going to hurt a lot of people.

Maybe a quote from the kernel docu can help:

> Note that, on the Internet, there are many broken firewalls which
> refuse connections from ECN-enabled machines, and it may be a while
> before these firewalls are fixed. Until then, to access a site behind
> such a firewall (some of which are major sites, at the time of this
> writing) you will have to disable this option, either by saying N now
> or by using the sysctl.
>
> If in doubt, say N.

Obviously, Debian is not in doubt about it's own users and knows better.
*t

PS: Since you're Cc:ing me in addition to the list, you maybe need an
extra copy as well.


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Wichert Akkerman]

Previously Nick Phillips wrote:
> Well, shouldn't it? Wouldn't it make sense to have the translated description
> in there rather than the original one?

I actually makes more sense to remove even the english description
from status to another location.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

"Folio" file types / AS Physics

[Hereward Cooper]

Hi,

Does anyone know how to read a "folio" file under linux/debian?
The file extension is a nfo.
I needed it as the new AS Physics Course now comes with the
text book on a CD. It uses, yes you guessed it, a windows based
program, called "Folio Views", and well I don't want to spend
any more time using windows than I have too.

Thanks,

Hereward

Re: sysctl should disable ECN by default

[Steve Langasek]

On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:

> On Wed, 5 Sep 2001, Guillaume Morin wrote:

> > Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > > From a technical behavior, throwing away packets with unknown protocol
> > > flags is perfectly acceptable in any case and even reasonable in some
> > > environments.

> > I would not call reasonable dropping packets carrying bits of a protocol
> > rated as Proposed Standard by IETF.

> The question is only if devices should be programmed in order to know
> the future and it's potential proposed stadards by the IETF. Mind you I
> don't know if the devices in question (websites, routers etc. droping ECN
> packets) *are* violating a standard that was current at *their* time. The
> routers in particular I think *are* wrong, since they are making decisions
> based on bits that at that time were reserved.

The devices in question *are* violating the standards that existed at the time
they were created.  The bits that they're fiddling with are *reserved*.  That
means "don't touch".  They were in violation of the TCP/IP protocol from day
one, it's just that it's only now that the IETF is making use of those bits,
/as is their right/, that the problem with this equipment has come to light.


> But tell me, in case there's an IMAP client that has some problems with
> the IMAP protocol. Should a Debian box by default *refuse* to talk
> to it or should the default be to try to talk to it (provided that it
> can)?

Are you joking?  If someone filed a bug against my package saying I should
make changes to it to accomodate a broken client (equivalent: my IMAP server
sends back a valid IMAP response and this causes the client to segfault), I
would immediately close the bug with a smile and a have-a-nice-day.

Anyone using such broken software should do the right thing, which is one of:

 a) get a different IMAP client
 b) get an upgrade/fix for the IMAP client so that it's no longer broken
 c) sue the vendor for selling a product under false pretenses, with the
goal of achieving either a) or b) above.

The same applies to these POS Zylex routers.  There's no reason that Debian
should be covering their asses when they refuse to provide firmware upgrades
to their customers in a timely manner, especially when everyone else on the
Internet has been ready to go with ECN for some time now.

Steve Langasek
postmodern programmer

Re: step by step HOWTO switch debian installation into utf-8

[Radovan Garabik]

On Wed, Sep 05, 2001 at 02:47:26PM +0200, Marek Habersack wrote:
> are set to the fixed-misc USC version and it seems to work fine. The only
> problem I have found is with the Unicode TTF fonts - mkttfdir doesn't
> generate correct fonts.dir file for those AFAICT - all entries have their
> charset set to ISO-8859-1 in the generated file.

use ttmkfdir instead. It still does not generate 10646 encoding in output,
but at least it will put there all the encodings that the font covers,
and you can add 10646 entry by hand.

I have however other problems with ttf fonts - they are 
EXTREMELY slow. When I use arialuni.ttf (25MB font with the best
unicode coverage) as main font in konqueror, just drawing a page
in ASCII takes 2 minutes (PIII 600 MHz). During those 2
minutes, X are unresponding, I cannot even switch to the console.
Using fontserver at least allows me to switch to the console,
and using -deferglyphs all helped a bit, but really only a bit.

Using ttf font with less characters (lucida sans unicode, 300 KB)
cuts down the time to 30 seconds - still untolerable.

and X seems to be really unstable - mean time between crashes was reduced
to 1 hour. 

So I replaced ttf fonts with bdf (unicode) fonts, speed is OK, 
but the X still keep crashing - in average once per day, but what is
worse, they now crash really hard, leaving VGA adapter in graphical 
mode and console unusable. This does not seem to happen when I limit
myself to non-UCS fonts.

-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: sysctl should disable ECN by default

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Guillaume Morin wrote:

> Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait :
> > The question is only if devices should be programmed in order to know
> > the future and it's potential proposed stadards by the IETF. Mind you I
> > don't know if the devices in question (websites, routers etc. droping ECN
> > packets) *are* violating a standard that was current at *their* time. The
> > routers in particular I think *are* wrong, since they are making decisions
> > based on bits that at that time were reserved.
>
> It is not a good debate. Devices can be upgraded. Net admins should do
> their job.

You will not be able to upgrade a Zyxel Prestige 2864i. And a lot of
other old equipment.

> > With ECN set, Debian's default is to plain *refuse* to talk to all
> > equipment which, for whatever reason has problems with ECN.
>
> Debian default does not refuse to talk, it is the broken
> routers/firewalls which do.

Yes - it does. By knowingly setting a flag which is known (!) to cause
trouble.

> Should we stop progress because admins do not their job. I do not think
> so.

There is no one taking your right away to:

echo 1 > /proc/sys/net/ipv4/tcp_ecn

and march ahead on the edge of progress. It's another thing though to set
this flag on default and leave the user in the dark why wondering why
suddenly connectivity has ceased. Which is what Debian does.

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: e2fsprogs as an essential package

[Colin Watson]

On Wed, Sep 05, 2001 at 10:23:52PM +0800, [EMAIL PROTECTED] wrote:
> with reiserfs etc. shall we downgrade debian package e2fsprogs'
> essential state to at least to allow it to be removable? thanks!
> (one thing to notice is maybe the generic fsck wrapper?)

Perhaps it would make sense to put /sbin/fsck in its own small essential
package and have it depend on fsck-backend, which *fsprogs can provide.

fsck does link against libext2fs, though ... it uses
ext2fs_find_block_device() to get around a devfs problem. That function
doesn't seem inherently ext2-specific.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Nick Phillips]

On Thu, Sep 06, 2001 at 01:07:40AM +1000, Martijn van Oosterhout wrote:

> > The description is part of the package, can we agree on that one?
> > What is the difference between a translated description and the
> > original one, except for which language it is written in?

The original, canonical, description is part of the package, and a
necessary part at that. Others aren't.

They're just different representations of the original one, and don't
*need* to be provided by the maintainer. If the maintainer chooses to
provide, obtain, manage translations, fine. If not, also fine. The
translations are not a necessary part of the package, they are related
to it, and could be provided however is most convenient for the situation
at hand - not necessarily in one big lump.

> Well, all descriptions are in english by default and there is no real reason
> to store every description for every package on every machine/archive.

Exactly.

> > The package is the responsibility of the maintainer, and s/he has the
> > final words on all aspects of how it should be packaged (subject to
> > policy, of course).  To me, it looks like you want this changed, which
> > I think is a bad idea.
> 
> But then the maintainer has to take full responsibility to maintain the
> translations. And several maintainers have said they don't even want to know
> about new translations since they can be added without any action on their
> part.

Exactly again.

If translations are available both from the maintainer and from a separate
translation archive, it should be up to the user to decide which they want
to use. That would allow for all sorts of flexibility - as I said before,
you could even have different "translations" in the same language. I can
think of at least one way in which this could be useful.



Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
Someone whom you reject today, will reject you tomorrow.

Re: sysctl should disable ECN by default

[Guillaume Morin]

Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait :
> The question is only if devices should be programmed in order to know
> the future and it's potential proposed stadards by the IETF. Mind you I
> don't know if the devices in question (websites, routers etc. droping ECN
> packets) *are* violating a standard that was current at *their* time. The
> routers in particular I think *are* wrong, since they are making decisions
> based on bits that at that time were reserved.

It is not a good debate. Devices can be upgraded. Net admins should do
their job.

> With ECN set, Debian's default is to plain *refuse* to talk to all
> equipment which, for whatever reason has problems with ECN.

Debian default does not refuse to talk, it is the broken
routers/firewalls which do.

Should we stop progress because admins do not their job. I do not think
so.

-- 
Guillaume Morin <[EMAIL PROTECTED]>

 If you want the answers, you'd better get ready for the fire
   (System of a Down)

Re: sysctl should disable ECN by default

[Neil Spring]

> ECN is RFC2481
> 
> http://www.ietf.org/rfc/rfc2481.txt?number=2481

the internet draft by the same authors that supercedes
rfc2481 and is a "Proposed Standard" instead of an
"Experimental Standard" is draft-ietf-tsvwg-ecn-04.
It is listed under "working group standards track" at
http://www.rfc-editor.org/queue.html

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-04.txt

-neil

Re: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Scott Dier wrote:

> working fine.  The really broken part is firewalls and tcp/ip stacks on
> the internet that do things to TCP that they shouldn't and break your
> experience.
>
> Go bugreport those instead.

Never mind the users: they will be happy to spend two days debuging the
network to find out that "Ahhh, Debian is defending the flag of the true
IP compliance", where as *all* the other box he knows just work.

And yes, Debian can be proud to be right.
*t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Tomas Pospisek wrote:

> So *please* can we add something like:
>
>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
>
> to the kernel-image-2.4.x postinst.

Which of course will set up people who are stil runing potato, have a 2.4
kernel and *do* want/need ECN, since it will *silently* disable ECN.

So since netbase does not want to be the proper place, a better
fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
use debconf with a default value of "0" and to inform/ask the user about
it when installing a new kernel.

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: reopening ECN bugreport/netbase

[Scott Dier]

> critical   makes unrelated software on the system (or the whole system)
>break, [...]

The user experience is broken, not the software.  The software is
working fine.  The really broken part is firewalls and tcp/ip stacks on
the internet that do things to TCP that they shouldn't and break your
experience.

Go bugreport those instead.

-- 
Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://www.ringworld.org/  [EMAIL PROTECTED]

Re: reopening ECN bugreport/netbase

[Branden Robinson]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> >From the docu:
> 
> critical   makes unrelated software on the system (or the whole system)
>break, [...]
> 
> This is *exacly* what happens after an update from a vanilla 2.2.x kernel
> to a 2.4. Some sites plain disapear from the internet, which is not a
> catastrophy.

PUT THE CRACK PIPE *DOWN*.

-- 
G. Branden Robinson| Suffer before God and ye shall be
Debian GNU/Linux   | redeemed.  God loves us, so He
[EMAIL PROTECTED] | makes us suffer Christianity.
http://people.debian.org/~branden/ | -- Aaron Dunsmore


pgpSvcK8mo3Dw.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Tollef Fog Heen]

* Tomas Pospisek 

| ) then it's the kernel-image package that needs to make sure it's runing
| in a sane environment. So *please* can we add something like:
| 
|   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
|   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
|   fi
| 
| to the kernel-image-2.4.x postinst.

This is not allowed.  /etc/sysctl.conf is a conffile and a package
must not modify other packages' conffiles.

And the reason why this breaks with Zyxel routers is that the routers
are broken.  Reassign the bugs against zyxel or something. ;)

-- 

Tollef Fog Heen
You Can't Win

Re: sysctl should disable ECN by default

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote:

> On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote:
> >
> > It's not only *sites* that do not work with ECN. It's also *routers*. That
> > means if you have *one* router between you and your destination, that does 
> > not
> > support ECN, then you'll get *very* strange behaveour like hanging TCP
> > connections that somehow get halfway through but do hang never the less 
> > while
> > ping works. Please check my bugreport #110862. And amongst the broken 
> > equipment
> > are f.ex. (older?) Zyxel ISDN routers which are *very* popular.
>
> FYI,
>
>Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but 
> not 0x40 (ECN Echo) (TOS bits) on all SYN
>packets. This is the last official firmware. A beta firmware is available 
> internally which fixes this issue: (ZyXEL
>firmware v2.50(T.05)b6 | 03/28/2001)

So it's not only old routers. It's also new ones. Zyxel didn't get it.

But until this day Debian didn't get it either.

Whoever owns a Zyxel router that has this bug will be into troubles
with Debian unless s/he's a netwoking nerd that knows about ECN. Go
figure.

And while we're at it - if you happen to stumble accross a firmware-fix
for the Zyxel Prestige 2864i please point me to it. Because untill I fix
that, one of our customers will be runing a broken network.
*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: sysctl should disable ECN by default

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Guillaume Morin wrote:

> Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > From a technical behavior, throwing away packets with unknown protocol
> > flags is perfectly acceptable in any case and even reasonable in some
> > environments.
>
> I would not call reasonable dropping packets carrying bits of a protocol
> rated as Proposed Standard by IETF.

The question is only if devices should be programmed in order to know
the future and it's potential proposed stadards by the IETF. Mind you I
don't know if the devices in question (websites, routers etc. droping ECN
packets) *are* violating a standard that was current at *their* time. The
routers in particular I think *are* wrong, since they are making decisions
based on bits that at that time were reserved.

But tell me, in case there's an IMAP client that has some problems with
the IMAP protocol. Should a Debian box by default *refuse* to talk
to it or should the default be to try to talk to it (provided that it
can)?

With ECN set, Debian's default is to plain *refuse* to talk to all
equipment which, for whatever reason has problems with ECN.

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Martijn van Oosterhout]

On Wed, Sep 05, 2001 at 03:22:47PM +0200, Tollef Fog Heen wrote:
> * Nick Phillips 
> 
> | The translation of any part of a package, be it the text of error messages,
> | the text in control, or the text in debconf templates, does not need to
> | be part of the package, and hence certainly shouldn't have to be. The
> | translations can easily be completely abstracted from the package itself,
> | and that relieves the maintainer from having to have anything to do with 
> them.
> 
> The description is part of the package, can we agree on that one?
> What is the difference between a translated description and the
> original one, except for which language it is written in?

Well, all descriptions are in english by default and there is no real reason
to store every description for every package on every machine/archive.

> The package is the responsibility of the maintainer, and s/he has the
> final words on all aspects of how it should be packaged (subject to
> policy, of course).  To me, it looks like you want this changed, which
> I think is a bad idea.

But then the maintainer has to take full responsibility to maintain the
translations. And several maintainers have said they don't even want to know
about new translations since they can be added without any action on their
part.

I actually quite like the idea of allowing the farming of parts of a
package to other people. And since most people can't read more than a
language or two, it seems silly to require them to keep every translation
up-to-date.

It not like any functionality is being changed, just some text.

-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.

e2fsprogs as an essential package

[zw]

hi,

with reiserfs etc. shall we downgrade debian package e2fsprogs'
essential state to at least to allow it to be removable? thanks!
(one thing to notice is maybe the generic fsck wrapper?)

zw

Re: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Anthony Towns wrote:

> severity 110892 wishlist
> thanks
>
> On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > # > > I don't know if this is the right place to assign the bug.
>
> It's not a bug at all really, and it's certainly not a "critical" one.

>From the docu:

critical   makes unrelated software on the system (or the whole system)
   break, [...]

This is *exacly* what happens after an update from a vanilla 2.2.x kernel
to a 2.4. Some sites plain disapear from the internet, which is not a
catastrophy. What's worse is that with some routers you will *completely*
loose TCP network connectivity. If you happen to be using your box as a
firewall it's the whole LAN that'll be dropped.

How does this differ from the phrasing ".. or the whole system) break"?
Does there need some physical violence be involved to fullfill the
requirements for a critical bugreport?

> If
> you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> to /etc/sysctl.conf (which is a much better place for such things than
> /etc/network/options) and be done with it.

I couldn't care less about ECN or whatever acronym. The problem is that
"the whole system) break"s. That's a problem. And this will happen at
every single site that f.ex. is using an mildly old Zyxel router.

> AFAIC, the default settings'll remain exactly as they are in the kernel.

There's a problem and no one feels responsible. Well, so I reiterate from
the begining. If netbase is not responsible and that setting has to be
set through /etc/sysctl.conf and since the procps package is not supposed
to know what possible kernel-feature-configuration combinations are
possible/allowed (check this output:

error: '/proc/sys/net/ipv4/tcp_ecn' is an unknown key
(when starting from a 2.2.x kernel)

) then it's the kernel-image package that needs to make sure it's runing
in a sane environment. So *please* can we add something like:

if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
fi

to the kernel-image-2.4.x postinst.

*t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: sysctl should disable ECN by default

[Eric Van Buggenhaut]

On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote:
> 
> Zitiere Eduard Bloch <[EMAIL PROTECTED]>:
> 
> > Neil Spring wrote on Sat Sep 01, 2001 um 12:34:40PM:
> > 
> > > being turned off behind my back.  ECN doesn't need any
> > > more inertia slowing its deployment.  It's already an 
> > > experimental, off by default, addition to the kernel.
> > 
> > Why do many people think that it is OFF by default?
> > The fact is, it is ON (see kernel docs) and it breaks with many sites.
> > We could live long without this experimental feature, so why _force_
> > the users to use the feature now and make a stable distribution with
> > limited networking ability?
> 
> Incidentaly I'd today filled a *critical* bugreport against
> kernel-image-2.4.8 just because of that.
> 
> It's not only *sites* that do not work with ECN. It's also *routers*. That
> means if you have *one* router between you and your destination, that does not
> support ECN, then you'll get *very* strange behaveour like hanging TCP
> connections that somehow get halfway through but do hang never the less while
> ping works. Please check my bugreport #110862. And amongst the broken 
> equipment
> are f.ex. (older?) Zyxel ISDN routers which are *very* popular.

FYI,

   Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but 
not 0x40 (ECN Echo) (TOS bits) on all SYN
   packets. This is the last official firmware. A beta firmware is available 
internally which fixes this issue: (ZyXEL
   firmware v2.50(T.05)b6 | 03/28/2001)

-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: sysctl should disable ECN by default

[Eric Van Buggenhaut]

On Sat, Sep 01, 2001 at 04:39:30PM -0700, Neil Spring wrote:
> > Incidentaly I'd today filled a *critical* bugreport against
> > kernel-image-2.4.8 just because of that.
> 
> It lists as "Done"; perhaps you're expected to file it
> someplace else?
> 
> > The first *experimental* rfc for ECN dates from 1999. That's not like ages.
> > There's a lot of equipment online from that time.
> 
> No.  IP and TCP have been around a little longer.  The bits
> that ECN uses are RESERVED.  Reserved means "this will
> be used someday" not "this must be zero for the packet
> to be valid", and certainly not "set this bit to zero".
> 
> Blaming ECN for faulty IP implementations is wrong.
> Calling a box that reaches inside your IP frame to zero
> a bit in the TCP header a "router" is just wrong (this is
> what the Zyxel thing does wrong).
> 
> Finally, just a warning: calling it *experimental* is only 
> going to last a little while longer.  It's been approved as 
> a Proposed Standard, and is just waiting for it's RFC number.
> (don't think proposed is meaningless: SACK is just a proposed 
> standard.  header compression is just a proposed standard).


ECN is RFC2481

http://www.ietf.org/rfc/rfc2481.txt?number=2481

-- 
Eric VAN BUGGENHAUT "Oh My God! They killed init! You Bastards!"
--from a /. post
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Branden Robinson]

On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote:
> Do package descriptions change so regularly that translated descriptions
> couldn't be submitted through the bug tracking system and included
> in the next upload?

That doesn't serve the purpose of hijacking pieces of the maintainer's
package away from him, which, as you'll note, is the foundational
premise of Michael Bramer's entire proposal.

He doesn't want the maintainer involved at all, except to sit by
helplessly and get flooded with emails notifying him that his package
has been modified yet again.

-- 
G. Branden Robinson|I have a truly elegant proof of the
Debian GNU/Linux   |above, but it is too long to fit
[EMAIL PROTECTED] |into this .signature file.
http://people.debian.org/~branden/ |


pgpufZruavAvI.pgp
Description: PGP signature

Re: new port: the never ending story

[Branden Robinson]

On Wed, Sep 05, 2001 at 09:55:08AM +0200, A Mennucc1 wrote:
> ok, I think I will switch again to w32
> 
> I say again because that was my choice for 3 days, and then I thought
> that I didnt like w32 <-> w64 ; but again , who cares?
> 
> anyway, Real Life (tm) is hitting me hard; summer is over; if I find
> some web space I will put the work I did there, otherwise, the world will wait

Yeah, we'll all be holding our breath.

-- 
G. Branden Robinson|
Debian GNU/Linux   |   If existence exists,
[EMAIL PROTECTED] |   why create a creator?
http://people.debian.org/~branden/ |


pgpL9XYv8kg8V.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Vociferous Mole]

On 05-Sep-01, 07:09 (EDT), Nick Phillips <[EMAIL PROTECTED]> wrote: 
> If you look at it logically, *everything* that has to do with translations
> is quite distinct from the other tasks relating to package maintenance.
> 
> The translation of any part of a package, be it the text of error messages,
> the text in control, or the text in debconf templates, does not need to
> be part of the package, and hence certainly shouldn't have to be. The
> translations can easily be completely abstracted from the package itself,
> and that relieves the maintainer from having to have anything to do with them.

I disagree with this. Translation of text that is part of the upstream
source needs[1] to go to/through the maintainer, as it should be
integrated upstream.

Steve

[1] Okay, it *could* be sent directly upstream, but often the debian
maintainer has an established relationship to the upstream author,
and may be able to fit them into the package more cleanly.

Re: sysctl should disable ECN by default

[Guillaume Morin]

Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> From a technical behavior, throwing away packets with unknown protocol
> flags is perfectly acceptable in any case and even reasonable in some
> environments.

I would not call reasonable dropping packets carrying bits of a protocol
rated as Proposed Standard by IETF.

-- 
Guillaume Morin <[EMAIL PROTECTED]>

Oh, that is nice out there, I think I'll stay for a while (RHCP)

Re: reopening ECN bugreport/netbase

[Anthony Towns]

severity 110892 wishlist
thanks

On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> # > > I don't know if this is the right place to assign the bug. 

It's not a bug at all really, and it's certainly not a "critical" one. If
you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
to /etc/sysctl.conf (which is a much better place for such things than
/etc/network/options) and be done with it. AFAIC, the default settings'll
remain exactly as they are in the kernel.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpAOsq3spfIm.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Tollef Fog Heen]

* Nick Phillips 

| The translation of any part of a package, be it the text of error messages,
| the text in control, or the text in debconf templates, does not need to
| be part of the package, and hence certainly shouldn't have to be. The
| translations can easily be completely abstracted from the package itself,
| and that relieves the maintainer from having to have anything to do with them.

The description is part of the package, can we agree on that one?
What is the difference between a translated description and the
original one, except for which language it is written in?

The package is the responsibility of the maintainer, and s/he has the
final words on all aspects of how it should be packaged (subject to
policy, of course).  To me, it looks like you want this changed, which
I think is a bad idea.

-- 

Tollef Fog Heen
You Can't Win

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Nick Phillips]

On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote:

> Do package descriptions change so regularly that translated descriptions
> couldn't be submitted through the bug tracking system and included
> in the next upload?

Apparently maintainers regularly fail to do anything with them at all for
ages. Besides which there is no real *need* for the maintainers to be
required to take action to make translations available.

> Most of my packages have never had their description changed from
> when I first wrote it. It would be better if we could just include
> translated descriptions in the debian/control file.

The descriptions are just one of the parts of a package that needs to
be translated. It would make more sense to consider the way to deal with
*all* the text in the package that needs to be translated.

Why put the translations in the control file? Why not just make available
(either in the package, or elsewhere, depending on the means by which the
package is to be distributed, and the maintainer's knowledge and inclination)
the translations for the whole package in one place?


Cheers,


Nick, who is waiting for someone to tell him he's completely wrong.

-- 
Nick Phillips -- [EMAIL PROTECTED]
Tonight's the night: Sleep in a eucalyptus tree.

Re: step by step HOWTO switch debian installation into utf-8

[Marek Habersack]

** On Sep 05, Brian May scribbled:
> > "Marek" == Marek Habersack <[EMAIL PROTECTED]> writes:
> 
> Marek> Or just put LANG=en_GB in /etc/environment
> 
> Hmmm. Might be worth trying. However, either this is going to override
> the language chosen by gdm, or gdm is going to override this. Not an
> ideal solution.
I use this on my machine and have the locale set correctly to this value
when starting GDM. From what I could see, gnome-session reads the LANG=
variable and uses its value. I have set GNOME up so that all system fonts
are set to the fixed-misc USC version and it seems to work fine. The only
problem I have found is with the Unicode TTF fonts - mkttfdir doesn't
generate correct fonts.dir file for those AFAICT - all entries have their
charset set to ISO-8859-1 in the generated file.

marek

-- 
Visit: http://caudium.net - the Caudium WebServer

/* A completely unrelated fortune */
 Gnagloot, n.:  A person who leaves all his ski passes on his jacket just 
 to  impress people.   -- Rich Hall, "Sniglets" 
 
 
 
 

pgp8Lqa5l14zh.pgp
Description: PGP signature

Re: [woodm@equire.com: XFree86 common]

[Steven Hanley]

On Thu, Aug 30, 2001 at 08:34:45PM +0200, Marcus Brinkmann wrote:
> Give a person a fish, and he will won't starve today.  Teach him how
> to fish, and he will never have to starve anymore.

btw the use of person followed by he is kind of weird in the above.

and it opens us up to lots of fun interpretations...

Give a "man" a fish, and he wont starve today. Teach him how to fish, and he
will sit in a boat and drink beer all day.

Heard that from some comedian on the radio the other day AFAIR.

See You
Steve

-- 
[EMAIL PROTECTED] http://wibble.net/~sjh
Look Up In The Sky
Is it a bird?   No
Is it a planeNo
Is it a small blue banana?
Yes

Bug#111309: ITP: xtail -- like "tail -f", but works on truncated files, directories, more

[Roderick Schertler]

Package: wnpp
Version: N/A; reported 2001-09-05
Severity: wishlist

xtail watches the growth of files.  It's like running a "tail -f" on
a bunch of files at once.  It notices if a file is trunated and starts
from the beginning.  You can specify both filenames and directories on
the command line.  If you specify a directory, it watches all the files
in that directory.  It will notice when new files are created (and start
watching them) or when old files are deleted (and stop watching them).

It's available from http://www.unicom.com/sw/xtail/ .

The distribution doesn't include copyright terms.  I've mailed the author
about it.

-- 
Roderick Schertler
[EMAIL PROTECTED]

Re: 2.4 bootdisk for testing?

[T.Pospisek's MailLists]

Make sure you have ECN disabled on those bootdisks otherwise some people
will be finding out that to their surprise they are not able to download
their packages via the network. See the recent ECN thread.
*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote:
> On Wed, Sep 05, 2001 at 12:11:56PM +0100, Nick Phillips wrote:
> > I'd have thought that the current situation re. maintainers putting
> > translations into .debs makes it blindingly obvious that requiring them
> > to do so in order for a translation to become available is a bad idea.
> 
> Do package descriptions change so regularly that translated descriptions
> couldn't be submitted through the bug tracking system and included
> in the next upload?
> 
> Most of my packages have never had their description changed from
> when I first wrote it. It would be better if we could just include
> translated descriptions in the debian/control file.

See also the other mail: >50 changes in 10 days in main/sid

But if you include the translation only in the debian/control you have 
 - delays (maybe we have a override file and can solve this)
 - you will have outdated translations (like debconf now)
 - you must patch dpkg etc. in a wide way

We can include the translation in the package. This is not the
problem, but please not in the control file. The translation is no new
information of the package, it is only a translation. Only a other form of
the orignal text.

Please read the last proposal, I explain a possibly solution in it.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"We just typed make..."   -- (Stephen Lambrigh, Director of Server Product  
  Marketing at Informix about porting their Database to Linux)


pgpnEyGGJwokg.pgp
Description: PGP signature

reopening ECN bugreport/netbase

[Tomas Pospisek]

reopen 110862

# Here with I am reopening this bug.
#
# On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
#
# > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
# > >
# > > I don't know if this is the right place to assign the bug. Maybe the
# > > right place for this is netbase, ifupdown or kernel-package - I
# > > don't know. Please reassign the bug as you wish.
# >
# > This is certainly not the right place.  Anyway, it's your job to
# > decide, not mine.
#
# As it's up to me to decide: Yes, this is the right place. This *is* a
# bug of this kernel-image package. ECN is *not* a standard setting. It
# is marked experimental and is off by default in the upstream default
# config. The reason for this is wellknown and has been discussed in the
# ECN thread on debian-devel.
#
# I do agree with you that by not compiling ECN into the kernel module
# users will not be able to use it and will have to recompile their
# kernel.
#
# So the problem is upstream - ECN should be either a module or off by
# default even if compiled into the kernel.
#
# A workaround, which would be also to some extend cleaner would be to
# enable or disable ECN in netbase. A patch to netbase has been proposed
# in this same bugreport:
#
#   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=4
#
# There's a whishlist pending against netbase reporting the same problem:
#
#   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98228
#
# So I am going to follow up on that report now, which means that it is up
# to Anthony to hopefully include that patch in netbase allthough it is
# frozen.
#
# *t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: sysctl should disable ECN by default

[Florian Weimer]

Russell Coker <[EMAIL PROTECTED]> writes:

> Why should the default configuration be changed to account for the 
> diminishing number of broken routers on the net?

>From a technical behavior, throwing away packets with unknown protocol
flags is perfectly acceptable in any case and even reasonable in some
environments.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://cert.uni-stuttgart.de/
RUS-CERT  +49-711-685-5973/fax +49-711-685-5898

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Wed, Sep 05, 2001 at 01:13:35PM +0200, Radovan Garabik wrote:
> On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote:
> 
> > If we talk about translation, this is not a big problem. You must only
> > use gettext all the time. Maybe we can throw away the 'maintainer
> > name' problem with this. (You know it: maintainer fields with
> > ÖÄÜöüüßåñïééõú... in the name.)
> > 
> > We need only one .po file, like this 
> >  msgid "Werner Mueller <[EMAIL PROTECTED]>"
> >  megstr "Werner Mülller <[EMAIL PROTECTED]>"
> > And the german User see the 'right' Name of this maintainer all the
> > time. 
> 
> except that I would suggest to do it the other way round, having
> the proper full name as original, and individual languages
> will transform the name according to their established charset.
> (So that all latin 1 and latin 2 languages does not need to translate
> the proper form Werner Müller, but latin 2 languages will
> ASCIIfy Javier Fernandez-Sanguino Peña into Pena, and koi8-r 
> languages (russian) will use ASCII only form of both)

this is ok. 

This was not a proposal. it was only a first thought and should show,
that gettext can make more (and not only Descriptions...)

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"We just typed make..."   -- (Stephen Lambrigh, Director of Server Product  
  Marketing at Informix about porting their Database to Linux)


pgpDlbQuuhk0H.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Raphael Hertzog]

Le Wed, Sep 05, 2001 at 12:20:42PM +0100, Nick Phillips écrivait:
> > > It needs to be stored, in /var/lib/dpkg/status, as a single file.  This 
> > > is so
[...]
> > no, it does not store there. And I can explain it:
> 
> Well, shouldn't it? Wouldn't it make sense to have the translated description
> in there rather than the original one?

Status is for installed packages, what about packages that are not yet
installed ? 

Adam has an opinion, but while I agree that we may allow people
to put translated field in the control file, it's not the way that Debian
should use ... for all the reasons repeated over and over.

Grisu's initial solution is the best on the different points. Check
my summary somewhere else on this list.

Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguer sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Wed, Sep 05, 2001 at 12:20:42PM +0100, Nick Phillips wrote:
> On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote:
> 
> > > It needs to be stored, in /var/lib/dpkg/status, as a single file.  This 
> > > is so
> > > that dpkg can make safe updates to it.  Trying to sync multiple files is 
> > > not a
> > > simple solution.
> > 
> > no, it does not store there. And I can explain it:
> 
> Well, shouldn't it? Wouldn't it make sense to have the translated description
> in there rather than the original one?

(I hope I understand it right...)

No, don't touch the files in /var/lib/dpkg/*. Don't insert the
translation, don't replace the orignal with the translation. 

We should support not only one language, see should support more
languages at the same time with dpkg and with a nice fallback path.

And if we don't change the files in /var/lib/dpkg/, we don't need a
big patch in dpkg. dpkg is a core element in debian and it must be
stable. If we change a lot, we break (maybe) a lot. This is not nice.


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Ein Prompt! Um Himmelswillen! Ein Prompt!! HILF


pgpp7bt9qrP3Y.pgp
Description: PGP signature

Re: Date format (was: How many people need locales?)

[Martijn van Oosterhout]

On Wed, Sep 05, 2001 at 12:23:34PM +0100, Nick Phillips wrote:
> On Wed, Sep 05, 2001 at 12:53:37PM +0200, Petr Cech wrote:
> > On Tue, Sep 04, 2001 at 09:17:12PM +1000 , Martijn van Oosterhout wrote:
> > > Does that mean it should always take a certain format irrespective of the
> > > locale? If so, which format?
> > 
> > or number format. ie. in Czech decimal separator is `,' comma and in C it's
> > `.' dot. OK, now restart gnumeric in other locale and you cannot load the
> > file :((
> 
> Which implies that it needs to know the locale used by the file. This
> means that you either need to:
> 
> 1) always use the same locale, or
> 2) tell it which local is used by the file at load time, either manually or
>by the use of metadata in/around the file.

This could be tricky if the decimal point is the same as the seperator?

3,4,5,6  <- How many fields/numbers in that line?

That's why I prefer tab separated files...
-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Hamish Moffatt]

On Wed, Sep 05, 2001 at 12:11:56PM +0100, Nick Phillips wrote:
> I'd have thought that the current situation re. maintainers putting
> translations into .debs makes it blindingly obvious that requiring them
> to do so in order for a translation to become available is a bad idea.

Do package descriptions change so regularly that translated descriptions
couldn't be submitted through the bug tracking system and included
in the next upload?

Most of my packages have never had their description changed from
when I first wrote it. It would be better if we could just include
translated descriptions in the debian/control file.

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

Re: Date format (was: How many people need locales?)

[jcdubacq]

On Wed, 5 Sep 2001, Petr Cech wrote:

> On Tue, Sep 04, 2001 at 09:17:12PM +1000 , Martijn van Oosterhout wrote:
> > Does that mean it should always take a certain format irrespective of the
> > locale? If so, which format?
> 
> or number format. ie. in Czech decimal separator is `,' comma and in C it's
> `.' dot. OK, now restart gnumeric in other locale and you cannot load the
> file :((

In the save file, the locale should obviously be C. However, the display
and input of data should be according to the current locale.

-- 
Jean-Christophe Dubacq -- ATER en informatique à la faculté d'Orsay.
Tel: 01 69 15 76 43 / 06 64 86 10 56 --- Email: [EMAIL PROTECTED]

Re: Making better use of multiple maintainers

[Raphael Hertzog]

Le Tue, Sep 04, 2001 at 12:30:12PM -0400, Joey Hess écrivait:
> I would like to see this oft-requested feature, but in the meantime
> there is nothing to prevent you as a backup maintainer from seeing every
> bug for every package you backup maintain. debian-bugs-dist + procmail.
> Trivial.

Of course, but not many people use this ... trivial but still too
complicated.

Too expensive for people behind modem... of course they could subscribe via
their debian.org [1] address and use procmail on the Debian machines ... but
still it requires many efforts for a very little gain.

Cheers,

[1] That is only possible for actual developers and not future developer
or simply contributor ... and also not possible for the upstream author
(if he's interested in Debian).
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguer sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Radovan Garabik]

On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote:

> If we talk about translation, this is not a big problem. You must only
> use gettext all the time. Maybe we can throw away the 'maintainer
> name' problem with this. (You know it: maintainer fields with
> ÖÄÜöüüßåñïééõú... in the name.)
> 
> We need only one .po file, like this 
>  msgid "Werner Mueller <[EMAIL PROTECTED]>"
>  megstr "Werner Mülller <[EMAIL PROTECTED]>"
> And the german User see the 'right' Name of this maintainer all the
> time. 

except that I would suggest to do it the other way round, having
the proper full name as original, and individual languages
will transform the name according to their established charset.
(So that all latin 1 and latin 2 languages does not need to translate
the proper form Werner Müller, but latin 2 languages will
ASCIIfy Javier Fernandez-Sanguino Peña into Pena, and koi8-r 
languages (russian) will use ASCII only form of both)


-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Date format (was: How many people need locales?)

[Nick Phillips]

On Wed, Sep 05, 2001 at 12:53:37PM +0200, Petr Cech wrote:
> On Tue, Sep 04, 2001 at 09:17:12PM +1000 , Martijn van Oosterhout wrote:
> > Does that mean it should always take a certain format irrespective of the
> > locale? If so, which format?
> 
> or number format. ie. in Czech decimal separator is `,' comma and in C it's
> `.' dot. OK, now restart gnumeric in other locale and you cannot load the
> file :((

Which implies that it needs to know the locale used by the file. This
means that you either need to:

1) always use the same locale, or
2) tell it which local is used by the file at load time, either manually or
   by the use of metadata in/around the file.

-- 
Nick Phillips -- [EMAIL PROTECTED]
Think twice before speaking, but don't say "think think click click".

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Nick Phillips]

On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote:

> > It needs to be stored, in /var/lib/dpkg/status, as a single file.  This is 
> > so
> > that dpkg can make safe updates to it.  Trying to sync multiple files is 
> > not a
> > simple solution.
> 
> no, it does not store there. And I can explain it:

Well, shouldn't it? Wouldn't it make sense to have the translated description
in there rather than the original one?

-- 
Nick Phillips -- [EMAIL PROTECTED]
Slow day.  Practice crawling.

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Nick Phillips]

On Wed, Sep 05, 2001 at 10:41:53AM +0200, Christian Kurz wrote:
> On 01-09-04 Nick Phillips wrote:
> > On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote:
> > I don't expect most maintainers to be able or inclined to keep track of
> > a shedload of different translations, and those who are that keen should
> 
> May I ask if you are aware about the ongoing translation of the debconf
> templates via the bts? If yes, would you mind explaining what's the
> difference between keeping track of thsoe translation/bugreports and
> keeping track of the package translation via a simple ddts mail?

Yes. Ideally, the maintainer should not have to be involved in those
translations either...

If you look at it logically, *everything* that has to do with translations
is quite distinct from the other tasks relating to package maintenance.

The translation of any part of a package, be it the text of error messages,
the text in control, or the text in debconf templates, does not need to
be part of the package, and hence certainly shouldn't have to be. The
translations can easily be completely abstracted from the package itself,
and that relieves the maintainer from having to have anything to do with them.

It would also be very simple to have another subdirectory in the debian
area of the source into which any translations over which the maintainer
did wish to keep control could be placed (this would also be useful for
sending packages independently of any archive/CD set).

The fact that some maintainers want control of some of the translations
in their package should not force translators to rely on maintainers, and
should not force upon all maintainers the task of managing translations.



Translations do not "belong" in the package. It should be possible to
include translations in a package, but I don't see that this is a sensible
way to do it by default, all the time.



Cheers,


Nick

[hoping I've not missed something that
 means I'm making a prize tit of myself]
-- 
Nick Phillips -- [EMAIL PROTECTED]
You will soon forget this.

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Nick Phillips]

On Wed, Sep 05, 2001 at 08:00:18PM +1000, Martijn van Oosterhout wrote:

> > No, make it opt-in and don't sent them by defaulot.
> 
> Just checking, but having it optional is mutually exclusive with any final
> solution that involves the maintainer having to put the translation into the
> .deb. 

I'd have thought that the current situation re. maintainers putting
translations into .debs makes it blindingly obvious that requiring them
to do so in order for a translation to become available is a bad idea.

> If they don't get sent, how will the maintainer know when there are new
> translations?

They shouldn't need to know.

-- 
Nick Phillips -- [EMAIL PROTECTED]
Excellent day for putting Slinkies on an escalator.

Re: step by step HOWTO switch debian installation into utf-8

[Radovan Garabik]

On Wed, Sep 05, 2001 at 05:03:50PM +1000, Brian May wrote:
> > "Vociferous" == Vociferous Mole <[EMAIL PROTECTED]> writes:
> 
> >> doesn't look like it to me:
> >> 
> >> [503] [pluto:bam] ~ >LANG=en_AU:en_GB dia
> >> 
> >> Gdk-WARNING **: locale not supported by C library
> 
> Vociferous> From another message (in one of the numerous
> Vociferous> "translated descriptions" threads), you can set
> Vociferous> LANGUAGES=en_AU:en_GB, and it will do fallback.
> 
> Are you sure? As far as I can tell, the value of LANGUAGES is totally
> ignored.

it is LANGUAGE, and you have to set LANG to something (which
will be ignored in this case, but has to be set).

-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Date format (was: How many people need locales?)

[Petr Cech]

On Tue, Sep 04, 2001 at 09:17:12PM +1000 , Martijn van Oosterhout wrote:
> Does that mean it should always take a certain format irrespective of the
> locale? If so, which format?

or number format. ie. in Czech decimal separator is `,' comma and in C it's
`.' dot. OK, now restart gnumeric in other locale and you cannot load the
file :((
Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

<_Anarchy_> telsa: rommable debian will be potato chips

Re: step by step HOWTO switch debian installation into utf-8

[Michael Bramer]

On Wed, Sep 05, 2001 at 05:03:50PM +1000, Brian May wrote:
> > "Vociferous" == Vociferous Mole <[EMAIL PROTECTED]> writes:
> 
> >> doesn't look like it to me:
> >> 
> >> [503] [pluto:bam] ~ >LANG=en_AU:en_GB dia
> >> 
> >> Gdk-WARNING **: locale not supported by C library
> 
> Vociferous> From another message (in one of the numerous
> Vociferous> "translated descriptions" threads), you can set
> Vociferous> LANGUAGES=en_AU:en_GB, and it will do fallback.
> 
> Are you sure? As far as I can tell, the value of LANGUAGES is totally
> ignored.

no gettext use it as fallback. 

I find it in the source code and a note in the ABOUT-note in the
source tar from gettext.

But LANGUAGES is a extra eviroment, it is only used, if you have set a
normal LANG too.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Das ist das entscheidende Problem. Hirn ist heutzutage eine sehr seltene 
 und teure Resource" -- Ullrich von Bassewitz <[EMAIL PROTECTED]>


pgptGtQWYjbt2.pgp
Description: PGP signature

Re: How many people need locales?

[Eduard Bloch]

#include 
Tille, Andreas wrote on Wed Sep 05, 2001 um 10:33:43AM:

> In my opinion the problem is an obvious target for a debconf solution.
> 
> The user has just to press  one times:
> 
>  Do you want locales [y/N]

I did also suggested an --install-locales option for debootstrap (and
hope Anthone will include it in the next debootstrap release). The last
thing which is to be done is this question in the installer (what I
will try to intergrate today) and probably some more questions in the
base config. See attachment.

Gruss/Regards,
Eduard.
-- 
"Die Erfahrungen sind wie die Samenkörner, aus denen die Klugheit
emporwächst." (Konrad Adenauer)
#include 
Michael Bramer wrote on Mon Sep 03, 2001 um 09:25:04AM:

> maybe you don't use it, but a lot of user don't speak english or can't
> understand it. We must support locales and if a user can't speak
> english he pay this price. 
> 

I had another idea: integrate it into boot floppies (*) so the user has
never have to face English. How?

- before the initial debootstrap run, the user gets a question from
  dbootstrap: "Would you like to install support for languages other
  than English (default)? This would eat up about 9MB disk space."

- debootstrap will be patched to accept an argument like
  --install-locales, then it would install locales

- When the work is done, dbootstrap would ask "Would you like to keep
  the current language during the rest of Debian installation? This
  would require the preparation of locales support and need some
  additional disk space"

- If "yes", the current localisation data could be written to a special
  file and used in baseconfig when it is running the first time. 
  - Edit the /target/etc/locale.def file and enable the locale.
  - Run "chroot /target /usr/sbin/locale-gen" to generate the files.

Later, while doing other baseconfig jobs, it could also re-ask what you
suggested:
  
> Make a debconf question in base-config or in the locale package and
> ask the user
>  - install all locales
>  - install the locales from the list 
>   ...
> and write a nice /etc/loacle.gen and run locale-gen in the postinst.

And probably also:

"Would you like to change the localisation scheme completely to /foobar/? This 
would change the messages in your programs, the prefered charset, time/date 
formats and other stuff."

- Yes
- No
- All users but not root

If NO, it could ask for LC_CTYPE since it is often needed even if a
person does not like localized messages.

"Would you like to use localise'd charset (LC_CTYPE)? This is needed to enter
special charakters."

- Yes
- No
- All users but not root

Gruss/Regards,
Eduard.

PS: (*) I don't know if anyone would complain about additional size of
dbootstrap when the mentioned code is added to it.
-- 
"In my opinion MS is a lot better at making money than it is at making
good operating systems" (Linus Torvalds, August 1997)

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Tue, Sep 04, 2001 at 05:40:25PM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > > A proper solution, at the very least, invovles storing the data in the
> > > foo.deb{control.tar.gz/control} file.
> >
> > gettext is not a hack. Gettext for translations and dpkg use gettext
> > is self for translation. Why re-inventing the wheel?
> 
> gettext can not really be used for this data.
> 
> It needs to be stored, in /var/lib/dpkg/status, as a single file.  This is so
> that dpkg can make safe updates to it.  Trying to sync multiple files is not a
> simple solution.

no, it does not store there. And I can explain it:

 The translation is no new information, it is not new package
 metadata. It is only a translation, a other form of the exact same
 information. 

 You can update /var/lib/dpkg/status, you can change the format, you
 can do all things with it. You and you don't break the system. The
 system use only gettext and get a translation.

I quote Wichert:
'It has nothing to do with package metadata and does not belong there.'

He don't mean translation, but he has right. No package metadata
should not in include in the controll file and not in
/var/lib/dpkg/status.
 
> > I propose to store the translations in a some po.files and store this
> > in foo.deb{control.tar.gz}. But not in the control file.
> 
> They must be stored inline inside status/available.  This is the only sane way
> to implement atomic file updates.

you don't need atomic file updates with the translations. 

See a other example: the menu system.

This information is not in the control file, but you can make updates
without problems.

The translation is only a other form of the same information. You
don't need this information while the update process. You need the
translation only 
 - after the installation/update process (like dpkg --list)
 - and before the installation/update with dselect, apt-cache show,
   seach. 

There is no need of a atomic file updates. 

> > If you store the translation as normal field in the control file (like
> > Description-de: dff) you have outdated translations with the time.
> > And outdated translations is a very big problem.
> 
> zcat Packages_de.gz Packages_jp.gz | dpkg --merge-lang

and?

If in the dpkg database are changed description and in the Packages_de
file is one/some translation from the old description, you don't find
this this way. You will get outdated translation in the dpkg database. 

Only one number: in the last 10 days we have >50 changed description
 in sid/main 
   
If a description is already translated, we need 1-20 days to
change the translation also. You will have outdate translation all the
time in sid and testing. And we must handle this problem. 

Or didn't I understand your 'dpkg --merge-lang'?

> > this make the patch and the patch work. I don't stress the patch and
> > maybe it has one or two bugs. But it work with Descriptions on my
> > system.
> 
> Please stop just applying this to Description fields.  Make it generic.  dpkg
> supports user-defined fields, so this proposal/implementation should as well.

If we talk about translation, this is not a big problem. You must only
use gettext all the time. Maybe we can throw away the 'maintainer
name' problem with this. (You know it: maintainer fields with
ÖÄÜöüüßåñïééõú... in the name.)

We need only one .po file, like this 
 msgid "Werner Mueller <[EMAIL PROTECTED]>"
 megstr "Werner Mülller <[EMAIL PROTECTED]>"
And the german User see the 'right' Name of this maintainer all the
time. 

Gettext is generic with translations. You must only use it in the
output process of dpkg, dselect and apt. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Und mit doppelseitig bestrichenen Sandwiches baut man das
Perpetuum Mobile nach Murphy. -- Kristian Koehntopp in dasr


pgpRnHrQG2aDE.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Christian Kurz]

On 01-09-04 Wouter Verhelst wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:

> > Maybe I have on next WE more time and I can improve the server and
> > make this notification mail configable per package and someone can
> > remove his packages from the notification process. 

> You didn't already?

> Jeez... In the US, this is illegal... and isn't gluck located in the
> states?

Would you telling me which part of this emails make them exactly
illegal? They maybe annoying for some people, but they are not illegal
in my opion. [1]

Christian

[1] No, I'm not a lawyer.

P.S.: If you already call this e-Mails illegal, did you started lawsuits
against all other us-based senders of mails to you, which you consider
illegal?
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgp2W4MEEMiiZ.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Christian Kurz]

On 01-09-04 Nick Phillips wrote:
> On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote:
> I don't expect most maintainers to be able or inclined to keep track of
> a shedload of different translations, and those who are that keen should

May I ask if you are aware about the ongoing translation of the debconf
templates via the bts? If yes, would you mind explaining what's the
difference between keeping track of thsoe translation/bugreports and
keeping track of the package translation via a simple ddts mail?

Christian
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpK9nBMBbLu1.pgp
Description: PGP signature

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[Martijn van Oosterhout]

On Wed, Sep 05, 2001 at 07:03:42AM +0200, Wichert Akkerman wrote:
> Previously Michael Bramer wrote:
> > Maybe I have on next WE more time and I can improve the server and
> > make this notification mail configable per package and someone can
> > remove his packages from the notification process. 
> 
> No, make it opt-in and don't sent them by defaulot.

Just checking, but having it optional is mutually exclusive with any final
solution that involves the maintainer having to put the translation into the
.deb. 

If they don't get sent, how will the maintainer know when there are new
translations?
-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.