xconsole eats up memory

[Erik Steffl]

  I noticed that xconsole eats up a lot of ram:

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 4725 root  14 -10  105M  13M 11244 S <   0.0 11.2  2208m XFree86
10873 erik  10   0 18224  11M  5800 S 0.0  9.4   0:27
communicator-sm
 4753 root   9   0  8564 4112  3804 S 0.0  3.2   0:17 xconsole

  there are several bugs filed (and merged) but not resolved (few years
old!). Is there any workaround? Any similar program that would work
correctly (not eating up RAM)?

  TIA

erik


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

Re: call for lintian patches

[Edward Betts]

Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> 
> On 12-Sep-2001 Edward Betts wrote:
> > Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> >> The lintian maintainer is back!  I am slowly reading up on the new policy
> >> and
> >> my bug list.  So, if you have any beefs or patches please read the BTS and
> >> submit accordingly.
> > 
> > I presume you are looking for patches for lintian 1.x rather than lintian 2.
> > Am I right?
> > 
> 
> what is lintian 2.x? (-:

http://cvs.debian.org/lintian2/?cvsroot=lintian

-- 
Edward Betts (GPG: 1BC4E32B)

splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Martin Quinson]

On Wed, Sep 12, 2001 at 03:50:16PM +0200, Wichert Akkerman wrote:
> Previously Martin Quinson wrote:
> > 1) Do the translation
> > 2) Put the translation in the Debian archive
> 
> Wrong. `Make the translation available' would be better. Not all packages
> are in the Debian archive, and they have to be just as useful without
> being forced to be in there.
> 
> > 3) Publish the translation, ie make sure it comes to the user hard disk when
> >the package gets available, even before it gets installed
> 
> Not sure about that. `Make it possible to access a translation for a
> specific version of a specific package' would be better.
> 
> > 4) Use the translation when environment variable is properly set, and when
> >the user ask dpkg & Cie about a package.
>
> > You want to handle 2 by putting the translation in the package.
> 
> No, I want it to be possible to have it in the package, but it might
> be elsewhere as well. Putting all translations in all packages doesn't
> scale, but having multiple translations in a package can be useful (think
> packages not in a full archive, for example a vendor shipping debs on a
> CD).

So, you want to make possible for a package to contain meta-data about
another package, am I right ? Or are you thinking about a separate file, not
in a package, like the Packages.gz is ?
 
> > That's ok, but with which form ? There is at least two solutions: in a
> > po file located somewhere in debian/ dir, or directly in the control
> > file. You prefere the second solution, am I right ?
> 
> For translations inside the package, yes, definitely.

But if you put the translation in the control file, you have to add almost
hundred fields, on per locale: Description-fr ; Description-fr_FR ;
Description-fr_CA ; Description-fr_BE just to have the more used french
variants (and no, it would not be acceptable to merge all country variant of
the language in the language. Think about pt_BR and pt_PT).
http://www.debian.org/intl/l10n/l10n-lang shows that 96 languages are used
somehow in [po files of] Debian. And this list does not contains wa, for
example, which is offen used to design wallon (AFAIK, dutch spoken in
Belgium). http://www.debian.org/intl/l10n/l10n-errors#guess give a list of
refused language codes because they are not part of ISO639. And by the way,
this specification contain much more language, which are not used in Debian
yet.

Would we declare one new field in /lib/parse.c:fieldinfo for each one,
choose the most used one, have a new kind of 'variable field', designating
the Description, allowing a parameter designing the language used ?

> > As far as I understand, you want to take the descriptions aways from
> > the /var/lib/dpkg/status file, and make several files, one per
> > language. this would make the status DB lighter, and ease the handle
> > of several languages.
> 
> I want the status file as it is to change, it contains much more 
> information then dpkg needs to do most of its work. Non-essential
> data such as descriptions, maintainer info, etc. can be moved to
> a seperate new file that tools like dpkg-query and frontends can
> access (dpkg still needs to update it of course).

That sounds great. For example, I'm sure 486 or PentiumI users will love
this idea.

Should we make two files, like status-essential and status-extra, or split
it further ? Moreover, what should be the format of the new file(s) ? Also
rfc822-complient, or something else ? 

For example, for descriptions,
file:///usr/share/doc/gettext-doc/gettext_7.html#SEC36 gives the format of
the binary file used by gettext. It is pretty clear and well documented. We
could use it to store descriptions. Not only translated one, but also
original one. I'm thinking about a mo file associating 'package-version' to
the description in the given language. You could have dpkg writing directly
this file (gettext is GPL, and could be borrowed). 
Then, given the face that any user add a fallback to english, the use of
these data in dpkg & Cie would be easier. But that's just an idea I wanted
to propose, I'm not sure at all that's the best way to do things. (I tend to
think the contrary)

Bye, Mt.

-- 
Un clavier azerty en vaut deux.

Could be this user be nuked from the ML, too ? (was: Wiadomo?? nie mog?a by? dostarczona)

[Martin Quinson]

Every time I post to debian-devel, I get this automatic reply I can read. Is
the fault of seting a wrong auto-responder grave enough to nuke this guy
from the list, or should I set a procmail rule ?

Thanks, Mt.

On Thu, Sep 13, 2001 at 08:56:57AM +, Tomek Zubilew wrote:
> Przykro mi, ale Twoja wiadomo?? o temacie "splitting /var/lib/dpkg/status and 
> handling desc translation (was: ddts notification)" nie mog?a by?
> dostarczona do adresata ("Tomek Zubilew" <[EMAIL PROTECTED]>). Powodem tego 
> jest przekroczenie dozwolonej
> pojemno?ci jej/jego skrzynki pocztowej, spr?buj p??niej.
> 

-- 
Un clavier azerty en vaut deux.

Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Michael Bramer]

On Thu, Sep 13, 2001 at 08:55:44AM +0200, Martin Quinson wrote:
> > > You want to handle 2 by putting the translation in the package.
> > 
> > No, I want it to be possible to have it in the package, but it might
> > be elsewhere as well. Putting all translations in all packages doesn't
> > scale, but having multiple translations in a package can be useful (think
> > packages not in a full archive, for example a vendor shipping debs on a
> > CD).
> 
> So, you want to make possible for a package to contain meta-data about
> another package, am I right ? Or are you thinking about a separate file, not
> in a package, like the Packages.gz is ?

IMHO he thinking about this way:
   The translations should in (optional) in the deb file of a package
  and
   'elsewhere as well', like a Packages.gz or a Description.gz or a ...
   for the archive (for apt-get update and co)




Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
 Es fehlen Informationen der Inhaltsratgeberkonfiguration.
(aus einer Programmfehlermeldung)


pgp1CChusPH8h.pgp
Description: PGP signature

apt.conf.d actions

[Admar Schoonen]

I've posted this 10 days ago on deity, but got no reply, so I'm trying here...

NB: just to make my self clear, I want to download a sources.list-like file
from a server every time just before 'apt-get update' is run. I hope this is
possible.

Admar

- Forwarded message from admar -

Date: Sun, 2 Sep 2001 13:16:55 +0200
Subject: apt.conf.d actions
To: [EMAIL PROTECTED]

Where can I get information about the possible "actions" which can be specified
in /etc/apt/apt.conf.d/ ?

I'm asking this, since I've written a small program which generates a
sources.list.example which contains all distributions of the partial debian
mirror on a machine (azrael); Now I'm looking for a way to automatically
download that sources.list.example on a client every time apt-get update is
run on that client. Is something like putting
APT::Pre-Update {"/usr/local/sbin/getsources.list ftp://azrael/debian";};
in /etc/apt/apt.conf.d/60getsources.list possible?

Kind regards,

Admar Schoonen

- End forwarded message -

A language by any other name

[Marcelo E. Magallon]

Hi,

 some days ago I submitted a bug (111465) against the "locales" package
 asking for the inclusion of the alias "english" for the locale
 "en_US.ISO-8851-1".  Ben Collins, the maintainer of "locales", swiftly
 closed it with this message:

Find a consensus on whether english should be en_US or en_UK and
I'll do it. As I fail to think you will find this consensus, I'm
closing this bug.

 My bug was triggered by the fact that gdm offers a long selection of
 languages, among them English (without bells and whistles, just plain
 old "English") and in case you select that, it sets the environment
 variable LANG to that, "english".  Since that locale doesn't exist, and
 there isn't an alias for that, this causes some programs to emit
 spurious warnings about undefined/invalid locales.  I don't care.  For
 me the solution is to set LANG in my .bashrc (or unset it, which is
 what I actually do -- I noticed the bug because this was a new
 installation where my standard environment wasn't available yet).
 Since other users are likely to hit this, too, I submitted at bug.  At
 first I was going to submit it against gdm, for setting LANG to a "bad"
 value, but then I noticed /etc/locale.alias contains things like:

deutsch de_DE.ISO-8859-1
françaisfr_FR.ISO-8859-1
french  fr_FR.ISO-8859-1
german  de_DE.ISO-8859-1
portuguese  pt_PT.ISO-8859-1
spanish es_ES.ISO-8859-1

 What's the problem?  German is spoken outside Germany.  That what's
 spoken outside Germany is not the same as that what's spoken inside
 Germany, but that what's spoken outside is still called German
 (officially), as far as I know.  That is to say, de_AT.ISO-8859-1 is as
 "german" as de_DE.ISO-8859-1.  The same goes for French, Portuguese and
 Spanish, this being the extreme case since it's spoken in 20+ countries
 outside Spain but it's still called "Spanish" in all of them (ignore
 "Castellano", please).  What makes English different?  In fact, after
 thinking about this, and given what's stored in that file, I'd change
 my bug to "please alias english to en_UK.ISO-8859-1" (or more
 appropiately en_UK.ISO-8859-15)

 But Ben wants a consensus, so I'm asking here.

 FWIW, that file *is* shipped with locales as /etc/locale.alias, even if
 there's no sensible default for some entries there, as I have shown
 above.

 TIA,

-- 
Marcelo | Nanny Ogg never did any housework herself, but she was
[EMAIL PROTECTED] | the cause of housework in other people.
| -- (Terry Pratchett, Lords and Ladies)

Re: A language by any other name

[Guus Sliepen]

On Thu, Sep 13, 2001 at 11:07:43AM +0200, Marcelo E. Magallon wrote:

>  But Ben wants a consensus, so I'm asking here.

I would alias english to en_UK, since it is reasonable to choose the flavour
spoken in the language of origin.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


pgp5LzGx3Z12f.pgp
Description: PGP signature

Re: A language by any other name

[Nick Phillips]

On Thu, Sep 13, 2001 at 11:07:43AM +0200, Marcelo E. Magallon wrote:

>  But Ben wants a consensus, so I'm asking here.
> 
>  FWIW, that file *is* shipped with locales as /etc/locale.alias, even if
>  there's no sensible default for some entries there, as I have shown
>  above.

2 aliases, "english" for the English, "american" for the Americans.

-- 
Nick Phillips -- [EMAIL PROTECTED]
People are beginning to notice you.  Try dressing before you leave the house.

Re: A language by any other name

[David N. Welton]

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

>  My bug was triggered by the fact that gdm offers a long selection
>  of languages, among them English (without bells and whistles, just
>  plain old "English") and in case you select that, it sets the
>  environment variable LANG to that, "english".

Maybe it should ask if you want british or american english.

Trying to decide which one is 'the' English is probably a good recipe
for a flame war with no result.

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

Re: A language by any other name

[David N. Welton]

Nick Phillips <[EMAIL PROTECTED]> writes:

> 2 aliases, "english" for the English, "american" for the Americans.

I don't speak 'american', though, I speak 'english', and will look for
that, as will the rest of my compatriots, when asked to select the
language I speak.  Nice try for a compromise, but it won't work.
"British English" and "American English" is ok, though, and is
probably the only fair way to do this (or use English(American) and
English(British) so they sort next to one another?).

Before we go off on too much of a flame war here, *please* note that
Marcelo says that Ben wants a consensus.  Does anyone believe that a
*consensus* is possible?

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

Re: A language by any other name

[Nick Phillips]

On Thu, Sep 13, 2001 at 11:46:06AM +0200, David N. Welton wrote:

> > 2 aliases, "english" for the English, "american" for the Americans.
> 
> I don't speak 'american', though, I speak 'english', and will look for
> that, as will the rest of my compatriots, when asked to select the
> language I speak.  Nice try for a compromise, but it won't work.

OK then, if the English aren't allowed to speak "english" [*], 2 aliases
"english-british" and "english-american".

> Before we go off on too much of a flame war here, *please* note that
> Marcelo says that Ben wants a consensus.  Does anyone believe that a
> *consensus* is possible?

Based on pragmatism, yes. Based on everyone having their ideal, no.



Cheers,


Nick


[*] By definition, the English speak English. What the Americans speak is
different to what the English speak. Therefore the Americans don't speak
English.
Simple as that ;) I am however prepared to let it go in the interest of
avoiding a pointless flamewar. Happy to continue by private mail, though.
Limited offer, for a short time only...

-- 
Nick Phillips -- [EMAIL PROTECTED]
You've been leading a dog's life.  Stay off the furniture.

Re: A language by any other name

[Junichi Uekawa]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> immo vero scripsit

> deutsch de_DE.ISO-8859-1
> > french  fr_FR.ISO-8859-1
> german  de_DE.ISO-8859-1
> portuguese  pt_PT.ISO-8859-1
> spanish es_ES.ISO-8859-1

If these refer to the "people", then the problem is simple.

The flame war would look at the direction of 
"why don't we have scots while we have english?"


english for EN and american for US seems to be 
a logical solution.

Discussions claiming that people in the US are not American,
or American people should not default to English language,
should really not be done here.



If people are expecting "language" to be there,
yes, we know there exists variations of languages.


regards,
junichi

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

Re: A language by any other name

[Francesco P. Lovergine]

On Thu, Sep 13, 2001 at 11:07:43AM +0200, Marcelo E. Magallon wrote:
> Hi,
> 
>  some days ago I submitted a bug (111465) against the "locales" package
>  asking for the inclusion of the alias "english" for the locale
>  "en_US.ISO-8851-1".  Ben Collins, the maintainer of "locales", swiftly
>  closed it with this message:
> 
> Find a consensus on whether english should be en_US or en_UK and
> I'll do it. As I fail to think you will find this consensus, I'm
> closing this bug.
> 
>  My bug was triggered by the fact that gdm offers a long selection of
>  languages, among them English (without bells and whistles, just plain
>  old "English") and in case you select that, it sets the environment
>  variable LANG to that, "english".  Since that locale doesn't exist, and
>  there isn't an alias for that, this causes some programs to emit
>  spurious warnings about undefined/invalid locales.  I don't care.  For
>  me the solution is to set LANG in my .bashrc (or unset it, which is
>  what I actually do -- I noticed the bug because this was a new
>  installation where my standard environment wasn't available yet).
>  Since other users are likely to hit this, too, I submitted at bug.  At
>  first I was going to submit it against gdm, for setting LANG to a "bad"
>  value, but then I noticed /etc/locale.alias contains things like:
> 

What if the gdm pkg cut off `plain' english?
Maybe a choice among english_british and english_american could
me more correct. 
What about english_italian also :) ? We speak brooklino instead of
plain english, generally ...

-- 
Francesco P. Lovergine

Re: System spec.'s

[Wouter Verhelst]

On Thu, 13 Sep 2001, Jason Thomas wrote:
> On Wed, Sep 12, 2001 at 04:30:40PM -0700, Ralph Jennings wrote:
> > A video card makes things easier, though you could also do it over a serial
> > dumb terminal (but you do need *something* to enable interaction with the 
> > install scripts).  Your ATI card, and normal AT or PS/2 keyboard will most
> > likely work (unless they're broken).
> 
> PC hardware won't even POST without a videocard!

I've got a 486 running 24/7 here, without a videocard. You're telling me
its BIOS is running a firewall? ;-)

Sure, windows won't boot. But most BIOSes allow you to select there's no
need to stop booting when the POST reports a failure. I get lots of beeps
when it boots, but it works perfectly well.

-- 
wouter dot verhelst at advalvas dot be

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

rm -rf /bin/laden

Re: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Steve Greenland]

On 12-Sep-01, 19:08 (CDT), Cesar Mendoza <[EMAIL PROTECTED]> wrote: 
> 
> I find the package useful and I'm also aware of the shortcomings of
> ssh-agent, but was your solution to cron job's that do rsync over ssh?
> and I don't think that pass phrase less keys is an option. 

Why not? Create a dedicated key for the job, and set the options on the
key to minimize its functionality[1] to only that absolutely needed
for the job (from="myhost.whatever", etc.). That, to my taste, seems a
lot more secure than what keychain does. Admitted, that may be only my
perception, but I doubt that it is an *less* secure.

>What you are doing is building a case against ssh-agent, keychain is
>just a wrapper around it.

Ssh-agent can be used and abused. Keychain seems to encourage abuse. It
adds an extra layer of things to go wrong.

Steve

[RFC] Developer documentation packages.

[Francesco P. Lovergine]

Hi folks.

I think there is a fundamental lacks of `general' documentation for
developers in Debian. I'd like to see some e-book available as
packages under /usr/share/doc. E.g. an HTML reference or many
e-books currently available at DevEdge, or many others - Thinking
C/Java/C++?. 

Some e-books are available also under Open Publication License.
What do you think of a pseudo package `ebooks-dev' which collects
as many guides, faqs and e-books as possible (in HTML format 
whenever possible)? Is this a well-known question? What are your
comments about this argument?
What about including OPL under /usr/share/common-licenses ?

-- 
Francesco P. Lovergine

Re: Could be this user be nuked from the ML, too ? (was: Wiadomo?? nie mog?a by? dostarczona)

[Marcin Owsiany]

On Thu, Sep 13, 2001 at 09:04:20AM +0200, Martin Quinson wrote:
> Every time I post to debian-devel, I get this automatic reply I can read. Is
> the fault of seting a wrong auto-responder grave enough to nuke this guy
> from the list, or should I set a procmail rule ?
> 
> Thanks, Mt.
> 
> On Thu, Sep 13, 2001 at 08:56:57AM +, Tomek Zubilew wrote:
> > Przykro mi, ale Twoja wiadomo?? o temacie "splitting /var/lib/dpkg/status 
> > and handling desc translation (was: ddts notification)" nie mog?a by?
> > dostarczona do adresata ("Tomek Zubilew" <[EMAIL PROTECTED]>). Powodem tego 
> > jest przekroczenie dozwolonej
> > pojemno?ci jej/jego skrzynki pocztowej, spr?buj p??niej.

BTW this means "quota exceeded", so this is probably this guy's
ISP's fault.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Re: [RFC] Developer documentation packages.

[David N. Welton]

"Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:

> Some e-books are available also under Open Publication License.
> What do you think of a pseudo package `ebooks-dev' which collects as
> many guides, faqs and e-books as possible (in HTML format whenever
> possible)? Is this a well-known question? What are your comments
> about this argument?

Books are big.  Something that pulls in a lot of them is likely to be
quite heavy.  I think a package called 'books index' would make more
sense.  This would provide an index to all the book packages that are
available in Debian, instructing the user on how to go about
downloading it.  Does something like this make sense?

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

Re: A language by any other name

[Federico Di Gregorio]

On Thu, 2001-09-13 at 11:35, David N. Welton wrote:
> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> 
> >  My bug was triggered by the fact that gdm offers a long selection
> >  of languages, among them English (without bells and whistles, just
> >  plain old "English") and in case you select that, it sets the
> >  environment variable LANG to that, "english".
> 
> Maybe it should ask if you want british or american english.
> 
> Trying to decide which one is 'the' English is probably a good recipe
> for a flame war with no result.

why? we know what is *the* english, the one that originated in england.
(note how the two words have the same root, eng-?) as a pratical rule, i
suggest to assign the language 'name' to the locale of the coutry that
originated it. spain for spanish, italy for italian, france for french,
etc. everybody is accepting that on other languages, don't see why the
americans should do different... :( 

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
  Put a GNOME on your desktop! [http://www.gnome.org]
  -- brought to you by One Line Spam

Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Wichert Akkerman]

Previously Martin Quinson wrote:
> So, you want to make possible for a package to contain meta-data about
> another package, am I right ?

Wrong, that would not make any sense.

> Or are you thinking about a separate file, not in a package, like the
> Packages.gz is ?

Yes.

> But if you put the translation in the control file, you have to add almost
> hundred fields, on per locale: Description-fr ; Description-fr_FR ;
> Description-fr_CA ; Description-fr_BE just to have the more used french
> variants (and no, it would not be acceptable to merge all country variant of
> the language in the language. Think about pt_BR and pt_PT).

Bogus. If you buy wordperfect  does it have 96 different translations
in it? Of course not, they only put in a few important ones. 

> Would we declare one new field in /lib/parse.c:fieldinfo for each one,
> choose the most used one, have a new kind of 'variable field', designating
> the Description, allowing a parameter designing the language used ?

Please let go of the idea that dpkg should keep a list of all descriptions
in memory, that is simply not reasonable. In fact forget about dpkg internals
completely, they are completely irrelevant to this discussion.

> Should we make two files, like status-essential and status-extra, or split
> it further ? Moreover, what should be the format of the new file(s) ? Also
> rfc822-complient, or something else ? 

Does it really matter?

> For example, for descriptions,
> file:///usr/share/doc/gettext-doc/gettext_7.html#SEC36 gives the format of
> the binary file used by gettext. It is pretty clear and well documented. We
> could use it to store descriptions. Not only translated one, but also
> original one.

And it would mean you have a format that no standard unix commandline
tools can parse or modify, in other words it's not acceptable.

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: [RFC] Developer documentation packages.

[Roland Mas]

David N. Welton (2001-09-13 14:30:54 +0200) :

> Books are big.  Something that pulls in a lot of them is likely to
> be quite heavy.  I think a package called 'books index' would make
> more sense.  This would provide an index to all the book packages
> that are available in Debian, instructing the user on how to go
> about downloading it.  Does something like this make sense?

  So we'd have some sort of book-get package, like the controversial
porn-get (which shares the characteristics you've described)?

Roland.
-- 
Roland Mas

A lesson for you all: never fall in love during a total eclipse.
  -- Senex, in A Funny Thing Happened on the Way to the Forum

Re: [RFC] Developer documentation packages.

[Francesco P. Lovergine]

On Thu, Sep 13, 2001 at 02:30:54PM +0200, David N. Welton wrote:
> "Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:
> 
> > Some e-books are available also under Open Publication License.
> > What do you think of a pseudo package `ebooks-dev' which collects as
> > many guides, faqs and e-books as possible (in HTML format whenever
> > possible)? Is this a well-known question? What are your comments
> > about this argument?
> 
> Books are big.  Something that pulls in a lot of them is likely to be
> quite heavy.  I think a package called 'books index' would make more
> sense.  This would provide an index to all the book packages that are
> available in Debian, instructing the user on how to go about
> downloading it.  Does something like this make sense?
> 

Well if we started with conventional names such as

ebook-dev-*

then something like:

apt-cache search ebook-dev 

suffices for a complete index. In this case, a pseudo package could
be unuseful.

What about a unique tree for this kind of books, like

/usr/share/doc/ebook-dev

which contains a couple of directories:

html
pdf

for different kinds of ebooks?

> Ciao,
> -- 
> David N. Welton
>Consulting: http://www.dedasys.com/
> Free Software: http://people.debian.org/~davidw/
>Apache Tcl: http://tcl.apache.org/
>  Personal: http://www.efn.org/~davidw/
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Francesco P. Lovergine

Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Michael Bramer]

On Thu, Sep 13, 2001 at 02:35:46PM +0200, Wichert Akkerman wrote:
> > But if you put the translation in the control file, you have to add almost
> > hundred fields, on per locale: Description-fr ; Description-fr_FR ;
> > Description-fr_CA ; Description-fr_BE just to have the more used french
> > variants (and no, it would not be acceptable to merge all country variant of
> > the language in the language. Think about pt_BR and pt_PT).
> 
> Bogus. If you buy wordperfect  does it have 96 different translations
> in it? Of course not, they only put in a few important ones. 

stop.

wordperfect is no free software and they can only support some
languages. Get KDE, we have 38 kde-i18n-* packages. This is the
_minimum_.

You say 'few important'. But what languages is important? Somebody
say: throw away English and get Russian. Others like (or better
_need_) Polish, german, Japanese, China, ...

And if we get translators, why not add a some more languages. We have
now in the ddtp only 11 languages at the beginning and we don't have
real support in the project, in dpkg etc.

(btw, the boot-floppies support now IMHO 19 languages.)

If debian is a 'general OS', it will (and must) support more and more
languages. Only some people can speak, read and understand english. 



Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Ist es nicht jedem selbst überlassen, ob er einen Arbeitsplatz
wählt, bei dem Windows oder Zölibat Pflicht sind?


pgpetRb3PvdH1.pgp
Description: PGP signature

Re: Bug#112118: ITP: python-visual -- A Python library for 3d visualization

[Peter S Galbraith]

[EMAIL PROTECTED] wrote:

> Package: wnpp
> Severity: wishlist
> 
> Visual is a library for 3D scientific visualization. It allows rapid
> development of programs in Python, but is itself written in C++ for speed. 
> It currently supports various colored geometrical primitives (texture 
> support is being added). It was developed for use by a Carnegie-Mellon 
> University honors first-year physics course.
> 
> It is copyrighted under the Python license, and you can get it from
> http://vpython.sourceforge.net by CVS.

Link not found. I found http://sourceforge.net/projects/visualpython/

The home page seems to be 
 http://virtualphoton.pc.cc.cmu.edu/projects/visual/
 
Looks cool!

Peter

proposal for an Apache (web server) task force

[Ardo van Rangelrooij]

Hi,

I would like to propose to form an Apache (web server) task force to maintain 
the
Apache packages currently maintained by Johnie Ingram (netgod) (and potentially
related packages if the need arises).  The current state of Apache and the 
recent
need to fix at least some of the outstanding bugs led me to the conclusion a 
more
active maintenance of these packages is needed.  The intend of this proposal is
not to simply take over the packages (although it might come to that), but to 
help
in the maintenance of them.

As the first step I propose to add an Uploaders field to the package (once we 
have 
a list of people).

Some of the other things this task force would do are

 - writing up guidelines for packaging Apache modules (a kind of policy doc)
 - migration to Apache 2 (IIRC an ITP for this has already been filed by 
somebody)

I also propose to set up a mailing list for this.
 
Thanks,
Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: Automating dpkg-reconfigure answers via a shell script

[VALETTE Eric]

Wichert Akkerman wrote:
It should be possible to do
dpkg -i pkg.deb <
No it should not, that is completely the wrong way to do it. That
is just a hack to work around debconf not working properly for you
or packages not using it yet.
I disagree. Debconf will never be able to answer anything that I want 
and that is not default. If debconf is able to handle default value 
correctly, I will then need to use dpkg-reconfigure to change the 
default value. I want to make it non interactively. Other solution is to 
not install the packages that need special configuration and install 
them using dpkg -i and a way tio give the values I want.

And if you look at the fai software 


They have faced excatly the same problem meaning they have also found no 
solution. I think we should have dpkg-reconfigure (or dpkg or whatever) 
be able to overide default pacakge installtion value from a file.

So for me it is a serious missing feature either in dpkg -i or 
dpkg-reconfigure. Or try to install more than 3 machine each week and 
you will see what I mean...

Never mind, thanks for your time and answers,
--
   __
  /  `  Eric Valette - Canon CRF
 /--   __  o _. Product Dev. Group Software Team Leader
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne  Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91   Fax: +33 (0)2 99 84 11 30
E-mail: [EMAIL PROTECTED]http://www.crf.canon.fr

Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Wichert Akkerman]

Previously Michael Bramer wrote:
> wordperfect is no free software and they can only support some
> languages. Get KDE, we have 38 kde-i18n-* packages. This is the
> _minimum_.

This is not just about Debian. It is about the dpkg packaging system,
which can be (and is) used outside Debian just as well.

> You say 'few important'. But what languages is important? Somebody
> say: throw away English and get Russian. Others like (or better
> _need_) Polish, german, Japanese, China, ...

That's decided by whoever makes a package. I don't expect everyone
to feel the same way about translations as Debian does.

> And if we get translators, why not add a some more languages. We have
> now in the ddtp only 11 languages at the beginning and we don't have
> real support in the project, in dpkg etc.

Debian can do that. Other might not be able to do that. The world is
bigger then Debian.

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: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Richard Atterer]

On Wed, Sep 12, 2001 at 11:06:30PM -0400, Daniel Jacobowitz wrote:
> Keychain is functionaly equivalent to a passphraseless key, though.

Exactly my point! The only additional thing you get with keychain is a
false sense of security.


On Wed, Sep 12, 2001 at 07:08:32PM -0500, Cesar Mendoza wrote:
> I find the package useful and I'm also aware of the shortcomings of
> ssh-agent, but was your solution to cron job's that do rsync over
> ssh?

SSH keys without a passphrase! :-/ Not that I like the idea, but you
have to realize that keychain buys you absolutely nothing!

> and I don't think that pass phrase less keys is an option.

Sorry, but I can't understand why you think keychain is more secure.

> > What's really needed is a little work on ssh-agent so that
> > - when ssh asks for a DSA passphrase, it also sends it to ssh-agent
> > - ssh-agent can expire keys after some time of inactivity
> > 
> I know that but for now we have to work with what we have, don't you
> think?

Indeed.

You might want to experiment with the following: Create a dedicated
user on the machine that you log into, whose default shell is not
/bin/sh, but a script of yours which executes rsync with the right
options, no matter what arguments are passed to it. Also, the user
should not be able to write to any files in his home directory.

This way, even if the key is compromised, it will be difficult for the
attacker to do anything but run that one command. This doesn't provide
an awful lot of security, and a determined attacker might find a way
to circumvent it, but it's already a lot better than a completely open
account.

Cheers,

  Richard

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


pgpNCX1z3Kcci.pgp
Description: PGP signature

Re: A language by any other name

[Allan Sandfeld Jensen]

On Thursday 13 September 2001 11:07, Marcelo E. Magallon wrote:
>
> deutsch de_DE.ISO-8859-1
> françaisfr_FR.ISO-8859-1
> french  fr_FR.ISO-8859-1
> german  de_DE.ISO-8859-1
> portuguese  pt_PT.ISO-8859-1
> spanish es_ES.ISO-8859-1
>
Okey.  Then english SHOULD point to en_UK.ISO-8859-1. If disagreement with 
americans should block this inclusion, portuguese should be removed too. 
Since the most frequencly use portuguese is Brazilian.

Consistency rules
-Allan

Re: Automating dpkg-reconfigure answers via a shell script

[VALETTE Eric]

No because I install fixed package version.
What does `fixed package version' mean?
Means that I have a package repository (in addition of a generic debian 
mirror via rsync) where I regenerate the Packages and Relase file.

The reason behind that is that I normally install testing with a 
collection of selected packages from unstable (e.g gs-alladin, X11 4.1.x 
untiul recently...). So not apt-get or dselect would do the job.
I automated the creation of a given package set from a reference machine 
as well as the recreation of the Packages and Relase file. I also 
automated the selection of thoses pacakes using the dpkg --set-selection 
trick.


Now I just would like to be able to install automatically this packages 
set using predefined answer value to configuration question. This is the 
only missing item. I'm very frustrated no be able to call either dpkg -i 
or dpkg-reconfigure using predefined input values.


I tested non-interactive mode for debconf without sucess (as well as 
text mode)

What exactly failed?
It does not take my inputs and wait for keyboard.
I did dpkg-reconfigure debconf and selected the non-interactive mode. 
But installing pacakages, I was prompted for questions anyway and the 
usual <

> debian-devel would be better, other people have done automated installed
> and there are a few tools to do that (like fai, which is packaged).
So I also posted to this list. For people that did not get the start of 
the discussion my question is :

It should be possible to do
dpkg -i pkg.deb <
or dpkg-reconfigure pkg <

--
   __
  /  `  Eric Valette - Canon CRF
 /--   __  o _. Product Dev. Group Software Team Leader
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne  Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91   Fax: +33 (0)2 99 84 11 30
E-mail: [EMAIL PROTECTED]http://www.crf.canon.fr

Re: System spec.'s

[Mike Dresser]

> PC hardware won't even POST without a videocard!
>
Depends on your BIOS, I had a 486 in the closet for over a year with no
video card in it.  Setup the machine, set the video to NONE, in the bios,
and pulled the video card out.  Worked fine, until it locks up and you
can't see why :)

Mike

Re: proposal for an Apache (web server) task force

[David N. Welton]

Sounds like a good idea.  I would also be willing to help out if
anything is needed from the ASF, although I'm not involved with the
server project itself.

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

Re: (forw) [ardo@debian.org: proposal for an Apache (web server) task force]

[Daniel Stone]

> From: Ardo van Rangelrooij <[EMAIL PROTECTED]>
> To: Johnie Ingram <[EMAIL PROTECTED]>, debian-devel@lists.debian.org
> Subject: proposal for an Apache (web server) task force
> 
> Hi,
> 
> I would like to propose to form an Apache (web server) task force to maintain 
> the
> Apache packages currently maintained by Johnie Ingram (netgod) (and 
> potentially
> related packages if the need arises).  The current state of Apache and the 
> recent
> need to fix at least some of the outstanding bugs led me to the conclusion a 
> more
> active maintenance of these packages is needed.  The intend of this proposal 
> is
> not to simply take over the packages (although it might come to that), but to 
> help
> in the maintenance of them.

Yes, the bug list is huge. I'm not subscribed to -devel, but this thread
was mentioned on IRC and thus forwarded to me.

> As the first step I propose to add an Uploaders field to the package (once we 
> have 
> a list of people).
> 
> Some of the other things this task force would do are
> 
>  - writing up guidelines for packaging Apache modules (a kind of policy doc)
>  - migration to Apache 2 (IIRC an ITP for this has already been filed by 
> somebody)

"What is 'not on a cold day in hell'?" ;)

Thom May ([EMAIL PROTECTED]) and myself are maintaining apache2. If you want to
email anything related, [EMAIL PROTECTED] is the address; that
goes to both of us. Currently it's not in Debian because Thom's laptop
has blown up. He did very extensive hacking on said laptop (which was
really cool), and it's back in the UK (irony, since he's a Pom
backpacker here in .au) getting fixed. There were no backups or
anything, so I'm just waiting from some stuff from Thom's tree.

In the meantime, I've toyed with modperl-2.0 and php4 for apache2. I got
a successful install of php4 after an apache2 install, but I need to do
silly build and apache2 voodoo to get it integrated. I'm currently
working on it, but I don't exactly have a lot of time.

The current place for my packages is
http://kabuki.sfarc.net/apache2/README. Note that this is strictly
non-US due to modules/ssl and modules/tls in the apache2 source. These
packages don't include mod_perl2 and php4; if you want you can grab them
from CVS and attempt to build.

> I also propose to set up a mailing list for this.

Feel free, but apache2 is nowhere near ready for prime-time. Hell, they
haven't even agreed on a release that should be a beta candidate since
2.0.18, which was ... a long time ago. I'd give it probably more than a
year before I even thought about letting it loose in production.

I also got bored a while ago, and discovered that 2.0.24 builds cleanly
(and works) on Progeny.

:) d
(CC all replies to me as I'm not on -devel).

-- 
Daniel Stone<[EMAIL PROTECTED]>
 I got Linux for Christmas... but it don't work... I'm taking it back
  to the shops
 I got Debian from Dad, RedHat from Mum, and slackware from my
  brother... he's no brother of mine no more

Re: A language by any other name

[John Hasler]

Federico writes:
> ...spain for spanish, italy for italian, france for french,
> etc. everybody is accepting that on other languages, don't see why the
> americans should do different...

Right.  Swiss for Switzerland, belgian for Belgium, canadian for Canada,
mexican for Mexico, brazilian for Brazil...
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: Automating dpkg-reconfigure answers via a shell script

[Thomas Lange]

> On Thu, 13 Sep 2001 16:26:32 +0200, "VALETTE Eric" <[EMAIL PROTECTED]> 
> said:

> Wichert Akkerman wrote:
>>> It should be possible to do
>>> 
>>> dpkg -i pkg.deb <>> 
>>  No it should not, that is completely the wrong way to do
>> it. That is just a hack to work around debconf not working
>> properly for you or packages not using it yet.

> I disagree. Debconf will never be able to answer anything that I
> want and that is not default. If debconf is able to handle
> default value correctly, I will then need to use
> dpkg-reconfigure to change the default value. I want to make it
> non interactively. Other solution is to not install the packages
> that need special configuration and install them using dpkg -i
> and a way tio give the values I want.

> And if you look at the fai software
> 


> They have faced excatly the same problem meaning they have also
> found no solution. I think we should have dpkg-reconfigure (or
> dpkg or whatever) be able to overide default pacakge installtion
> value from a file.

The best solution would be that all postinst scripts use debconf. The
We do not need this dirty trick.

-- 
 Thomas
--
Thomas Lange
Institut fuer Informatikmailto:[EMAIL PROTECTED]
   Universitaet zu Koeln
Pohligstr. 1Telefon: +49 221 470 5303
 50969 KoelnFax: +49 221 470 5317

1024D/AB9B66FD AEA6 A8C1 BD8E 67C4 8EF6  8BCA DC13 E54E AB9B 66FD
--

Re: [RFC] Developer documentation packages.

[Francesco P. Lovergine]

On Thu, Sep 13, 2001 at 03:05:09PM +0200, Francesco P. Lovergine wrote:
> On Thu, Sep 13, 2001 at 02:30:54PM +0200, David N. Welton wrote:
> > "Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:
> > 
> > > Some e-books are available also under Open Publication License.
> > > What do you think of a pseudo package `ebooks-dev' which collects as
> > > many guides, faqs and e-books as possible (in HTML format whenever
> > > possible)? Is this a well-known question? What are your comments
> > > about this argument?
> > 
> > Books are big.  Something that pulls in a lot of them is likely to be
> > quite heavy.  I think a package called 'books index' would make more
> > sense.  This would provide an index to all the book packages that are
> > available in Debian, instructing the user on how to go about
> > downloading it.  Does something like this make sense?
> > 
> 
> Well if we started with conventional names such as
> 
> ebook-dev-*
> 
> then something like:
> 
> apt-cache search ebook-dev 
> 
> suffices for a complete index. In this case, a pseudo package could
> be unuseful.
> 
> What about a unique tree for this kind of books, like
> 
> /usr/share/doc/ebook-dev
> 
> which contains a couple of directories:
> 
>   html
>   pdf
> 
> for different kinds of ebooks?
> 

A note: all ebooks should be not package-specific, i.e. not a program
user's guide. So, HTML 4.0 specs at W3C is a good example, 
Perl doc is a bad example, generally.
It could be nice if all you send me a collection of ebooks you think 
is a must for a developer. Only HTML/PDF/PS/TXT formats.

E.g.

HTML 4.0 and other W3C documentation.
Advanced Linux Programming
Thinking C
Thinking Java
Thinking C++

Copyright and distribution rights should be verified ...


-- 
Francesco P. Lovergine

Re: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Daniel Jacobowitz]

On Thu, Sep 13, 2001 at 01:27:05PM +0200, Richard Atterer wrote:
> Indeed.
> 
> You might want to experiment with the following: Create a dedicated
> user on the machine that you log into, whose default shell is not
> /bin/sh, but a script of yours which executes rsync with the right
> options, no matter what arguments are passed to it. Also, the user
> should not be able to write to any files in his home directory.
> 
> This way, even if the key is compromised, it will be difficult for the
> attacker to do anything but run that one command. This doesn't provide
> an awful lot of security, and a determined attacker might find a way
> to circumvent it, but it's already a lot better than a completely open
> account.

Don't even bother :)  Use command restriction.  man sshd(8), search for
command=.

-- 
Daniel Jacobowitz   Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer

Re: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Cesar Mendoza]

On Thu, Sep 13, 2001 at 06:46:57AM -0500, Steve Greenland wrote:
> On 12-Sep-01, 19:08 (CDT), Cesar Mendoza <[EMAIL PROTECTED]> wrote: 
> > 
> > I find the package useful and I'm also aware of the shortcomings of
> > ssh-agent, but was your solution to cron job's that do rsync over ssh?
> > and I don't think that pass phrase less keys is an option. 
> 
> Why not? Create a dedicated key for the job, and set the options on the
> key to minimize its functionality[1] to only that absolutely needed
> for the job (from="myhost.whatever", etc.). 

That is the setup I have (a especial key just for the cronjob, but since 
it is runing under my user name, I like to use ssh-agent to add my other 
keys, then delete them when the session is over), but I want the key to 
have passphrase, because the moment I shutdown ssh-agent everything is 
secure again, with the passphrase-less key you are insecure all the time 
no matter what until you add a passphrase again. For example if I reboot 
my machine I know that I'm secure until I start ssh-agent, with the 
other option you don't. 

>That, to my taste, seems a
> lot more secure than what keychain does. Admitted, that may be only my
> perception, but I doubt that it is an *less* secure.
> 
> >What you are doing is building a case against ssh-agent, keychain is
> >just a wrapper around it.
> 
> Ssh-agent can be used and abused. Keychain seems to encourage abuse. It
> adds an extra layer of things to go wrong.
>
> Steve

Yeah, but those that means that we are going to censor the package just
because it can be abused. I just wanted to include it on the distribution
because I had an script that did something similar and I though that
other people may be looking for something like that. 

Am I wrong? and we are going to censor packages just because you can 
shoot yourself on the foot. Do I have to add a disclaimer to the package? 
I expect that people that don't like it just don't use it.

Bye
Cesar Mendoza
http://WWW.kitiara.org
--
"Thank you for the latest release of gradewrecker. 
My GPA just went in the corner and shot itself."
 -- USENET posting refering to 
the latest release of NetHack, author unknown 

Re: A language by any other name

[Drew Parsons]

On Thu, Sep 13, 2001 at 02:34:45PM +0200, Federico Di Gregorio wrote:
> > 
> > Maybe it should ask if you want british or american english.
> > 
> why? we know what is *the* english, the one that originated in england.
> (note how the two words have the same root, eng-?) as a pratical rule, i
> suggest to assign the language 'name' to the locale of the coutry that
> originated it. spain for spanish, italy for italian, france for french,
> etc. everybody is accepting that on other languages, don't see why the
> americans should do different... :( 
> 

I agree. This argument sounds reasonable.  If spanish maps to Spain, then
english should map to England.

Drew

-- 
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0  EC0A B6CE 7041 6412 4E4A

RE: A language by any other name

[Sean 'Shaleh' Perry]

> 
>  What's the problem?  German is spoken outside Germany.  That what's
>  spoken outside Germany is not the same as that what's spoken inside
>  Germany, but that what's spoken outside is still called German
>  (officially), as far as I know.  That is to say, de_AT.ISO-8859-1 is as
>  "german" as de_DE.ISO-8859-1.  The same goes for French, Portuguese and
>  Spanish, this being the extreme case since it's spoken in 20+ countries
>  outside Spain but it's still called "Spanish" in all of them (ignore
>  "Castellano", please).  What makes English different?  In fact, after
>  thinking about this, and given what's stored in that file, I'd change
>  my bug to "please alias english to en_UK.ISO-8859-1" (or more
>  appropiately en_UK.ISO-8859-15)
> 

In every app where I was presented the choice I had two -- English(British),
English(American).  We should do the same in the alias file.

Better question is why does gdm expect English there when we don't have it. 
Are other dists or the upstream locale maint making this choice?

Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)

[Michael Bramer]

On Thu, Sep 13, 2001 at 04:25:43PM +0200, Wichert Akkerman wrote:
> Previously Michael Bramer wrote:
> 
> This is not just about Debian. It is about the dpkg packaging system,
> which can be (and is) used outside Debian just as well.
> 
> That's decided by whoever makes a package. I don't expect everyone
> to feel the same way about translations as Debian does.
> 
> Debian can do that. Other might not be able to do that. The world is
> bigger then Debian.

all right. 

But dpkg should have the possibility to include >40 translations.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Falls Ihr Rechner zu oft blau macht ist es Zeit auf Linux umzusteigen.


pgpOBv2IjkQaK.pgp
Description: PGP signature

Re: Bug#112118: ITP: python-visual -- A Python library for 3d visualization

[mdanish]

> > Package: wnpp
> > Severity: wishlist
> > 
> > Visual is a library for 3D scientific visualization. It allows rapid
> > development of programs in Python, but is itself written in C++ for speed. 
> > It currently supports various colored geometrical primitives (texture 
> > support is being added). It was developed for use by a Carnegie-Mellon 
> > University honors first-year physics course.
> > 
> > It is copyrighted under the Python license, and you can get it from
> > http://vpython.sourceforge.net by CVS.
> 
> Link not found. I found http://sourceforge.net/projects/visualpython/
My mistake.


Also I received a response from the visualpython-devel list that the license
is not quite the Python license.  I have enclosed their version here:



The Visual library is Copyright (c) 2000 by David Scherer.

All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of David Scherer not be used
in advertising or publicity pertaining to distribution of the software
without specific, written prior permission.

DAVID SCHERER AND HIS ASSIGNEES DISCLAIM ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL
DAVID SCHERER OR ANY ASSIGNEE OF DAVID SCHERER BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The following notice applies to the CXX library, which is linked with
cvisual:

*** Legal Notice for all LLNL-contributed files ***

Copyright (c) 1996. The Regents of the University of California. All
rights reserved.

Permission to use, copy, modify, and distribute this software for any
purpose without fee is hereby granted, provided that this entire notice
is included in all copies of any software which is or includes a copy or
modification of this software and in all copies of the supporting
documentation for such software.

This work was produced at the University of California, Lawrence
Livermore National Laboratory under contract no. W-7405-ENG-48 between
the U.S. Department of Energy and The Regents of the University of
California for the operation of UC LLNL.


DISCLAIMER

This software was prepared as an account of work sponsored by an agency
of the United States Government. Neither the United States Government
nor the University of California nor any of their employees, makes any
warranty, express or implied, or assumes any liability or responsibility
for the accuracy, completeness, or usefulness of any information,
apparatus, product, or process disclosed, or represents that its use
would not infringe

privately-owned rights. Reference herein to any specific commercial
products, process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation, or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.



-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; OpenPGP public key available from:'finger [EMAIL PROTECTED]' ;;
;;

Re: new proposal: Translating Debian packages' descriptions

[Steve Langasek]

On Tue, 11 Sep 2001, Martin Quinson wrote:

> On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote:

> > Only if the implementation is poor.  The accuracy of a translation can be
> > verified in the process of assembling the file that is to be made available 
> > to
> > user machines (whether that file is Packages.gz, or debian-descs.mo, or
> > whatever).  Obviously the /inputs/ used to create this file must include
> > mappings of English string -> translated string, but these mappings need not
> > be retained in the output file.  We only need to make sure once that the
> > translation is up-to-date, not every time the user runs dpkg, because each
> > version of each package can have only one untranslated description 
> > associated
> > with it -- it's a unique key, by definition.

> > If nothing else, perhaps you would consider that a .mo file containing
> > [untranslated string -> translation] mappings will on average be almost 
> > twice
> > as large as a .mo file containing [(package name,version) -> translation]
> > mappings. :)

> The problem is that you wont have to do a little wheel engineering, but a
> lot of. Think, you will have to design:

>  - the extracting tool control -> po file
>ok, that's true for all solutions ;) I'm working on a patch against
>gettext so that it can handle text following rfc822.

As you say, this is common to all solutions.


>  - a mechanism to help the translator finding which text have to be
>translated in the po file.

>With your solution, the translator will face something like

>msgid "dpkg-1.9"
>msgstr ""

Not at all.  I never suggested that anyone, translator or maintainer, would
directly manipulate a .po file that looks like this.  The .po files should
look exactly as you would expect them to.  It's only /after/ these .po files
have been submitted to the archive that they would be automatically processed
and matched up with actual packages in the archive, so that the resulting .mo
file (or file in another format) contains only the relevant translations.


>  - a mechanism to produce the mo file, or what ever. If you stick to the po
>format, you can reuse msgfmt, through.

So, msgfmt is one option, yes.  Other solutions to parse and merge text would
not be difficult to implement.

>  - an output mecanism, including the fallback to original if the translation
>is outdated. You have either to rewrite msgfmt to do this job at previous
>step, or design a new function in dpkg, apt, grep-dctrl, and all programm
>using the translated descriptions.

The end-user tools would never have to deal with outdated translations if the
".mo" file is assembled ahead of time in a central location.  Match up the
translations, insert them into the distilled .po file using the package
name/version as the key, and you're done.


>  If you change any tool of the gettext mechanism, you lost advantages from
>  the translator point of view, like compendium, containing standard
>  translations for reuse, or user-friendly tools like kbabel for translating,
>  (including ispell possibility, which is implemented in kbabel, and some
>  others)

I'm not suggesting replacing the format that translators will work with.  I'm
just disagreeing that standard .mo files are the best solution to be
integrated into dpkg and apt.

> For what gain ?

> A lookup less ? But gettext is cached, and well optimized. I think the
> change and redesign is too much, regarding to the small speedup you can
> expect...

> Smaller resulting po files ? Come on, the woody+1 release will come on 6 CD
> or more, and you are speaking about saving a few Mb... These data will be
> well compressed, as any natural text, so that a minor problem, in my point
> of view.

More direct lookups.  Smaller .po files.  Better integration with existing
tools, instead of grafting a new arm onto our existing /var/lib/dpkg
structure.

Steve Langasek
postmodern programmer

Re: Automating dpkg-reconfigure answers via a shell script

[VALETTE Eric]

T
The best solution would be that all postinst scripts use debconf. The
We do not need this dirty trick.
So you mean that real life is not as simple as wichert seems to think...
--
   __
  /  `  Eric Valette - Canon CRF
 /--   __  o _. Product Dev. Group Software Team Leader
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne  Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91   Fax: +33 (0)2 99 84 11 30
E-mail: [EMAIL PROTECTED]http://www.crf.canon.fr

Re: A language by any other name

[Keith G. Murphy]

Federico Di Gregorio wrote:
> 
> On Thu, 2001-09-13 at 11:35, David N. Welton wrote:
> > "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> >
> > >  My bug was triggered by the fact that gdm offers a long selection
> > >  of languages, among them English (without bells and whistles, just
> > >  plain old "English") and in case you select that, it sets the
> > >  environment variable LANG to that, "english".
> >
> > Maybe it should ask if you want british or american english.
> >
> > Trying to decide which one is 'the' English is probably a good recipe
> > for a flame war with no result.
> 
> why? we know what is *the* english, the one that originated in england.
> (note how the two words have the same root, eng-?) as a pratical rule, i
> suggest to assign the language 'name' to the locale of the coutry that
> originated it. spain for spanish, italy for italian, france for french,
> etc. everybody is accepting that on other languages, don't see why the
> americans should do different... :(
> 
Closest parallel would be pt/pt_BR, since Brazil/Portugal is another
example of where the daughter country has a greater population and
rivals the mother country as cultural center.  Actually, probably more
so.  So that precedent would argue for english -> en_UK.

As a southerner, I would object to yank -> en_US.  :-)

Considering our troubles, maybe it should be anguished -> en_US.  :-(

Re: A language by any other name

[Federico Di Gregorio]

On Thu, 2001-09-13 at 16:39, John Hasler wrote:
> Federico writes:
> > ...spain for spanish, italy for italian, france for french,
> > etc. everybody is accepting that on other languages, don't see why the
> > americans should do different...
> 
> Right.  Swiss for Switzerland, belgian for Belgium, canadian for Canada,
> mexican for Mexico, brazilian for Brazil...

why did you inverted coutry and language (and the meaning of my post)?

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
  The reverse side also has a reverse side.  -- Japanese proverb

Re: A language by any other name

[David Starner]

On Thu, Sep 13, 2001 at 04:11:39PM +0200, Allan Sandfeld Jensen wrote:
> Okey.  Then english SHOULD point to en_UK.ISO-8859-1. If disagreement with 
> americans should block this inclusion, portuguese should be removed too. 
> Since the most frequencly use portuguese is Brazilian.

Sure. GDM should not be emitting the language names; it should emit the
proper locale names. IMO, the alias file should be purely a local thing;
it's just too adhoc to standardize on, especially as which locales exist
is also local choise.

Anyway, for most people, English is the default language of the system,
and that English is LC_MESSAGES=C, not LC_MESSAGES=en_UK. If we're 
changing this for GDM, it'd be better for GDM to call English C or en_US,
so there's no changes.

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

Why isn't apt 0.5.4 moving to testing?

[Paul D. Smith]

I'm seeing lots of problems with apt 0.5.3 in my testing release
installation which have apparently been fixed in 0.5.4.  So, I wanted to
see why it wasn't in testing yet.

The excuses say:

  apt 0.5.4 (currently 0.5.3) (important) (low) 
Maintainer: APT Development Team <[EMAIL PROTECTED]> 
apt uploaded 22 days ago, out of date by 12 days! 
valid candidate (will be installed unless it's dependent
   upon other buggy pkgs)

So, I took a look at the 0.5.4 Depends line, which says:

  Depends: libc6 (>= 2.2.3-7), libstdc++2.10-glibc2.2

Packages which satisfy both of those dependencies _are_ currently in
testing, so... why isn't APT?

Is there something else I'm missing, or is this bug somewhere?

Thanks!

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]> HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
---
   These are my opinions---Nortel Networks takes no responsibility for them.

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Elie Rosenblum]

On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote:
> On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote:
> > Would turning /usr/lib/procmail-lib into a symlink to the appropriate
> > location be acceptable? I would really rather avoid breaking every rcfile
> > that currently uses any of these recipes.
> 
> This, in particular, won't work, because dpkg won't replace a directory with
> a symlink.  You could, however, replace the files themselves with symlinks,
> and if you decide that it is important enough to transparently preserve
> backward compatibility, I would recommend that you do that.

Good point, I hadn't gotten that far yet. Thanks.

> > My real philosophical difficulty here is that this is a weird case - it is
> > unlikely to burn admins, for whom I could add a notice of this during
> > package upgrade; I am worried about the users in general.
> 
> You can't take too much direct responsibility for the users; you should keep
> the admin well-informed, and let them communicate/deal with the users.  In
> some sites, the admin might silently fix all of the users' configurations;
> at another, they might send out an email announcement telling them to do it
> themselves; another admin might leave it up to the users to fix their
> configurations.  As the Debian maintainer, you can't be aware of local
> policy.

I was worried about bonehead admins who would just consider, "I'm not
using that myself," and ignore the note. I guess, however, it is the
admins right to screw over their own users. It was the very fact that
I can't be aware of local policy that had me worried. :)

I'll probably follow your recommendations, barring anybody else piping
up with something we've overlooked.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

Re: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Martijn van Oosterhout]

On Thu, Sep 13, 2001 at 09:44:06AM -0500, Cesar Mendoza wrote:
> That is the setup I have (a especial key just for the cronjob, but since 
> it is runing under my user name, I like to use ssh-agent to add my other 
> keys, then delete them when the session is over), but I want the key to 
> have passphrase, because the moment I shutdown ssh-agent everything is 
> secure again, with the passphrase-less key you are insecure all the time 
> no matter what until you add a passphrase again. For example if I reboot 
> my machine I know that I'm secure until I start ssh-agent, with the 
> other option you don't. 

You can make multiple keys you know. ssh-keygen -f whateveriwant. Then use
the -i option on ssh and command= in the authorised keys file at the other
end.

No passwords required and basically uncrackable and leaves your normal ssh
key secure.

-- 
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: (forw) [ardo@debian.org: proposal for an Apache (web server) task force]

[Ardo_Vanrangelrooij]

On Fri, Sep 14, 2001 at 12:36:37AM +1000, Daniel Stone wrote:
> > From: Ardo van Rangelrooij <[EMAIL PROTECTED]>
> > To: Johnie Ingram <[EMAIL PROTECTED]>, debian-devel@lists.debian.org
> > Subject: proposal for an Apache (web server) task force
> > 
> > Hi,
> > 
> > I would like to propose to form an Apache (web server) task force to 
> > maintain the
> > Apache packages currently maintained by Johnie Ingram (netgod) (and 
> > potentially
> > related packages if the need arises).  The current state of Apache and the 
> > recent
> > need to fix at least some of the outstanding bugs led me to the conclusion 
> > a more
> > active maintenance of these packages is needed.  The intend of this 
> > proposal is
> > not to simply take over the packages (although it might come to that), but 
> > to help
> > in the maintenance of them.
> 
> Yes, the bug list is huge. I'm not subscribed to -devel, but this thread
> was mentioned on IRC and thus forwarded to me.
> 
> > As the first step I propose to add an Uploaders field to the package (once 
> > we have 
> > a list of people).
> > 
> > Some of the other things this task force would do are
> > 
> >  - writing up guidelines for packaging Apache modules (a kind of policy doc)
> >  - migration to Apache 2 (IIRC an ITP for this has already been filed by 
> > somebody)
> 
> "What is 'not on a cold day in hell'?" ;)

And you react like this exactly why?  Perhaps I should have said 'could' 
instead of
'would' and make the second item 'support in migrating to Apache2'.  I 
certainly didn't
want to imply that you and Thom would be out of business because of this.  But 
I'm sure
that we cannot drop Apache2 in place and assume everything keeps working fine 
without
a hitch.  I was merely thinking that this task force could participate in 
testing and
porting stuff over.  There's no need to feel threatened by this proposal.  
You're work
is appreciated.
 
> Thom May ([EMAIL PROTECTED]) and myself are maintaining apache2. If you want 
> to
> email anything related, [EMAIL PROTECTED] is the address; that
> goes to both of us. Currently it's not in Debian because Thom's laptop
> has blown up. He did very extensive hacking on said laptop (which was
> really cool), and it's back in the UK (irony, since he's a Pom
> backpacker here in .au) getting fixed. There were no backups or
> anything, so I'm just waiting from some stuff from Thom's tree.
> 
> In the meantime, I've toyed with modperl-2.0 and php4 for apache2. I got
> a successful install of php4 after an apache2 install, but I need to do
> silly build and apache2 voodoo to get it integrated. I'm currently
> working on it, but I don't exactly have a lot of time.
> 
> The current place for my packages is
> http://kabuki.sfarc.net/apache2/README. Note that this is strictly
> non-US due to modules/ssl and modules/tls in the apache2 source. These
> packages don't include mod_perl2 and php4; if you want you can grab them
> from CVS and attempt to build.
>   
> > I also propose to set up a mailing list for this.
> 
> Feel free, but apache2 is nowhere near ready for prime-time. Hell, they
> haven't even agreed on a release that should be a beta candidate since
> 2.0.18, which was ... a long time ago. I'd give it probably more than a
> year before I even thought about letting it loose in production.

I didn't expect the migration to happen overnight.  But there are certainly a
lot of gotchas when moving to Apache2 which need to be sorted out and resolved.
If we have a year to do this, all the better given the time certain things 
might take.

> I also got bored a while ago, and discovered that 2.0.24 builds cleanly
> (and works) on Progeny.

Cool!
 
> :) d
> (CC all replies to me as I'm not on -devel).

Done.

Thanks,
Ardo 

Re: Why isn't apt 0.5.4 moving to testing?

[Daniel Burrows]

On Thu, Sep 13, 2001 at 11:16:53AM -0400, "Paul D. Smith" <[EMAIL PROTECTED]> 
was heard to say:
> Packages which satisfy both of those dependencies _are_ currently in
> testing, so... why isn't APT?

  I'm not sure, but I think deity would break if apt moved to testing.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|   DROP THE SCYTHE AND TURN AROUND SLOWLY.   |
| -- Terry Pratchett, "Reaper Man"|
\ Real Programmers don't have braces. -- http://www.python.org ---/

Re: Why isn't apt 0.5.4 moving to testing?

[Anthony Towns]

On Thu, Sep 13, 2001 at 11:16:53AM -0400, Paul D. Smith wrote:
> I'm seeing lots of problems with apt 0.5.3 in my testing release
> installation which have apparently been fixed in 0.5.4.  So, I wanted to
> see why it wasn't in testing yet.
> The excuses say:
>   apt 0.5.4 (currently 0.5.3) (important) (low) 
> Maintainer: APT Development Team <[EMAIL PROTECTED]> 
> apt uploaded 22 days ago, out of date by 12 days! 
> valid candidate (will be installed unless it's dependent
>upon other buggy pkgs)

The List says:

   apt: alpha: apt-move aptitude gnome-apt stormpkg

which means that the new apt breaks apt-move, aptitude, gnome-apt
and stormpkg get broken unless they're upgraded at the same time as
apt. Unfortunately aptitude isn't able to be upgraded (there's an update,
but it's not built on arm yet) and additionally the updated gnome-apt and
stormpkg were built with the old apt on powerpc, so can't be successfully
upgraded either.

Cheers,
aj

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

 ``Freedom itself was attacked this morning by faceless cowards.
 And freedom will be defended.''   Condolences to all involved.


pgpCIckcMQrdZ.pgp
Description: PGP signature

Re: new proposal: Translating Debian packages' descriptions

[Michael Bramer]

On Tue, Sep 11, 2001 at 12:05:25PM -0500, Steve Langasek wrote:
> On Tue, 11 Sep 2001, Martin Quinson wrote:
> > On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote:
> >  - an output mecanism, including the fallback to original if the translation
> >is outdated. You have either to rewrite msgfmt to do this job at previous
> >step, or design a new function in dpkg, apt, grep-dctrl, and all programm
> >using the translated descriptions.
> 
> The end-user tools would never have to deal with outdated translations if the
> ".mo" file is assembled ahead of time in a central location.  Match up the
> translations, insert them into the distilled .po file using the package
> name/version as the key, and you're done.

one point:
 I get the package-1.2 from 'commercial german distributor' with german
 translation. And I watch (with apt-cache show) the description
 package-1.2.1 from security.debian.org? 

 I don't see the german description...

other point:
 I have a gnome-base-1.2 from HelixCode and show the description from
 gnome-base-1.2 from debian... But the description from both packages
 is not the same

 (I know our package management don't support this case, but we have
 this case in real (maybe)...)

next point:
 You have in your apt-source some sources. Like a older CD-Rom with
 2.1 and 2.2_r0, a uptodate 2.2_r3 from ftp.debian.org, testing and
 sid from http.debian.org. 

 With this you have alle descriptions many times in the .mo file.
 (like package-0.9 from 2.1, package-1.4 from 2.2_r0, package-1.4.1
 from 2.2_r3 and package-1.5 from testing and sid...)

 And with the pin feature of apt, more and more people have more
 sources in sources.list...

> >  If you change any tool of the gettext mechanism, you lost advantages from
> >  the translator point of view, like compendium, containing standard
> >  translations for reuse, or user-friendly tools like kbabel for translating,
> >  (including ispell possibility, which is implemented in kbabel, and some
> >  others)
> 
> I'm not suggesting replacing the format that translators will work with.  I'm
> just disagreeing that standard .mo files are the best solution to be
> integrated into dpkg and apt.
...
> More direct lookups.  Smaller .po files.  Better integration with existing
> tools, instead of grafting a new arm onto our existing /var/lib/dpkg
> structure.

Yes, .mo files are not the best thing. this is your point and you are
right. 

But this is a other problem and we can solve this problem parallel. 

I propose this: 
  - use (a unchanged) gettext now in dpkg and get the thing rolling.
  - change the gettext to use a optional 'md5sum-like' thing for a
lookups.

(save the translation with the md5sum of the orignal text as key)

This .mo files can use all programmes with a lot of text and have the
advantages of this. 


Please don't reinvent the wheel, improve the old wheel and make it
chubbier. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung
 der Linux-Rechner erst mal ins Schwimmen kommen." -- Matthias Peick


pgp6Fbio1IZ0O.pgp
Description: PGP signature

Re: Bug#112020: ITP: keychain -- An OpenSSH key manager

[Brian Sniffen]

These are not equivalent situations.  If the machine is turned off,
keychain's keys are removed from memory.  The passphraseless key is
still on disk.  It's also significantly harder to get the key out of
ssh-agent's memory than it is to read it off of disk.

Keychain is inappropriate for many situations.  One case where it fits
perfectly is an ssh gateway machine:  lots of people connecting to a
single account, which has a key with access to a wide-spread network.
They get transparent access, their access to the wide-spread network
can be controlled at the choke-point of the gateway machine, and the 
widely deployed key can be rotated smoothly and transparently.  Only a
few highly trusted people know the passphrase.

This is *significantly* better than the other alternatives:

* Put their keys on the wide-spread network.  Now you have a KMI
  nightmare.  Hundreds of keys to protect, and rotating them is
  hard, slow, and unreliable.  Tracking what's been rotated is even worse.

* Put a passphraseless key on the gateway machine.  People will copy
  it to their home machines, desktops, wireless windows laptops, and
  so on.  It's more convenient and helps them do their jobs.

* Tell everyone the passphrase.  Same problem.

-Brian

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> On Wed, Sep 12, 2001 at 07:08:32PM -0500, Cesar Mendoza wrote:
> > I find the package useful and I'm also aware of the shortcomings of
>> ssh-agent, but was your solution to cron job's that do rsync over ssh?
>> and I don't think that pass phrase less keys is an option. What you are
>> doing is building a case against ssh-agent, keychain is just a wrapper
>> around it.
>
> Keychain is functionaly equivalent to a passphraseless key, though.
-- 
Brian Sniffen [EMAIL PROTECTED]
Security Engineer day: (617) 613-2642cel: (617) 721-0927
Akamai Technologies   eve: (781) 874-0699 pi: (314) 159-2654 


pgpVlIeFNCxjM.pgp
Description: PGP signature

Re: A language by any other name

[Gustavo Noronha Silva]

Em 13 Sep 2001 09:39:07 -0500
John Hasler <[EMAIL PROTECTED]> escreveu:

> Federico writes:
> > ...spain for spanish, italy for italian, france for french,
> > etc. everybody is accepting that on other languages, don't see why the
> > americans should do different...
> 
> Right.  Swiss for Switzerland, belgian for Belgium, canadian for Canada,
> mexican for Mexico, brazilian for Brazil...
hmmm I think he meant the opposite... brazil to portuguese as spoken in Brasil, 
canada for english/french(?) spoken on canada, etc...

[]s!

-- 
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**

Re: A language by any other name

[Gustavo Noronha Silva]

Em Fri, 14 Sep 2001 00:11:06 +1000
Drew Parsons <[EMAIL PROTECTED]> escreveu:

> I agree. This argument sounds reasonable.  If spanish maps to Spain, then
> english should map to England.
nah that's not it... if I understand it correctly, "united states"
would map to es_US and "england" would map to en_EN(UK?)...

[]s!

-- 
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**

Re: A language by any other name

[Gustavo Noronha Silva]

Em Thu, 13 Sep 2001 19:15:28 +0900
Junichi Uekawa <[EMAIL PROTECTED]> escreveu:

> "Marcelo E. Magallon" <[EMAIL PROTECTED]> immo vero scripsit
> 
> > deutsch de_DE.ISO-8859-1
> > > french  fr_FR.ISO-8859-1
> > german  de_DE.ISO-8859-1
> > portuguese  pt_PT.ISO-8859-1
> > spanish es_ES.ISO-8859-1
> 
> english for EN and american for US seems to be 
> a logical solution.
I prefer to map languages to countries as was proposed, by the way
brazilian portuguese doesn't have an entry on that list =(

[]s!

-- 
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**

Re: proposal for an Apache (web server) task force

[T.Pospisek's MailLists]

On Thu, 13 Sep 2001, Ardo van Rangelrooij wrote:

> I would like to propose to form an Apache (web server) task force to
> maintain the Apache packages currently maintained by Johnie Ingram
> (netgod) (and potentially related packages if the need arises). The
> current state of Apache and the recent need to fix at least some of the
> outstanding bugs led me to the conclusion a more  active maintenance of
> these packages is needed.

I agree. I can't remember the last time I did a "apt-get install apache"
an I still had a running webserver. I would think this is mostly due to
the maintainer having too much work on his hands and so not being able to
finetune the upgrade process.

Apache is a very popular package and so IMHO it would be good if it'd be
in a perfect shape.

*t


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

Re: root rm: Permission denied - solution found

[Edward Betts]

Martijn van Oosterhout  wrote:
> The point is that if there is corruption in the filesystem then the
> immutable flag may have be switched on accedently.
> 
> You notice this on ext2 when an inode has been corrupted. There's a 50%
> chance the immutable bit may have been set, leading people to wonder why
> they can't delete the file even as root.

I had the same problem, just worked out how to fix it, I used the chattr
program, see the chattr man page for more details. 

-- 
Edward Betts (GPG: 1BC4E32B)

Re: A language by any other name

[Federico Di Gregorio]

On Thu, 2001-09-13 at 18:26, Gustavo Noronha Silva wrote:
> Em Fri, 14 Sep 2001 00:11:06 +1000
> Drew Parsons <[EMAIL PROTECTED]> escreveu:
> 
> > I agree. This argument sounds reasonable.  If spanish maps to Spain, then
> > english should map to England.
> nah that's not it... if I understand it correctly, "united states"
> would map to es_US and "england" would map to en_EN(UK?)...

my english is really that poor? i meant that if french maps to the fr_FR
locale and so on i don't see why there are problems mapping english to
en_EN. ok, english is _also_ how the americans call their language, but
i think it was called english even before Colombo, right? 

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
 Best friends are often failed lovers. -- Me

Re: new proposal: Translating Debian packages' descriptions

[Steve Langasek]

Hi Michael,

On Thu, 13 Sep 2001, Michael Bramer wrote:

> > The end-user tools would never have to deal with outdated translations if 
> > the
> > ".mo" file is assembled ahead of time in a central location.  Match up the
> > translations, insert them into the distilled .po file using the package
> > name/version as the key, and you're done.

> one point:
>  I get the package-1.2 from 'commercial german distributor' with german
>  translation. And I watch (with apt-cache show) the description
>  package-1.2.1 from security.debian.org?

>  I don't see the german description...

> other point:
>  I have a gnome-base-1.2 from HelixCode and show the description from
>  gnome-base-1.2 from debian... But the description from both packages
>  is not the same

>  (I know our package management don't support this case, but we have
>  this case in real (maybe)...)

This is an interesting point, but the solution is simple.  If package+version
can't be used as a key to uniquely identify packages in the dpkg status
database, then we key on whatever /is/ used by this database.

> next point:
>  You have in your apt-source some sources. Like a older CD-Rom with
>  2.1 and 2.2_r0, a uptodate 2.2_r3 from ftp.debian.org, testing and
>  sid from http.debian.org.

>  With this you have alle descriptions many times in the .mo file.
>  (like package-0.9 from 2.1, package-1.4 from 2.2_r0, package-1.4.1
>  from 2.2_r3 and package-1.5 from testing and sid...)

If the descriptions remain constant for the packages, you're correct that
there would be duplication.  But should we not optimize for the common case?
Most users won't keep /old/ sources in the list; few will even have testing,
unstable, and stable in the list at the same time.

And if we use a file format other than .mo files, it's also possible to design
a system of indirect lookups that /still/ edges out standard gettext lookups
for efficiency.

> > I'm not suggesting replacing the format that translators will work with.  
> > I'm
> > just disagreeing that standard .mo files are the best solution to be
> > integrated into dpkg and apt.
> ...
> > More direct lookups.  Smaller .po files.  Better integration with existing
> > tools, instead of grafting a new arm onto our existing /var/lib/dpkg
> > structure.

> Yes, .mo files are not the best thing. this is your point and you are
> right.

> But this is a other problem and we can solve this problem parallel.

> I propose this:
>   - use (a unchanged) gettext now in dpkg and get the thing rolling.
>   - change the gettext to use a optional 'md5sum-like' thing for a
> lookups.

> (save the translation with the md5sum of the orignal text as key)

For the goal of getting support for translated descriptions into Debian as
soon as possible, I think use of unmodified gettext is a reasonable choice.

Steve Langasek
postmodern programmer

Re: A language by any other name

[David Starner]

On Thu, Sep 13, 2001 at 08:06:22PM +0200, Federico Di Gregorio wrote:
> On Thu, 2001-09-13 at 18:26, Gustavo Noronha Silva wrote:
> > Em Fri, 14 Sep 2001 00:11:06 +1000
> > Drew Parsons <[EMAIL PROTECTED]> escreveu:
> > 
> > > I agree. This argument sounds reasonable.  If spanish maps to Spain, then
> > > english should map to England.
> > nah that's not it... if I understand it correctly, "united states"
> > would map to es_US and "england" would map to en_EN(UK?)...
> 
> my english is really that poor?

I don't think so. I understood perfectly what you meant.

> english is _also_ how the americans call their language, but
> i think it was called english even before Colombo, right? 

It's en_UK, btw. And the locale code for pre-Columbus English
is enm_UK (assuming that the locale system uses 3 character codes
where a 2 character one is not available), not en_UK.

-- 
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: proposal for an Apache (web server) task force

[Martin F Krafft]

also sprach Ardo van Rangelrooij (on Thu, 13 Sep 2001 08:42:44AM)
> I would like to propose to form an Apache (web server) task force to
> maintain the Apache packages currently maintained by Johnie Ingram
> (netgod) (and potentially related packages if the need arises).

count me in.

> I also propose to set up a mailing list for this.

i can give you one easily. applying at lists.debian.org takes ages!
how about [EMAIL PROTECTED] :)

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
first snow, then silence.
this thousand dollar screen dies
so beautifully.


pgpKIi2mmI5n5.pgp
Description: PGP signature

Re: A language by any other name

[mheyes]

Don't forget Dutch, French and German in Belgium.

michael heyes





Gustavo Noronha Silva <[EMAIL PROTECTED]> on 09/13/2001 11:55:08 AM

To:   debian-devel@lists.debian.org
cc:

Subject:  Re: A language by any other name


Em 13 Sep 2001 09:39:07 -0500
John Hasler <[EMAIL PROTECTED]> escreveu:

> Federico writes:
> > ...spain for spanish, italy for italian, france for french,
> > etc. everybody is accepting that on other languages, don't see why the
> > americans should do different...
>
> Right.  Swiss for Switzerland, belgian for Belgium, canadian for Canada,
> mexican for Mexico, brazilian for Brazil...
hmmm I think he meant the opposite... brazil to portuguese as spoken in
Brasil,
canada for english/french(?) spoken on canada, etc...

[]s!

--
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**


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

Re: HW Probe

[Mike Markley]

I don't think that this is a bad goal by any means, but you're still asking
questions about how the RedHat installer does things, on a Debian list. If
you asked for suggestions on how to do it within Debian's current bootdisks
and so forth, that'd be one thing, but if you're mostly trying to duplicate
how RedHat does it, you're asking the wrong list.

Now, on to the Debian-specific question that just came out, I don't know of
any such hardware probe currently available but there are GPL'd tools which
other distros use. These could prove useful.

Also, *please* don't Cc: me on list posts. Even if you disagree with,
ignore, or are ignorant  the suggestion in the developers-reference that
list members *not* be Cc:'d on list mails, I've also set Mail-Followup-To:
and Mail-Copies-To: headers. Thanks.

On Tue, Sep 11, 2001 at 05:19:45AM -0700, BERNARDES,JOAN (Non-HP-Brazil,ex1) 
<[EMAIL PROTECTED]> spake forth:
>   Hi,
>   What do you think about Debian has a GUI for installation? It will
> not be better?
>   Is it possible to do the same with Debian?
>   My project has a Bootable CD based on Debian, but it's difficult to
> run a XServer in any machine without a HW probe, do you know if Debian has
> something like that?
>   Thanks,
>   Joan.

-- 
Mike Markley <[EMAIL PROTECTED]>
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313  FE2B 77A8 F36A 3B04 7084

No problem is insoluble.
- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

mirror-operators please help

[Martin F Krafft]

assuming that i have a local mirror of the entire debian and
debian-non-US trees, how can i rebuild the Packages.gz files myself?
reason that my link is slow, and keeping the mirror up to date takes
time and causes differences between Packages.gz and packages present.
so i figure i'll just make them myself.

how???

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
"it is the mark of an educated mind
 to be able to entertain a thought
 without accepting it."
-- aristoteles


pgp3dRl57D6a4.pgp
Description: PGP signature

Re: new proposal: Translating Debian packages' descriptions

[Michael Bramer]

On Thu, Sep 13, 2001 at 01:26:07PM -0500, Steve Langasek wrote:
> On Thu, 13 Sep 2001, Michael Bramer wrote:
> > > The end-user tools would never have to deal with outdated translations if 
> > > the
> > > ".mo" file is assembled ahead of time in a central location.  Match up the
> > > translations, insert them into the distilled .po file using the package
> > > name/version as the key, and you're done.
> 
> > one point:
> >  I get the package-1.2 from 'commercial german distributor' with german
> >  translation. And I watch (with apt-cache show) the description
> >  package-1.2.1 from security.debian.org?
> 
> >  I don't see the german description...
> 
> > other point:
> >  I have a gnome-base-1.2 from HelixCode and show the description from
> >  gnome-base-1.2 from debian... But the description from both packages
> >  is not the same
> 
> >  (I know our package management don't support this case, but we have
> >  this case in real (maybe)...)
> 
> This is an interesting point, but the solution is simple.  If package+version
> can't be used as a key to uniquely identify packages in the dpkg status
> database, then we key on whatever /is/ used by this database.

apt use IMHO a 'long' pointer. like:
security.debian.org_dists_potato_updates_main_binary-i386_Package_version

But yes, this don't need the size of a normal description.

> > next point:
> >  You have in your apt-source some sources. Like a older CD-Rom with
> >  2.1 and 2.2_r0, a uptodate 2.2_r3 from ftp.debian.org, testing and
> >  sid from http.debian.org.
> 
> >  With this you have alle descriptions many times in the .mo file.
> >  (like package-0.9 from 2.1, package-1.4 from 2.2_r0, package-1.4.1
> >  from 2.2_r3 and package-1.5 from testing and sid...)
> 
> If the descriptions remain constant for the packages, you're correct that
> there would be duplication.  But should we not optimize for the common case?
> Most users won't keep /old/ sources in the list; few will even have testing,
> unstable, and stable in the list at the same time.

No. stable and testing is more and more common. With pins you can
install all from stable and some packages from testing/unstable. I
make some talks about this feature and the user use it, after the know
it. Believe me. 

> > > I'm not suggesting replacing the format that translators will work with.  
> > > I'm
> > > just disagreeing that standard .mo files are the best solution to be
> > > integrated into dpkg and apt.
> > ...
> > > More direct lookups.  Smaller .po files.  Better integration with existing
> > > tools, instead of grafting a new arm onto our existing /var/lib/dpkg
> > > structure.
> 
> > Yes, .mo files are not the best thing. this is your point and you are
> > right.
> 
> > But this is a other problem and we can solve this problem parallel.
> 
> > I propose this:
> >   - use (a unchanged) gettext now in dpkg and get the thing rolling.
> >   - change the gettext to use a optional 'md5sum-like' thing for a
> > lookups.
> 
> > (save the translation with the md5sum of the orignal text as key)
> 
> For the goal of getting support for translated descriptions into Debian as
> soon as possible, I think use of unmodified gettext is a reasonable choice.

Yes. 

We should find a conclusion with the dpkg and apt developer. Only
with a conclusion (maybe without gettext) our user can use this
translations.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
 Der Optimist glaubt wir leben in der besten aller moeglichen Welten.
 Der Pessimist befuerchtet, dass das stimmt.


pgp3FQRorGpXF.pgp
Description: PGP signature

Orphaning all packages

[Lars Wirzenius]

I'm about to take an extended vacation from being a Debian developer,
and will therefore have to orphan all my packages; list with
descriptions below. I suspect that not very many people actually use
these packages (if you do, now is a good time to speak up). Therefore,
if I can't find new maintainers, I'll ask for their removal. The most
popular package is probably sysadmin-guide, but I'm ambivalent whether
it's a good idea to have it packaged anyway.

These packages have three open bugs, of which one is a wishlist bug:

#92294: sysadmin-guide; Missing Build-Depends-Indep 
#99605: publib-dev: Missing symlinks for some man pages 
#67608: syslog-summary: please summarize "least message rpeated x times"
and dont ignore it 

(These are all fairly old by now; my inability to get the time and
energy to fix them is one of the reasons I want to have a vacation from
Debian - all the energy I feel I can put into Debian is spent reading
mailing lists.)

I will happily continue to be the upstream of these packages (except
sysadmin-guide, which really needs a new upstream as well). I will also
help fix packaging related bugs, if necessary.

If you wish to adopt one or more of these packages, please mail me
within September. (Private mail would be preferred, no need to burden
the list with a huge flood of ITAs.) After that, I'll ask for the
removal of the remaining packages. Thanks.

Package: liwc
Description: Tools for manipulating C source code
 Includes programs for converting C++ comments to C comments,
 removing C comments, print out string literals, and converting
 characters to trigraphs and trigraphs to characters.

Package: publib-dev
Description: C function library
 Publib is a library of C functions for various purposes. It has
 been written so that it is easy to extend. It's build tools can
 easily be used for other libraries, but that isn't relevant for
 the Debian pre-packaged version.
 .
 The library contains functions for memory allocation, bit arrays,
 configuration files, comparing standard C types for qsort and
 bsearch, error messages, expression parsing and evaluation,
 filenames, hash tables, integer sets, log files, the Linux Software
 Map, NNTP, priority queues, normal queues, editor buffers, stacks,
 and strings.

Package: sex
Description: Simple editor for X
 The Simple editor for X (SeX) is a relatively small, simple, not too
 slow editor for X. It has no text mode user interface. It doesn't have
 very many features. The primary attraction is the mouse language, which
 is almost identical to xterm's, but clicking the middle mouse button
 inside a selection cuts it instead of pasting it.
 .
 SeX is still under development, and is known to be buggy.

Package: sysadmin-guide
Description: The Linux System Administrators' Guide
 The Linux System Administrators' Guide from the Linux Documentation
Project. Aimed at novice system administrators.

Package: syslog-summary
Description: Summarize the contents of a syslog log file.
 This program summarizes the contents of a log file written by syslog,
 by displaying each unique (except for the time) line once, and also
 the number of times such a line occurs in the input. The lines are
 displayed in the order they occur in the input.

-- 
Lars Wirzenius <[EMAIL PROTECTED]>

Re: mirror-operators please help

[Brandon L. Griffith]

It was just recently posted here:
Oohara Yuuma wrote a short, but decent HOWTO on doing this. You can find it at
http://www.interq.or.jp/libra/oohara/apt-gettable/apt-gettable/index.html

* Martin F Krafft ([EMAIL PROTECTED]) wrote:
> assuming that i have a local mirror of the entire debian and
> debian-non-US trees, how can i rebuild the Packages.gz files myself?
> reason that my link is slow, and keeping the mirror up to date takes
> time and causes differences between Packages.gz and packages present.
> so i figure i'll just make them myself.
> 
> how???



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


pgpPErktozD4R.pgp
Description: PGP signature

Re: A language by any other name

[Wouter Verhelst]

On Thu, 13 Sep 2001, Nick Phillips wrote:
> [*] By definition, the English speak English. What the Americans speak is
> different to what the English speak. Therefore the Americans don't speak
> English.

That would mean the Belgian would speak Belgian, right?

I doubt it...

-- 
wouter dot verhelst at advalvas dot be

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

rm -rf /bin/laden

Re: (forw) [ardo@debian.org: proposal for an Apache (web server) task force]

[Daniel Stone]

On Thu, Sep 13, 2001 at 11:01:49AM -0500, Ardo_Vanrangelrooij wrote:
> On Fri, Sep 14, 2001 at 12:36:37AM +1000, Daniel Stone wrote:
> > > From: Ardo van Rangelrooij <[EMAIL PROTECTED]>
> > > To: Johnie Ingram <[EMAIL PROTECTED]>, debian-devel@lists.debian.org
> > > Subject: proposal for an Apache (web server) task force
> > > 
> > > Hi,
> > > 
> > > I would like to propose to form an Apache (web server) task force to 
> > > maintain the
> > > Apache packages currently maintained by Johnie Ingram (netgod) (and 
> > > potentially
> > > related packages if the need arises).  The current state of Apache and 
> > > the recent
> > > need to fix at least some of the outstanding bugs led me to the 
> > > conclusion a more
> > > active maintenance of these packages is needed.  The intend of this 
> > > proposal is
> > > not to simply take over the packages (although it might come to that), 
> > > but to help
> > > in the maintenance of them.
> > 
> > Yes, the bug list is huge. I'm not subscribed to -devel, but this thread
> > was mentioned on IRC and thus forwarded to me.
> > 
> > > As the first step I propose to add an Uploaders field to the package 
> > > (once we have 
> > > a list of people).
> > > 
> > > Some of the other things this task force would do are
> > > 
> > >  - writing up guidelines for packaging Apache modules (a kind of policy 
> > > doc)
> > >  - migration to Apache 2 (IIRC an ITP for this has already been filed by 
> > > somebody)
> > 
> > "What is 'not on a cold day in hell'?" ;)
>
> And you react like this exactly why?  Perhaps I should have said 'could' 
> instead of
> 'would' and make the second item 'support in migrating to Apache2'.  I 
> certainly didn't
> want to imply that you and Thom would be out of business because of this.  
> But I'm sure
> that we cannot drop Apache2 in place and assume everything keeps working fine 
> without
> a hitch.  I was merely thinking that this task force could participate in 
> testing and
> porting stuff over.  There's no need to feel threatened by this proposal.  
> You're work
> is appreciated.

No, I don't feel at all threatened, it's just that apache2 is still in
alpha and nowhere near ready to replace apache; not by a long shot.

> > Thom May ([EMAIL PROTECTED]) and myself are maintaining apache2. If you 
> > want to
> > email anything related, [EMAIL PROTECTED] is the address; that
> > goes to both of us. Currently it's not in Debian because Thom's laptop
> > has blown up. He did very extensive hacking on said laptop (which was
> > really cool), and it's back in the UK (irony, since he's a Pom
> > backpacker here in .au) getting fixed. There were no backups or
> > anything, so I'm just waiting from some stuff from Thom's tree.
> > 
> > In the meantime, I've toyed with modperl-2.0 and php4 for apache2. I got
> > a successful install of php4 after an apache2 install, but I need to do
> > silly build and apache2 voodoo to get it integrated. I'm currently
> > working on it, but I don't exactly have a lot of time.
> > 
> > The current place for my packages is
> > http://kabuki.sfarc.net/apache2/README. Note that this is strictly
> > non-US due to modules/ssl and modules/tls in the apache2 source. These
> > packages don't include mod_perl2 and php4; if you want you can grab them
> > from CVS and attempt to build.
> > 
> > > I also propose to set up a mailing list for this.
> > 
> > Feel free, but apache2 is nowhere near ready for prime-time. Hell, they
> > haven't even agreed on a release that should be a beta candidate since
> > 2.0.18, which was ... a long time ago. I'd give it probably more than a
> > year before I even thought about letting it loose in production.
> 
> I didn't expect the migration to happen overnight.  But there are certainly a
> lot of gotchas when moving to Apache2 which need to be sorted out and 
> resolved.
> If we have a year to do this, all the better given the time certain things 
> might take.

I think that we need to maintain them separately for quite some time;
even when apache2 *does* replace apache, we should still have an apache1
package.

> > I also got bored a while ago, and discovered that 2.0.24 builds cleanly
> > (and works) on Progeny.
> 
> Cool!
>  
> > :) d
> > (CC all replies to me as I'm not on -devel).
> 
> Done.

Thanks :)
-d

-- 
Daniel Stone<[EMAIL PROTECTED]>
 I got Linux for Christmas... but it don't work... I'm taking it back
  to the shops
 I got Debian from Dad, RedHat from Mum, and slackware from my
  brother... he's no brother of mine no more

Re: Could be this user be nuked from the ML, too ?

[Marc Haber]

On Thu, 13 Sep 2001 14:36:34 +0200, Marcin Owsiany
<[EMAIL PROTECTED]> wrote:
>BTW this means "quota exceeded", so this is probably this guy's
>ISP's fault.

This ISP deserves a LART anywa for sending bounces to the Header-From:
instead of the Envelope-From:.

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: Why isn't apt 0.5.4 moving to testing?

[Christian Leutloff]

Anthony Towns  writes:

> On Thu, Sep 13, 2001 at 11:16:53AM -0400, Paul D. Smith wrote:
> > I'm seeing lots of problems with apt 0.5.3 in my testing release
> > installation which have apparently been fixed in 0.5.4.  So, I wanted to
> > see why it wasn't in testing yet.
> > The excuses say:
> >   apt 0.5.4 (currently 0.5.3) (important) (low) 
> > Maintainer: APT Development Team <[EMAIL PROTECTED]> 
> > apt uploaded 22 days ago, out of date by 12 days! 
> > valid candidate (will be installed unless it's dependent
> >upon other buggy pkgs)
> 
> The List says:
> 
>apt: alpha: apt-move aptitude gnome-apt stormpkg
> 
> which means that the new apt breaks apt-move, aptitude, gnome-apt
> and stormpkg get broken unless they're upgraded at the same time as
> apt. Unfortunately aptitude isn't able to be upgraded (there's an update,
> but it's not built on arm yet) and additionally the updated gnome-apt and
> stormpkg were built with the old apt on powerpc, so can't be successfully
> upgraded either.

Is it really necessary that the package must be able to be upgraded on
every architecture!? If we have 10 (or more) architecture to support,
it is very likely that packages break on a single architecture and
hold on the whole improvement process aided through more people
testing new software (packages).

Bye
  Christian

-- 
Dipl.-Ing. Christian Leutloff, Aachen, Germany  [EMAIL PROTECTED]
   http://www.oche.de/~leutloff/[EMAIL PROTECTED]

Debian GNU/Linux - http://www.de.debian.org/
   taz muss sein. [EMAIL PROTECTED]

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Steve Greenland]

On 13-Sep-01, 10:27 (CDT), Elie Rosenblum <[EMAIL PROTECTED]> wrote: 
> On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote:
> > On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote:
> > > Would turning /usr/lib/procmail-lib into a symlink to the appropriate
> > > location be acceptable? I would really rather avoid breaking every rcfile
> > > that currently uses any of these recipes.
> > 
> > This, in particular, won't work, because dpkg won't replace a directory with
> > a symlink.  You could, however, replace the files themselves with symlinks,
> > and if you decide that it is important enough to transparently preserve
> > backward compatibility, I would recommend that you do that.

Hmmm, I thought that had been fixed, but I may be thinking of something
else.

> Good point, I hadn't gotten that far yet. Thanks.

But what you can do is add the symlink in the postinst. This would mean
failures while the install was processing, but then again, so would no
symlink at all :-).

--
Steve

Re: (forw) [ardo@debian.org: proposal for an Apache (web server) task force]

[Ardo van Rangelrooij]

Daniel Stone ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 13, 2001 at 11:01:49AM -0500, Ardo_Vanrangelrooij wrote:
> > On Fri, Sep 14, 2001 at 12:36:37AM +1000, Daniel Stone wrote:
> > > > From: Ardo van Rangelrooij <[EMAIL PROTECTED]>
> > > > To: Johnie Ingram <[EMAIL PROTECTED]>, debian-devel@lists.debian.org
> > > > Subject: proposal for an Apache (web server) task force
> > > > 
> > > > Hi,
> > > > 
> > > > I would like to propose to form an Apache (web server) task force to 
> > > > maintain the
> > > > Apache packages currently maintained by Johnie Ingram (netgod) (and 
> > > > potentially
> > > > related packages if the need arises).  The current state of Apache and 
> > > > the recent
> > > > need to fix at least some of the outstanding bugs led me to the 
> > > > conclusion a more
> > > > active maintenance of these packages is needed.  The intend of this 
> > > > proposal is
> > > > not to simply take over the packages (although it might come to that), 
> > > > but to help
> > > > in the maintenance of them.
> > > 
> > > Yes, the bug list is huge. I'm not subscribed to -devel, but this thread
> > > was mentioned on IRC and thus forwarded to me.
> > > 
> > > > As the first step I propose to add an Uploaders field to the package 
> > > > (once we have 
> > > > a list of people).
> > > > 
> > > > Some of the other things this task force would do are
> > > > 
> > > >  - writing up guidelines for packaging Apache modules (a kind of policy 
> > > > doc)
> > > >  - migration to Apache 2 (IIRC an ITP for this has already been filed 
> > > > by somebody)
> > > 
> > > "What is 'not on a cold day in hell'?" ;)
> >
> > And you react like this exactly why?  Perhaps I should have said 'could' 
> > instead of
> > 'would' and make the second item 'support in migrating to Apache2'.  I 
> > certainly didn't
> > want to imply that you and Thom would be out of business because of this.  
> > But I'm sure
> > that we cannot drop Apache2 in place and assume everything keeps working 
> > fine without
> > a hitch.  I was merely thinking that this task force could participate in 
> > testing and
> > porting stuff over.  There's no need to feel threatened by this proposal.  
> > You're work
> > is appreciated.
> 
> No, I don't feel at all threatened, it's just that apache2 is still in
> alpha and nowhere near ready to replace apache; not by a long shot.

I see.  All the more reason to get the current version in a better shape as it 
will be
around for quite a while.
 
> > > Thom May ([EMAIL PROTECTED]) and myself are maintaining apache2. If you 
> > > want to
> > > email anything related, [EMAIL PROTECTED] is the address; that
> > > goes to both of us. Currently it's not in Debian because Thom's laptop
> > > has blown up. He did very extensive hacking on said laptop (which was
> > > really cool), and it's back in the UK (irony, since he's a Pom
> > > backpacker here in .au) getting fixed. There were no backups or
> > > anything, so I'm just waiting from some stuff from Thom's tree.
> > > 
> > > In the meantime, I've toyed with modperl-2.0 and php4 for apache2. I got
> > > a successful install of php4 after an apache2 install, but I need to do
> > > silly build and apache2 voodoo to get it integrated. I'm currently
> > > working on it, but I don't exactly have a lot of time.
> > > 
> > > The current place for my packages is
> > > http://kabuki.sfarc.net/apache2/README. Note that this is strictly
> > > non-US due to modules/ssl and modules/tls in the apache2 source. These
> > > packages don't include mod_perl2 and php4; if you want you can grab them
> > > from CVS and attempt to build.
> > >   
> > > > I also propose to set up a mailing list for this.
> > > 
> > > Feel free, but apache2 is nowhere near ready for prime-time. Hell, they
> > > haven't even agreed on a release that should be a beta candidate since
> > > 2.0.18, which was ... a long time ago. I'd give it probably more than a
> > > year before I even thought about letting it loose in production.
> > 
> > I didn't expect the migration to happen overnight.  But there are certainly 
> > a
> > lot of gotchas when moving to Apache2 which need to be sorted out and 
> > resolved.
> > If we have a year to do this, all the better given the time certain things 
> > might take.
> 
> I think that we need to maintain them separately for quite some time;
> even when apache2 *does* replace apache, we should still have an apache1
> package.

Absolutely.  I haven't looked at Apache2 at all yet, but I can imagine that
the APIs have changed too, so every package build against Apache1 will have to
have a separate binary build against Apache2.  But I see the task force as a
means to facilitate all this with guidelines for building and packaging, and
testing, etc. to make the transition as smooth as possible.
 
Thanks,
Ardo 
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: Web interface for Debian Description Translation Server

[Jaime E . Villate]

Hi,
A month ago Michael Bramer (grisu) announced the DDTS project to translate
packages descriptions, and asked me to make a similar announcement about the
translation that we've been doing at "La Espiral" (a group of Spanish-speaking
developers).

We've been translating descriptions into Spanish since last year, using a web
interface. We are already in a very advanced stage -- 5354 descriptions
translated by 99 translators -- to start using the new method proposed by
grisu, and he is to used to the e-mail method that he's been using for the
debconf templates.

Therefore, we agreed with grisu to keep using the two different methods for
translations into different languages, and let other translation teams decide
what they prefer. Both methods will accomplish the same: the creation of
"Packages" files where the descriptions appear translated. Some people
prefer to work using a web browser, while others would rather use a mail
composing program.

The discussion on what will be the best way to incorporate the translated
descriptions into a Debian distribution is a separate issue, and while it gets
resolved we can keep working on the translations.

Our web interface can be accessed at the URL:

   http://www.laespiral.org/ddts/

Where you can find more information about it. At this moment we are
translating descriptions into Spanish and Portuguese (as spoken in Portugal).
Grisu is taking care of the translations into German, French, Italian and
Brazilian Portuguese. If any other groups want to use our web interface,
please let me know (it can be done in a couple of minutes).

We will now try to unify the two methods so that the translation into any of
these languages can be done using any of the two interfaces and ends up at the
same central point.

Cheers,
Jaime Villate
<[EMAIL PROTECTED]>

Re: mirror-operators please help

[Martin F Krafft]

also sprach Brandon L. Griffith (on Thu, 13 Sep 2007 06:03:10PM -0400):
> It was just recently posted here: Oohara Yuuma wrote a short, but
> decent HOWTO on doing this. You can find it at
> http://www.interq.or.jp/libra/oohara/apt-gettable/apt-gettable/index.html

i know this much and made it work before. however, i have the entire
debian tree mirrored and thus need to use apt-ftparchive. but its
syntax is overwhelming.

given the entire
dists/{stable,testing,unstable}/{main,contrib,non-free}/binary-i386
tree for debian and debian-non-US, how do you call apt-ftparchive? the
example given in online help:

   apt-ftparchive packages dists/potato/main/binary-i386/ > \
  dists/potato/main/binary-i386/Packages

seems to ignore override files, and it doesn't really care about pool/
at all, where all the packages are kept...

please help.

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
"if I can't dance, i don't want to be part of your revolution."
- emma goldman


pgp5CK9Md7tww.pgp
Description: PGP signature

Re: A language by any other name

[Federico Di Gregorio]

On Thu, 2001-09-13 at 20:32, David Starner wrote:

> > english is _also_ how the americans call their language, but
> > i think it was called english even before Colombo, right? 
> 
> It's en_UK, btw. And the locale code for pre-Columbus English

ack. just a typo... 

> is enm_UK (assuming that the locale system uses 3 character codes
> where a 2 character one is not available), not en_UK.

hey, i'd like to know _why_ enm... :)

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
 Best friends are often failed lovers. -- Me

Re: Why isn't apt 0.5.4 moving to testing?

[Wichert Akkerman]

Previously Christian Leutloff wrote:
> Is it really necessary that the package must be able to be upgraded on
> every architecture!?

That's the whole purpose of testing, keep the brokenness to a minimum.

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: Orphaning all packages

[mdanish]

Can I have sex?





(sorry, had to be said 8-)

If anyone else steps up to take the package, they're welcome to it.

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; OpenPGP public key available from:'finger [EMAIL PROTECTED]' ;;
;;

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Edward Betts]

Elie Rosenblum <[EMAIL PROTECTED]> wrote:
> I would happily move it to /usr/share, however I am worried about users
> who are already using the current version. Users can use the provided
> recipes with the procmail INCLUDERC directive, and if I move the files
> it will break all of the user rcfiles that already use these includes.
> 
> Would turning /usr/lib/procmail-lib into a symlink to the appropriate
> location be acceptable? I would really rather avoid breaking every rcfile
> that currently uses any of these recipes.

Debconf question: do you want a symlink.

-- 
Edward Betts (GPG: 1BC4E32B)

Re: A language by any other name

[David Starner]

On Fri, Sep 14, 2001 at 01:01:12AM +0200, Federico Di Gregorio wrote:
> On Thu, 2001-09-13 at 20:32, David Starner wrote:
> 
> > is enm_UK (assuming that the locale system uses 3 character codes
> > where a 2 character one is not available), not en_UK.
> 
> hey, i'd like to know _why_ enm... :)

We use the ISO 639-1 values for locales. At which point we need
to exceed those values (and the KDE project has hit that point)
we'll probably use the ISO 639-2 (T) values, which is an extended
list of languages using 3 character codes. enm is Middle English 
(1000-1500 AD) in that list.

-- 
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: A language by any other name

[John Hasler]

michael heyes writes:
> Don't forget Dutch, French and German in Belgium.

French and english in Canada, spanish and mayan in Guatemala, german and
french in Switzerland...  and yet the US gets singled out for criticism
because we refer to our most common language as english.  Why?

There is no one to one relationship between languages and nations, or even
a one to many relationship.  Are US spanish speakers to be told that
they must live in Spain just because they asserted that their preferred
language was spanish?
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Preview of new Ghostscript packages - please test

[Torsten Landschoff]

Hi *, 

Today I got a bunch of gs packages built - they are not ready but at
least everything compiles and I have something to base the following
work on.

You can find them on klecker - apt line:

deb http://people.debian.org/~torsten gs/

Available are i386 binaries and source. Please take a look at these packages
and tell me about any problems which are not obvious - there is a lot
of stuff still lacking and I only want to upload the packages to the
archive when they are feature complete.

On my todo list for tomorrow:

- Enabling the Omni driver
- gimp-print support (stp)
- Adding the wrappers to gs-common (ps2pdf etc.)

Greetings

Torsten


pgpqyusY46Jjh.pgp
Description: PGP signature

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

[Oohara Yuuma]

On Wed, 12 Sep 2001 21:43:16 +0900,
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> If you claim to have rewritten my awk script in perl,
> you should have done something which checks the 
> deps AND the builddeps.
Now count-depends-field looks for both dependency and
build-dependency by default.

top 10 list
6314 perl5
6291 awk
6290 perlapi-5.6.0
6290 perl5-base
6290 mig
6290 libz-dev
6290 libxaw-dev
6290 libwww-ssl0
6290 libstdc++-dev
6290 libpng-dev

source code
http://www.interq.or.jp/libra/oohara/count-depends-field/count-depends-field.perl.gz
full result
http://www.interq.or.jp/libra/oohara/count-depends-field/result-all.txt.gz

--
Oohara Yuuma <[EMAIL PROTECTED]>
Graduate-school of Science, Kyoto University
PGP Key  http://www.interq.or.jp/libra/oohara/pub-key.txt
Key fingerprint = 6142 8D07 9C5B 159B C170  1F4A 40D6 F42E F464 A695

I always put away what I take.
--- Ryuji Akai, "Star a way"

Re: Preview of new Ghostscript packages - please test

[Alan Shutko]

Torsten Landschoff <[EMAIL PROTECTED]> writes:

> - Adding the wrappers to gs-common (ps2pdf etc.)

Is that a good idea?  I know the scripts have changed between GNU and
Aladdin GS, to make things somewhat more secure.  You naturally won't
be able to use the Aladdin versions in gs-common, but that means that
you will lose features.

-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
Give your very best today.  Heaven knows it's little enough.

Re: Preview of new Ghostscript packages - please test

[Alan Shutko]

Alan Shutko <[EMAIL PROTECTED]> writes:

> Is that a good idea?  I know the scripts have changed between GNU and
> Aladdin GS, to make things somewhat more secure.  You naturally won't
> be able to use the Aladdin versions in gs-common, but that means that
> you will lose features.

A bit more data... I'm not sure there are any differences between GNU
GS 6.51 and AFPL 7.00 in this area, but there are changes in CVS HEAD,
so when that releases, there will be differences.  Two I know of are
pdfopt and pdf2ps.

-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
A wise man once said ..."I don't know."

Re: proposal for an Apache (web server) task force

[Ardo van Rangelrooij]

David N. Welton ([EMAIL PROTECTED]) wrote:
> 
> Sounds like a good idea.  I would also be willing to help out if
> anything is needed from the ASF, although I'm not involved with the
> server project itself.

Ok, thanks.

Regards,
Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: proposal for an Apache (web server) task force

[Ardo van Rangelrooij]

T.Pospisek's MailLists ([EMAIL PROTECTED]) wrote:
> On Thu, 13 Sep 2001, Ardo van Rangelrooij wrote:
> 
> > I would like to propose to form an Apache (web server) task force to
> > maintain the Apache packages currently maintained by Johnie Ingram
> > (netgod) (and potentially related packages if the need arises). The
> > current state of Apache and the recent need to fix at least some of the
> > outstanding bugs led me to the conclusion a more  active maintenance of
> > these packages is needed.
> 
> I agree. I can't remember the last time I did a "apt-get install apache"
> an I still had a running webserver. I would think this is mostly due to
> the maintainer having too much work on his hands and so not being able to
> finetune the upgrade process.
> 
> Apache is a very popular package and so IMHO it would be good if it'd be
> in a perfect shape.

So I can count you in as a volunteer?

Thanks,
Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: A language by any other name

[Gustavo Noronha Silva]

Em 13 Sep 2001 20:06:22 +0200
Federico Di Gregorio <[EMAIL PROTECTED]> escreveu:

> > nah that's not it... if I understand it correctly, "united states"
> > would map to es_US and "england" would map to en_EN(UK?)...
> 
> my english is really that poor? i meant that if french maps to the fr_FR
no, your english is not poor, yes I really meant that... you said 
"french" maps to "fr_FR" but what was proposed was not this... the proposal
was "france" maps to "fr_FR"...

> locale and so on i don't see why there are problems mapping english to
> en_EN. ok, english is _also_ how the americans call their language, but
> i think it was called english even before Colombo, right? 
that would confuse people...

[]s!

-- 
Gustavo Noronha Silva - kov 
**
|  .''`.  | Debian GNU/Linux: |
| : :'  : | Debian BR...:  |
| `. `'`  |  Be Happy! Be FREE!  |
|   `-| "Think globally, act locally!"   |
**

Re: proposal for an Apache (web server) task force

[Ardo van Rangelrooij]

Martin F Krafft ([EMAIL PROTECTED]) wrote:
> also sprach Ardo van Rangelrooij (on Thu, 13 Sep 2001 08:42:44AM)
> > I would like to propose to form an Apache (web server) task force to
> > maintain the Apache packages currently maintained by Johnie Ingram
> > (netgod) (and potentially related packages if the need arises).
> 
> count me in.

Excellent!

There are a couple of things we can start with:

 - filing a request for the mailing list
 - putting together a web page similar to that of the X Strike Force
   with a link to the packages and their bug lists, a todo list, etc.
 - an NMU of the packages with an Uploaders field in the control file
   (see the thread about multiple maintainers per package on this list)
 - setting up a CVS archive somewhere 

If I interpret all the responses correctly there're four people on the
task force.  I propose we all go over the bug list and make an inventory
in terms of difficulty to solve.  That should give us a better idea of
the status and how much we can do before the freeze.

> > I also propose to set up a mailing list for this.
> 
> i can give you one easily. applying at lists.debian.org takes ages!
> how about [EMAIL PROTECTED] :)
> 
> martin;  (greetings from the heart of the sun.)
>   \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]

Well, I would prefer a debian mailing list since it's rather debian
related but thanks anyway for the offer.  Until the list is created
we can use debian-devel I guess.

Thanks,
Ardo
-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: mirror-operators please help

[Junichi Uekawa]

Martin F Krafft <[EMAIL PROTECTED]> immo vero scripsit

> i know this much and made it work before. however, i have the entire
> debian tree mirrored and thus need to use apt-ftparchive. but its
> syntax is overwhelming.

How about having a mirror script which mirrors intelligently,
and updates Packages.gz after things have been updated ?



regards,
junichi


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