Wherabouts of buildd logs

[Stephen Zander]

[Try this again, something's been eating my emails.]

I'm trying to track down why some of my packages have not made into
testing.  update_excuses shows one of them as out of date on hppa, but
doesn't give a buildd log showing why.  Do hppa buildd logs exist
online anywhere?

-- 
Stephen

Test: my posts are not getting to this list

[Stephen Zander]

Please ignore; just trying to see why my posts aren't getting through

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

[Wichert Akkerman]

Previously Michael Bramer wrote:
> I am right and the translated description don't need be store in the
> status file?

Yes and no. That is just a side-effect of a possible larger change.

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: A script to see how much a package is depended upon.

[Junichi Uekawa]

Marcus Brinkmann <[EMAIL PROTECTED]> immo vero scripsit

> > As I anticipated, it has a lot of "loops", and it is going in ridiculous
> > values. These things should have had trouble when porting to new arches,
> 
> Hell, they did!  It took ages to become somewhat self-contained Debian wise.
> One problem is that all features are enabled and as such become mandatory.
> 
> Removing loops is easy.  Just keep a list of all nodes visited, and don't
> follow any twice.

Yes, that's what I did.

Looking quickly at why I had this, I have a need to remove those things
which are related to documentation, to get a reasonable value.

Many number of package which depend on tetex/sgml-base/texinfo
to build documentation is depended upon (eventually) by 
tetex/sgml-base/texinfo.

Becayse many libs come with documentation in texinfo, etc.
This is probably the main reason people need to cross-compile,
because initially there is no native text-compilers, 
because there is no native library available, because 
there is not native ... whatever.


regards,
junichi

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

Re: dispersive translation via DDTS

[Tomohiro KUBOTA]

Hello,

At Thu, 6 Sep 2001 10:36:04 +0200,
Michael Bramer <[EMAIL PROTECTED]> wrote:

> The server need a translator per description, it need a email address.
> If a maintainer change a description, the server will send a update
> mail to the translator. For it the server need the email address.

I didn't think about this point.  You are right.

However, I think the "official translator" should be able to be
changed easily, though I don't have concrete idea now.

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: ideas about how to package something

[Sebastian Rittau]

On Wed, Sep 05, 2001 at 10:50:56PM -0400, Brandon L. Griffith wrote:

> Should I package each plugin seperately or make one large
> openverse-plugins.deb?

I would package them according to their size and external dependencies.
For example, I would package the plugin that requires dict separately,
but would package small plugins that have no external dependencies
together. Also, you could check, whether an external dependency is
really a dependency. If for example the dict plugin is very small, put
it in the main plugin package and make it popup a requester saying
"You need the dict package for this plugin." or something similar if
dict is not installed. That may even be a feature that's interesting
for upstream.

 - Sebastian

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

[John H. Robinson, IV]

On Thu, Sep 06, 2001 at 04:09:49PM +0200, Marc Haber wrote:
> On Wed, 5 Sep 2001 21:08:21 +0200, Eric Van Buggenhaut
> <[EMAIL PROTECTED]> wrote:
> >Do you want to go for another name then ? I find it quite confusing. mtail or
> >multitail might be clearer.
> 
> Changing the upstream name for this sake is a bad idea. Hey, xinetd
> doesn't need X as well.

nor does xargs.

-john

Re: sysctl should disable ECN by default

[Alex Pennace]

On Wed, Sep 05, 2001 at 02:37:06PM +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, such bastardization of TCP/IP, while already rampant, has no place
on the Internet.

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

[Nick Phillips]

On Thu, Sep 06, 2001 at 07:47:26PM +0200, Christian Kurz wrote:

> > > upstream packages because they are not part of a package? The
> > > translation of the error messages and other messages of a program belong
> > > to the package of it. 
> 
> > That depends on whether you're distributing one package or thousands.
> 
> Why do make this dependant on the number of packages? I think that using
> some count like you do, is a bad thing.

Because if you're only distributing one package or small group of packages
(say, KDE), then your focus is making the translations available for all the
people who use that package, whether or not the particular distribution
they got it from has infrastructure to support translations. Hence it makes
sense to put the translations in the package in that case.

If on the other hand you are one of those distributions, distributing
all sorts of packages, some of which have upstream translations, some of
which don't, some of whose maintainers are able and willing to spend time
on translations, some of whose maintainers aren't, then it doesn't make
sense to set yourselves up in such a way (translations always living in
packages) that translations will only be available when the maintainer
does work on them.

Think about it.

> > But if we want to be, and are, able to easily add extra translations, or
> > override poor-quality upstream translations (all without causing hassles for
> > maintainers), then why not?
> 
> Because for example I would prefer to be informed if any of my packages
> has a bad upstream translation and some has better one for me. Then I
> can forward and discuss it with the upstream and he can include it maybe
> in the official upstream sources. That way we wouldn't only improve the
> translation for people using debian, but also for people who are using
> some other free operating system and the upstream package.

Fine, no-one is saying that you shouldn't be able to arrange to be notified
when a particular package has a translation made available.

There is a difference between "not requiring a maintainer to be involved in
the provision of translations" and "not enabling a maintainer to be involved
in the provision of translations".


-- 
Nick Phillips -- [EMAIL PROTECTED]
Fine day to work off excess energy.  Steal something heavy.

Re: What is debian.net used for?

[Brandon L. Griffith]

* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> > BTW, trainspotters gather at stations and take notes on times for
> > departure and arrival as well as what kind of trains there are at what
> > routes.  Is far as I know that is, a have no first hand knowledge.  It
> > was just a subject very distinct from free software.
> 
> I can't see why such a site would reflect badly on Debian; however, as you
> said, it is very distinct from free software. Anyway, IMHO if your
> foo.debian.net pages are done in a "my homepages" style, with a main page
> that not only link to proper free software material but also to some
> personal pages (such as your trainspotting page), I don't see any problem
> in that.

Who not take a look at what other DDs have been using *.debian.net for and make
your mind up from there.

$ host -l debian.net gives about 85 names.

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


pgpsxtZYK5tT9.pgp
Description: PGP signature

Re: A script to see how much a package is depended upon.

[Marcus Brinkmann]

On Fri, Sep 07, 2001 at 12:11:28AM +0900, Junichi Uekawa wrote:
> As I anticipated, it has a lot of "loops", and it is going in ridiculous
> values. These things should have had trouble when porting to new arches,

Hell, they did!  It took ages to become somewhat self-contained Debian wise.
One problem is that all features are enabled and as such become mandatory.

Removing loops is easy.  Just keep a list of all nodes visited, and don't
follow any twice.

Thanks,
Marcus

ANother library problem: autobuilder for i386?

[Jules Bean]

I just had to recompile balsa to make it installable again, after
another of these volatile gnome libraries changed soname on me in sid.

It was just a simple recompile, no source changes except the
changelog. Of course, it's going to trigger recompiles on all the
other architectures.  And some of these may even be unnecessary, since 
the other architectures may have happened to do their recompiles
*after* the new libraries were installed.

Which made me think:

It would be really cunning if there was an i386 autobuilder to do that 
for me, so I didn't have to waste bandwidth (and a version bump) on a
version which isn't actually different.

In principle, at least, there could be something which checked whether 
a recent sid install had rendered any other packages uninstallable (as 
the install of libgtkhtml15, which purged libgtkhtml14, had rendered
balsa uninstallable). If so, it could attempt to auto-build it.  If
the auto-build didn't go through it could email the maintainer, file a 
bug, whatever.

More extremely, it could trigger a rebuild whenever a source
dependency increased its version (since the new version of the source
dependency is what any *user* would get trying to compile from
source).

Thoughts?

As an afternote: Yes, I know that my particular problem wouldn't
happen if the gnome library maintainers did the 'oldlibs' trick
keeping old libraries around.  But I think it's fairly well accepted
that that's not desirable at this stage of rapid development.

Jules

Re: ntp gone from unstable

[Colin Watson]

On Thu, Sep 06, 2001 at 10:11:33PM +0200, Mikael Hedin wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
> > apt sources, or tell us which arch you're using if it is not i386...
> 
> I use i386.  But
> [EMAIL PROTECTED]:~$ madison ntp
>ntp | 1:4.0.99g-2 |stable | source, alpha, arm, i386, m68k, 
> powerpc, sparc
>ntp | 1:4.0.99g-3 |   testing | source, alpha, arm, hppa, i386, 
> ia64, m68k, powerpc, sparc
> [EMAIL PROTECTED]:~$ 

$ lynx -dump http://ftp-master.debian.org/removals.txt | grep -3 ' ntp'
[Date: Mon,  3 Sep 2001 20:09:35 -0400] [ftpmaster: James Troup]
Removed the following packages from unstable:

   ntp |  1:4.1.0-1 | source, alpha, hppa, arm, i386, m68k, mips, mipsel, 
powerpc, sh, sparc, ia64
   ntp | 1:4.1.0-1.0.1 | s390
   ntp-doc |  1:4.1.0-1 | all
ntp-refclock |  1:4.1.0-1 | alpha, hppa, arm, i386, m68k, mips, mipsel, 
powerpc, sh, sparc, ia64
ntp-refclock | 1:4.1.0-1.0.1 | s390
ntp-simple |  1:4.1.0-1 | alpha, hppa, arm, i386, m68k, mips, mipsel, powerpc, 
sh, sparc, ia64
ntp-simple | 1:4.1.0-1.0.1 | s390
   ntpdate |  1:4.1.0-1 | alpha, hppa, arm, i386, m68k, mips, mipsel, powerpc, 
sh, sparc, ia64
   ntpdate | 1:4.1.0-1.0.1 | s390

--- Reason ---
moving to non-US

-- 
Colin Watson  [EMAIL PROTECTED]

Re: ntp gone from unstable

[Tollef Fog Heen]

* Mikael Hedin 

| Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
| 
| > Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
| > apt sources, or tell us which arch you're using if it is not i386...
| 
| I use i386.  But
| [EMAIL PROTECTED]:~$ madison ntp
|ntp | 1:4.0.99g-2 |stable | source, alpha, arm, i386, m68k, 
powerpc, sparc
|ntp | 1:4.0.99g-3 |   testing | source, alpha, arm, hppa, i386, 
ia64, m68k, powerpc, sparc

I believe you are looking for:

$ madison ntp-simple
ntp-simple |  1:4.1.0-2 |  unstable | i386, ia64, powerpc
$ 

-- 

Tollef Fog Heen
You Can't Win

Re: ntp gone from unstable

[Adam Heath]

On 6 Sep 2001, Mikael Hedin wrote:

> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>
> > Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
> > apt sources, or tell us which arch you're using if it is not i386...
>
> I use i386.  But
> [EMAIL PROTECTED]:~$ madison ntp
>ntp | 1:4.0.99g-2 |stable | source, alpha, arm, i386, m68k, 
> powerpc, sparc
>ntp | 1:4.0.99g-3 |   testing | source, alpha, arm, hppa, i386, 
> ia64, m68k, powerpc, sparc
> [EMAIL PROTECTED]:~$

It's on pandora now.

Re: ntp gone from unstable

[Henrique de Moraes Holschuh]

On Thu, 06 Sep 2001, Mikael Hedin wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
> > apt sources, or tell us which arch you're using if it is not i386...
> 
> I use i386.  But
> [EMAIL PROTECTED]:~$ madison ntp
>ntp | 1:4.0.99g-2 |stable | source, alpha, arm, i386, m68k, 
> powerpc, sparc
>ntp | 1:4.0.99g-3 |   testing | source, alpha, arm, hppa, i386, 
> ia64, m68k, powerpc, sparc

Weird. madison is beserk, then. It IS in unstable, I just run today's
upgrade and got 4.1.0-2 from unstable...

-- 
  "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: What is debian.net used for?

[Henrique de Moraes Holschuh]

On Thu, 06 Sep 2001, Mikael Hedin wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> > No. It has Debian's name in the URI, so it must not be used for anything
> > that would reflect badly on Debian...  Obviously, I do not mean your
> 
> Maybe it comes down to common sence?  But I'd prefer to know what more

Yes...

> BTW, trainspotters gather at stations and take notes on times for
> departure and arrival as well as what kind of trains there are at what
> routes.  Is far as I know that is, a have no first hand knowledge.  It
> was just a subject very distinct from free software.

I can't see why such a site would reflect badly on Debian; however, as you
said, it is very distinct from free software. Anyway, IMHO if your
foo.debian.net pages are done in a "my homepages" style, with a main page
that not only link to proper free software material but also to some
personal pages (such as your trainspotting page), I don't see any problem
in that.

-- 
  "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: What is debian.net used for?

[Mikael Hedin]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> No. It has Debian's name in the URI, so it must not be used for anything
> that would reflect badly on Debian...  Obviously, I do not mean your
> mother-in-law's homepage or your trainspotter (what is a trainspotter?)
> would refect badly on Debian, since I've never seen them ;)

Maybe it comes down to common sence?  But I'd prefer to know what more
people think.  Maybe I should go for a precedent and set up this
trainspotter site?

BTW, trainspotters gather at stations and take notes on times for
departure and arrival as well as what kind of trains there are at what
routes.  Is far as I know that is, a have no first hand knowledge.  It
was just a subject very distinct from free software.

> 
> And mixing warez and Debian will get you a one way express ticked out of the
> project, real fast. It's the one precedent we have for swiftly kicking
> someone out of the project :P

It'd better be.

/Micce

-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

Re: ntp gone from unstable

[Mikael Hedin]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
> apt sources, or tell us which arch you're using if it is not i386...

I use i386.  But
[EMAIL PROTECTED]:~$ madison ntp
   ntp | 1:4.0.99g-2 |stable | source, alpha, arm, i386, m68k, 
powerpc, sparc
   ntp | 1:4.0.99g-3 |   testing | source, alpha, arm, hppa, i386, 
ia64, m68k, powerpc, sparc
[EMAIL PROTECTED]:~$ 

-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

Re: What is debian.net used for?

[Henrique de Moraes Holschuh]

On Thu, 06 Sep 2001, Mikael Hedin wrote:
> Seriously, is it OK to use it for all kind of personal stuff?  Like my
> mother-in-laws homepage?  Or for my personal trainspotter-site?

No. It has Debian's name in the URI, so it must not be used for anything
that would reflect badly on Debian...  Obviously, I do not mean your
mother-in-law's homepage or your trainspotter (what is a trainspotter?)
would refect badly on Debian, since I've never seen them ;)

And mixing warez and Debian will get you a one way express ticked out of the
project, real fast. It's the one precedent we have for swiftly kicking
someone out of the project :P

-- 
  "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: What is debian.net used for?

[Wouter Verhelst]

On 6 Sep 2001, Mikael Hedin wrote:

> So noone would object if I put up a machine warez.debian.org and

That would be .net, not .org

> distributed my other project stuff;-)
> 
> Seriously, is it OK to use it for all kind of personal stuff?  Like my
> mother-in-laws homepage?  Or for my personal trainspotter-site?

That's how I understood things. I could be wrong.

-- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"

Re: ntp gone from unstable

[Henrique de Moraes Holschuh]

On Thu, 06 Sep 2001, Mikael Hedin wrote:
> Hi, i notice that ntp is available in stable and testing, but not in
> unstable.  Why?

Ntp 4.1.0 IS in unstable... at least for i386.  Check another mirror, your
apt sources, or tell us which arch you're using if it is not i386...

-- 
  "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: What is debian.net used for?

[Mikael Hedin]

So noone would object if I put up a machine warez.debian.org and
distributed my other project stuff;-)

Seriously, is it OK to use it for all kind of personal stuff?  Like my
mother-in-laws homepage?  Or for my personal trainspotter-site?

/Micce

-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

ntp gone from unstable

[Mikael Hedin]

Hi, i notice that ntp is available in stable and testing, but not in
unstable.  Why?

/Micce

-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

Re: A script to see how much a package is depended upon.

[Wouter Verhelst]

On Fri, 7 Sep 2001, Junichi Uekawa wrote:

> Wouter Verhelst <[EMAIL PROTECTED]> immo vero scripsit
> 
> > > 3.24463e+09 liburi-perl
> > 
> > You need to debug your script. We don't have this much packages in any of
> > our archives. Not even...
> > 
> > [...]
> > > 29169746 readline4
> > 
> > ... this much.
> > 
> 
> I think this signifies that packages depend on itself to build.
> 
> I can detect A->A relationship easily, but 
> A->B->C->A cannot easily be detected.

Sure you can. Create a linked list of all packages:

package->package->package->package->...

Then go through this linked list once, and create bi-directional pointers
(or references, depending on the language being used ;-) to all packages 
this particular package depends on. You'll then get some web of package 
dependencies, while being able to find loops in the process.

It'll probably need a *lot* of time to process, but that's something
else...

-- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"

Re: A script to see how much a package is depended upon.

[Junichi Uekawa]

Wouter Verhelst <[EMAIL PROTECTED]> immo vero scripsit

> > 3.24463e+09 liburi-perl
> 
> You need to debug your script. We don't have this much packages in any of
> our archives. Not even...
> 
> [...]
> > 29169746 readline4
> 
> ... this much.
> 

I think this signifies that packages depend on itself to build.

I can detect A->A relationship easily, but 
A->B->C->A cannot easily be detected.

regards,
junichi



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

Re: Reasons why package central approach to handling translations may be suboptimal

[Michael Bramer]

On Thu, Sep 06, 2001 at 03:31:49PM +0200, Richard Atterer wrote:
> On Thu, Sep 06, 2001 at 03:42:00PM +0900, Junichi Uekawa wrote:
> > I have been reading the DDTS thread, and seeing that it was
> > resolving into a "each package should maintain their translation". I
> > would like to present what I think may be problematic in that
> > approach :
> > 1. This results in filing random bugs in BTS in random manner. [snip]
> 
> I think there's an answer to this problem: When the maintainer updates
> the translations of his package, this should be fully automated.
> E.g. just one command
> 
>   update-translations --from-mbox 
> 
> which fishes out the DDTS messages (which are sent in a standard
> layout), or, for people lucky enough to be permanently online, an
> "update-translations --from-web" command in debian/rules which gets
> the translation updates directly from the DDTS server.
> 
> So far, *everything* related to a Debian package can be found in the
> corresponding source package. I don't think it's a good idea to change
> this.

full agree

> > 2. A package is re-uploaded with translation. There is a package 
> > uploaded with one-line changelog saying something like "Merged
> > spanish templates". It is a load to autobuilder/ftpmirror/etc. and
> > of course manual intervention to rebuild a package means that an
> > error occurs, and it does.
> > 
> > The main problem here is that translation start after the initial
> > upload of packageto Debian happens, which means there will be a "-2"
> > Debian package which will include the translation, and a "-1" Debian
> > package will have no translation.
> 
> Yes, that's one of the basic problems. IMHO with the proposed
> "override" mechanism via Descriptions-XX.po (or whichever form it is
> going to have), this is mostly solved - anyone getting the "-1"
> package from testing will already see the translation. People tracking
> unstable may or may not see them, depending on how often they update
> and on the speed of the translators.
> 
> Some people are concerned that their daily update from unstable will
> need too much bandwidth because of all those extra uploads. If the
> override mechanism works, I see no reason not to have a policy "don't
> re-upload if only the translation changed".

full agree

> > 3. No choice of "I want this locale and not others".
> 
> I assume in particular you mean "I prefer this _encoding_"? This is a
> point that hasn't been discussed at all so far.

see below

> Will there be one description .po file per language in the source
> package, or one for all translations? The alternatives here are:

In a .po file is only one languages. 

So we have n Description.po file (n = Number of supportet languages).
A User must only downloads the needed Descriptions files.

In the source we have control-de.po, control-fr.po, control-es.po, ...
maybe all in one subdir.

> - Supply descriptions in UTF-8, and recode them for the user's current
>   encoding on the user's machine. Nice and clean, but requires support
>   (possibly quite extensive changes) in dpkg/apt. NB, we _do_not_ need
>   full Unicode support in all of Debian for this, just in the tools
>   that deal directly with the description data.

no, don't re-invent the wheel. This all make gettext. We don't need
patch apt, dpkg, other toold this way. 

We must only use a old, nice and tested tool: gettext.

> - Supply descriptions in UTF-8 and recode them to a default encoding
>   that root can configure on each machine. Do the recoding immediately
>   after an "apt-get update" or "dpkg -i", so the UTF-8 version is
>   never stored on the machine. Might be the way to go for the moment,
>   even if it's not ideal. Most importantly, it is upwards-compatible
>   with the first solution above.

we don't need this all

> - Pick one default encoding per language and just assume the user uses
>   that encoding. Problematic: Should we ever want to change the
>   default encoding, there'll be lots of packages using the old
>   encoding, and we'd be stuck with it.

yes, we use one default encoding per languages in the ddtp. 
 
> I'm all for at least _supplying_ the translations in UTF-8, even if
> they're not stored on the user's machine like that for now. Note that
> this does not even mean that the translators need to produce
> translations in UTF-8 - the DDTS can recode their work into UTF-8.

In future the ddts will make this and send UTF-8 encoded po files. I
have get a request von Wichert to use UTF-8 only. We can latin-X etc
recode to UTF-8, so this all is no problem.


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
 Win0.98 supports real multitasking - it can boot and crash simultaneously.

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

[Christian Kurz]

On 01-09-06 Nick Phillips wrote:
> On Thu, Sep 06, 2001 at 01:08:25PM +0200, Christian Kurz wrote:
> > On 01-09-05 Nick Phillips wrote:
> > > The translation of any part of a package, be it the text of error 
> > > messages,

> > So, shall we now remove all .po files and other translation from
> > upstream packages because they are not part of a package? The
> > translation of the error messages and other messages of a program belong
> > to the package of it. 

> That depends on whether you're distributing one package or thousands.

Why do make this dependant on the number of packages? I think that using
some count like you do, is a bad thing.

> If upstream includes translations, then we don't have to worry about the
> maintainer managing inclusion of whichever languages people happen to write
> translations for.

> But if we want to be, and are, able to easily add extra translations, or
> override poor-quality upstream translations (all without causing hassles for
> maintainers), then why not?

Because for example I would prefer to be informed if any of my packages
has a bad upstream translation and some has better one for me. Then I
can forward and discuss it with the upstream and he can include it maybe
in the official upstream sources. That way we wouldn't only improve the
translation for people using debian, but also for people who are using
some other free operating system and the upstream package.

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


pgpobuT4Njd53.pgp
Description: PGP signature

Re: What is debian.net used for?

[Wouter Verhelst]

On 6 Sep 2001, Mikael Hedin wrote:

> Hi, 
> 
> on db.d.o there is instructions for setting a DNS A record for
> debian.net.  But I cannot find any explanation on what it is intended
> for.  Any pointer or explanation available?

As far as I understood things, it's intended for people to have their own
domain at home, for personal matters.

-- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"

Re: sysctl should disable ECN by default

[Neil Spring]

> RFC793 says 
> 
> Reserved:  6 bits
> 
> Reserved for future use.  Must be zero.
> 
> 
> The last statement is the cause of all confusions. s/Must/Should/ would
> have been better.

No; to be forward compatible, a TCP must set the bits
to zero.  2481 describes the operation of those bits and
augments 793, much like SACK augments it.  Some TCP's
have a bug where they set the bits in the SYN/ACK if
they received reserved bits in the SYN, which is why ECN
negotiation is asymmetric.

If you want to blame routers for not implementing
standards, try 791.

  The internet protocol is specifically limited in scope
  to provide the functions necessary to deliver a package
  of bits (an internet datagram) from a source to a
  destination over an interconnected system of networks.

-neil

Re: A script to see how much a package is depended upon.

[Wouter Verhelst]

On Fri, 7 Sep 2001, Junichi Uekawa wrote:

> 
> Hello,
> 
> 
> I was writing a script to see how much a package is depended upon,
> i. e. cumulatively culculating Reverse-Build-Deps, and
> Reverse-dependencies. However, I thought it might be useful to see
> what kind of packages have a "weight", i.e. needs fixing first for 
> packages to enter "testing".
> 
> As I anticipated, it has a lot of "loops", and it is going in ridiculous
> values. These things should have had trouble when porting to new arches,
> but anyway, I have put the script up on
> http://mikilab.doshisha.ac.jp/~dancer/analyse-sourcepackages
> 
> 
> It requires Packages.gz and Sources.gz on the current directory.
> 
> It needs tweaking (like removing all base/required/build-essential packages 
> from the 
> selection to reduce the number of loops), but anyway.
> The number on the left is the superficious "number of packages which depend
> on this package", hopefully. 
> 
> 
> 3.24463e+09 liburi-perl

You need to debug your script. We don't have this much packages in any of
our archives. Not even...

[...]
> 29169746 readline4

... this much.

-- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"

Re: Fonts working "out of the box"

[David Starner]

On Thu, Sep 06, 2001 at 12:14:26PM -0500, David Starner wrote:
> One worry I have, is that we don't really want Debian to have a
> large number of 'junk' fonts. 

Which may be a bit panicy on my part. The same thing could happen
with themes, yet we don't have a problem with an overwhelming
number themes.

-- 
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: Fonts working "out of the box"

[David Starner]

On Wed, Sep 05, 2001 at 10:17:48AM +0100, Jules Bean wrote:
> 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 them useful to a huge group of people who might
> not have heard about them otherwise.

Appropriate font licenses are the X11 license (or minor variants
thereon) and the Arphic license (found in the *arphic* packages or
linked from the GNU license list.

One worry I have, is that we don't really want Debian to have a
large number of 'junk' fonts. I'd prefer any fonts added to
Debian be of reasonably high quality, certainly cover ASCII,
and hopefully a larger codepage (CP1252 is a nice target for
Western European fonts, and Markus Kuhn offered a larger
Latin subset* that would be nice to hit.) I hesitate to argue
against all grunge fonts, but there's a lot of them out there,
they aren't heavy use fonts, and they're better left to the
font archives rather than debian.

*
$ uniset + -017e + 8859-2.TXT + 8859-3.TXT \
  + 8859-4.TXT + 8859-9.TXT + 8859-10.TXT + 8859-13.TXT \
  + 8859-14.TXT + 8859-15.TXT + 8859-16.TXT + CP1252.TXT clean c
{
  { 0x0020, 0x007E }, { 0x00A0, 0x017E }, { 0x0192, 0x0192 },
  { 0x0218, 0x021B }, { 0x02C6, 0x02C7 }, { 0x02D8, 0x02D9 },
  { 0x02DB, 0x02DD }, { 0x1E02, 0x1E03 }, { 0x1E0A, 0x1E0B },
  { 0x1E1E, 0x1E1F }, { 0x1E40, 0x1E41 }, { 0x1E56, 0x1E57 },
  { 0x1E60, 0x1E61 }, { 0x1E6A, 0x1E6B }, { 0x1E80, 0x1E85 },
  { 0x1EF2, 0x1EF3 }, { 0x2013, 0x2015 }, { 0x2018, 0x201A },
  { 0x201C, 0x201E }, { 0x2020, 0x2022 }, { 0x2026, 0x2026 },
  { 0x2030, 0x2030 }, { 0x2039, 0x203A }, { 0x20AC, 0x20AC },
  { 0x2122, 0x2122 }
};



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

ͨÓÃÍøÖ·(¿ì½ÝÍøÖ·¡¢ÍøÂçʵÃû)------ÍøÂçµØÖ·ÐÂÐÎÏó

[debian-devel]

尊敬的客户：
 
通用网址(快捷网址、网络实名)――网络地址新形象 

直接输入企业、产品、网站的名称，即可直达目标网站 无需记忆复杂的域名、网址，
无需 http://、www 、 .com、.net等前后缀，是继IP、域名之后，最先进、最快捷、
最方便的第三代互联网访问标准 。
允许个人注册，开放通用词汇注册并可自由转让，商机无限！


通用网址带来更多访客与商机

1、客户无需死记硬背复杂的域名/网址，凭着简单的记忆、在浏览器地址栏输入印象
中的名字，即可找到您。

2、不必注册所有的顶级域名，降低企业经营成本！ 严格的服务选择原则，保护公司
商标权和全球性、区域性识别！

3、当输入名不精确时，智能推测功能仍可帮客户找到您。

4、利用多样的词汇和特殊的符号增强品牌的可识别性！ 

5、可指向深层链接地址，便于网站深层次内容被直接访问！

更多介绍，敬请访问：
知识商务在线：www.21kbol.com
通用网址：http://www.21kbol.com/web-keywords.htm
现在注册：http://203.196.7.89/client/xuxk/realname_1.html   

注：本邮件为善意的商业邮件，如有打扰敬请删除!!
 

Bug#111462: ITP: prelude -- Prelude is a new innovative Network Intrusion Detection system designed to be very modular, evolutive, rock solid and fast.

[Igor Genibel]

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

* Package name: prelude
  Version : 0.4.2
  Upstream Author : Yoann Vandoorselaere <[EMAIL PROTECTED]>
* URL : http://prelude.sourceforge.net/
* License : (GPL)
  Description : Prelude is a new innovative Network Intrusion  Detection
  system designed to be very modular, evolutive, rock solid and fast.
  
 Prelude is a general-purpose hybrid intrusion detection system, written
 entirely from scratch, in C. Right now, it handles all  of  the  TCP/IP
 stack over Ethernet. Prelude is divided into several parts :

* Prelude, the  NIDS  sensor,  responssible  for  real  time  packet
  capture and analysis.

  * The signature engine, designed to be completly  generic  and
evolutive, it is currently able to read Snort  rulesets.  By
simply adding parser, it should permit to load rulesets from
any NIDS easily.

  * The protocol plugins, which can handle packet  at  a  higher
level than prelude do, ie: you  got  a  tcp  packet,  and  a
Protocol plugin detect  that  packet  data  contain  an  rpc
header, so it will decode the rpc header,  and  ask  to  the
associated Detection plugin to analyze the decoded header.

  * A set of detection plugins which job is to analyze the  data
they are interested in (they register the protocol they  are
interested in at initialisation time), and  will  eventually
emmit a security warning. Dection plugin should only be used
for complex intrusion detection that can't be done using the
signature engine.

* A report server, which sensors contacts  in  order  to  report  an
  intrusion, that generate user readable reports using plugins.

  * The reporting plugins, which job is to  decode  the  reports
issued by Detection plugin, and translate them  in  an  user
readable form (ex: syslog report, html report, etc).

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tass 2.4.9 #1 mer aoû 29 19:24:43 CEST 2001 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR

Re: mplayer / divx

[Zdenek Kabelac]

Niklas Hoglund wrote:
> 
> On Thu, Aug 30, 2001 at 12:22:35PM +0100, Andrew Suffield wrote:
> > On Wed, Aug 29, 2001 at 12:06:10AM -0700, Aaron Lehmann wrote:
> >
> > The only real challenge is the borderline processors...
> 
> Like my AMD K6-2.  Works well for most movies, but some are almost
> unwatchable because they skip so much (with -framedrop). I compiled mplayer
> locally, so I have some of the optimizations. I'd say the best alternative
> would be to make mplayer detect processor type at runtime and use the
> relevant routines, but lacking that one package for i383, one for MMX and
> one for 3dnow would be nice.

Which will be addressed by using libmmxnow - which will be hopefully
supported by mplayer team (developed in avifile  for this moment)
but with cooperation of mplayer team.

[EMAIL PROTECTED]

What is debian.net used for?

[Mikael Hedin]

Hi, 

on db.d.o there is instructions for setting a DNS A record for
debian.net.  But I cannot find any explanation on what it is intended
for.  Any pointer or explanation available?

/Micce

-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

A script to see how much a package is depended upon.

[Junichi Uekawa]

Hello,


I was writing a script to see how much a package is depended upon,
i. e. cumulatively culculating Reverse-Build-Deps, and
Reverse-dependencies. However, I thought it might be useful to see
what kind of packages have a "weight", i.e. needs fixing first for 
packages to enter "testing".

As I anticipated, it has a lot of "loops", and it is going in ridiculous
values. These things should have had trouble when porting to new arches,
but anyway, I have put the script up on
http://mikilab.doshisha.ac.jp/~dancer/analyse-sourcepackages


It requires Packages.gz and Sources.gz on the current directory.

It needs tweaking (like removing all base/required/build-essential packages 
from the 
selection to reduce the number of loops), but anyway.
The number on the left is the superficious "number of packages which depend
on this package", hopefully. 


3.24463e+09 liburi-perl
3.24463e+09 libnet-perl
3.24463e+09 libmime-base64-perl
3.24463e+09 libhtml-tagset-perl
3.24463e+09 libhtml-parser-perl
3.24462e+09 libsgmls-perl
3.24462e+09 libi18n-langtags-perl
3.24462e+09 debiandoc-sgml
2.34979e+09 sgml-base
2.34979e+09 sed
1425083059 zlib
1272054460 symlinks
1177662310 sgml-data
923320735 patch
893015369 dpkg
692266802 debianutils
617864726 fileutils
574628341 m4
486285077 flex
474784868 autoconf
296341728 autotools-dev
294774234 kernel-package
287772245 bzip2
232608922 gcc272
232608918 linux86
232321264 libtool
220897012 slang
147395314 e2fsprogs
147387953 util-linux
147387948 sysvinit
147387940 modutils
147100289 kernel-source-2.4.9
147013175 base-passwd
147013020 makedev
95298072 jade
90330961 libjpeg6b
77166180 pmake
73551186 byacc
73550152 ash
73550148 kernel-source-2.4.8
73550142 initrd-tools
73507062 gpm
73506654 aalib
73506497 devfsd
73506492 libggi
73378169 svgalib4libggi
68743694 libpng
65730152 sharutils
64991458 docbook-xml
63830131 automake
37208560 autoconf2.13
36775071 kernel-image-sparc-2.4
36775071 kernel-image-2.4.9-i386
36775071 kernel-image-2.4.8-i386
36689088 svgalib
36688940 svgalib-dummy
36688801 gs
36684502 tcl8.3
36682876 lynx
36681394 tcl8.0
36681213 tcl8.2
36681104 utah-glx
36679531 menu
36679469 mh
36679467 xfree86
32006927 tiff
30466075 opensp
29400691 docbook
29169746 readline4



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

Re: sysctl should disable ECN by default

[Guillaume Morin]

Dans un message du 06 Sep à 16:58, Eric Van Buggenhaut écrivait :
> RFC 793 reserve bits 'for future use'. These bits may not be
> touched by a router or a firewall.
> The buggy hardware we are talking about zeroes those bits.
> Thus they violate RFC793.

RFC793 says 

Reserved:  6 bits

Reserved for future use.  Must be zero.


The last statement is the cause of all confusions. s/Must/Should/ would
have been better.

-- 
Guillaume Morin <[EMAIL PROTECTED]>

If it doesn't work, force it.  If it breaks, it needed replacing anyway.

Re: funny idle time from time

[Russell Coker]

On Thu, 6 Sep 2001 08:42, Brian May wrote:
> and I don't think you can really say that this is a slow computer either:

400MHz CPU, 10/15G disks, by today's standards that is rather slow.  Compare 
it to an Athlon 1.2G with 46G drives...

> So I can only conclude that something is very odd with this computer, but I
> don't know what.

One issue is that IO isn't prioritised/scheduled unlike CPU use.  This means 
that a process that schedules a lot of IO (EG doing a find / when atime is 
enabled) can cause large amounts of disk IO to be queued which kills 
interactive performance.

Maybe some of the options under /proc/sys/vm will let you tune this...

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: sysctl should disable ECN by default

[Eric Van Buggenhaut]

On Thu, Sep 06, 2001 at 04:43:57PM +0200, Florian Weimer wrote:
> Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
> 
> > 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.
> 
> I was indeed wrong, but not because of RFC 793.  IIRC, there isn't
> such a required in this standard.

Yes there is.

RFC 793 reserve bits 'for future use'. These bits may not be
touched by a router or a firewall.
The buggy hardware we are talking about zeroes those bits.
Thus they violate RFC793.

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

[Florian Weimer]

Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:

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

I was indeed wrong, but not because of RFC 793.  IIRC, there isn't
such a required in this standard.  But RFC 1812 explicitly requires
routers not to check or otherwise deal with unused IP header fields,
and I think this might be extended by analogy to TCP.

OTOH, anyone is free to do anything with packets passing through his
systems.  Internet is not a right. ;-)

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

Re: ideas about how to package something

[Alberto Gonzalez Iniesta]

On Wed, Sep 05, 2001 at 10:50:56PM -0400, Brandon L. Griffith wrote:
> Should I package each plugin seperately or make one large
> openverse-plugins.deb? I can see pros and cons of each method, such as the
> "dict" plugin requiring the dict program which in turn has its dependencies
> and such. If I made one large deb then it would have alot of dependencies. But
> if I made several small ones then there would be no problem there, except that
> the entire deb for some of the smaller ones would be just a few kb in size.
> Could someone else out there give me their opinion on this?
> thanks

Hi,

As you already know, I'm quite new to Debian ;-) but here's my opinion 
from what I've learned/seen here. I'll try to group plugins by 
requirements (ie. all those needing "dict" in a openverse-dict-plugins).
That way you could have the simplest plugins in openverse-base-plugins
(or maybe a better name than 'base') and those requiring more
dependencies in separate packages.

Just my .02 Euro


-- 
Alberto Gonzalez Iniesta
[EMAIL PROTECTED]
 
Give Me Liberty or Give Me Death (Patrick Henry)

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

[Daniel Kobras]

On Wed, Sep 05, 2001 at 09:54:45AM +0200, Martin Michlmayr wrote:
> * 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:
(...) 
>  * #110948: O: doc-linux-de -- Linux HOWTOs in German

I'd be willing to step in for the Debian package, but the problem is Marco
also seems to be upstream for the German Linux HOWTOs. Does anyone if there's 
German Linux documentation that's still actively developped?

Regards,

Daniel.

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

[Marc Haber]

On Wed, 5 Sep 2001 21:08:21 +0200, Eric Van Buggenhaut
<[EMAIL PROTECTED]> wrote:
>Do you want to go for another name then ? I find it quite confusing. mtail or
>multitail might be clearer.

Changing the upstream name for this sake is a bad idea. Hey, xinetd
doesn't need X as well.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

FIXED: screwed up fonts after latest dist-upgrade

[Carl B. Constantine]

I found the problem I had with the xfonts-scalable package and xftcache
that I reported. I forgot, that I still had DRI code from sourcefource
running that wasn't updated to the latest XFree86 4.1 release, so their
libraries were interfering with normal operation. I disabled the DRI 
libraries and did the dist-upgrade again to fix the problems and all is 
well now. Guess I'll have to find time to grab the latest DRI code from
cvs.

l8r.

-- 

__   _   Carl B. Constantine
   / /  (_)__  __   __  [EMAIL PROTECTED]
  / /__/ / _ \/ // /\ \/ /  (2.4.4)   http://www.duckwing.ca 
 //_/_//_/\_ _/ /_/\_\  Stormix 2000
PGP key available on request


  Up the line - out the server- past the firewall - nothing but Net!!

Re: Reasons why package central approach to handling translations may be suboptimal

[Richard Atterer]

On Thu, Sep 06, 2001 at 03:42:00PM +0900, Junichi Uekawa wrote:
> I have been reading the DDTS thread, and seeing that it was
> resolving into a "each package should maintain their translation". I
> would like to present what I think may be problematic in that
> approach :
> 1. This results in filing random bugs in BTS in random manner. [snip]

I think there's an answer to this problem: When the maintainer updates
the translations of his package, this should be fully automated.
E.g. just one command

  update-translations --from-mbox 

which fishes out the DDTS messages (which are sent in a standard
layout), or, for people lucky enough to be permanently online, an
"update-translations --from-web" command in debian/rules which gets
the translation updates directly from the DDTS server.

So far, *everything* related to a Debian package can be found in the
corresponding source package. I don't think it's a good idea to change
this.

> 2. A package is re-uploaded with translation. There is a package 
> uploaded with one-line changelog saying something like "Merged
> spanish templates". It is a load to autobuilder/ftpmirror/etc. and
> of course manual intervention to rebuild a package means that an
> error occurs, and it does.
> 
> The main problem here is that translation start after the initial
> upload of packageto Debian happens, which means there will be a "-2"
> Debian package which will include the translation, and a "-1" Debian
> package will have no translation.

Yes, that's one of the basic problems. IMHO with the proposed
"override" mechanism via Descriptions-XX.po (or whichever form it is
going to have), this is mostly solved - anyone getting the "-1"
package from testing will already see the translation. People tracking
unstable may or may not see them, depending on how often they update
and on the speed of the translators.

Some people are concerned that their daily update from unstable will
need too much bandwidth because of all those extra uploads. If the
override mechanism works, I see no reason not to have a policy "don't
re-upload if only the translation changed".

> 3. No choice of "I want this locale and not others".

I assume in particular you mean "I prefer this _encoding_"? This is a
point that hasn't been discussed at all so far.

Will there be one description .po file per language in the source
package, or one for all translations? The alternatives here are:

- Supply descriptions in UTF-8, and recode them for the user's current
  encoding on the user's machine. Nice and clean, but requires support
  (possibly quite extensive changes) in dpkg/apt. NB, we _do_not_ need
  full Unicode support in all of Debian for this, just in the tools
  that deal directly with the description data.

- Supply descriptions in UTF-8 and recode them to a default encoding
  that root can configure on each machine. Do the recoding immediately
  after an "apt-get update" or "dpkg -i", so the UTF-8 version is
  never stored on the machine. Might be the way to go for the moment,
  even if it's not ideal. Most importantly, it is upwards-compatible
  with the first solution above.

- Pick one default encoding per language and just assume the user uses
  that encoding. Problematic: Should we ever want to change the
  default encoding, there'll be lots of packages using the old
  encoding, and we'd be stuck with it.

I'm all for at least _supplying_ the translations in UTF-8, even if
they're not stored on the user's machine like that for now. Note that
this does not even mean that the translators need to produce
translations in UTF-8 - the DDTS can recode their work into UTF-8.

Comments?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ ´` ¯


pgp16ClvZnD3o.pgp
Description: PGP signature

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

[Roderick Schertler]

On Wed, 5 Sep 2001 21:08:21 +0200, Eric Van Buggenhaut <[EMAIL PROTECTED]> said:
> 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.

I can see how there might be some confusion.  This program has been
around for a long time, however.  I believe it was first released, as
xtail, in 1989.

-- 
Roderick Schertler
[EMAIL PROTECTED]

Re: isync vs mailsync

[Roland Bauerschmidt]

Joey Hess wrote:
> >  - create message on client => gets ignored by isync.
> 
> It's supposed to have support for uploading local messages now, but I
> have never seen it work yet.

It actually works here! When I first tried isync (version 0.4) I was
dissatisfied because this wasn't working. I wrote Michael Elkins about
it, but never got a reply. With isync 0.5 it actually seems to work.

Roland

-- 
Roland Bauerschmidt

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

[Nick Phillips]

On Wed, Sep 05, 2001 at 10:18:04AM -0400, Vociferous Mole wrote:

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

And if the maintainer is in the "no time for translations" camp, then
nothing happens. There's no reason why we can't cater for all types of
maintainer.


-- 
Nick Phillips -- [EMAIL PROTECTED]
You will feel hungry again in another hour.

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

[Nick Phillips]

On Thu, Sep 06, 2001 at 01:08:25PM +0200, Christian Kurz wrote:
> On 01-09-05 Nick Phillips wrote:
> > The translation of any part of a package, be it the text of error messages,
> 
> So, shall we now remove all .po files and other translation from
> upstream packages because they are not part of a package? The
> translation of the error messages and other messages of a program belong
> to the package of it. 

That depends on whether you're distributing one package or thousands.
If upstream includes translations, then we don't have to worry about the
maintainer managing inclusion of whichever languages people happen to write
translations for.

But if we want to be, and are, able to easily add extra translations, or
override poor-quality upstream translations (all without causing hassles for
maintainers), then why not?


Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Everything will be just tickety-boo today.

Re: sysctl should disable ECN by default

[Henrique de Moraes Holschuh]

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

Yes. However, if one wants the possibility of turning ECN on, it defaults to
enabled. You know that, and so do I and everyone else (worth talking to) in
this thread. Don't push the issue around.

> can't help but think that if someone's first experience with Debian is
> that the network install fails silently because ECN is enabled and some
> router between him and the archive is broken then we have failed to meet
> our (implied?)commitment in the Social Contract. All the newbie is going
> to know is that it doesn't work. Boy, I'm glad we've made our political
> point.
[...]

Sight. I give up. I said it THREE times that we should warn users about the
issue, since Xu does not want to poke the kernel AND he wants the
possibility of turning ECN on in the kernel.

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

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

[Christian Kurz]

On 01-09-05 Nick Phillips wrote:
> The translation of any part of a package, be it the text of error messages,

So, shall we now remove all .po files and other translation from
upstream packages because they are not part of a package? The
translation of the error messages and other messages of a program belong
to the package of it. 

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


pgpNVcw3nJbiu.pgp
Description: PGP signature

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

[Marek Habersack]

** On Sep 06, Radovan Garabik scribbled:
[snip]
> > I noticed that it also fails to process fome TTF fonts (check out
> > http://curiosity.de/downloads/fonts/curefonts.zip - most of them get
> > ignored when generating fonts.dir)
> 
> they are not complete - ttmkfdir generates lines only for
> encodings the font contains all the chars of (obviously, 
> very few - if any - ucs fonts pass this test)
> Use -c option with such fonts.
OK, thanks. Will use just that :)
 
> 
> >  
> > > 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
> > Are you using the freetype backend?
> > 
> 
> freetype backend, xfs font server and xfs-ttf font server all
> seem to take the same long time.
> I tried xtt backend but I was not succesful in setting it up.
I must say that I don't have speed/stability problems on my Sid machine with
the Bitstream Cyberbit font (http://www.ccss.de/slovo/unifonts.htm) which is
also quite large (13MB). Nevertheless, fact is that the fixed font works the
best :)). I just wish I could make GNOME display the wide fonts correctly in
the GUI elements...

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

/* A completely unrelated fortune */
 They spell it "da Vinci" and pronounce it "da Vinchy".  Foreigners always
 spell better than they pronounce.   -- Mark Twain 
 
 
 
 

pgpLNea3LFHAR.pgp
Description: PGP signature

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

[Radovan Garabik]

On Thu, Sep 06, 2001 at 01:29:11PM +0200, Marek Habersack wrote:
> ** On Sep 05, Radovan Garabik scribbled:

> > 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 noticed that it also fails to process fome TTF fonts (check out
> http://curiosity.de/downloads/fonts/curefonts.zip - most of them get
> ignored when generating fonts.dir)

they are not complete - ttmkfdir generates lines only for
encodings the font contains all the chars of (obviously, 
very few - if any - ucs fonts pass this test)
Use -c option with such fonts.


>  
> > 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
> Are you using the freetype backend?
> 

freetype backend, xfs font server and xfs-ttf font server all
seem to take the same long time.
I tried xtt backend but I was not succesful in setting it up.


-- 
 ---
| 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: step by step HOWTO switch debian installation into utf-8

[Radovan Garabik]

On Wed, Sep 05, 2001 at 03:10:16PM -0300, Henrique de Moraes Holschuh wrote:
> 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,

No big change in this regard (maybe a tad faster, but not much).
However, there was one noticeable change (may be a bug in
konqueror though): with xfs-xtt, konqueror stretches pages vertically by a 
factor of something like 100 times ! So you have heading, then several
tens of blank pages, then first paragraph, then several blank
pages etc...

> setting deferglyphs=16 in both the X server and the font server might save
> you a lot of grief.

I have deferglyphs=all

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

ok, I removed references to freetype module from xfree86config and I
will see if it helps (but, path to font server was at the beginning, 
so I guess X was not getting to the 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: ddts: notification about pt_BR-translation of the hello-debhelper description

[Michael Bramer]

On Thu, Sep 06, 2001 at 08:43:10PM +1000, Hamish Moffatt wrote:
> On Wed, Sep 05, 2001 at 02:44:01PM +0200, Michael Bramer wrote:
> > See also the other mail: >50 changes in 10 days in main/sid
> 
> In a single package? Huh?

no.

The description of >50 deb-packages from the debian distribution
main/sid/binary-i386 (with >6000 Packages) had changed in the last 10
days.

> > 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)
> 
> Yes, such is life. I don't see these as being sufficient reason
> to invent a completely new system for dealing with this data.

No outdated translations is a very big problem. The system should
better show untranslated descriptions than outdated translation. 

Also the delay is a big problem. And if the the maintainer fast and
upload after a change in the translation, we kill all the autobuilder.

A translation is no 'data' like Dependes, Description, Package. 

A translation is only a translation, a other form of the data in a
other languages and a other encoding. And we don't need a completely
new system for translations! We have a old, very well tested system
and we propose to use this system: gettext.

Gettext make all the work and we don't need a new system in dpkg and
apt.

> >  - you must patch dpkg etc. in a wide way
> 
> This is not a good excuse. dpkg is a Debian-specific tool,
> and so it should be modified if there is good reason to do so.
> Don't work around it.

I agree with this.

If we need new features in dpkg, we should patch it. And yes, we have
propose a patch for dpkg.

But you should not break the dpkg with a big patch only for
translation. Make it smart. Use this -9/+30 patch and you have it.

> > 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.
> 
> I don't see why the distinction is necessary.

sorry, it is usefull. 

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Weiß vielleicht jemand warum ich meine Freundin ständig anrufen soll, seitdem 
sie ihr neues Handy mit Vibrationsalarm hat?  (Volker Flohr in daa'ooo)


pgpT2CQTG5mk0.pgp
Description: PGP signature

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

[Marek Habersack]

** On Sep 05, Radovan Garabik scribbled:
> 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 noticed that it also fails to process fome TTF fonts (check out
http://curiosity.de/downloads/fonts/curefonts.zip - most of them get
ignored when generating fonts.dir)
 
> 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
Are you using the freetype backend?

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

/* A completely unrelated fortune */
 Men will always be men -- no matter where they are.   -- Harry Mudd,
 "Mudd's Women", stardate 1329.8 
 
 
 
 

pgp2UohulSyp4.pgp
Description: PGP signature

Re: funny idle time from time

[Wouter Verhelst]

On Thu, 6 Sep 2001, Brian May wrote:

> Unfortunately, this system already has DMA enabled by default:

Then switch it off. Put

hdparm -d0 /dev/hdx

in some initscript, and it'll be off.

I've had to do something similar to be able to read my CD-ROM while
accessing the harddisk without read-errors. Unfortunately, not all
hardware is error-free...



-- 
wouter dot verhelst at advalvas dot be

"Human knowledge belongs to the world"
  -- from the movie "Antitrust"

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

[Radovan Garabik]

On Thu, Sep 06, 2001 at 11:02:17AM +1000, Brian May wrote:
> > "Radovan" == Radovan Garabik <[EMAIL PROTECTED]> writes:
> 
> Radovan> it is LANGUAGE, and you have to set LANG to something
> Radovan> (which will be ignored in this case, but has to be set).
> 
> Not only does it have to be set, but it looks like it can't be set to "C":
> 

And it probably should be set to a valid locale (except C and POSIX, that is)
When set to invalid locale, mc shows menus in English, but Hints in LANGUAGE.


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

[Hamish Moffatt]

On Wed, Sep 05, 2001 at 02:44:01PM +0200, Michael Bramer wrote:
> See also the other mail: >50 changes in 10 days in main/sid

In a single package? Huh?

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

Yes, such is life. I don't see these as being sufficient reason
to invent a completely new system for dealing with this data.

>  - you must patch dpkg etc. in a wide way

This is not a good excuse. dpkg is a Debian-specific tool,
and so it should be modified if there is good reason to do so.
Don't work around it.

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

I don't see why the distinction is necessary.


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

Re: sysctl should disable ECN by default

[tpo2]

Well all of this has been said on this thread here allready, but
I'll repeat it never the less to get the facts straight.

Zitiere Dominik Kubla <[EMAIL PROTECTED]>:

> On Wed, Sep 05, 2001 at 05:30:12PM +0200, T.Pospisek's MailLists wrote:

> But the whole discussion here is folly. The whole thing has been
> discussed
on linux-kernel by people far more knowlegable in this things
> than the
average debian developer.  I think we should follow the
> conclusions
from that discussions: enable ECN by default and every
> non-compliant
device be dammned.

However you, or whoever on the kernel lists might argue, the default in
Linus' kernel sources is off! Please check it yourself.

> Mind you that we are only talking about firewalls here (and all of the
> can be fixed by firmware upgrades, or at least they should).

Fact is some aren't.

> Ordinary
routers have no business altering packets passing through and
> ordinary
hosts have to ignore "reserved bits" they don't know about.
> Routers
doing NAT are to be treated as firewalls.  If they are broken:
> replace
them.  They will have more bugs that this one anyway.

You are wellcome to be without a fault. Unfortunately a lot of HW/SW isn't.
And often enough it's not up to the user to replace it. He just has to live 
with it.

I think Craig Sanders and Anthony Towns said it best:

Craig:

> the fact is that there is no possibility of harm if ECN is disabled
> in the kernel, while there IS possibility of harm if it is enabled.
> therefore it should be disabled by default.

Anthony:

> I'm not sure what you mean by "idealism" but surely it's obvious the
> solution that's closest to ideal for the most users should be chosen as
> the default.

*t

Re: sysctl should disable ECN by default

[David Schleef]

On Thu, Sep 06, 2001 at 09:47:05AM +0200, Dominik Kubla wrote:
> 
> But the whole discussion here is folly. The whole thing has been discussed
> on linux-kernel by people far more knowlegable in this things than the
> average debian developer.  I think we should follow the conclusions
> from that discussions: enable ECN by default and every non-compliant
> device be dammned.


Assuming that defconfig reflects lkml discussions, it looks like
the answer depends on the architecture. =)  But it appears that
Linus thinks it should be disabled by default.

  uhv:~/linux/linux-2.4.9-rthal5$ grep INET_ECN arch/*/defconfig
  arch/alpha/defconfig:CONFIG_INET_ECN=y
  arch/arm/defconfig:# CONFIG_INET_ECN is not set
  arch/cris/defconfig:# CONFIG_INET_ECN is not set
  arch/i386/defconfig:# CONFIG_INET_ECN is not set
  arch/mips/defconfig:# CONFIG_INET_ECN is not set
  arch/mips64/defconfig:# CONFIG_INET_ECN is not set
  arch/parisc/defconfig:# CONFIG_INET_ECN is not set
  arch/ppc/defconfig:# CONFIG_INET_ECN is not set
  arch/s390/defconfig:# CONFIG_INET_ECN is not set
  arch/s390x/defconfig:# CONFIG_INET_ECN is not set
  arch/sparc/defconfig:# CONFIG_INET_ECN is not set
  arch/sparc64/defconfig:CONFIG_INET_ECN=y
  uhv:~/linux/linux-2.4.9-rthal5$



dave...

Re: funny idle time from time

[Martijn van Oosterhout]

On Thu, Sep 06, 2001 at 04:42:14PM +1000, Brian May wrote:
> /dev/hda:
>  unmaskirq=  0 (off)

> /dev/hdb:
>  unmaskirq=  0 (off)

Turn those on and see if it helps...

-- 
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: dispersive translation via DDTS

[Michael Bramer]

On Thu, Sep 06, 2001 at 04:12:12PM +0900, Tomohiro KUBOTA wrote:
> According to the FAQ, a person (A) who translated a package into
> a language will has a priviledge on the translation of the package.
> I.e., if someone (B) wants to modify the translation, B needs A's
> help for his/her translation to be finally adopted.  A problem of
> this policy is that if A has gone the project, nobody will be able
> to modify the translation.  Another problem is that leading translator
> will continue to load the responsibility of the pakcage translation.
> Fear of this continuing and growing responsibility can hesitate
> translators to translate as many packages as possible.

Yes, I make the first translator like a owner of the translation. 

And since 2(?) weeks, only the first translator can upload a new
translation. If a other translator send a changed translation to the
server, it will send a mail to the first translator with the old and
new translation and a diff. 

This is the first step of the BTS in the ddts. Now we have only the
notification mail. 

In future the server will make this: 
 - the translator must resende the package (maybe unchanges) or close
   the bug
 - If the translator don't send the bug back to the system in 4 weeks,
   he will remove as translator of this package and the bug submitter
   get a 'you can take over this package' mail
 - If the submitter don't take over the package, the server will put
   the description back in the pool again.

Also can every coordinator change a translation on request. 

> I rather like a more dispersive equality model like CVS.  In CVS,
> every committer have equal right to commit their modifications.
> We will think about committing priviledge control (account issuing)
> to avoid attack to DDTS.  I think the account issuing job should be
> done by language cordinators.

what is your opinion? Solve the above solution the problem?

The server need a translator per description, it need a email address.
If a maintainer change a description, the server will send a update
mail to the translator. For it the server need the email address.

> I only read the FAQ of DDTS.  I have never experiened this situation.
> Sorry if I misunderstand the FAQ.

one thing to the ddts:
  The ddts is only at the beginning and I change daily the code. We
  have now only 60% of the ddts running. I have a long TODO list and
  some ideas for the future.

  If you have problems or improvements, please write a mail. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Linux zu benutzen adelt nicht! Es bildet.


pgp47KEAFvFzO.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Craig Sanders]

On Thu, Sep 06, 2001 at 01:37:02AM -0500, Scott Dier wrote:
> * Craig Sanders <[EMAIL PROTECTED]> [010905 20:17]:
> > the correct solution is to NOT compile ECN support into the distribution
> > kernels. that's a choice that should be left up to the individual system
> 
> So, lets fix one problem by creating another problem!  ECN isn't there
> anymore!

no, that isn't a problem. the kernel works just fine without ECN being
enabled.

if you want it, you do what every other user of the linux kernel has to do
and compile a new kernel with support for it.

quite frankly, if someone doesn't know how to compile a kernel then
they're not qualified to decide whether they want to use it or not. in
that case, the correct course of action for a package maintainer is to
cause the least harm.

the fact is that there is no possibility of harm if ECN is disabled
in the kernel, while there IS possibility of harm if it is enabled.
therefore it should be disabled by default. 

anyone who is running servers busy enough that they actually need ECN
should have enough of a clue to know how to compile a kernel and enable
it.

> What if some users were actually using that?

see above.

since it's only been enabled in recent kernel-image packages, very few
(if any) people will be be surprised by it being removed again.


> ECN IS NOT A USELESS RFC. ECN IS NOT A USELESS RFC.

of course it's not.  it will eventually be universal.


> some people actually like to use this stuff.

yes, i know.  i use it.

however, it's an experimental feature which isn't needed on the debian 
distributed kernel images.

it might be appropriate to have it on by default in a year or so. but
not now.

craig

ps: why is it that so many people get so upset if their pet
feature-of-the-month isn't the default in debian? debian's defaults
should conform to the principles of Least Suprise and Least Harm, not
the principle of Maximal GeeWhizzery.

it's only a default, get over it.

-- 
craig sanders <[EMAIL PROTECTED]>

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

Re: reopening ECN bugreport/netbase

[tpo2]

Thanks for caring Anthony!

Zitiere Anthony Towns :

> I'm not sure what you mean by "idealism" but surely it's obvious the
> solution that's closest to ideal for the most users should be chosen as
> the default. We've currently had what options?
> 
>  1) Disable ECN in the kernel, and let people who want it recompile
> the kernel by hand. Pros: doesn't hurt anyone, follows the upstream
> kernel defaults.  Cons: makes it hard for people to enable, which
> in the long term damages the Internet's resiliance to DoS attacks.
> 
>  2) Leave ECN in the kernel, but disable it externally by default.
> Pros:
doesn't hurt anyone, makes it easy to change. Cons: requires
> kludging
around in other packages (boot-floppies and procps/netbase)

Cons for procps: solving it here is a techincally bad choice, since
it would require procps to decide to assign the flag based on available kernel 
options. Which is doable for this specific problem but is not a
general solution for similar problems.

Pros netbase: The message "ECN disabled: use /etc/network/options to enable"
keeps reminding the user which rises the probability that s/he will enable it 
later and so serve the purpose of ECN in the first place.

>  3) Leave ECN in the kernel, enabled by default. Pros: easy to setup,
> easy
to change after the fact. Cons: neophytes can easily be confused
> when
random sites start not working unpredictably from Debian machines
> but work fine elsewhere.

Cons: if upstream doesn't accept the changed default and include it, there
forever be a fork between Debian an the main kernel. Changing the default
upstream will cause a lot of trouble there which makes it not very probable.
IMO this would be the cleanest solution though.

> Another option, which would require a minor patch to the kernel, would
> be
to have ECN default to disabled even when compiled into the kernel (and
> thus require an explit 'echo 1 >/proc/sys/net/ipv4/tcp_ecn' to enable).
> This'd be analagous to the current behaviour with IP forwarding.
> 
> There might be other options too.

Both 1) and 3) would require action from the kernel-image maintainer, which
requires someone else than me talking to him since he's either not seeing
ECN as his problem at all:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=8

or just ignoring my reports:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=14

*t

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

> Another option, which would require a minor patch to the kernel, would be
> to have ECN default to disabled even when compiled into the kernel (and
> thus require an explit 'echo 1 >/proc/sys/net/ipv4/tcp_ecn' to enable).
> This'd be analagous to the current behaviour with IP forwarding.
 
Eduard Bloch suggested this on 9/2, though it took me a
while to understand what he meant:

  Good. The problem - it is on by default in our precompiled kernel-image  
  packages. To disable (by default), you have to remove ECN support from
  kernel or either patch the kernel to make int off-as-default (*) or put
  in in the template of sysctl.conf.  

  (*) I doubt Herbert Xu would like such modifications.  

And Herbert replied on 9/3:

  2. The kernel will not be patched to disable it by default with INET_ECN
  compiled in as the same thing can be easily achieved from user space.

It could be a nice solution that would satisfy my insane
desire that enabling ECN should be a one-step process -
either in kernel configuration or by manually editing
sysctl.conf.

-neil

dispersive translation via DDTS

[Tomohiro KUBOTA]

Hi,

I am now working on Debian Description Translation Project.
I have a request on the behavior of DDT Server.

According to the FAQ, a person (A) who translated a package into
a language will has a priviledge on the translation of the package.
I.e., if someone (B) wants to modify the translation, B needs A's
help for his/her translation to be finally adopted.  A problem of
this policy is that if A has gone the project, nobody will be able
to modify the translation.  Another problem is that leading translator
will continue to load the responsibility of the pakcage translation.
Fear of this continuing and growing responsibility can hesitate
translators to translate as many packages as possible.

I rather like a more dispersive equality model like CVS.  In CVS,
every committer have equal right to commit their modifications.
We will think about committing priviledge control (account issuing)
to avoid attack to DDTS.  I think the account issuing job should be
done by language cordinators.

I only read the FAQ of DDTS.  I have never experiened this situation.
Sorry if I misunderstand the FAQ.

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

Re: reopening ECN bugreport/netbase

[David Starner]

On Thu, Sep 06, 2001 at 01:37:02AM -0500, Scott Dier wrote:
> So, lets fix one problem by creating another problem!  ECN isn't there
> anymore!

So? Neither is a lot of options. You can recompile a kernel just
as well as anyone else.
 
-- 
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: funny idle time from time

[Brian May]

On Wed, Sep 05, 2001 at 04:13:00PM -0400, Norbert Veber wrote:
> On Sat, Sep 01, 2001 at 12:12:46PM +1000, Craig Sanders wrote:
> > On Sat, Sep 01, 2001 at 11:35:05AM +1000, Brian May wrote:
> > > Also, if a computer is running slowly, but top says the CPU has plenty
> > > of idle time and free RAM, is there anyway I can find out what is
> > > wrong?
> > 
> > most likely slow disks.
> 
> Your system is supposed to multitask regardless if your disks are slow or
> not.  Unfortunatelly the default settings are quite conservative and give
> very bad performance via older disks.
> 
> Try reading man hdparm.  The most useful setting is enabling DMA (which
> needs additional kernel support for your chipset), there is also the unmask
> irq setting which lets your machine (somehow) process other interrupts while
> waiting for disk IO, and the 32-bit access.
> 
> This however can lead to data corruption on crappy hardware, so test
> thoughtly before making the change long-term..

Thanks for the tip. It sounds exactly like my problem: system runs extremely 
slowly 
while find runs in the background. This was when find was searching 
/usr/src/kernel-source-2.2.8,
which is not NFS 

Unfortunately, this system already has DMA enabled by default:

/dev/hda:
 multcount= 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 1247/255/63, sectors = 20044080, start = 0
pluto:~# hdparm /dev/hdb

/dev/hdb:
 multcount= 16 (on)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 1871/255/63, sectors = 30064608, start = 0

top says:

 16:38:03 up 13 min,  1 user,  load average: 1.71, 1.40, 0.70
91 processes: 88 sleeping, 2 running, 1 zombie, 0 stopped
CPU states:   7.8% user,  34.0% system,   2.9% nice,  55.3% idle
Mem:126564K total,   123764K used, 2800K free,38828K buffers
Swap:   497972K total,59796K used,   438176K free,11732K cached

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 2170 root  19  10   224  132   132 R N  10.0  0.1   0:04 find
 2193 root  17   0   920  912   700 R 6.7  0.7   0:00 top
  632 jan   15   0 17460  11M 11168 S 5.8  9.0   0:10 mozilla-bin

and I don't think you can really say that this is a slow computer either:

pluto:/proc/2170# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 5
cpu MHz : 434.327
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr
bogomips: 865.07

Bootup harddisk information:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev f9
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:DMA
hda: WDC WD102AA, ATA DISK drive
hdb: WDC WD153AA, ATA DISK drive
hdd: MATSHITADVD-ROM SR-8583A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 20044080 sectors (10263 MB) w/2048KiB Cache, CHS=1247/255/63, UDMA(66)
hdb: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 >
 /dev/ide/host0/bus0/target1/lun0: p1 p2 < p5 p6 p7 >
8139too Fast Ethernet driver 0.9.18

So I can only conclude that something is very odd with this computer, but I 
don't know
what.
-- 
Brian May <[EMAIL PROTECTED]>

Reasons why package central approach to handling translations may be suboptimal

[Junichi Uekawa]

Hello, 

I have been reading the DDTS thread, and seeing that it was resolving into
a "each package should maintain their translation". I would like to
present what I  think may be problematic in that approach :

1. This results in filing random bugs in BTS in random manner. Telling the
submitter to re-submit in a more useful format, and not gettinga response
is bad. Many of the debconf translation "bugs" have translated text
inserted in the mail body. It should really be an attachment if it were to
be handled sanely, to preserve the intended encoding. (for example,
Japanese mail is in ISO-2022-JP, while debconf data should be in euc-jp).
BTS doesn't seem to like attachments either.

2. A package is re-uploaded with translation. There is a package 
uploaded with one-line changelog saying something like
"Merged spanish templates". It is a load to
autobuilder/ftpmirror/etc. and of course manual intervention 
to rebuild a package means that an error occurs, and it does.

The main problem here is that translation start after the initial 
upload of packageto Debian happens, which means there will be
a "-2" Debian package which will include the translation, and 
a "-1" Debian package will have no translation.


3. No choice of "I want this locale and not others".




This is the reason I think the translation data would be 
better off maintained outside of usual packages.


regards,
junichi

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

Re: mac parts?

[Scott Dier]

* Rick Younie <[EMAIL PROTECTED]> [010905 20:03]:
> that still needs a few gig narrow SCSI disk and matched sets of
> 30-pin ram.  If someone can loan some parts to the cause it will

As sick as it is, I might have 4 4mb 30pin ram laying around somewhere,
would this help?

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

Re: reopening ECN bugreport/netbase

[Scott Dier]

* Craig Sanders <[EMAIL PROTECTED]> [010905 20:17]:
> the correct solution is to NOT compile ECN support into the distribution
> kernels. that's a choice that should be left up to the individual system

So, lets fix one problem by creating another problem!  ECN isn't there
anymore!

What if some users were actually using that?

ECN IS NOT A USELESS RFC. ECN IS NOT A USELESS RFC.

some people actually like to use this stuff.

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

Re: sysctl should disable ECN by default

[Scott Dier]

* Jaldhar H. Vyas <[EMAIL PROTECTED]> [010905 20:01]:
> whether they can deal with that or not.  Debians sole responsibility is to
> see it is properly documented somewhere.  If people don't read the

*Please* dont document this in debconf.  Do it in a README.Debian or the
release notes.

I *really dont* want to see 'important' information in debconf and not a
README.Debian file.
-- 
Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://www.ringworld.org/  [EMAIL PROTECTED]

Re: reopening ECN bugreport/netbase

[Anthony Towns]

On Wed, Sep 05, 2001 at 06:30:27PM -0700, Neil T. Spring wrote:
> My point is: the maintainers have spoken.  If we're going
> to make progress in helping users behind broken equipment,
> we're going to have to find another way that doesn't offend
> Herbert, Craig, and Anthony's sense of idealism.

I'm not sure what you mean by "idealism" but surely it's obvious the
solution that's closest to ideal for the most users should be chosen as
the default. We've currently had what options?

 1) Disable ECN in the kernel, and let people who want it recompile
the kernel by hand. Pros: doesn't hurt anyone, follows the upstream
kernel defaults.  Cons: makes it hard for people to enable, which
in the long term damages the Internet's resiliance to DoS attacks.

 2) Leave ECN in the kernel, but disable it externally by default. Pros:
doesn't hurt anyone, makes it easy to change. Cons: requires kludging
around in other packages (boot-floppies and procps/netbase)

 3) Leave ECN in the kernel, enabled by default. Pros: easy to setup, easy
to change after the fact. Cons: neophytes can easily be confused when
random sites start not working unpredictably from Debian machines
but work fine elsewhere.

Another option, which would require a minor patch to the kernel, would be
to have ECN default to disabled even when compiled into the kernel (and
thus require an explit 'echo 1 >/proc/sys/net/ipv4/tcp_ecn' to enable).
This'd be analagous to the current behaviour with IP forwarding.

There might be other options too.

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)


pgpqN9PKX5BBJ.pgp
Description: PGP signature

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

[Michael Bramer]

On Wed, Sep 05, 2001 at 10:42:12PM -0500, David Starner wrote:
> On Thu, Sep 06, 2001 at 01:08:52AM +0200, [EMAIL PROTECTED] wrote:
> > On Wed, 5 Sep 2001, Branden Robinson wrote:
> > 
> > > On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
> > > >The maintainer need not do anything. Maybe he don't know the
> > > >translation. The user only use this. This need only the
> > > >translators.
> > > 
> > > While we're on the subject, can you get someone to translate your mails
> > > into a comprehensible dialect of English?
> > 
> > Branden, please don't be rude.
> 
> True, Branden was rude. But the fact that grisu's emails are sometimes hard 
> to understand has been a stumbling block for me; it would certainly help to
> get a translator/editor for the full blown proposals.

sorry, about this problem.

Maybe someone can help and translate the proposal.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
 --==   Free Software: Contribute nothing, expect nothing ==--


pgpiIjO3UkQvb.pgp
Description: PGP signature

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

[Michael Bramer]

On Wed, Sep 05, 2001 at 03:56:38PM -0500, Adam Heath wrote:
> On Wed, 5 Sep 2001, Wichert Akkerman wrote:
> 
> > Previously Nick Phillips wrote:
> > > Well, shouldn't it? Wouldn't it make sense to have the translated 
> > > description
> > > in there rather than the original one?
> >
> > I actually makes more sense to remove even the english description
> > from status to another location.
> 
> Note, that there is no reason dpkg could not be modified to read from multiple
> status files.

what? 

sorry, but in a other mail you say:
> 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.

I am right and the translated description don't need be store in the
status file?


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Wie haben andere Linux Benutzer ihr `erstes Mal' mit Linux erlebt??"
"Wir haben danach gemeinsam eine Gitanes geraucht und nochmal ueber alles 
 geredet." -- P.Vollmann und Stefanie Teufel in dcolm


pgplyEQLoJbS1.pgp
Description: PGP signature