Re: [Debian-l10n-devel] DDTSS broken
On 02/22/2012 03:10 AM, Cyril Brulebois wrote: Martin Eberhard Schauermartin.e.scha...@gmx.de (21/02/2012): As I can't magically fix all this by myself, I think that the only choice I have is detailing the simple alternative we have: - revert the change that drop long descriptions from Packages files - live with the localization effort of packages descriptions being broken and several localization teams demotivated ... especially the most active ones until now The next step after fixing the bug will be cleaning the database from about 30+K useless entrys. On ddtp.debian.org should be a database dump from last year... Maybe we should import this dump... and start a new importer... Gruss Michael Bramer http://www.deb-support.de/ email: m.bra...@deb-support.de Tel: +49 170 2253865 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f44a472.8030...@deb-support.de
dynamic Text in package descriptions
Hello
If you look a the control file from java-common-0.40, you found
something like this:
! Package: default-jre
! Architecture: any
! Depends: default-jre-headless (= ${binary:Version}), ${jre}${jre:version},
! ${misc:Depends}
! Provides: ${jre:provides}
! Description: Standard Java or Java compatible Runtime
! This package points to the Java runtime, or Java compatible
! runtime recommended for the ${jre:arch} architecture,
! which is ${jre} for ${jre:arch}.
I my optinion the variables in the description are a problem:
- the 'arch' is in the control file of the package, this information
don't need in the description.
- One package with the same version should be have the same description.
(Go to http://packages.debian.org/sid/default-jre:
'Standard Java or Java compatible Runtime
This package points to the Java runtime, or Java compatible runtime
recommended for the alpha architecture, which is openjdk-6-jre for
alpha.'
- This make extra load for the translation of this description.
I don't find something about this in the debian policy?!
Comments?
Gruss
Grisu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e4e52ef.9070...@debian.org
Re: Extended descriptions size
Goswin von Brederlow schrieb: Andreas Tille til...@rki.de writes: On Mon, 30 Mar 2009, Michael Bramer wrote: Goswin von Brederlow schrieb: I think the idea of using the Description-md5sum is that in most cases the md5sum remains identical for many versions. If you use the packages actual version then every upload will need a new translation entry or some fuzzyness to accept an older versions translation. I understood the sense of having md5sums in translation files. My suggsetion was an *additional* field which keeps the package version. In case there are different versions of a package in one dist (might be because an arch is lagging behind) either the md5sums differ and you store different translations anyway or the desciptions are equal and in this case use the highes available version number. Cant you have mutliple descriptions for the same package with different md5sums in the translation file? We _have_ mutliple descriptions for the same package with different md5sums in the translation file for sid. Gruss Grisu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Extended descriptions size
Goswin von Brederlow schrieb: Andreas Tille til...@rki.de writes: On Sun, 22 Mar 2009, Michael Bramer wrote: if we like to remove the long description from the package file, we must change apt in some way and use some other rules for select the right description (a new 'Description-md5sum' or the Version-Nr) I'd call the Version-Nr. a sinsible choice. ;-) Kind regards Andreas. I think the idea of using the Description-md5sum is that in most cases the md5sum remains identical for many versions. If you use the packages actual version then every upload will need a new translation entry or some fuzzyness to accept an older versions translation. ACK Gruss Grisu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)
Paul Wise schrieb: On Sat, Mar 21, 2009 at 4:58 PM, Neil Williams codeh...@debian.org wrote: It's another instance of duplication - why retain the long description in the Packages file while a translated version also exists from DDTP? Probably better for the description to be removed from the Packages file completely and the DDTP one contains the translated version and English ones for those with missing or outdated translations. That way, apt spends less time parsing the (smaller) Packages file when doing ordinary stuff like package installation and only needs to look at the DDTP information when specifically called as 'apt-cache search'. One issue is that many people will have disabled downloading translations so they'll need to change their configuration from none to en: APT::Acquire::Translation none; Since en will now be a Translation, perhaps a different config item is more appropriate: APT::Acquire::Description en; This will not work: apt use a md5sum from the sort and lang description (from the packages file) to find the right 'translation'. If you remove the long description from the packages file, apt can't do this task... if we like to remove the long description from the package file, we must change apt in some way and use some other rules for select the right description (a new 'Description-md5sum' or the Version-Nr) Gruss Grisu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497433: i18n.debian.org: [DDTP] Getting old descriptions when requesting new ones
On Mon, Sep 01, 2008 at 06:34:17PM +0200, Christian Perrier wrote: Package: general User: [EMAIL PROTECTED] Usertags: i18n.debian.org Usertags: ddtp Severity: normal PS: this bug should be moved to the i18n.debian.org pseudo-package - Forwarded message from Martin Eberhard Schauer [EMAIL PROTECTED] - Date: Mon, 01 Sep 2008 13:34:54 +0200 From: Martin Eberhard Schauer [EMAIL PROTECTED] To: Christian Perrier [EMAIL PROTECTED] Subject: Re: Churro aka i18n.debian.net down X-CRM114-Status: Good ( pR: 9.8622 ) At 19.08.2008 19:41 Christian Perrier wrote: Since Saturday, we're experiencing outages with churro, aka i18n.debian.net, aka ddtp.debian.net. Since churro is up again, its behavior is slightly unstable. While working on the german package descriptions, when ordering a new description, sometimes I get one that has recently passed the reviews or that i have already worked on. Yes, I know it... /var/ on churro was full (see http://ddtp.debian.net/munin/localdomain/localhost.localdomain-df.html) and the submit from ddtss to the ddtp-db was not working. (you get some 'internal Error'-Page as last reviewer... We now export all translations from the ddtss from the last 2 days and submit (per hand) this translations per mail interface again to the ddtp-db. sorry for that. (we must work on the filesystem layout on churro...) Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wenn ich die Folgen geahnt hätte, wäre ich Uhrmacher geworden! --- Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495643: Catalan DDTP issues
Package: general Severity: normal User: [EMAIL PROTECTED] Usertags: i18n.debian.org Usertags: ddtp - Forwarded message from Guillem Jover [EMAIL PROTECTED] - Date: Mon, 18 Aug 2008 22:15:03 +0300 From: Guillem Jover [EMAIL PROTECTED] Subject: Catalan DDTP issues Hi, The Catalan Translation file seems to have duped entries, and I think it's missing several others, like dacco-eng-users.s, as seen at: http://ftp.fi.debian.org/debian/dists/sid/main/i18n/Translation-ca I've not checked others, so it could be a general problem. On the DDTSS we have 42 pending translations for stuff that's quite specialized, which blocks translations for more important and common packages. I guess this is due to the force fetch problems mentioned before on the i18n list. Could someone please reset the pending list? thanks, guillem - End forwarded message - Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wenn ich die Folgen geahnt hätte, wäre ich Uhrmacher geworden! --- Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495643: Catalan DDTP issues
hi see bug #495643 On Mon, Aug 18, 2008 at 10:15:03PM +0300, Guillem Jover wrote: Hi, The Catalan Translation file seems to have duped entries, and I think it's missing several others, like dacco-eng-users.s, as seen at: http://ftp.fi.debian.org/debian/dists/sid/main/i18n/Translation-ca I've not checked others, so it could be a general problem. On the DDTSS we have 42 pending translations for stuff that's quite specialized, which blocks translations for more important and common packages. I guess this is due to the force fetch problems mentioned before on the i18n list. Could someone please reset the pending list? thanks i18n.d.n is still down... After a reboot/reconnection I can fix this... Thanks for the report. Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wenn ich die Folgen geahnt hätte, wäre ich Uhrmacher geworden! --- Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495643: Catalan DDTP issues
On Tue, Aug 19, 2008 at 08:57:30AM -0700, Steve Langasek wrote: On Tue, Aug 19, 2008 at 10:28:21AM +, Michael Bramer wrote: see bug #495643 Why has this been filed on general? see #388212 The bug is about the i18n debian infrastructure... Don asked for filling this bugs to gerneral (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388212#24). Did I made a mistake? Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wenn ich die Folgen geahnt hätte, wäre ich Uhrmacher geworden! --- Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liblinux-inotify2-perl 1:1.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Aug 2007 13:41:51 +0200 Source: liblinux-inotify2-perl Binary: liblinux-inotify2-perl Architecture: source i386 Version: 1:1.1-2 Distribution: unstable Urgency: low Maintainer: Michael Bramer [EMAIL PROTECTED] Changed-By: Michael Bramer [EMAIL PROTECTED] Description: liblinux-inotify2-perl - scalable directory/file change notification Changes: liblinux-inotify2-perl (1:1.1-2) unstable; urgency=low . * Thanks to LaMont Jones: * Work on all architectures that define the syscalls Files: b934ff3cd4d7616f0b4dd5d179bb84ba 634 perl optional liblinux-inotify2-perl_1.1-2.dsc 2555bb70f0ef0ad847213cb78a652318 2384 perl optional liblinux-inotify2-perl_1.1-2.diff.gz 13e0daad9c0bede10309a6307a94b015 21006 perl optional liblinux-inotify2-perl_1.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG1W3d+F6/RiWNh4ERAhQBAKCbmJdBowmOIY0IP4iaiXqeWtzyLgCfROAL /o5zY1Q/3tjL0wngMtfutts= =UN2c -END PGP SIGNATURE- Accepted: liblinux-inotify2-perl_1.1-2.diff.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-2.diff.gz liblinux-inotify2-perl_1.1-2.dsc to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-2.dsc liblinux-inotify2-perl_1.1-2_i386.deb to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liblinux-inotify2-perl 1:1.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 22 Jun 2007 21:25:10 +0100 Source: liblinux-inotify2-perl Binary: liblinux-inotify2-perl Architecture: source i386 Version: 1:1.1-1 Distribution: unstable Urgency: low Maintainer: Michael Bramer [EMAIL PROTECTED] Changed-By: Michael Bramer [EMAIL PROTECTED] Description: liblinux-inotify2-perl - scalable directory/file change notification Closes: 382417 416329 Changes: liblinux-inotify2-perl (1:1.1-1) unstable; urgency=low . * upgrade (closes: #416329, #382417) Files: b04a926e9d96febf9603f0e91f2c60f4 634 perl optional liblinux-inotify2-perl_1.1-1.dsc ae6919262fbc5613304b2388b99e4081 9807 perl optional liblinux-inotify2-perl_1.1.orig.tar.gz 3fa266c11649be1da53f236665c664fe 2143 perl optional liblinux-inotify2-perl_1.1-1.diff.gz 4f17c23ddb514136ea2084f723b9ee94 20876 perl optional liblinux-inotify2-perl_1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGfUrj+F6/RiWNh4ERAvUNAJ0UM2NDsEGr2ZogSur5mS/KvO0G8gCgjVbW HujIsI9Qw0P4Qol5fa2JVMg= =rmmt -END PGP SIGNATURE- Accepted: liblinux-inotify2-perl_1.1-1.diff.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-1.diff.gz liblinux-inotify2-perl_1.1-1.dsc to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-1.dsc liblinux-inotify2-perl_1.1-1_i386.deb to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1-1_i386.deb liblinux-inotify2-perl_1.1.orig.tar.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting package translations into the mirrors (was Re: APT 0.7 for sid)
On Sun, Jun 10, 2007 at 07:16:49PM +0200, Martijn van Oosterhout wrote: On 6/10/07, Frank Küster [EMAIL PROTECTED] wrote: That's because they're not the latest files. The latest output form the DDTP project is here: http://ddtp.debian.net/debian/dists/sid/main/i18n/ There have been requests to have the FTP site mirror from there or have some other mechanism to get the data to the main servers. As far as I know it needs an FTP master to fix. I understand the reason for it not having been done earlier was lack of support in apt? Have you submitted a bug against ftp.d.o? I couldn't find one. I havn't because I didn't think it was my problem. But I found it here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109955 It's six years old, the URLs have changed but thats it. I came to this rather late so I don't know the story. Just google for apt-i18n brings up some stuff. There's this: http://lists.debian.org/debian-i18n/2006/06/msg00107.html http://lists.debian.org/debian-devel-announce/2006/06/msg3.html When I last asked about it I was told to wait, so I've done nothing. I've CCed grisu, perhaps he knows what's going on... Thanks for the info. I close the bug. The files are already on the ftp master (see ftp://ftp.debian.org/debian/dists/unstable/main/i18n/) as translation files. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung der Linux-Rechner erst mal ins Schwimmen kommen. -- Matthias Peick pgpTY1wj54j1F.pgp Description: PGP signature
Re: Translated packages descriptions progress
On Sun, Aug 06, 2006 at 05:59:38PM +0200, Martijn van Oosterhout wrote: On 8/4/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] wrote: no. the currend ddtp-server don't support the review process, sorry. No problem, just to let the translators aware. We can use the pseudo-urls system to review that, before the translator send it back to the ddtp-server. I've been playing a little and have written a bunch of scripts which I've unimaginativly named DDTS Satellite. It can send and receive emails from the DDTS and provides a web interface where you can do the actual translating. It has the capability to let people review translations before sending them. Reviewers can also amend the translations straight away. It's a bit rough, but I'm using it for my own translation submissions. If people think it's interesting I can put up the source somewhere. Especially the reviewing bit might be handy, since the main server doesn't do that well right now. nice. Where can we download the script? Gruss Grisu -- Michael Bramer - http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Zur Strafe, weil Du nicht rechnen kannst, musst Du zwei Wochen lang ein Rechenzentrum mit 25 NT Servern administrieren. Heisst das nicht Rebootzentrum? :) [ Roger Schwentker u. Philipp Buehler in d.a.s.r ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On Fri, Aug 04, 2006 at 12:32:59PM -0300, Felipe Augusto van de Wiel (faw) wrote: I hope we can test the new apt version and can get this version to sid and after some days to testing. Ok, I will work on a few tests for pt_BR. BTW, the translations are all in UTF-8, or it doesn't matter? All translations are in UTF-8 in the db. But a translator can send his translation in any encoding. He can use: Description-de.UTF-8: or Description-de.latin1: or Description-de.SOME_ENCODING: The ddtp-server transforms this in UTF-8 and store the translation in his db. Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linux is like a wigwam: no Windows, no Gates, Apache inside -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On Sun, Jul 30, 2006 at 06:55:19PM -0300, Felipe Augusto van de Wiel (faw) wrote: On 07/30/2006 03:26 AM, Michael Vogt wrote: Dear Friends, Hi Michael, Hi the current version of apt in debian/experimental has support for translated package descriptions and we have a the current translations available for sid on the mirrors (currently not on ftp.debian.org itself because of the mirror split I suspect). In a couple of mirrors that I checked, the translations look a little bit out-of-date (from May.2006), is this expected and for now the idea is just have it for tests, or we will have it being update automagically (which would be wonderful). :-) Yes, yesterday I see the out-of-date files too. The problem ist a broken cronjob on ddtp.debian.net. sorry I will check and fix this. Please help testing the new code and report problems and/or success. It should be enough to install apt, python-apt, synaptic from experimental and if your LANG is set to something other than C it should download the appropriate translation indexes and displays them with apt-cache or synaptic (warning: not everything is translated yet). It is already based on the recent work of Michael Bramer (grisu)? I don't work on apt and co. This work is based on otavio's work. But the running ddtp-server is my work. But only for the next months. We like to switch the ddtp as part of the new i18n-framework. I have a few doubts, because I would like to ask the Brazilian Portuguese Team to start working on it again, so here they go: The review process is the same? no. the currend ddtp-server don't support the review process, sorry. There are also coordinators with special commands to the pdesc server? (At least for Brazilian team, we will need to update that address). Is there anything else that we could do to help DDTP? dito. The server don't know all the special commands from the old ddtp-server yet. sorry. No 'help', no 'admin', no 'review' etc. But I like to add some of them. But we should concentrate on the work of the i18n framework. We exchange a lot of ideas about the DDTP during DebConf6, we also tried to add this as a pet release goal for etch, but for quite a while now, there were no news, thanks for this report. :-) yes. But all the ideas about the DDTP during DebConf6, are ideas about the new i18n framework. I hope we can test the new apt version and can get this version to sid and after some days to testing. Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liblinux-inotify2-perl 1.01-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 26 Mar 2006 00:08:57 +0100 Source: liblinux-inotify2-perl Binary: liblinux-inotify2-perl Architecture: source i386 Version: 1.01-2 Distribution: unstable Urgency: low Maintainer: Michael Bramer [EMAIL PROTECTED] Changed-By: Michael Bramer [EMAIL PROTECTED] Description: liblinux-inotify2-perl - scalable directory/file change notification Closes: 358957 Changes: liblinux-inotify2-perl (1.01-2) unstable; urgency=low . * now with mips and mipsel support (closes: #358957) Files: 8eef07d7d1c4cd643a9afd7cfb793170 655 perl optional liblinux-inotify2-perl_1.01-2.dsc f5c5fdde37393a747c490ddd762e4d45 2363 perl optional liblinux-inotify2-perl_1.01-2.diff.gz d36c501c50180ea4bd35014e1f573521 20770 perl optional liblinux-inotify2-perl_1.01-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEJc9f+F6/RiWNh4ERArVxAJ9eqU8vIGMXXcmeAEHmOQ1N+2joEwCfXKHl g047o6Ub+kQLRGfelMz+Eis= =jrLD -END PGP SIGNATURE- Accepted: liblinux-inotify2-perl_1.01-2.diff.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-2.diff.gz liblinux-inotify2-perl_1.01-2.dsc to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-2.dsc liblinux-inotify2-perl_1.01-2_i386.deb to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liblinux-inotify2-perl 1.01-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Mar 2006 14:15:30 +0100 Source: liblinux-inotify2-perl Binary: liblinux-inotify2-perl Architecture: source i386 Version: 1.01-1 Distribution: unstable Urgency: low Maintainer: Michael Bramer [EMAIL PROTECTED] Changed-By: Michael Bramer [EMAIL PROTECTED] Description: liblinux-inotify2-perl - scalable directory/file change notification Changes: liblinux-inotify2-perl (1.01-1) unstable; urgency=low . * Initial Release. Files: b7abee4a70170a41f1394d21f0f17b33 655 perl optional liblinux-inotify2-perl_1.01-1.dsc be76bdd0224025bcbee1df72cada1271 9377 perl optional liblinux-inotify2-perl_1.01.orig.tar.gz 51a9ff484a60543f7b692109afc4caec 2024 perl optional liblinux-inotify2-perl_1.01-1.diff.gz e0362a72dea0255169bc8ea2a6bcce1f 20680 perl optional liblinux-inotify2-perl_1.01-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEDDfz+F6/RiWNh4ERAuvdAJ48oVvhtobgI3Bx0Ks5XX/BT71+ZwCfcHHn nHRodMxyURZaTZjT4SHjqiY= =FkQr -END PGP SIGNATURE- Accepted: liblinux-inotify2-perl_1.01-1.diff.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-1.diff.gz liblinux-inotify2-perl_1.01-1.dsc to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-1.dsc liblinux-inotify2-perl_1.01-1_i386.deb to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01-1_i386.deb liblinux-inotify2-perl_1.01.orig.tar.gz to pool/main/libl/liblinux-inotify2-perl/liblinux-inotify2-perl_1.01.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
On Fri, Jul 29, 2005 at 11:32:18PM +0200, Clément Stenac wrote: Someone suggested an announcement should be sent to d-d-a. What do you think ? Yes, go to it and find some reviewer. Will do... Maybe you should add a 'get a random Description' link on your Page... I'm not sure it would be very good, because it's better to review related packages together. It's however true that it could probably make the whole stuff more attractive. how will you handel changes in the description (from upstream, aka package maintainer)? some changed description from this night: changed description from dvorak7min (dvorak7min) changed description from libnetclient-ocaml-dev (netclient) changed description from libocamlnet-ocaml (ocamlnet) changed description from libocamlnet-ocaml-dev (ocamlnet) Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux »A train station is a station where trains stops. But what are workstations?« signature.asc Description: Digital signature
Re: Packages descriptions review
On Sat, Jul 30, 2005 at 04:08:10PM +0200, Clément Stenac wrote: how will you handel changes in the description (from upstream, aka package maintainer)? By comparing all descriptions when we are done. For packages which have a new descriptions, a manual review/merge will be needed. No, this will not work. We habe 10 and more changes in the description _per_day. Some are very stupid (like http://ddtp.debian.net/ddt.cgi?diff1=16963diff2=953 ) other more complex (like http://ddtp.debian.net/ddt.cgi?diff1=16966diff2=2177 ) If you need some weeks for the review of all descriptions (and you will need more time), you can check this all again. You must update unreviewed description daily. Checked reviewed descriptions again and show changes to the reviewer, if the review ist not finished. Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Frage: Stammt der Begriff UNIX aus einem Dialog zwischen einem Deutschen und einem Engländer? - This is for you nix. -- Andreas (Felix) Kalbitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
On Fri, Jul 29, 2005 at 08:23:26AM +0200, Clément Stenac wrote: If you go to review all description, please check the technical parts also. Sure, thanks for the reminder. I added it to the wiki page Thanks I think the interface is now ready for the work to begin. However, very few people replied. Someone suggested an announcement should be sent to d-d-a. What do you think ? Yes, go to it and find some reviewer. Anyway, it is possible to start the work with the interested persons now... I set up a table on the wiki page ( http://wiki.debian.net/?PackagesDescriptionsReview ). Please register yourself on this page before starting work on a section. Maybe you should add a 'get a random Description' link on your Page... I think we should begin by the desktop packages (x11, gnome, kde, ...). I don't think base packages should be given a high priority as people don't often want to install them. Libs and devel packages are also lower priority IMHO and you should add some 'send the new description to the BTS' After the two reviewer write a new/better/improved/... description, the new description should be send to the BTS as minor bug. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Du wei?t doch... jeder hat die Software, die er verdient hat. --- Felix von Leitner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
On Tue, Jul 26, 2005 at 08:55:23PM +0200, Clément Stenac wrote: Hello, Following the recent discussion about packages descriptions (see http://lists.debian.org/debian-devel/2005/07/msg01074.html and later), and based on Lars Wirzenius' idea, I started working on preparing a general review of all package descriptions. If you go to review all description, please check the technical parts also. Thinks like this: . o Adduser can create new users and groups and add existing users to existing groups. o Deluser can remove users and groups and remove users from a given group. . shoud like this: . o Adduser can create new users and groups and add existing users to existing groups. o Deluser can remove users and groups and remove users from a given group. . (see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description for more infos) Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Fuer die einen ist es Windows - für die anderen der laengste Virus der Welt... signature.asc Description: Digital signature
Documentation of alioth?
Hello Maybe I miss something, but have we some Documentation about alioth/gforge? And is there some alioth mailinglist (or is debian-devel ok for more alioth questions?) Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux it was hard to write, so it should be hard to read signature.asc Description: Digital signature
Re: description writing guide
On Wed, Dec 04, 2002 at 12:55:50PM -0500, Colin Walters wrote: I think the package descriptions are a very important product of this project. They're going to be one of the first things people see when they use Debian, and their quality directly reflects on the quality of Debian. I've been putting in some random efforts here and there to comment on new package descriptions, but I finally sat down and committed my thoughts on description writing in a semi-coherent form: In the DDTP I collect some rules about the descriptions. You can find this on the end of the FAQ. (http://ddtp.debian.org/ddtp-text/misc/ddts-faq.txt) Maybe this help Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux The UNIX Guru's View of Sex: gawk; talk; nice; date; wine; grep;\ touch; unzip; strip; touch; gasp; finger; gasp; mount; fsck; more;\ yes; gasp; umount; make clean; make mrproper; sleep pgptsa4s0CmWw.pgp Description: PGP signature
Re: Why DDTP? shouldn't it be DPTP? (was Re: spanish translations in DDTP now)
On Wed, Dec 04, 2002 at 11:29:47PM +0100, Javier Fernández-Sanguino Peña wrote: I'm curious as to why was DDTP (Debian Documentation Translation Project) ^ Description was chosen for the project in helping translate, exclusively, the package descriptions in Debian. Shouldn't this be renamed to DPTP (Debian Packages Translation Project). As far as I know the DDTP has nothing to do with: - translating .po files in packages (for upstream maintainers) - translating documentation of the DDP - translating documents provided by packages (manpages, GNOME/KDE help pages...) - translating the installation system - translating the website ok. Maybe we will change this to DTP (Debian Translation Project) in remote future. I have this task (translation of .po files and man pages) on my privat TODO list. And for your information: the DDTP support already the translation of the debconf templates of the debian-install system (this is in the normal debconf part) and the server also support the description of the normal package description of the udebs packages (didesc part). But the last one is not used now. Please, Michael, don't use that name for the project. It's quite misleading (both internally and to outside of the Debian project) and should be changed. I don't really see a problem. Read the FAQ or the ddtp.debian.org web page and you will find the words 'Debian _Description_ Translation Project'. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux ...und Windows ist ein Grafikadventure... Mir sind die Textadventures manchmal lieber ;-) -- Juergen Ilse pgpyRDCT2ya8j.pgp Description: PGP signature
Re: And why DDTP does not use webwml? Re: Why DDTP? shouldn't it be DPTP? (was Re: spanish translations in DDTP now)
On Thu, Dec 05, 2002 at 01:23:33PM +0100, Jose Carlos Garcia Sogo wrote: One question I have is why DDTP does not use webwml. This is now part of the Debian project (as it's under ddtp.debian.org), but it's completely incoherent with Debian www style, and it also is the part of the Debian web with less translations! I hope you have this also in your TODO. no. I don't like web pages and I don't make this all. I found some webmaster, and he make all the work with this web stuff. Maybe _he_ will move to webwml and maybe he have this on his TODO list. (I don't think so, btw.) I cc: this to [EMAIL PROTECTED] If you (or others) have questions about the web pages, ask the webmaster. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux I am Borg of FSF - resistance is proprietary pgpiw7I4v8A4n.pgp Description: PGP signature
Re: debconf template translations from ddtp
On Wed, Nov 27, 2002 at 05:11:26PM -0500, Joey Hess wrote: Michael Bramer wrote: The ddtp will produce also po-debconf files in future. I must only write some scripts for it... I did something like: for lang in cs da de es fr hu it ja nl pl pt_BR ru ; do wget http://ddtp.debian.org/debconf/template_unstable/base-config/templates-$lang; done rename 's/-/./' templates-* debconf-gettextize templates nice... if some one use debconf-po-files. I don't want to use the result for base-config though. The generated po files reference only the downloaded templates file, while base-config uses three seperate templates files which should be referenced prperly by the po files. And I have no tools to tell which of the translations on this site are more up-to-date than the ones in debconf. I see the problem. I am not sure, but can you make something like: for $file in ddtp-po.* do cat $file po/template.po done after your sripte. Gettext should handel this... Maybe 'msgmerge' can help. If I understand it in the right way, you can use this to merge two po-files... And of course base-config is in debian cvs where anyone can check in a translation, in the po-debconf form that I prefer. So all this close to a step backwards for base-config, maybe not so for everything else though. maybe for base-config. But 'all' the other packages don't use cvs.debian.org, don't use translated debconf templates, don't support changes in search some translators etc. Maybe some of the base-config template translators can use this translations in the ddtp and can update your po files per hand... Gruss Grisu FYI: only 800 debconf templates and we have all debconf templates from sid translated into german :-) -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wissensdurst ist die fluessige Form von Bildungshunger
Re: debconf template translations from ddtp
On Tue, Nov 26, 2002 at 05:54:21PM -0600, Steve Langasek wrote: On Wed, Nov 27, 2002 at 12:21:28AM +0100, Michael Bramer wrote: You can download translated template files from http://ddtp.debian.org/debconf/template_unstable/$PACKAGE (like http://ddtp.debian.org/debconf/template_unstable/base-config/templates-de for German) Is it your intention for these translations to only be made available on the ddtp website, instead of being submitted directly to maintainers as bug reports? I can do this. But IMHO the best should be, if some dh_-script download the last translations from some web site. comments about this? I write some scripts to make links in the PTS to the ddtp now. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux | X-Mailer: Mozilla 4.73 [en] (Win98; I) Wie sollst Du auch verstehen können? -- Stefan Scholl in dasr pgpuMXyzI2CSD.pgp Description: PGP signature
Re: debconf template translations from ddtp
On Wed, Nov 27, 2002 at 01:41:34AM +0100, Luca - De Whiskey's - De Vitis wrote: On Tue, Nov 26, 2002 at 05:54:21PM -0600, Steve Langasek wrote: We've started the translation of debconf templates some weeks ago. See http://ddtp.debian.org/debconf/gnuplot/ddts-stat.png It seems that you don't use po-debconf: isn't it? AFAIK we all should switch to po-debconf for a better translation system. The ddtp will produce also po-debconf files in future. I must only write some scripts for it... Is it your intention for these translations to only be made available on the ddtp website, instead of being submitted directly to maintainers as bug reports? I would like to recive the translation as bugs, so i hope you'll set it up in this way sooner or later. some other with this opinion? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux | X-Mailer: Mozilla 4.73 [en] (Win98; I) Wie sollst Du auch verstehen können? -- Stefan Scholl in dasr pgpg6czFCTgUf.pgp Description: PGP signature
Re: debconf template translations from ddtp
On Wed, Nov 27, 2002 at 02:23:56PM +0100, Simon Richter wrote: Javier/Michael, On Wed, Nov 27, 2002 at 02:04:28PM +0100, Javier Fernández-Sanguino Peña wrote: some other with this opinion? I believe most Debian Developers share this opinion. The BTS is the place to keep track of package issues, I, personally, don't like to go to other places (or don't have time to investigate them) to include patches/bug fixes (excluding upstream of course). I believe that translations change so often that the real bugs would get lost in a pile of auto-generated bug reports. IMO it would be nice to have a note new translations available on the BTS and PTS pages, so you know that you need to call ddtp-update-translations or whatever the mighty script will be called. IMHO this changes of the translation is the big problem. And the server translate the description not on a package base. If I templates file has 10 templates, the server will submit 10 bug reports per language. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Every use of Linux is a proper use of Linux. -- John Maddog Hall, Keynote at the Linux Kongress in Cologne pgpWI0bJKT6vP.pgp Description: PGP signature
debconf template translations from ddtp
Hello We've started the translation of debconf templates some weeks ago. See http://ddtp.debian.org/debconf/gnuplot/ddts-stat.png The debconf template translation is still in a beta stage and only few translators from 2-3 language teams are making translations every now and then. But now the first translated debconf templates from the ddtp is downloadable from the ddtp web site. At http://ddtp.debian.org/debconf/maintainer/new.all.txt you'll get a list of all packages including new translated debconf templates. (File http://ddtp.debian.org/debconf/maintainer/new.all.sort.txt is sorted by number of new translated templates) If you are a package maintainer, you can obtain a package-related file from http://ddtp.debian.org/debconf/maintainer/$PACKAGE with more information. http://ddtp.debian.org/debconf/maintainer/base-config as example: |../maintainer/new.all.txt: 84 base-config |../maintainer/new.cs.txt:- 26 7 33 base-config |../maintainer/new.da.txt:- 29 7 33 base-config |../maintainer/new.de.txt:- 29 12 33 base-config |../maintainer/new.es.txt:- 25 6 33 base-config |../maintainer/new.fr.txt:- 25 6 33 base-config |../maintainer/new.hu.txt:- 19 6 33 base-config |../maintainer/new.it.txt:- 20 6 33 base-config |../maintainer/new.ja.txt:- 21 7 33 base-config |../maintainer/new.nl.txt:- 20 6 33 base-config |../maintainer/new.pl.txt:- 27 6 33 base-config |../maintainer/new.pt_BR.txt:- 30 9 33 base-config |../maintainer/new.ru.txt:- 22 6 33 base-config The ddtp server has 84 new translated templates for the base-config package (first line). The package uses 33 templates of which: - 29 are translated into German, and - 12 are in ddtp's db only (not in the unstable base-config package) You can download translated template files from http://ddtp.debian.org/debconf/template_unstable/$PACKAGE (like http://ddtp.debian.org/debconf/template_unstable/base-config/templates-de for German) Comments? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher. -- A. Einstein pgpStFK7rXjFs.pgp Description: PGP signature
Request: patching APT
On Sun, Oct 06, 2002 at 09:56:06PM +0200, Michael Bramer wrote: A future APT version will download one or some 'Translate-$lang' file(s) at 'update'-time. After this download it show a translated description instead of the english form, if it found a translated description of the package with the right md5 chechsum. The enviroment of the user will controlled this process (LANG, LANGUAGE, LC_MESSAGES, etc). With this the package system will never show a outdated translation. Ok, we should start patching APT... Jason don't have time for this patching and now I am searching some C++ programmer to patch APT. The task can be split in this sub-task: - download the 'Translate-$lang' from a http/ftp/... source (like the Release file) and store the values in the APT-db - examine the LANG etc. environment and choose the right translated package description from the APT-db. Maybe you can help or you know some C++ developer who has time. Please mail [EMAIL PROTECTED] and we can start the work. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Unix ist ein Konzept! Windows hat garkeins (oder wo sind die Gemeinsamkeiten von Win 3, 9x, und NT?) -- Lakmal Gunasekara [EMAIL PROTECTED] pgpKdGU0hXRNY.pgp Description: PGP signature
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Sat, Aug 31, 2002 at 07:06:47AM +1000, [EMAIL PROTECTED] wrote: In a couple of days uncompressed Packages files for unstable will cease to be generated, and bzip2'ed Packages files will be generated in their place (actually, if you look carefully, they're already being generated). Sources.bz2 files are being added too. If you have any scripts looking at the uncompressed Packages files, you should change them to look at either the gzip or bzip2 versions now. this break apt-proxy with rsyncing Packages files. Please don't remove the normal uncompressed Packages files. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Make a software that is foolproof, and someone will make a better fool. pgpmAN2YpE0Ba.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Wed, Apr 10, 2002 at 10:25:22AM +1000, Martijn van Oosterhout wrote: On Tue, Apr 09, 2002 at 05:02:34PM +0200, Michael Bramer wrote: you propose to add 'some' diff files for all files on ftp-master.d.o? With rsync we need only one rsync-checksum file per normal file and all apt's need only download the neededs parts. You get the point? With the standard rsync algorithm, the rsync checksum files would actually be 8 times larger than the original file (you need to store the checksum for each possible block in the file). I don't see that the checksum file is larger than the origanl file. If the checksum file is larger, we will have more bytes to download... This was not the goal. What you are suggesting is that the server store checksums for precalculated blocks on the server. This would be 4 bytes per 1k in the original file or so. The transaction proceeds as follows: 1. Client asks for checksum list off server 2. Client calculates checksums for local file 3. Client compares list of server with list of client 4. Client downloads changed regions. Yes, this is the way.. Note, this is not the rsync algorithm, but the one that is possibly patented. maybe I don't understand the rsync algorithm... IMHO the rsync algorithm is: 1.) Computer beta splits file B in blocks. 2.) calculate two checksums a.) weak ``rolling'' 32-bit checksum b.) md5sum 3.) Computer B send this to computer A. 4.) Computer A search in file A for parts with the same checksums from file B 5.) Computer A request unmatch blocks from computer B and build the file B. I get this from /usr/share/doc/rsync/tech_report.tex.gz right? The _only_ difference is: precalculate the checksums on computer B Or maybe store the calculated checksums in a /var/cache/rsync/ cache dir. sorry, I know that partentes don't have any logic, but this is the same algorithm, only with some cache. Comments? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Nicht geschehene Taten ziehen oft einen erstaunlichen Mangel an Folgen nach sich. -- S.J. Lec pgpQY2Jd0eOPS.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Wed, Apr 10, 2002 at 01:26:17AM -0700, Robert Tiberius Johnson wrote: This looks like an interesting algorithm, so I decided to compare it to the diff scheme analyzed in http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg00502.html The above message also gives my analysis methodology. The results: - The following table summarizes the performance of the checksum-based scheme and the diff-based scheme under the assumption that users tend to perform apt-get update often. I think disk space is cheap and bandwidth is expensive, so 20 days of diffs is the best choice. Scheme Disk space Bandwidth --- Checksums (bwidth optimal)26K 81K diffs (4 days)32K 331K diffs (9 days)71K 66K diffs (20 days) 159K 27K can you explain your counts? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Nicht geschehene Taten ziehen oft einen erstaunlichen Mangel an Folgen nach sich. -- S.J. Lec pgp2Mvffax1Cu.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Wed, Apr 10, 2002 at 08:29:49PM +1000, Martijn van Oosterhout wrote: On Wed, Apr 10, 2002 at 09:22:50AM +0200, Michael Bramer wrote: On Wed, Apr 10, 2002 at 10:25:22AM +1000, Martijn van Oosterhout wrote: With the standard rsync algorithm, the rsync checksum files would actually be 8 times larger than the original file (you need to store the checksum for each possible block in the file). I don't see that the checksum file is larger than the origanl file. If the checksum file is larger, we will have more bytes to download... This was not the goal. That's because the client doesn't not download the checksums. Look below. maybe I don't understand the rsync algorithm... IMHO the rsync algorithm is: 1.) Computer beta splits file B in blocks. 2.) calculate two checksums a.) weak ``rolling'' 32-bit checksum b.) md5sum 3.) Computer B send this to computer A. 4.) Computer A search in file A for parts with the same checksums from file B 5.) Computer A request unmatch blocks from computer B and build the file B. I get this from /usr/share/doc/rsync/tech_report.tex.gz Computer A wants to download a file F from computer B. 1. Computer A splits it's version into blocks, calculates the checksum for each block. 2. Computer A sends this list to computer B. This should be 1% the size of the original file. Depends on the block size. 3. Computer B takes this list and does the rolling checksum over the file. Basically, it calculates the checksum for bytes 0-1023, checks for it in the list from the client. If it's a match send back a string indicating which block it is, else send byte 0. Calculate checksum of 1-1024 and do the same. The rolling checksum is just an optimisation. 4. Computer A receives list of tokens which are either bytes of data or indications of which block to copy from the original file. all ok. I write the same above, except point '4' and you switch A and B... Notice that: a. The server (computer B) does *all* the work. If you use A as Server, the client make all the work. c. Precalculating checksums on the client is useless d. Precalculating checksums on the server is also useless because the storage would be more (remember, checksum for bytes 0-1023, then for 1-1024, 2-1025, etc). It's faster to calculate them than to load them off disk. Precalculating of the _block_ checksums is _not_ useless. This checksums are only 1% the size of the original file (depends on the block size). So, the main difference between what you are proposing is 1 versus 2 requests per file. And rsync definitly only has one. The main difference is: The client and not the server make all the work! Besides, look at the other posts on this thread. Diff requires less download than rsync. I read it, but I don't understand it. But this is not the problem. IMHO the diff is a kind of a hack and a cached rsync is a nice framework. But this is only my taste... Maybe I should read the rsync-source-code...Done Ok, with the normal rsync program the client make the block checksums and the server search in the file... Thanks for your help. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Hummeln koennen wirklich stechen, tun das aber nur in extremen Ausnahme- Situationen. NT tut in solchen Situationen nichts mehr. aus d.a.s.r pgphEKKQCFH3u.pgp Description: PGP signature
Re: Debian's problems, Debian's future
hello we sould stop this and start after woody again... On Thu, Mar 28, 2002 at 08:17:46PM +0100, Jeroen Dekkers wrote: On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote: I'd suggest using diffs, as this brings the best results and is the http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg01303.html (I use apt-pupdate all the time now, it works for me (tm)) Sorry, diffs are simply silly! Use rsync with the uncompressed Packages file and diffs aren't necessary. Or use a packer which doesn't hinder rsync from saving (gzip --rsyncable). This isn't server friendly. no. sorry. I must say this: We can use rsync on the client site. - get a rsync-checksum file (use a fix block size) - make the check on the client site and - download the file partly per ftp/http - make the new file with the old and downloaded parts With this the server need only extra rsync-checksum files. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wenn man sich naeher mit Linux beschaeftigt, wird man nie versuchen, WinNT das Attribut stabil aufzudruecken! ([EMAIL PROTECTED]) pgp24zK6DHCTU.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Sat, Mar 30, 2002 at 04:49:25AM +0900, Junichi Uekawa wrote: [EMAIL PROTECTED] (Otto Wyss) cum veritate scripsit: Packages.0 from 28-March is probably the newest and the smallest upgrade is problably the diff for one day (209k uncompressed, 50k gzipped). On the 28th rsync's download was 130k, today it was less than 100k. I don't know why your uncompressed diff is bigger than what rsync says. Also note that this is a one-time thing, and can be served through normal http protocol, or ftp, or whatever. rsync requires handholding from the server side. Which is unlikely to happen for every single server serving Debian mirror. no. technical you can move this all to the client and use ftp/http for the download of parts of the files.. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux How hard can it be, it's just an operating system? -- Linus Torvalds pgp2uWU9pT7sG.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Sat, Mar 30, 2002 at 02:11:00AM +0100, Wichert Akkerman wrote: - I would like to have templates with substitution fields. Already exists. Any references? How about the debconf manual? but sorry, we have some outdated translations in debconf templates files. No translator know, if someone change the english template. Please can we use gettext or something other without 'outdated translations'? Joey ? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux it was hard to write, so it should be hard to read pgpJ83wRzeC7l.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Thu, Mar 28, 2002 at 04:55:17PM +0100, Otto Wyss wrote: I'd suggest using diffs, as this brings the best results and is the [diffs for Packages files that is] wooo!!! http://people.debian.org/~dancer/Packages-for-main-i386/ # Time for suggesting is up, please implement. Indeed, it appears it has been implemented more than once. http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg01303.html (I use apt-pupdate all the time now, it works for me (tm)) Sorry, diffs are simply silly! Use rsync with the uncompressed Packages file and diffs aren't necessary. Or use a packer which doesn't hinder rsync from saving (gzip --rsyncable). right. Now I search in the lists and found the old mails... Maybe someone like to read the mails and reply: http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00757.html Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux it was hard to write, so it should be hard to read pgp6S2IxrFfDb.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Fri, Mar 29, 2002 at 11:16:44AM +0100, Eduard Bloch wrote: #include hallo.h Joey Hess wrote on Wed Mar 27, 2002 um 02:21:49PM: That is a rather misleading summary of the situation, which as a subscriber to debian-boot, you should understand better. Have you done any testing of the proposed base-config patch? Sure. Peter's patches are AFAIK not ready and I have a bad feeling about his dbootstrap modifications. I have a testing installation image with hacked base-config (my patches), but I was disappointed, since many debconf templates in called packages templates in the first base-config steps were not translated. It is too late to change them all, so I can only keep calling it a pity and hope that people mastering customised CD sets would contact me or Peter. can you put this files online? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman pgpJ7WkUkIsXF.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote: On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote: This isn't server friendly. no. sorry. I must say this: We can use rsync on the client site. - get a rsync-checksum file (use a fix block size) - make the check on the client site and - download the file partly per ftp/http - make the new file with the old and downloaded parts With this the server need only extra rsync-checksum files. I beleive this method is patented by somebody, which is why it's not in use/supported. Other than that, it's very nice idea. I beleive there may be some semi-implementations around somewhere. The concept is no different from normal rsync. has someone a pointer? This is rsync, only the server is the client und the client work as server... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Da haben wir es, emacs ist eine Religon, kein Editor. Ich bin nicht bereit einer Goetze meinen Spreicher zu opfern. -- Werner Olschewski pgpMi6mUUNMnB.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Tue, Apr 09, 2002 at 08:02:14AM -0500, Steve Langasek wrote: On Tue, Apr 09, 2002 at 09:53:44AM +0200, Michael Bramer wrote: On Sat, Mar 30, 2002 at 02:11:00AM +0100, Wichert Akkerman wrote: - I would like to have templates with substitution fields. Already exists. Any references? How about the debconf manual? but sorry, we have some outdated translations in debconf templates files. No translator know, if someone change the english template. Please can we use gettext or something other without 'outdated translations'? Joey ? If you are concerned that translators receive automatic notification when a source debconf template has changed, that's an infrastructure problem. Neither debconf nor gettext has automatic translator notifications built-in, and debconf's templates are not an inferior solution for not providing this. I know this. And as infrastructure we can use the ddtp. I have already work on this. But in the last weeks I don't have real time and I break this sub project. Debconf, if used correctly, does correctly handle merging of outdated translations. See debconf-mergetemplate(1). ok. thanks. I don't know this. Maybe I must RTFM... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ja, aber der Bootvorgang ist doch so sch?n mit den Wolken und so. Das st?rt meiner Meinung nach garnicht. (Martin Heinz zum Rebooten von M$-W) pgp8vSydUMyki.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Tue, Apr 09, 2002 at 04:34:43PM +0200, Jeroen Dekkers wrote: On Tue, Apr 09, 2002 at 09:09:39AM +0200, Michael Bramer wrote: no. sorry. I must say this: We can use rsync on the client site. - get a rsync-checksum file (use a fix block size) - make the check on the client site and - download the file partly per ftp/http - make the new file with the old and downloaded parts With this the server need only extra rsync-checksum files. IMHO it's better to make just diffs instead of extra rsync-checksum files and then having to download all parts of those files. you propose to add 'some' diff files for all files on ftp-master.d.o? With rsync we need only one rsync-checksum file per normal file and all apt's need only download the neededs parts. You get the point? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Like sex in high school, everyone's talking about Linux, but is anyone doing it? -- Computer Currents pgpA31TJ6OvFp.pgp Description: PGP signature
Re: Debian's problems, Debian's future
On Tue, Apr 09, 2002 at 10:25:04PM +1000, Martijn van Oosterhout wrote: On Tue, Apr 09, 2002 at 10:58:24AM +0200, Michael Bramer wrote: On Tue, Apr 09, 2002 at 06:39:19PM +1000, Martijn van Oosterhout wrote: I beleive this method is patented by somebody, which is why it's not in use/supported. Other than that, it's very nice idea. I beleive there may be some semi-implementations around somewhere. The concept is no different from normal rsync. has someone a pointer? This is rsync, only the server is the client und the client work as server... Unfortunatly no. I just remember it as a passing comment while talking with Andrew Tridgell (creator of rsync). A google search turns up oblique references at: http://rproxy.samba.org/doc/notes/server-generated-signatures.txt 'The current RProxy specifications at sourceforge.net do not have the client calculating the signature. Instead, the client gets the signature from the server when it first downloads the file, and saves this signature (just like an ETag) for use when re-loading the file. This mechanism was chosen only because of possible patent problems with client calculation of signature. These patent problems may need to be investigated.' Read the mails. The checksum-file is _download_ from the server and _not_ calculated from the client! http://www.sharemation.com/~milele/public/rsync-specification.htm (near bottom) the same... http://pserver.samba.org/cgi-bin/cvsweb/rproxy/doc/calu_paper/calu_paper.tex?annotate=1.1 the same... http://olstrans.sourceforge.net/release/OLS2000-rsync/OLS2000-rsync.html the opposite point. maybe I don't understand some points... 3 times server generateted checksums are forbidden by partent and one time a client generateted checksums are forbidden... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux GNU does not eliminate all the world's problems, only some of them. - Richard Stallman - The GNU Manifesto, 1985 pgpKim1jMD89C.pgp Description: PGP signature
Re: We still need sponsors!
On Wed, Jan 09, 2002 at 11:18:05AM +0100, Tille, Andreas wrote: OK. If I understand this right that would mean that the control file would state Maintainer: Future Maintainer [EMAIL PROTECTED] and my own address will be in the changelog (like in an NMU). Where is the place to make clear that: The package is called a sponsored package ... Are there any fields/conventions? I make a ~/.forward-PACKAGENAME on master.d.o and put [EMAIL PROTECTED] and the not-yet-maintainer address in this file. I use [EMAIL PROTECTED] in the controll file and all is ok... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Windows gehört zu den von sich aus unlogischen Systemen ohne Tradition. Anselm Lingnau in de.comp.os.unix.discussion pgpO6U3TryErq.pgp Description: PGP signature
Re: my.debian.org
On Sat, Dec 29, 2001 at 03:25:57PM +0100, Stefano Zacchiroli wrote: On Sat, Dec 29, 2001 at 01:52:25PM +0100, Noel Koethe wrote: As a debian developer, I like an easier way to find and keep up with all the nice reports out there keeeping track of me. I think it would help myslef and others do a better job if they were more accessable. One suggestion is a portal page in the vein of MyYahoo -- i.e. a web page generated specifically for me, linking to all those Debian statistics and reports directly relevant to me. Just build your own personal page (replace login with your debian login) This is not the point: you are able to write that page because you know what link put in it. The point is to collect all informations about reports in a place that is well known, easy to know for new developers (i.e. readable in the developers reference) and kept up to date. yesterday I add a new status pages on request of a maintainer: http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] for your list... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux als typisch für linux benutzer gilt aber wohl immernoch eher was ala: man blafurz | grep RTFM | cut -c /d 10-2837 | uahha (Adam Kopacz) pgpn9CWORKt2K.pgp Description: PGP signature
Re: L10n of Debconf templates
On Mon, Dec 31, 2001 at 01:59:33AM +0100, Denis Barbier wrote: there are 2 ways for a package maintainer to deal with l10n-ed Debconf templates: either put all translations in a single file, or separate each language in its own template file. The former has a severe drawback, because when English text is modified, there is no flag to tell that translated text is outdated, and translators won't notice. So it would be really nice if package maintainers do follow the latter, and learn to play with Debconf goodies (debconf-getlang, debconf-mergetemplate, dh_installdebconf). If my figure are right, 258 source packages have translated Debconf templates, but only 71 in separate files. and if my figure are right, we have a lot of open bug reports with translated Debconf templates (see URL:http://auric.debian.org/~grisu/debian_translation/ In reality we need a framework for this translations... like the DDTP/DDTS. IMHO this all is not the task of a package maintainer. He don't know all the languages, he must ask for a update all the times after a change, he must search proofreaders for all the languages, He must track bugs and improvments in the translation, ... This can make all a good framework. We can add other parts to DDTS (like debconf templates), but - Now I have no time (btw: maybe someone will take over my package cupsomatic-ppd?) - debconf templates are more difficult (sometimes you need more knowledge for a translation) - We have some translated templates in the packages, some in the Debian-BTS, ... - Somebody must write a mail-parser and a 'update' client - Maybe we must rewrite more parts of the DDTS, the DDTS is now very package description centric I have this all on my todo list. But I will make this all, after the pdesc is 'finished'. (not really finished, but I have some open TODO-Points on my list...) If someone will help, write a mail... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux als typisch für linux benutzer gilt aber wohl immernoch eher was ala: man blafurz | grep RTFM | cut -c /d 10-2837 | uahha (Adam Kopacz) pgpap14qFzLCU.pgp Description: PGP signature
Re: my.debian.org
On Mon, Dec 31, 2001 at 11:23:19AM +0100, Noel Koethe wrote: On Mon, 31 Dez 2001, Michael Bramer wrote: The point is to collect all informations about reports in a place that is well known, easy to know for new developers (i.e. readable in the developers reference) and kept up to date. yesterday I add a new status pages on request of a maintainer: http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] for your list... You have to add .txt to the end. example: http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] yes, sorry And If we have a working packages.debian.org, I will make real HTML pages with links to the packages.debian.org. After this, you must add .html at the end... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Windows kann kein Virus sein. Ein Virus ist in der Regel klein, effizient und verrichtet seine Arbeit ohne dabei abzuschmieren. pgpVjPN7tdIHQ.pgp Description: PGP signature
Re: my.debian.org
On Mon, Dec 31, 2001 at 12:08:30PM +0100, Martin Michlmayr wrote: * Michael Bramer [EMAIL PROTECTED] [20011231 10:35]: yesterday I add a new status pages on request of a maintainer: http://ddtp.debian.org/pdesc/maintainer/[EMAIL PROTECTED] Your packages file is outdated. This page lists me as the maintainer for a package of which I'm no longer the maintainer. not the Packages file was outdated. The update_db process had not updated the Maintainer db from the maintainer file. This is fixed and the build process should fix this. and now I see the next bug: the build process already run, but it don't remove the old files... See: ! $ cat /home/grisu/public_html/ddtp/maintainer/[EMAIL PROTECTED] ! dejapt_BR fritdaplhunlsk sv_SE ukrucs ! [EMAIL PROTECTED] !dadadodo !cplayde pt_BR ! dejapt_BR fritdaplhunlsk sv_SE ukrucs ! [EMAIL PROTECTED] !cplayde pt_BR I fix this also and start a new build process of this files. sorry. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Auf Windows 95 laufen so ziemlich alle Spiele. F?r ernsthaftes Arbeiten sollte man aber zus?tzlich ein Betriebssystem installieren. -- unknown pgp1hASfZJgGn.pgp Description: PGP signature
Re: my.debian.org
On Sun, Dec 30, 2001 at 10:03:34AM +0100, Stefano Zacchiroli wrote: On Sat, Dec 29, 2001 at 12:00:14PM +0100, Martin Michlmayr wrote: * Stefano Zacchiroli [EMAIL PROTECTED] [20011229 11:32]: BTW, why madison isn't packaged? We could package it and mention it in the developer reference. Because the tool requires the SQL database on pandora and auric. Cool, anyway I see that madison use postgresql, so just a few command line switch that specify the db host, the port and eventually username and password. In such a way it can be used by developers using ssh tunneling or something similar. Personally I have a slow connection (standard 56K modem) and I really prefer using it with ssh tunneling rather than on an interactive ssh session. maybe you search: $ apt-show-versions -a -p bb bb 1.2-9 install ok installed bb 1.2-9 stable bb 1.3rc1-0.1 testing bb 1.3rc1-1unstable bb/stable uptodate 1.2-9 Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wer in Reih und Glied marschiert, hat bereits meine Verachtung verdient -- Albert Einstein... So let's install Linux! pgpH67igWifqV.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation
On Sun, Sep 16, 2001 at 09:55:14AM +1000, Herbert Xu wrote: Michael Bramer [EMAIL PROTECTED] wrote: 1.) notification mails This is already fixed. Verybody can stop the server to send this mails. And I send a No it's not. You have to send an email for every package that you maintain. This is simply unacceptable. If I don't stop receiving these mails soon, I will have to impose a site-wide ban on mail from that location. Yes, I know this problem. I will improve this and I have add all your packages on the nonotification list. Thanks Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux »Trau nur nicht der Diskretion der Behörden, mein Junge. Je mehr es davon gibt, desto mehr Futter brauchen sie.« -- Heinrich Böll, »Billard um halbzehn« pgpLLdbyl4E1H.pgp Description: PGP signature
Re: Web interface for Debian Description Translation Server
On Thu, Sep 13, 2001 at 11:37:12PM +0100, Jaime E . Villate wrote: Where you can find more information about it. At this moment we are translating descriptions into Spanish and Portuguese (as spoken in Portugal). Grisu is taking care of the translations into German, French, Italian and Brazilian Portuguese. If any other groups want to use our web interface, please let me know (it can be done in a couple of minutes). some comments: - The 'grisu' ddts has some more languages: de (german), pt_BR (Brazilian Portuguese), ja (Japanese), fr (french), it (Italian), nl (Netherlands), pl (Polish), da (dutch), hu , sk , sv_SE See also http://auric.debian.org/~grisu/ddts/ddts-stat.png for the stage of development in the last weeks. - We have a beta web interface for the ddts, but we need cgi's and cvs on auric (or a other debian machine). - We can also start a new languages group in a couple of minutes. You must only ask. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linuk is like a wigwam: no Windows, no Gates, Apache inside pgpnbF53sQZyM.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Fri, Sep 14, 2001 at 09:11:36AM +0200, Martin Quinson wrote: On Thu, Sep 13, 2001 at 04:25:43PM +0200, Wichert Akkerman wrote: Previously Michael Bramer wrote: And if we get translators, why not add a some more languages. We have now in the ddtp only 11 languages at the beginning and we don't have real support in the project, in dpkg etc. Debian can do that. Other might not be able to do that. The world is bigger then Debian. Even Debian can't do that for now, because nobody know how to deal with description translation in a scalable manner. And debian has some translations now and can use it really. We proposed a first solution (the one with translation package) which did not scale well in number of package. We changed it (with translation in package or in extra file), but it did not solve the publishing issue. You proposed a solution (translation in control file) which does not scale in number of language, and makes the translator job hard (keeping track of outdated solutions). We have propose some solutions. And the last proposal solve - the publishing issue (for apt and for dpkg) - and scale in number of package and number of language If we use this proposal or if we use a other not-yet-writen proposal, we need the support from dpkg and apt. Please can we make a brainstorming with the apt, dpkg and translator developer? We should find a technical solution of this technical problem. Maybe we can trashing gettext, but we need a solution. And IMHO we don't need this solution in some years, we need it in some months. We need a decision. If we have a decision, the ddts can support any open format (that I understand). Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Schlag mich! Kratz mich! Nenn mich OE-Nutzer! pgptcJQVxtcal.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Fri, Sep 14, 2001 at 01:41:35PM +0200, Wichert Akkerman wrote: Previously Michael Bramer wrote: Please can we make a brainstorming with the apt, dpkg and translator developer? As I already said, not now besides from what we've just being doing. I have to admit that the fact that this discussion keeps repeating itself and people don't seem to accept what we (dpkg people) tell them makes me rapidly loose interest in continueing it. As I also said, at this moment we simply can't implement it anyway due to missing infrastructure. We'll get there, but it just might take a bit longer then you would like. That's life. Ok, Now I understand it, Thanks We should find a technical solution of this technical problem. Maybe we can trashing gettext, but we need a solution. And IMHO we don't need this solution in some years, we need it in some months. You can't get it in months for two simple reasons: * dpkg internals aren't ready * you can't do it during a freeze anyway I suggest that you focus on fixing the translation infrastructure first while us dpkg people focus on dpkg. Right now I'm still being spammed with ddts emails which I have to procmail to /dev/null, and I also saw that you still need to integrate two different translation systems. Sounds like there is enough to be done. 1.) notification mails This is already fixed. Verybody can stop the server to send this mails. And I send a command to the server and it will not send notifications on this packages: base-passwd, doc-central, dpkg, dpkg-dev, dpkg-doc, exuberant-ctags, fdflush ipmi-control, kernel-patch-ipmi-kcs, ksymoops, ldap-gateways ldap-utils, libldap2, libldap2-dev, lsb-release, modutils slapd, strace, tftp-hpa, tftpd-hpa, varmon, vim, vim-gtk vim-perl vim-python, vim-rt, vim-tcl, vim-tiny I hope I miss no of your package. If you have problemes, please mail me. Thanks and sorry. 2.) Yes, we translator have a lot of work. But this two or three translation systems, are not the real problem. We have already a beta web interface but we need cgi's and CVS on a debian machine. We now waiting for debian-admin. Finally I will wait now for a real solution and maybe I make some hacks to test and use this translations in the meantime. But please do me a favour: Before the dpkg people start with codeing, please make a proposal and discuss this proposal in the mailings lists. Thanks. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux I am Borg of FSF - resistance is proprietary pgpO78epyBird.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Fri, Sep 14, 2001 at 07:06:25PM +0200, Wouter Verhelst wrote: On Fri, 14 Sep 2001, Michael Bramer wrote: 1.) notification mails This is already fixed. Verybody can stop the server to send this mails. And I send a Perhaps it would be nice to mention this in the notification mail there is a mention in the notification mail. I quote: !If you don't like this mail in future send mail to ![EMAIL PROTECTED] !with the subject line !NONOTIFICATION package all !Replace 'package' with the package name. But if somebody ask, I send this mail myself. (something like If you don't want to receive these mails anymore, just send a mail to [EMAIL PROTECTED]) Oh, nice. But now we don't have a ddts.debian.org domain. 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 pgp6zUTYNEx6o.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Thu, Sep 13, 2001 at 08:55:44AM +0200, Martin Quinson wrote: You want to handle 2 by putting the translation in the package. No, I want it to be possible to have it in the package, but it might be elsewhere as well. Putting all translations in all packages doesn't scale, but having multiple translations in a package can be useful (think packages not in a full archive, for example a vendor shipping debs on a CD). So, you want to make possible for a package to contain meta-data about another package, am I right ? Or are you thinking about a separate file, not in a package, like the Packages.gz is ? IMHO he thinking about this way: The translations should in (optional) in the deb file of a package and 'elsewhere as well', like a Packages.gz or a Description.gz or a ... for the archive (for apt-get update and co) Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Es fehlen Informationen der Inhaltsratgeberkonfiguration. (aus einer Programmfehlermeldung) pgp1CChusPH8h.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Thu, Sep 13, 2001 at 02:35:46PM +0200, Wichert Akkerman wrote: But if you put the translation in the control file, you have to add almost hundred fields, on per locale: Description-fr ; Description-fr_FR ; Description-fr_CA ; Description-fr_BE just to have the more used french variants (and no, it would not be acceptable to merge all country variant of the language in the language. Think about pt_BR and pt_PT). Bogus. If you buy wordperfect does it have 96 different translations in it? Of course not, they only put in a few important ones. stop. wordperfect is no free software and they can only support some languages. Get KDE, we have 38 kde-i18n-* packages. This is the _minimum_. You say 'few important'. But what languages is important? Somebody say: throw away English and get Russian. Others like (or better _need_) Polish, german, Japanese, China, ... And if we get translators, why not add a some more languages. We have now in the ddtp only 11 languages at the beginning and we don't have real support in the project, in dpkg etc. (btw, the boot-floppies support now IMHO 19 languages.) If debian is a 'general OS', it will (and must) support more and more languages. Only some people can speak, read and understand english. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ist es nicht jedem selbst überlassen, ob er einen Arbeitsplatz wählt, bei dem Windows oder Zölibat Pflicht sind? pgpetRb3PvdH1.pgp Description: PGP signature
Re: splitting /var/lib/dpkg/status and handling desc translation (was: ddts notification)
On Thu, Sep 13, 2001 at 04:25:43PM +0200, Wichert Akkerman wrote: Previously Michael Bramer wrote: This is not just about Debian. It is about the dpkg packaging system, which can be (and is) used outside Debian just as well. That's decided by whoever makes a package. I don't expect everyone to feel the same way about translations as Debian does. Debian can do that. Other might not be able to do that. The world is bigger then Debian. all right. But dpkg should have the possibility to include 40 translations. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Falls Ihr Rechner zu oft blau macht ist es Zeit auf Linux umzusteigen. pgpOBv2IjkQaK.pgp Description: PGP signature
Re: new proposal: Translating Debian packages' descriptions
On Tue, Sep 11, 2001 at 12:05:25PM -0500, Steve Langasek wrote: On Tue, 11 Sep 2001, Martin Quinson wrote: On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote: - an output mecanism, including the fallback to original if the translation is outdated. You have either to rewrite msgfmt to do this job at previous step, or design a new function in dpkg, apt, grep-dctrl, and all programm using the translated descriptions. The end-user tools would never have to deal with outdated translations if the .mo file is assembled ahead of time in a central location. Match up the translations, insert them into the distilled .po file using the package name/version as the key, and you're done. one point: I get the package-1.2 from 'commercial german distributor' with german translation. And I watch (with apt-cache show) the description package-1.2.1 from security.debian.org? I don't see the german description... other point: I have a gnome-base-1.2 from HelixCode and show the description from gnome-base-1.2 from debian... But the description from both packages is not the same (I know our package management don't support this case, but we have this case in real (maybe)...) next point: You have in your apt-source some sources. Like a older CD-Rom with 2.1 and 2.2_r0, a uptodate 2.2_r3 from ftp.debian.org, testing and sid from http.debian.org. With this you have alle descriptions many times in the .mo file. (like package-0.9 from 2.1, package-1.4 from 2.2_r0, package-1.4.1 from 2.2_r3 and package-1.5 from testing and sid...) And with the pin feature of apt, more and more people have more sources in sources.list... If you change any tool of the gettext mechanism, you lost advantages from the translator point of view, like compendium, containing standard translations for reuse, or user-friendly tools like kbabel for translating, (including ispell possibility, which is implemented in kbabel, and some others) I'm not suggesting replacing the format that translators will work with. I'm just disagreeing that standard .mo files are the best solution to be integrated into dpkg and apt. ... More direct lookups. Smaller .po files. Better integration with existing tools, instead of grafting a new arm onto our existing /var/lib/dpkg structure. Yes, .mo files are not the best thing. this is your point and you are right. But this is a other problem and we can solve this problem parallel. I propose this: - use (a unchanged) gettext now in dpkg and get the thing rolling. - change the gettext to use a optional 'md5sum-like' thing for a lookups. (save the translation with the md5sum of the orignal text as key) This .mo files can use all programmes with a lot of text and have the advantages of this. Please don't reinvent the wheel, improve the old wheel and make it chubbier. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung der Linux-Rechner erst mal ins Schwimmen kommen. -- Matthias Peick pgp6Fbio1IZ0O.pgp Description: PGP signature
Re: new proposal: Translating Debian packages' descriptions
On Thu, Sep 13, 2001 at 01:26:07PM -0500, Steve Langasek wrote: On Thu, 13 Sep 2001, Michael Bramer wrote: The end-user tools would never have to deal with outdated translations if the .mo file is assembled ahead of time in a central location. Match up the translations, insert them into the distilled .po file using the package name/version as the key, and you're done. one point: I get the package-1.2 from 'commercial german distributor' with german translation. And I watch (with apt-cache show) the description package-1.2.1 from security.debian.org? I don't see the german description... other point: I have a gnome-base-1.2 from HelixCode and show the description from gnome-base-1.2 from debian... But the description from both packages is not the same (I know our package management don't support this case, but we have this case in real (maybe)...) This is an interesting point, but the solution is simple. If package+version can't be used as a key to uniquely identify packages in the dpkg status database, then we key on whatever /is/ used by this database. apt use IMHO a 'long' pointer. like: security.debian.org_dists_potato_updates_main_binary-i386_Package_version But yes, this don't need the size of a normal description. next point: You have in your apt-source some sources. Like a older CD-Rom with 2.1 and 2.2_r0, a uptodate 2.2_r3 from ftp.debian.org, testing and sid from http.debian.org. With this you have alle descriptions many times in the .mo file. (like package-0.9 from 2.1, package-1.4 from 2.2_r0, package-1.4.1 from 2.2_r3 and package-1.5 from testing and sid...) If the descriptions remain constant for the packages, you're correct that there would be duplication. But should we not optimize for the common case? Most users won't keep /old/ sources in the list; few will even have testing, unstable, and stable in the list at the same time. No. stable and testing is more and more common. With pins you can install all from stable and some packages from testing/unstable. I make some talks about this feature and the user use it, after the know it. Believe me. I'm not suggesting replacing the format that translators will work with. I'm just disagreeing that standard .mo files are the best solution to be integrated into dpkg and apt. ... More direct lookups. Smaller .po files. Better integration with existing tools, instead of grafting a new arm onto our existing /var/lib/dpkg structure. Yes, .mo files are not the best thing. this is your point and you are right. But this is a other problem and we can solve this problem parallel. I propose this: - use (a unchanged) gettext now in dpkg and get the thing rolling. - change the gettext to use a optional 'md5sum-like' thing for a lookups. (save the translation with the md5sum of the orignal text as key) For the goal of getting support for translated descriptions into Debian as soon as possible, I think use of unmodified gettext is a reasonable choice. Yes. We should find a conclusion with the dpkg and apt developer. Only with a conclusion (maybe without gettext) our user can use this translations. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Der Optimist glaubt wir leben in der besten aller moeglichen Welten. Der Pessimist befuerchtet, dass das stimmt. pgp3FQRorGpXF.pgp Description: PGP signature
Re: dispersive translation via DDTS
On Fri, Sep 07, 2001 at 12:25:05PM +0400, Mikhail Sobolev wrote: On Fri, Sep 07, 2001 at 09:01:55AM +0900, Tomohiro KUBOTA wrote: However, I think the official translator should be able to be changed easily, though I don't have concrete idea now. The best way would be to make it possible for the translation coordinator. I can add this feature and put it now on my TODO list. If you or others need this feature now, please ask. I can make this by hand. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel. -- Jens Dittmar in de.comp.os.unix.linux.newusers pgpZERFaMcYDL.pgp Description: PGP signature
Re: Reasons why package central approach to handling translations may be suboptimal
On Fri, Sep 07, 2001 at 11:47:36AM +0200, Richard Atterer wrote: On Thu, Sep 06, 2001 at 08:10:10PM +0200, Michael Bramer wrote: no, don't re-invent the wheel. This all make gettext. We don't need patch apt, dpkg, other toold this way. We must only use a old, nice and tested tool: gettext. Nice, I wasn't aware it solves the encoding problem as well! I don't check it, but the info page assert this: ... `gettext' not only looks up a translation in a message catalog. It also converts the translation on the fly to the desired output character set. This is useful if the user is working in a different character set than the translator who created the message catalog, because it avoids distributing variants of message catalogs which differ only in the character set. ... The only place where it isn't 100% suited for our purposes is the Descriptions-XX.po, because the English text is duplicated. Would it See the last proposal, we can bypass this problem. With a Descriptions-XX file (without the .po and without the english description) we can reduce the download size. But we must make a work on the client side and we use the size on the client all the time. make sense to hack gettext to make it allow checksums instead of the English descriptions? Maybe. But we can use gettext now. Make a generall improvement to gettext to use optinal md5sum-.mo files. Gettext support a version number in the .mo file also. With this improvement all programs can use this feature. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel. -- Jens Dittmar in de.comp.os.unix.linux.newusers pgpVVTr42C1wP.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Thu, Sep 06, 2001 at 01:23:12PM +1000, Martijn van Oosterhout wrote: On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote: With this the maintainers get some mails from the translator project. More like now. Now we only at the start, now we don't make a real review process. Now we have only 10 languages. I thought there was mention of translations mailing lists where all the translations are sent to in addition to the maintainer. I thought that was the review process. yes and no. Now all french translations are send to the debian-i10n-french ML ist. Because of this we have more fr updates like de or pt_BR. But after some time the ddts server will make a own review process. It will send all finish translated description a second time to the translators for a review. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ja, aber der Bootvorgang ist doch so sch?n mit den Wolken und so. Das st?rt meiner Meinung nach garnicht. (Martin Heinz zum Rebooten von M$-W) pgpCOb2Lao7PM.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 03:56:38PM -0500, Adam Heath wrote: On Wed, 5 Sep 2001, Wichert Akkerman wrote: Previously Nick Phillips wrote: Well, shouldn't it? Wouldn't it make sense to have the translated description in there rather than the original one? I actually makes more sense to remove even the english description from status to another location. Note, that there is no reason dpkg could not be modified to read from multiple status files. what? sorry, but in a other mail you say: It needs to be stored, in /var/lib/dpkg/status, as a single file. This is so that dpkg can make safe updates to it. Trying to sync multiple files is not a simple solution. I am right and the translated description don't need be store in the status file? Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Wie haben andere Linux Benutzer ihr `erstes Mal' mit Linux erlebt?? Wir haben danach gemeinsam eine Gitanes geraucht und nochmal ueber alles geredet. -- P.Vollmann und Stefanie Teufel in dcolm pgplyEQLoJbS1.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 10:42:12PM -0500, David Starner wrote: On Thu, Sep 06, 2001 at 01:08:52AM +0200, [EMAIL PROTECTED] wrote: On Wed, 5 Sep 2001, Branden Robinson wrote: On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote: The maintainer need not do anything. Maybe he don't know the translation. The user only use this. This need only the translators. While we're on the subject, can you get someone to translate your mails into a comprehensible dialect of English? Branden, please don't be rude. True, Branden was rude. But the fact that grisu's emails are sometimes hard to understand has been a stumbling block for me; it would certainly help to get a translator/editor for the full blown proposals. sorry, about this problem. Maybe someone can help and translate the proposal. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux --== Free Software: Contribute nothing, expect nothing ==-- pgpiIjO3UkQvb.pgp Description: PGP signature
Re: dispersive translation via DDTS
On Thu, Sep 06, 2001 at 04:12:12PM +0900, Tomohiro KUBOTA wrote: According to the FAQ, a person (A) who translated a package into a language will has a priviledge on the translation of the package. I.e., if someone (B) wants to modify the translation, B needs A's help for his/her translation to be finally adopted. A problem of this policy is that if A has gone the project, nobody will be able to modify the translation. Another problem is that leading translator will continue to load the responsibility of the pakcage translation. Fear of this continuing and growing responsibility can hesitate translators to translate as many packages as possible. Yes, I make the first translator like a owner of the translation. And since 2(?) weeks, only the first translator can upload a new translation. If a other translator send a changed translation to the server, it will send a mail to the first translator with the old and new translation and a diff. This is the first step of the BTS in the ddts. Now we have only the notification mail. In future the server will make this: - the translator must resende the package (maybe unchanges) or close the bug - If the translator don't send the bug back to the system in 4 weeks, he will remove as translator of this package and the bug submitter get a 'you can take over this package' mail - If the submitter don't take over the package, the server will put the description back in the pool again. Also can every coordinator change a translation on request. I rather like a more dispersive equality model like CVS. In CVS, every committer have equal right to commit their modifications. We will think about committing priviledge control (account issuing) to avoid attack to DDTS. I think the account issuing job should be done by language cordinators. what is your opinion? Solve the above solution the problem? The server need a translator per description, it need a email address. If a maintainer change a description, the server will send a update mail to the translator. For it the server need the email address. I only read the FAQ of DDTS. I have never experiened this situation. Sorry if I misunderstand the FAQ. one thing to the ddts: The ddts is only at the beginning and I change daily the code. We have now only 60% of the ddts running. I have a long TODO list and some ideas for the future. If you have problems or improvements, please write a mail. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Linux zu benutzen adelt nicht! Es bildet. pgp47KEAFvFzO.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Thu, Sep 06, 2001 at 08:43:10PM +1000, Hamish Moffatt wrote: On Wed, Sep 05, 2001 at 02:44:01PM +0200, Michael Bramer wrote: See also the other mail: 50 changes in 10 days in main/sid In a single package? Huh? no. The description of 50 deb-packages from the debian distribution main/sid/binary-i386 (with 6000 Packages) had changed in the last 10 days. But if you include the translation only in the debian/control you have - delays (maybe we have a override file and can solve this) - you will have outdated translations (like debconf now) Yes, such is life. I don't see these as being sufficient reason to invent a completely new system for dealing with this data. No outdated translations is a very big problem. The system should better show untranslated descriptions than outdated translation. Also the delay is a big problem. And if the the maintainer fast and upload after a change in the translation, we kill all the autobuilder. A translation is no 'data' like Dependes, Description, Package. A translation is only a translation, a other form of the data in a other languages and a other encoding. And we don't need a completely new system for translations! We have a old, very well tested system and we propose to use this system: gettext. Gettext make all the work and we don't need a new system in dpkg and apt. - you must patch dpkg etc. in a wide way This is not a good excuse. dpkg is a Debian-specific tool, and so it should be modified if there is good reason to do so. Don't work around it. I agree with this. If we need new features in dpkg, we should patch it. And yes, we have propose a patch for dpkg. But you should not break the dpkg with a big patch only for translation. Make it smart. Use this -9/+30 patch and you have it. We can include the translation in the package. This is not the problem, but please not in the control file. The translation is no new information of the package, it is only a translation. Only a other form of the orignal text. I don't see why the distinction is necessary. sorry, it is usefull. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Weiß vielleicht jemand warum ich meine Freundin ständig anrufen soll, seitdem sie ihr neues Handy mit Vibrationsalarm hat? (Volker Flohr in daa'ooo) pgpT2CQTG5mk0.pgp Description: PGP signature
Re: Reasons why package central approach to handling translations may be suboptimal
On Thu, Sep 06, 2001 at 03:31:49PM +0200, Richard Atterer wrote: On Thu, Sep 06, 2001 at 03:42:00PM +0900, Junichi Uekawa wrote: I have been reading the DDTS thread, and seeing that it was resolving into a each package should maintain their translation. I would like to present what I think may be problematic in that approach : 1. This results in filing random bugs in BTS in random manner. [snip] I think there's an answer to this problem: When the maintainer updates the translations of his package, this should be fully automated. E.g. just one command update-translations --from-mbox my_mail_archive which fishes out the DDTS messages (which are sent in a standard layout), or, for people lucky enough to be permanently online, an update-translations --from-web command in debian/rules which gets the translation updates directly from the DDTS server. So far, *everything* related to a Debian package can be found in the corresponding source package. I don't think it's a good idea to change this. full agree 2. A package is re-uploaded with translation. There is a package uploaded with one-line changelog saying something like Merged spanish templates. It is a load to autobuilder/ftpmirror/etc. and of course manual intervention to rebuild a package means that an error occurs, and it does. The main problem here is that translation start after the initial upload of packageto Debian happens, which means there will be a -2 Debian package which will include the translation, and a -1 Debian package will have no translation. Yes, that's one of the basic problems. IMHO with the proposed override mechanism via Descriptions-XX.po (or whichever form it is going to have), this is mostly solved - anyone getting the -1 package from testing will already see the translation. People tracking unstable may or may not see them, depending on how often they update and on the speed of the translators. Some people are concerned that their daily update from unstable will need too much bandwidth because of all those extra uploads. If the override mechanism works, I see no reason not to have a policy don't re-upload if only the translation changed. full agree 3. No choice of I want this locale and not others. I assume in particular you mean I prefer this _encoding_? This is a point that hasn't been discussed at all so far. see below Will there be one description .po file per language in the source package, or one for all translations? The alternatives here are: In a .po file is only one languages. So we have n Description.po file (n = Number of supportet languages). A User must only downloads the needed Descriptions files. In the source we have control-de.po, control-fr.po, control-es.po, ... maybe all in one subdir. - Supply descriptions in UTF-8, and recode them for the user's current encoding on the user's machine. Nice and clean, but requires support (possibly quite extensive changes) in dpkg/apt. NB, we _do_not_ need full Unicode support in all of Debian for this, just in the tools that deal directly with the description data. no, don't re-invent the wheel. This all make gettext. We don't need patch apt, dpkg, other toold this way. We must only use a old, nice and tested tool: gettext. - Supply descriptions in UTF-8 and recode them to a default encoding that root can configure on each machine. Do the recoding immediately after an apt-get update or dpkg -i, so the UTF-8 version is never stored on the machine. Might be the way to go for the moment, even if it's not ideal. Most importantly, it is upwards-compatible with the first solution above. we don't need this all - Pick one default encoding per language and just assume the user uses that encoding. Problematic: Should we ever want to change the default encoding, there'll be lots of packages using the old encoding, and we'd be stuck with it. yes, we use one default encoding per languages in the ddtp. I'm all for at least _supplying_ the translations in UTF-8, even if they're not stored on the user's machine like that for now. Note that this does not even mean that the translators need to produce translations in UTF-8 - the DDTS can recode their work into UTF-8. In future the ddts will make this and send UTF-8 encoded po files. I have get a request von Wichert to use UTF-8 only. We can latin-X etc recode to UTF-8, so this all is no problem. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Win0.98 supports real multitasking - it can boot and crash simultaneously.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Tue, Sep 04, 2001 at 09:35:48PM +0200, Richard Atterer wrote: Now the server can only mail notifications to all packages or to no packages. Should I stop it? Comments? The way I see your current proposals, such notifications will /eventually/ be necessary because maintainers will need to update their source packages with translations. some, or better a lot of maintainer ask for this notifications. Some maintainer would like to see all translations. Only with this he can make improvments, check the translation etc. Until then, it's not really necessary. IMHO, we should first reach a conclusion as to *how* a package maintainer should add the translation to the package. yes, it is not really necessary, like bug mails from the bts to the maintainer. And yes, we should find a conclusion *how* we add the translation to the package and to the distribution. This is a problem and we should find a solution. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux The UNIX Guru's View of Sex: gawk; talk; nice; date; wine; grep;\ touch; unzip; strip; touch; gasp; finger; gasp; mount; fsck; more;\ yes; gasp; umount; make clean; make mrproper; sleep pgpA6IE56PLrJ.pgp Description: PGP signature
Re: How many people need locales?
On Wed, Sep 05, 2001 at 12:12:06AM -0400, Ben Collins wrote: On Wed, Sep 05, 2001 at 12:19:01PM +0900, Junichi Uekawa wrote: Ben Collins [EMAIL PROTECTED] immo vero scripsit This isn't a matter of not using it, it's a matter of a sane base install. Perhaps base-config could ask if the user wants locales. Know what? That question is being asked in english _anyway_. Having a few well-known questions asked in English is fine, having a sequence of questions in English is scaring a lot of people away, at least in Japan. You might be ignorant about this, but English language is not understood by everybody. Don't make assertions. I never said everyone understands it. The point is, as it stands now, you have to go through the entire install in english...not just a few questions..._all_ of them. That needs to be fixed first. sorry Ben, but this is already fixed! If you get a Debian in German with german BFs, you get _all_ in german. After the install you have a LANG=de_DE. The first thing you see in english is: - exim (it don't use debconf... not easy to translate) - maybe some 'debconf' templates - the package descriptions We have german, french, ... BFs since years. We have translated a lot of debconf templates sine one year (in german we have 75%, see http://auric.debian.org/~grisu/debian_translation/index-de.html) and now we start with the package description. Some guides are also translated sine some time. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Demzufolge ist Windows wie Nutella: furchtbar suess und schlecht fuer die Zaehne. -- Norbert Kunka pgpj4AUxede7L.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Tue, Sep 04, 2001 at 05:40:25PM -0500, Adam Heath wrote:
On Tue, 4 Sep 2001, Michael Bramer wrote:
A proper solution, at the very least, invovles storing the data in the
foo.deb{control.tar.gz/control} file.
gettext is not a hack. Gettext for translations and dpkg use gettext
is self for translation. Why re-inventing the wheel?
gettext can not really be used for this data.
It needs to be stored, in /var/lib/dpkg/status, as a single file. This is so
that dpkg can make safe updates to it. Trying to sync multiple files is not a
simple solution.
no, it does not store there. And I can explain it:
The translation is no new information, it is not new package
metadata. It is only a translation, a other form of the exact same
information.
You can update /var/lib/dpkg/status, you can change the format, you
can do all things with it. You and you don't break the system. The
system use only gettext and get a translation.
I quote Wichert:
'It has nothing to do with package metadata and does not belong there.'
He don't mean translation, but he has right. No package metadata
should not in include in the controll file and not in
/var/lib/dpkg/status.
I propose to store the translations in a some po.files and store this
in foo.deb{control.tar.gz}. But not in the control file.
They must be stored inline inside status/available. This is the only sane way
to implement atomic file updates.
you don't need atomic file updates with the translations.
See a other example: the menu system.
This information is not in the control file, but you can make updates
without problems.
The translation is only a other form of the same information. You
don't need this information while the update process. You need the
translation only
- after the installation/update process (like dpkg --list)
- and before the installation/update with dselect, apt-cache show,
seach.
There is no need of a atomic file updates.
If you store the translation as normal field in the control file (like
Description-de: dff) you have outdated translations with the time.
And outdated translations is a very big problem.
zcat Packages_de.gz Packages_jp.gz | dpkg --merge-lang
and?
If in the dpkg database are changed description and in the Packages_de
file is one/some translation from the old description, you don't find
this this way. You will get outdated translation in the dpkg database.
Only one number: in the last 10 days we have 50 changed description
in sid/main
If a description is already translated, we need 1-20 days to
change the translation also. You will have outdate translation all the
time in sid and testing. And we must handle this problem.
Or didn't I understand your 'dpkg --merge-lang'?
this make the patch and the patch work. I don't stress the patch and
maybe it has one or two bugs. But it work with Descriptions on my
system.
Please stop just applying this to Description fields. Make it generic. dpkg
supports user-defined fields, so this proposal/implementation should as well.
If we talk about translation, this is not a big problem. You must only
use gettext all the time. Maybe we can throw away the 'maintainer
name' problem with this. (You know it: maintainer fields with
ÖÄÜöüüßåñïééõú... in the name.)
We need only one .po file, like this
msgid Werner Mueller [EMAIL PROTECTED]
megstr Werner Mülller [EMAIL PROTECTED]
And the german User see the 'right' Name of this maintainer all the
time.
Gettext is generic with translations. You must only use it in the
output process of dpkg, dselect and apt.
Gruss
Grisu
--
Michael Bramer - a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux
Und mit doppelseitig bestrichenen Sandwiches baut man das
Perpetuum Mobile nach Murphy. -- Kristian Koehntopp in dasr
pgpRnHrQG2aDE.pgp
Description: PGP signature
Re: step by step HOWTO switch debian installation into utf-8
On Wed, Sep 05, 2001 at 05:03:50PM +1000, Brian May wrote: Vociferous == Vociferous Mole [EMAIL PROTECTED] writes: doesn't look like it to me: [503] [pluto:bam] ~ LANG=en_AU:en_GB dia Gdk-WARNING **: locale not supported by C library Vociferous From another message (in one of the numerous Vociferous translated descriptions threads), you can set Vociferous LANGUAGES=en_AU:en_GB, and it will do fallback. Are you sure? As far as I can tell, the value of LANGUAGES is totally ignored. no gettext use it as fallback. I find it in the source code and a note in the ABOUT-note in the source tar from gettext. But LANGUAGES is a extra eviroment, it is only used, if you have set a normal LANG too. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Das ist das entscheidende Problem. Hirn ist heutzutage eine sehr seltene und teure Resource -- Ullrich von Bassewitz [EMAIL PROTECTED] pgptGtQWYjbt2.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 12:20:42PM +0100, Nick Phillips wrote: On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote: It needs to be stored, in /var/lib/dpkg/status, as a single file. This is so that dpkg can make safe updates to it. Trying to sync multiple files is not a simple solution. no, it does not store there. And I can explain it: Well, shouldn't it? Wouldn't it make sense to have the translated description in there rather than the original one? (I hope I understand it right...) No, don't touch the files in /var/lib/dpkg/*. Don't insert the translation, don't replace the orignal with the translation. We should support not only one language, see should support more languages at the same time with dpkg and with a nice fallback path. And if we don't change the files in /var/lib/dpkg/, we don't need a big patch in dpkg. dpkg is a core element in debian and it must be stable. If we change a lot, we break (maybe) a lot. This is not nice. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ein Prompt! Um Himmelswillen! Ein Prompt!! HILF pgpp7bt9qrP3Y.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 01:13:35PM +0200, Radovan Garabik wrote: On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote: If we talk about translation, this is not a big problem. You must only use gettext all the time. Maybe we can throw away the 'maintainer name' problem with this. (You know it: maintainer fields with ÖÄÜöüüßåñïééõú... in the name.) We need only one .po file, like this msgid Werner Mueller [EMAIL PROTECTED] megstr Werner Mülller [EMAIL PROTECTED] And the german User see the 'right' Name of this maintainer all the time. except that I would suggest to do it the other way round, having the proper full name as original, and individual languages will transform the name according to their established charset. (So that all latin 1 and latin 2 languages does not need to translate the proper form Werner Müller, but latin 2 languages will ASCIIfy Javier Fernandez-Sanguino Peña into Pena, and koi8-r languages (russian) will use ASCII only form of both) this is ok. This was not a proposal. it was only a first thought and should show, that gettext can make more (and not only Descriptions...) Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux We just typed make... -- (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) pgpDlbQuuhk0H.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote: On Wed, Sep 05, 2001 at 12:11:56PM +0100, Nick Phillips wrote: I'd have thought that the current situation re. maintainers putting translations into .debs makes it blindingly obvious that requiring them to do so in order for a translation to become available is a bad idea. Do package descriptions change so regularly that translated descriptions couldn't be submitted through the bug tracking system and included in the next upload? Most of my packages have never had their description changed from when I first wrote it. It would be better if we could just include translated descriptions in the debian/control file. See also the other mail: 50 changes in 10 days in main/sid But if you include the translation only in the debian/control you have - delays (maybe we have a override file and can solve this) - you will have outdated translations (like debconf now) - you must patch dpkg etc. in a wide way We can include the translation in the package. This is not the problem, but please not in the control file. The translation is no new information of the package, it is only a translation. Only a other form of the orignal text. Please read the last proposal, I explain a possibly solution in it. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux We just typed make... -- (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) pgpnEyGGJwokg.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 09:13:00AM -0500, Branden Robinson wrote: On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote: Do package descriptions change so regularly that translated descriptions couldn't be submitted through the bug tracking system and included in the next upload? That doesn't serve the purpose of hijacking pieces of the maintainer's package away from him, which, as you'll note, is the foundational premise of Michael Bramer's entire proposal. He doesn't want the maintainer involved at all, except to sit by helplessly and get flooded with emails notifying him that his package has been modified yet again. sorry, branden. 1.) you speak only about the 1. proposal 2.) In the last proposal, I propose a way to include the translation in the package. This proposal has some improvments and is more exact. 3.) I don't flooded the maintainer. 4.) In this list and per PM I get some request about this mails. If I hadn't support this mails, some maintainers whould have wept. 5.) I ask yesterday if we should stop this mails, and only some make this request. 6.) I and some other translators get some 'Thanks' after the notifcation mail. This is not wrong in all ways. 7.) This notification mails are like the mails from the BTS or from katie 8.) This mails are not helplessly. I know some translators, who get improvments from the maintainer. 9.) If you right and this mails are useless, we should put the maintainer out of the loop. But you are wrong. Some maintainers are very active and help the translators. 10.) Make you the request to send this all to the BTS? If we make the translations, we have two excesses: - we put the maintainer really in the loop (without a override file) With this the maintainers get some mails from the translator project. More like now. Now we only at the start, now we don't make a real review process. Now we have only 10 languages. In this case the maintainer must make the whole work after the translation. Sorry, but if some maintainers complain about this mails (without real work on there site) now, they don't make a good work in the future. - we put the maintainer out of the loop The maintainer need not do anything. Maybe he don't know the translation. The user only use this. This need only the translators. I don't propose one of this excesses now. I post a proposal with both sites. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux «Computers are like air conditioners -- they stop working properly if i you open WINDOWS» pgppMJua4uT92.pgp Description: PGP signature
Re: (my) summary about translated description with dpkg (still RFC)
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.lang 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.lang are a hack. What are Packages.lang file? Files with the English and the translated Description? Only the translated Description? With a Description or a Description-lang 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.lang files Packages.lang 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
new proposal: Translating Debian packages' descriptions
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/locale/ 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/locale/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/locale/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
Re: (my) summary about translated description with dpkg (still RFC)
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.lang 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.lang are a hack. What are Packages.lang file? Files with the English and the translated Description? Only the translated Description? With a Description or a Description-lang tag? With the other tags? Oh yes, I was referring to the older solution. s/Packages.lang/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: (my) summary about translated description with dpkg (still RFC)
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: ddts: notification about pt_BR-translation of the hello-debhelper description
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: ddts: notification about pt_BR-translation of the hello-debhelper description
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
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 pkg@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: new proposal: Translating Debian packages' descriptions
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/locale/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
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: ddts: notification about pt_BR-translation of the hello-debhelper description
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
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
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: new proposal: Translating Debian packages' descriptions
On Tue, Sep 04, 2001 at 02:24:41PM -0500, Steve Langasek wrote: 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. yes, you must two lookups. First in the package db (normal in the menory) and (if LANG is set) make a second lookup with gettext. But this not a big problem, or is there a problem? If you put the translated text only in the db, and you don't use the english text as key (like gettext) you get maybe outdated translation. And better a untranslated text than a wrong translation. 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? yes, If we add the translation in the source, we should also add it in the normal deb. 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 pgpSxhzPg8Lu2.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Tue, Sep 04, 2001 at 05:26:00PM -0500, Adam Heath wrote: On Tue, 4 Sep 2001, Michael Bramer wrote: 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 Is the code public? How does one join? Is it open? etc. the code is public (see daily tar on the page). Now I don't use CVS (or like this) but you can send patches, it is open and it is free. If you need more infos ask or see on auric in my home. 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. I'm not denying their work. I just don't want to be constantly emailed that something has changed. I don'e mean the notification mail, I mean the proposal in generally. And I don't mean you personal, I mean all apt/dpkg developer. This developer must make the next step. They must choose a proposal or write a own, make the techniq etc. I and the others can write more proposals, but we all need the support of dpkg and apt. Please give some of your time this project. Thanks. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux als typisch für linux benutzer gilt aber wohl immernoch eher was ala: man blafurz | grep RTFM | cut -c /d 10-2837 | uahha (Adam Kopacz) pgpFhHbC7BZWq.pgp Description: PGP signature
Re: new proposal: Translating Debian packages' descriptions
On Wed, Sep 05, 2001 at 01:40:47AM +0200, Richard Atterer wrote: On Tue, Sep 04, 2001 at 08:55:32PM +0200, Michael Bramer wrote: 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. [snip] You see in the mo file is the orignal description. OK, then why do you say above But [the .po] will include the orignal description and with this it has the double size? Doubled size compared to what? Packages-XX? Oh, I will explain: We can make two things: 1.) Description-XX file In this file are only the Packagname and the Description (and maybe the version), like: !Package: foo !Description: trans of bar of foo ! trans of first line ! !Package: foo2 !Description: trans of headline of foo2 ! trans of first section of foo2 You see this file will not have the orignal description. Apt must combine this file with the normal Packages file and make with the orignal description of the Packages file a .po file. (The .po file must have the orignal description.) 2.) Description-XX.po file This is a normal po file. This File have the orignal description with the translation, like: !msgid bar of foo\n ! first line !msgstr trans of bar of foo\n ! trans of first line ! !msgid headline of foo2\n ! first section of foo2 !msstr trans of headline of foo2\n ! trans of first section of foo2 You see this file has the double size. But the client must not generate the .po file. It must only copy this file in the right location. You understand it now? 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. Right, the Descriptions-XX.po.gz needs to contain all translations. Sorry, I mixed things up. (BTW, wouldn't it make sense to represent the English translation only with a checksum in Descriptions-XX? We'd save a lot of space...) yes, I make this with the ddts. But gettext don't work like this. If you use gettext (like other programs), you must have a .po file, make a .mo with this file and only use it. You can use your own way (like checksum, etc.) and don't use gettext. But now you must re-inventing the wheel, with all gettext features. And in Descriptions-XX we don't need checksum, we have the package name and maybe the version. With this we can assign the translation to the orignal description. What do you think of my main point: Since we already have an override facility with the Descriptions-XX.po.gz, why should we bother introducing another override mechanism which modifies the control.tar.gz? OK, dpkg --info will not work until the maintainer catches up, but most people use dselect or apt-cache show. If we use my proposal, the information in control.tar.gz will only used by dpkg --info and from katie to produce the Description-XX[.po] file. All other outputs use gettext and no special files from dpkg, control, etc. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Every use of Linux is a proper use of Linux. -- John Maddog Hall, Keynote at the Linux Kongress in Cologne pgpMdhWcp9Zq2.pgp Description: PGP signature
Re: new proposal: Translating Debian packages' descriptions
On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote: 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. yes, you must two lookups. First in the package db (normal in the menory) and (if LANG is set) make a second lookup with gettext. But this not a big problem, or is there a problem? It casts doubt on the argument that gettext is a good solution here. Just because gettext is the optimal solution for translation of messages within programs does not mean it's the best solution for package translations. I'm personally willing to do a little wheel-engineering if it leads to a more elegant result. yes, maybe other technics like catgets, or own implementations are have in this special case more performance. But if such a solution more elegant? Other programs have also 'non static' output and use gettext. I don't see a real problme with gettext. Gettext work, you must not thought about it. It is like a VW Käfer, it is runing, runing and runing. IMHO it is elegant, if you get with a only -9/+30 clear patch translated description in dpkg. Reuse the code. If we have a real advantage with a re-engineering wheel, make a re-engineering. I have no problem with a special wheel, if we need it. If you put the translated text only in the db, and you don't use the english text as key (like gettext) you get maybe outdated translation. Only if the implementation is poor. The accuracy of a translation can be verified in the process of assembling the file that is to be made available to user machines (whether that file is Packages.gz, or debian-descs.mo, or whatever). Obviously the /inputs/ used to create this file must include mappings of English string - translated string, but these mappings need not be retained in the output file. We only need to make sure once that the translation is up-to-date, not every time the user runs dpkg, because each version of each package can have only one untranslated description associated with it -- it's a unique key, by definition. If nothing else, perhaps you would consider that a .mo file containing [untranslated string - translation] mappings will on average be almost twice as large as a .mo file containing [(package name,version) - translation] mappings. :) yes, you right in all point. I propose to use only .po files in the source with this thought. I use this [(package name,version) - translation] relation also (to make a .po file from a Desription-XX and a Package file). This is possible, if we don't use gettext. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel. -- Jens Dittmar in de.comp.os.unix.linux.newusers pgpVMuqK8fAyY.pgp Description: PGP signature
Re: How many people need locales?
On Mon, Sep 03, 2001 at 03:16:25AM -0400, Ben Collins wrote: On Mon, Sep 03, 2001 at 08:24:43AM +0200, Eduard Bloch wrote: #include hallo.h Santiago Vila wrote on Mon Sep 03, 2001 um 02:21:04AM: I think we can consider the volume or the number of subscribers of the debian-user mailing list, and compare it with the volume or the number of subscribers of all other language-specific debian-user-foo lists combined. Is there anybody who can do this count? Can you think of another way to estimate the proportion of users using locales? I really wish to make the locales beeint installed by default, either allways, or with some user interacton (yes/no, which locale etc.). IMO this should be included as one of the first questions in baseconfig. With an installed size of over 8megs, I don't think that is such a good idea. maybe you don't use it, but a lot of user don't speak english or can't understand it. We must support locales and if a user can't speak english he pay this price. Make a debconf question in base-config or in the locale package and ask the user - install all locales - install the locales from the list ... and write a nice /etc/loacle.gen and run locale-gen in the postinst. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Unix ist ein Konzept! Windows hat garkeins (oder wo sind die Gemeinsamkeiten von Win 3, 9x, und NT?) -- Lakmal Gunasekara [EMAIL PROTECTED] pgp7qBHtSd9mP.pgp Description: PGP signature
Re: How many people need locales?
On Mon, Sep 03, 2001 at 03:33:52AM -0400, Ben Collins wrote: On Mon, Sep 03, 2001 at 09:25:04AM +0200, Michael Bramer wrote: On Mon, Sep 03, 2001 at 03:16:25AM -0400, Ben Collins wrote: On Mon, Sep 03, 2001 at 08:24:43AM +0200, Eduard Bloch wrote: I really wish to make the locales beeint installed by default, either allways, or with some user interacton (yes/no, which locale etc.). IMO this should be included as one of the first questions in baseconfig. With an installed size of over 8megs, I don't think that is such a good idea. maybe you don't use it, but a lot of user don't speak english or can't understand it. We must support locales and if a user can't speak english he pay this price. This isn't a matter of not using it, it's a matter of a sane base install. Perhaps base-config could ask if the user wants locales. Know what? That question is being asked in english _anyway_. no, the question is not ask in english. If you use german BF's you get the debconf questions in german (if someone had translated the templates and we have some translated templates in german) Installing locales by default doesn't even come close to solving this problem, so there is no point in including it by default. Maybe you should not include it in base. But it should install on user request and it should ask, which lang it should aktivate in /etc/locale.gen and run locale-gen itself. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Zur Strafe, weil Du nicht rechnen kannst, musst Du zwei Wochen lang ein Rechenzentrum mit 25 NT Servern administrieren. Heisst das nicht Rebootzentrum? :) [ Roger Schwentker u. Philipp Buehler in d.a.s.r ] pgpbhix4juE15.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sat, Sep 01, 2001 at 10:36:59PM +0200, Richard Atterer wrote: On Sat, Sep 01, 2001 at 01:32:26PM +0200, Michael Bramer wrote: - How do we avoid that a package is updated too often? Updating the .deb for each translation change is far too often - maybe add any new translations the moment the package moves from unstable to testing? Obviously, people using unstable will then not benefit from the translations. which uploads? There are no extra uploads. There have to be, in my eyes. Consider this scenario: - Maintainer uploads package with changed English translation - Maintainer goes AWOL - Translators catch up with translations Now what happens? The translations are there, waiting to be incorporated into any new upload of the package, but there is none. Isn't this exactly the problem that we have right now with templates, and that we're trying to solve with this whole system? if only katie put new parts in the deb. yes, we habe a problem. But maybe we can run add_translation_to_old_packages.pl weekly and this do the job. - What would source packages look like for such a system? It /is/ possible to continue to use the old .orig.tar.gz + diff.gz, but automatic updates for new translations would invalidate the maintainer's signature. Should we seize the opportunity to switch to a more flexible source package format? Or just switch to .orig.tar.gz + diff.gz + .i18n.tar.gz? The new source format is the old source format. The translated parts are in the normal diff.gz. OK, but re-diffing will invalidate the maintainer's signature on the diff! Hm, I guess this doesn't matter as long as that sig's sole purpose is to authorize the upload. :-/ no, only the translation in the package source (from the mailtainer are in the source.) Extra translations from katie or the weekly script are not in the source. You don't need real source, the translation is the source. There is no binary, I don't see a problem with this point. 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 pgpxAdcCPMPA0.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 07:03:07AM +0200, Simon Richter wrote: Also problematic is the idea of packaging all the translations into one package. This would never be up-to-date, and more frequent updates are not nice. I prefer a solution similar to the current system in ddts. This could be included in the current FTP archive, in the subdirectories for each language as proposed by Grisu before. If I've understood Grisu's proposal correctly, he suggests that each package with an active maintainer ship translated descriptions inside the package, and there is an override package which contains the translations for which there have been no uploads so far. Nothing is ever changed on the FTP server. yes, this is my proposal. 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 pgpQUL0UYmmyk.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
On Sat, Sep 01, 2001 at 11:19:42PM +0200, Richard Atterer wrote: On Sat, Sep 01, 2001 at 03:38:58PM +0200, Raphael Hertzog wrote: Le Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer écrivait: With language-specific Packages files, there is no size issue. And that's a mirror where we I only have i386. So multiply by 10 arch, then by 50 languages, and you get 10Gb of Packages file. We could reduce that if we remove uncompressed Packages but still ... And a good part of those packages files changes daily ... so the mirror need to download many data each day. That's not acceptable. Oh, but you're not comparing this to the requirements for centralized translation packages: If you do, there is no difference, *if* you assume that the translation packages would also have to be released per arch. no, you don't need one package per arch. _Now_ We make only a file from the i386 arch. (IMHO you get 90% of the other archs with this file) But a po file with all descriptions in archs from sid, will not the big problem and is not very bigger. Furthermore, as mentioned before, translation packages have the disadvantage that new Descriptions, i.e. _the_ones_you_are_most_likely _to_look_at_, will *not* be translated because you haven't yet downloaded the latest translation package. no. If you download the desc-trans-XX.de you have all translations from XX on your system. Not only the translations from the installed packages. see my comments from a other proposal. Maybe we should make Descriptions-XX files (like the Packages files), get this with apt and make the po files with this files. This Descriptions files can maybe stored in one place per dist. Independent of the solution, we need some - translated Packages file - Description-XX file (with translated descriptions) - a desc-trans-XX.deb (with a po/mo file with translated descriptions) if the user should see translated descriptions before he installed a package. And all of this you must download and install before you can see the translations. The first and second download a patched apt, the last one you must install per hand. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Before you play two notes learn how to play one note - and don't play one note unless you've got a reason to play it. - Mark Hollis pgp7pJDidvMOW.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 07:03:01AM +0200, Simon Richter wrote: I like this all, but we have the problem with outdated translations. Yes, that's why I want these files to be automatically added from the database: The database still contains the untranslated strings, so we can check whether the translations are up to date. If the checking were performed on the end user's machine, you would ship the unstranslated strings n+1 times, with n being the number of translations, and if the translation was no longer up to date, the end user's box would throw them away. With my proposal, a .deb file would never contain an outdated translation unless the maintainer forced it. please can you point out this process more clearly in a new version of the proposal. A to written script (dh_i10ndesc) include the translation only in the deb, if the orignal description from the po file comform with the description in the controll file. With this we don't have outdate descriptions in the deb. This still has the problem that the maintainer has to take some action to get the translation into the .deb, which we wanted to avoid. But we might need to take an approach like that, see my next mail. no, I don't see a extra work. maybe the maintainer don't add translations: He must do nothing. The dh_i10ndesc script is in rules and make all work. maybe the maintainer add a french translation (a french maintainer): He write only a po file like description and the dh_i10ndesc script is in rules and make all work. If he change the english text and forgot the translation he get a error and the script don't add the translation in the deb. The user can install a desc-trans-XX.deb and have with this deb a local override file. I don't see the point in this. Why would the user want to override translated descriptions? Normal the user (or better root) don't have a this override file. But maybe he is a translator and translate some descriptions and he will add this translation to his po files and use this and he must not wait on the delay with the ddts and the ftp admin from this override file. This local override don't cost something. If we use the local gettext and some po files and generate with this a mo file, we have this feature and some roots will maybe use it... katie has all informations. it has the descriptions from the packages, the translations from the packages and maybe one/some override files with traslations. It can make Packages-XX files. But I don't like this. IMHO better is this: katie make the normal Packages file and some Descriptions-XX files. With only Package: and Description-XX: tags. Apt can download the Packages file like normal and/or on/some Descriptions file(s). This makes sense once people want to have the descriptions of uninstalled packages in multiple (read: more than one language on one box) languages, since it helps avoid some confusion with packages of the same name and version being available from multiple sources. this is IMHO a must feature. If you can only install one languages, the system is very bad. The user can config what languages he will support. Apt can use this Descriptions files itself or (IMHO) better make a po file with the Packages and Description file and make with this a mo file. And use the normal dgettext. With this we don't use the desc-trans-XX.deb in real. What is the point in using gettext then? If you generate the .po file from two different sources (original and translation without the original text), the translation cannot be out of date. gettext do all the work, you get never old translations, you must patch apt with 30 lines (note: we don't count apt now), we use old tested code, use all the time the same translations, ... 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 pgpExiMu7mnwS.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On Sun, Sep 02, 2001 at 04:53:16AM -0500, Manoj Srivastava wrote: Michael == Michael Bramer [EMAIL PROTECTED] writes: Michael A process on the ftp-master patch the deb with the Michael translation, if the translation is not alread in the the Michael package. This process don't change the package or the Michael version number- It only add the translation parts in the ar Michael file. So the same file name, at dieerent times, shall have different MD5Sums, and indeed, the same file on different debian archives shall have different lengths and different checksums. (Did you know that an X upload was rejected because it changed a file without changing the version number?) I don't think that signing all parts of the ar separately solves this issue at all. sorry, I don't make this proposal. This was only my understanding. If we can make this, if we have problem with the debian archives, if we can solved this problems, I don't know this all. I don't make comments on the points - 'put the translations in a extra ar element' and - make signatures on all ar elements I don't know the archives maintainment and the dpkg framework in this depth. I can't make real good comments on this. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman pgpWAzpod9mzT.pgp Description: PGP signature
Re: Translating Debian packages' descriptions
On Sun, Sep 02, 2001 at 02:28:45AM -0500, David Starner wrote: On Sun, Sep 02, 2001 at 09:12:52AM +0200, Martin Quinson wrote: On Sat, Sep 01, 2001 at 10:11:45AM +0200, Radovan Garabik wrote: Of 8 friends of mine that are using debian, I know that: 2 would want fallback hungarian-slovak-czech 1 would want fallback lithuanian-slovak-czech-russian 1 would want fallback slovak-hungarian-czech the rest would want fallback slovak-czech I prefer original English version nice statistics :-) Sure, that would be great. But, AFAIK, no i18n mecanism can handle that for now. Feel free to fill a wishlist bug report against gettext. It's not well documented (neither gettext (3) or setlocale (n) seems to mention it), but: ~ $ date -h date: invalid option -- h Try `date --help' for more information. ~ $ LANGUAGE=xo:eo_EO:de_DE:en date -h date: Ungültige Option -- »h« Mit `date --help' bekommen Sie mehr Informationen. ~ $ yesterday I ask google and groups.google and find some pointers but no real documentation. I don't test this real, use this a fallback per - mo file, or - message? If it is per mo file, it is not usefull for our problem. But we can patch gettext. IMHO a per message based fallback is for normal gettext application also a nice thing. (with this someone can make a de_AT:de_DE:de:fr) If gettext support this per message (or if we patch it otherwise): Please, please dpkg and apt maintainers/developers use gettext for the translation! With gettext we have all, what we need and this all with some nice, small patches. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman pgp1KrUW3UDq7.pgp Description: PGP signature
