The review should be trivial as the spec file is largely inspired from existing
fedora font packages

Is it acceptable to have accented letters in package names?

I don't know if we have an official policy on this, but the infrastructure
should be able to handle this nowadays (after some embarrassing failures when
bodhi was first deployed)

Since the contents are tied to a locale, I'd hate to mangle the naming

The infrastructure maybe (and it would even be a good test...)
but what about people scripts and stuff that use the package names?
The locale may be use another encoding than utf8, this may call
for troubles in that case.

skvidal & abadger1999 seem to think the technical problems linked to the naming
(if any) should be fixed and not ignored. So naming is not a blocker

I'm not too worried about the non-utf8 locale case:
1. utf-8 is the default fedora encoding, so that's what we should optimize for
2. almost every fedora locale migrated to utf-8 long long ago
3. I thoroughly doubt any user of a non-utf8 locale (be it because this locale
is some complex obscure asian stuff or be it because the user is an US sysadmin
which has not understood i18n needs yet) will be interested in this particular
package

(In reply to comment #6)
> I'm not too worried about the non-utf8 locale case:
> 1. utf-8 is the default fedora encoding, so that's what we should optimize for

I am not sure that it is relevant here. The issue is would it
be right to have encoded characters in a package name.

> 2. almost every fedora locale migrated to utf-8 long long ago

No, the otherwise encoded locales are still there, like fr_FR.

> 3. I thoroughly doubt any user of a non-utf8 locale (be it because this locale
> is some complex obscure asian stuff or be it because the user is an US sysadmin
> which has not understood i18n needs yet) will be interested in this particular
> package

Even if the user isn't interested in this particular package, the package
name may still appears somewhere (in repoquery calls, for example). Or
as a dependency.


I don't feel strongly about that issue, but I have seen so 
many trouble with encodings that I think it is better to be
cautious.

I know some people still using 8 bit locales. That is a situation
we shouldn't prevent, and we should leave this choice to the user
(even though we are more targetting utf8).

My vote would go for "ecolier-fonts" FWIW.

I also note that the .ttf files are just named "ec*.ttf"
and it is hard for many people in the world to type "é"
without changing xkb layout, installing a input method, or having
to cut and paste the letter (like I just did).

These files should be prefixed with the package name:
Source2:   OFL.txt
Source3:   OFL-fr.txt


Imho you should add a
Provides: ecolier-fonts = %{version}-%{releae}
to make it easier to install the fonts.


The %changelog entry uses strange characters instead of "-".


The License Page uses http://scripts.sil.org/OFL_web as a reference to the OFL
License.
(http://fedoraproject.org/wiki/Licensing#head-19fc3ef10add085a28cb06784dc34ef8b05a9bd6-4)

(In reply to comment #10)

> These files should be prefixed with the package name:
> Source2:   OFL.txt

This is SIL's filename, won't touch it we do not rename downloadable sources
> Source3:   OFL-fr.txt
OK

> Imho you should add a
> Provides: ecolier-fonts = %{version}-%{releae}
> to make it easier to install the fonts.

This is a nice idea - done

> The %changelog entry uses strange characters instead of "-".

Changelog is freeform, changelog parsers need to grok utf-8 to get author names
right, and other fedora packages do it too so I don't see the problem. It made
the infra team laugh the first time

> The License Page uses http://scripts.sil.org/OFL_web as a reference to the OFL
> License.

And on this page you have a link to the FAQ that includes the download link to
the standalone text version. (with an unfortunate URL - SIL's site sucks a bit)

(In reply to comment #9)
> I also note that the .ttf files are just named "ec*.ttf"
> and it is hard for many people in the world to type "é"
> without changing xkb layout, installing a input method, or having
> to cut and paste the letter (like I just did).

I've added a provides for accented-less name
If you browse the website you'll see the actual project name takes an accent
The font filenames are infortunate and could use a refresh

I think using the 'é' in the actual package name is just asking for trouble, and
that it would be better to use plain 'e' there and 'é' in the Provides if you
insist.

(In reply to comment #13)
> I think using the 'é' in the actual package name is just asking for trouble,

1. It is somewhat asking for trouble but our infrastructure needs to get utf-8
proof and I'd rather it was done with a small package like this than in an
urgent way when a bigger package lands. There is really an astonishing few
problems revealed by this package, and it's a pity to stop just >< this close to
full support

2. your know how we French are, we care about our language

Anyway here's the updated srpm
http://nim.fedorapeople.org/%c3%a9colier-court-fonts-1.00-0.2.20070628.fc8.src.rpm

(In reply to comment #11)

> > The %changelog entry uses strange characters instead of "-".
> 
> Changelog is freeform, changelog parsers need to grok utf-8 to get author names
> right, and other fedora packages do it too so I don't see the problem. It made
> the infra team laugh the first time

The Guidelines demand the "-":
http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199c6a33128acce5fb453213

| You must use one of the following formats:

I do not know enough about rpm to decide, whether your format will cause trouble
or not.

(In reply to comment #15)

> The Guidelines demand the "-":

I'm not so sure if they demand the - or ask to normalize the first line of each
changelog entry (and normalize is a big word as there are 3 different possible
formats anyway)

Didn't see this entry before, I'll change the format if you really insist (and
re-change it later)

> | You must use one of the following formats:
> 
> I do not know enough about rpm to decide, whether your format will cause
> trouble or not.

It won't because there are already other packages that use this format, and went
through mock plague kiji bodhi without anyone objecting

(In reply to comment #14)
> (In reply to comment #13)
> > I think using the 'é' in the actual package name is just asking for trouble,
> 
> 1. It is somewhat asking for trouble but our infrastructure needs to get utf-8
> proof and I'd rather it was done with a small package like this than in an
> urgent way when a bigger package lands. There is really an astonishing few
> problems revealed by this package, and it's a pity to stop just >< this close to
> full support

Testing the infrastructure should not be tied to a review request.
Your srpm is good enough to test the infrastructure with it, but
without adding the package to fedora. A real package add to fedora 
should never ever be used to test the infrastructure.
 
> 2. your know how we French are, we care about our language

I am french, and I care more about compatibility... But maybe
I have been contaminated with the english language virus. 
And also it is to note that some french people care even more
about their iso latin1 encoding ;) and set their locales 
appropriately (yes, yes I know more than one). 

Tiny little nit-pick (I was curious about this package and took a look):
s/traditionnal/traditional/ in the Description. :)

(In reply to comment #17)
> (In reply to comment #14)

> A real package add to fedora 
> should never ever be used to test the infrastructure.

That's the only thing that ever tests the infrastructure, because the rest does
not exist. And that's a practical assesment.
 
> > 2. your know how we French are, we care about our language
> 
> I am french, and I care more about compatibility...

Get real the worst your users will see is one miscoded glyph in their package
manager UI. And they already get a ton of those by choosing not to use the
distro default encoding, because all our French material is UTF-8 encoded.

Bottom point: they can continue as they used to, and they'll even be able to get
the new font, provided they suffer a little UI unpleasantness, which won't kill them

> But maybe
> I have been contaminated with the english language virus. 

Nope you've been contaminated by the "I want to keep on life-support features
that died clinicaly years ago". Which is fine as long as you don't freeze the
rest of the distro to make your life easier. I suppose you also object to X not
dying anymore when legacy core fonts are misconfigured.

(In reply to comment #18)
> Tiny little nit-pick (I was curious about this package and took a look):
> s/traditionnal/traditional/ in the Description. :)

Nice catch I'll fix it

(In reply to comment #17)

> And also it is to note that some french people care even more
> about their iso latin1 encoding ;)

BTW just to show how ridiculous your position is: all the letters the French
language uses are not included in latin-1, nor is the symbol for the money your
users have their bank account labeled in

Bugzilla can't handle the name, at least it doesn't display it correctly
for me, but as "Ã © c o l i e r" (adding spaces for emphasis).

OK, I realize we have leak in the FPG, people seem to be keen to exploit.

IMHO, this package name should be rejected, because
a) It technically means asking for trouble wrt. tools processing rpms/rpm-spec
(rpmbuild, rpm, yum, apt, yumex, createrepo, db-formats etc.). 
I am sure at least some of them are not able to process such names.

b) It is user unfriendly: You can't expect people to be able to type "arbitrary
exotic characters" on their keyboard. The crucial point about this is "exotic is
relative": Europeans might be able to type "Ä©", but how would Westerners feel
about Middle/Far East chars being used in package names?

That said, I am inclined to propose restricting package names to using printable
chars from 7bit ASCII to the FPG - I never would have expected this to be
necessary, but ... seems like this is inevitable.

This is just bugzilla UTF-8 handling being broken. It's not a package problem.
Last I looked at it upstream had implemented proper UTF-8 support for new
bugzilla databases, but existing ones need to be painfuly converted (painfully
since previous bugzilla versions allowed any sort of encoding mixes making clean
data recovery hard)

(In reply to comment #22)
> OK, I realize we have leak in the FPG, people seem to be keen to exploit.

???

> IMHO, this package name should be rejected, because
> a) It technically means asking for trouble wrt. tools processing rpms/rpm-spec
> (rpmbuild, rpm, yum, apt, yumex, createrepo, db-formats etc.). 
> I am sure at least some of them are not able to process such names.

What's asking for trouble is continuing to ignore UTF-8 handling problems in
low-level rpm tools. All our software stack has been moving to UTF-8 for years,
and in fact our upper package management layers (comps...) already use XML
(which default encoding is UTF-8) pervasively. As far as I know there is *no*
way to restrict XML to a 7-bit encoding like ASCII, and even if it were it's
probably not supported by one or several of the XML libs we use, since it's not
a common need. And if you start using 8-bit encodings UTF-8 is the only one
everyone agrees on.

> b) It is user unfriendly: You can't expect people to be able to type "arbitrary
> exotic characters" on their keyboard.

This is not a problem. The GUI tools do not care, and the package provides an
ascii-7 name alias for CLI users.

(In reply to comment #24)
> (In reply to comment #22)
> > OK, I realize we have leak in the FPG, people seem to be keen to exploit.
> 
Yes, I consider this package review/submission as a provocation, trying to
challenge the FGP.

The FPC and rpm missed to specify the precise syntax of rpm.specs.

> > IMHO, this package name should be rejected, because
> > a) It technically means asking for trouble wrt. tools processing rpms/rpm-spec
> > (rpmbuild, rpm, yum, apt, yumex, createrepo, db-formats etc.). 
> > I am sure at least some of them are not able to process such names.
> 
> What's asking for trouble is continuing to ignore UTF-8 handling problems in
> low-level rpm tools.
My view is differently: It is a matter of specification/standardization of the 
"rpm.spec - syntax".

> All our software stack has been moving to UTF-8 for years,
Yes, and? ... this doesn't mean exploing the technical possibilities is
necessary useful. (Think about using non-7bit application names).

> > b) It is user unfriendly: You can't expect people to be able to type "arbitrary
> > exotic characters" on their keyboard.
> 
> This is not a problem.
Well, an acute accent probably is not much of a problem for French folks, but
... would you think the same wrt. non ASCII-chars of other languages?

At least I would be facing the such issues, if packages names (or worse
applicaition) were named in East European, Middle and Far East charsets.

I would not be able find them on my keyboard. I also would be likely not to be
able in GUI tools because I would not have the fonts installed. 

> The GUI tools do not care, and the package provides an
> ascii-7 name alias for CLI users.
These aren't of help, when e.g. ftp'ing a package.

The converse would be applicable: ASCII-file/package-name, utf-8-provides.

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #22)
> > > OK, I realize we have leak in the FPG, people seem to be keen to exploit.
> > 
> Yes, I consider this package review/submission as a provocation, trying to
> challenge the FGP.
> 
> The FPC and rpm missed to specify the precise syntax of rpm.specs.

I'm sorry I have zip interest into going in rant mode. Please move hyperbolics
somewhere else. 

> > > IMHO, this package name should be rejected, because
> > > a) It technically means asking for trouble wrt. tools processing rpms/rpm-spec
> > > (rpmbuild, rpm, yum, apt, yumex, createrepo, db-formats etc.). 
> > > I am sure at least some of them are not able to process such names.
> > 
> > What's asking for trouble is continuing to ignore UTF-8 handling problems in
> > low-level rpm tools.
> My view is differently: It is a matter of specification/standardization of the 
> "rpm.spec - syntax".

As noted in one of the first comments this was politely discussed with Seith
Vidal among others so don't be so quick to condemn me for not following the
hypothetical rule you assume will be written down someday. Plus you know what
they say about retroactivity of the law.

> > All our software stack has been moving to UTF-8 for years,
> Yes, and? ... this doesn't mean exploing the technical possibilities is
> necessary useful. (Think about using non-7bit application names).
> 
> > > b) It is user unfriendly: You can't expect people to be able to type
"arbitrary
> > > exotic characters" on their keyboard.
> > 
> > This is not a problem.
> Well, an acute accent probably is not much of a problem for French folks, but
> ... would you think the same wrt. non ASCII-chars of other languages?

Please don't invent strawmen. It's up to projects to choose names that play well
with their intended audience, and you're not well placed to decide here without
knowing their aims or their users they would be better served by ascii-7 names.
We already have a lot of parts in Fedora which are totally useless to people
that do not read a specific scripts, and this is good (globalization has
limits), so pretending everything needs an ascii-7 transliterated name is
stretching things quite a bit.

> At least I would be facing the such issues, if packages names (or worse
> applicaition) were named in East European, Middle and Far East charsets.
> 
> I would not be able find them on my keyboard. I also would be likely not to be
> able in GUI tools because I would not have the fonts installed. 

And you would likely not have any use for them. Projects with a global reach do
not use names in East European, Middle and Far East scripts.

> > The GUI tools do not care, and the package provides an
> > ascii-7 name alias for CLI users.
> These aren't of help, when e.g. ftp'ing a package.

Manual ftp-ing of packages has not been our primary distribution method for
years, and anyway rpm does not care about the file name so limiting metadata
just for filenames is a red herring.

> The converse would be applicable: ASCII-file/package-name, utf-8-provides.

This falls against the choices pretty much every other app did. You don't expose
low-level ascii-limited strings to users and hide the correct utf-8 variant. And
package name is a very important user-exposed string.

Also you should realise this would win you little, as the problems if there are
likely lurk rpm db side and will be largely the same either way.

(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > (In reply to comment #22)
> > > > OK, I realize we have leak in the FPG, people seem to be keen to exploit.
> > > 
> > Yes, I consider this package review/submission as a provocation, trying to
> > challenge the FGP.
> > 
> > The FPC and rpm missed to specify the precise syntax of rpm.specs.
> 
> I'm sorry I have zip interest into going in rant mode. Please move hyperbolics
> somewhere else. 
What is ranting about this? rpm.spec don't have a syntax specification, the FPG
doesn't cover this case and this package submission challenges both.

>
> And you would likely not have any use for them. Projects with a global reach do
> not use names in East European, Middle and Far East scripts.
OK, so this font package is addressing the French audience only?

You might not be aware how exotic even comparatively far spread things like an
acute accent is to many users?

My last name contains one, I am well aware about the fact how much it is. Now
extend this to other charsets and languages.

> > > The GUI tools do not care, and the package provides an
> > > ascii-7 name alias for CLI users.
> > These aren't of help, when e.g. ftp'ing a package.
> 
> Manual ftp-ing of packages has not been our primary distribution method for
> years,
ftp'ing and using other command tools are still the only applicable method in
many use cases, e.g. in case of broken repositories, broken network access etc.

I'll bring this to the FPC.

Sadly FPC and FESCO decided on a solution that does not work in the stead of the
one proposed and tested (proving once again the power of FUD), but here are
updated packages anyway

http://nim.fedorapeople.org/ecolier-court-fonts.spec
http://nim.fedorapeople.org/ecolier-court-fonts-20070702-1.fc10.src.rpm

* Sat Jul 12 2008 <nicolas.mailhot at laposte.net>
- 20070702-1
⚱ Stop waiting for upstream to answer distribution change requests
♔ FESCO chickened out on UTF-8 names
♿ FESCO decision unimplementable due to bug #455119
⚙ Sync spec style with the way our font packaging guidelines have evolved
⚤ Package both fonts in a single package
  I'm going to consider they are two faces of the same font
∞ Register in new fontconfig generic families

Using weird characters to enumerate changelog entries to annoy the people who
expressed concern about this is just childish.

(In reply to comment #29)
 
> Using weird characters to enumerate changelog entries to annoy the people who
> expressed concern about this is just childish.

Changelog is UTF-8 land and this has never been contested. There are scores (if
not more) of packages in Fedora now (and for several versions) that have UTF-8
there. It passes rpmlint fine (modulo the new nobreakspace warning someone added
without checking it actually worked)

I'm sorry if you can't envision that someone working on extending the
distribution unicode support does not limit himself to ASCII. If I agreed with
you I wouldn't be packaging those in the first place.

(In reply to comment #30)
> (In reply to comment #29)
>  
> > Using weird characters to enumerate changelog entries to annoy the people who
> > expressed concern about this is just childish.

I found that utf8 illustrated changelog very funny.

> Changelog is UTF-8 land and this has never been contested. There are scores (if
> not more) of packages in Fedora now (and for several versions) that have UTF-8
> there. It passes rpmlint fine (modulo the new nobreakspace warning someone added
> without checking it actually worked)

The issue is not with utf8 in the changelog but with different 
characters for each line, though, here, they are admitedly meaningful. 
This may be fun for the reviewers and fedora maintainers, for the user 
I think that it is likely to be scary.

More generally, I like the check character for the changelog item,
but I find the smiling face not very relevant, maybe a watch (231A) would be
better? 

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> >  
> > > Using weird characters to enumerate changelog entries to annoy the people who
> > > expressed concern about this is just childish.
> 
> I found that utf8 illustrated changelog very funny.

Thank you.

> The issue is not with utf8 in the changelog but with different 
> characters for each line, though, here, they are admitedly meaningful.

I try to write meaningful changelogs and the UTF-8 bits are part of it. Like any
maintainer, sometimes I succeed, sometimes not.
 
> This may be fun for the reviewers and fedora maintainers, for the user 
> I think that it is likely to be scary.

Almost any changelog, with UTF-8 or not is going to be scary for users.

> More generally, I like the check character for the changelog item,
> but I find the smiling face not very relevant, maybe a watch (231A) would be
> better? 

I've reverted to - for the version line since sadly that's what rpmlint insists
on and I don't want to upset reviewers that don't understand it does not change
anything.

However if you review this package I can sprinkle watches there if you want :p

Can you indicate the location of the latest spec and srpm?

(In reply to comment #33)
> Can you indicate the location of the latest spec and srpm?

Thank you for looking at this package!
The latest spec is currently in comment #28

OK  | MUST: rpmlint is clean
OK  | MUST: The package must be named according to the Package…
OK  | MUST: The spec file name must match the base package…
OK  | MUST: The package must meet the Packaging Guidelines…
OK  | MUST: The package must be licensed with a Fedora approved…
OK  | MUST: The License field in the package spec file must…
OK  | MUST: Packaged detached license and specified in %doc
OK  | MUST: The spec file for the package MUST be legible.
OK  | MUST: The package must successfully compile and build…
OK  | MUST: successfully compile, build 
OK  | MUST: All build dependencies must be listed…
OK  | MUST: A package must own all directories that it creates
OK  | MUST: A package must not contain any duplicate files 
OK  | MUST: Permissions on files must be set properly. 
OK  | MUST: Each package must have a %clean section
OK  | MUST: Each package must consistently use macros
OK  | MUST: The package must contain code, or permissible 
OK  | MUST: Packages must not own files or directories already
OK  | MUST: At the beginning of %install, each package MUST…
OK  | MUST: All filenames in rpm packages must be valid UTF-8.
OK  | SHOULD: If the source package does not include license 
OK  | SHOULD: The description and summary section … translations…
OK  | SHOULD: The package builds in mock
OK  | SHOULD: The package builds on all supported architectures
OK  | SHOULD: The reviewer should test that the package…
OK  | SHOULD: If scriptlets are used, those scriptlets must be sane…

Please fix the typos: licence and traditionnal before you commit. The UTF-8
details have been hashed out already and I don't have much to add. I don't
understand French and can't read the text file provided but I see the reference
to OFL. Perhaps you should add a README.dist and include a note in English too?
Probably not needed as the fonts are useful only for French folks.

APPROVED

Ok, I'll do this on import.

Thank you for looking at that contentious package

New Package CVS Request
=======================
Package Name: ecolier-court-fonts
Short Description: Écolier court fonts
Owners: nim
Branches: devel only
InitialCC: fonts-sig
Cvsextras Commits: yes

cvs done.

Thanks!