Bug#1072714: ITP: odin-lang -- Compiler and runtime for the Odin programming language

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name    : odin-lang
  Version : O.0.dev2024.06
  Upstream Contact: (this community goes over Discord, not emails)
* URL : https://odin-lang.org
* License : BSD-3-Clause
  Programming Lang: C++ for the compiler, and Odin for the stdlib
  Description : Compiler and runtime for the Odin programming language

# Package description
Odin is a general-purpose programming language with distinct typing
built for high performance, modern systems and data-oriented
programming.

Odin is the C alternative for the Joy of Programming.

# Why is this package useful?
Because this language is nice and elegant. I plan to use it, and according to
upstream, they are getting close to a v1 version (the language and compiler are
ready, they are working on the standard library)

# How do you plan to maintain it?
I don't need a sponsor, but I'd like to have co-maintainers, if possible. I
guess I could find some help with upstream. I already started packaging it,
mostly to see whether it's doable given my free time, and I found an helping
hand upstream in the person of the maintainer of the homebrew package.

Cheers,
Mt


signature.asc
Description: This is a digitally signed message part

Re: dehs will stop

[Martin Quinson]

[Why to cc on policy? Cut]

On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote:

> >If people don't care as much about this as you think they should,
> >perhaps it would be a good idea to try explaining why they *should*
> >care, instead of just lamenting their lack of a telepathic
> >understanding of your intentions?
> 
> This is not true. Had u tried to do a search about dehs/watch on
> debian-devel about 2004/2005? 

I didn't. Just change the content of this mail into one of the pages of your
site, and you're set.

> I'm not a debian developer, so i could not post on dda mailing list. I
> had opened many thread over this months on debian-qa debian-devel about
> dehs issues. The only reply are:
> 
> 1) Dehs is useless.
> 2) Submitting 6229 wishlist bug is not possible/is not the solution
> (without proposing alternatives method)
> 
> I had try to randomly submit wishlist bugs for 6 packages to bts with
> the tag "patch" pointing to the dehs site or attaching the watch file to
> the bug.
> Almost all of this bug was closed and the watch file was check (in some
> cases fixed) and inserted in the package on the next upload. 

So, you got the way to go. Please go ahead and submit those 6229 bugs.
Providing a patch *is* an alternative method. We did the same sort of
wishlish bug mass filling with the transition from raw debconf to
po-debconf. We had less packages to bug, though.

It represents an insane amount of work, but it's the way to go, I guess.
What's useless is to fill the bug without the patches, but if you write the
watch file for the people, nobody should complain.

Good luck, Mt.


signature.asc
Description: Digital signature

Re: dehs will stop

[Martin Quinson]

On Sun, Mar 06, 2005 at 06:44:37PM +0100, Jeroen van Wolffelaar wrote:
> On Sun, Mar 06, 2005 at 10:49:47AM +0100, Martin Quinson wrote:
> > 
> > On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote:
> > 
> > > I'm not a debian developer, so i could not post on dda mailing list. I
> > > had opened many thread over this months on debian-qa debian-devel about
> > > dehs issues. The only reply are:
> > > 
> > > 1) Dehs is useless.
> > > 2) Submitting 6229 wishlist bug is not possible/is not the solution
> > > (without proposing alternatives method)
> > > 
> > > I had try to randomly submit wishlist bugs for 6 packages to bts with
> > > the tag "patch" pointing to the dehs site or attaching the watch file to
> > > the bug.
> > > Almost all of this bug was closed and the watch file was check (in some
> > > cases fixed) and inserted in the package on the next upload. 
> > 
> > So, you got the way to go. Please go ahead and submit those 6229 bugs.
> 
> NO!
> 
> Do *not* file 6229 bugs about the same subject. Never.
> 
> Adding a watchfile is up to the maintainer. It's a feature offered to
> maintainers, they can use it if the wish. If a watchfile for a package
> makes sense (for quite some packages it doesn't) I think it's useful.
> In no case should 6229 bugs be filed about these watchfiles that don't
> have ANY effect on the resulting binary packages.

Erm. You did cut what I said, ie, that if someone wants to write the few
thousands missing watch files and provide them as wishlist bug, I'd say that
they should proceed. People not wanting of those watch files can always mark
the bug wontfix if it's a political opinion, or close the bug if it does not
make any sense in their case.

Of course, mass bug filling saying "please do the job I'd like to see done"
is never a solution. That's not what I proposed. That's not what we did for
the po-debconf transition.

And hoping that maintainers are perfect and will write everybit of the
needed infrastructure alone is a dream. I welcome any transversal help
offer. That's QA job, and that's good, IMHO.

Thanks, Mt.


signature.asc
Description: Digital signature

The keychain package, its debconf templates, the security hole induced

[Martin Quinson]

Hello,

as part of my current effort of getting rid of packages using debconf
without providing support to translators, I had a bug repport against the
keychain package asking simply to drop this template:

Description: Information for people upgrading from versions prior to 2.0.
 With this new version of keychain, the output of ssh-agent will be
 redirected to the ~/.keychain/[hostname]-{c}sh files.  Any cron job or
 login script that uses keychain needs to be updated to use the new
 directory location.
 .
 For more information please read the man page.

IMHO, it's clearly a debconf abuse which should be changed to a
README.Debian entry. Moreover, the message is shown each time without even
checking whether the user upgrades from an old version or not (what a pitty
to show this on new installs). Not speaking from the fact that it's called
from postinst instead of config and will thus stop the installation process
right in the middle.

My bug was close with a laconic changelog entry:
  * l10n changes Closes: #235812,#259567,#262738,#266356,#274900,#192165

And now, I'm mad about this. 

A closer check to the package reveals that it's only useful if you want to
open a security risk on your machine. All info relatives to the ssh-agent
are written into a well known file, allowing cron jobs and attackers to use
them without prior knowledge of your passwords.

Dudes. There is a reason why those informations are not written to file by
ssh itself. If my local machine gets corrupted, I'm happy to see the
password I've set on my keys slowing down the attacker enough to allow me
dropping the ssh keys from remote hosts. 

You should at least speak about the potential security risk in the
description. 

I'd drop the package from the archive right away. I have several cron jobs
using ssh keys (a new key for each cron, without pass and allowed to do only
one specific command on the remote host).


So, please do at least the following to your package:
 - speak about the potential security hazard in description
 - check the pre-installed version before showing your crufty template (or
   use README.Debian, it's what it's good for)
 - use a proper config script instead of blocking the install with a db_get
   in the postinst (just read the debconf documentation)
 - do usefull changelog entries in your packages in the future.
 
 
Bye, Mt.


signature.asc
Description: Digital signature

Re: The keychain package, its debconf templates, the security hole induced

[Martin Quinson]

On Mon, Jan 24, 2005 at 10:08:11AM -0600, Cesar Mendoza wrote:
> Hi,
> 
> You know, I'm parent. You look a lot like my son when he doesn't get
> his way. When I don't do what he wants, he would start screaming and
> making noise. I have learned that is better to ignore him for a while
> until he calms down and we can have a normal conversation.

I'm not sure your son provided over hundred patches in bugs to get a really
simple issue fixed in every other package. ;)

> If you have
> contacted me instead of having a tantrum, you would have known that I made
> a mistake and I would have worked with you to have your bug report resolved
> to your satisfaction.

This is not my satisfaction we are speaking about. It's your package (that I
don't even use). I repported a bug against your package just to help you and
improve the overall quality of debian.

I never received any mail from you. Not "thanks", not "go to hell and learn
english in there", nothing. Only an automatic mail stating: 
  * l10n changes Closes: #235812,#259567,#262738,#266356,#274900,#192165

Not even spaces after the colon, it would take 2 lines to close all those
bugs in one shoot (note that my request was about i18n, not l10n).

> I think that is why people receive emails from the
> Bug tracking system. So, people can verify if the Bug was resolved or
> not. Please contact me once you feel that you are ready to have a normal 
> conversation. I will work with you to have the bug resolved.

If you want to improve your package's quality, I already gave you all the
advices I could. If there is something you don't understand, I'd be glad to
assist you. If you expect me to implore your pardon, you're dreaming, dude.

> > So, please do at least the following to your package:
> >  - speak about the potential security hazard in description
> >  - check the pre-installed version before showing your crufty template (or
> >use README.Debian, it's what it's good for)
> >  - use a proper config script instead of blocking the install with a db_get
> >in the postinst (just read the debconf documentation)
> >  - do usefull changelog entries in your packages in the future.

Note that I was too mad about all this to think properly. You should convert
your template to an entry into NEWS.Debian, not README.Debian.

And, as a conclusion, I think I owe you an explanation. I reported 151 bug
report about converting debconf templates to po-debconf or dropping them (49
still being open). I become mad about this from time to time. This time, it
falls on you. Last time it was mono packagers...

Have a nice day anyway, 
Mt.


signature.asc
Description: Digital signature

Re: Upstream requires forked Date::Manip

[Martin Quinson]

On Sun, Jun 29, 2003 at 03:50:29PM -0500, Kenneth Pronovici wrote:
> The upstream maintainer of XMLTV, which I package for Debian, has
> temporarily forked the Perl Date::Manip module.  He says:
> 
>Over the past six months or so I've accumulated various bug fixes to
>the Date::Manip module, most of them because of xmltv bug reports
>sent by users.  Rather than wait any longer for the upstream
>Date::Manip to incorporate the fixes I have made my own release
>(intended as a temporary measure, not a permanent fork)... I've
>updated xmltv to require this version of the module (since it does
>fix several fairly important problems).
> 
> I'm not entirely sure what to do with this.
[...]

A third option would be to use the dpkg diversion on libdate-manip-perl
files to install the fixed version. That's clearly an ugly hack, but it
could do the trick until either libdate-manip-perl upstream or its
maintainer do something to get the issues fixed.

Thanks, Mt.

-- 
Les rebelles disaient que les débutants avaient le droit d'utiliser un
"éditeur", qui ressemblait à MSWord comme sa mère à Pamela Anderson.
"Vihaille" comme les rebelles l'appellaient, était sans doute un bizutage
  -- L'histoire des pingouins

Bug#199390: ITP: quilt -- Scripts for working with series of patches

[Martin Quinson]

Package: wnpp
Version: unavailable; reported 2003-06-30
Severity: wishlist

* Package name: quilt
  Version : 0.24 
  Upstream Author : Andreas Gruenbacher <[EMAIL PROTECTED]>
Andrew Morton <[EMAIL PROTECTED]>
    Martin Quinson <[EMAIL PROTECTED]>
* URL : http://savannah.nongnu.org/projects/quilt
* License : GPL
  Description : Scripts for working with series of patches

 The scripts allow to manage a series of patches by keeping
 track of the changes each patch makes. Patches can be
 applied, un-applied, refreshed, etc.
 The key philosophical concept is that your primary output is patches.
 Not ".c" files, not ".h" files.  But patches.  So patches are the
 first-class object here.
 .
 This package also provide some basic support to build debian package
 and handling the diffs with quilt.
 .
 These scripts are based on Andrew Morton's patch scripts posted a 
 while ago on the linux-kernel mailing-list, but were heavily 
 modified since then. 

The package is available from
http://graal.ens-lyon.fr/~mquinson/deb.html#quilt

Thanks, Mt.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux galadriel 2.4.20 #1 dim mar 30 23:53:59 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Bug#199692: ITP: rfc-tool -- Tool to search in the RFCs and display them

[Martin Quinson]

Package: wnpp
Version: unavailable; reported 2003-07-02
Severity: wishlist

* Package name: rfc-tool
  Version : 3.2
  Upstream Author : Derrick Daugherty <[EMAIL PROTECTED]>
* URL : http://www.dewn.com/rfc/
* License : Unclear, probably free
  Description : Tool to search in the RFCs and display them

 The Requests for Comments (RFCs) form a series of notes, started in 1969,
 about the Internet (originally the ARPANET). The notes discuss many aspects
 of computer communication, focusing on networking protocols, procedures,
 programs, and concepts but also including meeting notes, opinion, and
 sometimes humor. See RFC2026 (in package rfc-bcp) for more information.
 .
 This package contains a tool called rfc which can be used to search the
 RFCs about a given port number, a given protocol, arbitrary text or even
 perl regexps. If you have the rfc-* packages installed, it will search
 there, but if not, it will connect to the internet to retrieve the RFC
 index and work on it.


Please note that this description is not correct until my new version of
the rfc package gets uploaded to the archive. But I don't exepect the
rfc-tool to hit the archive before the data RFC packages.

Likewise, the licence for now is:
#
# Feel free to redistribute as long as you keep this header in tact.
# http://www.dewn.com/rfc/
# Please let me know if you find this useful, I'd love to hear about it!
# [EMAIL PROTECTED]
#
I contacted upstream to clarify it.

Lastly, for now, it will not search the locally installed RFC, and will
always download the RFC from the net. But I plan to fix this before the
package gets uploaded.


Thanks, Mt.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux galadriel 2.4.20 #1 dim mar 30 23:53:59 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Bug#199642: xpilot: French translation of the debconf templates

[Martin Quinson]

On Wed, Jul 02, 2003 at 06:12:02PM -0300, Ben Armstrong wrote:
> Now I'm left at a loss as to what to do with the file.  I want the 
> half-finished work to remain in the package so that someone picking up the 
> package and customizing it (or in future, adopting it, should I decide to 
> ever give it up) can benefit from it.  But to include the translation is 
> going to give the wrong signals to other translators, causing them, too, to 
> spend unnecessary time with translations for texts that aren't even in use 
> in the package.
> 
> So, how do I include "development only" text in debian/foo.templates that 
> translators are not to waste their time translating until it actually goes 
> into production?  And do we need a standard for this?

You can put a README.trans in debian/ where you explain the situation, and
clearly state that those files should not be translated.

You can also add an header in the template stating it. Just add plain text
without special formating. It will break the template handling tools,
forcing translators to check the source to see why, and realize those facts.

Yet another way is to create a debian/underway directory, and pack
everything not done yet here. I guess the tools used by translators to check
what is still to do won't find them here.

Once this is done, you can add the translated stuff for archiving without
fear.

Bye, Mt.

-- 
Tout dormeur a en lui un lève tard qui sommeil.

Re: Please remove RFCs from the documentation in Debian packages

[Martin Quinson]

On Thu, Jul 03, 2003 at 05:16:07PM -0700, Brian Nelson wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote:
> > You have some free software, and it comes with a manual. You modify
> > the software in a manner which suits you... but you're not allowed to
> > modify the manual to reflect this change; the license of the manual
> > requires that it only document the unmodified version, so any modified
> > versions are at an immediate disadvantage.
> >
> > And you think this is acceptable? Why?
> 
> It's more acceptable to me than the alternative: to move a good portion
> of documentation to non-free where it will not be distributed by
> vendors, will not be considered "part of Debian" and thus will be under
> threat of removal, and will be considered a "lower class" package.

That's not exactly what we are speaking about. We don't speak about
documentation, but about standards. Documentation comes after the
implementation of the program to explain how to use it. Standards comes
before the implementation to explain how it should behave to be
interoperable with other implementations from other people.

RFCs are not program documentation.
[but the program documentation can refere to RFCs, as ldap stuff does]

> Fortunately, the situation you describe is unlikely to occur because few
> people are perverse enough to make their software free but their
> documentation very non-free.

The fact is that it happens. Look at FDL discussions. But in my mind, that's
out of topic, and I would appreciate if we could discuss one item at once to
have a small chance of converging to a decision...

Thanks, Mt.

-- 
If the automobile had followed the same development cycle as the computer, a
Rolls-Royce today would cost $100, get a million miles to the gallon, and
explode once every few weeks, killing everyone inside.

Re: logging for package installs

[Martin Quinson]

On Thu, Jul 03, 2003 at 05:38:46PM -0400, Joey Hess wrote:
> Maybe this is a good time to present this idea I've been kicking around,
> but never really got anywhere with, for as long as I've been working on
> debconf. My idea is to add an abstraction layer for package install-related
> logging in debian.
> 
> It seems that many maintainers like to do some or all of the following
> in their maintainer scripts:
> 
> - Display various fairly unimportant warnings, which are often not
>   useful until after the package is installed and you're using it.
> - Display error messages, some fatal, and some not.
> - Show progress displays (in contravention of policy of course).
> - Various other indications of important and not so important things
>   that the maintainer script is doing.
> - Remind users to read the README.Debian file.
> 
> Almost all of this is done with echo, and almost all of this is
> completly ignored by our users, believe it or not. I suppose that those
> users who see it would prefer to be able to go back and look at it
> later, when they're actually using the package they installed earlier.
> Some of them would certianly like for it to be localised. Many users
> would like not to see this stuff at all at install time, unless it's a
> real immediate error.

That would be really great, and I'm quite entousitastic about the idea.

> So the basic idea is that instead of using echo for these messages,
> we provide some interface for them. Call it dpkg-log. I have not gotten
> as far as to what the interface of dpkg-log would be, or how users would
> configure how it displays, filters, and/or logs messages. Nor have I
> given much thought to what kind of data should be included in the log,
> though it would probably include the date, package name, log message,
> log type, and message importance.

Check the log4j project, they did come up with a really great logging
framework. Of course, their code isn't usable at all (that's java), but
their concept are very advanced. Applying this to dpkg-log would allow the
user to provide the format they want, depending of the kind of message and
its gravity.

For that, we kind of need a standardization of the possible categories.
Using package name as categorie seems underoptimal to me since it won't be
useable from the user point of view. We could use the sections for that.

 dpkg-log --category main/doc --level critical "Hey, this version will \
  break your install, erase your data and kill your mum unless you check \
  README.debian carfully"

or the tags

 dpkg-log --category gnome --level minor "subliminal message: Gnome rulez"

or a mix of the two, but that may be hard to do right.

> Nor have I thought about l10n at all.

You'll have a bad time i18ning that. The problems with debconf template
i18ning was that:
 - the translation must be there before the program install
 - the texts are short and dispatched over all packages, making the ratio of
   translator work between actual translation work and administrative work to 
   get their work included rather bad.
   
With dpkg-log messages, you'll get into those two problems too, plus the
fact that I guess that maintainers will want to add variating text like
  errmsg=`run a command`
  if [ $? != ] ; then
dpkg-log $"Damnit the execution of this command failed with the message 
$errmsg"
  fi

The errmsg stuff is impossible to translate unless setting LC_ALL for the
execution program run, but this leads to other problems if you want to parse
the output... 

I can't find a good way to translate those errmsg stuff, but for the others,
I think that it could be pushed to the debian/po file. debian/po/POTFILE.in
provides a provision for such extends. I need to speak with Denis Barbier to
see how we could this happen in the po-debconf and po4a realm.

> This could be bolted on the side of debconf. The abuse of debconf by
> maintainers who feel the need to do the kinds of things listed above
> certianly points at the need for this mechanism. And at least debconf
> has a kind of l10n framework, and some ideas about question priority.
> But this logging and message display is really conceptually different
> than debconf. Debconf is just there to ask questions. It would likely be
> better to design it as a separate program.

Fully agreed.
 
> Here's one way a dpkg-log program might be used, just to give the feel
> for the idea:
> 
> #!/bin/sh
> if [ "$1" = configure ] && grep -q evil /etc/myconfig; then
>   dpkg-log --priority=critical \
>--warning=$"/etc/myconfig has evil in it! See README.Debian!"
> elsif [ "$phase_of_moon" = full ]; then
>   dpkg-log --priority=critical \
>--error=$"This package only upgrades during new moons."
>   exit 1
> fi
> 
> The user would see either this:
> 
> # dpkg -i mypkg.deb
> dpkg: Installing mypkg (1.2.3) ...
> dpkg: Not replacing modified conffile /etc/myconfig with 
> /etc/myconfig.dpkg-new
> mypkg: /etc/myconfig has evil in it! See R

Re: Please remove RFCs from the documentation in Debian packages

[Martin Quinson]

On Sat, Jul 05, 2003 at 04:40:36PM -0500, Branden Robinson wrote:
> On Fri, Jul 04, 2003 at 12:53:56AM -0400, David B Harris wrote:
> > Except for the title, the DFSG is very content-agnostic. It can be
> > applied equally well to software, fiction, nonfiction, images, what have
> > you.
> 
> I think that's a feature.  Apparently, some people think it's a bug.

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

;)

the RFC mess: tentative summary

[Martin Quinson]

Ok, people. Even if I'm not native speaker, I'll now try to sum up the
flamewar we just had about the RFC licencing. Don't get me wrong here. In
fact I personnaly have no fixed opinion about this. I just want to be able
to fix the tons of RC bugs involved by this issue, close them, get other
bugs do the same, see Sarge released before mid-2004 and drink a bier to
celebrate. Please be patient with me and correct me if I'm wrong.



This is all about one of the oldest RC bug in debian, the infamous #92810.
The issue here is that the RFC licence (at least for the modern ones) is
clearly non free. For some people, that's a reason to throw this out of
main, for some other, RFCs can stay in main for several reasons.

I belive that the discussion showed that the status-quo (ie, RFC being in
main without being free) cannot stay as is. Here are first the arguments
proposed by people for this status-quo and their refutation proposed by
others.

 1. RFC are not software but standards.
 
Answer 1: What is a software, then? It's impossible to establish a clear
  definition of that (Perl interpreting scripts is not clearly different
  from mozilla or php processing an html document).
Answer 2: Ok, that's not software. But it should remain free anyway to
  make its way to main (non-free non-software is not equivalent to free
  software)
Answer 3: If they are not software, they don't belong to Debian (one
  interpretation of "Debian will remain 100% free software")
   
 2. Standards gain their value from their rigid rigid procedure for updates
and modifications.
  or:
Who needs to edit the RFCs by the way?
  or:
Keep cool, IETF are good guys, sharing some goals with us.

Answer 1: Nobody asked the right to change the content of the file
  RFC23423.txt and distribute it as is. This would clearly be wrong and
  it would be ok to ask for a file rename, for a clear notice changes
  between the original version and the distributed one, and so on.
Answer 2: As long as the IETF is a good willing institution, that's fine,
  but what will happen in 10 years? If they disapear, we need the *right*
  to modify the existing RFCs to create new ones, and fork the
  standardisation process. 
 This is not very different forking gcc: in both cases it's generally a
  bad idea, but the health of a free system depends on it being 
  potentially possible.
Answer 3: If I want to document a program following quite well a given
  RFC, but not completely, it's easier for me to edit the RFC file (and
  rename it of course) than paraphrasing it. If I'm not allowed to do
  this edit, I'll probably never document those changes, which is a loss
  for the users. 
 Same thing for comments in code explaining which part of the RFC
  constraints some design decision.
Answer 4: "Ceci n'est pas une RFC". The file containing the standard is
  not the standard itself. Sure I won't change the standard. But I may
  want to use bits of the standard if I want (see also argument 6).
 
 3. It serves our users (no need to download)
  or
Banning RFCs from Debian is just silly.

Answer 1: Serving our users is not a sufficient reason. It would help a lot
 of people to have a complete implementation of java in main, but since
 there is no free implementation, that's currently impossible.
Answer 2: If anyone but the IETF wanted to get something under such
 licence in Debian main, nobody would agree. We have to be consistent
 with ourselves. Netscape and acrobate did get banned.
See also answer 2.3.

 4. It would be arrogant to ask IETF to change its licence to fit our views. 
   
Answer 1: So far, we just discussed about moving it to non-free.
Answer 2: Some people belive that the intention of the licence is good
  (authors intended the RFCs to be freely usable, but also trustable, ie
  that a file claiming to be the RFC1253215 is actually the version
  endorsed by IETF), but the wording is wrong and makes it non-free.
Answer 3: We asked a lt of stuff around to *clarify* their licence.

 5. ISOC is not granted an exclusive copyright license, and even if they
wanted, they cannot relicence the file.

Answer 1: People wanting to include a perticular RFC in a free packages
  can contact the RFC authors directly to manage this.
Answer 2: ISOC could change the licence terms for future RFCs.

 6. There is a "fair use" provision.
 
Answer 1: "fair use" provisions are not legally appliable everywhere in
  the world (UK only have a more limited concept called "fair dealing").
See also answer 2.2

That's the main arguments I've seen. As in any flamewar, some "not so
fundamental and related" arguments were also given:

 7. There is a tons of other craps in main which should be removed.
 
Answer 1: Fine, let's remove them

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
> * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-20 10:31]:
> > > Martin Quinson <[EMAIL PROTECTED]> wrote:
> > > > I just wondered if it would be possible for non-developper
> > > > contributors to Debian to get their GPG key in the Debian keyserver. 
> > 
> > You can also apply as a NM for translation work. You don't need to
> > maintaine a package or know much about the packaging system for
> > that. You get different task&skill tests.
> 
>V I P   Martin Quinson <[EMAIL PROTECTED]>

Exact. I *did* apply. I'm even pretty well advanced in the process.

$ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

This is the ID of my key, available from www.keyserver.net and signed by 2
DD. Did I mess something up ?

Shouldn't Debian make sure that work submition from non-DD contributor are
signed, just like it does for the work submition from DD ?


Bye, Mt.

-- 
Dans un pays d'extrême droite, On y parle beaucoup de Dieu, parce que ça
fait longtemps, qu'il a quitté les lieux.
   -- Frères misère

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> > gpg: no valid OpenPGP data found.
> > gpg: Total number processed: 0
> > 
> > This is the ID of my key, available from www.keyserver.net and signed by 2
> > DD. Did I mess something up ?
> 
> keyring.debian.org has only DDs in it.  I think people were suggesting
> using the public keyservers.  keyring.debian.org isn't a part of the
> public key servers.

That's the part of the system I was criticizing :)

> > Shouldn't Debian make sure that work submition from non-DD contributor are
> > signed, just like it does for the work submition from DD ?
> 
> Interesting question.  While it's not a bad idea I don't see it as
> entirely necessary either.  At least when sponsoring a package the DD
> performing the sponsor must check everything regardless of if it was
> sent to them signed or not. 
[...]

Hey, guys, I begun the thread stating that I was mainly a translator and not
a packager.


Let's say that the test case here is that I send a translation patch to
Wichert about dpkg, as I already did. I think that Wichert has no idea about
french, so he cannot review the meaning of my work. If he actually
understand some french, let's imagine I'm japaneese or whatever.


Of course, he can (and should) review the syntax of my po file (a badly
formated po file can easily let the application segfault by replacing %d by
%s in a printf format). msgfmt will warn him if I made such error.

Nevertheless, should he trust the meaning of my translation blindly? I mean,
it could contain offending material, and even unlegal material. I guess that
there will be someone to engage pursuits if dpkg subtly displayed racial
crime incitation, or so. 

I dunno in the states, but such things can bring you in jail for a bunch of
few months (if not years) in France. And it should be easy to insert illegal
material for the US in displayed text, thanks to your wonderfull anti
terrorist and digital right management acts...

Who will get sued in such situation? I guess Debian in first place, but if
I understand well, the whole identification process of the NM is exactly
about giving Debian the possibility to report the charges on the guilty
developper when sued, isn't it?


So, I ask again, shouldn't Debian check the real identity of contributors
when the maintainer is unable to check the material himself ?
If it's ok so, what is the big deal of asking the DD for having a trusted
key and signing the packages, anyway ?

I know about the public servers, but I was wondering why Debian make things
harder for the DD while it has the infrastructure to simplify their work.


Thanks for your time, Mt.

-- 
Failure is not an option.
It comes bundled with software.

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 11:03:32AM -0500, Steve Langasek wrote:
> On Wed, Aug 20, 2003 at 11:23:47AM +0200, Martin Quinson wrote:
> > On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
> > > * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-20 10:31]:
> > > > > Martin Quinson <[EMAIL PROTECTED]> wrote:
> > > > > > I just wondered if it would be possible for non-developper
> > > > > > contributors to Debian to get their GPG key in the Debian 
> > > > > > keyserver. 
> > > > 
> > > > You can also apply as a NM for translation work. You don't need to
> > > > maintaine a package or know much about the packaging system for
> > > > that. You get different task&skill tests.
> > > 
> > >V I P   Martin Quinson <[EMAIL PROTECTED]>
> 
> > Exact. I *did* apply. I'm even pretty well advanced in the process.
> 
> > $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> > gpg: no valid OpenPGP data found.
> > gpg: Total number processed: 0
> 
> > This is the ID of my key, available from www.keyserver.net and signed by 2
> > DD. Did I mess something up ?
> 
> > Shouldn't Debian make sure that work submition from non-DD contributor are
> > signed, just like it does for the work submition from DD ?
> 
> The keyring on keyring.debian.org is used directly as a means of
> authorizing people to a number of Debian resources, including the
> package upload queue and d-d-a.  Whether you agree with this design or
> not, it means that the Debian keyserver is not suitable for use as a
> general-purpose means of *authenticating* people.  For authenticating
> PGP users to one another, you should use the usual Web of Trust to
> achieve this.

I have to confess my ignorance here. Since it seems to be 4 keyrings on that
server (according to /usr/share/doc/debian-keyring/README.gz at least), I
was wondering if it would be possible to add a 5th for the trusted
contributors not being DD.

I can well imagine that the debian-keyring.{gpg,pgp} is used to allow people
to upload packages and such and want certainly not to get into that ring
(yet -- I'm in the NM process). But I was dreaming of such trust facility
for non DD contributors.


Another point is that it would constitute a strong signal to non DD
contributors: They would be trusted by Debian. According to the cathedral
and the bazzar, that's the way it should be if not too technically
difficult...


Thanks, Mt.

-- 
The unavoidable price of reliability is simplicity.
--Hoare

Re: Bits from the RM

[Martin Quinson]

On Wed, Aug 20, 2003 at 11:08:28AM +0200, cobaco wrote:
> On 2003-08-20 10:13, Chris Cheney wrote:
> > On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote:
> 
> > > On Tuesday 19 August 2003 08:49, Anthony Towns wrote:
> > > > I'm all for aggressive goals, let's aim for sometime in December -- how
> > > > about 2003-12-01 00:00:00 UTC?
> 
> > > Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc,
> > > X, gnome versions will be in sarge?
> 
> > KDE 3.1.4   (KDE 2.2 _will not_ stay in sarge!)
> 
> kde 3.2  release is slated for 8th december[1], is there any chance we'll 
> wait 
> for it, just so the outdated kde label doesn't apply again immediately after 
> release?

What recent change in the KDE releasing schema let you think that they will
manage to get a really stable x.y.0 release [*] when it seems like it took 4
minor releases in the 3.1 branch ?

Naturally, no offense intended to the kde guys. Needing only 4 minor releases
to stabilize such an amount of code is really great.


Bye, Mt.

[*] ie, suitable for debian stable release, ie a version with which you
could live for a year on your desktop, maybe dreaming of new features (we
always want more), but not pesting against the bugs.
I speak of course of the ideal debian stable release ;)

-- 
Testing can only prove the presence of bugs. 
--- Dijkstra

Re: non-DD contributors and the debian keyring

[Martin Quinson]

[answer to a private mail on the list with the permission of Christian]

On Wed, Aug 20, 2003 at 02:53:49PM +0200, Christian Kurz wrote:
> On [19/08/03 18:05], Martin Quinson wrote:
> > point is that currently, DD is very very strict about who can upload to the
> > source and the packages, but when I submit a translation to someone who do
> > not speak french, he have to trust me.
> 
> Well, but even if you are a DD, I would have to trust you and the
> translation that you provided. And for me that trust doesn't depend on
> the signature of the e-Mail that contained the translation. For me it
> doesn't matter if you send me a translation know, with your key signed
> or with your key in the debian-keyring. I will in both cases apply the
> same procedure before including the translation. 

Of course, the signature is not sufficient to get the needed trust. But I'm
coordinator of the french translation team since a few years, so my skills
should be trustable, I guess.

But the point is that without the key, anyone can forge mails which seem to
come from me, and thus abuse the trust my work gained me in the mind of some
DDs.

I see this point as necessary even if not sufficient.


That is to say that if I were DD, I would never trust any contribution I
cannot check myself and comming from someone I'm not confident in 1) the
identity 2) the skills. 

Judging from the amount of translation rotting in the BTS, I guess some of
you guys react the same way, and I want to change this by easing this trust
relationship, if possible.


Thanks for your time, Mt.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> > > keyring.debian.org has only DDs in it.  I think people were suggesting
> > > using the public keyservers.  keyring.debian.org isn't a part of the
> > > public key servers.
> > 
> > That's the part of the system I was criticizing :)
> 
> Not going to change.

Quite definitive answer.. Ok, I guess I got my answer and go back to work ;)
 
> > Nevertheless, should he trust the meaning of my translation blindly? I mean,
> > it could contain offending material, and even unlegal material. I guess that
> > there will be someone to engage pursuits if dpkg subtly displayed racial
> > crime incitation, or so. 
> 
> To some extent "that's what unstable is for".
Right

> I doubt a poor translation would make it into a released version.
A lot of poor translation get into stable, mainly by lack of manwork, but
you are right no offending translation gets into testing. At least in french.

> > Who will get sued in such situation? I guess Debian in first place, but if
> > I understand well, the whole identification process of the NM is exactly
> > about giving Debian the possibility to report the charges on the guilty
> > developper when sued, isn't it?
> 
> Ehhh, I'm not sure I'd agree with that specifically, but whatever.

Mmm. If so, I really cannot understand the big deal with IDs when signing
the key. Knowing my ID is not enough to prove that I won't upload a rootkit,
and it is not even needed... I must be perticulary dumb.

> Honestly I see there being a very big difference between having rude
> things done in a translation and, for example, having packages which
> install rootkits.  Sorry, that's just life.

Sure. Who said the contrary ? I said that really broken translation can lead
to issues, too ("type 'Y' to erase/list the content of your home dir" ;).  
I never said that it was the most important point in Debian. I'm not *that*
dumb ;)

> > I know about the public servers, but I was wondering why Debian make things
> > harder for the DD while it has the infrastructure to simplify their work.
> 
> What is harder for the DD and how could the existing Debian
> infrastructure fix that?  Nothing in what you've said would lead me to
> believe that there's something we can change which would make things
> easier for the DD with regard to 'poor' translations.

The whole story is about easing the technical issue in a trust relationship.

Of course, I could (and have) uploaded my key on public servers, meaning
that other Debian member could check than a given mail with my address
desserve the trust they habitually give me. But those guys would have to 
configure their email specifically on people like me[*]. I was wondering if
could be avoided, that's all.

A really great improvement of this situation would be to make easily
available the keys of people in the NM queue, since translators are supposed
to become debian "developer", too.


But, ok, if the majority here says that there would not be sufficient
benefit wrt the effort, I guess I'll have to deal with it. Easy :)


Thanks for your time, and sorry for preventing you fixing bugs.
Mt.

[*] Yeah, I use my personal example because of my borken non-native english,
to ease my sentences and have a little chance to get them right, But in
fact, we are a whole bunch in my situation.

-- 
Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe.
  --- F. Nietzsche

NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote:
> * Christian Perrier ([EMAIL PROTECTED]) wrote:
> > Quoting Stephen Frost ([EMAIL PROTECTED]):
> > 
> > > > I, for sure, cannot hijack any package for which nothing has been done
> > > > for translation related bugs. I would quickly end up with dozens of
> > > > packages I'm responsible for, the majority of which I'm perfectly
> > > > unable to maintain.
> > > 
> > > If you can't maintain the package then you shouldn't be NMU'ing it.
> > > It's real simple, learn that.
> > 
> > WowThere's a strong difference between maintaining a package,
> > which means following it along its entire life and making one single
> > fix for a very specific thing.
> 
> Except what you don't realize is that one should never, ever, ever just
> NMU and then forget about the package.  If you do an NMU then you need
> to make sure it worked, follow the package and make sure there aren't
> problems with it and follow up with the maintainer on the bugs.  I don't
> care what you change in the package, if you NMU then you need to do that
> at a *minimum*, just as if you were the maintainer.  It's not until the
> official maintainer incorporates the NMU changes and closes the bugs
> that the NMU'er can forget about it.

Dude, translators already more than this. When I translate a package, I
register to its PTS to check that my translation does not trigger any
"translation bug report". 

Are you one of the guys considering translators as a technically handicaped
plague of the Debian world? I know that most of the time, the problem is
between the screen and the chair, but that's not always the case ;)

Of course, translators can only do that for the package whom they translate
the po files or documentation. People translating the debconf templates feel
often responsible for a few hundreds of them. The lack of i18n tag to bug
reports makes it impossible for them to watch the state of their work
efficiently that way.

For NMU, I know that Christian tracks every NMUed packages until the next
maintainer upload, to check that his changes are not broken or ignored. If
you speak some french, come on debian-l10n-french for one week, to see the
logistic issues we are facing, and how we address them. If you speak another
language, go to the relevant debian-l10n- list, I'm sure that the french
team is not an exception here, but rather the average.

> > I'm perfectly able to do the changes required by the NMU i send,
> > mostly po-debconf switches or translation incormoration. But, if a bug
> > related to something completely different in the package occurs, then
> > I cannot fix it be cause I'm not invloved in the given software.
> 
> Then you shouldn't be doing an NMU on it.  When you NMU something you
> take responsibility for it temporairly until the maintainer gets back.

Could you point the poor stupid monkeys we are to the relevant part of the
policy or developer reference or whatever other document ? I really do not
understand what let you think about NMU that way, especially after the last
bits of the RM...

> > For what I read, it is not required to be able to maintain everything
> > for a given package for being able to NMU it. It is just required to
> > be able to fix possible introduced bugs
> 
> Then what you read is wrong.

Again, why? Stating without argumenting will only bring us in yet another
fruitless flamewar. Please help us avoiding that curse.

> > They're not complex at all. Most of the time (for russian
> > translations), it is just required to know how to uudecode  file and
> > how should a debconf translation be named... :-)
> 
> A patch would probably still be easier, but whatever.

No offense intended, but this statement clearly shows a misunderstanding of
the issues the russian (and japaneese) translators are facing. If they
provide a simple patch, it is almost certain that the maintainer with
extract it from the mail and apply it with tools not well suited to the
weird encoding they need, leading to catastrophic results such as
undisplayable texts on user boxes, which is even worst than untranslated
ones, isn't it?

On the other hand, uuencoding the patchs helps to make sure that the
encoding will be preserved by the stupid mailers and wrong configurations
out there.

> > This is precisely what's currently happening.. :-)
> 
> Glad to hear it, perhaps some day you will, though personally I hope to
> hell you never manage to get it considered an RC bug, and I'll work to
> make sure that doesn't happen.

Who, beside you, spoke of raising the gravity of translation bugs to RC ?
Christian certainly meant that the normal gravity may be better appropriated
to such bugs, since it *does* make the package unusable under some
conditions (when the user cannot speak english, obviously). 

Let's be provocative: 

Stating the contrary may be bring down to the point that free software is
about making software freely available (as in free speach) to the american,

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote:

> > Dude, translators already more than this. When I translate a package, I
> > register to its PTS to check that my translation does not trigger any
> > "translation bug report". 
> 
> I'm not special caseing translations, nor do I feel they should be.  I'm
> referring to NMU's in general.

Maybe that's the point. Christian won't handle the same way non translation
bugs, because the changes implied are bigger and possibly more intrusive.
 
> > Of course, translators can only do that for the package whom they translate
> > the po files or documentation. People translating the debconf templates feel
> > often responsible for a few hundreds of them. The lack of i18n tag to bug
> > reports makes it impossible for them to watch the state of their work
> > efficiently that way.
> 
> This hasn't got anything to do with NMU's.

With NMU in general, maybe not. But I see this as rather relevant to the
kind of NMU we are talking about. If we add such tag, translators could
follow the result of their work. Same thing for NMUer of translations.

> > For NMU, I know that Christian tracks every NMUed packages until the next
> > maintainer upload, to check that his changes are not broken or ignored. If
> 
> Yet he admits that he can't actually maintan the packages he uploads via
> an NMU.  That's what I have a problem with.

Well, he said that he cannot handle any kind of bugs rising in any kind of
package. Yet, he can handle any kind of issue related to l10n and a bunch of
i18n issues.

> The RM is the one who said we should be "taking more care doing NMUs
> than doing your own packages".

And that's exactly what is done here. We are not speaking of automated mass
NMU, but manual carfull and as rare as possible ones, with tracking the
future of the package afterward. I understand your point about what could be
an NMU fest, but this is not the case. The procedure *is* followed (beside
the fact that they imply wishlist bugs).

> I've pointed out numerous times in this thread already why it's wrong to
> believe that you can NMU a package without having any responsibility to
> it afterwards, except maybe for the bits you changed.  Having that kind
> of an attitude is detrimental to the distribution as a whole.

Fully agreed. Who behave so badly ?
 
> > > A patch would probably still be easier, but whatever.
> > 
> > No offense intended, but this statement clearly shows a misunderstanding of
> > the issues the russian (and japaneese) translators are facing. If they
> > provide a simple patch, it is almost certain that the maintainer with
> > extract it from the mail and apply it with tools not well suited to the
> > weird encoding they need, leading to catastrophic results such as
> > undisplayable texts on user boxes, which is even worst than untranslated
> > ones, isn't it?
> 
> patch won't handle it properly?  Attaching the patch to a mail message
> instead of including it directly doesn't work?  Funny, I recall applying
> a patch for OpenLDAP using just such a mechanism without having a
> problem.

Well, either you were lucky, or you use good and well configurated mail
tools. But if my language did need a funky encoding, I would not let my work
depend of such conditions. Don't get me wrong. I mean that in such
condition, uuencoding prevents the DD from shouting himself in the foot, and
I've the feeling that it helps anyone, including the developer.

> So you're talking about it actually being a patch just uuencoded?  That

Err. Yes, that's what I meant. I may say it wrong, though. Sorry about that.

> > Who, beside you, spoke of raising the gravity of translation bugs to RC ?
> > Christian certainly meant that the normal gravity may be better appropriated
> > to such bugs, since it *does* make the package unusable under some
> > conditions (when the user cannot speak english, obviously). 
> 
> I'm tired of having to repeat for you what's been said in the thread.
> Try reading it before you attempt to comment on it.  Christian said:
> 
> > The key point, as usual, is the "wishlist" status of translation bug
> > reports. I, as a non native english speaker, do not consider
> > translation to be only a "wish", but a requirement.
> 
> I considered 'requirement' to be 'RC' level.  He didn't disagree.

I did read this mail. He did not agree either. Christian did say that he
felt that discution leaded to nowhere because of radical opin

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> 
> > > This hasn't got anything to do with NMU's.
> > 
> > With NMU in general, maybe not. But I see this as rather relevant to the
> > kind of NMU we are talking about. If we add such tag, translators could
> > follow the result of their work. Same thing for NMUer of translations.
> 
> As I said above, which you apparently missed, I'm referring to NMU's in
> general.

No, I did not miss your point, but we (ie, almost everybody in the thread
beside you) are speaking of the special case of translation bug NMUing. I
also understood that you feel that such thing is a bad thing. 

What I still wait for is another solution around that particular problem.

If I understand correctly, you seem to say that packages with dormant
translation bugs should be orphaned or removed from the distribution. If so,
then *you* think that translation bugs are RC, don't you? On which other
argument do you want to orphan packages with dormant translation bugs when
other kinds of bugs are not sufficient to orphan the package? 

I do not think that translation is a sufficient issue to orphan the package,
even if the fact that having such simple fix not applied shows that the
maintainer either 1) does not know what to do with the patch 2) does not
trust the patch since he cannot check it 3) have so few interest in
translations that he does not bother dealing with the bug 4) is MIA, at
least temporarily.

I don't belive in 1. If you cannot handle a patch, then you shouldn't
maintain a package. No matter if it's uuencoded or not. It was said earlier
in the thread that the dormance of translation bugs was not a trust issue,
discarding 2. Moreover, that's what the debian-l10n-* lists are made for.

I have no problem with people falling in the 3rd category. Everybody has his
own center of interest. That's fine as long as translators can do their part
of the job. But if we cannot NMU such package, what can we do? 

Contrary to you, I have no problem either with MIA maintainers. We all have a
real life, and not tuning every day packages which are free of issues
(beside whishlist ones) is also ok for me.

I guess that most of the packages Christian NMUs are somewhere between 3 and
4. What do you propose to get these bugs integrated beside of NMUing and
raising the gravity of the bug, which we do not want to do?

> I'm starting to tire of this.  If you can't maintain the package you
> shouldn't be NMU'ing it.  It's really that simple.

Maybe you're tired of typing the same sentences with no argument in it?

Quoting the RM bits: "You should consider this perhaps your one and only
chance to get some fix you desperately need into sarge, whether it be to a
release-critical bug, an important bug, a normal bug, a minor bug, or in
many cases even a wishlist bug." 

The french translation team aims at providing a fully translated
installation, *including the package installations*. That's the sub-release
goal of our sub debian team. We only speak of using the opportunity offered
by the RM to do so.

> > > I've pointed out numerous times in this thread already why it's wrong to
> > > believe that you can NMU a package without having any responsibility to
> > > it afterwards, except maybe for the bits you changed.  Having that kind
> > > of an attitude is detrimental to the distribution as a whole.
> > 
> > Fully agreed. Who behave so badly ?
> 
> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

So, what do you think of people currently going through the RC bugs and mass
NMUing packages they do not intend to maintain afterward, just to fix
compilation bugs? I've the feeling that you strongly disagree with this
behaviour too, but I may be wrong.

> > So, once again, nobody here is threating to open RC bugs against all
> > packages not translated in a given language. Nobody even spoke of opening
> > bugs because a given program is not translated.
> 
> You, again, didn't read the thread. 

Your attitude is kind of arrogant on that point. My broken english does not
prevent me to read the thread, which I did.

> No one said anything about
> threating to open RC bugs, etc, etc.  There was, however, a discussion
> about the possibility of changing the severity level at some point in
> the future to where translations would be considered RC-level bugs. 

And I did clearly state that it was not the case. 

The only explanation I hav

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Mon, Aug 25, 2003 at 01:19:57PM +0100, Mark Brown wrote:
> On Mon, Aug 25, 2003 at 01:22:03PM +0200, Christian Perrier wrote:
> 
> > With the former (and still widely used) method for translating debconf
> 
> Is anyone maintaining statistics on how widely used the original Debconf
> scheme is?

Greping around in (I love grep-dctrl)
http://ftp-master.debian.org/~barbier/l10n/material/data/unstable.gz
(used to generate w.d.o/intl/l10n) 

shows me that there is 2122 strings using old debconf and
http://www.debian.org/intl/l10n/po-debconf/rank
says that there is 3421 strings using po-debconf.

I have no historic on that data; these are the files integrated in the
packages, not counting the opened bugs not yet integrated, neither the
switches underway and not yet submitted.

So, I guess that the transition will be achieved for sarge + 1, at least.

Earlier if the french team reachs its goal of completely translated package
install in sarge, since we only translate po-debconf files, and do (read
submit as patch) the switch if needed. ;)

Bye, Mt.

-- 
Never trust someone who only codes in CAML... because the way things are
done matters more to him than the result.

Updating packages' l10n without risk (~unrelated to previous)

[Martin Quinson]

On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> On Fri, 22 Aug 2003, Christian Perrier wrote:
> 
> > And, as Steve pointed out, translation stuff is minimalistically
> > invasive so this does not require an enormous amount of attention
> > after the NMU.
> 
> Yes, but there are new libraries that get linked to, new compilers, etc.

It should be possible to get the source, rebuild to needed mo files
(containing the translation in a compiled form), unpack the binary package,
add the mo file and repack the binary package, shoudn't it ?

Of course, you have to bump the package number when doing so,

Of course, this is useless if the maintainer does not integrate the
translation since it has to be done each time.

Of course, this is only possible for the program translations, and not the
translation of material used by debconf (at least I'm less confident) or
others.


I do not plan to do so anytime soon (or later), I merely ask about
feasability.

Proper l10n in debian is a big puzzle, and I don't even know the pieces
yet :)


Thanks, Mt.

-- 
Finally it's Poland's turn to invade someone else's country.
We have to understand them, as they have been deprived from
that pleasure for such a long time.

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Mon, Aug 25, 2003 at 03:15:07PM -0400, Stephen Frost wrote:
>
> I'm not against translations.

I did the same error than Sven when reading your first definitive statement.
Apologies again.

> Perhaps even have a system where
> translations can be done without NMU's and have a seperate system for
> them which would make it easier for maintainers and translators alike.
> 
> On the other hand, I have strong feelings about NMUs.

For sure. I'm happy that after 1452353532 mails, we are about to reach a
point on which we could both agree. :)

Be sure that the people NMUing for translation (ie, Christian) are not
feeling comfortable with this situation. We know that it's a risky game to
play, and that if something goes wrong, we will get the flames we deserve
here...

But even if I though really hard about that issue, I cannot see any solution
to dormant bugs in otherwise bug free packages.

I dream every day of a centralization system allowing the developer and
translators to work hand in hand and not more or less despite of each other
as the current system often implies. But I still miss some pieces of the
puzzle (conceptually) and do not have time to implement the others for now.

(BTW, #206363 waits for someone with (very) basic python abilities having
 one or two days free)

Until now, we did deal with this and waited for better days. But the RM
explicitly stated that the only solution to get a given point fixed before
sarge may be to NMU it in the next few weeks. With this new deal, we have to
play another game to fulfill our goals.

> NMUs should not be used to update packages of maintainers who are MIA.
> They should not be used as a blunt instrument.  If a maintainer is MIA
> then their packages should be orphaned to QA, hijacked, or removed.
> Blunt instruments should be avoided, they don't work all that well.

Well, I guess that Christian is able to put QA as maintainer for packages he
uploads for l10n bug in dormance since more than N months, but I've the
feeling that it would raise even more issues and flames than it solves...



But I should stop writting long mails to d-d, let you guys work on the RC
bugs and other issues implied by sarge release, and become more studious on
redacting this damn PhD thesis. I'll try from now. I promise. Don't worry,
I'll be back after sarge comes out. You guys won't get ride of me that
easily. And there is many of me. :)

Bye, Mt.

-- 
Finally it's Poland's turn to invade someone else's country.
We have to understand them, as they have been deprived from
that pleasure for such a long time.

Re: non-DD contributors and the debian keyringS

[Martin Quinson]

On Wed, Aug 27, 2003 at 12:35:36AM +1000, Hamish Moffatt wrote:
> On Mon, Aug 25, 2003 at 05:18:45PM +0200, Sven Luther wrote:
> > On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote:
> > > * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > > > On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> > > > > keyring.debian.org has only DDs in it.  I think people were suggesting
> > > > > using the public keyservers.  keyring.debian.org isn't a part of the
> > > > > public key servers.
> > > > 
> > > > That's the part of the system I was criticizing :)
> > > 
> > > Not going to change.
> > 
> > Why ?
> 
> Because an entry in the Debian keyring gives you voting rights, and so is
> limited to developers.

DudeS, there is already _4_ keyrings.  [If you don't belive me, have a look
at /usr/share/doc/debian-keyring/README.gz ;]

We are speaking about adding a 5th keyring to debian, for example for the
NM, or more generally for people not in the main keyring for a reason, but
which key may have a place on Debian for some reason.

Of course I was not asking to go in the main keyring without going through
the NM process, and being allowed to vote, upload packages, log on
servers...

> Maybe there's an argument for other classes of voting project member
> other than just developer (typically package maintainer) such as a
> translator or documentor. Those roles might have voting rights (ie be in
> the keyring) but not machine access or something, and a different (less
> rigorous?) NM process. I suggest you start a thread on debian-project if
> you think so.

Yes, thanks for the advice. I'm the kind of guy who forgets always that
d-d is for developers, and that all members have to be (said) developer, but
that d-d is not for the dicussion about the project as a whole... Sorry.

Thanks for your time, Mt.

-- 
The "US department of defense" should be renamed the "US department of
attack". 

Re: Updating packages' l10n without risk (~unrelated to previous)

[Martin Quinson]

On Tue, Aug 26, 2003 at 12:12:07AM +0100, Andrew Suffield wrote:
> On Mon, Aug 25, 2003 at 10:27:44PM +0200, Martin Quinson wrote:
> > On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> > > On Fri, 22 Aug 2003, Christian Perrier wrote:
> > > 
> > > > And, as Steve pointed out, translation stuff is minimalistically
> > > > invasive so this does not require an enormous amount of attention
> > > > after the NMU.
> > > 
> > > Yes, but there are new libraries that get linked to, new compilers, etc.
> > 
> > It should be possible to get the source, rebuild to needed mo files
> > (containing the translation in a compiled form), unpack the binary package,
> > add the mo file and repack the binary package, shoudn't it ?
> 
> It might be better to ask why we are shipping translations in the
> package at all, and figure out how to make it work with them split
> out. Our current infrastructure can't handle it, but it's probably
> possible to figure out something which can.

Well, people already sometime split the documentation out of the package, so
I guess there is no fundamental reason in dinstall, katie or other
maintainance script for not doing the same about languages.

But that would mean multiplying the number of packages by about:
 \times 3-10 for all languages
 \times 1.5 to split out the documentations which are not yet (plus separating
   the man pages useless on computational servers from the extra
   documentation)
 \times 3-10 again, to split the documentation depending on the language
 
And since dpkg is known for not scale well in number of packages in the DB
(#69192, #157060), the package management system would certainly explode.

There is some well known optimisation in the dpkg parser, and the dpkg team
is working on it: tuning (#74259, #139838, #160447, #206416), use of binary
DB when possible (#149760), use of a flex parser (#179296), and maybe others. 

Most of these bugs are taged patch, so there is nothing I can do as not dpkg
developper, beside praying every night that the real life of doogie and
wichert leave them more time (to look at those patch and tell us what does
not fit in them), and wait for better days. What I do quite happily.
   
Another interesting lead is the split of the status DB in several files. One
for the critical information, and others for the less critical ones
(description, ..). It was proposed back in august 2001, and I proposed my
help to propose a patch, once the dpkg maintainer explained to me how they
wanted to design the beast. A summary of this discution is at:
http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02193.html
(partial summary, since it's mine :)

Answer was in the spirit of:
http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200109/msg00082.html

and I'm still waiting for the day where capable people will be given the
time to think about the design and inform me. But that's ok, I'm unable to
do what the dpkg team does, so how could I dare complaining?

> I don't have an interest in doing this, but somebody might.

I do :)


Thanks for your time, Mt.

-- 
No, I'm not going to explain it.
If you can't figure it out, you didn't want to know anyway...
   --- Larry Wall

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Tue, Aug 26, 2003 at 07:28:03PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> > Let's say i do translataion work, for that i have to build the package,
> > and notice that it FTBFS (at least on some obscure arch or something). I
> > then fill a FTBFS bug report, thus liberating me of the responsability
> > you want to trust on me, and then NMU the translation improved package.
> 
> Uh, no. If it liberates you of anything, it'll likely be your ability to
> do any more NMUs.
> 
> If the package is less useful to people after you do the NMU than before
> you started looking at it, that's a problem. If it was formerly able
> to be run by everyone no matter which architecture, and now no longer
> works on alpha, that's a problem.


If I were in Christian shoes facing such issue (dormant l10n bug, but the
rebuild triggers a FTBFTS), I would report the FTBFTS, and look at another
package (ie, not doing the NMU if he obviously cannot do it right). 

If it's too late already (ie, the FTBFTS is trigered by build daemons on
alpha or other), I will go cry on debian-l10n-french or other to get some
help. I am coordinator of the french l10n, but in the civilian, I work on
massively heterogeneous platforms (yup, da grid). So, I guess I could try to
work around such issues. I know some perl semi-gods in the team. Other
members may be good at libraries puzzles.

As we work heavily in team, we know that the responsability of fixing the
mess we introduce in NMUs is ours. Not only Christian's, but ours. And our
chance is that there is many of us, all wanting to get a better l10n, but
with not only translating abilities (in fact I'm even rather bad at
translating).


Little need to worry about who's responsability it is to fix the mess, it
has to be done, that's all.

Thanks for your time, Mt.

-- 
Un clavier azerty en vaut deux.

Re: SAL

[Martin Quinson]

On Thu, Sep 04, 2003 at 07:25:16PM +0300, Aigars Mahinovs wrote:
> Hello,
> 
> How would this do as a mass RFP :)
> 
> http://sal.kachinatech.com/
> 
> SAL (Scientific Applications on Linux) is a collection of information
> and links to software that will be of interest to scientists and
> engineers. The broad coverage of Linux applications will also benefit
> the whole Linux/Unix community. There are currently 3,070 entries in SAL
> 
> Most of the software is not GPL, but about a half is and can be
> packaged. I never thougt that Linux has THAT many scientific progs that
> are not in Debian jet. :)

>From the bunch of cruft, which perticular application are you looking for ?

Thanks, Mt.

-- 
Programming in Bourne-Shell is a higher form of masochism.

Re: your mail

[Martin Quinson]

On Thu, Sep 04, 2003 at 10:44:08PM -0700, Joshua Kwan wrote:
> On Fri, Sep 05, 2003 at 07:15:57AM +0200, Martin Godisch wrote:
> > Are these actually used somewhere? If I switch my browser language I see
> > packages.d.o still in English, if I switch my environment, dselect and
> > apt-cache show package descriptions still in English... What are these
> > translations good for?
> 
> Oh, also debconf templates are translated there for use in po-debconf,
> but those usually get to the BTS anyway.

Err, AFAIK, the ddtp translates the old-style debconf templates. Ie, without
using po-debconf. Or, even worse, using the files /generated/ by po-debconf.

I guess Grisu is working on adding the native po support to the ddtp. Until
then, the most advanced teams in translating debconf (ie, french and
portuguese) are not using the ddtp for that, which is a kind of evidence in
my mind.

> But there's an apt floating around that has support for showing
> localized package descriptions if availbale. It was announced awhile ago
> without great fanfare, but perhaps it will get merged sometime.

http://lists.debian.org/deity/2003/deity-200307/msg00359.html

Bye, Mt.

-- 
"2+2 = 5 ... Pour d'assez grandes valeurs de 2"

translations and the ddtp

[Martin Quinson]

On Fri, Sep 05, 2003 at 11:21:18AM +0200, Wouter Verhelst wrote:
> Op vr 05-09-2003, om 09:16 schreef Martin Quinson:
> > On Thu, Sep 04, 2003 at 10:44:08PM -0700, Joshua Kwan wrote:
> > > On Fri, Sep 05, 2003 at 07:15:57AM +0200, Martin Godisch wrote:
> > > > Are these actually used somewhere? If I switch my browser language I see
> > > > packages.d.o still in English, if I switch my environment, dselect and
> > > > apt-cache show package descriptions still in English... What are these
> > > > translations good for?
> > > 
> > > Oh, also debconf templates are translated there for use in po-debconf,
> > > but those usually get to the BTS anyway.
> > 
> > Err, AFAIK, the ddtp translates the old-style debconf templates. 
> 
> Well, your knowledge is outdated, then. Please check your facts next
> time :-)

It's not so often that I'm so happy to be wrong ;) 

Are you sure that the templates are stored under the po format during their
whole lifetime? Since when is it so? Where did I oversee the announcement?

Are the templates extracted from the source package now, or still from the
binaries? 

Thanks for correcting me, Mt.

-- 
Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe.
  --- F. Nietzsche

Re: "Single point of entry" for translation work?

[Martin Quinson]

On Mon, Sep 08, 2003 at 07:29:27PM +1000, Matthew Palmer wrote:
> On Mon, Sep 08, 2003 at 11:21:00AM +0200, Andreas Metzler wrote:
> > Matthew Palmer <[EMAIL PROTECTED]> wrote:
> > > On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote:
> > >> W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: 
> > >>> Is there a page somewhere that I can point people to for all translation
> > >> work relating to Debian (DDTS, po-debconf, etc)?  Just trying to make the
> > >> debian-mentors FAQ as useful as possible...
> > 
> > >> Take look at http://ddtp.debian.org/
> > 
> > > AFAICT, that site only covers descriptions.  I'm looking for somewhere (if
> > > it exists, even as a link farm) to the DDTP, Debconf, and documentation
> > > translation efforts.
> > 
> > Check the left column, it does cover debconf.
> >  Stats
> > [...]
> > debconf
> 
> OK, that looks good.  Is there a similar "coordination" page or site for
> documentation translations?

Please don't use the ddtp as entry point to translation. Use w.d.o/intl.

Thanks, Mt.

-- 
The nice thing about standards is that there are so many to choose from.  And 
if you
really don't like all the standards you just have to wait another year until 
the one
arises you are looking for
  -- Tannenbaum, 'Introduction to Computer Networks'

translations and the ddtp

[Martin Quinson]

On Fri, Sep 05, 2003 at 11:21:18AM +0200, Wouter Verhelst wrote:
> Op vr 05-09-2003, om 09:16 schreef Martin Quinson:
> > On Thu, Sep 04, 2003 at 10:44:08PM -0700, Joshua Kwan wrote:
> > > On Fri, Sep 05, 2003 at 07:15:57AM +0200, Martin Godisch wrote:
> > > > Are these actually used somewhere? If I switch my browser language I see
> > > > packages.d.o still in English, if I switch my environment, dselect and
> > > > apt-cache show package descriptions still in English... What are these
> > > > translations good for?
> > > 
> > > Oh, also debconf templates are translated there for use in po-debconf,
> > > but those usually get to the BTS anyway.
> > 
> > Err, AFAIK, the ddtp translates the old-style debconf templates. 
> 
> Well, your knowledge is outdated, then. Please check your facts next
> time :-)
> 
> (they do both...)

I did recheck, and the fact is that I'm right and you are wrong, sorry about
that.

The translations of debconf templates in the ddtp are always as broken as
they used to be. The templates are extracted from the binary package, and
then reformated to the po format. But it means that previous translations
are lost in the process of updating, for example. That means that you have
to choose between using the ddtp always or never. Using it once leads to
unacceptable translation loss.

Moreover, the update is not done, which leads to wrong results. Check for
example http://ddtp.debian.org/debconf/maintainer/[EMAIL PROTECTED]
about slrn. The german translation is reported to be completed (17/17) while
the french one is not that advanced (14/17). 

But when looking at the source code of slrn, I get the following:
/tmp/slrn-0.9.8.0/debian/po$ msgfmt --statistics fr.po 
25 translated messages.
/tmp/slrn-0.9.8.0/debian/po$ msgfmt --statistics fr.po
17 translated messages.
/tmp/slrn-0.9.8.0/debian/po$ debconf-updatepo 
/tmp/slrn-0.9.8.0/debian/po$ msgfmt --statistics fr.po 
25 translated messages.
/tmp/slrn-0.9.8.0/debian/po$ msgfmt --statistics  de.po 
17 translated messages, 3 fuzzy translations, 5 untranslated messages.

When the maintainer does not run the debconf-updatepo, there is little to do
for statistic extractors (and w.d.o/intl/l10n also report the german
translation as completed), but I dunno where the ddtp gets that the french
template is not translated. I guess the data where not updated since the
version 0.9.7.4-23 of slrn, which updates the french translation (according
to the relevant changelog). For information, it was released the 17 Oct
2002. But I may be wrong on the explanation, of course. The fact is that it
is not uptodate.

Moreover, if you really want me to state my feeling about the ddtp, I don't
feel it really reliable. The web page is a nightmare to navigate since there
is so much broken links. It is also very very difficult to translate, since
all translations are in the same wml file (that's exactly the broken design
po-debconf solves for debconf). That's kind of sad that people commited to
translations did such an internationalisation error.

And the adress to use is now [EMAIL PROTECTED] (or something like that).
It exists since 10 days since the previous one stoped to work a while ago.
And it looks like that it is now broken as well.


So, please, next time, *you* should check your facts before switching to the
arrogant mode.


And to answer the original question, no, the ddtp is not the central point
of translation in debian. There is no such page right now, but the better
existing approximation for now is www.debian.org/international 

Note however that I do not try to minimize the work of grisu and others on
the ddtp. I'm just saying that there is still issues which have to be solved
before the ddtp (which means debian *description* translation project) can
be used as central point for that.

Thanks for your time, Mt.

-- 
Every day of my life I am forced to add another name to the list of people 
who piss me off!
--- Calvin

Re: Converting configure.in for use with new auto* tools - what a mess!

[Martin Quinson]

On Sat, Sep 27, 2003 at 12:23:54PM +0200, Richard Atterer wrote:
> Hi,
> 
> I've fixed a critical bug in w3c-libwww and now want to regenerate all the 
> libtool/autoconf/automake files. Not trivial!

[...]
 
> I've uploaded the file to  - could 
> some autoconf-knowledgeable person please have a look at getting it to work 
> with the w3c-libwww sources, or give me some hints what I need to fix?

I use the attached bootstrap script to build the autotools scripts. the
version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel
free to steal anyway ;)


First, remove acconfig.h from the archive. It triggers a warning in
autoheader and is unneeded. (also remove the occurence of its name in
Makefile.am) Do not erase it, but move it away. You'll need it afterward.

Then, rename configure.in to configure.ac to make clear to the autotool that
you are planing to use autoconf 2.50.


And most of your problems comes from the fact that the acinclude.m4 (ie, the
local definitions) contains macros of the same name than ones distributed by
default in modern autoconf versions.
Get rid of the definition of AC_C_VOLATILE and AC_HEADER_TIOCGWINSZ in
acinclude.m4 Those macros are not used in the w3c-libwww source code
(according to grep), and serve only to mess autoconf up.


Then, there is a bazillon of warnings in autoheader about "missing
templates". It does complain about AC_DEFINE without third argument (giving
the meaning of the define for comments in the www-config.h header). Get
those comments from the acconfig.h file and put them as third argument where
needed. If there is no second argument do:
AC_DEFINE(HAVE_READDIR_R_3,,[Define to use the three-argument variant of 
readdir_r])
I would say it is safer to put the comment between square braces like that.


Then automake-1.7 complains that way:
Library/src/Makefile.am:53: CPPFLAGS' is a user variable, you should not
override it;
Library/src/Makefile.am:53: use AM_CPPFLAGS' instead.

He is right. Defining CPPFLAGS from an Makefile.am is a Bad Thing (TM). Just
rename the variable the way it tells you, it will take care of adding this
to the right variable automatically.


And the configure runs. I guess it means that your issues are solved. It was
mainly the dupplicate definition of macros. autotools are always bitches
about error messages. That's why I like them so much ;)

If you need more help, please make available a tarball solving the bunch of
warning trigered by autotools.


HTH, Mt.

-- 
The unavoidable price of reliability is simplicity.
--Hoare



pgpr0RyEbCvj9.pgp
Description: PGP signature

Re: Converting configure.in for use with new auto* tools - what a mess!

[Martin Quinson]

On Sat, Sep 27, 2003 at 01:54:36PM -0500, Branden Robinson wrote:
> On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote:
> > I use the attached bootstrap script to build the autotools scripts. the
> > version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel
> > free to steal anyway ;)
> 
> As far as I could tell, this message had no attachment (apart from the
> message body and signature).

Ups
#!/bin/sh

##
## Some defs
##

PKG_NAME="w3c-libwww"
# a list of all dirs containing possibly some macros
acmacrodirs="${HOME}/share/aclocal ${PWD}/tools/acmacro ${PWD}/m4"
 
##
## End of conf part
##
for dir in $acmacrodirs ; do
   if test -d $dir ; then
   aclocalinclude="$aclocalinclude -I $dir";
   fi
done

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

echo "Autoregenerate package \`$PKG_NAME' in directory \`$srcdir'";

(test -f $srcdir/configure.ac \
  && test -f $srcdir/Robot/src/RobotMain.c) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

##
## Some tests (borrowed from Mt who borrowed it from 
## macros/autogen.sh from achtung)
##
DIE=0

(autoconf --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: You must have \`autoconf' installed to compile $PKG_NAME."
  echo "Download the appropriate package for your distribution,"
  echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/";
  DIE=1
}

(grep "^AM_PROG_LIBTOOL" $srcdir/configure.ac >/dev/null) && {
  (libtool --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "**Error**: You must have \`libtool' installed to compile $PKG_NAME."
echo "Get ftp://ftp.gnu.org/pub/gnu/libtool-1.4.tar.gz";
echo "(or a newer version if it is available)"
DIE=1
  }
}

(automake-1.7 --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: You must have \`automake' 1.7 installed to compile 
$PKG_NAME."
  echo "Get ftp://ftp.gnu.org/pub/gnu/automake-1.7.tar.gz";
  echo "(or a newer version if it is available)"
  DIE=1
  NO_AUTOMAKE=yes
}

# if no automake, don't bother testing for aclocal
test -n "$NO_AUTOMAKE" || (aclocal --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: Missing \`aclocal'.  The version of \`automake'"
  echo "installed doesn't appear recent enough."
  echo "Get ftp://ftp.gnu.org/pub/gnu/automake-1.3.tar.gz";
  echo "(or a newer version if it is available)"
  DIE=1
}

if test "$DIE" -eq 1; then
  exit 1
fi
## END of test part


##
## Action part
##
if test -z "$*"; then
  echo "**Warning**: I am going to run \`configure' with no arguments."
  echo "If you wish to pass any to it, please specify them on the"
  echo \`$0\'" command line."
  echo
fi
echo "Generating configuration files for $PKG_NAME, please wait"
echo;

case $CC in
xlc )
  am_opt=--include-deps;;
esac

#for coin in  `find $srcdir -name configure.ac -print `\
# `find $srcdir -name configure.in -print`
for coin in $srcdir/configure.ac
do 
  dr=`dirname $coin`
  if test -f $dr/NO-AUTO-GEN; then
echo skipping $dr -- flagged as no auto-gen
  else
echo ""
echo "* Processing directory $dr"
echo ""

if [ -e $dr/configure.in ] ; then
   configfile="configure.in"
else 
   configfile="configure.ac"
fi
macrodirs=`sed -n -e 's,AM_ACLOCAL_INCLUDE(\(.*\)),\1,gp' < $coin`
  pwd=`pwd`
  cd $dr
  if grep "^AM_PROG_LIBTOOL" $configfile >/dev/null; then
if test -z "$NO_LIBTOOLIZE" ; then 
  echo "Running libtoolize --force --copy in "`pwd`"..."
  libtoolize --force --copy
fi
  fi
  echo "Running aclocal-1.7 $aclocalinclude..."
  aclocal-1.7 $aclocalinclude 
  if grep "^AM_CONFIG_HEADER" $configfile >/dev/null; then
echo "Running autoheader in "`pwd`"..."
autoheader
  fi
  echo "Running automake-1.7 --gnu --add-missing $am_opt ..."
  automake-1.7 --gnu --add-missing $am_opt
#  echo "Running automake m4/Makefile ..."
#  automake m4/Makefile
  echo "Running autoconf..."
  autoconf
  cd $pwd
  fi
done

#conf_flags="--enable-maintainer-mode"

if test x$NOCONFIGURE = x; then
  echo ""
  echo "* Running $srcdir/configure $conf_flags $@ ..."
  echo ""

  $srcdir/configure $conf_flags "$@" || exit 1
else
  echo Skipping configure process.
fi

echo Now type \`make\' to compile $PKG_NAME



pgp7O9BmjPUFR.pgp
Description: PGP signature

Re: Which packages will hold up the release?

[Martin Quinson]

On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote:
> Hi!
> 
> Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
> > I don't know the reason for some packages being marked [REMOVE] but it
> > seems to me that it is not just an 'This package is not essential for
> > a releas an useful distribution'.
> 
> OTOH, php4 is marked for removal. I assume that I'm not the only one
> that would classify it as important. In addition, it is odd that there
> are still packages depending on php4 which are not marked for removal.
> 
> I did not dig into the reasons why php4 should be removed (BTS says
> "see -release", but that doesn't tell me anything), so I don't object
> against it loudly. But I would certainly call it a pity if it
> disappears. It would make Debian much less useful for the average LAMP
> server.
> 
> Maybe someone can enlighten me here?

The removal of php4 was proposed as temporary measure to help sorting the
unstable -> testing progression. The plan is that it gets back into testing
before release. A quite usual trick. If a package A in testing blocks the
entry of a package B from unstable to testing, and in turn the lack of B
prevents the new version of A from unstable to testing, A is removed from
testing for a moment. But it is welcomed to get into testing again afterward. 

That's at least what I understood from -release.

The removal of php4 from testing (and not removal from unstable, which is the
death penalty for the package you were afraid of) was discussed in
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html

(which explains the reference to -release in the bug repport)

Now, glibc which were blocking the regular progression of php4 into testing
is solved, IIRC. The current status is discussed in:
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html

http://lists.debian.org/cgi-bin/searchlists
is your friend for more details.

Thanks, Mt.

-- 
I'm not griping, I'm just observing what a miserable experience this is.
--- Calvin


pgpIVg9vhQx3f.pgp
Description: PGP signature

Re: Which packages will hold up the release?

[Martin Quinson]

On Thu, Oct 02, 2003 at 02:10:21PM +0200, Peter Makholm wrote:
> Matthew Palmer <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
> >> A script that reads packages I'm interested in and prints out the
> >> RC-bugs I should try to fix would be usable. Does anyone have such
> >> script?
> >
> > Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
> > if you can't find it in the archives (recently, like < 6 months) e-mail me
> > and I'll send it to you.
> 
> Found it.
> 
> http://people.debian.org/~tbm/rc-alert
> http://people.debian.org/~tbm/wnpp-alert
> 
> Of course it assumes that the packages I'm interested in are the same
> as the pacakges I have installed which isn't always true. But it is
> usable.

To make this assumption more accurate, you may play a bit with deborphan and
debfoster.

Bye, Mt.

-- 
Le capitalisme, c'est l'exploitation de l'homme par l'homme.
Le communisme, c'est le contraire.
   -- Coluche


pgpbmnUAGZKxq.pgp
Description: PGP signature

Re: Czech translation of po-debconf templates completed

[Martin Quinson]

On Thu, Aug 18, 2005 at 10:38:00AM +0200, Marc Haber wrote:
> On Thu, 18 Aug 2005 08:53:44 +0200, Christian Perrier
> <[EMAIL PROTECTED]> wrote:
> >And now welcome to the wonderful world of angry translators, where you
> >will find your stats approaching the 100% Nirvana without ever
> >reaching it, thanks to the efforts of our fellow Debian developers who
> >constantly change their translations...:-)or omit updating their
> >packages with the new translations they receive...:-)
> 
> As for changing the templates, are there automatisms in place to fire
> off e-mails to the translators and their mailing lists to inform them
> of changed templates?

Nope, nothing automatic. There's a tool in podebconf to allow developper to
do this email when they want to, but nothing like an automatic reminder to
translators when a package containing outofdate translation from them is
uploaded

It would be cool, for sure, but it still has to be done. And as Christian
noted, the bottleneck is mostly on the developper side here. I mean that
there is more translator waiting for their translations to get integrated
than developpers waiting for a given translator to update his work.

Of course, what's automatic is that outofdate translations will get
discarded from what's shown to users. Until they get updated, users will see
the english message instead.

Bye, Mt.


signature.asc
Description: Digital signature

Re: Standardisation of the name of the patching targets included in debian/rules.

[Martin Quinson]

On Sun, Feb 03, 2008 at 06:32:42PM +0900, Charles Plessy wrote:
> Dear maintainers of CDBS, dpatch, and quilt,
> 
> if you are subscribed to [EMAIL PROTECTED], you must have noticed the
> long discussion about patch systems. An idea that was quite popular
> was to standardise the patch target in all patch systems used during
> package building.
> 
> Here is a summary of the targets used by the different makefile
> includes available to the developpers:
> 
> File  Package To patchTo 
> depatch
> /usr/share/dpatch/dpatch.make dpatch  patch   unpatch
> /usr/share/quilt/quilt.make   quilt   patch   unpatch
> /usr/share/cdbs/1/rules/patchsys-quilt.mk quilt   apply-patches   
> reverse-patches
> /usr/share/cdbs/1/rules/simple-patchsys.mkcdbsapply-patches   
> reverse-patches
> /usr/share/cdbs/1/rules/dpatch.mk cdbsapply-dpatches  
> deapply-dpatches
> 
> Since these five files provide patching facilities to a large number of Debian
> source packages, it would be very advantageous if they could use the same
> name for the patching and depatching rules: developpers could use them
> without needing ab initio knowledge of the underlying system.
> 
> Obviously, there is no solution that wouldn't require a change in at least two
> packages, and that is the reason I contact all of you and CC debian-devel.

Hello,

I'm sorry I'm so overhelmed currently that I cannot follow d-d.
Whatever the conclusion of the discussion is, I'll happilly follow it.

/usr/share/cdbs/1/rules/patchsys-quilt.mk follows the same "syntax"
than /usr/share/cdbs/1/rules/simple-patchsys.mk since it aims at being
a (decent) drop-in replacement for the cdbs trivial patch system.

I find personnaly patch/unpatch more easy to understand, but YMMV...

A solution would be to add "patch: apply-patches" pseudo-rules to cdbs
files, and such. 

Please fill a bug when you reach a consensus to keep me aware of it.

Bye, Mt.

-- 
There is no experimental demonstration of your theorem.
  -- Bastard Reviewer From Hell


signature.asc
Description: Digital signature

Re: Some observations regardig the progress towards Debian 3.1

[Martin Quinson]

I like this idea of pre-testing. It would allow to cut down the versionned
dependencies caused by automatic detection and allow a quicker move to
testing. 

The issue I see however is that a package rebuilded that way would go into
testing without being tested by anyone. What if a given package fail to work
when compiled with libs in testing? I agree that would be a missing
versionning in the build-dep, but who would detect it?

I'm afraid that such mistakes would lead to the disparition of the package
from testing until its versionned build-dep comes into testing, which would
be even more problematic than outdated content of testing, IMHO.

Thanks, Mt.


signature.asc
Description: Digital signature

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

[Martin Quinson]

On Tue, May 13, 2003 at 09:42:16AM +0200, Fabio Massimo Di Nitto wrote:
> 
> If you really believe that the apache description should be improved than
> you file a bug against apache asking to changing layout, proposing the
> better one so that everyone can be alligned to it.

If I understand well, you are bored because you think that the layout used
in french could be good in all languages, but the french translators sort of
kept it for themselves.

But we didn't do that because we don't think that the french typographical
rules should be used in all languages, as well as we think that the english
typographical rules do not apply in French.

> > We are performing a lot of reviews to ensure that the quality of the
> > translation is good. 3 translators were agreed to use this translation.
> 
> We did not, i will repeat this until the end of the world, discuss the
> quality of the contents. We are discussing the layout.

No, not exactly. We are not discussing esthetical layout here.

This layout in french is not only esthetical, it must be so because of
typographical rules[1]. That's why we didn't think that all languages must
follow the same rules. In written french, the typographical rules have
almost the same impact than gramatical ones.

But feel free to adapt this new layout to the original text if you want
to. Only, don't try to prevent us to follow the rules in our language.

For example, we always put a space before the colon symbol (a non-breaking
space when technically possible), but we won't repport as an error in the
original text a colon without space before (as requiered by english
typographical rules). That's the same kind of thing for us.

Bye, Mt.

[1] Lexique des règles typographiques en usage à l'imprimerie nationale,
ISBN: 2743304820. Available at:
http://www.amazon.fr/exec/obidos/ASIN/2743304820/qid%3D1047692993/sr%3D1-4/ref%3Dsr%5F1%5F2%5F4/402-2014446-9559346

-- 
Don't drink as root!

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

[Martin Quinson]

On Tue, May 13, 2003 at 12:57:51PM +0200, Fabio Massimo Di Nitto wrote:
> On Tue, 13 May 2003, Martin Quinson wrote:
> 
> > On Tue, May 13, 2003 at 09:42:16AM +0200, Fabio Massimo Di Nitto wrote:
> > >
> > > If you really believe that the apache description should be improved than
> > > you file a bug against apache asking to changing layout, proposing the
> > > better one so that everyone can be alligned to it.
> >
> > If I understand well, you are bored because you think that the layout used
> > in french could be good in all languages, but the french translators sort of
> > kept it for themselves.
> 
> No, I am not bored. People in some msgs wrote that the french layout is
> better. I am not against the fact that it can be better. Just use the
> right way so that everyone can benefit in a similar way.

But you missed our point saying that we don't want to use it in french
because it looks better, but because we have to. The fact that it looks
better and could be used in the other languages as well is another point,
and nobody in the french team never commented on that.

Again, in french, that's not just esthetical. And we, as french translators,
let you the decision about the esthetic of the thing for the other languages.

> I don't want to prevent you to use your language like i wouldn't like the
> otherw ay around. Is there any way to be closer to the original esthetical
> layout?

Nop. It must be so in French. The previous translation was an obvious error.

And I'm not the right person to decide if it's better looking in other
languages since I'm only native french speaker.



Your engagement for the quality of your package is really great. Only, I
think that you are not responsible of the translation. I know that there is
a lack in debian framework concerning this point, but it really should be so
('cause maintainer cannot be responsible for translations they do not
understand. How do you handle tranlations in russian, japaneese and
bokmal?).

Correcting this lack is a completely other topic, too large to be discussed
here (browse debian-i18n archives if you really care).

As long as this lack isn't corrected, feel free to mark all bugs
concerning the french translation as "forwarded to upstream", and forward it
to our mailing list. We will take care of them and help you to correct them.

Bye, Mt.

-- 
Learning and doing is the true spirit of free software -- learning without
doing gets you academic sterility, and doing without learning is all too
often the way things are done in proprietary software.
  -- Raph Levien 

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

[Martin Quinson]

[I only speak for myself, and not for the french translation team neither
for the ddtp, in which I'm not involved at all. Please flame *me* for what I
say]

On Wed, May 14, 2003 at 08:27:02AM -0400, Theodore Ts'o wrote:
> On Wed, May 14, 2003 at 12:07:29PM +0200, Martin Quinson wrote:
> >
> > Your engagement for the quality of your package is really great. Only, I
> > think that you are not responsible of the translation. I know that there is
> > a lack in debian framework concerning this point, but it really should be so
> > ('cause maintainer cannot be responsible for translations they do not
> > understand. How do you handle tranlations in russian, japaneese and
> > bokmal?).
> 
> This is a fundamental question for which there definitely isn't
> consensus, and it is a fundamental polity (governance) issue.
> 
> One is that the linguistic teams have full and ultimate responsibility
> over the translations, and there is no recourse or appeal if the
> maintainer doesn't like what they have done.   
> 
> Another position is that the maintainer is ultimately responsible; he
> or she may delegate responsibility to helpers, just as the Debian
> Leader may delegate certain responsibilities to subordinates.
> However, it is clear that the maintainer or the Debian Leader is
> ultimately responsible, even if the wise maintainer and/or Debian
> Leader may not choose to exercise his or her perogatives very often.
> 
> This point is a subtle one.  I will point out that in a corporate
> setting, it's quite normal for the employer's manager and or his
> manager's manager will not fully understand all of the work that that
> the employee does.  Yet they are still responsible for the work of the
> employee, and if they don't like it, they can tell the employee to do
> things a different way, or in the extreme case, they can fire him.
> 
> Obviously, if the manager doesn't completely understand what the
> employee is doing, there will be a certain negotiation, and a certain
> back and forth over goals and directions and what is and isn't
> technically possible, etc.  Hopefully, said negotiations will be done
> in a mutally respectful and civil manner.  But that doesn't change the
> fact that ultimately the manager gets to have the final say.
> 
> Which model people subscribe to makes a lot of difference in how they
> communicate.  For example, if your manager doesn't like the work that you
> do, even if you think his grounds for objecting may not be the best
> ones, would you tell him, "tough luck"?   Probably not
> 
>   - Ted
> 
> P.S.  To the extent that the DDTP gives the package maintainer veto
> rights, it seems pretty clear that at least initially the DDTP
> believed that the package maintainer was ultimately responsible.
> Given comments and the tenor of the tone made by some of the people on
> some of the language teams, it's not clear they believe that as
> strongly today.

Please keep in mind that I have nothing to do with the DDTP. My advice is
personal.

I completely agree with you on several points, like the fact that there is
no special reason in the constitution or in policy or in BCP or in any
official Debian writting to say that the maintainer is not responsible for
the content of the translations.

I only meant that it's rather illogical to ask to maintainer to review texts
in languages he/she don't understand. I know that this issue is related to
what can be found for porting to architectures the maintainer does not know,
but still, there is some quite fundamental differences here. 

Thanks to the wonderfull dbuild architecture, it is very easy to know if
there *is* a problem on a given architecture, and what the right solution
is (apply patches as long as dbuild repports an error). 

This is not true for translations, since no mecanical validation is enough.
Even if a text is ispell-clean, there might be a ton of gramatical error,
typographical ones and even badly constructed sentences which do not "sound
well". 

Moreover, languages are sometimes difficult even for native speaker. French
is a rather good example of this complexity, and explains why we cam up with
so complicated reviewing processes within our team: webpages are posted at
least three time to the ML, in [ITT] mails for 'intend to translate', [DDR]
for 'ask for review', and [RELU] for 'reviewed, ready to be commited'
emails ; the DDTP integrate a reviewing process where all description have to
be accepted by 3 other translators before being declared as usable by the
end user.

So, if we need so much work to find a good translation when all involved
people are native french speaker, how 

Re: Do not touch l10n files [without notifying translators]

[Martin Quinson]

On Wed, May 14, 2003 at 01:03:07PM -0500, Manoj Srivastava wrote:
> On Wed, 14 May 2003 19:17:50 +0200, Javier Fernández-Sanguino Peña <[EMAIL 
> PROTECTED]> said: 
> 
> > On Wed, May 14, 2003 at 02:18:04AM -0500, Manoj Srivastava wrote:
> >> As a package developer I hold veto powers over anything shipped in
> >> my package, since it is my signature that goes with it, and I am
> >> responsible for all bugs.
> 
> > You do hold upstream responsible for the bugs in their software
> > right?
> 
>   I don't shrug off my responsibilities so lightly. I am
>  responsible for all my packages. I may need help to solve or diagnose
>  some bugs, but every single bug on my packages receives my attention,
>  and I work on trying to gather enough information to help upstream
>  debug those issues.
> 
>   In case the upstream does not respond, or does not think it is
>  a bug, I create local patches. 
> 
> 
> > From my point of view, same should go for translators.
> 
>   Sure. When (if?) translated descriptions are included in
>  packages, I'll contact the translators fiirst, perhaps including
>  local changes until the matter is resolved.  Just like I do with
>  upstream code. 

So, I would say that you are handling translations right, and there is no
need to get hurt by Denis's complain. It wasn't directed at all maintainers,
but to the ones feeling confident enough to corrupt l10n files *without
informing the translator of their changes*.

I admit that his tone was quite categorical, but he was only repporting a
problem which exists (we have some example of bad habits, but giving any
name would only lead to more people feeling insulted, and a bigger flamewar,
which would help nobody). If you don't do the stuff he is complaining about,
if, as Colin said, the collaboration between you and the tranlators
colaborating on your packages is based on mutual respect, everything is
perfect, and there is no need for yet another flamewar here.

Please don't get me wrong. I understand that the tone of the complain may
lead too easily to such flamewar (ie, I don't say that you or anybody else
wanted to get this flamewar), but I would like people to understand that
instead of flooding -devel yet another time, we should document somewhere
what the best current practices are concerning l10n (yours are good
candidate), and try to ease the collaboration needed to achieve the l10n
goals.

> > Translation-related bugs should be the responsibility of the
> > translation teams (and should be forwarded to them).
> 
>   While translations reside outside my package, the bugs shall
>  be reassigned (or closed), not forwarded. When the translation is in
>  my package, the bug shall be forwarded, and perhaps I'll use local
>  patches to correct the issue. 

That's an interesting point. I asked for a translation pseudo package, so
that developpers can reassign bug repports about translations to somewhere
where translators can be made aware of the issue and work on it to help the
maintainer, but this request never leaded to any concret decision. :)


In my opinion, one of the problems here is that we have no infrastructure at
all to ease the l10n work, neither do we have any infrastructure to handle
properly the l10n bugs. I dream of something like the dbuild and
packages.qa.debian.org or qa.debian.org/developer.php for translators, but
there is still a very long road until there.

First step being to create a DT (debian translator) status, or renaming
Debian Developers to Debian Contributor, since the former name clearly do
not capture all the ways to contribute to Debian. You may think that it's a
dummy name problem, but the problem more complicated. 

In the past, I applyed to become DD with stating that I do not want to
maintain any package, only become translator. And most of the questions I
was asked was how to deal with bug repports against my packages, and how to
use lintian and yada to increase the quality of my packages...

[in the meanwhile, I begun helping to fix RC bugs, and repackaged doc-rfc to
solve the issues repported against it, for example, so those questions where
not that useless to that extend, but that's another story]


So, to summarize myself, if we would live in a perfect world, we would:
 1. Document the BCP concerning l10n, and repport as bug any maintainer or
translator not sticking to it (and only them)
 2. Think about improving (creating?) the l10n infrastructure within Debian.
Much more thinkings (=flamewar? ;) are needed for that.

Bye, Mt.

-- 
Computers are not intelligent. They only think they are.

Re: Where are translated man pages packaged?

[Martin Quinson]

On Thu, May 15, 2003 at 11:24:14AM +0200, Denis Barbier wrote:
> Hi,
> 
> There is currently no consensus whether translated man pages should
> be shipped along with original man pages or within manpages-xx packages.
> Unfortunately this leads to conflicts when a translation is first
> shipped by the latter, then incorporated into the former (e.g. when
> it becomes part of upstream tarball).
> 
> Some developers are reluctant to include French translated man pages and
> ask me to ship them in manpages-fr.  How can I make them change their
> mind?  Is there a consensus that translated man pages must go with
> original man pages?  Are exceptions needed for some packages?

I would say that the manpages-XX should disappear as source packages, and all
manpages-XX bin packages should be generated from the same source package.
That way, it would be really easier to check if the translations are
uptodate or not.
Alioth can be very useful to base a group in charge of maintaining this
package.

To answer your question, I would say that translated manpages have to be in
the same package than the original one when possible.
Concerning packages in base, where space is a concern, as far as dpkg cannot
handle properly translations (ie, until sarge+12 :) they can be placed in
the manpages-XXX packages. 

But that's only my opinion, Mt.

-- 
Tout dormeur a en lui un lève tard qui sommeil.

Re: Do not touch l10n files

[Martin Quinson]

On Thu, May 15, 2003 at 01:47:37PM -0500, Branden Robinson wrote:
> On Thu, May 15, 2003 at 03:40:57PM +0200, Denis Barbier wrote:
> > On Thu, May 15, 2003 at 01:25:56PM +0100, Thom May wrote:
> > > * Denis Barbier ([EMAIL PROTECTED]) wrote :
> > > > It has already been told more than once: in French, an itemized list is
> > > > preferred over a comma separated list when it gives a very long 
> > > > sentence.
> > >
> > > Now, preferred, in English, means "more desirable than another" not "we 
> > > must
> > > use this at all costs". So, again. We have said we don't like the layout 
> > > and
> > > would *prefer* that the translators change it. 
> > 
> > Following your definition of "prefer", you ask us to change it, but will
> > accomodate otherwise.  This is fine with me, let's see what the translator
> > will decide.
> 
> It's the package maintainer's preference that controls, unless he is
> overruled.  The procedures for overruling a maintainer's decision are
> described in the Constitution.

I guess that the translator (CCed) will prefer an ugly looking description
than getting in such war, which already took too much useful energy from
useful work. I mean, I still think that forcing the way stuff is translated
is not very wise from maintainers, but I naturally admit that when
translators and maintainers cannot find an agreement, the maintainer have to
be right.

Sigh, Mt.

-- 
If the facts don't fit the theory, change the facts.
  -- Albert Einstein

Re: Where are translated man pages packaged?

[Martin Quinson]

On Fri, May 16, 2003 at 10:02:18PM +0200, Fabio Massimo Di Nitto wrote:
> On Fri, 16 May 2003, Keegan Quinn wrote:
> 
> > On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote:
> > > On Fri, 16 May 2003, Keegan Quinn wrote:
> > > > > more than once i had to install small dns servers on boxes with less
> > > > > than 100Mb flash and stuff like that... so basically also the minimal
> > > > > installation has to be tight.. then rm doc and man and after install
> > > > > the minimum sets of pkgs to provide the services.
> > > >
> > > > Please do not try to force this methodology upon the standard Debian 
> > > > base
> > > > system.  Administrators of embedded systems have many tools to deal with
> > > > these problems already, that do not require ever unpacking the full base
> > > > onto the target.
> > >
> > > sorry but i can hardly read from the previous post that i am trying to
> > > force something to someone. I guess this is just a misunderstanding.
> >
> > Perhaps the word 'force' was a bit harsh, but it's essentially how it works
> > for an end-user.  It seemed to me that you were suggesting that the standard
> > installer should be optimized for embedded systems, which does not sound 
> > like
> > a very good idea.  These systems have many specialized needs which cannot be
> > easily accounted for.
> 
> No i was not suggesting either. I was just explaining why i would like to
> avoid to get a bigger base system and giving out one of the reason. it was
> an example, no more no less. anyway no big deal ;)

Ok, so, it wouldn't hurt anyone if all translated man pages were along the
original one, or did I miss something again ?

Thanks, Mt.

-- 
Dans la france profonde, il y a surtout des spéléologues.
   -- Le Chat

[RFC] Chapter for the debian reference about l10n

[Martin Quinson]

Hello,

I repost this because I got no feedback at all. I guess it shows that my
email was long enough for not being read :)

Thanks, Mt.

On Wed, May 14, 2003 at 05:29:00PM +0200, Martin Quinson wrote:

> In order to help the current discution to find an usefull conclusion, I
> would like to propose you the following blahblah for inclusion in the debian
> reference "Managing packages" chapter, for example after the one on porting
> and geting ported. This is very far from being perfect, and I would be more
> than happy to discuss it before the actual inclusion. But, please, do
> respect the reply-to to debian-i18n, so that we discuss it on the right ML.
> 
> Friendly, Mt.
> 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Internationalizing, translating and being internationalized and translated

Debian supports an ever-increasing number of natural language. Even if you
are native english speaker and do not speak any other language, it is part
of your duty as a maintainer to be aware of issues of internationalization
(abbreviated i18n because there is 18 letters between the 'i' and the 'n' in
internationalization). Therefore, even if you are ok with english only
programs, you should read most of this chapter.

According to "Introduction to i18n" from Tomohiro KUBOTA,
(http://www.debian.org/doc/manuals/intro-i18n/), "I18N
(internationalization) means modification of a software or related
technologies so that a software can potentially handle multiple languages,
customs, and so on in the world." while "L10N (localization) means
implementation of a specific language for an already internationalized
software."

l10n and i18n are tied, but the difficulties related to each of them are
very different. It's not really difficult to allow the program to change the
language in which texts are displayed based on user settings, but it is very
time consuming to actually translate the messages. On the other hand,
setting the character encoding is trivial, but adapting the code to use
several character encodings is a really hard problem.

Letting alone the i18n problems, where no general receipt exist, there is
actually no central infrastructure for l10n within Debian which could be
compared to the dbuild mecanism for porting. So, most of the work have to be
done manually

How are handled translations within Debian?
===
Handling translation of the texts contained in a package is still a manual
task, and the process depends on the kind of text you want to see
translated.

For program messages, the gettext infrastructure is used most of the time.
Most of the time, the translation is handled upstream within projects like
the Free Translation Project (http://www.iro.umontreal.ca/contrib/po/HTML/),
the Gnome translation Project (http://developer.gnome.org/projects/gtp/) or
the KDE one (http://i18n.kde.org/). The only centralized resource within
Debian is the Central Debian translation statistics
(http://www.debian.org/intl/l10n/), where you can find some statistics about
the translation files found in the actual package, but no real infrastucture
to ease the translation process. 

An effort to translate the package descriptions started long ago even very
few support is offered by the tools to actually use them (ie, only APT can
use them, when configured correctly). There is nothing to do for the
maintainers, and the translators should use the DDTP
(http://ddtp.debian.org/).

For debconf templates, maintainer should use the po-debconf package to ease the
work of your translators, which should use the DDTP to do their work. Some
statistics can be found both on the DDTP site (about what is actually
translated), and on the Central Debian translation statistics site
(http://www.debian.org/intl/l10n/ -- about what is integrated in the
packages). 

For webpages, each l10n team have access to the relevant CVS, and the
statistics are available from the Central Debian translation statistics site.

For general documentation about debian, the process is more or less the same
than for the webpages (the translators have an access to the CVS), but there
is no statistics pages.

For package specific documentation (man pages, info document, other
formats), almost everything have yet to be done. Most notably, the KDE
project handles translation of its documentation in the same way than its
program messages. Debian specific man pages begin to be handled within a
specific CVS repository (http://cvs.debian.org/manpages/?cvsroot=debian-doc). 

I18N & L10N FAQ for maintainers
===

This is a list of problems that maintainers may face concerning i18n and
l10n. While reading this, keep in mind that there is no real consensus on
those points within Debian, and that they are on

Re: Translating Debian packages' descriptions

[Martin Quinson]

On Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer wrote:
> Hi Raphael,
> 
> On Fri, Aug 31, 2001 at 01:59:32PM +0200, Raphael Hertzog wrote:
 [snip]
> > using my "fr" environnment I could'n reconfigure debconf to use the
> > Gnome frontend, it wasn't listed in the proposed choices because the
> > french translation was outdated and didn't include the new Gnome
> > frontend. The contrary can happen, a choice has been removed but my
> > french translation does still propose it :( I should have submitted
> > a bug about this so that we can find a solution for debconf ...
> 
> Hm, IMHO the package maintainer should be intelligent enough to notice
> that he has made an incompatible change to the templates, and as a
> result delete/comment out all the translations. Or did you use
> translations from a different source than the package itself?

Ouch ! As translator, I can promise you that if Joey Hess had removed all my
translation just because he added 'gnome' to the list of choices, he would
had to search out another french translator !

The debconf i18n stuff is suposed to discard outdated translations, but it
failed in this case. Call this a bug. 

So, you can fix that bug, and reinvent the wheel, or use the gettext
mecanism to handle outdated translations.

But we where at package descriptions, not debconf templates. (one problem
after the other ;)


Bye, Mt.

PS: this perticular problem is fixed, since I updated the french
translation. But the problem still exists for these languages: de, fi, gl,
it, ja, ko, nl, pl, pt_br, ru, sv, zh_cn and zh_tw. 
To whom should I send my translation bug reports ? ;)

Re: Translating Debian packages' descriptions

[Martin Quinson]

On Sat, Sep 01, 2001 at 10:11:45AM +0200, Radovan Garabik wrote:
> Just a small nitpicks...
> 
> On Sat, Sep 01, 2001 at 02:17:01AM +0200, Richard Atterer wrote:
> > Hi Raphael,
> > 
> > On Fri, Aug 31, 2001 at 01:59:32PM +0200, Raphael Hertzog wrote:
> 
> > 
> > With language-specific Packages files, there is no size issue.
> > 
> > About the only disadvantage I can think of is that the fallback
> > language would have to be English, and not configurable - but surely
> > that's acceptable. There is no encoding issue either, since AFAIK for
> 
> well, it surely is less then optimal. Most Slovaks would want
> fallback to Czech version, and I imagine vice versa is also true.
> (and Ukrainians and Belorussians may want fallback to Russian - 
> and now you have an encoding issue as well)
> 
> 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 may also be that I misunderstood your mail, and that this feature exists
somewhere. If it's the case, please be patient with me, and give me some
pointers. 

Thanks, Mt.

Re: new proposal: Translating Debian packages' descriptions

[Martin Quinson]

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

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

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

Good luck, Mt.

-- 
Un clavier azerty en vaut deux.

pkg desc translation: Let's talk about implementation (was: something else)

[Martin Quinson]

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.

You're a bit short on this point. Why ?

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

Letting gettext handle the translation syncronization, and letting dpkg
handle technical syncronization does not seem that bad to me. This can lead
to desyncronisation of the translation sometimes, but mainly in 'unstable',
where it's not critical. Please also note that nobody said there is any
simple solution.

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

That's not sane either because you will need to reimplement a lot of gettext
in dpkg, with no other benefit than having dpkg reinventing the wheel. (I
mainly think about tracking translation accurary and several language
fallback)

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

Oh, I like this form. But what will it do ? I would say that when called
with --merge-lang option, dpkg call msgcat in background to merge the new
translation with the old one, and generate the resulting mo file. What's
your wish for this option ?

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

Well, the patch I proposed contain a w_i18n_charfield function, which is
used only for the description in the table in lib/parse.c You're free to use
it for other fields also, but I did not find any.

This lead me to think that we are speaking since almost one month about a
patch nobody reviewed seriously. That's my fault, I submitted it without any
explanation.  Let me explain how it works:

First point, it does not change any status information because I think
gettext is better than any patch I can ever submit, and gettext have its own
"status file" (the mo files).

Second point, the patch is against the cvs version, and won't apply to the
released version.

Third, this patch do not solve the publishing issue. Ie, the mo file have to
be installed for it to work. I don't care if it's using a po file in each
package, concatening them and compiling them on fly, or if you have a
package installing all translation, or if you ask to Martians to send you
this file, that's another point (which also need to be solved, but not with
this patch). 



Then, four outputs are modified:
 1) dpkg --list
 2) the short description of the package in the list of dselect
 3) the long description, at the bottom of the dselect windows, when on a
package
 4) dpkg --status and --print-avail



For 1-3, the data flow in dpkg and dsellect is classically:
  a) information on disk
  b) information in memory
  c) filtering, sellecting information
  d) preprocessing (wrapping, or isolating short desc)
  e) output to screen

My patch only insert a call to dgettext between (c) and (d). It is a call to
Dgettext and not the regular gettext because the text to translate does not
take place in the dpkg textual domain. So, we've made a new textual domain
called dpkg-desc, and use the function dgettext to allow searching in this
new domain.


I did not put the call between (a) and (b) because these informations get
written on disk sometime. This would be bad to write some translated
information in place of the english one because the different admins of the
machine may speak different languages.

I did not put the call between (b) and (c) to reduce the number of call to
gettext. Even if all gettext translations are cached, the time taken is not
null. And also, this would need to change the filtering process.

I did not put the call between (d) and (e) because gettext want the original
in the exaclty same way than it's in the mo file (so, no wrapping)

See the attached patch for more details on exactly were I've put the
dgettext call.



For the fourth one (dpkg -l and -p), that's a bit more tricky, because dpkg
use the same buffer mecanism when writting db to disk and when outputing
results for end-user. There is a ta

Re: new proposal: Translating Debian packages' descriptions

[Martin Quinson]

On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote:
> On Tue, 4 Sep 2001, Michael Bramer wrote:
> 
> > 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?
> 
> 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.
>

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

The problem is that you wont have to do a little wheel engineering, but a
lot of. Think, you will have to design:
 - the extracting tool control -> po file
   ok, that's true for all solutions ;) I'm working on a patch against
   gettext so that it can handle text following rfc822.
 
 - a mechanism to help the translator finding which text have to be
   translated in the po file.

   With your solution, the translator will face something like
   
   msgid "dpkg-1.9" 
   msgstr ""

   and how will them find what text they have to translate ? most of the
   translators I know are running the stable version of debian because they
   are not as geek as maintainers.

 - a mechanism to produce the mo file, or what ever. If you stick to the po
   format, you can reuse msgfmt, through.
   
 - 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.
   
 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)
   
For what gain ? 

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

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

Bye, Mt.

-- 
Un clavier azerty en vaut deux.

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

[Martin Quinson]

On Fri, Sep 07, 2001 at 03:36:32AM +0200, Wichert Akkerman wrote:
> Previously Michael Bramer wrote:
> > I am right and the translated description don't need be store in the
> > status file?
> 
> Yes and no. That is just a side-effect of a possible larger change.

Could you please explain what you're thinking about ? I am interessed in
allowing end user having translation. I don't really care about the way it
is done[*]. But with such a cryptic mail, it's hard to figure what can be
done for my perticular problem in your much larger framework...

I am willing to (try to) help, but it's hard without a decent information.
I'm subscribed on -dpkg since months, and I did not see any related mail
either.

What do I have to do to be informed about dpkg development ?


Bye, Mt.

[*]: ie, I think gettext does what we need, but if you explain what's wrong
about that, I'm pretty flexible.

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

[Martin Quinson]

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?

What if several admins does not speak the same languages ?

Mt

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

[Martin Quinson]

On Tue, Sep 11, 2001 at 03:47:36PM +0200, Wichert Akkerman wrote:
> Previously Martin Quinson wrote:
> > Could you please explain what you're thinking about ? I am interessed in
> > allowing end user having translation. I don't really care about the way it
> > is done[*]. But with such a cryptic mail, it's hard to figure what can be
> > done for my perticular problem in your much larger framework...
> 
> I'm not thinking of anything in particular at the moment, mostly just
> following the discussion and noting possible issues.
> 
> At this moment translations are simply not on the top of the todo-list
> for dpkg, and we already know that we will need some infrastructure to
> support them properly that does not exist at the moment.

Agreed.

> > What do I have to do to be informed about dpkg development ?
> 
> Follow CVS.

I also did, but I just subscribed to dpkg-cvs to ease this task. 

> > [*]: ie, I think gettext does what we need, but if you explain what's wrong
> > about that, I'm pretty flexible.
> 
> You've already been told a few times that gettext only does a small (and
> simple) part of what is involved.

Ok, I'll try to summarize the problem to face. Please correct me if I'm
wrong.

1) Do the translation
2) Put the translation in the Debian archive
3) Publish the translation, ie make sure it comes to the user hard disk when
   the package gets available, even before it gets installed
4) Use the translation when environment variable is properly set, and when
   the user ask dpkg & Cie about a package.
   
My patch gives a solution to 4, given that you use the gettext solution for
3, and maybe for 1-3. The ddts give a solution for 1.

[In the rest, when I say 'You', I don't mean 'You, Wichert', but 'You, dpkg
devellopers', or something even larger]

I think your opinion about 1 is that it's a translator issue, and I agree.
But the "Prefect Solution"(TM) have to take their point of view in account,
haven't it ?

You want to handle 2 by putting the translation in the package. That's ok,
but with which form ? There is at least two solutions: in a po file located
somewhere in debian/ dir, or directly in the control file. You prefere the
second solution, am I right ?

3 is pretty hard to handle when you put the translation in a po file, and
simpler when it's in the control file (but this approach leads to others
problems, mainly from the translator point of view).

As far as I understand, you want to take the descriptions aways from the
/var/lib/dpkg/status file, and make several files, one per language. this
would make the status DB lighter, and ease the handle of several languages.



Sorry to annoy you all about translating package descriptions, but that's an
important point for me. I'm willing to help, and the only answers I get are
"you're deadly wrong". So I'm trying to understand how to do it right...


Thanks, Mt.

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

[Martin Quinson]

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

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

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

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

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

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

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

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

Bye, Mt.

-- 
Un clavier azerty en vaut deux.

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

[Martin Quinson]

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

Thanks, Mt.

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

-- 
Un clavier azerty en vaut deux.

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

[Martin Quinson]

On Thu, Sep 13, 2001 at 02:35:46PM +0200, Wichert Akkerman wrote:
> Previously Martin Quinson 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. 

If I buy Word, there is only one language in it. Mine. Is it the way to go ?

I agree with the fact we should select the 'most important language'. I just
wanted to point out that this approach does not scale *at all*.

> > Would we declare one new field in /lib/parse.c:fieldinfo for each one,
> > choose the most used one, have a new kind of 'variable field', designating
> > the Description, allowing a parameter designing the language used ?
> 
> Please let go of the idea that dpkg should keep a list of all descriptions
> in memory, that is simply not reasonable. In fact forget about dpkg internals
> completely, they are completely irrelevant to this discussion.

Should I understand 'keep away from dpkg' ?

Of course dpkg does not have to keep all language in memory. But to update
the status files, it has to parse it and write it, don't it ?

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

It depends on if you plan to acctually implement it one day...

Bye, Mt.

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

[Martin Quinson]

On Thu, Sep 13, 2001 at 04:25:43PM +0200, Wichert Akkerman wrote:
> Previously Michael Bramer wrote:
> > wordperfect is no free software and they can only support some
> > languages. Get KDE, we have 38 kde-i18n-* packages. This is the
> > _minimum_.
> 
> This is not just about Debian. It is about the dpkg packaging system,
> which can be (and is) used outside Debian just as well.

Fine, but that's an argument to say dpkg support of description translation
must scale in number of languages, too.

> > You say 'few important'. But what languages is important? Somebody
> > say: throw away English and get Russian. Others like (or better
> > _need_) Polish, german, Japanese, China, ...
> 
> That's decided by whoever makes a package. I don't expect everyone
> to feel the same way about translations as Debian does.

Nobody using dpkg can choose what kind of description translation they want
as long as there is no support in dpkg.

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

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

>From there, we have two solutions. First, we say we have no Perfect Idea,
forget about it, and wait for others to try in a few years, or we search
further.

I'm ok with your solution, but we have to search a scalable way to put
translations in the control file, and then in the status files after
parsing. So, yes, the format matter to thing about a scalable implementation. 

Mt.

Re: Web interface for Debian Description Translation Server

[Martin Quinson]

On Fri, Sep 14, 2001 at 11:00:22AM +0200, Wouter Verhelst wrote:
> On Fri, 14 Sep 2001, Michael Bramer wrote:
> 
> > 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
> 
> Not completely true.
> 
> The Netherlands is a country, where people speak Dutch; in Dutch,
> "Dutch" is translated as "Nederlands", hence the "nl".

True

> I have no idea what "da" means.

danish, according to iso639...

Re: Looking for Martin Quinson (Fwd: Mail delivery failed: returning message to sender (Tue, Sep 25, 2001 at 01:13:12AM +0200))

[Martin Quinson]

I'm still alive ! ;)

The mail server of my school had some hard problems yesterday. I reply
privately now..

Mt

On Tue, Sep 25, 2001 at 01:35:07AM +0200, Eric Van Buggenhaut wrote:
> - Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> -
> 
> Envelope-to: [EMAIL PROTECTED]
> X-Failed-Recipients: [EMAIL PROTECTED]
> From: Mail Delivery System <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Mail delivery failed: returning message to sender
> 
> This message was created automatically by mail delivery software (Exim).
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
> 
>   [EMAIL PROTECTED]
> retry time not reached for any host after a long failure period

Re: Looking for Martin Quinson (Fwd: Mail delivery failed: returning message to sender (Tue, Sep 25, 2001 at 01:13:12AM +0200))

[Martin Quinson]

On Tue, Sep 25, 2001 at 11:33:56AM +0200, Eric Van Buggenhaut wrote:
> On Tue, Sep 25, 2001 at 09:33:43AM +0200, Martin Quinson wrote:
> > I'm still alive ! ;)
> > 
> > The mail server of my school had some hard problems yesterday. I reply
> > privately now..
> 
> This doesn't help me. Provide an alternate email address please.

May be a problem with ECN. The firewall of my scholl is broken. Remove ECN
from your kernel, or write to [EMAIL PROTECTED] ...

Sorry, Mt.

-- 
Un clavier azerty en vaut deux.

Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses

[Martin Quinson]

On Sat, Apr 06, 2002 at 05:57:43PM -0500, Dale Scheetz wrote:
> There are an ever growing number of packages that make use of the GNU Free
> Documentation License. Isn't it about time to put a copy of this license
> into the common reference area?
> 
> Who should I talk to about this?

Please check #139437...

Thanks, Mt.

-- 
Si les grands esprits se rencontrent, les petits esprits, eux, se cognent.


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

Bug#698233: ITP: pajeng -- visualization tool for the analysis of parallel applications

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: pajeng
  Version : 1.0
  Upstream Author : Lucas Schnorr 
* URL : https://github.com/schnorr/pajeng
* License : GPL v3
  Programming Lang: C++
  Description : visualization tool for the analysis of parallel
applications

PajeNG (Paje Next Generation) is a re-implementation (in C++) and
direct heir of the well-known Paje visualization tool for the analysis
of execution traces (in the Paje File Format) through trace
visualization (space/time view).  PajeNG comprises the libpaje
library, the space-time visualization tool in pajeng and a set of
auxiliary tools to manage Paje trace files (such as pj_dump and
pj_validate).


Note that this thus a reimplementation of paje.app,  that is already packaged
for debian


-- 
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/20130115183758.11850.79121.report...@alphonse.loria.fr

Bug#698238: ITP: viva -- Trace Visualization Tool

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: viva
  Version : 1.0
  Upstream Author : Lucas Schnorr 
* URL : https://github.com/schnorr/pajeng
* License : GPL v3
  Programming Lang: C++
  Description : Trace Visualization Tool
   Viva is a tool used to analyze traces recorded during the execution of
   parallel or distributed applications. These traces should be formatted
   according to the Paje file format. Viva also serves as a sandbox to
   the development of new visualization techniques.
   .
   Current features include:
 * Temporal integration using dynamic time-intervals
 * Spatial aggregation through hierarchical traces
 * Interactive Graph Visualization with a force-directed algorithm, with
viva
 * Squarified Treemap to compare processes behavior on scale, with
vv_treemap


-- 
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/20130115200219.12245.44818.report...@alphonse.loria.fr

Bug#706469: ITP: minetest-modpack-mobf -- Minetest ModPack providing a framework for creating mobs

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: minetest-modpack-mobf
  Version : 2.1.0
  Upstream Author : sapier 
* URL : https://github.com/sapier/animals_modpack
* License : CC-BY-SA
  Programming Lang: lua
  Description : Minetest ModPack providing a framework for creating mobs
  Minetest modification pack constituting a complete framework to add mobs
  to the game.
  .
  Several predefined mobs are also provided, some of them being hostile
  (Vombies, Dungeon masters, Big Red, Boom bomb, Slime, Oerkki, Wolf)
  while others are friendly (Chicken, Sheep, Cow, Deer, Rat, Blue White
  Fish, Gull, Clownfish, Ostrich). You can sheer sheeps, milk cows,
  collect chicken eggs, tame wolves and ride oerkkis.
  .
  Finally, you can trade goods with the trader and even hire archers and
  guards to fight for you.


-- 
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/20130430143647.gd23...@alphonse.loria.fr

Bug#622324: ITP: jlm -- Learning Management System for the Java programming language

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 


* Package name: jlm
  Version : 1.110411
  Upstream Author : martin.quin...@loria.fr
* URL : http://www.loria.fr/~quinson/Teaching/JLM/
* License : GPL
  Programming Lang: Java
  Description : Learning Management System for the Java programming language

The Java Learning Machine (JLM) is a free platform to teach
programming in general, and Java in particular. This is a Java program
allowing to discover the concepts of programming through interactive
exercises. The following lessons are included in this package:

 - Welcome: teach basics of Java to absolute beginners
 - Array: basic array traversal and research for beginners
 - Bat: basic boolean expression for beginners
 - Sort: classical sorting algorithms for intermediate
 - Recursion: classical logo algorithms for intermediate
 - Maze: classical maze escaping algorithms for intermediate
 - LightBot: little programming game for intermediate and advanced



-- 
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/20110412065815.4679.84793.report...@arthur.loria.fr

Bug#622326: ITP: libirclib-java -- Java implementation of the IRC protocol

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: libirclib-java
  Version : 1.10
  Upstream Author : Christoph Schwering (schwer...@gmail.com)
* URL : http://moepii.sourceforge.net/
* License : GPL / Apache 2.0 / Eclipse Public License v1.0
  Programming Lang: Java
  Description : Java implementation of the IRC protocol

IRClib is a free Java implementation of the IRC protocol.  This thin
library is RFC1459 and RFC2812 compliant.

I package this as a dependency to jlm (#622324)



-- 
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/20110412072559.5111.66329.report...@arthur.loria.fr

Bug#622619: ITP: libjsyntaxpane-java -- Java EditorPane with support for Syntax Highlighting

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: libjsyntaxpane-java
  Version : 0.9.5~svn148
  Upstream Author : Ayman Al-Sairafi (ayman.alsair...@gmail.com)
* URL : http://code.google.com/p/jsyntaxpane/
* License : Apache-2.0
  Programming Lang: Java
  Description : Java EditorPane with support for Syntax Highlighting

JSyntaxPane provides you with a very simple to use, and now with
simple method to configure, way to handle simple Syntax Highlighting
and editing of various languages within your Java Swing application.

Currently supported out of the box are Java, JavaScript, Properties,
Groovy, C, C++, XML, SQL, Ruby and Python. 


**
Upstream does not distribute any source package, so I had to get it
from the svn directly. The prefered version is 0.9.5, but it is not
released yet, with some beta versions distributed (in binary version)
since one year and half. There is no tag in this branch pointing to
where the binary version were taken. This explain the strange version
number I've picked. I hope it's ok.

I'm packaging it as a dependency to JLM (see #622324).

The current version of the package is at
git://git.debian.org/pkg-java/libjsyntaxpane-java.git
(empty right now, soon populated)



-- 
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/20110413124554.20231.73409.report...@arthur.loria.fr

Bug#640873: ITP: libsmack-java -- Easy to use Java XMPP client library

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* Package name: libsmack-java
  Version : 3.2.1
  Upstream Author : Jive Software (http://www.igniterealtime.org/)
* URL : http://www.igniterealtime.org/projects/smack/index.jsp
* License : Apache-2.0
  Programming Lang: Java
  Description : Easy to use Java XMPP client library.

Smack is a XMPP (Jabber) client library for instant messaging and
presence. A pure Java library, it can be embedded into your
applications to create anything from a full XMPP client to simple XMPP
integrations such as sending notification messages and
presence-enabling devices.

Please note that I'm intending to package this as a (new) dependency
to JLM, so this is a blocker to #622324.

-- 
Alvin: Sinon, le polymorphisme en C, c'est trop bô. :)
Emptty: Ca, c'est clair. Le C, j'aime ca. C'est un peu de l'art primitif,
   mais ca te secoue les tripes...



-- 
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/20110908061346.ga...@arthur.loria.fr

Help needed with a dh_shlibs failure on non amd64 platforms

[Martin Quinson]

Hello all,

I come to you because I'm puzzled with a bug I have in one of my package, and
I'm seeking for help. Please CC me when answering as I'm not on this list.

The package is ns3, a scientific simulator of computer networks. This package is
huge, I seem to be the only active maintainer, but upstream is very
collaborative.

Upstream just moved from a build system called waf to cmake, which is an nice
move. They introduced a small python script saving the waf interface to their
users that don't like changes, and unfortunately the raw cmake interface is not
usable yet (cmake checks on files created by the script), so I cannot use the
plain classical cmake build in debian/rules. I did my best to mimick the
behavior of `dh --buildsystem=cmake` but I have a strange failure on non-amd64
platforms:
https://buildd.debian.org/status/package.php?p=ns3

The build, tests and install targets go well, until dh_shlibdeps. At that step,
I get a huge bunch of errors like the following:
```
   dh_shlibdeps -a
dpkg-shlibdeps -Tdebian/libns3.36.substvars 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wifi.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wave.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-visualizer.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-virtual-net-device.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-uan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-traffic-control.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-topology-read.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-tap-bridge.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-stats.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-spectrum.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-sixlowpan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-propagation.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point-layout.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-olsr.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-nix-vector-routing.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-network.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-netanim.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mobility.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mesh.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lte.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lr-wpan.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet-apps.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-flow-monitor.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-fd-net-device.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-energy.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsr.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsdv.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma-layout.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-core.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-config-store.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-buildings.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-bridge.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-applications.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-aodv.so.36.1 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-antenna.so.36.1
dpkg-shlibdeps: error: cannot find library libns3-bridge.so.36.1 needed by 
debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 
'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libns3-traffic-control.so.36.1 
needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 
(ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
```
This specific one is for arm64, but I get exactly the same problem for all
platforms but amd64.
https://buildd.debian.org/status/fetch.php?pkg=ns3&arch=arm64&ver=3.36.1%2Bdfsg-2&stamp=1656893780&raw=0

All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the
package. They are added to the debian/libns3.36/DEBIAN/shlibs a few lines above
in the build log, and dh_strip found them further above in the log. What really
puzzles me is that the package builds fine on amd64 and i386. 

The package is uptodate on salsa, in case someone wants to test something
directly on the package. Fear not to do so, this package only takes one hour to
build on my machine :)

If you wonder, the cmake macro to define and build a library is in 
  ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake
I already had to patch it to support Debian

Changing the epoch of widelands package

[Martin Quinson]

Hello,

as per policy 5.6.12, I'm seeking for a consensus for upgrading the epoch of the
widelands package. The version currently in Debian is 1:21-2, corresponding to
the upstream build21. 

Last year, upstream released their v1.0 after maybe two decades of developemnt,
but our watch file didn't detect it because 1.0 < 21.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005370
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992626

I thus think that we should package the new version as 2:1.0-1.

Do you people agree?

Thanks, 
Mt.



signature.asc
Description: This is a digitally signed message part