Re: feedback on jablicator: package choice sharing tool

[Dmitriy]

On Mon, Sep 03, 2001 at 09:07:46PM -0700, Jeff Breidenbach wrote:
> 
> Hi all,
> 
> I just wrote "jablicator" [1], which is a tool to help novice Debian
> administrators leech off of more experienced administrators.
> Specifically in the area of picking an appropriate set of packages to
> install from Debian's untold thousands. I appreciate any feedback or
> suggestions, and particularly technical feedback or comments from
> those involved with the infamous "task-*" packages and their
> successors.
> 
> I'm sending this mail to debian-devel because this program actually
> creates packages, and from a certain perspective, subdistributions.
> This is traditionally the realm of Debian developers, so I want
> developer feedback first. Eventually I expect tools like this to
> somewhat blur the line between users and developers.
> 
> 
> 0: General reactions? Would anyone consider using this tool?
> 
> 1: Does some other Debian package already have this functionality?
> 
> 2: Any technical hiccups? Am I doing the right thing with the output,
>when creating "dists" and "pool"?
> 
> 3: What's a better name? "deblicator" and "apt-share" have been
>suggested so far.
> 
> 4: Do some gurus with well thought out or specialized package
>collections want to share the fruits of their labor by posting
>their jablicator output?
> 
> Thanks,
> Jeff
> 
> [1] It's in incoming http://incoming.debian.org or maybe already
> in sid by the time you read this. If you try it out, make sure 
> to get version 1.0-3 or later.
> 
Ugh My clock appers to run right (date shows correct TZ and local
time) , but I get:

tar: ./postinst: time stamp 2001-09-04 20:53:08 is 81768 s in the
future
tar: ./prerm: time stamp 2001-09-04 20:53:09 is 81769 s in the future
tar: ./md5sums: time stamp 2001-09-04 20:53:14 is 81774 s in the
future
tar: ./control: time stamp 2001-09-04 20:53:13 is 81773 s in the
future

It works fine, but I just thought I'd point that out (v. 1.0-3 BTW)


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

-- 
GPG key-id: 1024D/5BE3DCFD Dmitriy
CCAB 5F17 A099 9E43 1DBE  295C 9A21 2F1C 5BE3 DCFD

Free Dmitry Sklyarov!  http://www.freesklyarov.org


pgpo4qeupHmfV.pgp
Description: PGP signature

Re: feedback on jablicator: package choice sharing tool

[Glenn McGrath]

> 3: What's a better name? "deblicator" and "apt-share" have been
>suggested so far.
> 

I like deblicator due to its originality, and its not really a part of apt
is it ?


Glenn

Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'

[tluxt]

Starting from a (IIRC) rather basic potato system, I did (essentially):
change sources.list to point to testing
apt-get update
apt-get dist-upgrade

I got the following error after much stuff had installed:


Preparing to replace exim 3.12-10 (using .../archives/exim_3.31-1_i386.deb) ...
mv: cannot create regular file `/etc/exim/exim.conf': No such file or directory
dpkg: error processing /var/cache/apt/archives/exim_3.31-1_i386.deb (--unpack):
 subprocess pre-installation script returned error exit status 1
Starting MTA: exim.
Preparing to replace gettext-base 0.10.35-13 (using 
.../gettext-base_0.10.39-2_i386.deb) ...
Unpacking replacement gettext-base ...
Selecting previously deselected package groff-base.
Unpacking groff-base (from .../groff-base_1.17-3_i386.deb) ...
Moving /etc/tmac.man.local to /etc/groff/man.local.
Replacing files in old package groff ...
Errors were encountered while processing:
 /var/cache/apt/archives/exim_3.31-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
debian:/var/cache/apt#


In fact, the directory:
/etc/exim
does not exist.

I found
Subject: Re: dist-upgrade from stable to testing
http://lists.debian.org/debian-user/2001/debian-user-200108/msg02377.html
Date: Tue, 14 Aug 2001 08:35:28 -0500

Which said:

"
On Tue, Aug 14, 2001 at 12:20:57AM -0600, Phil Reardon wrote:
> On Monday 13 August 2001 11:36 pm, John Galt wrote:
> > mkdir /etc/exim then rerun apt-get dist-upgrade...  You won't have to
> > re-download the 166M, BTW.
> >
> > On Mon, 13 Aug 2001, Phil Reardon wrote:
> > >After apt-get update, apt-get dist-upgrade to testing, I got a successful
> > >download of 166 MB. But during the install/config, I saw this message:
> > >
> > >mv: cannot create regjular file '/etc/exim/exim.conf' ;  No such file or
> > >directory.
> > > .(stuff removed)
> 
> Thanks, John:
> 
> I tried creating the exim directory and even did a touch exim.conf there. 
> Then I did apt-get dist-upgrade again and it complained of unmet dependencies 
> and recommended apt-get -f install.  I did that too, and then things 
> proceeded okay.  I think I have Woody now!

This is also fixed in exim 3.32-1 in unstable, by the way.

exim (3.32-1) unstable; urgency=low

  [...]
  * debian/preinst: create /etc/exim before moving exim.conf (Closes:
#106659, #107657)
  [...]

 -- Mark Baker <[EMAIL PROTECTED]>  Wed,  8 Aug 2001 23:34:04 +0100

-- 
Colin Watson  [EMAIL PROTECTED]
"

In my /v/c/a/a I have:
@debian:/var/cache/apt/archives$ ls -al exim*
-rwxr-xr-x1 root root   650710 Jun  9 19:45 exim_3.12-10.1_i386.deb
-rwxr-xr-x1 root root   650572 May  2  2000 exim_3.12-10_i386.deb
-rwxr-xr-x1 root root   746472 Apr 11 17:28 exim_3.22-4_i386.deb
-rwxr-xr-x1 root root   747228 Jul 18 16:50 exim_3.31-1_i386.deb
-rwxr-xr-x1 root root   748988 Aug 14 17:30 exim_3.32-2_i386.deb
@debian:/mnt/hda11/var/cache/apt/archives$

My Question:
I don't know enough about Debian to know if this is a bug - would you 
please enlighten me?
The msg from CW said, on 8/14, that exim 3.32-1 fixes this.
I have exim 3.32-2 in my cache.
Q: Since it is over 2 weeks past 8/14, shouldn't my dist-upgrade
be using 3.32, which, presumably, has this bug fixed?
Why is dist-upgrade using 3.31-1?

Now, I did try a dist-upgrade to unstable a week or two ago, and perhaps
that's how 3.32-2 got there. (That dist-upgrade was on another system.)

I thought that after less than about 2 weeks the packages migrate from unstable 
to testing.  So, that should be done now, therefore.


Also, if this _is_ a bug that's not submitted yet, I don't know enough
yet about the bug tracking system, etc., to properly submit this.  
So, I hope _you_, dear reader, will submit this bug to the system,
if it is indeed a current, non-submitted bug.

Thanks! :)


__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: CUPS

[Michael Meskes]

On Mon, Sep 03, 2001 at 07:48:54PM +0300, Ari Makela wrote:
> No, it can be done by hand. With cups one really has to do one's
> RTFM. If one does, it'll work fine.

I used to tell everyone we need no fancy GUI for configuration as our
postinst scripts take care of all that. All you need to know is
dpkg-reconfigure if you want to change anything.

That probably won't work with cups.

> IMAO: development list shouldn't be a help desk. And thus maybe I
> shouldn't be writing this email.

Or else you should read my original mail. :-)

The problem is not RTFM since all works well with the default ppds, but a)
the interaction with cupsomatic-ppd and b) the missing configuration in
postints. WHere does this belong if not into -devel?

Michael

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

Re: isync vs mailsync

[Colin Walters]

Brian May <[EMAIL PROTECTED]> writes:

> In my search for a "perfect" offline IMAP client(TM) I have looked
> at isync vs mailsync.

What's wrong with Gnus?  Perhaps with the Agent?  I admit I've never
tried disconnected IMAP with it, but I see people talking about it on
the ding lists.

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

[Radovan Garabik]

On Tue, Sep 04, 2001 at 11:20:33AM +1000, Brian May wrote:
> > "Radovan" == Radovan Garabik <[EMAIL PROTECTED]> writes:

> Radovan> format is important but whoever designes his software to
> Radovan> display 8/1/63 should be shot, locale or no locale.
> 
> GNUmeric doesn't display the date in this format (it is up to the user
> to pick what format is used), BUT it does require entering dates in
> MM/DD/ format.
> 
> - unless of course you have changed the locale...

I would file a bug against gnumeric in this case.
This is broken behaviour. Does in behave the same
when you import data from text file? Then it
is even more broken.

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

Format: field in .dsc files

[Glenn McGrath]

Hi, there are a few .dsc files that dont have a Format: field, the few
that i found all had a Standards-Version: 3.0.1, but some packages of that
same Standards-Version do have a Format: field in the .dsc file, i tried
to find more details of theis field.

man dpkg-source refers to it being described in the packaging manual which
is obsolete, parts of the packaging manual have been moved to policy.

>From the policy manual,

C.3 Source packages as archives 

Debian source control file - .dsc
 This file contains a series of fields, identified and separated just like
the fields in the control file of a binary package. The fields are listed
below; their syntax is described above, in Control files and their fields
(from old Packaging Manual), Appendix D. 
 Source 
Version 
Maintainer 
Binary 
Architecture 
Build-Depends et al. (source package interrelationships) 
Standards-Version 
Files 


There is a link to appendix D, where i find mention of _a_ Format: field

D.2.17 Format 

 This field occurs in .changes files, and specifies a format revision for
the file. The format described here is version 1.5. The syntax of the
format value is the same as that of a package version number except that
no epoch or Debian revision is allowed - see Version numbering, Chapter 4.




But the Format: field of the .changes file mustnt caryover to the .dsc
file becasue my last upload had .changes;Format: 1.7 and .dsc;Format:1.0

So was the Format field in the .dsc option at one stage, is it still
optional, is it documented ?

This also makes me wonder, when a new release is made do we specify that
all packages must be newer than a specific standards version, or do we let
all the cruft in ?

Confused


Glenn

Re: Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'

[Laurent de Segur]

Hi all,

Actually, from stable to testing, I got a blocker with gnome-help package.
The install wouldn't let me go any further and I had to remove this
particular package from the selection just to be able to finish it up. Then
later on, I installed it individually with no problem. The error was the
same type as below.

Laurent

on 9/3/01 11:01 PM, tluxt at [EMAIL PROTECTED] wrote:

> Starting from a (IIRC) rather basic potato system, I did (essentially):
> change sources.list to point to testing
> apt-get update
> apt-get dist-upgrade
> 
> I got the following error after much stuff had installed:
> 
> 
> Preparing to replace exim 3.12-10 (using .../archives/exim_3.31-1_i386.deb)
> ...
> mv: cannot create regular file `/etc/exim/exim.conf': No such file or
> directory
> dpkg: error processing /var/cache/apt/archives/exim_3.31-1_i386.deb
> (--unpack):
> subprocess pre-installation script returned error exit status 1
> Starting MTA: exim.
> Preparing to replace gettext-base 0.10.35-13 (using
> .../gettext-base_0.10.39-2_i386.deb) ...
> Unpacking replacement gettext-base ...
> Selecting previously deselected package groff-base.
> Unpacking groff-base (from .../groff-base_1.17-3_i386.deb) ...
> Moving /etc/tmac.man.local to /etc/groff/man.local.
> Replacing files in old package groff ...
> Errors were encountered while processing:
> /var/cache/apt/archives/exim_3.31-1_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> debian:/var/cache/apt#
> 
> 
> In fact, the directory:
> /etc/exim
> does not exist.
> 
> I found
> Subject: Re: dist-upgrade from stable to testing
> http://lists.debian.org/debian-user/2001/debian-user-200108/msg02377.html
> Date: Tue, 14 Aug 2001 08:35:28 -0500
> 
> Which said:
> 
> "
> On Tue, Aug 14, 2001 at 12:20:57AM -0600, Phil Reardon wrote:
>> On Monday 13 August 2001 11:36 pm, John Galt wrote:
>>> mkdir /etc/exim then rerun apt-get dist-upgrade...  You won't have to
>>> re-download the 166M, BTW.
>>> 
>>> On Mon, 13 Aug 2001, Phil Reardon wrote:
 After apt-get update, apt-get dist-upgrade to testing, I got a successful
 download of 166 MB. But during the install/config, I saw this message:
 
 mv: cannot create regjular file '/etc/exim/exim.conf' ;  No such file or
 directory.
 .(stuff removed)
>> 
>> Thanks, John:
>> 
>> I tried creating the exim directory and even did a touch exim.conf there.
>> Then I did apt-get dist-upgrade again and it complained of unmet dependencies
>> and recommended apt-get -f install.  I did that too, and then things
>> proceeded okay.  I think I have Woody now!
> 
> This is also fixed in exim 3.32-1 in unstable, by the way.
> 
> exim (3.32-1) unstable; urgency=low
> 
> [...]
> * debian/preinst: create /etc/exim before moving exim.conf (Closes:
> #106659, #107657)
> [...]
> 
> -- Mark Baker <[EMAIL PROTECTED]>  Wed,  8 Aug 2001 23:34:04 +0100

Re: Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'

[Christian Marillat]

 "LdS" == Laurent de Segur <[EMAIL PROTECTED]> writes:

> Hi all,

Hi,

> Actually, from stable to testing, I got a blocker with gnome-help package.
> The install wouldn't let me go any further and I had to remove this
> particular package from the selection just to be able to finish it up. Then

Which problem with gnome-help ?

Christian

Bug#111151: ITP: xfm -- X file and application manager

[Branden Robinson]

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

* Package name: xfm
  Version : 1.4.3
  Upstream Author : Simon Marlow, Albert Graef, Till Straumann
* URL : http://www.musikwissenschaft.uni-mainz.de/~ag/xfm/
* License : GPL, plus portions that are MIT'ish
  Description : X file and application manager

Source: xfm
Section: utils
Priority: optional
Maintainer: Branden Robinson <[EMAIL PROTECTED]>
Build-Depends: xlibs-dev, xaw3dg-dev, debhelper (>= 3.0.0)
Standards-Version: 3.5.6

Package: xfm
Architecture: any
Depends: ${shlibs:Depends}
Description: X file and application manager
 Xfm is an file and application manager program for the X Window System, based
 on the Xaw3d widget set.  It provides virtually all of the features that you
 would expect in a file manager; move around your directory tree in multiple
 windows, move, copy or delete files, and launch programs with simple mouse
 operations.  Directory displays are updated automatically in regular
 intervals when the contents of the directory change.  The integrated
 application manager provides a kind of "shelf" onto which you can place your
 favorite applications, as well as the files and directories you are currently
 working with.  It also allows you to access different groups of applications
 and files.  User-definable file types let you specify a command to be
 executed when double-clicking on a file or dropping other files onto it.
 Last not least, xfm can automatically mount and unmount special devices like
 floppies as you open and close the corresponding directories (mount points).

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux apocalypse 2.4.7 #1 Sun Jul 22 19:11:47 EST 2001 i686
Locale: LANG=C, LC_CTYPE=en_US.iso-8859-1

-- 
G. Branden Robinson| No math genius, eh?  Then perhaps
Debian GNU/Linux   | you could explain to me where you
[EMAIL PROTECTED]  | got these...   PENROSE TILES!
http://www.deadbeast.net/~branden/ | -- Stephen R. Notley

Re: wnpp still down

[Christian Marillat]

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

>>> Nicolas SABOURET <[EMAIL PROTECTED]> writes:
>> Just to inform that the web page devel/wnpp still doesn't work. I don't
>> know wether sby is dealing with that already or not.

>  The WNPP pages use the LDAP frontend to the BTS, which has been
>  affected by a small change in the BTS "database"[0].  Last weekend I
>  mailed Ben Collins a pseudo patch to fix the affected script but I
>  think he's on vacation as I haven't got any sort of ack.

>  [0] A directory is no longer a directory but a symlink

Today the WNPP is still broken. Somebody can do something ?

I want to check the WNPP before doing ITP.

Christian

Re: feedback on jablicator: package choice sharing tool

[Nick Phillips]

On Mon, Sep 03, 2001 at 09:07:46PM -0700, Jeff Breidenbach wrote:

> I just wrote "jablicator" [1], which is a tool to help novice Debian
> administrators leech off of more experienced administrators.

> 0: General reactions? Would anyone consider using this tool?
> 
> 1: Does some other Debian package already have this functionality?

The easy way to do it is to use dpkg --get-selections to create a text
file package list, and dpkg --set-selections to set it, before doing
an appropriate apt/dpkg command to update to the selected list (apt-get
dselect-upgrade?).

Cool name, though. Don't change that, whatever else you may end up changing.

It'd be good to be able to create something like a commented version of
the output from dpkg --get-selections so that you could say why you've
purged lynx and added w3m-ssl, for example.



Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
You can create your own opportunities this week.  Blackmail a senior executive.

Re: Making better use of multiple maintainers

[Raphael Hertzog]

Le Sun, Sep 02, 2001 at 07:55:43PM +0200, Martin Michlmayr écrivait:
> I think we should try to implement that scheme at least for packages in
> base and standard... but why not go ahead and try to do it for all
> packages?

Yes, this is a long term thing to do ... it will be quite a logical
step once we have everything, there's the support for it in katie
and dpkg (at least there'll be shortly). The only thing that is
missing and that is *required* is the integration with the BTS. 

There's several things that have to be done :
- be able to subscribe other people to a package bug list (in this case
  the people listed in the Uploaders field), there should be some
  automation here, otherwise beeing in the Uploader field won't change
  anything as the backup maintainer won't know of any bug
- when doing a "per maintainer" lookup
  (http://bugs.debian.org/[EMAIL PROTECTED] for example) the page
  should also list the bugs on package where I am an "Uploader", probably
  separated from my very own packages, or maybe just provide a BIG link
  to the page listing those ...
- the Uploader should also be listed on "per package" page ... so that
  people may know who to contact when the main maintainer
  doesn't respond
- then we need to update the @packages.debian.org alias to list
  all maintainer (main and backup).
  
> would get more attention and more bugs fixed.  The BTS allows more
> than one person to get bug reports for a specific package (through an
> overwrite file) and in the future it will be possible to subscribe to
> individual bugs.

I'm eagerly waiting for this one ... :) as long as the subscription is not
only per bug-report but also per source-package and per binary-package.

> Debian is growing quite dramatically in size but I'd love to see more
> manpower devoted to existing packages instead of (or in addition to) new
> packages.

/me too

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

Re: (my) summary about translated description with dpkg (still RFC)

[Chris Halls]

On Thu, Aug 30, 2001 at 09:58:59AM +0200, Martin Quinson wrote:
 
> The more controversial point of our proposal is that we where planing
> to centralize the translation in a way that keeps the maintainer out
> of the loop. But it's not the key point, it's an add-on which ease the
> work of translators. Each package can still provide the translation
> and be 'self contained'. For the MIA maintainers, or the ones not
> willing to interfere with the translation stuff, the po file providing
> the translation is in a translator-maintained package. There is no
> dependency between the formal package and the translation one. The
> second enhance the first when installed. When no translation is
> installed, the system will be the same than it is now, and will
> display the description in good old english.

I've got a suggestion regarding integrating the translations into the
packages themselves.  Instead of having package translations which the
user has to install and are not included in the actual .deb, what about
generating and using package translation -dev packages in the same way
that e.g.  autotools-dev is used to automatically integrate files
(config.guess,sub) that are maintained elsewhere into packages as they are
built by the maintainer or buildds?

The package translations would be used to generate -dev packages that
would be installed into the archive along with all the other tools that a
developer (not a user) needs.  Maybe the package translations could be
split by something like archive section to keep the size down.  The
developer would be able to keep these 'source' translations up to date
using existing infrastructure (apt-get update etc.)  

At package build time, a dh_ helper script could be used to integrate the
translations into the newly built .deb, which is uploaded to incoming as
usual.  You now have translated descriptions integrated into the .debs,
and it is possible to generate the Packages. files for use by the
modified dpkg/dselect as was originally suggested, except that the
translations are coming from the .debs instead of a single server.

Now this doesn't solve the possible bloat issue of a package containing
multiple languages - but that's something that needs to be solved along
with all the other types of translations that are put into a .deb (debconf
templates, program messages etc.).  But at least the package translation
case is no longer such a special case, with a completely different way of
handling it.  And the user's machine no longer needs to do .po file
merging from a central source, since the translations are distributed
along with the .deb in every case, not just the case that the maintainer
wishes to do the translation themseleves or it comes from another source.

Putting the maintainer back in the loop does have a cost - the time taken
for them to re-upload the package once the translation has been integrated,
and the resulting bandwidth and cost to buildds etc.  But maybe that's a
problem that should be solved along with the other translation areas that
have the same issues in the .debs?  At least by automating the translation
integration, you make the loop a lot smaller.  And another advantage: A
user building a package themselves from the source packages ends up with a
.deb which includes the translated descriptions.

Would would need to be done to implement this?
 - Translation server needs to generate packages with translations that
   are put into the archives
 - helper scripts modification to integrate translations into package
   build process
 - the scripts to generate Packages files from .debs need to also generate
   Packages. files
 - dpkg/delect patch to be applied

Chris

Re: wnpp still down

[Andres Seco Hernandez]

I think bugs.debian.org/wnpp reports correctly the list of packages.

El 04 Sep 2001 a las 10:11AM +0200, Christian Marillat escribio:
>  "MEM" == Marcelo E Magallon <[EMAIL PROTECTED]> writes:
> 
> >>> Nicolas SABOURET <[EMAIL PROTECTED]> writes:
> >> Just to inform that the web page devel/wnpp still doesn't work. I don't
> >> know wether sby is dealing with that already or not.
> 
> >  The WNPP pages use the LDAP frontend to the BTS, which has been
> >  affected by a small change in the BTS "database"[0].  Last weekend I
> >  mailed Ben Collins a pseudo patch to fix the affected script but I
> >  think he's on vacation as I haven't got any sort of ack.
> 
> >  [0] A directory is no longer a directory but a symlink
> 
> Today the WNPP is still broken. Somebody can do something ?
> 
> I want to check the WNPP before doing ITP.
> 
> Christian
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Andres Seco Hernandez- [EMAIL PROTECTED]
MCP ID 445900 - http://andressh.alamin.org
GnuPG public information:  pub  1024D/3A48C934
E61C 08A9 EBC8 12E4 F363  E359 EDAC BE0B 3A48 C934
--
Alamin GSM SMS Gateway   -   http://www.alamin.org
Debian GNU/Linux -   http://www.debian.org
Grupo de Usuarios de GNU/Linux  de  Guadalajara  y
alrededores  -  http://gulalcarria.sourceforge.net
--


pgp9sziibxhED.pgp
Description: PGP signature

Re: How many people need locales?

[Raphael Hertzog]

Le Mon, Sep 03, 2001 at 12:03:19PM +0200, Santiago Vila écrivait:
> Ooops! Sorry. The bug I refer is really #110980 (I happen to submit
> two i18n-related bugs the same day and confused them).
> 
> The bug basically says "/etc/locale.gen should not be a conffile
> because most people will need to modify it" but Ben does not agree
> that people using locales is "most people".

I read the discussion, it's a shame. I usually don't like your critics
Santiago, howevere here you're right. Ben, it's a pity that we have to
prove to you that people *use* locales. It's so self-evident !

As for facts (not really up to date but anyway) :
http://lists.debian.org/stats/

debian-user : 2120 subscribers

sum of debian-{otherlanguage}: 3355

I have a counted the biggest list in each language (ie i have not added
debian-chinese, debian-chinese-big5 and debian-chinese-gb, i just used
the biggest figure from all three).

So there's at least more than 60% of our users who are non-english
and who use locales ... and this can only increase when Debian gets
more and more non-en friendly (ie more localized).

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

Re: wnpp still down

[Christian Marillat]

 "ASH" == Andres Seco Hernandez <[EMAIL PROTECTED]> writes:

> I think bugs.debian.org/wnpp reports correctly the list of packages.

Yes, but a search in wnpp pages was more easy.

Christian

Re: Intent for NMU of python-2.1 packages

[Jérôme Marant]

Matthias Klose <[EMAIL PROTECTED]> writes:

...
> in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0
> maintainer) has put experimental packages at
> http://people.debian.org/~flight/python and was asking for help
> regarding the packaging (20010801). Jérôme Marant answered (20010803),
> but since this date nothing happened. I intend to do a NMU of
> python2.1 based on Gregor's experimental packages that can coexist
...

Do you know what happened to Gregor since 20010801? I periodicaly
had a look to his page at debian.org but nothing happened since then.
Did you contact him? Do you have his agreement for the NMU?
What do you plan to do about the idle package?

Thanks.

Cheers,

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

Bug#111158: Kernel 2.4.5+ network timeouts

[Francesco P. Lovergine]

Package: kernel-image-2.4
Version: N/A
Severity: important

This is an issue for the kernel folk. Just verify 

telnet www.compaq.com 80

It will not respond with all kernel 2.4.5+ (timeout)
I used my workstation at work with 2.4.8,9 and several machines of 
the Project. It seems ok with 2.4.2 or 2.4.4 (eg auric et al.)
This seems a problem with routing filtering policies (icmp filtering
I think) used by some sites. 
Use debussy.debian.org to see the problem.
Compaq is only one of sites with the same problem.
It does not seem a problem due to PMD (path mtu discovery): 

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

does not solve the problem.

Ideas?

-- 
Francesco P. Lovergine

Re: ITP: webreport

[Eric Van Buggenhaut]

On Mon, Sep 03, 2001 at 11:13:16PM +0200, Martin F Krafft wrote:
> first of all, is this the right way to do ITP's? i just simply sent a
> mail...
> 
> second, and mainly, i would like to package WebReport for debian. it
> may be found at http://www.inter7.com/webreport/ and i could not find
> it in the current dist, and wnpp system seems down on debian.org.
> 
> anyway, web report is a web log statistics reporting program
> especially designed for virtual hosting sites. It is also very useful
> for single hosting sites. The main difference between web report and
> other statistics programs is a configuration file which allows for
> easy manipulation of the features.
> 
> please let me know whether this is the right way.
> 
> unless there are objections, i would like to start packaging...
> 

Please file a ITP bug against virtual package wnpp. See

http://www.debian.org/devel/wnpp/prospective


Then start packaging and find a sponsor to upload it.


> martin;  (greetings from the heart of the sun.)
>   \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
> -- 
> weekend, where are you?
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 
> 

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

Bug#111167: ITP: loop-aes

[Robert van der Meulen]

Package: wnpp
Severity: wishlist

http://loop-aes.sourceforge.net/loop-AES-v1.4d.tar.bz2

>From the readme:
"This package provides loadable Linux kernel module (loop.o) that has AES
cipher built-in. The AES cipher can be used to encrypt local file systems
and disk partitions."

Before you ask about the difference(s) between the kerneli patch:

"This package does *not* modify your kernel in any way, so you are free to
use kernels of your choice, with or without cool patches. This package works
with all past, present, and future 2.2 and 2.0 kernels, and with recent 2.4
kernels (2.4.3 or later)."

License is GPL.

I have not decided on delivering binary-only modules for this yet.

Greets,
Robert
-- 
  Linux Generation
   encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
Mijn muck is ook wit!

Re: Bug#111158: Kernel 2.4.5+ network timeouts

[Christian Surchi]

On Tue, Sep 04, 2001 at 10:42:43AM +0200, Francesco P. Lovergine wrote:
> Package: kernel-image-2.4
> Version: N/A
> Severity: important
> 
> This is an issue for the kernel folk. Just verify 
> 
> telnet www.compaq.com 80
> 
> It will not respond with all kernel 2.4.5+ (timeout)
> I used my workstation at work with 2.4.8,9 and several machines of 
> the Project. It seems ok with 2.4.2 or 2.4.4 (eg auric et al.)
> This seems a problem with routing filtering policies (icmp filtering
> I think) used by some sites. 
> Use debussy.debian.org to see the problem.
> Compaq is only one of sites with the same problem.
> It does not seem a problem due to PMD (path mtu discovery): 
> 
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> 
> does not solve the problem.
> 
> Ideas?

Is it the ECN question discussed in these days on -devel?

See #110875 and
http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg00041.html

-- 
Christian Surchi   |   [EMAIL PROTECTED]   |   [EMAIL PROTECTED]
FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org
The mature bohemian is one whose woman works full time.

Re: Two sets of binary packages from one source package?

[Jules Bean]

On Mon, Sep 03, 2001 at 05:00:58PM -0400, Colin Walters wrote:
> James LewisMoss <[EMAIL PROTECTED]> writes:
> 
> > So my first inclination is just to stop producing the gnome versions,
> > but several users have requested that I not do so.
> 
> If the GTK+/GNOME version of XEmacs isn't really usable, then it would
> probably make sense to stop producing those packages until woody is
> released.

Or upload GTK+/GNOME versions to some other location,
e.g. experimental, or your people.debian.org homepage.

Jules

Re: isync vs mailsync

[T.Pospisek's MailLists]

On 4 Sep 2001, Brian May wrote:

[...]
> MAILSYNC

Has been in use here for 9 months without a flaw...

>
> PROS:
[...]
>  - can delete deleted messages (not tested).

...this feature works here.

>  - can create and delete folders (not tested).

Dito.

[...]
> CONS:
>
>  - upstream author seems to be really anti-maildir, although maildir
>  patches have been included in Debian version.

Just to clarify: you're talking about Mark Crispin the author of the
UW-suite, which includes c-client, a mail-access library.

The upstream author of mailsync is Tim Culver, who's not oposed to any
such things :-)

On a sidenote:

  I have been submerged (which nearly periodically happens in fact) by
  professional work the last two weeks so sorry you haven't got any reply
  from me yet to your reports (thanks!).

  The same is true for the upstream author. He's been looking for people
  who'd maintain (integrate patches, extend it etc.) mailsync. So if you,
  or anybody who's interested, wants to work on mailsync, add features,
  remove bugs or help maintaining the Debian packge - you are more then
  wellcome.

*t


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

Re: (my) summary about translated description with dpkg (still RFC)

[Michael Bramer]

On Tue, Sep 04, 2001 at 10:39:00AM +0200, Chris Halls wrote:
> On Thu, Aug 30, 2001 at 09:58:59AM +0200, Martin Quinson wrote:
>  
> > The more controversial point of our proposal is that we where planing
> > to centralize the translation in a way that keeps the maintainer out
> > of the loop. But it's not the key point, it's an add-on which ease the
> > work of translators. Each package can still provide the translation
> > and be 'self contained'. For the MIA maintainers, or the ones not
> > willing to interfere with the translation stuff, the po file providing
> > the translation is in a translator-maintained package. There is no
> > dependency between the formal package and the translation one. The
> > second enhance the first when installed. When no translation is
> > installed, the system will be the same than it is now, and will
> > display the description in good old english.
> 
> I've got a suggestion regarding integrating the translations into the
> packages themselves.  Instead of having package translations which the
> user has to install and are not included in the actual .deb, what about
> generating and using package translation -dev packages in the same way
> that e.g.  autotools-dev is used to automatically integrate files
> (config.guess,sub) that are maintained elsewhere into packages as they are
> built by the maintainer or buildds?

nice idea.

> At package build time, a dh_ helper script could be used to integrate the
> translations into the newly built .deb, which is uploaded to incoming as

How will the translated Description be stored in the deb Package?

> usual.  You now have translated descriptions integrated into the .debs,
> and it is possible to generate the Packages. files for use by the
> modified dpkg/dselect as was originally suggested, except that the
> translations are coming from the .debs instead of a single server.

Packages. are a hack.

What are Packages. file? Files with the English and the
translated Description? Only the translated Description? With a
Description or a Description- tag? With the other tags?

some cons:
 - apt-get don't know about the translation with this
 - if you will use some languages, you must download some Packages
   files with all the tags.
 - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size
   _without_ translation... 
 - you must patch apt in a whole
 - maybe we get outdates translations (like debconf)

> Now this doesn't solve the possible bloat issue of a package containing
> multiple languages - but that's something that needs to be solved along
> with all the other types of translations that are put into a .deb (debconf
> templates, program messages etc.).  But at least the package translation

the deb addone size it not the big problem. This is only 11-22 MBytes
(now) per languages.

> Would would need to be done to implement this?
>  - Translation server needs to generate packages with translations that
>are put into the archives

this is not a problem.

>  - helper scripts modification to integrate translations into package
>build process
>  - the scripts to generate Packages files from .debs need to also generate
>Packages. files

Packages. is not a real solution...

>  - dpkg/delect patch to be applied


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Free Software is like sex: You don't know what's it like until you've
tried it.


pgp7JCZ5ZNKAY.pgp
Description: PGP signature

Re: Bug#111158: Kernel 2.4.5+ network timeouts

[Francesco P. Lovergine]

On Tue, Sep 04, 2001 at 11:42:37AM +0200, Christian Surchi wrote:
> On Tue, Sep 04, 2001 at 10:42:43AM +0200, Francesco P. Lovergine wrote:
> > Package: kernel-image-2.4
> > Version: N/A
> > Severity: important
> > 
> > This is an issue for the kernel folk. Just verify 
> > 
> > telnet www.compaq.com 80
> > 
> > It will not respond with all kernel 2.4.5+ (timeout)
> > I used my workstation at work with 2.4.8,9 and several machines of 
> > the Project. It seems ok with 2.4.2 or 2.4.4 (eg auric et al.)
> > This seems a problem with routing filtering policies (icmp filtering
> > I think) used by some sites. 
> > Use debussy.debian.org to see the problem.
> > Compaq is only one of sites with the same problem.
> > It does not seem a problem due to PMD (path mtu discovery): 
> > 
> > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> > 
> > does not solve the problem.
> > 
> > Ideas?
> 
> Is it the ECN question discussed in these days on -devel?
> 
> See #110875 and
> http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg00041.html
> 

Ok, after some times with /proc/sys/net/ipv4/tcp_ecn set to 0,
it worked. Anyway I strongly suggest to modify this setting ASAP in
procps. Moreover this is required only for kernel 2.4.5+  (why?
Maybe it was turned on only after that release)
And www.compaq.com (maybe) is not a minor site...
And sometimes www.debian.org, too (due to BGP routing choices)

I missed the previous thread. This bug rep should be merged with 
110875  and others, maybe.  

-- 
Francesco P. Lovergine

Re: CUPS

[Tille, Andreas]

On Tue, 4 Sep 2001, Michael Meskes wrote:

> I used to tell everyone we need no fancy GUI for configuration as our
> postinst scripts take care of all that. All you need to know is
> dpkg-reconfigure if you want to change anything.
>
> That probably won't work with cups.
I´m really sure that debconf could be used for that purpose.  If you
look at a /etc/cups/printers.conf file you see quite simple
  Variable Value
pairs enclised in   brackets.  Really do not
see any reason why it should be impossible to use debconf to create
such a file.

By the way:  That lpadmin does not work seems to be a bug but a feature -
at least I had the same result as you. :-((
The web frontend worked for me after some fiddling around (not after
the plain install).

Moreover I´m missing some information how /etc/cups/ppds.dat is generated
and how I could add some local ppds to it.

Kind regards

   Andreas.

Bug#111173: ITP: cryptoapi

[Robert van der Meulen]

Package: wnpp
Severity: wishlist

http://cryptoapi.sourceforge.net/

|This is a repackaged distribution of the international crypto patch,
|with the aim to improve adoption of this package by not requiring to
|patch the kernel in order to be able to use the cryptoapi and the loop
|encrytion.
|
|License is GPL; Some parts are licensed trough the following license, which
|is free according to the DFSG:
|
|Permission is hereby granted, free of charge, to any person obtaining a
|copy of this software and associated documentation files (the
|"Software"), to deal in the Software without restriction, including
|without limitation the rights to use, copy, modify, merge, publish, dis-
|tribute, sublicense, and/or sell copies of the Software, and to permit
|persons to whom the Software is furnished to do so, subject to the fol-
|lowing conditions:
|
|The above copyright notice and this permission notice shall be included
|in all copies or substantial portions of the Software.
|
|THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL-
|ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
|SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL-
|ITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|IN THE SOFTWARE.
|
|Except as contained in this notice, the name of the authors shall
|not be used in advertising or otherwise to promote the sale, use or
|other dealings in this Software without prior written authorization from
|the authors.


Note: This means i will probably drop the 'kernel-patch-int' package, which
is the normal 'international crypto patch'.

-- 
  Linux Generation
   encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
  Laat je in ieder geval nooit imponeren door een hard blaffende advocaat.

Re: CUPS

[Christian Kurz]

On 01-09-03 Michael Meskes wrote:
> On Mon, Sep 03, 2001 at 11:16:31AM -0500, Dimitri Maziuk wrote:
> > Probably because you're supposed to use a gooey web browser to add
> > a printer... a bit much for a postinst script. 
 
> Not exactly. The way I read the docs you can use lpadmin from the
> commandline to add a printer. In fact it works for the default deskjet ppd.

Well, that's also a possible method for adding a printer. Do you get any
error messages then on the console or in the logfiles beneath
/var/log/cups? 

> > WTF is cupsomatic-ppd anyway? Go to http://localhost:631, add _a_ 
> > printer (say, call it foobar), get a PPD for your printer and copy 
> > it to /etc/cups/ppd/foobar.ppd. You can then use web frontend to 
> > configure things, duplex printing, watermark etc. Works for me.
 
> But that's a hack and not a real configuration option. 

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

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


pgpy7cgCc0Ckz.pgp
Description: PGP signature

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

[T.Pospisek's MailLists]

Btw:

> http://melkor.dnp.fmph.uniba.sk/~garabik/debian-utf8/HOWTO

Does not serve any pages to me - it's pingable though. If you've got
problems with that server you could put the HOWTO on the debian servers or
if that's a problem I'd gladly put it up at our site.

*t


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

Re: Format: field in .dsc files

[Wichert Akkerman]

Previously Glenn McGrath wrote:
> Hi, there are a few .dsc files that dont have a Format: field, the few
> that i found all had a Standards-Version: 3.0.1, but some packages of that
> same Standards-Version do have a Format: field in the .dsc file, i tried
> to find more details of theis field.

It's not documented (in any released document anyway), but was added to
the dpkg code about a year ago since dsc files didn't have it before.
Since nothing has changed it is still at format 1.0. You could have
gotten that info frmo the dpkg changelog :)

> There is a link to appendix D, where i find mention of _a_ Format: field

That's for a .changes file, which has a different format indeed.

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: Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'

[Colin Watson]

(Mail-Followup-To: set to -user only. I'd also appreciate not being
directly cc'ed on your questions; I read both -user and -devel, so I got
three copies of this!)

On Mon, Sep 03, 2001 at 11:01:56PM -0700, tluxt wrote:
> In fact, the directory:
> /etc/exim
> does not exist.

You can create it yourself, as a workaround for now.

> In my /v/c/a/a I have:
> @debian:/var/cache/apt/archives$ ls -al exim*
> -rwxr-xr-x1 root root   650710 Jun  9 19:45 
> exim_3.12-10.1_i386.deb
> -rwxr-xr-x1 root root   650572 May  2  2000 exim_3.12-10_i386.deb
> -rwxr-xr-x1 root root   746472 Apr 11 17:28 exim_3.22-4_i386.deb
> -rwxr-xr-x1 root root   747228 Jul 18 16:50 exim_3.31-1_i386.deb
> -rwxr-xr-x1 root root   748988 Aug 14 17:30 exim_3.32-2_i386.deb
> @debian:/mnt/hda11/var/cache/apt/archives$
> 
> My Question:
> I don't know enough about Debian to know if this is a bug - would you 
> please enlighten me?
> The msg from CW said, on 8/14, that exim 3.32-1 fixes this.
> I have exim 3.32-2 in my cache.

You must have got that manually, or when apt was temporarily pointing at
unstable. apt uses whatever's in its package list, not necessarily the
contents of the cache.

> Q: Since it is over 2 weeks past 8/14, shouldn't my dist-upgrade
> be using 3.32, which, presumably, has this bug fixed?

It's not that simple. Testing is not just "two weeks behind unstable";
the algorithm is a lot more complex than that, and is more like:

  * Look at the 'urgency' field of the new package. low => 10 days,
medium => 5 days, high => 2 days, critical => 0 days. Wait that long
before doing anything else. If a new version of the package is
uploaded in the meantime, the count is reset.

  * Do all architectures in woody have the same version of the package
compiled for them? If not, give up.

  * Does the version in sid have more release-critical bugs than the
version in woody? If so, give up.

  * Experimentally upgrade the package in woody, together with all
packages that come from the same source package. After doing this,
does the number of packages that can't be installed at all in woody
due to broken dependencies go down, or at least stay the same? If
so, it's OK to upgrade the package. If not, the package has to wait.

I'm sure you can see now that you can't just say "wait two weeks, then
it should be in testing".

For the status of any individual package (plus some explanation), you
can look at http://ftp-master.debian.org/testing/. Some of it's a bit
cryptic, and you have to do more digging to find out exactly what's
going on sometimes, but it's there.

In the case of exim, update_excuses.html says:

 * exim 3.32-2 (currently 3.31-1) (important) (low)
  + Maintainer: Mark Baker <[EMAIL PROTECTED]>
  + exim uploaded 19 days ago, out of date by 9 days!
  + valid candidate (will be installed unless it's dependent upon
other buggy pkgs)

OK, so the first three steps above are passed. For the last, look at
update_output.txt, which says, down near the end:

  exim: alpha: eximon

This means that exim can't be upgraded because the eximon package would
be uninstallable on alpha if it did. Doing some more investigation, this
is because eximon depends on XFree86 4.1.0 on alpha, which hasn't got
into testing yet. However, it should be there in two days, if nothing
goes wrong in the meantime:

 * xfree86 4.1.0-4 (currently 4.0.3-4) (optional) (medium)
  + Maintainer: Branden Robinson <[EMAIL PROTECTED]>   
  + only 3/5 days old
  + not considered   

At that point, exim should be upgraded too, unless there are other
problems.

> Also, if this _is_ a bug that's not submitted yet, I don't know enough
> yet about the bug tracking system, etc., to properly submit this.  
> So, I hope _you_, dear reader, will submit this bug to the system,
> if it is indeed a current, non-submitted bug.

It's not a bug there's any point reporting. All that the exim maintainer
can do about it is refrain from uploading anything for two days; package
maintainers don't get to influence what's in testing directly. Anybody
else will tell you to wait for the testing bot to synchronize things.

Tracking bugs in the various distributions of Debian (potato, woody, and
sid) is an outstanding general problem. We have a crude system of tags
which helps a little, but really the best we can do is try to ensure
that the testing and unstable distributions are as close to each other
as possible.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Intent for NMU of python-2.1 packages

[Gregor Hoffleit]

* Jérôme Marant <[EMAIL PROTECTED]> [010904 11:18]:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> 
> ...
> > in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0
> > maintainer) has put experimental packages at
> > http://people.debian.org/~flight/python and was asking for help
> > regarding the packaging (20010801). Jérôme Marant answered (20010803),
> > but since this date nothing happened. I intend to do a NMU of
> > python2.1 based on Gregor's experimental packages that can coexist
> ...
> 
> Do you know what happened to Gregor since 20010801? I periodicaly
> had a look to his page at debian.org but nothing happened since then.
> Did you contact him? Do you have his agreement for the NMU?
> What do you plan to do about the idle package?

I'm still alive, I'm not lost ;-)

I'm just back from a ten day vacation after several weeks of intense
real world work, which will continue until the mid of September.


I'm +2 on uploading the python2.1 packages into unstable. All I wanted
to do was a little bit cosmetic cleanup, and (and that was the stumbling
point due to lack of time), some kind of documentation included in the
packages. Matthias, have you already done some work on these packages ?
Could you forward your modifications to me ?


Also, I'm +1 on uploading the python1.5 packages into unstable.

That means they would replace the existing python-* packages.

And that's the problem where I was stuck.

The dependencies of the current experimental python1.5 packages aren't
good enough to allow an easy upgrade from potato or earlier. AFAICS, I
would have to include empty transitional packages for almost all
python-* packages built from the python source. That's butt ugly IMHO.

Furthermore, it's my current impression that we have to orphan all
python-* packages in order to get a clean upgrade path!

There are many packages with broken dependencies in potato (i.e.
packages that install stuff in /usr/lib/python1.5, but don't have a
versioned dependency on Python 1.5). Therefore, any future python-base
package either has to be compatible with stuff in /usr/lib/python1.5,
or has to list all those broken packages as conflicts. Either is ugly.

Therefore I think we have to get rid of all the problem-ridden package
names, i.e. at least python-base and python-tk, perhaps even python-dev.
I don't see any other solution.



Please provide me with feedback if I should make this radical
transition. I would then go on and upload python1.5 and python2.1
(perhaps even a python2.0 source package to ease the migration). The
existing python (and python2) packages would be removed by this upload
(the packages built from python.orig.tar.gz, that is).

Python package maintainers should then change their packages to build
python1.5-* and python2.1-* packages (python2.0 if needed), and make
them depend on python1.5-base etc. That would remove the need for
versioned dependencies.

At a later point, we could implement a kind of registry like the emacsen
have, so that third-party packages could build only one python-*
package, that registers itself with all existing pythons.


How does that sound ?


Gregor

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

[Radovan Garabik]

On Tue, Sep 04, 2001 at 12:01:24PM +0200, T.Pospisek's MailLists wrote:
> Btw:
> 
> > http://melkor.dnp.fmph.uniba.sk/~garabik/debian-utf8/HOWTO
> 
> Does not serve any pages to me - it's pingable though. If you've got
> problems with that server you could put the HOWTO on the debian servers or
> if that's a problem I'd gladly put it up at our site.
> 

Nah - I was just a bit overactive with grsecurity networking setup :-)
(it seemed to affect only some clients, though)
But I will put it on debian server soon, it is better to have
a copy somewhere else.

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

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

[Martijn van Oosterhout]

On Tue, Sep 04, 2001 at 08:56:54AM +0200, Radovan Garabik wrote:
> On Tue, Sep 04, 2001 at 11:20:33AM +1000, Brian May wrote:
> > > "Radovan" == Radovan Garabik <[EMAIL PROTECTED]> writes:
> 
> > Radovan> format is important but whoever designes his software to
> > Radovan> display 8/1/63 should be shot, locale or no locale.
> > 
> > GNUmeric doesn't display the date in this format (it is up to the user
> > to pick what format is used), BUT it does require entering dates in
> > MM/DD/ format.
> > 
> > - unless of course you have changed the locale...
> 
> I would file a bug against gnumeric in this case.
> This is broken behaviour. Does in behave the same
> when you import data from text file? Then it
> is even more broken.

Does that mean it should always take a certain format irrespective of the
locale? If so, which format?

As far as I'm concerned, as long as it accepts -mm-dd I'm happy.

-- 
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: Bug#111158: Kernel 2.4.5+ network timeouts

[Ethan Benson]

On Tue, Sep 04, 2001 at 11:59:25AM +0200, Francesco P. Lovergine wrote:
> 
> Ok, after some times with /proc/sys/net/ipv4/tcp_ecn set to 0,
> it worked. Anyway I strongly suggest to modify this setting ASAP in
> procps. Moreover this is required only for kernel 2.4.5+  (why?

if its to be set anywhere it should be in netbase NOT procps.  if you
put it in /etc/sysctl.conf every default debian system will output an
error on boot:

error: 'net/ipv4/tcp_ecn' is an unknown key

remember the default kernel in woody is 2.2, not 2.4.

there should be a new option added to /etc/network/options just like
the current syncookies option.

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


pgpdcJlLCjCrr.pgp
Description: PGP signature

Re: (my) summary about translated description with dpkg (still RFC)

[Martijn van Oosterhout]

On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote:
>  - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size
>_without_ translation... 

I'm curious, but why are there so many?

I can see numarches (10) x sections ({non-us/,}{main,contrib,non-free} (6)

Where does the other 5x come from?
-- 
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: (my) summary about translated description with dpkg (still RFC)

[Chris Halls]

On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote:
> On Tue, Sep 04, 2001 at 10:39:00AM +0200, Chris Halls wrote:
> 
> How will the translated Description be stored in the deb Package?

Sorry, I wasn't addressing that :-)  I was expecting to use the solution
that would need to be worked out as a result of your statement:

> > > The more controversial point of our proposal is that we where planing
> > > to centralize the translation in a way that keeps the maintainer out
> > > of the loop. But it's not the key point, it's an add-on which ease the
> > > work of translators. Each package can still provide the translation
> > > and be 'self contained'.

My proposal simply lets all packages be 'self contained'.

> > You now have translated descriptions integrated into the .debs,
> > and it is possible to generate the Packages. files for use by the
> > modified dpkg/dselect as was originally suggested, except that the
> > translations are coming from the .debs instead of a single server.
> 
> Packages. are a hack.
>
> What are Packages. file? Files with the English and the
> translated Description? Only the translated Description? With a
> Description or a Description- tag? With the other tags?

Oh yes, I was referring to the older solution.  

s/Packages./Packages.po

(i.e. use the Packages.po format you suggested - I'm just suggesting
always generating them from .debs in the same way as Packages, instead of
introducing a seperate centralised system)

> some cons:
>  - apt-get don't know about the translation with this
>  - if you will use some languages, you must download some Packages
>files with all the tags.
>  - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size
>_without_ translation... 
>  - you must patch apt in a whole

I think your objections are because I didn't talk about Packages.po,
aren't they?  Do your objections still hold if you use Packages.po?

>  - maybe we get outdates translations (like debconf)

Yes, the issue is not solved totally MIA maintainers, who never
initiate a package rebuild.  But at leat, any NMU rebuild by someone else
(or qa?) would then automatically fold in your updated description
translations to the package, compared to the sometimes hit-and-miss affair
of a BTS request which the maintainer may or may not integrate into the
package.  Using this suggestion, the 'default case' of a maintainer doing
nothing to the translations when rebuilding would pick up the translations
(provided they at least did an apt-get update every now and then!).
Compare this with the debconf template situation: If the maintainer does
nothing, the translation rots in the BTS.

Chris

Re: isync vs mailsync

[Wichert Akkerman]

Previously Brian May wrote:
> ISYNC:
>  
> CONS
> 
>  - delete message on client => gets transfered again on next download.

If I remember correctly that is not true if you use mutt to mark it as
deleted but don't physically delete it. isync should then do the right 
thing on sync and delete it at both ends.

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: Date format (was: How many people need locales?)

[Radovan Garabik]

On Tue, Sep 04, 2001 at 09:17:12PM +1000, Martijn van Oosterhout wrote:
> On Tue, Sep 04, 2001 at 08:56:54AM +0200, Radovan Garabik wrote:

> > > 
> > > GNUmeric doesn't display the date in this format (it is up to the user
> > > to pick what format is used), BUT it does require entering dates in
> > > MM/DD/ format.
> > > 
> > > - unless of course you have changed the locale...
> > 
> > I would file a bug against gnumeric in this case.
> > This is broken behaviour. Does in behave the same
> > when you import data from text file? Then it
> > is even more broken.
> 
> Does that mean it should always take a certain format irrespective of the
> locale? If so, which format?
> 

It should reject commonly used ambiguous formats (such as NN/NN/NN,
NN/NN/), or at least warn if something like this is entered.
This should ideally be configurable, but rejecting should be 
the default (and independent on locale).

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

Re: How many people need locales?

[Ingo Saitz]

MoiN

On Mon, Sep 03, 2001 at 10:30:25PM +0200, Marcelo E. Magallon wrote:
>  Well, it still happens on upgrades because
>  dpkg stops to ask if a configuration file should be replaced or not.
>  Is this avoiable somehow?

Yes. Dpkg has the switches --force-confnew, --force-confold and
--force-confdef to skip these questions. If you use apt, you can
pass options to dpkg with the Dpkg::Options setting in
/etc/apt/apt.conf. Use with care.

See also the manpages apt.conf(5), dpkg(8) and "dpkg --force-help".

Ingo
-- 
< $INFILE cat -n | cut -b 8- | cat > $OUTFILE

-- from "useless cutting of cute cats" vol. II

Re: wnpp still down

[Marcelo E. Magallon]

>> Christian Marillat <[EMAIL PROTECTED]> writes:

 > >  mailed Ben Collins a pseudo patch to fix the affected script but I
 > >  think he's on vacation as I haven't got any sort of ack.

 s/pseudo/proper, one line/; s/ but/./; s/on/back from/; s/as I/but I still/;

 > Today the WNPP is still broken. Somebody can do something ?

 AFAIUI, Ben Collins.  A couple of mails from him have showed up here
 and there, so I think he's reading his mail again.  After sending him
 two mails about the problem, I'd consider a third one rude.

-- 
Marcelo | No matter how fast light travels it finds the darkness
[EMAIL PROTECTED] | has always got there first, and is waiting for it.
| -- (Terry Pratchett, Reaper Man)

new proposal: Translating Debian packages' descriptions

[Michael Bramer]

Hello all


After I read some more mails and write some comments myself, IMHO it
is time to write a newer hopefully better proposal. Not all is new.
But I add some new thoughs and some parts from some comments.

In this proposal I have combined the decentralized translations, and
also the central repository. And this all without a delay in the
translator to user path. 

Not all parts are turned into stone. I need some comments and decision 
on some parts. Maybe you can help.

One quote from a mail from Raphael Hertzog:
 I find that having translations is far better that having not a
 single one and refusing to add them because we can't have the perfect
 solution right now.



 Add Translations of the Package Description 
  in the Debian Distribution

(c) Michael Bramer <[EMAIL PROTECTED]>


1.) use all the time _gettext_!

   All know gettext and all use this. Why should we use gettext to add
   the translated description in the debian describution? Because of
   this. Gettext is *the* technic for translations. 

   All know it, you need not teach a maintainer, you need not teach a
   user (a important point). If a user already use a system with
   locale enviroment, he just will have translated descriptions in
   future. 

   gettext make all the work and gettext is tested (and is useing in many
   programes). With this you need only some little pachtes. (We show a
   -9/+30 patch for dselect/dpkg and hopefully a apt patch will it not
   much bigger.) Gettext show never outdated translation (a big point)
   and have other nice features (see below).

   Maybe the release manager will allowing this patch in woody, but
   this is a other story.

   If apt and dpkg is patched and the user have a nice .mo file in
   /usr/share/desc-trans// all output of _all_ package
   management programs is transled. (dpkg and APT use a patch, other
   programs (like deity, etc.) use APT)

   gettext support already fallback languages. See [1] for more
   informations. If I understand the gettext source code in the right
   way, the fallback is per message and not per .mo file. With this
   someone can set LANGUAGE=hu:sl:cz and get a
   hungarian->slovak->czech->->english fallback path. (If a
   description is translated in slovak but not in hungarian, the user
   will see the slovak description.)


   This is all nice, and we have only one problem. How will the user
   get a nice .mo file? 

   First on comment on this question: You have this problem all the
 time with the description. You must download the
 descriptions and the translations first. Only and after this, you can
 use (see) it and install the real programs/packages. 
 With the normal (english) Descriptions we use the Packages files
 (with apt or dselect (the old methodes)) We must use somethink
 like this with the translations too...


2.) get the .po/.mo files on the system

   If we will use gettext, we must get one .mo file on the system.
   The .mo file is generatted from a .po file and it is itself a binary
   data file. If you have some sources (like ftp.debian.de and a
   local mirror with own packages) you will have some translations and
   some .mo/.po files.

   The best way is, that you download the .po files, merge this files
   with a tool and make from this one big .po file a .mo file and use
   this file. (maybe you must only make a 'cat *.po > master.po', I have
   not test this now, but this is only a technical question and
   problem)

   I propose the dir /usr/share/desc-trans//desc-trans.d/ to
   store all .po files. 
   
   If you make a apt-get update (or a other funktion like this in
   deity and co), you have (maybe) new and changed description in the
   apt database. And now you need a newer, better .po file. Because of
   this, I propose to download the .po like file (see below) with apt
   by the update process. 

   What is the size of all this? Ok. we have now in sid/main/i386 (see
   [2]) 7000 Packages and the descriptions of all this packages is
   2660993 bytes big. We get a description size per package of 384 bytes.
   With gzip we will get (maybe) 130 bytes. 
 
   With this the size on the system is like the Package files from
   apt. If you have some sources you will have some (5-20) Megabytes in
   /usr/share/desc-trans//desc-trans.d/ and a collect .mo file
   per language.

   But the admin of the system must pay this price, if he will see translated
   descriptions. (and it don't care if we use gettext or a other
   technic, with gettext we have only the extra .mo file.)

   But what file should apt download? The first thought is maybe a
   translated Packages-XX file. But the first thought is not the
   best way all the time.

   We have _now_ 316 Packages* (see [3]) files on ftp-master with 141
   MByte of size. If we translate this all in (only) 10 languages we
   need 1,4 GByte. With more Packages and more Languages more and
   more. Ok, harddisk a

Re: (my) summary about translated description with dpkg (still RFC)

[Michael Bramer]

On Tue, Sep 04, 2001 at 12:57:02PM +0200, Chris Halls wrote:
> On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote:
> > > You now have translated descriptions integrated into the .debs,
> > > and it is possible to generate the Packages. files for use by the
> > > modified dpkg/dselect as was originally suggested, except that the
> > > translations are coming from the .debs instead of a single server.
> > 
> > Packages. are a hack.
> >
> > What are Packages. file? Files with the English and the
> > translated Description? Only the translated Description? With a
> > Description or a Description- tag? With the other tags?
> 
> Oh yes, I was referring to the older solution.  
> 
> s/Packages./Packages.po
> 
> (i.e. use the Packages.po format you suggested - I'm just suggesting
> always generating them from .debs in the same way as Packages, instead of
> introducing a seperate centralised system)
> 
> > some cons:
> >  - apt-get don't know about the translation with this
> >  - if you will use some languages, you must download some Packages
> >files with all the tags.
> >  - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size
> >_without_ translation... 
> >  - you must patch apt in a whole
> 
> I think your objections are because I didn't talk about Packages.po,
> aren't they?  Do your objections still hold if you use Packages.po?

no, .po with gettext throw away all this point. 
> 
> >  - maybe we get outdates translations (like debconf)

and this point to.

With gettext you don't get outdated translations.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Montag ist eine furchtbare Art, ein Siebtel seines Lebens zu
 verbringen."   --- Gerd Schmerse in detebe


pgpwBeiGH4kAA.pgp
Description: PGP signature

Re: Bug#111158: Kernel 2.4.5+ network timeouts

[Eric Van Buggenhaut]

On Tue, Sep 04, 2001 at 10:42:43AM +0200, Francesco P. Lovergine wrote:
> 
> Package: kernel-image-2.4
> Version: N/A
> Severity: important
> 
> This is an issue for the kernel folk. Just verify 
> 
> telnet www.compaq.com 80
> 
> It will not respond with all kernel 2.4.5+ (timeout)
> I used my workstation at work with 2.4.8,9 and several machines of 
> the Project. It seems ok with 2.4.2 or 2.4.4 (eg auric et al.)
> This seems a problem with routing filtering policies (icmp filtering
> I think) used by some sites. 
> Use debussy.debian.org to see the problem.
> Compaq is only one of sites with the same problem.
> It does not seem a problem due to PMD (path mtu discovery): 
> 
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> 
> does not solve the problem.
> 
> Ideas?


Please see

http://www.tux.org/lkml/#s14-2

Question 2.

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

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

Re: (my) summary about translated description with dpkg (still RFC)

[Michael Bramer]

On Tue, Sep 04, 2001 at 09:03:00PM +1000, Martijn van Oosterhout wrote:
> On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote:
> >  - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size
> >_without_ translation... 
> 
> I'm curious, but why are there so many?
> 
> I can see numarches (10) x sections ({non-us/,}{main,contrib,non-free} (6)

this is only auric (without non-us). And I count Packages* (with .gz). 

some extra files:
 dists/sid/main/debian-installer/*
 dists/woody-proposed-updates/{main,contrib,non-free}/binary-*
 project/experimental/{main,contrib,non-free}/binary-*

and we have 13 arches in sid.

some quotes:
[EMAIL PROTECTED]:/org/ftp-master.debian.org/ftp$ find -type f -name 
"Package*"|wc  
316 316   15774
[EMAIL PROTECTED]:/org/ftp-master.debian.org/ftp$ find dists/ -type f -name 
"Package*"|wc 
238 238   11123
[EMAIL PROTECTED]:/org/ftp-master.debian.org/ftp$ find -type f -name 
"Package*"|xargs cat |wc
3276560 14878467 149011824
[EMAIL PROTECTED]:/org/ftp-master.debian.org/ftp$ find dists/ -type f -name 
"Package*"|xargs cat |wc
3275537 14873809 148962385

have I make a error? 

Maybe you shoud read my new proposal for a possible solution of this problem.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Montag ist eine furchtbare Art, ein Siebtel seines Lebens zu
 verbringen."   --- Gerd Schmerse in detebe


pgpdy6RiMYPAI.pgp
Description: PGP signature

Re: Intent for NMU of python-2.1 packages

[David Maslen]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> How does that sound ?

I think it sounds like an awful lot of work.  I still don't really
understand why we keep python1.5, but presumably there are some good
reasons, and I trust the debian team to have thrashed that out by now.

You mentioned emacs, which made me think about xemacs packaging
system, and wonder how the python packaging system might work for
debian? Probably it doesn't really.

Ideally I only want to install python2.1 (or whatever the latest
greatest is), but if I did find a need for 1.5 then I would like it to
be able to co-exist. It would be nice, if I only have 2.1 installed,
for the packaging system to automagically configure python as an
alternative for python2.

Probably it would be pretty cool if modules could sort out at install
time what version they were to compile for, just like some debian lisp
packages do for different emacsen.

cheers

Bug#111185: ITP: libtie-perl -- Various Tie::xxx perl modules

[Ivo Timmermans]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I intend to package some modules from
http://cpan.perl.org/modules/by-module/Tie/ that tie hashes to files,
databases, virtual things, and whatever else I find useful.

I will create one (Debian native) package rather than package each and
every one of them separately.



- -- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux spark 2.4.3 #2 do apr 12 00:50:33 CEST 2001 i586
Locale: LANG=C, [EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7lMURbTEMl+oVcvERApkqAJ4mJfy6Ph5g99MkvR+CBRXx7CZ3EQCeKcU0
IxGWr43x6sho0dPmSKZNQKc=
=9d79
-END PGP SIGNATURE-

Re: How many people need locales?

[Tille, Andreas]

On Mon, 3 Sep 2001, Ari Makela wrote:

> Just about anyone who's not from English speaking countries. For
> example, we Finns need 'åäö' and their capital versions. They just
> don't work if you don't set locales right.  If you take a look at even
> just European languages you can see that most of them cannot be
> written with a-zA-Z. Actually, I think only English can. I'm not sure
> of some of the smaller countries like Belgia, though.
Similar for German.  Many German users (including me for the most
cases) use locale.  My wife asked me:  Has yoour stupid Linux no
German browser?  It´s so easy at work and here I have to leran English.
(So, I builded a mozilla-locale-de-at package, see #110513.)
Moreover I try to catch my son with German fortunes.  By the way
Debian-Junior heavily needs locale for all non-English speaking
childs.

Kind regards

 Andreas.

Re: new proposal: Translating Debian packages' descriptions

[Simon Richter]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> After I read some more mails and write some comments myself, IMHO it
> is time to write a newer hopefully better proposal. Not all is new.
> But I add some new thoughs and some parts from some comments.

We can reduce the download size by 50% by letting the ddts database decide
which translations are still up to date and pack only those into the
downloadable file. It won't be a .po file, but it will be smaller.

Also, an important point will be that the downloadable files be sorted, so
that you can diff them easily (I believe there is some effort going on to
make diffs from the Packages files).

I'm going to apply for a new job now, after that I'll take a more
extensive look into this.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: new proposal: Translating Debian packages' descriptions

[Martin Quinson]

On Tue, Sep 04, 2001 at 02:52:40PM +0200, Simon Richter wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > After I read some more mails and write some comments myself, IMHO it
> > is time to write a newer hopefully better proposal. Not all is new.
> > But I add some new thoughs and some parts from some comments.
> 
> We can reduce the download size by 50% by letting the ddts database decide
> which translations are still up to date and pack only those into the
> downloadable file. It won't be a .po file, but it will be smaller.

You can also have the ddts building po files with only the uptodate
translations in it. So, it will be smaller, and you still can use the
gettext mecanism.

> Also, an important point will be that the downloadable files be sorted, so
> that you can diff them easily (I believe there is some effort going on to
> make diffs from the Packages files).
>
> I'm going to apply for a new job now, after that I'll take a more
> extensive look into this.

Good luck, Mt.

-- 
Un clavier azerty en vaut deux.

Re: new proposal: Translating Debian packages' descriptions

[Nick Phillips]

Sorry to screw up the threading; thought I'd posted this already, then
deleted grisu's message before finding that I hadn't sent this :(

On Tue, Sep 04, 2001 at 01:22:16PM +0200, Michael Bramer wrote:

> Not all parts are turned into stone. I need some comments and decision 
> on some parts. Maybe you can help.
> 
> One quote from a mail from Raphael Hertzog:
>  I find that having translations is far better that having not a
>  single one and refusing to add them because we can't have the perfect
>  solution right now.

However we do need to make sure that whatever we do right now can be
migrated fairly painlessly to the perfect solution, whatever that may be.

> 1.) use all the time _gettext_!

And don't forget that "the perfect solution" will involve translations
of all relevant text in a package, not just descriptions. I'm not saying
that anyone has forgotten this, just that a lot of the thought in these
threads seems to have been aimed at getting translated descriptions, and
that all would do well to remember the final aim at all times...


> 2.) get the .po/.mo files on the system
> 
>If we will use gettext, we must get one .mo file on the system.

I'm not familiar with gettext, but I would suggest that this is incorrect.
I'd have thought that you would eventually need (at least) one .mo per
package, and several others (such as for package descriptions).

>I propose the dir /usr/share/desc-trans//desc-trans.d/ to
>store all .po files. 

You've forgotten that in the end we'll not just be talking about
descriptions, haven't you?

>If you make a apt-get update (or a other funktion like this in
>deity and co), you have (maybe) new and changed description in the
>apt database. And now you need a newer, better .po file. Because of
>this, I propose to download the .po like file (see below) with apt
>by the update process. 

Does the user actually ever need the .po? I thought you said that the
.mo was generated from the .po, and then the .mo is used.

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

Whoa there. I guess this is a good a point as any for me to "go off on one".

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

Now, think about the structure of where they should/could go, and the
relationships between source, binary, and text data. Think databases.
Think normalization.

The text data in any one of an *arbitrary* number of languages is related
to the package, but you'd normally normalize it out into a separate
table in your database - you don't want to have your packages' source and
binary records growing to arbitrary sizes as arbitrary numbers of
translations are added to them.

So you probably don't usually want the translations to be part of the
package sources or binaries. They're logically separate, and should usually
be physically separate (as physically as we ever get in this sense).

Gettext abstracts the *idea* that is being communicated from the text used
to communicate it. That leaves the actual text used as an overlay, metadata.

So, we need to structure the repositories in such a way that the structure
of the data is respected. It also happens that this conveniently allows
for separation of areas of maintainer/translator expertise (and also
responsibility).

Packages as prepared by a maintainer need to contain text (.mo) for at
least one language; probably usually english, but once this works there'll
be no good reason for that to be the case. Translations of a package would
logically be in another file (we have .dsc, .deb, .tar.gz, .diff already
describing logically different aspects of a package, so there's no problem
adding .trans or similar). The exact best method to store these is open to
question, but I'd guess that it would be another section in the archive,
as sources and binaries are split now.

So, apt, for example would be told what to do with a line:

deb-trans http://www.debian.org/debian potato/de main contrib non-free


Which would be able to provide Packages files created from the various
translation packages. Multiple versions of the same package would be
dealt with in the same way as currently.

It also allows certain mirrors to provide certain sets of translations,
which will certainly be a Good Thing. And CD sets could easily include
one extra CD which provided the translation section of the archive for
whatever languages are required (OK, for the initial install there would
need to be a little more jiggery-pokery).


Exceptions and trickery needed:

  1) to ensure that versions provided within a p

NFS root with initrd and GRUB

[Russell Coker]

Following the advice from some people here (thanks in particular to Thierry 
Laronde) I have got initrd and NFS root working so that I can use the same 
kernel binary for hard drives, RAID, and NFS root without making the kernel 
excessively large.

I have written a document on what I have done because there seems no other 
good documentation on some of these things.  It is attached.  Any suggestions 
on improving the document (or how I could have done things differently to 
save myself some effort) will be appreciated.

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Title: NFS Root With INITRD, GRUB, and Devfs


GRUB Configuration
The first thing to do is compile GRUB with support for your network card.
Typical binaries of GRUB (such as the Debian package of GRUB) come without any
support for network booting. I imagine that part of the reason for this is the
fact that probing for the wrong network card has the potential to lock the
machine, and also for the tulip card there are two versions of the driver (only
the old version works for my card). I am going to request the creation of
grub packages for network booting to be created for Debian.
Anyway the way to build GRUB with network support is to run ./configure
with the option for your network card and then run make. For my work I tried to
build GRUB in a temporary directory and install it from there, but it seemed
to get some files from the Debian GRUB package I had installed so I ended up
changing the debian/rules file and building and installing my own
package of GRUB for network booting.
Once GRUB is compiled you have to install it to a floppy. There is a script
that just writes the stage1 and stage2 files to the raw floppy
device, AFAIK it is not possible to use a menu.lst file with this so it won't
work for anything other than a recovery disk where you type every command
entirely.
So I created a minix format floppy disk and installed GRUB to it, and
then put the following in boot/grub/menu.lst:

# give me 10 seconds to interrupt the boot and change things
timeout 10
# boot from the first image by default
default 0
 
# set the title that is displayed in the menu
title net
# I am not using dhcp/bootp so we have an ifconfig command to set our IP address
# to 10.0.0.1 and the tftp server is 10.0.0.2
# use the dhcp, bootp, or rarp directives instead for a dynamic IP
ifconfig --address=10.0.0.1 --server=10.0.0.2
# the root file system is a network disk
root (nd)
# specify the kernel file to load (/vmlinuz), --no-mem-option means not to
# pass mem= to the kernel (I trust the kernel to find it's own memory)
# load the root file system from /dev/ram (the initrd) and make /linuxrc the
# init program.
kernel --no-mem-option /vmlinuz root=/dev/ram init=/linuxrc
# load the initrd from /boot/initrd on the tftp server
initrd /boot/initrd
# now boot the sucker!
boot

# now we've got an option to boot from the old version.
title net-old
ifconfig --address=10.0.0.1 --server=10.0.0.2
root (nd)
kernel --no-mem-option /vmlinuz.old root=/dev/ram init=/linuxrc
initrd /boot/initrd.old
boot

Initrd configuration
The first problem of initrd is that in the default setup the kernel will mount
the root file system after the /linuxrc process exits, however
the kernel options nfsroot= and ip= don't seem to operate when
the NFS client code is loaded as modules (may not even be compiled into the
module). This means that the regular operation of initrd won't work. So I
tell the kernel it's a regular ram disk and that /linuxrc is the init
program. This means that I had to put in some script code to mount the root
file system and then use pivot_root to make change the root file system.

This is the script I put in /etc/mkinitrd/scripts/nfs to set the initrd
options for NFS. In Debian there are scripts to automatically create an initrd
in the initrd-tools package. As part of this creation process the
scripts in /etc/mkinitrd/scripts are all run, and the variable
$INITRDDIR specifies the temporary directory that contains the new
file system image.

#!/bin/sh
 
# make a directory for mounting the NFS root file system
mkdir $INITRDDIR/new-root
# Create this script to be run on the initrd after modules have been loaded
SCRIPT=$INITRDDIR/scripts/nfs.sh
cat > $SCRIPT << END
#!/bin/sh
ifconfig eth0 10.0.0.1
mount -n 10.0.0.2:/var/tftpboot /new-root -orsize=8192,wsize=8192,lock,ro,port=2049,mountport=32790
mount -n none -t devfs /new-root/dev
cd /new-root
pivot_root . initrd
umount /initrd/dev
END
chmod 755 $SCRIPT

# my script needs ifconfig, pivot_root, and mount which aren't installed by
# default, change ifconfig to dhclient, pump, etc for dynamic IP addresses
cp /sbin/ifconfig /sbin/pivot_root $INITRDDIR/sbin
cp /bin/mount $INITRDDIR/bin

# tell /linuxrc to run init because the kernel won

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

[Drew Parsons]

On Tue, Sep 04, 2001 at 11:12:25AM +1000, Brian May wrote:
> 
> I am not sure if this is what you meant, but my understanding is that
> there is far greater support for the _GB locale, rather then the _AU
> locale:
> 
> [515] [scrooge:bam] ~ >du /usr/share/locale/en_GB   
> 136   /usr/share/locale/en_GB/LC_MESSAGES
> 140   /usr/share/locale/en_GB
> [516] [scrooge:bam] ~ >du /usr/share/locale/en_AU
> 8 /usr/share/locale/en_AU/LC_MESSAGES
> 12/usr/share/locale/en_AU
>

I didn't realise that!  Actually, I hadn't really thought about it.  I'm not
really bothered about the messages themselves (I figure if the author's
American then he has the right to write his messages in American).  I just
set the locale to en_AU on principle ;)

> ideally, if the message is not found in _AU, it should fall back onto
> _GB, but I am not sure this is possible.
> 

I think I read somewhere in the middle of this discussion that you can use
":" to make something like
LANG=en_AU:en_GB
which is supposed to define fallbacks.

> Experimentation shows that using en_AU often uses the US spelling of
> words, where en_GB doesn't.
> 

Curious.  I haven't noticed yet :)  If it starts to become a bother I'll put
en_GB in.


> How do you get gdm to log you in using a nonstandard locale? 

That I do not know.  I'm currently running from startx :)

Drew

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

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

[Adam Heath]

On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:

> Hello
>
> This is only an automated notification mail from the ddts (Debian Description
> Translation Server).

As an automated mail, to which I have not request, I consider this spam.

Please remove me, and all ways of contacting me, from your automated lists.  I
do not take kindly to unwarranted spam mails.

Re: Intent for NMU of python-2.1 packages

[Jérôme Marant]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:

 
> I'm still alive, I'm not lost ;-)

  You're not dead, which is the most important ;-)

> And that's the problem where I was stuck.
> 
> The dependencies of the current experimental python1.5 packages aren't
> good enough to allow an easy upgrade from potato or earlier. AFAICS, I
> would have to include empty transitional packages for almost all
> python-* packages built from the python source. That's butt ugly IMHO.

  That is what happened for the Perl transition. I don't think you
  can avoid this.

  What you have to do:
  . provide transitional packages. These packages will guaranty that
nothing will break during the transition.
  . ask people to change their dependencies. You will regularly list
packages that have not been updated and warn their maintainers
to do so.

> 
> Furthermore, it's my current impression that we have to orphan all
> python-* packages in order to get a clean upgrade path!

  Huh?!

> 
> There are many packages with broken dependencies in potato (i.e.
> packages that install stuff in /usr/lib/python1.5, but don't have a
> versioned dependency on Python 1.5). Therefore, any future python-base
> package either has to be compatible with stuff in /usr/lib/python1.5,
> or has to list all those broken packages as conflicts. Either is ugly.

  Do we have a list of them?

> 
> Therefore I think we have to get rid of all the problem-ridden package
> names, i.e. at least python-base and python-tk, perhaps even python-dev.
> I don't see any other solution.

  Sorry, I did not understand this.

...

> Python package maintainers should then change their packages to build
> python1.5-* and python2.1-* packages (python2.0 if needed), and make
> them depend on python1.5-base etc. That would remove the need for
> versioned dependencies.

  Right.

> 
> At a later point, we could implement a kind of registry like the emacsen
> have, so that third-party packages could build only one python-*
> package, that registers itself with all existing pythons.

  We have dealt with this a long time ago and we have always said that it
  was too late because we were approaching the freeze. But we are still
  not frozen (optional packages) and I think it's time to implement this,
  whenever is the freeze (it will be usefull whether it is integrated in
  woody or not).

  Cheers, 


-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

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

[Marek Habersack]

** On Sep 04, Daniel Burrows scribbled:
[snip]
> > - in the configuration screen manually type "en_GB", but this doesn't
> > seem to do anything.
> 
>   This may not be the answer you want, but what about adding:
> export LC_ALL=en_GB
> 
>   or something similar at the front of ~/.xsession?
Or just put LANG=en_GB in /etc/environment

marek

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

/* A completely unrelated fortune */
 We are all worms.  But I do believe I am a glowworm.   -- Winston
 Churchill 
 
 
 
 

pgpqcjGulaNoG.pgp
Description: PGP signature

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

[Vince Mulhollon]

On 09/04/2001 09:44:11 AM Adam Heath wrote:

>> On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
>>
>> > Hello
>> >
>> > This is only an automated notification mail from the ddts (Debian
Description
>> > Translation Server).
>>
>> As an automated mail, to which I have not request, I consider this spam.
>>
>> Please remove me, and all ways of contacting me, from your automated
lists.  I
>> do not take kindly to unwarranted spam mails.

Read the contents of the email.  It's a bug on their side.  It's not
automated at all, or at least no more than any mailling list software is
"automated".  It was generated by a person who knows a language that you
don't.  The translator presumably doesn't know English as well as us, thus
they mistakenly call it "automated", as if it's a computer generated
translation like from babelfish...

Someone whom speaks "BR" (Brazilian?) wrote translations for your Debian
package, so rather that send you a message in BR language (which you
probably can't read) you get the English form letter.  Overall, better to
get a form letter in a language you can read, than a personally written
email in a language you can't read.

I've gotten similar emails from "IT"s (Italians? Information
Technologists?) ...

They are nice guys, being nice to you and your Debian packages.  Please be
nice in return.  Treat it like a NMU, smile and say "thanks" and carry on
with life.

It's a new system so it's understandable that everyone doesn't know about
it.

build daemon architectures

[Matt Kraai]

[I don't subscribe, so please copy replies to me.]

Howdy,

The Automatic Package Building System page[1] lists the build
daemons with web pages.  It does not list those without, however.
Since my latest libcdaudio packages are considered out of date on
i386, I was wondering if a build daemon exists for that
architecture.  If you know of a build daemon for an architecture
other than arm, m68k, powerpc, or sparc (even if it doesn't have a
web interface), please let me know so that I can list it.

Matt

1. http://www.debian.org/devel/buildds

Re: new proposal: Translating Debian packages' descriptions

[Eduard Bloch]

#include 
Nick Phillips wrote on Tue Sep 04, 2001 um 03:30:08PM:
> So you probably don't usually want the translations to be part of the
> package sources or binaries. They're logically separate, and should usually
> be physically separate (as physically as we ever get in this sense).
...
> So, apt, for example would be told what to do with a line:
> 
> deb-trans http://www.debian.org/debian potato/de main contrib non-free

Just my 0.02¤:

You are completely right. We should keep the translated stuff out of the
packages. Some people claim a package to contain all stuff related to
it, but it is too complicated considering the frequency of updated when
translating the stuff. Developers should work together with DDTS if they
want to have control of the stuff concerning their packages.

IMHO a new script should work with the ddts database and create the
needed .po files. Additionally, the .mo file may be created so the
clients won't have to compile then on their side. This needs further
decissions.

About the space usage: I thing the best way is to create a big .po/.mo
file for all arches and each release.

Gruss/Regards,
Eduard.
-- 
Für manche ist es Windows, für andere der längste Virus der Welt

Re: new proposal: Translating Debian packages' descriptions

[Steve Langasek]

On Tue, 4 Sep 2001, Martin Quinson wrote:

> On Tue, Sep 04, 2001 at 02:52:40PM +0200, Simon Richter wrote:
> > On Tue, 4 Sep 2001, Michael Bramer wrote:
> >
> > > After I read some more mails and write some comments myself, IMHO it
> > > is time to write a newer hopefully better proposal. Not all is new.
> > > But I add some new thoughs and some parts from some comments.
> >
> > We can reduce the download size by 50% by letting the ddts database decide
> > which translations are still up to date and pack only those into the
> > downloadable file. It won't be a .po file, but it will be smaller.

> You can also have the ddts building po files with only the uptodate
> translations in it. So, it will be smaller, and you still can use the
> gettext mecanism.

This is a very good point that I think hasn't received enough attention yet.
The gettext mechanism of resolving translations is an important one to make
use of, but it /doesn't/ have to take place on the end user machine.  We have
an additional, guaranteed-unique index that we can use on description
translations: the package name and version.

The end user needs exactly one translated description per language for each
package name and version that's present in the Debian archive.  If there is
more than one translation for the same original text, one is out of date --
drop it.  If there are translations that don't match the descriptions on any
packages in the current archive, discard them -- they don't belong in any file
that we're sending to users.  If there are packages installed on a system that
are no longer present in the archive, the translated descriptions should be
stored on the local system: it should not be expected that the archive will
keep track of these outdated translations.

With such a structure, it doesn't matter what the precise lookup mechanism is
for finding the translations on the end user machine.  The translations can
still be stored in .po files if you like -- gettext is very nice, after all --
and use full text of the original description as the key for lookups, as is
done with most gettext stuff.  Or you can use package_version-deb.version as
the key, which is bound to be a little more efficient.  Or you can use any
other mechanism that can look up the translation based on the
(language,package,version) tuple -- including storing the requested
translations in {the,a} Packages.gz file and in /var/lib/dpkg/available.

This is not such a complicated thing that "reinventing the wheel" is
dangerous.

Steve Langasek
postmodern programmer

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

[Gustavo Noronha Silva]

Em Tue, 4 Sep 2001 10:08:15 -0500
"Vince Mulhollon" <[EMAIL PROTECTED]> escreveu:

> don't.  The translator presumably doesn't know English as well as us, thus
> they mistakenly call it "automated", as if it's a computer generated
> translation like from babelfish...
the translator did nothing... it's a feature of the ddts...

> Someone whom speaks "BR" (Brazilian?) wrote translations for your Debian
Brazillian Portuguese

> package, so rather that send you a message in BR language (which you
> probably can't read) you get the English form letter.  Overall, better to
> get a form letter in a language you can read, than a personally written
> email in a language you can't read.
well, that's what people wanted and asked for in this list...

> I've gotten similar emails from "IT"s (Italians? Information
> Technologists?) ...
italians =)

> They are nice guys, being nice to you and your Debian packages.  Please be
> nice in return.  Treat it like a NMU, smile and say "thanks" and carry on
> with life.
> 
> It's a new system so it's understandable that everyone doesn't know about
> it.
hey, that's it! we're nice =), we want to make Debian universal and maintainers
will probably help us ;), now that's not an NMU and it could be optional
too... that's an issue we have to take care of... but I am sure no maintainer
got angry with the automated message from katie ;)

[]s!

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

Re: [RFC] New BTS field

[Adam Heath]

On Wed, 29 Aug 2001, Richard A Nelson wrote:

> On Wed, 29 Aug 2001, Eduard Bloch wrote:
>
> > Summary: we need an "changemaint" command in the BTS. It should be
> > probably protected with PGP, though.
>
> That'd be nice, but if we do anything to the BTS, I'd like to request
> an additional field in the bug record 'InterestedParties' where one
> could register and receive copies of all mail regarding the bug

Already started months ago([EMAIL PROTECTED], will be handled like a normal
list).

Haven't had time to finish the code.

Re: Making better use of multiple maintainers

[Joey Hess]

Raphael Hertzog wrote:
> There's several things that have to be done :
> - be able to subscribe other people to a package bug list (in this case
>   the people listed in the Uploaders field), there should be some
>   automation here, otherwise beeing in the Uploader field won't change
>   anything as the backup maintainer won't know of any bug

I would like to see this oft-requested feature, but in the meantime
there is nothing to prevent you as a backup maintainer from seeing every
bug for every package you backup maintain. debian-bugs-dist + procmail.
Trivial.

-- 
see shy jo, who just sees every bug, period, and uses scoring on some
package names

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 09:44:11AM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
> > This is only an automated notification mail from the ddts (Debian 
> > Description
> > Translation Server).
> 
> As an automated mail, to which I have not request, I consider this spam.
> 
> Please remove me, and all ways of contacting me, from your automated lists.  I
> do not take kindly to unwarranted spam mails.

OH, this is now the second 'remove me' request.

Now the server can only mail notifications to all packages or to no
packages. Should I stop it?

Comments?

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

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Windows ist der One-Night-Stand unter den Betriebssystemen. Man fühlt
sich so billig, wenn man es benutzt hat. -- Illiad in uf


pgpbe8pwqoJ5g.pgp
Description: PGP signature

Re: How many people need locales?

[Marco d'Itri]

On Sep 03, Radovan Garabik <[EMAIL PROTECTED]> wrote:

 >well, the smallest country (Vatican) does not need 8-bit chars for Latin :-)
It does, since they speak italian, which needs accented letters.
I'm not sure if modern latin needs the latin accents which are in UTF-8.

-- 
ciao,
Marco

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

[Adam Heath]

On Tue, 4 Sep 2001, Vince Mulhollon wrote:

>
> On 09/04/2001 09:44:11 AM Adam Heath wrote:
>
> >> On Tue, 4 Sep 2001 [EMAIL PROTECTED] wrote:
> >>
> >> > Hello
> >> >
> >> > This is only an automated notification mail from the ddts (Debian
> Description
> >> > Translation Server).
> >>
> >> As an automated mail, to which I have not request, I consider this spam.
> >>
> >> Please remove me, and all ways of contacting me, from your automated
> lists.  I
> >> do not take kindly to unwarranted spam mails.
>
> Read the contents of the email.  It's a bug on their side.  It's not
> automated at all, or at least no more than any mailling list software is
> "automated".  It was generated by a person who knows a language that you
> don't.  The translator presumably doesn't know English as well as us, thus
> they mistakenly call it "automated", as if it's a computer generated
> translation like from babelfish...

No, it's an automated server.

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

[Adam Heath]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> OH, this is now the second 'remove me' request.
>
> Now the server can only mail notifications to all packages or to no
> packages. Should I stop it?

You mailed -devel-announce on Aug 30.  I then started getting these mails over
the weekend.  I would have hoped a week of time for discussion would have been
appropriate.

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

[Adam Heath]

On Tue, 4 Sep 2001, Gustavo Noronha Silva wrote:

> > package, so rather that send you a message in BR language (which you
> > probably can't read) you get the English form letter.  Overall, better to
> > get a form letter in a language you can read, than a personally written
> > email in a language you can't read.
> well, that's what people wanted and asked for in this list...

This is more a response to Vince, than Gustavo:

How can you know what language is native for a maintainer, based on the
package name?  Sending an english form-letter to @packages seems wrong,
and against what this whole idea is about.

I would rather see support added to dpkg first, for storing this info(make all
tools in dpkg(this includes dpkg-dev(which stores the data into the .deb) do
this), then work on displaying this info.  I am very much against this hackish
end-run around what are open-development tools.

Adam, who is a dpkg developer.

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

[Vince Mulhollon]

On 09/04/2001 10:52:58 AM Gustavo Noronha Silva wrote:

>> Em Tue, 4 Sep 2001 10:08:15 -0500
>> "Vince Mulhollon" <[EMAIL PROTECTED]> escreveu:
>> > they mistakenly call it "automated", as if it's a computer generated
>> > translation like from babelfish...

>> the translator did nothing... it's a feature of the ddts...

I think of it like the bug reports from the "bug" package.  (I'm thinking
bug uses email submission, or maybe I'm thinking of a similar package)
True, in both cases a "program" sends the message.  However, in both cases
the email is generated by a person "filling in the blank", either bug
description or package description.

There was a person involved in each individual email, thus to me, it's not
automated.  To me, automated would be writing a Perl script to run the
entire Packages file thru a computer auto-translator like babelfish and
then submitting without any human editing...  That could be annoying.

>> > Someone whom speaks "BR" (Brazilian?) wrote translations for your
Debian
>> Brazillian Portuguese

>> > I've gotten similar emails from "IT"s (Italians? Information
>> > Technologists?) ...
>> italians =)

The emails should have a full language name instead of abbreviation.
It's hard enough for developers to figure out if the translation is "fair",
without having to guess if "ES" means Eastonian or Espanol.

Sorry, broken packages

[Karl Voit]

Hi folks!

I'm new at this ML and hoping, that I'll not make a fool of myself ;)

Using: Debian testing/sid (since 1 yr)
(Linux for 5 yrs)

Since a few weeks, I noticed, that I can't install something with e.g.
apt-get because of broken packages.

Yes, I _did_ use "apt-get update" and "[U]pdate" within dselect too ;)

No, I don't have a cron-job with "apt-get dist-update" in it. I make it by
hand every few months or so.

Though I uses apt-get and dselect over one year without havin troubles yet,
I am confused of the recent troubles. Especially because they didn't vanish
by waiting for a couple of weeks (hoped that maintainers will fix the bugs 
anyway).

Our local linux-newsgroup couldn't help me and so I address the experts
here:

Is that _my_ problem or are there many broken dependencies in sid?


lisa:~# apt-get -su install something
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
 
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
 
Sorry, but the following packages have unmet dependencies:
  abiword: Conflicts: abi-fonts but it is not installable
   Conflicts: abisuite but it is not installable
   Conflicts: abiword-xml but it is not installable
   Conflicts: abiword-expat but it is not installable
   Conflicts: abiword-common but it is not installable
  communicator-smotif-476:  ddd: Conflicts: ddd-dmotif but it is not
installable
E: Sorry, broken packages
lisa:~#

OK, get rid of that abiword:

lisa:~# dpkg -P abiword
(Reading database ... 94535 files and directories currently installed.)
Removing abiword ...
Purging configuration files for abiword ...
lisa:~#

but:

lisa:~# apt-get -su install something
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
 
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
 
Sorry, but the following packages have unmet dependencies:
  cracklib2: Conflicts: cracklib2.6 but it is not installable
  ddd: Conflicts: ddd-dmotif but it is not installable
  debconf: Conflicts: apt (< 0.3.12.1) but 0.5.3 is to be installed
   Conflicts: cdebconf (< 0.10-5) but it is not going to be
installed
  emacs20: Conflicts: w3-el but it is not installable
  g++:  libgimp1.1: Conflicts: libgimp1.1.3 but it is not installable
  Conflicts: libgimp1.1.6 but it is not installable
  Conflicts: libgimp1.1.7 but it is not installable
  Conflicts: libgimp1.1.9 but it is not installable
  Conflicts: libgimp1.1.12 but it is not installable
  Conflicts: libgimp1.1.14 but it is not installable
  Conflicts: libgimp1.1.24 but it is not installable
  libmpeglib0: Conflicts: task-kdemultimedia but it is not installable
  python-imaging: Conflicts: pil but it is not installable
  Conflicts: python-pil but it is not installable
E: Sorry, broken packages
lisa:~#

and so on :(

I also used dselect and the main problem there seems to be that
apache-common requires a apache-perl packet with a version-number that
doesn't exist yet. (Again, since a couple of weeks!)

Hope, that someone can give me a hint what I should do to fix these problems.

-- 
Karl VOIT
   [EMAIL PROTECTED]
   Graz University of Technology (Austria/Europe)
   Linux - because it works. (mostly ;)

pgpUQiV9CWj2q.pgp
Description: PGP signature

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 11:51:07AM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> > OH, this is now the second 'remove me' request.
> >
> > Now the server can only mail notifications to all packages or to no
> > packages. Should I stop it?
> 
> You mailed -devel-announce on Aug 30.  I then started getting these mails over
> the weekend.  I would have hoped a week of time for discussion would have been
> appropriate.

Yes, a week would be better.

But I have get some request of this notification mails per List and
privat mails and I start this after this requests.

I don't see a real problem with this mail. If someone don't like it he
can make a procmail rule and move the mails to /dev/null and I can
improve the server by time. 

sorry, for this problem. 

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


pgp5CxptbzC8q.pgp
Description: PGP signature

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

[Wouter Verhelst]

On Tue, 4 Sep 2001, Michael Bramer wrote:

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

You didn't already?

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

-- 
wouter dot verhelst at advalvas dot be

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

Re: isync vs mailsync

[Joey Hess]

Brian May wrote:
> In my search for a "perfect" offline IMAP client(TM) I have looked at
> isync vs mailsync.

Me too, I have settled on isync for now although it's less than perfect.

>  - supports reliably synchronisation of message flags, such as read,
>  and previously read, important.

This is the killer feature for me. I don't really see how a mail sync
program can be useful without it.

>  - supports only maildirs. IMHO, the use of maildirs in this
>  application isn't really needed, and results in less efficient use of
>  diskspace.

Agreed. It was a pita to have to switch to maildirs to use this program.

>  - encodes message UID into the message filename, apparently this is
>  against maildir specifications.

Doesn't seem to break anything though.

>  - delete message on client => gets transfered again on next download.

Not if you can set up your mail client properly. If using mutt, set
maildir_trash.

>  - create message on client => gets ignored by isync.

It's supposed to have support for uploading local messages now, but I
have never seen it work yet.

-- 
see shy jo

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

[Steve Langasek]

On Tue, 4 Sep 2001, Vince Mulhollon wrote:

> >> > Someone whom speaks "BR" (Brazilian?) wrote translations for your
> Debian
> >> Brazillian Portuguese

> >> > I've gotten similar emails from "IT"s (Italians? Information
> >> > Technologists?) ...
> >> italians =)

> The emails should have a full language name instead of abbreviation.
> It's hard enough for developers to figure out if the translation is "fair",
> without having to guess if "ES" means Eastonian or Espanol.

If a maintainer cares enough to keep track of these things, shouldn't they
also be expected to know enough to find the language codes on their own?



Besides... what if the maintainer doesn't speak English very well, and
recognizes languages better by ISO codes than by English names? :)

Steve Langasek
postmodern programmer

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

[Steve Langasek]

On Tue, 4 Sep 2001, Wouter Verhelst wrote:

> On Tue, 4 Sep 2001, Michael Bramer wrote:

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

> You didn't already?

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

There are laws prohibiting Unsolicited Commercial Email and Unsolicited Bulk
Email in the United States.  I don't think one DD notifying other DDs by email
whenever translations have been updated for their packages qualifies as either
'Commercial' or 'Bulk'. :P

Whereas it does fall under the 'Unsolicited' modifier, and if select DDs wish
not to receive these messages, I can see where such a request should be
honored.

Steve Langasek
postmodern programmer

Re: CUPS

[Ari Makela]

Michael Meskes writes:
 > Or else you should read my original mail. :-)

 > The problem is not RTFM since all works well with the default ppds, but a)
 > the interaction with cupsomatic-ppd and b) the missing configuration in
 > postints. WHere does this belong if not into -devel?

Ok. I'm sorry. I misunderstood, I read that too quickly - my mistake,
of course. Because I was rude in public so I want to apologize in
public, too. I'm sorry.

-- 
#!/usr/bin/perl -w --   Ari Makela <[EMAIL PROTECTED]> #
# http://arska.org/hauva/ #

# "Sailing is, after all, a kind of grace, a kind of magic." - Phil Berman

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

[Adam Heath]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> I don't see a real problem with this mail. If someone don't like it he
> can make a procmail rule and move the mails to /dev/null and I can
> improve the server by time.

With spam, there is nothing I can really do to stop from even receiving it in
my accounts.  With this mail, I can get it stopped.

Please, turn off this mail-spamming service, until you have a facility to
exclude certain maintainers(note, I don't care about package excludes, but
maintainer excludes).

Re: new proposal: Translating Debian packages' descriptions

[Richard Atterer]

Hi Michael,

all in all, I think this sounds nice!

On Tue, Sep 04, 2001 at 01:22:16PM +0200, Michael Bramer wrote:
> 1.) use all the time _gettext_!

I agree, otherwise we'd just have to keep re-inventing the wheel.

> 2.) get the .po/.mo files on the system
[snip]
>If we don't like this process on the client all the time, we can
>produce Descriptions-XX.po files and the clinet must only
>download this file and save this in the right dir. But this file
>will include the orignal description and with this it has the
>double size and download time.

I don't know enough about gettext - am I assuming correctly that in
the .mo file, the English translation is replaced with a checksum or
similar, so you do not need to store the complete English translation?

> 4.) How get katie (or the desc-trans-XX.deb) the translation?
[snip]

> 5.) translated descriptions in the package. 
[snip]
>I see only one problem: the size. 
> 
>We have now 80446 .deb packages and 7643 source packages in the
>debian archiv on ftp-master. If we include the translation in the
>deb, we must store this in the source and in every deb package. 
> 
>check this calculation:
>  If in all sources are only one desription with 130 (geziped)
>  bytes of description we get 1 MByte per languages. If we use po
>  files in the source (see below), we get 2 MBytes per languages
>  And all deb packages have only one description with 130 (geziped)
>  bytes. This make 10 MByte per languages. If we store the
>  description as po file, we will use 20 MByte per languges. 
>  11/22 MByte per languages, with only 10 languages we will get
>  110/220 MBytes. 

Hm, this sounds a lot, but note that relative to the complete archive
size, it's only an increase of about 1%. A well-invested way of using
this disc space, IMHO.

>With more Packages, ports, languages, this will grow. This bytes
>must all be downloaded, uploaded and synced with the time.
> 
>And on the local system the descriptions and the translations of
>all languages from the package will stored on the local harddisk
>(without gzip). Count:
>  With 10 languages, 1000 installed Packages and 380 Bytes per
>  description and per translation you get additional 4/8MBytes on
>  the local disk.
> 
>Is this all usefull in a 'normal' deb package from the debian
>project? Maybe yes. We must decide this. (I personal don't find the
>real pro about this. But we can add it and I don't have a real
>problem with this. I see only the size problem, and this is not a
>big problem.)

I think it's very important to have the translations in the *source*
package.

For the binary package, I don't know... - Gnome and KDE do include all
translations, and I think it's easier to handle. Additionally, disc
space is really cheap these days, so maybe it would be better just to
include all the descriptions, too.

>In all the cases I propose: store the description in the source as
>  .po file in the /debian/ dir (one per languages). This is the
>  only real good way to store the translations. (no encodeing
>  problem, no outdated text, no debconf-mergetemplate hack, ...)

Seconded.

>But how get the maintainer the translation? We have some cases:
> - The maintainer translate the description hisself
> - He find some own translator (like now with debconf)
> - He use the ddtp
>   - He can ask the ddts and get all translations of the package
>   - He can use the override file of katie
>   - He use the notification mails from the ddts (In future the
>   server will use the decided format in this mail. With this,
>   the maintaner must only copy this file in the source.)
> 
>Now the technique part:
> 
>The proposal with the biggest patch, is the 'put the translation in
>a own element in the deb ar'. Maybe this is nice and feasible. 
>But this is not a fast way. 
> 
>Because of this I propose some solutions:
> 
>1.) (very fast)
> 
>  put the translation as normal .po file in the
>  /usr/share/desc-trans//desc-trans.d/ dir. finish. 
> 
>  This don't need some extra work on dpkg etc.

Actually, I think this is completely sufficient. Let the maintainer
include updated translations at his convenience in new uploads, and
use the override mechanism for the Descriptions-XX.mo.gz files until
he has done so.

Hm, but note that this means that dpkg will need to look first at
Descriptions-XX.mo files downloaded by apt, and only then at the .po
file in the package. Would that be a problem?

>2.) Put the translation in the control.tar.gz of the deb.
[snip]
>3.) Add the desc-trans.tar.gz in the deb ar as a own new element.
[snip]

Cheers,

  Richard

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

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 11:53:59AM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Gustavo Noronha Silva wrote:
> 
> > > package, so rather that send you a message in BR language (which you
> > > probably can't read) you get the English form letter.  Overall, better to
> > > get a form letter in a language you can read, than a personally written
> > > email in a language you can't read.
> > well, that's what people wanted and asked for in this list...
> 
> This is more a response to Vince, than Gustavo:
> 
> How can you know what language is native for a maintainer, based on the
> package name?  Sending an english form-letter to @packages seems wrong,
> and against what this whole idea is about.

english is all the time the right way. All maintainers can read
english mails, all doc and mailings list are in English.

A English letter to @packages.d.o or bugs.d.o is right.

> I would rather see support added to dpkg first, for storing this info(make all
> tools in dpkg(this includes dpkg-dev(which stores the data into the .deb) do
> this), then work on displaying this info.  I am very much against this hackish
> end-run around what are open-development tools.
> 
> Adam, who is a dpkg developer.

Ok, But why the dpkg so quiet?

I ask the first time on [EMAIL PROTECTED] at 11.06.2001 (maybe I send a
other mail before this time ...) and I get _no_ response.

I make some proposal (and IMHO the last one ok), but I don't see a
dpkg or APT developer with proposals, improvements, etc. 

I only see some comments like: `I don't like this hack', 'This don't
work', 'Make sure people submit their translations in UTF8', ...

And a second thing: The collection of translation (and only this make
the ddtp now) is other thing, as the technical implementation in dpkg
and apt.

If we start with the collection foremost after the technical
implementation, we lost only time. We can make this parallel. Now we
habe some languages with >10% translated. If we now start the
implementation process, we have with the implementation some already
translated description. 


But Adam and other dpkg/APT developer: some wishes

  - If you have already some thoughts about the technical
implementation of translated descriptions, give us some hints,
URL, etc.
  - Please read the proposals and make comments, make own proposals
etc. And don't say only: 'This will not work this way.'
If you have better ideas, talk about this!

The translated description is a important feature in the future! We
have a lot users from no english speaking countries. We need this
feature, and not in three years. Please make now thoughts and start
with this in future. 

IMHO the last proposal is a good start. It need only little changes in
dpkg and apt, include translations in the deb file, use a central
override file and avoids big delays. Maybe you have some comments
about this. 


Thanks for your work.


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Nicht geschehene Taten ziehen oft einen erstaunlichen Mangel an Folgen 
 nach sich." --   S.J. Lec


pgpdMrDPEf4x4.pgp
Description: PGP signature

Re: isync vs mailsync

[Jaldhar H. Vyas]

On 4 Sep 2001, Brian May wrote:

> MAILSYNC
>
> PROS:
>  - supports bidirectional transfer of messages.
>
>  - can delete deleted messages (not tested).
>

I can confirm this works.

>  - can create and delete folders (not tested).
>

And this.

>  - could potentially support other services too, such as NNTP (doesn't
>  work, see bug report). However, I imagine the slow down (see cons)
>  would be large, as NNTP groups can be very large.
>

Thanks to c-client also POP2, POP3, NNTP, and FTP and 'shared' (public)
mailboxes.

NNTP failing seems to be a bug in mailsync itself.

> CONS:
>
>  - upstream author seems to be really anti-maildir, although maildir
>  patches have been included in Debian version.
>

As Tomas pointed out, it is the c-client author who is anti-maildir.  I've
added a patch for maildirs but currently it is not working perfectly.
Miquel Van Smoorenburg said he was working on a better one.

>  - needs to retrieve the message-id of *every* message, which really
>  slows the process down, especially on slow Internet link and/or if
>  folder has lots of messages.
>
>  - synchronisation of message flags doesn't work the way I would
>  expect (bug has been reported).
>

Did you use the verbose option to see which imap commands are being sent?
Depending on that it could either be a c-client or mutt problem.

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

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

[David Starner]

On Tue, Sep 04, 2001 at 11:53:59AM -0500, Adam Heath wrote:
> How can you know what language is native for a maintainer, based on the
> package name?  Sending an english form-letter to @packages seems wrong,
> and against what this whole idea is about.

Why? This is multilingual support for users, not developers. Developers
get many English form-letters, not to mention English bug reports.
 
> I would rather see support added to dpkg first, for storing this info(make all
> tools in dpkg(this includes dpkg-dev(which stores the data into the .deb) do
> this), then work on displaying this info.  I am very much against this hackish
> end-run around what are open-development tools.

Then you should have been here for the lengthy discussion on the subject.
grisu provided lengthy (if not always persuasive) explanations for why
it's being done this way, and there were many discussions on the 
ramifactions.

Anyway, grisu is offering working code. There is no working dpkg 
solution, nor consensus that a dpkg solution would be better.

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

[Peter S Galbraith]

Martin F Krafft wrote:

> first of all, is this the right way to do ITP's? i just simply sent a
> mail...

If you use Emacs, install the package debbugs-el from testing and
do:

M-x debian-bug-ITP

Peter

Re: Sorry, broken packages

[Daniel Burrows]

On Tue, Sep 04, 2001 at 06:23:37PM +0200, Karl Voit <[EMAIL PROTECTED]> was 
heard to say:
> Sorry, but the following packages have unmet dependencies:
>   abiword: Conflicts: abi-fonts but it is not installable
>Conflicts: abisuite but it is not installable
>Conflicts: abiword-xml but it is not installable
>Conflicts: abiword-expat but it is not installable
>Conflicts: abiword-common but it is not installable
>   communicator-smotif-476:  ddd: Conflicts: ddd-dmotif but it is not

  Upgrade to apt 0.5.4 :-)  (IIRC, the workaround is to disable all but
one package archive in /etc/apt/sources.list)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|  Wisdom is one of the few things|
|  that looks bigger the farther away it is.  |
|-- Terry Pratchett   |
\--- Listener-supported public radio -- NPR -- http://www.npr.org /

Re: new proposal: Translating Debian packages' descriptions

[Michael Bramer]

On Tue, Sep 04, 2001 at 07:59:47PM +0200, Richard Atterer wrote:

> > 2.) get the .po/.mo files on the system
> [snip]
> >If we don't like this process on the client all the time, we can
> >produce Descriptions-XX.po files and the clinet must only
> >download this file and save this in the right dir. But this file
> >will include the orignal description and with this it has the
> >double size and download time.
> 
> I don't know enough about gettext - am I assuming correctly that in
> the .mo file, the English translation is replaced with a checksum or
> similar, so you do not need to store the complete English translation?

see in the info page from gettext.

from the info page:
...
   Then, at offset O and offset T in the picture, two tables of string
descriptors can be found.  In both tables, each string descriptor uses
two 32 bits integers, one for the string length, another for the offset
of the string in the MO file, counting in bytes from the start of the
file.  The first table contains descriptors for the original strings,
and is sorted so the original strings are in increasing lexicographical
order.  The second table contains descriptors for the translated
strings, and is parallel to the first table: to find the corresponding
translation one has to access the array slot in the second array with
the same index.
...

You see in the mo file is the orignal description.

 
> >Because of this I propose some solutions:
> > 
> >1.) (very fast)
> > 
> >  put the translation as normal .po file in the
> >  /usr/share/desc-trans//desc-trans.d/ dir. finish. 
> > 
> >  This don't need some extra work on dpkg etc.
> 
> Actually, I think this is completely sufficient. Let the maintainer
> include updated translations at his convenience in new uploads, and
> use the override mechanism for the Descriptions-XX.mo.gz files until
> he has done so.

Descriptions-XX.mo.gz? not Descriptions-XX.po.gz?

> Hm, but note that this means that dpkg will need to look first at
> Descriptions-XX.mo files downloaded by apt, and only then at the .po
> file in the package. Would that be a problem?

if dpkg use gettext, dpkg show the translation of all textes in the mo file.
And if you use apt-get update you have the translation of all packages
(from the apt source) in the .mo file. If you have installed the
package you have the translation in the .mo file to. 

Only a dpkg --info don't show the translated description with this
solution.

> >2.) Put the translation in the control.tar.gz of the deb.
> [snip]

This can show the translation with --info!

> >3.) Add the desc-trans.tar.gz in the deb ar as a own new element.
> [snip]

This can show the translation with --info!

this is the main difference from the user view of this three
solutions.

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Traue nie einer Computerzeitschrift mit schoenen Frauen auf dem Cover.
(Besim Karadeniz in de.comm.internet.misc)


pgpwyc38tLW4r.pgp
Description: PGP signature

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

[Christian Surchi]

On Tue, Sep 04, 2001 at 01:04:58PM -0500, Adam Heath wrote:
> Please, turn off this mail-spamming service, until you have a facility to
> exclude certain maintainers(note, I don't care about package excludes, but
> maintainer excludes).

Maybe we should call it EMP and not SPAM. I don't think he has a commercial 
target.
:)

-- 
Christian Surchi   |   [EMAIL PROTECTED]   |   [EMAIL PROTECTED]
FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org
The more they over-think the plumbing the easier it is to stop up the drain.

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 01:04:58PM -0500, Adam Heath wrote:
> Please, turn off this mail-spamming service, until you have a facility to
> exclude certain maintainers(note, I don't care about package excludes, but
> maintainer excludes).

comments?

(for the future: The ddts don't know maintainers and son't send it to
maintainers. It sends this mails to [EMAIL PROTECTED])

Gruss
Gri, man bekommt nie alle unter einen Hut, su
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Linux -- das System fuer Kaltduscher und aechte Maenner   aus d.c.o.u.l.n


pgpN87Tuf3Qc6.pgp
Description: PGP signature

Re: build daemon architectures

[Randolph Chung]

> The Automatic Package Building System page[1] lists the build
> daemons with web pages.  It does not list those without, however.
> Since my latest libcdaudio packages are considered out of date on
> i386, I was wondering if a build daemon exists for that
> architecture.  If you know of a build daemon for an architecture
> other than arm, m68k, powerpc, or sparc (even if it doesn't have a

i386, mips, mipsel, ia64, hppa, alpha, s390 all have autobuilders.

randolph
-- 
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/

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

[Adam Heath]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> > Adam, who is a dpkg developer.
>
> Ok, But why the dpkg so quiet?

No one sees a need?  We all have to split our time different ways, and the
current developers/authors/programmers don't see it as useful.

If someone were to develope a patch, test it, show it in use, it would very
likely get a good response.

> I only see some comments like: `I don't like this hack', 'This don't
> work', 'Make sure people submit their translations in UTF8', ...

So come up with a proper solution, not a hack.

A proper solution, at the very least, invovles storing the data in the
foo.deb{control.tar.gz/control} file.

> But Adam and other dpkg/APT developer: some wishes
>
>   - If you have already some thoughts about the technical
> implementation of translated descriptions, give us some hints,
> URL, etc.

Fetch the current locale, and when displaying a field(from a list of fields),
look for the fieldname with the locale appended.  Note, this is not as easy as
it may sound, because the description as stored by dpkg internally in memory
does not make it immediately easy to generify.

There may be other fields that should be 'converted' to an alternate form,
when displaying, not just Description(I'm leaving this open for other items in
the future).

Re: new proposal: Translating Debian packages' descriptions

[Steve Langasek]

Hello Richard,

On Tue, 4 Sep 2001, Richard Atterer wrote:

> On Tue, Sep 04, 2001 at 01:22:16PM +0200, Michael Bramer wrote:
> > 1.) use all the time _gettext_!

> I agree, otherwise we'd just have to keep re-inventing the wheel.

> > 2.) get the .po/.mo files on the system
> [snip]
> >If we don't like this process on the client all the time, we can
> >produce Descriptions-XX.po files and the clinet must only
> >download this file and save this in the right dir. But this file
> >will include the orignal description and with this it has the
> >double size and download time.

> I don't know enough about gettext - am I assuming correctly that in
> the .mo file, the English translation is replaced with a checksum or
> similar, so you do not need to store the complete English translation?

Gettext normally uses the entire untranslated string as the key in the .mo
file.  This has many advantages when dealing with translation of strings in
programs, where the untranslated string is actually present in the program
source, and this is a big reason the GNU project favors gettext over catgets
systems found on other Unices.  It makes less sense in the case of package
descriptions, however, because we're effectively doing two lookups -- first to
find the English description in Packages.gz using the package name and version
as a key, then to find the translated description in the .mo file using the
English description as a key.

> >check this calculation:
> >  If in all sources are only one desription with 130 (geziped)
> >  bytes of description we get 1 MByte per languages. If we use po
> >  files in the source (see below), we get 2 MBytes per languages
> >  And all deb packages have only one description with 130 (geziped)
> >  bytes. This make 10 MByte per languages. If we store the
> >  description as po file, we will use 20 MByte per languges.
> >  11/22 MByte per languages, with only 10 languages we will get
> >  110/220 MBytes.

> Hm, this sounds a lot, but note that relative to the complete archive
> size, it's only an increase of about 1%. A well-invested way of using
> this disc space, IMHO.

Agreed.  Spending 1% archive space for the benefit of the 80%+ of our userbase
who doesn't speak English natively is not prohibitive.

> I think it's very important to have the translations in the *source*
> package.

Also agreed.

> For the binary package, I don't know... - Gnome and KDE do include all
> translations, and I think it's easier to handle. Additionally, disc
> space is really cheap these days, so maybe it would be better just to
> include all the descriptions, too.

I think it does belong in the binary package; if not, I'm not sure why we
would want it in the source package at all.  I believe translated descriptions
have just as much reason for inclusion in the binary package's control file
(or in a functional equivalent) as the rest of the informational stuff that's
in there.

If translated Description: fields in binary packages are not important, then
why do we currently have the untranslated Description: in the control file?

Steve Langasek
postmodern programmer

2.4 bootdisk for testing?

[Jørgen Hermanrud Fjeld]

Hi.

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


-- 


 Sincerely
 Jørgen Hermanrud Fjeld

 [EMAIL PROTECTED]

Re: new proposal: Translating Debian packages' descriptions

[Adam Heath]

yOn Tue, 4 Sep 2001, Steve Langasek wrote:

> Hello Richard,
>
> On Tue, 4 Sep 2001, Richard Atterer wrote:
>
> > On Tue, Sep 04, 2001 at 01:22:16PM +0200, Michael Bramer wrote:
> > > 1.) use all the time _gettext_!
>
> > I agree, otherwise we'd just have to keep re-inventing the wheel.
>
> > > 2.) get the .po/.mo files on the system
> > [snip]
> > >If we don't like this process on the client all the time, we can
> > >produce Descriptions-XX.po files and the clinet must only
> > >download this file and save this in the right dir. But this file
> > >will include the orignal description and with this it has the
> > >double size and download time.
>
> > I don't know enough about gettext - am I assuming correctly that in
> > the .mo file, the English translation is replaced with a checksum or
> > similar, so you do not need to store the complete English translation?
>
> Gettext normally uses the entire untranslated string as the key in the .mo
> file.  This has many advantages when dealing with translation of strings in
> programs, where the untranslated string is actually present in the program
> source, and this is a big reason the GNU project favors gettext over catgets
> systems found on other Unices.  It makes less sense in the case of package
> descriptions, however, because we're effectively doing two lookups -- first to
> find the English description in Packages.gz using the package name and version
> as a key, then to find the translated description in the .mo file using the
> English description as a key.

-

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

[Adam Heath]

On Tue, 4 Sep 2001, Michael Bramer wrote:

> On Tue, Sep 04, 2001 at 01:04:58PM -0500, Adam Heath wrote:
> > Please, turn off this mail-spamming service, until you have a facility to
> > exclude certain maintainers(note, I don't care about package excludes, but
> > maintainer excludes).
>
> comments?

So load indicies/Maintainers, with an option to have a local override(see
/etc/debbugs/Maintainers{,override} on master).

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

[Nick Phillips]

On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote:

> comments?

Only send them to individuals who've asked for them?

I don't expect most maintainers to be able or inclined to keep track of
a shedload of different translations, and those who are that keen should
be able to muster the energy to make the small effort to subscribe to receive
notifications regarding particular packages.


Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Look afar and see the end from the beginning.

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 02:18:57PM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> > > Adam, who is a dpkg developer.
> >
> > Ok, But why the dpkg so quiet?
> 
> No one sees a need?  We all have to split our time different ways, and the
> current developers/authors/programmers don't see it as useful.

this is normal. But some comments (like your last mail) is better.
Thanks.

> If someone were to develope a patch, test it, show it in use, it would very
> likely get a good response.

Have you see the patch from martin (see the very proposal)? 

> > I only see some comments like: `I don't like this hack', 'This don't
> > work', 'Make sure people submit their translations in UTF8', ...
> 
> So come up with a proper solution, not a hack.
> 
> A proper solution, at the very least, invovles storing the data in the
> foo.deb{control.tar.gz/control} file.

gettext is not a hack. Gettext for translations and dpkg use gettext
is self for translation. Why re-inventing the wheel?

I propose to store the translations in a some po.files and store this
in foo.deb{control.tar.gz}. But not in the control file.

If you store the translation as normal field in the control file (like
Description-de: dff) you have outdated translations with the time.
And outdated translations is a very big problem. 

You have more than one encoding in this file. This can be a problem.
Maybe you make a hack like debconf-mergetemplates and save the
translations in some files and merge this later in one control file. I
don't see a advantage with this. 

> > But Adam and other dpkg/APT developer: some wishes
> >
> >   - If you have already some thoughts about the technical
> > implementation of translated descriptions, give us some hints,
> > URL, etc.
> 
> Fetch the current locale, and when displaying a field(from a list of fields),
> look for the fieldname with the locale appended.  Note, this is not as easy as
> it may sound, because the description as stored by dpkg internally in memory
> does not make it immediately easy to generify.

this make the patch and the patch work. I don't stress the patch and
maybe it has one or two bugs. But it work with Descriptions on my
system.

> There may be other fields that should be 'converted' to an alternate form,
> when displaying, not just Description(I'm leaving this open for other items in
> the future).

Maybe we can 'converted' other fields. But I don't see the sense?!

The other fields (like Package, Depends, Version, MD5SUM, ...) are all
more technical. The User need not to 'understand' the values of this
fields. The Package name is the package name, the version is the
version, ... Normal in RL you don't translate Names, etc. 


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Jaja. Die Heisenbergsche Unschaerferelation soll nur die Rechenfehler
der Simulationshardware verdecken.
  -- [EMAIL PROTECTED] (Lutz Donnerhacke) ueber simulierte Realitaet


pgpnfzBPUC9nK.pgp
Description: PGP signature

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 03:39:29PM -0500, Adam Heath wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > On Tue, Sep 04, 2001 at 01:04:58PM -0500, Adam Heath wrote:
> > > Please, turn off this mail-spamming service, until you have a facility to
> > > exclude certain maintainers(note, I don't care about package excludes, but
> > > maintainer excludes).
> >
> > comments?
> 
> So load indicies/Maintainers, with an option to have a local override(see
> /etc/debbugs/Maintainers{,override} on master).

yes I can make this (or get the info from the Package file, I get now
all infos from the Package file). But not now. 

Now I have no time for this. First I must (only ddtp-TODO list)
 - write the bts code in the ddpt
 - clean the code and write a better api
 - help with the html interface 
 - make the code more modular (hocks for the french boys, more config,
   add more encodings, ...)
 - add the review process

And I have some other TODO's on other lists. (like my job, my
packages, test BF's, patch dpkg and apt, ...)


And one note:
  Thanks to the >170 translators in the ddtp. They do all the work and
  we, the debian project, should use their translations. 
  Please don't deny their contribution. 

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


pgpkb00SblVc3.pgp
Description: PGP signature

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

[Michael Bramer]

On Tue, Sep 04, 2001 at 09:50:07PM +0100, Nick Phillips wrote:
> On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote:
> 
> > comments?
> 
> Only send them to individuals who've asked for them?
> 
> I don't expect most maintainers to be able or inclined to keep track of
> a shedload of different translations, and those who are that keen should
> be able to muster the energy to make the small effort to subscribe to receive
> notifications regarding particular packages.

Yes, I can make this. But not now.

Should I stop the notification mails now? 

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
Linux -- das System fuer Kaltduscher und aechte Maenner   aus d.c.o.u.l.n


pgpWtixVsiCWg.pgp
Description: PGP signature

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

[Gustavo Noronha Silva]

Em Tue, 4 Sep 2001 14:18:57 -0500 (CDT)
Adam Heath <[EMAIL PROTECTED]> escreveu:

> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > > Adam, who is a dpkg developer.
> >
> > Ok, But why the dpkg so quiet?
> 
> No one sees a need?  We all have to split our time different ways, and the
> current developers/authors/programmers don't see it as useful.
> 
> If someone were to develope a patch, test it, show it in use, it would very
> likely get a good response.
it was already done... if you don't see it as usefull you missed the Debian's
main goal wich is being "universal"...

[]s!

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

Re: new proposal: Translating Debian packages' descriptions

[Nick Phillips]

On Tue, Sep 04, 2001 at 02:24:41PM -0500, Steve Langasek wrote:

> > I think it's very important to have the translations in the *source*
> > package.
> 
> Also agreed.

Why? Each system will usually only require one language per package.
The rest, as far as any particular system is concerned, is just bloat.

It would be more powerful, flexible to keep translations physically (as
they are logically) separate.

Granted, there may be cases where it is useful to *be able* to put
translations into source/binary packages, but I believe that in most cases,
it will be more convenient and more useful to keep them separate.

Keeping them separate reduces space required in any particular archive,
or on any particular system. It reduces maintainer workload, reduces the
translators' reliance on maintainers, increases accountability (by allowing
each uploaded item to be signed by the relevant maintainer/translator),
reduces unnecessary upload/downloads, increases flexibility (for example
allowing multiple different sources of any particular language, or makes
it easy to provide unofficial translation archives), it makes more sense
given a potentially arbitrary number of translated languages...

As I said elsewhere, think of the archive as a big database (which it is).
Then think about how you would/should normalize the data.

When you ship bits around outside the database, it may be useful to be able
to encapsulate several related records from the database into one object.
Fine, but that doesn't mean that you should screw up your database and do
it that way all the time.

> > For the binary package, I don't know... - Gnome and KDE do include all
> > translations, and I think it's easier to handle. Additionally, disc
> > space is really cheap these days, so maybe it would be better just to
> > include all the descriptions, too.

Gnome and KDE include the translations because they know that that's the only
way they can ensure that everyone who distributes their packages distributes
the translations. They are designing their systems in the absense of any other
good working way of doing it *right now*. The fact that they do that in no
way implies that Debian should also do that.

> I think it does belong in the binary package; if not, I'm not sure why we
> would want it in the source package at all.

No reason at all. It doesn't make sense to have it in either, in most cases.

> I believe translated descriptions
> have just as much reason for inclusion in the binary package's control file
> (or in a functional equivalent) as the rest of the informational stuff that's
> in there.

No they don't. Translations are not providing extra information. They are
providing the same information in multiple different ways.

> If translated Description: fields in binary packages are not important, then
> why do we currently have the untranslated Description: in the control file?

Because you need *a* description, and in the past there has only been one
description, so there was no reason to normalise it out into a different
object. You don't, however, need 15, and when there are 15 or however many,
it makes sense to normalise them out.



Cheers,


Nick

-- 
Nick Phillips -- [EMAIL PROTECTED]
If you think last Tuesday was a drag, wait till you see what happens tomorrow!

Re: Sorry, broken packages - solved!

[Karl Voit]

Daniel Burrows ([EMAIL PROTECTED]) wrote:

> On Tue, Sep 04, 2001 at 06:23:37PM +0200, Karl Voit <[EMAIL PROTECTED]> was 
> heard to say:
> > Sorry, but the following packages have unmet dependencies:
> >   abiword: Conflicts: abi-fonts but it is not installable
> >Conflicts: abisuite but it is not installable
> >Conflicts: abiword-xml but it is not installable
> >Conflicts: abiword-expat but it is not installable
> >Conflicts: abiword-common but it is not installable
> >   communicator-smotif-476:  ddd: Conflicts: ddd-dmotif but it is not
> 
>   Upgrade to apt 0.5.4 :-)  (IIRC, the workaround is to disable all but
> one package archive in /etc/apt/sources.list)

TNX a lot!

I updated apt (and libc6) and then a "apt-get -f install" did the rest.

Seems to me that I have to keep my system more accurate by doing an "apt-get
upgrade" more often *g*

-- 
Karl VOIT
   [EMAIL PROTECTED]
   Graz University of Technology (Austria/Europe)
   Linux - because it works. (mostly ;)

pgpVW3JZWnl8Q.pgp
Description: PGP signature