Re: isync vs mailsync

[Brian Nelson]

Brian May <[EMAIL PROTECTED]> writes:

> > "Colin" == Colin Walters <[EMAIL PROTECTED]> writes:
> 
> Colin> Brian May <[EMAIL PROTECTED]> writes:
> >> In my search for a "perfect" offline IMAP client(TM) I have
> >> looked at isync vs mailsync.
> 
> Colin> What's wrong with Gnus?  Perhaps with the Agent?  I admit
> Colin> I've never tried disconnected IMAP with it, but I see
> Colin> people talking about it on the ding lists.
> 
> Gnus seems to be slow and inefficient. In online mode, it doesn't seem
> to cache anything for any reason, so just reading a message you read
> seconds ago requires downloading it again. It also means that messages
> need to be downloaded again for offline reading.

There's a whole ton of caching options in gnus, but I haven't yet
figured out how they work.

> However, the real killer, was that I could not get offline reading to
> work with IMAP, only NNTP. Perhaps I was doing something wrong, not
> sure here. At the time I took the easy way out and concluded that IMAP
> wasn't supported .

Works fine here (gnus 5.8.8)

> Despite these problems, Gnus is the only program I have seen that will
> highlight replies to my mail, something I find very valuable in large
> mailing lists like this one.
> 
> Another alternative that looked good last time I tried was Mozilla, as
> it seems to have very good off-line mail support. However, it was
> buggy and often refused to enter mail groups for no good reason, so I
> gave up on that. Eventually I will have to try it again.

Offline downloading for me in Mozilla broke in 0.9.3, and I've heard
mail is/has been completely broken in cvs recently.

I've tried almost all the options mentioned in this thread (mutt +
mailsync, mozilla, gnus) and have settled on gnus.  It's really nice
once you get it to behave.

-- 
Brian Nelson <[EMAIL PROTECTED]>

Re: isync vs mailsync

[GOTO Masanori]

At 05 Sep 2001 09:43:09 +1000,
Brian May <[EMAIL PROTECTED]> wrote:
> Colin> Brian May <[EMAIL PROTECTED]> writes:
> >> In my search for a "perfect" offline IMAP client(TM) I have
> >> looked at isync vs mailsync.
> 
> Colin> What's wrong with Gnus?  Perhaps with the Agent?  I admit
> Colin> I've never tried disconnected IMAP with it, but I see
> Colin> people talking about it on the ding lists.
> 
> Gnus seems to be slow and inefficient. In online mode, it doesn't seem
> to cache anything for any reason, so just reading a message you read
> seconds ago requires downloading it again. It also means that messages
> need to be downloaded again for offline reading.

wanderlust (package: wl) ?
It is also slow but it has nice feature including 
mail caching and imap disconnect mode.

> Despite these problems, Gnus is the only program I have seen that will
> highlight replies to my mail, something I find very valuable in large
> mailing lists like this one.
> 
> Another alternative that looked good last time I tried was Mozilla, as
> it seems to have very good off-line mail support. However, it was
> buggy and often refused to enter mail groups for no good reason, so I
> gave up on that. Eventually I will have to try it again.

wanderlust suits your purpose.
I also had trouble to select imap offline cache program previously,
but wanderlust took me the answer.

-- gotom

Re: How many people need locales?

[Junichi Uekawa]

Ben Collins <[EMAIL PROTECTED]> immo vero scripsit

> This isn't a matter of not using it, it's a matter of a sane base
> install. Perhaps base-config could ask if the user wants locales. Know
> what? That question is being asked in english _anyway_. 

Having a few well-known questions asked in English is fine,
having a sequence of questions in English is scaring a lot of 
people away, at least in Japan.

You might be ignorant about this, but English language is not 
understood by everybody.


regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: new port: the never ending story

[Junichi Uekawa]

A Mennucc1 <[EMAIL PROTECTED]> immo vero scripsit

> arch=w32
> arch64=  w64
> pro: it has been proposed by many parts (and actually it was my 
>   second-nearly-first choice); no trademark problems
> con: I think it is not so appealing to the layuser; and 
>   I dont like the arch64 <-> arch relationship

Hmm... layuser ? 
It's just an arch. Use this.
It has been an "agreed-upon" string for emacs, AFAICR

The only problem this has, AFAIK, is that 
it reserves this word for cygwin, while some others may 
port Debian to mingw, for example.
But I shouldn't worry about that.

thanks.
junichi


-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: How many people need locales?

[Ben Collins]

On Wed, Sep 05, 2001 at 12:19:01PM +0900, Junichi Uekawa wrote:
> Ben Collins <[EMAIL PROTECTED]> immo vero scripsit
> 
> > This isn't a matter of not using it, it's a matter of a sane base
> > install. Perhaps base-config could ask if the user wants locales. Know
> > what? That question is being asked in english _anyway_. 
> 
> Having a few well-known questions asked in English is fine,
> having a sequence of questions in English is scaring a lot of 
> people away, at least in Japan.
> 
> You might be ignorant about this, but English language is not 
> understood by everybody.

Don't make assertions. I never said everyone understands it. The point
is, as it stands now, you have to go through the entire install in
english...not just a few questions..._all_ of them. That needs to be
fixed first.

-- 
 .--===-=-==-=---==-=-.
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: new proposal: Translating Debian packages' descriptions

[Junichi Uekawa]

Nick Phillips <[EMAIL PROTECTED]> immo vero scripsit

> >What is the size of all this? Ok. we have now in sid/main/i386 (see
> >[2]) 7000 Packages and the descriptions of all this packages is
> >2660993 bytes big. We get a description size per package of 384 bytes.
> >With gzip we will get (maybe) 130 bytes. 

> This is not directed at this comment in particular, but many many of the
> posts in these threads that I've been reading seem to be overly worried
> about size. Stop and think about it. If you're going to have translations,
> they will take up space, somewhere. That's just life.


Thinking about compression of data, rather than mixing different language text
in one package's control.tar.gz, it might be better to have them 
one-language each.

Compression mechanisms have better chance of compression on data
which have the same kind of text, and Japanese text compress better
when it is all Japanese text.

So, a control.tar.gz in each package has more chance of being bigger 
than having language.tar.gz for each language.

And, longer files have better compression ratios.


regards,
junichi
-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

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

[Wichert Akkerman]

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.

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 |

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

[Wichert Akkerman]

Previously Martin Michlmayr wrote:
> Since this should probably be by-package and not by-maintainer, how
> about a field in debian/control?

It has nothing to do with package metadata and does not belong there.

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 |

Re: Making better use of multiple maintainers

[David Starner]

On Wed, Sep 05, 2001 at 01:02:34AM +0200, Martin Michlmayr wrote:
> However, I'm not sure I agree that a backup is totally
> useless in the case of celestia.  What happens if you're on vacation,
> woody is released tomorrow and a RC bug is filed on celestia today and
> noone cares to upload a fixed package? 

If no one cares to spend a few minutes to upload a fixed package, who is
interested enough to become a maintainer (even backup) of the package?
If no one's interested enough to upload a fixed package, it's probably
not going to be a big deal if it doesn't get released with woody.

> Similarly, if you were really
> busy for a while, your backup could do uploads so the users don't have
> to wait for bug fixes too long.

It could be just as easy for someone to pick up a backup maintainer
at that point, though. One (partial) solution is to encourage developers
to offer to make a NMU rather than just let bugs set. 

-- 
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: isync vs mailsync

[Marcelo E. Magallon]

>> Brian May <[EMAIL PROTECTED]> writes:

 > Despite these problems, Gnus is the only program I have seen that will
 > highlight replies to my mail, something I find very valuable in large
 > mailing lists like this one.

 color index red black "~t [EMAIL PROTECTED] | ~x scrooge.chocbit.org.au"

 or something like that with mutt.  Patterns can be much more complex
 than what's shown here.  ~t should be clear.  ~x refers to the messages
 that contain the given string in the References field.

-- 
Marcelo | Item 14: Make sure base classes have virtual destructors
[EMAIL PROTECTED] | -- Scott Meyers, Effective C++

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

[Brian May]

> "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.
-- 
Brian May <[EMAIL PROTECTED]>

Re: isync vs mailsync

[Brian May]

> "Marcelo" == Marcelo E Magallon <[EMAIL PROTECTED]> writes:

>>> Brian May <[EMAIL PROTECTED]> writes:
>> Despite these problems, Gnus is the only program I have seen
>> that will highlight replies to my mail, something I find very
>> valuable in large mailing lists like this one.

Marcelo>  color index red black "~t [EMAIL PROTECTED] | ~x
Marcelo> scrooge.chocbit.org.au"

Marcelo>  or something like that with mutt.  Patterns can be much
Marcelo> more complex than what's shown here.  ~t should be clear.
Marcelo> ~x refers to the messages that contain the given string
Marcelo> in the References field.

Oh, Thanks for this.

Not quite as sophisticated as Gnus[1] but still quite sufficient for
my needs.

[1] Gnus will record the message id of every outgoing E-Mail. Not only
that, but it is capable of automatically saving the message id of each
reply too, so the message will still be highlighted even if your
message id falls off the reference id list.
-- 
Brian May <[EMAIL PROTECTED]>

Re: CUPS

[Michael Meskes]

On Tue, Sep 04, 2001 at 09:01:45PM +0300, Ari Makela wrote:
> Ok. I'm sorry. I misunderstood, I read that too quickly - my mistake,

No problem.

> of course. Because I was rude in public so I want to apologize in
> public, too. I'm sorry.

I did not think your mail was being rude. No need to apologize IMO.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: CUPS

[Michael Meskes]

On Tue, Sep 04, 2001 at 10:27:49AM +0200, Dominik Kubla wrote:
> Oh that will work fine with CUPS. But i am not convinced that you want
> this.  How to administer printers with System V commands is pretty much
> standard in the Unix world.  dpkg-reconfigure is not.

Okay, accepted. My main problem is that the package os not configured during
installation. And it could be it seems.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: CUPS

[Michael Meskes]

On Tue, Sep 04, 2001 at 11:10:28AM +0200, Christian Kurz wrote:
> Well, that's also a possible method for adding a printer. Do you get any
> error messages then on the console or in the logfiles beneath
> /var/log/cups? 

Nothing except the one I posted here.

> Hm, do you need the cupsomatic-ppd because there's no other ppd file in
> the cups package for your printer available?

More or less. I have a deskjet 670C. While there is a deskjet ppd in the
standard package it does not work really well. For instance it does not
print the whole page. The borders it defines are way too large. So I decided
to try the other ppds.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: CUPS

[Michael Meskes]

On Tue, Sep 04, 2001 at 12:04:10PM +0200, Tille, Andreas wrote:
> By the way:  That lpadmin does not work seems to be a bug but a feature -
> at least I had the same result as you. :-((
> The web frontend worked for me after some fiddling around (not after
> the plain install).

So this looks like a bug. Did it work for you with the default ppds?

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

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

[Tille, Andreas]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> OH, this is now the second 'remove me' request.
>
> Now the server can only mail notifications to all packages or to no
> packages. Should I stop it?
>
> Comments?
Example for a procmail rule in the information part?

Kind regards

 Andreas.

Re: Bug#111274: ITA: doc-linux-ja -- Linux HOWTOs in Japanese

[Martin Michlmayr]

retitle 110938 ITA: doc-linux-ja -- Linux HOWTOs in Japanese
merge 110938 111274
thanks

* GOTO Masanori <[EMAIL PROTECTED]> [20010905 10:17]:
> I intend to adopt doc-linux-ja, Japanese version of doc-linux.
> The reason to adopt is that Colin Watson is also written as follows:
> 
> Marco Budde is packaged in 1999.12, but we JF Project

I already orphaned it.  The same goes for:

 * #110937: O: doc-linux-sv -- Linux HOWTOs in Swedish
 * #110941: O: doc-linux-zh -- Linux HOWTOs in Chinese
 * #110948: O: doc-linux-de -- Linux HOWTOs in German

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: new port: the never ending story

[A Mennucc1]

hi

On Wed, Sep 05, 2001 at 12:42:02PM +0900, Junichi Uekawa wrote:
> A Mennucc1 <[EMAIL PROTECTED]> immo vero scripsit
 
 hey, I like this ^^
 Do you study latin?

> > arch=w32
> > arch64=  w64
> > pro: it has been proposed by many parts (and actually it was my 
> >   second-nearly-first choice); no trademark problems
> > con: I think it is not so appealing to the layuser; and 
> >   I dont like the arch64 <-> arch relationship
> 
> Hmm... layuser ? 
> It's just an arch. Use this.
> It has been an "agreed-upon" string for emacs, AFAICR

yes I was told

> The only problem this has, AFAIK, is that 
> it reserves this word for cygwin, while some others may 
> port Debian to mingw, for example.
> But I shouldn't worry about that.
> 

yes, who cares?

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

a.

-- 
A Mennucc
 "? un mondo difficile. Che vita intensa!" (Renato Carotone)

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

[Tille, Andreas]

On Wed, 5 Sep 2001, Martin Michlmayr wrote:

> Since this should probably be by-package and not by-maintainer, how
> about a field in debian/control? (I'm not sure it really belongs
> there, but there were some advantages if it were there; e.g. it can
> easily be controlled by the maintainer.)
If this will be implemented at any time it would make sense, if
there would be a possibility to adjust the languages.  For instance
I would like to see:

Receive-Translated-Descriptions: de ru
(German and Russian)

Others might wish

Receive-Translated-Descriptions: all -de
(all without German - perhaps because they do the German translation
 themselves and don´t need notification)

or something like that.

Kind regards

Andreas.

Re: How many people need locales?

[Tille, Andreas]

On Mon, 3 Sep 2001, Radovan Garabik wrote:

> I have yet to meet a person who would ever need a slovak locale.
> Nobody cares at all (collate order? who needs that? Different
> format of numbers? This is not only unneeded, but even harmful.
> Different format of date? Who cares.. Gettext? Maybe, but nobody
> I know is using it, because they mostly understand english and
> slovak menus are more difficult to get used to when 70% of applications
> would be in English anyway).
Quote from www.debian.org


What is Debian?

Debian is a free operating system (OS) for your computer.
   

I understand the "your" as intended to *any* person who wants a
operating system for his computer.  I´m really sure that there
are people equipped with computers on this Earth who did not
understand any English word.  So our Website has a bug and has
to be fixed by
   s/computer/& if you understand English language/

In my opinion this would be no good fix for this situation.

Kind regards

Andreas.

Re: Making better use of multiple maintainers

[Nick Phillips]

On Wed, Sep 05, 2001 at 01:02:34AM +0200, Martin Michlmayr wrote:

> useless in the case of celestia.  What happens if you're on vacation,
> woody is released tomorrow and a RC bug is filed on celestia today and
> noone cares to upload a fixed package?  Similarly, if you were really
> busy for a while, your backup could do uploads so the users don't have
> to wait for bug fixes too long.

I'd guess that it {could be|is} often the case that whilst only one
person knows the package well enough to take on major upgrades, development
etc., several know it well enough to be able to make bug fixes in the
manner that the maintainer would wish.
> 
> What I'm trying to say is that a backup makes sense in virtually all
> cases, even in the case of smaller packages.  Bigger packages certainly
> benefit to a higher degree, but I think it makes sense for smaller
> packages, too.

Absolutely.

-- 
Nick Phillips -- [EMAIL PROTECTED]
A long-forgotten loved one will appear soon.

Buy the negatives at any price.

Re: How many people need locales?

[Tille, Andreas]

On Mon, 3 Sep 2001, Santiago Vila wrote:

> I never asked for a debconf interface (I explained in the bug report
But why not following Grisus suggestion?

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]

(or just press n in case of the other default)
if he don´t want locales.  All others can choose from a list only once.
All other changes will be handled by debconf.  This is quite orthogonal
in my opinion.

Kind regards

 Andreas.

Re: How many people need locales?

[Michael Bramer]

On Wed, Sep 05, 2001 at 12:12:06AM -0400, Ben Collins wrote:
> On Wed, Sep 05, 2001 at 12:19:01PM +0900, Junichi Uekawa wrote:
> > Ben Collins <[EMAIL PROTECTED]> immo vero scripsit
> > 
> > > This isn't a matter of not using it, it's a matter of a sane base
> > > install. Perhaps base-config could ask if the user wants locales. Know
> > > what? That question is being asked in english _anyway_. 
> > 
> > Having a few well-known questions asked in English is fine,
> > having a sequence of questions in English is scaring a lot of 
> > people away, at least in Japan.
> > 
> > You might be ignorant about this, but English language is not 
> > understood by everybody.
> 
> Don't make assertions. I never said everyone understands it. The point
> is, as it stands now, you have to go through the entire install in
> english...not just a few questions..._all_ of them. That needs to be
> fixed first.

sorry Ben, but this is already fixed!

If you get a Debian in German with german BFs, you get _all_ in
german. After the install you have a LANG=de_DE. The first thing you
see in english is: 
 - exim (it don't use debconf... not easy to translate)
 - maybe some 'debconf' templates
 - the package descriptions

We have german, french, ... BFs since years. We have translated a lot
of debconf templates sine one year (in german we have >75%, see
http://auric.debian.org/~grisu/debian_translation/index-de.html)
and now we start with the package description. 

Some guides are also translated sine some time. 

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Demzufolge ist Windows wie Nutella: furchtbar suess und schlecht fuer 
 die Zaehne."  -- Norbert Kunka


pgpj4AUxede7L.pgp
Description: PGP signature

Re: 2.4 bootdisk for testing?

[Eduard Bloch]

#include 
Jørgen Hermanrud Fjeld  wrote on Tue Sep 04, 2001 um 09:44:24PM:

> Are there any plans to have kernel 2.4.x boot-disks for testing?
> If there are/aren't could someone point me to more information about this, 
> woes, obstacles, etc.

The current kernel scheme is attached. For i386, I created a special
variant with 2.4.7 a while ago. http://people.debian.org/~blade/bf-ext3/

Gruss/Regards,
Eduard.

# kver  = main kernel for bootdisks
ifeq "$(architecture)" "alpha"
kver:= 2.2.19
endif
ifeq "$(architecture)" "arm"
kver:= 2.2.19
endif
ifeq "$(architecture)" "i386"
kver:= 2.2.19
endif
ifeq "$(architecture)" "m68k"
kver:= 2.2.19
endif
ifeq "$(architecture)" "powerpc"
kver:= 2.2.19
pcmcia_kver := 2.2.19-pmac
apuskver:= 2.2.10
endif
ifeq "$(architecture)" "sparc"
kver:= 2.2.19
kver_sun4u  := 2.4.7
endif
ifeq "$(architecture)" "ia64"
kver:= 2.4.9
endif
ifeq "$(architecture)" "hppa"
kver:= 2.4.9
endif
ifeq "$(architecture)" "mips"
kver:= 2.4.5
endif
ifeq "$(architecture)" "mipsel"
kver:= 2.4.5
endif
ifeq "$(architecture)" "s390"
kver:= 2.4.5
endif
-- 
>> "Genieße dein Leben ständig, denn du bist länger tot als lebendig."

Re: Fonts working "out of the box"

[Jules Bean]

On Wed, Sep 05, 2001 at 11:45:38AM +1000, The Nose Who Knows wrote:
> 
> What would be the best way of approaching these people who may find that
> Free licenses are the best way to distribute their work?  If we find
> that fontographers are interested, we may gain a lot of good quality
> work quite rapidly.

Write them an email stressing the practical advantages, without boring
them too much with a free software diatribe.

For example, point out to these designers that if their fonts are DFSG 
free, they can be distributed with Debian (and Redhat and anything
else) which will make the useful to a huge group of people who might
not have heard about them otherwise.

By all means post a draft of the letter here for comments.

Jules

Re: CUPS

[Tille, Andreas]

On Wed, 5 Sep 2001, Michael Meskes wrote:

> On Tue, Sep 04, 2001 at 12:04:10PM +0200, Tille, Andreas wrote:
> > By the way:  That lpadmin does not work seems to be a bug but a feature -
> > at least I had the same result as you. :-((
> > The web frontend worked for me after some fiddling around (not after
> > the plain install).
>
> So this looks like a bug. Did it work for you with the default ppds?
Some ppds shipped with the package worked (LaserJet and DeskJet mainly)
but I had to use the web interface at first time.  After generating
the /etc/cups/printers.conf I copied-and-pasted the relevant entries
in this file and created more printers this way (and copied some
other ppds which were shiped with some more specialized printers).

I did not found a way to add local ppds with the web frontend and
lpadmin failed all the time :-(.

Kind regards

 Andreas.

ifupdown needs help?

[David N. Welton]

I see that there are a lot of old bugs in ifupdown, some of which
include patches.  Are you having trouble working on this package?
Could you use some help?

-- 
David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

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.

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

[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

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

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

[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: 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: 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: 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?)

[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

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

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

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

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

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

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

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

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

[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

[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

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

[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

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

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

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

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