Re: Dropping/splitting (proper) i386 support

[Jakob Bohm]

On Tue, May 06, 2003 at 03:05:21PM +0200, Guillem Jover wrote:
> Hi,
> 
> On Mon, May 05, 2003 at 06:27:05PM -0400, Nathanael Nerode wrote:
> > After the 486, Intel always provided a method to determine the CPU type and 
> > features available.  As far as I can tell, there's no easy programmatic way 
> > to tell the difference between a (old, no CPUID) 486 and an (old, no CPUID) 
> > 386 without risking an illegal instruction, which bites. :-(  (I could be 
> > wrong.)
> 
> They exist and are not so difficult. One is by issuing illegal
> instructions like you have commented, the only thing to do is to trap
> INT 6 (Invalid Opcode). The only problem you may find is that really old
> cpus don't support this INT (only 80186+).
> 
> The other is a little bit more fun, you have to test for cpu specific
> non-documented behaviour, like how many bits shift a shl in a 8088 or
> 80186+, when does the cpu increment the sp (stack pointer) when doing
> a push/pop, which flags can or cannot be set, etc. I did some years ago
> asm code that distinguished from 8088 to the new CPUID aware cpus,
> including the distinction from 8086 and 8088, or from NEC V20 among
> others. =P
> 
> And I've seen code that did more insight testing. (I can give
> code / pointers to anyone interested).
> 

Note: the CPU manuals from Intel include an official assembler
sequence which does not generate exceptions or anything.  The
16 bit version requires ring 0 privileges, the 32 bit version
does not.  Distinguishing amongst pre-CPUID submodels (like
386DX versus 386SX or Intel 386 versus AMD 386 takes more
tricks), but the code cleanly distinguishes 086 from 186 from
286 from 386 from 486-noCPUID from CPU-with-CPUID.

> regards,
> guillem
> 

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


pgpEav57ffy3R.pgp
Description: PGP signature

Re: OOo and testing...

[Anthony Towns]

On Sat, May 17, 2003 at 06:59:37PM +0200, Rene Engelhard wrote:
> That is not parseable to me.. Can anyone give me a clue about why
> openoffice.org isn't in testing yet?

16383 katie 18   0  223M 223M   892 R99.9 29.7  72:31 python

'cause it's not finished running.

(It didn't go in yesterday in spite of being a valid candidate because the
two OOo packages need to go in simultaneously, which I didn't notice; you can
tell it didn't go in because update_output doesn't list openoffice.org in a
`final:' line anywhere)

Cheers,
aj

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

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''

Re: Do not touch l10n files

[Marc Haber]

On Wed, 14 May 2003 01:54:34 +0200, Nicolas Boullis
<[EMAIL PROTECTED]> wrote:
>You're probably right, those useless l10n teams are annoying.

No offense intended, but actually I would prefer my packages to stay
untranslated. I am not an English native speaker, and by no way fluent
in English, but I feel that the documentation for most of the packages
I maintain (which are mostly technical packages) should be read in
English to avoid misunderstandings. If it would be possible to
translate technical documents without causing misunderstanding, I
would be doing my German translation myself.

Unfortunately, there does not seem to be any possibility to prevent
translation work from being done on my packages.

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

Re: Some important orphaned packages

[Marc Haber]

On Mon, 12 May 2003 13:30:00 -0500, Donald J Bindner
<[EMAIL PROTECTED]> wrote:
>Maybe I should roll my sleeves up and send them some patches.

apg's upstream is pretty responsive.

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

Re: A strawman proposal: "testing-x86" (Was: security in testing)

[Theodore Ts'o]

On Sat, May 17, 2003 at 11:41:02AM +0200, Eduard Bloch wrote:
> Not only you, Jerome and me were suggesting it in the past. However I am
> afraid that the whole package movement machinery would have to be
> rewritten to allow independent handling of the version in different
> "testing" threes, plus there would appear some problems with porting of
> the security fixes to all varios testing versions on different
> plattforms. And don't forget, we need lots of man power to sort the
> relevant RC bugs, and likely need something in the BTS to set
> architecture marking tags.

I was thinking about having someone manually override packages into
the hypothetical testing-x86 distribution, and applying common sense
(hence my glibc example), as opposed to needing new machinery in the
BTS to set architecture marking bugs.  I also explicitly called it
"testing-x86", as opposed to the the x86 architecture of testing,
precisely to avoid needing to rewrite the package movement machinery.
The thought process was to see how much of the existing machinery
could be reused without needing to modify them, as I'm a Lazy S.O.B.  :-)

As far as the extra man power is concerned, if there is someone to
support the "testing-x86" distribution, and no one can be found to
support the "testing-m68k" distribution  oh well, they'll just
have to settle for the traditional stable, testing, and unstable.


- Ted

Do not touch l10n files

[Andrew M.A. Cater]

Some common sense rules, perhaps.

1. No one person can produce a solution to fit everyone.

2. The translation teams / translators should try as far as
possible to maintain the meaning of the original.  Sentence 
structure / paragraphing / layout / punctuation will vary
from language to language.  Let the translators find the
"official" rules for layout for their language - tell people
where they can be found - and stick to them.

3. If there are two or more authoritative rule sets e.g. for 
British/American/Canadian/Australian English [I don't know
whether this is true - but it probably is] seek to come
to an international consensus.  The standard British English
text is Hart's Rules for Compositors (as used by Oxford University
Press and the Oxford English dictionary).  This also includes
elementary typesetting rules for other languages but does not
claim to be authoritative for Spanish/Russian/Afrikaans etc.

4. The maintainer of the package should accept translations bona
fide.  If there is a disagreement as to the text of the translation
or its sense or meaning - refer it back to the translators _first_
then argue afterwards.

I speak as someone who can type badly in three languages and understand
the sense of a few more.  I can compose a relatively grammatical sentence
in French/Spanish but wouldn't dream of translating into those languages
without a native speaker looking over what I wrote.  I'm happy to 
talk about the technical meaning of English terms, English grammar or spelling
- but I'm only one native speaker and can't claim authority.  Experienced
translation teams (such as the one of which Martin Quinson forms so 
distinguished

a part) should not be disregarded lightly.

Just my 0.02 Euro :)

Andy

[Sorry about the typo - using mail as mutt has just died on me :) ]

Key-signing in Calgary

[Shaun Jackman]

I'm working in Calgary, Alberta for the next three months. If 
anyone's interested in a key-signing, drop me a line.

Cheers,
Shaun

Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]

[Emile van Bergen]

Hi,

On Sat, May 17, 2003 at 05:57:31PM +0100, Matt Ryan wrote:

> [He who should not be named wrote]
> > That .sig is problematic beyond just its content; it is 12 lines long and
> > adds almost 1kb to each of your messages (probably longer than the
> contents
> > of many messages).  Refer to RFC 1855 or any other netiquette document for
> > further information.
> 
> With statements such as this:
> 
> Never send chain letters via electronic mail.  Chain letters are forbidden
> on the Internet. Your network privileges will be revoked. Notify your local
> system administrator if your ever receive one.
> 
> You can tell this is great advice these days. Like almost all the
> Internet/Usenet etiquette and behaviour things it only serves 1 purpose - to
> make the people spouting it look like old fools when 99.999% of the users
> these days don't give a damn about the 'rules' dreamt up by academics in
> 1985!

So what do you propose then, to drop everything just because you
cynically point out that a lot of rules are being violated today?

Or were you just trolling?

Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

Re: Depends/Conflicts question

[Steve Greenland]

On 11-May-03, 20:41 (CDT), Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: 
> anacron recommends cron and having a system without cron is really rather 
> silly.  I do not see anything wrong with depending on cron only.

Well, that's a valid solution, and since I won't be maintaining
checksecurity after this, I won't have to deal with the inevitable bug
reports...

There still some problems, though. If I do this in checksecurity's
control file:

Depends: cron (>= 3.0pl1-74)

and the new checksecurity unpacks before the new cron, then I get 

dpkg: error processing ../checksecurity_1.0.0_all.deb (--install):
 trying to overwrite `/etc/checksecurity.conf', which is also in package
 cron

If I add "Replaces: cron". then it doesn't have this problem, but a new
one emerges: if I have cron -73 on the system, and just try to install
the new checksecurity, it will replace the checksecurity.conf file
before it fails to configure (due to the dependency on cron -74). If I
now purge checksecurity, it deletes the checksecurity.conf file. Oops!

A pre-depends on cron solves that, but seems excessive. 

Also, if I change the conffile from what was shipped in -73, I get a
bogus changed conffile message during the install (well, not really
bogus, because dpkg can't know that it isn't just some random file on
the system, but annoying.) 

Am I just going to have to handle all of this in the maintainer scripts?
How tedious :-(.

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

Re: Testing the voting scripts

[Steve Greenland]

On 16-May-03, 18:25 (CDT), Manoj Srivastava <[EMAIL PROTECTED]> wrote: 
> Do not enter a number smaller than 1 or larger than 5.
> You may skip numbers.  You may rank options equally (as long as all
> choices X you make fall in the range 1<= X <= 5).

But then:
> [   ] Choice 1: Ultra Violet
> [   ] Choice 2: Violet
> [   ] Choice 3: Indigo
> [   ] Choice 4: Blue
> [   ] Choice 5: Green
> [   ] Choice 6: Yellow
> [   ] Choice 7: Orange
> [   ] Choice 8: Red
> [   ] Choice 9: Infra Red
> [   ] Choice 10: None Of The Above

Was the limit supposed to be 1<=X<=10, or is the voting software
unreasonably limited? (I'm guessing the former, and voting
accordingly...)

Steve


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

Re: Where are translated man pages packaged?

[Martin Schulze]

Denis Barbier wrote:
> Hi,
> 
> There is currently no consensus whether translated man pages should
> be shipped along with original man pages or within manpages-xx packages.

The general rule is that manpages-$lang contains translated manual
pages from the manpages (upstream name: man-pages) package, i.e. libc,
general and kernel manpages.  However, translation upstream make
exceptions so section 1 pages are included as well.

Hence, translations of manual pages from non-manpages packages should
go into the package in question in general and not into the
manpages-foo package.

> Unfortunately this leads to conflicts when a translation is first
> shipped by the latter, then incorporated into the former (e.g. when
> it becomes part of upstream tarball).

"Simply" disable it from the manpages-foo package.  That's already
done with the manpages package (read: check how it's done) in Debian
as well, since it ships some manual pages that are also present in
other packages and Debian considered the other ones more appropriate.

> Some developers are reluctant to include French translated man pages and
> ask me to ship them in manpages-fr.  How can I make them change their
> mind?  Is there a consensus that translated man pages must go with
> original man pages?  Are exceptions needed for some packages?

I'd say that if the maintainer doesn't want to clutter his package
with non-english manpages that aren't supported by upstream,
manpages-foo is a better place than /dev/null.  Alternatively you
could start manpages-foo-debian or something similar if you're about
to collect a whole bunch of manpages that can't be included in the
Debian package the original manpage is in.

Regards,

Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.

OOo and testing...

[Rene Engelhard]

Hi,

first, thanks to aj -- he ovverrode openoffice.org to go into testing regardless
of the 1 RC bugs (flex) [1]

Anyhow, I just looked:

$ madison --regex ^openoffice.org
openoffice.org |1.0.3-2 |  unstable | source, all
openoffice.org-bin |1.0.3-2 |  unstable | i386, powerpc, s390
openoffice.org-debian-files |  1.0.3-2+1 |  unstable | source, all
openoffice.org-help-en |1.0.3-2 |  unstable | all
openoffice.org-l10n-ar |1.0.3-2 |  unstable | all
openoffice.org-l10n-da |1.0.3-2 |  unstable | all
openoffice.org-l10n-de |1.0.3-2 |  unstable | all
openoffice.org-l10n-el |1.0.3-2 |  unstable | all
openoffice.org-l10n-en |1.0.3-2 |  unstable | all
openoffice.org-l10n-es |1.0.3-2 |  unstable | all
openoffice.org-l10n-fr |1.0.3-2 |  unstable | all
openoffice.org-l10n-it |1.0.3-2 |  unstable | all
openoffice.org-l10n-ja |1.0.3-2 |  unstable | all
openoffice.org-l10n-ko |1.0.3-2 |  unstable | all
openoffice.org-l10n-nl |1.0.3-2 |  unstable | all
openoffice.org-l10n-pl |1.0.3-2 |  unstable | all
openoffice.org-l10n-pt |1.0.3-2 |  unstable | all
openoffice.org-l10n-ru |1.0.3-2 |  unstable | all
openoffice.org-l10n-sv |1.0.3-2 |  unstable | all
openoffice.org-l10n-tr |1.0.3-2 |  unstable | all
openoffice.org-l10n-zh-cn |1.0.3-2 |  unstable | all
openoffice.org-l10n-zh-tw |1.0.3-2 |  unstable | all
openoffice.org-spellcheck-de | 20020701-6 |  unstable | source
openoffice.org-spellcheck-de-at | 20020701-6 |  unstable | all
openoffice.org-spellcheck-de-ch | 20020701-6 |  unstable | all
openoffice.org-spellcheck-de-de | 20020701-6 |  unstable | all
openoffice.org-spellcheck-es | 0.0.2002.01.20-2 |  unstable | source, all

Hmm.

OK, check the excuses:

$ grep-excuses "Debian OpenOffice Team"
openoffice.org-debian-files (- to 1.0.3-2+1)
Maintainer: Debian OpenOffice Team
Section: contrib/editors
24 days old (needed 10 days)
Valid candidate
Depends: openoffice.org-debian-files openoffice.org
openoffice.org (- to 1.0.3-2)
Maintainer: Debian OpenOffice Team
Section: contrib/editors
30 days old (needed 10 days)
openoffice.org/alpha unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/arm unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/hppa unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/ia64 unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/m68k unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/mips unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/mipsel unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org/sparc unsatisfiable Depends: openoffice.org-bin (>> 
1.0.2-pre1.0.3)
openoffice.org (source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, 
powerpc, s390, sparc) is buggy! (1 > 0)
Should ignore, but considering anyway
Valid candidate
Depends: openoffice.org openoffice.org-debian-files
openoffice.org-spellcheck-de (- to 20020701-6)
Maintainer: Debian OpenOffice Team
Section: contrib/editors
57 days old (needed 10 days)
Valid candidate
Depends: openoffice.org-spellcheck-de openoffice.org
openoffice.org-spellcheck-es (- to 0.0.2002.01.20-2)
Maintainer: Debian OpenOffice Team
Section: contrib/editors
101 days old (needed 10 days)
Valid candidate
Depends: openoffice.org-spellcheck-es openoffice.org

Seems OK, all valid candidates.
Let's look at update_output.txt...

trying: openoffice.org
skipped: openoffice.org (5 <- 411)
got: 235+0: a-48:a-49:h-45:i-93
* i386: openoffice.org, openoffice.org-bin, openoffice.org-help-en, 
openoffice.org-l10n-ar, openoffice.org-l10n-da, openoffice.org-l10n-de, 
openoffice.org-l10n-el, openoffice.org-l10n-en, openoffice.org-l10n-es, 
openoffice.org-l10n-fr, openoffice.org-l10n-it, openoffice.org-l10n-ja, 
openoffice.org-l10n-ko, openoffice.org-l10n-nl, openoffice.org-l10n-pl, 
openoffice.org-l10n-pt, openoffice.org-l10n-ru, openoffice.org-l10n-sv, 
openoffice.org-l10n-tr, openoffice.org-l10n-zh-cn, openoffice.org-l10n-zh-tw
trying: openoffice.org-debian-files
skipped: openoffice.org-debian-files (6 <- 410)
got: 215+0: a-48:a-49:h-45:i-73
* i386: openoffice.org-debian-files
trying: openoffice.org-spellcheck-de
skipped: openoffice.org-spellcheck-de (7 <- 409)
got: 217+0: a-48:a-49:h-45:i-75
* i386: openoffice.org-spellcheck-de-at, openoffice.org-spellcheck-de-ch, 
openoffice.org-spellcheck-de-de
trying: openoffice.org-spellcheck-es
skipped: openoffice.org-spellcheck-es (8 <- 408)
got: 215+0: a-48:a-49:h-45:i-73
* i386: openoffice.org-spellcheck-es

That is not parseable to me.. Can anyone give me a clue about why
openoffice.org isn't in testing yet?

Regards and thank

Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]

[Matt Ryan]

[He who should not be named wrote]
> That .sig is problematic beyond just its content; it is 12 lines long and
> adds almost 1kb to each of your messages (probably longer than the
contents
> of many messages).  Refer to RFC 1855 or any other netiquette document for
> further information.

With statements such as this:

Never send chain letters via electronic mail.  Chain letters are forbidden
on the Internet. Your network privileges will be revoked. Notify your local
system administrator if your ever receive one.

You can tell this is great advice these days. Like almost all the
Internet/Usenet etiquette and behaviour things it only serves 1 purpose - to
make the people spouting it look like old fools when 99.999% of the users
these days don't give a damn about the 'rules' dreamt up by academics in
1985!


Matt.

Re: Support RFC 3534 - The application/ogg Media Type

[Fabio Massimo Di Nitto]

On Sat, 17 May 2003, J.H.M. Dassen (Ray) wrote:

> Recently the Ogg bitstream format (the container format employed for the
> well-known Ogg Vorbis audio code) has been designated an official MIME type:
> "application/ogg"; for details see http://www.ietf.org/rfc/rfc3534.txt .
>

[SNIP]

> apache: mime.types needs updating.

The mime.types that apache ships as example has been updated in our CVS,
but the one that is used by default (/etc/myme.types) is out of our
control, so apache will be compliant only after mime-support will be
updated.

Thanks for the information.

Fabio

Re: Support RFC 3534 - The application/ogg Media Type

[Matt Zimmerman]

On Sat, May 17, 2003 at 05:57:54PM +0200, J.H.M. Dassen (Ray) wrote:

> apache: mime.types needs updating.

On my system at least, /etc/apache/mime.types is a symlink to
/etc/mime.types.

-- 
 - mdz

Re: security in testing

[Matt Zimmerman]

On Sun, May 18, 2003 at 02:08:28AM +1200, Nick Phillips wrote:

> On Wed, May 14, 2003 at 01:27:12PM -0400, Matt Zimmerman wrote:
> > On Wed, May 14, 2003 at 10:03:32AM -0500, Steve Langasek wrote:
> > 
> > > Figuring that a security upload would be preferable, I approached the
> > > security team and offered to prepare an upload.  I was effectively told
> > > that this isn't done, and because it isn't done, most testing users don't
> > > have security.d.o in their sources.list, so don't bother.
> > 
> > This is an excellent point.
> 
> Really? I think it's a pisspoor point.

That's probably because you completely missed it.

> If people like Steve, who maintain important packages like Samba, bother
> to create the necessary packages, then:
> 
> a) It's a good start -- once people see these things starting to appear,
> more maintainers will bother, and users will start to put the relevant
> lines in their sources.list;
> b) They damn well should be made available.

I absolutely agree.  What are you doing to make this happen?  Sounds like we
need volunteers to process testing-proposed-updates.

> > Testing users do not have such an entry in sources.list, so any other
> > repository would be on equal footing.  However, so far no one has taken
> > any action to coordinate this, nor has anyone prepared updates for
> > testing that would occupy such a repository.
> 
> If this other repository had access to autobuilding facilities, then yes,
> it might be on an equal footing.

testing-proposed-updates does.

-- 
 - mdz

Re: Do not touch l10n files (was Re: DDTP issue)

[Gustavo Noronha Silva]

Em Sat, 17 May 2003 07:54:55 +0200 (CEST), Fabio Massimo Di Nitto
<[EMAIL PROTECTED]> escreveu:

> > Then you ask people to submit bugs to change the original description.
> 
> Yes because if they believe that a better layout should be in place i
> don't see anything wrong in filing a wishlist bug. I would do the same if
> i feel that a description is not readable or can be improved.

Let's clear this out. I do completely agree with you that there should
be clear conversation between maintainer and translator. Both are important
in the process of reaching the Universal goal.

I would agree on setting a policy saying that translators must file wishlist
bugs to present the maintainer their reasons for a future layout change.
I do not agree to binding any typographical stuff to the original with
no appeal. I think we should be rational here, different languages do have
different needs.

So I suggest we: set a policy defining that layout changes are acceptable
but must be taken to the maintainer's review and, if maintainer desagrees
with translator, the discussion should be taken to an appropriate
i18n-tech-ctte forum (that could even be debian-devel, as we have lots
of people speaking lots of different languages here).

> that can satisfy all the languages we have in Debian. Don't forget that
> most of the text we use in descriptions (or templates, or whatever) are
> based on technical language and terms, imho most of them farly new i would
> say and only recently adopted by common languages.

Sure, but that does not mean the typographical rules/recommendations for
each languages should not apply.

Thanks,

[]s!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:   *  
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br

Re: Do not touch l10n files (was Re: DDTP issue)

[Henrique de Moraes Holschuh]

On Sat, 17 May 2003, Martin Schulze wrote:
> Please keep in mind that a translation is a translation and not a
> redesign or reformat.  When translating documents and strings, you

True. But the Debian translators are trying to l10n Debian, not to translate
it.  And l10n *includes* redesign, reformat, and just about everything the
i18n structure of the program/documentation/system allows one to do in order
to make it stick to *all* the conventions of a locale.  And the better the
i18n structure, the MORE you can change when doing l10n.

And those conventions DO include layout, style, grammar... not just
language.

> should always try to stay as close to the original as you can.  Changing
> the text layout is a NO-GO in my opinion - and in the opinion of our
> Apache people apparently.

Apparently. We are trying to bring to light that proper l10n requires more
than that.

Oh, obviously this requires that the DDTP data makes it to inside the deb,
and that maintainers have a "update-from-ddtp" tool that fetches all l10n
data in there, updates it for all locales (this DOES include adding new
ones, and trashing deprecated ones).  That way, the maintainer can (as often
as he has time to do so) get the full view of his package in all locales.

Users would still get the up-to-date data from the DDTP (if they wish so),
or the one in the package (especially for stable releases), at their choice.

When contention arrises, we talk it out such as what is being done for the
apache case.

Is it different from what we do now? Certainly.  Is it better? Well, IMHO it
is MUCH better if we indeed are trying to make Debian universal.  Will it
work?  I am not sure, but I am willing to try.  Too bad I don't have time to
code the tools.

-- 
  "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: security in testing

[Mike Fedyk]

On Wed, May 14, 2003 at 09:24:51PM -0400, Matt Zimmerman wrote:
> already fixed there.  They should go into a security update repository, just
> as is done for stable, but not on security.debian.org.

Why not? It's already there.

#Security   
deb http://security.debian.org/ stable/updates main contrib non-free 
deb http://security.debian.org/ testing/updates main contrib non-free 

Re: Do not touch l10n files (was Re: DDTP issue)

[Martin Schulze]

Denis Barbier wrote:
> > | Description: Versatile, high-performance HTTP server
> > |  The most popular server in the world, Apache features a modular
> > |  design and supports dynamic selection of extension modules at runtime.
> > |  Some of its strong points are its range of possible customization,
> > |  dynamic adjustment of the number of server processes, and a whole   
> > |  range of available modules including many authentication mechanisms,
> > |  server-parsed HTML, server-side includes, access control, CERN httpd
> > |  metafiles emulation, proxy caching, etc.  Apache also supports multiple
> > |  virtual homing.
> > |  .
> > |  Separate Debian packages are available for PHP, mod_perl, Java
> > |  Servlet support, Apache-SSL, and other common extensions.  More
> > |  information is available at http://www.apache.org/.
> 
> [Fake French translation in ASCII]
> 
> > | Description-fr: Serveur HTTP polyvalent haute performance
> > |  Serveur le plus populaire du monde, Apache est caracterise par sa 
> > conception
> > |  modulaire et autorise la selection dynamique des modules d'extension 
> > lors de
> > |  l'execution.
> > |  Quelques-uns de ses points forts sont l'etendue des personnalisations
> > |  possibles, l'ajustement dynamique du nombre de processus du serveur, un
> > |  eventail complet de modules disponibles, incluant :
> > |- plusieurs mecanismes d'authentification ;
> > |- des analyseurs de serveurs de HTML ;
> > |- des inclusions cote serveur ;
> > |- un controle d'acces ;
> > |- une emulation de metafichiers httpd CERN ;
> > |- un cache proxy, etc.
> > |  Apache supporte aussi les sites internes virtuels multiples.
> > |  .
> > |  Des paquets Debian separes sont disponibles pour le PHP, mod_perl, le
> > |  support Servlet Java, Apache-SSL et d'autres extensions habituelles. Plus
> > |  d'informations sont disponibles sur http://www.apache.org/.
> 
> Apache maintainers do not like this translation because the French
> translator changed the layout they chose for their description.
> There is a comma separated list of items in English, and an itemized
> list in French.

Please keep in mind that a translation is a translation and not a
redesign or reformat.  When translating documents and strings, you
should always try to stay as close to the original as you can.  Changing
the text layout is a NO-GO in my opinion - and in the opinion of our
Apache people apparently.

Regards,

Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.

Re: security in testing

[Nick Phillips]

On Wed, May 14, 2003 at 01:27:12PM -0400, Matt Zimmerman wrote:
> On Wed, May 14, 2003 at 10:03:32AM -0500, Steve Langasek wrote:
> 
> > Figuring that a security upload would be preferable, I approached the
> > security team and offered to prepare an upload.  I was effectively told
> > that this isn't done, and because it isn't done, most testing users don't
> > have security.d.o in their sources.list, so don't bother.
> 
> This is an excellent point.

Really? I think it's a pisspoor point. I think that maintainers who care
enough to do the necessary work should be encouraged to do it. The argument
above is circular, chicken-and-egg style.

If people like Steve, who maintain important packages like Samba, bother
to create the necessary packages, then:

a) It's a good start -- once people see these things starting to appear,
more maintainers will bother, and users will start to put the relevant
lines in their sources.list;
b) They damn well should be made available.

> Testing users do not have such an entry in sources.list, so any other
> repository would be on equal footing.  However, so far no one has taken any
> action to coordinate this, nor has anyone prepared updates for testing that
> would occupy such a repository.

If this other repository had access to autobuilding facilities, then yes,
it might be on an equal footing. I believe that the work was put in to
enable automated security builds for woody (as aj keeps telling us).
Why not use it? If it's a case of manpower, what's needed?

As others have argued, I don't believe it's necessary that testing's security
effort be as good as stable's. If it's not, it's important to make sure that
users are aware of the level of security they're getting (so perhaps a
different name for the repository would be advisable?).

In any case, I think that "security updates when anyone can be bothered"
(which would be likely to be whenever the maintainer cared lots, or when
the issue and the package were important enough to motivate another
developer to contribute) would be an improvement on the status quo.


> This is a related, more general issue, of how to minimize the blockage
> introduced by package dependencies.  I think this problem is much more
> worthwhile to address than security updates targeted at 'testing'.

There is no denying that that would be a useful issue to overcome, but
I'm not sure I agree that it's more important than (at least some potential)
security updates to testing, let alone much more.


Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Avoid reality at all costs.

unsubscribe

[DaSilva, Anthony]

unsubscribe

Re: [debian-devel] Questions regarding utf-8

[Rüdiger Kuhlmann]

>--[Andreas Metzler]--<[EMAIL PROTECTED]>
> Bob Hilliard <[EMAIL PROTECTED]> wrote:
> > Andreas Metzler <[EMAIL PROTECTED]> writes:

> > glyphs iconv returns?  My locale is C.  What locale are you using?
> [...]
> de_AT (uses ISO-8859-1 as charset).
> LANG=de_AT, everything else is unset:
> *prompt* echo ö§ | env -u LANG iconv -f latin1 -t ascii//TRANSLIT
> ??
> *prompt* echo ö§ | env LANG=en_US iconv -f latin1 -t ascii//TRANSLIT
> ??
> *prompt* echo ö§ | env LANG=de_AT iconv -f latin1 -t ascii//TRANSLIT
> oe?
> *prompt* echo ö§ | env LANG=fr_FR iconv -f latin1 -t ascii//TRANSLIT
> o?

Which shows nothing other than that the transliteration is havily locale
dependend. Transliterations that make sense in one locale are simply wrong
in other locales. E.g. "a is simply bs in de_*. And while in French it may
be fine to strip the accents, in German it is not, you have to add an e. In
other words, what recode does is creating some sorts of replacement
characters which are often wrong, while iconv will give you question marks
if there's nothing it can do.

Btw in the example the -f latin1 is not only superfluous but wrong, because
it'll stop doing what you think it does when you happen not to use
ISO-8859-1 as your encoding.

-- 
 100 DM =  51  ¤ 13 ¢.
 100  ¤ = 195 DM 58 pf.
  mailto:[EMAIL PROTECTED]
http://www.ruediger-kuhlmann.de/

Re: A strawman proposal: "testing-x86" (Was: security in testing)

[Eduard Bloch]

#include 
* Björn Stenberg [Thu, May 15 2003, 01:18:57AM]:
> Theodore Ts'o wrote:
> > So let me make the following modest strawman proposal.  Let us posit
> > the existence of a new distribution, which for now I'll name
> > "testing-x86".
> 
> I suggested the same thing a few weeks ago, with little reaction. Nice to see
> someone else got the same idea.

Not only you, Jerome and me were suggesting it in the past. However I am
afraid that the whole package movement machinery would have to be
rewritten to allow independent handling of the version in different
"testing" threes, plus there would appear some problems with porting of
the security fixes to all varios testing versions on different
plattforms. And don't forget, we need lots of man power to sort the
relevant RC bugs, and likely need something in the BTS to set
architecture marking tags.

> (And, to avoid the whole "testing is a release tool" debate, we could call it
> something else. 'trying', perhaps. ;-) )

Why another name? Just parallel existing versions in the testing, every
arch may have another one.

MfG,
Eduard.
-- 
Es ist gut, eine Sache doppelt auszudrücken und ihr einen rechten und
linken Fuß zu geben. Auf einem Bein kann die Wahrheit zwar stehen; mit
zweien aber wird sie gehen und herumkommen.
-- Friedrich Nietzsche

Re: Testing the voting scripts

[Sven Luther]

On Fri, May 16, 2003 at 06:25:28PM -0500, Manoj Srivastava wrote:
> Hi folks,
> 
>   I would like to test the new voting scripts, complete with
>  signed acks. I'll be running this vote over on my home machine,
>  pending the resolution of the fact that devotee does not run on
>  potato (vote.d.o runs potato).  This vote would also be a good test
>  of the super majority calculations, since two of the options require
>  super majority.
> 
>   Just replying to this message should be OK. Please do not
>  encrypt the ballot, since the vote scripts can't deal with that yet.
> 
>   May the best color win.
> 
>   manoj
> 
> --
>  Votes must be received by 23:59:59 UTC on May 29th, 2003.

Just a cosmetic detail maybe, but could it be possible to put a space or
other separator in between the different chosen options in the ACK. The
current setup is fine for single digit options i guess, but it is a bit
hard to read when there are two digits.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 10:51:18PM +0200, Michael Banck wrote:
> > > I must be totally missing something. Is one getting the s3kr1t
> > > "create-a-repository-key" when you are becoming a DD? Where would these
> > > repositories be located? Nobody told me so!
> > > 
> > To create a respository you just need a couple debs and website and the
> > tools to create the Packages files, ie: dpkg-scanpackages.
> 
> Aha. And what exactly buys you being a DD in this regard? That's the
> implementation detail I was talking about earlier. You said
> repositories would be easier setup if one was a DD, if I'm not
> completely mistaken?

What it gains you ? It gains you being able to upload to one of the
official repositories (testing-proposed-updates for example) and have
your packages autobuilt on all arches, which is a prerequisite for them
to go into testing and be usefull.

Friendly,

Sven Luther

Re: security in testing

[Sven Luther]

On Fri, May 16, 2003 at 04:09:28PM -0400, Stephen Frost wrote:
> * Michael Banck ([EMAIL PROTECTED]) wrote:
> > I wouldn't feel like setting up a repository for testing that only
> > clueless people-who-put-every-apt-line-they-see-in-their-sources-list[0]
> > would use.
> 
> Others would see what you had done and you could post patches to the BTS
> with the fixes in them, etc.
> 
> > 1. See above
> > 2. I don't have the time
> > 3. I'm not running testing
> 
> Ah, so, you don't have the time.  That would be the reason testing
> hasn't got security updates- not enough skilled people with the time to
> actually *do* it.  People with the time and skills, DD or not, could
> provide updates and eventually I think these people and updates would be
> incorporated into Debian in a move where Debian would then start
> officially supporting testing.  I don't believe Debian should ever do it
> piecemeal or partially.  If it's going to be done then it needs to be
> done completely and we must have enough people to do it before we
> announce that we will.
> 
> > 4. I would have to get a s/390
> 
> While having one would be fun if you'd actually been reading what I've
> been saying you'd have noticed that you wouldn't have needed one.  You
> wouldn't need to be running testing as your main system either.

And beside, i think IBM can give you an account on one of those.

Friendly,

Sven Luther

Re: Do not touch l10n files (was Re: DDTP issue)

[Fabio Massimo Di Nitto]

On Sat, 17 May 2003, Gustavo Noronha Silva wrote:

> Em Fri, 16 May 2003 06:55:04 +0200 (CEST), Fabio Massimo Di Nitto
> <[EMAIL PROTECTED]> escreveu:
>
> > > Why do you bother with the layout of the translation? The translators are
> > > the authorities when it comes to their languages. I think we should not
> > > be put in a jail and be unable to decide how we think our users should
> > > see the message.
> > >
> > > Let's make it clear: we translate stuff to make it more readable to
> > > our fellow compatriots, making the translation look bad to our users
> > > does not help achieving the goal.
> >
> > All this other stuff already found several answers in the thread. No need
> > to reanswer them again and restart from scratch.
>
> You say that as if your answers were the Universal Truth.

It is exactly the otherway around. The question you made have been
discussed and evaluated by different people and found several answers from
different point of views. How can this match with your statement?
Mine was done simply to avoid to discuss again from 0 the same things we
went trough in the thread.

> I don't think anyone needs answers here, we need solution to a problem.

Yes we agree 100% on this.

> Our problem is: there's nothing wrong with the english description.
> French people have different typographical rules, so the layout is not
> approppriate for french.

Actually, what they stated to be a "must" has become during the time a
"preferred" way to write the same text.

> Then you ask people to submit bugs to change the original description.

Yes because if they believe that a better layout should be in place i
don't see anything wrong in filing a wishlist bug. I would do the same if
i feel that a description is not readable or can be improved.

> We have to understand we cannot simply put everyone's culture in a
> single template, because they actualy *are* different.

I didn't ask anyone to change their culture (read as: changing senteces
inside the translation or some words instead of others).

> And that's good.

Never doubt that.

> So the french people ask you through a bug report to modify the original
> description and you ask everybody to standardize, but (let's supose) the
> new layout is really bad for the korean readers. Are you going to ask
> them to file a new bug report asking to change the original description
> so you can make a standard world?

Before placing a new layout to satisfy a wishlist bug i would atleast
spend a mail to see if translators can generally agree on that, specially
after this flamewar. I don't believe that there is not an estestic layout
that can satisfy all the languages we have in Debian. Don't forget that
most of the text we use in descriptions (or templates, or whatever) are
based on technical language and terms, imho most of them farly new i would
say and only recently adopted by common languages.

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Do not touch l10n files (was Re: DDTP issue)

[Gustavo Noronha Silva]

Em Fri, 16 May 2003 06:55:04 +0200 (CEST), Fabio Massimo Di Nitto
<[EMAIL PROTECTED]> escreveu:

> > Why do you bother with the layout of the translation? The translators are
> > the authorities when it comes to their languages. I think we should not
> > be put in a jail and be unable to decide how we think our users should
> > see the message.
> >
> > Let's make it clear: we translate stuff to make it more readable to
> > our fellow compatriots, making the translation look bad to our users
> > does not help achieving the goal.
> 
> All this other stuff already found several answers in the thread. No need
> to reanswer them again and restart from scratch.

You say that as if your answers were the Universal Truth. I don't think
anyone needs answers here, we need solution to a problem. Our problem
is: there's nothing wrong with the english description. French people have
different typographical rules, so the layout is not approppriate for french.

Then you ask people to submit bugs to change the original description.
We have to understand we cannot simply put everyone's culture in a single
template, because they actualy *are* different. And that's good. So the
french people ask you through a bug report to modify the original description
and you ask everybody to standardize, but (let's supose) the new layout is
really bad for the korean readers. Are you going to ask them to file
a new bug report asking to change the original description so you can
make a standard world?

Are we trying to create an universal operating system or to eliminate
the differences between our peoples?

[]s!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:   *  
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br