This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 820642 - Review Request: figlet - A program for making large letters out of ordinary text
Review Request: figlet - A program for making large letters out of ordinary text
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paulo Andrade
Fedora Extras Quality Assurance
:
: 454917 489830 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-10 10:58 EDT by Simone Caronni
Modified: 2012-07-05 19:34 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-05 19:02:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
paulo.cesar.pereira.de.andrade: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Simone Caronni 2012-05-10 10:58:11 EDT
Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.4-4.fc17.src.rpm
Description:
FIGlet prints its input using large characters (called "FIGcharacters") made
up of ordinary screen characters (called "sub-characters"). FIGlet output is
generally reminiscent of the sort of "signatures" many people like to put at
the end of e-mail and UseNet messages. It is also reminiscent of the output of
some banner programs, although it is oriented normally, not sideways.
Comment 1 Simone Caronni 2012-05-10 10:59:36 EDT
*** Bug 489830 has been marked as a duplicate of this bug. ***
Comment 2 Jason Tibbitts 2012-05-10 14:39:43 EDT
I guess the licensing issue which caused so much problems has been fixed.

You should not use macro forms of simple executables, like %{__rm}.  See http://fedoraproject.org/wiki/Packaging:Guidelines#Macros:

Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, rm should be used in preference to %{__rm}, but %{__python} is acceptable. 

%defattr(-, root, root, 0755) is unnecessary.

BuildRoot: %clean and the first line of %install are unnecessary unless you intend to build this for EPEL5.
Comment 3 Terje Røsten 2012-05-11 03:01:45 EDT
rpmbuild will compress the man pages for you, you can remove the gzip line.
Comment 4 Simone Caronni 2012-05-11 03:28:36 EDT
Hello,

here are the changes:

1- Removal gzip of man pages
2- Removal of %defattr
3- Removal of configurable system executables

I left the %{buildroot}, %clean and first line of %install intentionally as I want to mantain the package also for EPEL5.

Here are the updated files, I bumped revisions:

Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.4-4.fc17.src.rpm

Thanks,
--Simone
Comment 5 Simone Caronni 2012-05-11 03:28:55 EDT
Hello,

here are the changes:

1- Removal gzip of man pages
2- Removal of %defattr
3- Removal of configurable system executables

I left the %{buildroot}, %clean and first line of %install intentionally as I want to mantain the package also for EPEL5.

Here are the updated files, I bumped revisions:

Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.4-5.fc17.src.rpm

Thanks,
--Simone
Comment 6 Simone Caronni 2012-05-11 03:29:22 EDT
Sorry for double posting, browser error. Second comment is ok.
Comment 7 Terje Røsten 2012-05-11 07:21:28 EDT
All man pages is marked as %doc by rpmbuild, you can drop the %doc macro here.

Listing is recursive by default:

%dir %{_datadir}/%{name}
%{_datadir}/%{name}/*

could just be:

%{_datadir}/%{name}
Comment 8 Simone Caronni 2012-05-11 07:35:28 EDT
Thanks, applied the changes; spec file is at the same place.

Any chance someone might take this for review? It has been opened since 2009...
Comment 9 Paulo Andrade 2012-05-11 11:14:05 EDT
I did talk a bit with Claudio Matsuoka about this package, and the work he
did to contact upstream to get several files relicensed under MIT/BSD like
licenses.

Claudio has a git repository at https://github.com/cmatsuoka/figlet

I did a quick review on fonts headers, and Claudio will add the LEGAL
NOTICE file commented in fonts derived from Bigelow & Holmes ones. But
I am unsure about this in the file being added:

        A royalty-free, nonexclusive trademark
	license to refer to the code and output as "OPEN LOOK" compatible 
	is available from AT&T if, and only if, the appearance of the 
	icons or glyphs is not changed in any manner except as absolutely
	necessary to accommodate the standard resolution of the screen or
	other output device, the code and output is not changed except as 
	authorized herein, and the code and output is validated by AT&T. 
	Bigelow & Holmes is the owner of the Lucida (R) trademark for the
	fonts and bit-mapped images associated with the materials on this 
	tape. Users are granted a royalty-free, nonexclusive license to use
	the trademark only to identify the fonts and bit-mapped images if, 
	and only if, the fonts and bit-mapped images are not modified in any
	way by the user.

The large C64-fonts subdirectory of the contrib fonts may have issues,
as all it says is:

NOTE: I got the font from a Commodore 64 charactor set file. (Wrote a little
program to convert them to Figlet). And since some charactors are different in
PETSCII then in ASCII, certain charactors will be different or even
non-existant. Such as `~{}\| _^

Most other "artistic" fonts come from usenet posts with the font
contents, with some interesting ones, like:

3x5 font by Richard Kirk (rak@crosfield.co.uk).
Ported to figlet, and slightly changed (without permission :-})
by Daniel Cabeza Gras (bardo@dia.fi.upm.es)


Otherwise, most if not all have an explicit clause of free to modify,
relicense, resell. Others are explicitly public domain, or have only
author name.

I suggest not adding the contributed fonts to the main package and having
a plain figlet with only the upstream fonts, and at your interest, making
yet another figlet-fonts package and getting legal review of it.

About figlet.spec I think you should remove the shell script commented
and the %defattr commented. Not agains't comments, but comments should
be for some explanation about the reason of next code, information about
generated files, etc.

As commented previously, you could change:

%dir %{_datadir}/%{name}
%{_bindir}/*
%{_datadir}/%{name}/*

to

%{_datadir}/%{name}
%{_bindir}/*

but either way works; some like to add a slash to the end to make it
easier to notice it is a directory listing.
Comment 10 Claudio Matsuoka 2012-05-11 14:06:04 EDT
I agree with pcpa. The main figlet package and bundled fonts is clear license-wise, but contributed fonts should be screened for potential violations.

After this screening I can move confirmed non-free contributed fonts to a separate repository upstream and contact individual authors to resolve licensing issues.
Comment 11 Simone Caronni 2012-05-14 04:04:28 EDT
Hello,

thanks for all the input. I've made all the modifications requested.
New files without contributed fonts and review fixes at:

Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.4-6.fc17.src.rpm

Regards,
--Simone
Comment 12 Simone Caronni 2012-05-14 04:05:12 EDT
I also added a small comment at the top of the spec file with the source code repository, I could not find the info on figlet's website.

--Simone
Comment 13 Claudio Matsuoka 2012-05-14 06:56:13 EDT
Hi,

John Cowan from the FIGlet development team informed us that:

"Bitmap fonts are in the public domain in the U.S., because they are
considered insufficiently creative to copyright.  Specifically, the actual
*appearance* of a font cannot be copyrighted, and bitmaps are considered
just a trivial transformation of the appearance.  Scalable fonts are
computer programs, though, and are copyrightable."
Comment 14 Paulo Andrade 2012-05-16 22:38:42 EDT
I am taking the package for review.
Comment 15 Paulo Andrade 2012-05-16 23:30:46 EDT
Not explicitly stated in the review procedures, but there is a make check
target not used in %check, and, actually make check fails. The solution
is just to not install the ms-dos fonts.

The ms-dos font also has an interesting header:
Rebel by Valerie Mates (popcorn@cyberspace.org), based on a font by Ron Bliss
(who sometimes goes by the name "rebel" because his initials are REB).
NOTE: THIS FONT ONLY WORKS IN MS-DOS.
May 27, 1994

Like the other fonts, I also suggest it in a possible figlet-fonts package,
but, as stated in the font header, I checked and it does not print anything
in xterm, konsole and linux console termimal.
Try
$ echo abc | figlet -f dosrebel > abc.txt
and see an empty file, well, newlines and padding spaces for where
text should have been added.
Comment 16 Paulo Andrade 2012-05-16 23:31:17 EDT
ok  MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.
$ rpmlint SRPMS/figlet-2.2.4-6.fc18.src.rpm RPMS/x86_64/figlet-2.2.4-6.fc18.x86_64.rpm 
figlet.x86_64: W: unstripped-binary-or-object /usr/bin/chkfont
figlet.x86_64: W: unstripped-binary-or-object /usr/bin/figlet
2 packages and 0 specfiles checked; 0 errors, 2 warnings.

ok  MUST: The package must be named according to the Package Naming Guidelines .
ok  MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.

++  MUST: The package must meet the Packaging Guidelines.
Not explicitly stated in guidelines, but should use
make %{?_smp_mflags}		or	make
instead of
%{__make}
Should not rm -rf %{buildroot}
Should not need to specify Buildroot tag.
But either of the above are cosmetic, and not mandatory.

ok  MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
ok  MUST: The License field in the package spec file must match the actual license.
ok  MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[4]
ok  MUST: The spec file must be written in American English.
ok  MUST: The spec file for the package MUST be legible.

ok  MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.
$ md5sum figlet-2.2.4.tar.gz ms-dos.tar.gz 
ea048d8d0b56f9c58e55514d4eb04203  figlet-2.2.4.tar.gz
49aa57ab989e8d952be037414b0bbbe4  ms-dos.tar.gz

ok  MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.

++  MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line.
Not confirmed to build on all architectures.

ok  MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
ok  MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
ok  MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
ok  MUST: Packages must NOT bundle copies of system libraries.
ok  MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
ok  MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
ok  MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)[14]
ok  MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example.
ok  MUST: Each package must consistently use macros.
ok  MUST: The package must contain code, or permissable content.
ok  MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity).
ok  MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
ok  MUST: Static libraries must be in a -static package.
ok  MUST: Development files must be in a -devel package.
ok  MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
ok  MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
ok  MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.
ok  MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [23]
ok  MUST: All filenames in rpm packages must be valid UTF-8.

ok  SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
ok  SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
ok  SHOULD: The reviewer should test that the package builds in mock.
 http://koji.fedoraproject.org/koji/taskinfo?taskID=4082778

++  SHOULD: The package should compile and build into binary rpms on all supported architectures.
ok  SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
ok  SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
ok  SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
ok  SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
ok  SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
ok  SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.
Comment 17 Paulo Andrade 2012-05-16 23:40:35 EDT
It is optional to address the usage and rm -fr of Buildroot, and
usage of make instead of %__make.

Addressing %check usage should be done.
Comment 18 Thomas Spura 2012-05-17 08:01:06 EDT
Further issues:
- %{optflags} are not honored:
  + /usr/bin/make
    gcc -c -g -O2 -Wall -DTLF_FONTS -DDEFAULTFONTDIR=\"/usr//share/figlet\" \
	-DDEFAULTFONTFILE=\"standard\" -o figlet.o figlet.c
- utf8.* has license ISC
- Please write specifically which files have which license as comment in the spec file (Didn't found a file in the tarball, which would describe that...)
- I'm +1 for the split into figlet-fonts, mentioned in comment #9.

(In reply to comment #13)
> John Cowan from the FIGlet development team informed us that:
> 
> "Bitmap fonts are in the public domain in the U.S., because they are
> considered insufficiently creative to copyright.  Specifically, the actual
> *appearance* of a font cannot be copyrighted, and bitmaps are considered
> just a trivial transformation of the appearance.  Scalable fonts are
> computer programs, though, and are copyrightable."

Who "considers [them] insufficently creative to copyright"?
I'm highly suggesting blocking FE-LEGAL and being sure that the licensing issues are clear, when you have added the comment to the spec file, which file has which license...
Comment 19 Thomas Spura 2012-05-17 08:01:52 EDT
*** Bug 454917 has been marked as a duplicate of this bug. ***
Comment 20 Claudio Matsuoka 2012-05-17 09:07:44 EDT
> Who "considers [them] insufficently creative to copyright"?

I did a small research on the subject and found the following pieces of information on the comp.fonts FAQ. Note however that this is valid only in US, and more important to the topic of this discussion, all fonts with objectionable licenses are part of a set of contributed fonts which are not part of the main figlet package (which contains only properly licensed material). It is relevant only if an extra package containing contributed fonts is to be generated.

  Volume 37 of the Code of Federal Regulations specifies this about the
  copyrightability of typefaces:
  
  "The following are examples of works not subject to copyright and
  applications for registration of such works cannot be entertained: . . .
  typeface as typeface" 37 CFR 202.1(e).
  
  The regulation is in accordance with the House of Representatives report
  that accompanied the new copyright law, when it was passed in 1976:
  
  "The Committee has considered, but chosen to defer, the possibility of
  protecting the design of typefaces.  A 'typeface' can be defined as a
  set of letters, numbers, or other symbolic characters, whose forms are
  related by repeating design elements consistently applied in a
  notational system and are intended to be embodied in articles whose
  intrinsic utilitarian function is for use in composing text or other
  cognizable combinations of characters.  The Committee does not regard
  the design of typeface, as thus defined, to be a copyrightable
  'pictorial, graphic, or sculptural work' within the meaning of this bill
  and the application of the dividing line in section 101."  H. R. Rep.
  No.  94-1476, 94th Congress, 2d Session at 55 (1976), reprinted in 1978
  U.S. Cong. and Admin. News 5659, 5668.
  
  It's also in accordance with the one court case I know of that has
  considered the matter: Eltra Corp. V. Ringer, 579 F.2d 294, 208 USPQ 1
  (1978, C.A. 4, Va.).
  
  The U.S. Copyright Office holds that a bitmapped font is nothing more
  than a computerized representation of a typeface, and as such is not
  copyrightable:
  
  "The [September 29, 1988] Policy Decision [published at 53 FR 38110]
  based on the [October 10,] 1986 Notice of Inquiry [published at 51 FR
  36410] reiterated a number of previous registration decisions made by
  the [Copyright] Office.  First, under existing law, typeface as such is
  not registerable.  The Policy Decision then went on to state the
  Office's position that 'data that merely represents an electronic
  depiction of a particular typeface or individual letterform' [that is, a
  bitmapped font] is also not registerable."  57 FR 6201.
  
  However, scalable fonts are, in the opinion of the Copyright Office,
  computer programs, and as such are copyrightable:
  
  "... the Copyright Office is persuaded that creating scalable typefonts
  using already-digitized typeface represents a significant change in the
  industry since our previous [September 29, 1988] Policy Decision.  We
  are also persuaded that computer programs designed for generating
  typeface in conjunction with low resolution and other printing devices
  may involve original computer instructions entitled protection under the
  Copyright Act.  For example, the creation of scalable font output
  programs to produce harmonious fonts consisting of hundreds of
  characters typically involves many decisions in drafting the
  instructions that drive the printer.  The expression of these decisions
  is neither limited by the unprotectable shape of the letters nor
  functionally mandated.  This expression, assuming it meets the usual
  standard of authorship, is thus registerable as a computer program."  57
  FR 6202."
Comment 21 Simone Caronni 2012-05-21 03:02:36 EDT
Hello,

come back from holiday right now, thanks for all the input. Here is the updated package and spec file:

Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.4-7.fc17.src.rpm

- ms-dos fonts have been removed, I will create a separate figlet-fonts package for all the extra fonts.
- Added check command to %check, reading the tests.log file I see them all pass.
- Replaced make macro with actual command as suggested by rpmdev-newspec.
- Added compile flags (%optflags) to make command to make sure they are passed at compile time.

Thanks,
--Simone
Comment 22 Simone Caronni 2012-05-21 03:07:42 EDT
I forgot to say that I left buildroot etc. intentionally as I plan to build it also for EPEL 5.
Comment 23 Thomas Spura 2012-05-21 04:02:12 EDT
A comment, which describes which file has which license is still missing:
https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios

(In reply to comment #13)
> John Cowan from the FIGlet development team informed us that:
> 
> "Bitmap fonts are in the public domain in the U.S., because they are
> considered insufficiently creative to copyright.  Specifically, the actual
> *appearance* of a font cannot be copyrighted, and bitmaps are considered
> just a trivial transformation of the appearance.  Scalable fonts are
> computer programs, though, and are copyrightable."

According to that, the fonts should be "Public Domain" and that license is missing yet.

Blocking FE-LEGAL to get clarification of the above and a "English" to "yes/no" translation...
(More aabout that in comment #9 comment #20)
Comment 24 Simone Caronni 2012-05-21 04:08:07 EDT
Thanks,

still waiting for the reply at comment #9 to see which files have which license.

I will add the appropriate license files and comments to the spec/srpm file when a response is available.
Comment 25 Matthias Runge 2012-05-21 04:39:57 EDT
There's also a ticket at debian regarding license issues:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274950
Comment 26 Tom "spot" Callaway 2012-05-21 10:13:29 EDT
(In reply to comment #23)
> A comment, which describes which file has which license is still missing:
> https://fedoraproject.org/wiki/Packaging/
> LicensingGuidelines#Multiple_Licensing_Scenarios
> 
> (In reply to comment #13)
> > John Cowan from the FIGlet development team informed us that:
> > 
> > "Bitmap fonts are in the public domain in the U.S., because they are
> > considered insufficiently creative to copyright.  Specifically, the actual
> > *appearance* of a font cannot be copyrighted, and bitmaps are considered
> > just a trivial transformation of the appearance.  Scalable fonts are
> > computer programs, though, and are copyrightable."
> 
> According to that, the fonts should be "Public Domain" and that license is
> missing yet.
> 
> Blocking FE-LEGAL to get clarification of the above and a "English" to
> "yes/no" translation...
> (More aabout that in comment #9 comment #20)

I would agree with John Cowan's assessment of the fact that non-scalable "bitmap" fonts are not copyrightable in the United States and can safely be treated as being in the Public Domain in Fedora.

Are all of these fonts clearly bitmap fonts and not scalable?
Comment 27 Simone Caronni 2012-05-24 09:32:06 EDT
All of the fonts are not scalable, they're made of ordinary ascii as far as I know.

Any news from Claudio Matsuoka regarding the license calrifications?
Comment 28 Claudio Matsuoka 2012-05-24 10:49:48 EDT
  
(In reply to comment #23)
> A comment, which describes which file has which license is still missing:
> https://fedoraproject.org/wiki/Packaging/
> LicensingGuidelines#Multiple_Licensing_Scenarios
> 
> (In reply to comment #13)
> > John Cowan from the FIGlet development team informed us that:
> > 
> > "Bitmap fonts are in the public domain in the U.S., because they are
> > considered insufficiently creative to copyright.  Specifically, the actual
> > *appearance* of a font cannot be copyrighted, and bitmaps are considered
> > just a trivial transformation of the appearance.  Scalable fonts are
> > computer programs, though, and are copyrightable."
> 
> According to that, the fonts should be "Public Domain" and that license is
> missing yet.

It is well understood that the appearance of fonts (the "typeface") is public domain. I'm not sure, however, about the files containing their encoding in a specific format such as the FIGlet FLF font file. My interpretation is that the bitmapped typeface can be freely copied as public domain, but the font file containing the encoding of the file can be subject to a license such as the one already used for the main package (so no other license is necessary).
Comment 29 Claudio Matsuoka 2012-05-28 09:40:17 EDT
We've just been informed by Jonathan McCrohan of Debian that:

"During a review of my updated figlet 2.2.4-1 package[1], it was
discovered that the fonts directory still contains non-distributable
files. An example of these files are the fonts/8859-*.flc files. These
files contain the following paragraph: 'Unicode, Inc. specifically
excludes the right to re-distribute this file directly to third
parties or other organizations whether for profit or not'.

Bart Martens has helpfully suggested that the files could be replaced
by the following re-distributable file [2].

(...)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673096#18
[2] ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-3.TXT"


The plan is to fix this problem upstream using Bart Martens' proposal. Please also review this option and if no further problems are found we'll release 2.2.5 with these changes.
Comment 30 Claudio Matsuoka 2012-05-28 13:49:58 EDT
Regarding comment #29, John Cowan informs that:

"Those should simply be replaced by the verbatim contents of the
corresponding files at http://www.unicode.org/Public/MAPPINGS/ISO8859 .

In addition, the jis0201.flc file should be replaced likewise by
the verbatim contents of
http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0201.TXT .
(Don't worry, the mapping is not obsolete; that's just a hint that Unicode
Inc. isn't maintaining these files -- but this one doesn't actually need
any maintenance.)

The other *.flc files were written by me (or Glenn and me, in the case
of upper.flc), and should be under the same license as FIGlet itself."
Comment 31 Simone Caronni 2012-05-28 15:37:54 EDT
Thanks for pushing this. I will wait on 2.2.5 to provide an updated package.

Regards,
--Simone
Comment 32 Simone Caronni 2012-06-14 03:46:16 EDT
Hello,

I noticed 2.2.5 has come out with the aforementioned changes to licensing.

Spec URL: http://slaanesh.fedorapeople.org/figlet.spec
SRPM URL: http://slaanesh.fedorapeople.org/figlet-2.2.5-1.fc17.src.rpm

I also added a quick diff file between 2.2.4 and 2.2.5 source tarballs so you can check all the differences between the copyright / license headers easily:

http://slaanesh.fedorapeople.org/figlet-2.2.4-2.2.5.diff

Can we proceed with the review?

Many thanks,
--Simone
Comment 33 Tom "spot" Callaway 2012-06-14 09:25:38 EDT
Lifting FE-Legal.
Comment 34 Simone Caronni 2012-07-02 05:16:33 EDT
Hello,

any news from Legal? Is there a way I can check the progress on this or as part of the Legal scrutiny updates will be posted here in the bug?

Thanks & regards,
--Simone
Comment 35 Matthias Runge 2012-07-02 05:18:31 EDT
It looks like legal problems were cleared.
(In reply to comment #33)
> Lifting FE-Legal.
Comment 36 Paulo Andrade 2012-07-03 08:44:00 EDT
Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== C/C++ ====
[x]: MUST Header files in -devel subpackage, if present.
[x]: MUST Package does not contain any libtool archives (.la)
[ ]: MUST Package does not contain kernel modules.
[ ]: MUST Package contains no static executables.
[ ]: MUST Rpath absent or only used for internal libs.
[ ]: MUST Package is not relocatable.


==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
[x]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[!]: MUST Buildroot is not present
     Note: Buildroot is not needed unless packager plans to package for EPEL5
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[!]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean is needed only if supporting EPEL
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[!]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf is only needed if supporting EPEL5
[x]: MUST Large documentation files are in a -doc subpackage, if required.
[x]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint output is silent.

rpmlint figlet-debuginfo-2.2.5-1.fc18.i686.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


rpmlint figlet-2.2.5-1.fc18.i686.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


rpmlint figlet-2.2.5-1.fc18.src.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/pcpa/rpmbuild/820642/figlet-2.2.5.tar.gz :
  MD5SUM this package     : d88cb33a14f1469fff975d021ae2858e
  MD5SUM upstream package : d88cb33a14f1469fff975d021ae2858e

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[x]: MUST Useful -debuginfo package or justification otherwise.
[x]: SHOULD Reviewer should test that the package builds in mock.
[x]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD SourceX is a working URL.
[x]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[x]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

Issues:
[!]: MUST Buildroot is not present
     Note: Buildroot is not needed unless packager plans to package for EPEL5
See: http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
[!]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean is needed only if supporting EPEL
See: http://fedoraproject.org/wiki/Packaging/Guidelines#.25clean
[!]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf is only needed if supporting EPEL5
See: None


Generated by fedora-review 0.1.3
External plugins:

---%<---%<---%<---%<---

If the package is not going to be submitted to EPEL5, please remove Buildroot and %clean and it is ok now.

Too bad the package got stripped a lot from cool fonts due to possible legal issues, but still has a lot of cool ones:

$ figlet -f standard Package approved!
 ____            _                    
|  _ \ __ _  ___| | ____ _  __ _  ___ 
| |_) / _` |/ __| |/ / _` |/ _` |/ _ \
|  __/ (_| | (__|   < (_| | (_| |  __/
|_|   \__,_|\___|_|\_\__,_|\__, |\___|
                           |___/      
                                          _ _ 
  __ _ _ __  _ __  _ __ _____   _____  __| | |
 / _` | '_ \| '_ \| '__/ _ \ \ / / _ \/ _` | |
| (_| | |_) | |_) | | | (_) \ V /  __/ (_| |_|
 \__,_| .__/| .__/|_|  \___/ \_/ \___|\__,_(_)
      |_|   |_|
Comment 37 Simone Caronni 2012-07-03 09:03:34 EDT
Yeah, it's a shame for the font, but anyway is
                      _   _                           _ _ 
       _ __  _ __ ___| |_| |_ _   _    ___ ___   ___ | | |
      | '_ \| '__/ _ \ __| __| | | |  / __/ _ \ / _ \| | |
 _ _ _| |_) | | |  __/ |_| |_| |_| | | (_| (_) | (_) | |_|
(_|_|_) .__/|_|  \___|\__|\__|\__, |  \___\___/ \___/|_(_)
      |_|                     |___/                       

Thanks for the review.
I'm leaving %buildroot and %clean as is my intention to build for EPEL 5.

Regards,
--Simone
Comment 38 Simone Caronni 2012-07-03 09:05:30 EDT
New Package SCM Request
=======================
Package Name: figlet
Short Description: A program for making large letters out of ordinary text
Owners: slaanesh
Branches: el5 el6 f16 f17
InitialCC:
Comment 39 Jon Ciesla 2012-07-03 09:07:16 EDT
Git done (by process-git-requests).
Comment 40 Fedora Update System 2012-07-03 09:27:43 EDT
figlet-2.2.5-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/figlet-2.2.5-1.el5
Comment 41 Fedora Update System 2012-07-03 09:28:22 EDT
figlet-2.2.5-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/figlet-2.2.5-1.el6
Comment 42 Fedora Update System 2012-07-03 09:28:41 EDT
figlet-2.2.5-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/figlet-2.2.5-1.fc16
Comment 43 Fedora Update System 2012-07-03 09:29:09 EDT
figlet-2.2.5-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/figlet-2.2.5-1.fc17
Comment 44 Fedora Update System 2012-07-05 19:02:17 EDT
figlet-2.2.5-1.el5 has been pushed to the Fedora EPEL 5 stable repository.
Comment 45 Fedora Update System 2012-07-05 19:03:49 EDT
figlet-2.2.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository.
Comment 46 Fedora Update System 2012-07-05 19:29:15 EDT
figlet-2.2.5-1.fc16 has been pushed to the Fedora 16 stable repository.
Comment 47 Fedora Update System 2012-07-05 19:34:28 EDT
figlet-2.2.5-1.fc17 has been pushed to the Fedora 17 stable repository.

Note You need to log in before you can comment on or make changes to this bug.