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.
*** Bug 489830 has been marked as a duplicate of this bug. ***
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.
rpmbuild will compress the man pages for you, you can remove the gzip line.
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
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
Sorry for double posting, browser error. Second comment is ok.
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}
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...
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.uk). Ported to figlet, and slightly changed (without permission :-}) by Daniel Cabeza Gras (bardo.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.
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.
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
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
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."
I am taking the package for review.
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), 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.
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.
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.
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...
*** Bug 454917 has been marked as a duplicate of this bug. ***
> 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."
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
I forgot to say that I left buildroot etc. intentionally as I plan to build it also for EPEL 5.
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)
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.
There's also a ticket at debian regarding license issues: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274950
(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?
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?
(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).
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.
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."
Thanks for pushing this. I will wait on 2.2.5 to provide an updated package. Regards, --Simone
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
Lifting FE-Legal.
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
It looks like legal problems were cleared. (In reply to comment #33) > Lifting FE-Legal.
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 / __/ (_| |_| \__,_| .__/| .__/|_| \___/ \_/ \___|\__,_(_) |_| |_|
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
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:
Git done (by process-git-requests).
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
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
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
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
figlet-2.2.5-1.el5 has been pushed to the Fedora EPEL 5 stable repository.
figlet-2.2.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository.
figlet-2.2.5-1.fc16 has been pushed to the Fedora 16 stable repository.
figlet-2.2.5-1.fc17 has been pushed to the Fedora 17 stable repository.