Spec Name or Url: http://www.daughtersoftiresias.org/progs/firefly/fortune-mod-firefly.spec SRPM Name or Url: None - noarch Description: Fortune-mod-firefly provides a set of quotes from the popular television series "Firefly", and its movie "Serenity", by Joss Whedon. This is my first package - I am seeking a sponsor.
Please provide an URL to the .src.rpm This spec file is very far from usual spec files, please have a look at the specfile template distributed in the fedora-rpmdevtools package.
Please review the "Code vs Content" guidelines: http://fedoraproject.org/wiki/PackagingGuidelines#head-4dc3d91015e3651ef0569c9810270ff31d277a4b The "fortune-mod" package, due to some of the content included within it which may be considered offensive in one way or another, is a corner-case already. I think adding a separate package to Fedora Extras for just 30 KiB of quotes is not justified.
So, the content issue is boiled down to two questions: 1. Does fortune-mod-firefly enhance the user experience? (I could see both sides of this issue, but I'm leaning towards yes) 2. Is the content legally permissable? I would say that this content falls safely under the guidelines of Fair Use, as long as the upstream authors are clearly attributed. Right now, this is not the case, but it would not be difficult to identify the authors from the various TV scripts (Tim Minear, Joss Whedon, Ben Edlund, Jane Espenson, Drew Z. Greenberg, Jose Molina, Cheryl Cain, Brent Matthews) and the movie script (Joss Whedon). Also, I think we should not worry about the fact that this package is small. If anything, we should worry less about it because it is so small. So, Karen, here's what you need to do: 1. Clean up that spec file. It's really icky. 2. In the %description section of that package, make sure you give citations to the authors of the scripts where your quotes originate. 3. Have your tarball just create a "firefly-mod" directory with those two files included in it, as opposed to the current "usr/share/games/fortune/*" hierarchy that it is currently using. Then, have your spec file make the correct target directories and install those files into them (and use %files to annotate what should be packaged in the rpm). If you need help doing any of that, please feel free to let me know.
Ok - I'll get to cleaning up the spec file. I've never written one before, so I worked (based on a rpm howto that I found) until I got one that worked - I'll use the example that Michael Schwendt referenced. Done - I started with the template, and the only thing that I really had to alter (apart from filling out the blanks) was that, since there's no building in this noarch package, all of the references to building were stripped. I already credit Whedon in the description - I'll credit the other writers as well. Done. As far as size goes, here are the size of some common fortune datafiles already out there, with Firefly added in, sorted by size.: 4.0K fgump 4.0K translate-me 8.0K ascii-art 8.0K goedel 8.0K pets 12K chapterhouse-dune 12K dune-messiah 12K magic 12K news 12K prog-style 12K ralph 12K starwars 16K calvin 16K kernelcookies 20K cbg 20K heretics-of-dune 20K house-harkonnen 20K linuxcookie 20K medicine 24K bofh-excuses 24K dune 24K hitchhiker 24K house-atreides 24K love 24K macintosh 24K powerpuff 24K riddles 28K fortunes 28K kids 28K oneliners 32K children-of-dune 32K god-emperor 32K startrek 32K xfiles 36K chalkboard 36K ethnic 36K food 36K platitudes 40K drugs 40K education 40K sports 40K tao 40K zippy 44K futurama 44K humorists 48K miscellaneous 48K osho 48K zippy2 52K homer 52K literature 56K law 60K wisdom 84K art 88K firefly 88K taow 92K kernelnewbies 108K work 112K politics 128K science 148K people 156K definitions 192K discworld 228K computers 232K songs-poems 240K cookie 2.4M simpsons You'll notice that firefly is not small, but large for a fortune-mod. It's over three times the size of, say, the "fortunes" file. Sure, it doesn't compare to monstrous mods like "simpsons", but it's quite sizable. Also, checking over other fortune mods, it shouldn't have "mod" in the title - so I'm stripping that out. New URLs are below. For the person who asked for a src rpm: this is a noarch package, which does no building. What would the point of a src rpm be? As for offensiveness: The TV-series quotes were deemed nonoffensive enough to be run on Fox, at the very least. The movie was rated PG-13, mostly for violence. Is that really too extreme? If what they said in Chinese was offensive to people (the Chinese wasn't translated in the series or movie, thus avoiding the censors, but is translated here), I could remove the translations of the Chinese to make it just like the TV series and movie. Thanks for your help and criticism! I made this package not only because I'm a Firefly fan, but because there are so many geeks out there who are. It's almost an obsessive topic on Slashdot, for example. Even without being part of a major distro, I've gotten several hundred (perhaps thousands by now, I haven't checked lately) downloads of the software (that, with my only exposure being a mention on the wikipedia firefly article and an occasional mention on Slashdot), and over a dozen emails. Thus, I thought that, given its popularity with limited exposure, it'd be nice to have in my favorite distro (Fedora). As I may end up having to package a more important package in the future (I'm a developer on nethack-vultureseye), I figured a simple project like this would be a good start. New URL: http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly-1.6-0.noarch.rpm New Specfile: http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly.spec New Let me know what to do next.
> For the person who asked for a src rpm: this is a noarch package, which does > no building. What would the point of a src rpm be? Those are actually quite different. A noarch package contains the final files, while a src.rpm contains the tarball and the specfile.
Ah, ok. It's created now. URL: http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly-1.6-1.src.rpm
Currently the fortune-mod package installs to /usr/games/fortune, not /usr/share/games/fortune, so you may want to install there instead.
Created attachment 119568 [details] Spec file patch Here's a patch for your spec file to get it to build. Looks like you were missing a few items: - Add fortune-mod requirement. - Install into %%prefix, instead of %%datadir. - Add prep, install, and clean sections. - Add buildroot. I'll attach a patch for your spec file for these changes. I would also suggest maybe adding some documentation (a simple README) to the package. My changes should also get a closer look, since I just banged this out real quick.
I've attached a patch for your spec file to get it to build. Looks like you were missing a few items: - Add fortune-mod requirement. - Install into %%prefix, instead of %%datadir. - Add prep, install, and clean sections. - Add buildroot. I would also suggest maybe adding some documentation (a simple README) to the package. My changes should also get a closer look, since I just banged this out real quick.
Thanks! I really appreciate that patch. I didn't get what the macros about building would do for a noarch package, so I had removed them - I guess they're needed? Using ${_prefix} makes good sense of course, as does the requirement to have fortune installed. :) I've incorporated the patch into the specfile, and rebuilt the RPMs. Again, thanks a lot!
Oh, one quick question: where would one incorporate a README into a fortune addon? None of the fortune addons that are RPMs that I've found have READMEs in them; the only one that I found a README for was in simpsons, which was downloaded as a tarball.
You would package a readme with %doc IE %files %defattr(-,root,root,-) %doc README etc. That will copy the README file to the appropriate documentation directory when rpm builds the package.
(In reply to comment #3) > 3. Have your tarball just create a "firefly-mod" directory with those two files > included in it, as opposed to the current "usr/share/games/fortune/*" hierarchy > that it is currently using. Then, have your spec file make the correct target > directories and install those files into them (and use %files to annotate what > should be packaged in the rpm). > > If you need help doing any of that, please feel free to let me know. I've changed your tarball's hierarchy to comply to Tom's suggestion. You can find it here: http://piedmont.homelinux.org/fedora/fortune-firefly-1.7.tar.bz2 I'll also attach a patch for the specfile for this change in hierarchy. BTW, I also added BuildArch: noarch. If you decide you also want to add a README file. All you would need to do is add the README to the tarball, and then add Michael's suggestion from comment #12.
Created attachment 119572 [details] Spec patch for Tarball hierarchy change
Thanks Brian, Michael - I've incorporated all of that now. :)
Is there an upstream source for which an md5sum can be checked? The source tarballs seems to contain just two files - one I can read with a text editor, one I can not read with a text editor. I assume this is coming from somewhere. How is the .dat file generated, and shouldn't it be generated inside the %build section from its source? Excuse my ignorance with respect to the way fortune works.
The dat file is created using 'strfile' (provided by fortune-mod). Example from fortune-mod.spec: # Recreate random access files for the added fortune files. for i in \ kernelnewbies bofh-excuses tao hitchhiker \ osfortune humorix-misc humorix-stories \ ; do util/strfile $RPM_BUILD_ROOT%{CookieDir}/$i ; done Of course, once fortune-mod is installed, strfile lives in %_sbindir I agree with comment #16 that the dat file should be generated in the spec. This helps automate the build a bit more - you won't have to manually create the dat file each time you want to update the fortunes.
In that case the src can be reduced to the single file and the README. fortune-mod should be a BuildRequires. In %build - call strfile on the text file to generate the .dat file.
Hmm... isn't that making it more complicated, though - requiring strfile on the builder's computers? dat files are noarch, and tiny - why not just include them? Every fortune addon rpm that I have on my system includes the dat file in the package. Michael: Dat files are designed to make it so that fortune doesn't have to read through every fortune file it has every time the user runs it (as you may have noticed, fortune files can get pretty sizable, as far as text file sizes go). Think of the dat file as an index.
(In reply to comment #7) > Currently the fortune-mod package installs to /usr/games/fortune, not > /usr/share/games/fortune, so you may want to install there instead. For stuff like fortune which has been kicked out of RHL/RHEL/FC a long time ago repackaging should follow strict FHS conventions IMHO, not reintroduce old RedHatisms even Red Hat does not care about nowadays. I'd go even further : unless a FC decision forces you not to follow the FHS you should follow the standard not RH habits, FE promotes cleaner packaging than FC in the hope FC follows later. Historical decisions or FC slopiness is not an example to follow in FE
Regarding comment #20 - OK, where is the documentation saying that packages should install to /usr/share/ instead of /usr? I see nothing of the sort in http://fedoraproject.org/wiki/PackagingGuidelines If this is a FE suggestion or requirement, I would like to know, and if so, I will look into modifying fortune-mod. But for the time being, my point is that sub-packages should install into the same place as the main package, be it /usr, /usr/share, or /some/crazy/dir. As for comment #19, yes it does complicate the spec a bit, although it simplifies rebuilds. This is still including the dat file in the rpm, it is simply removing it from the tarball.
(In reply to comment #19) > Hmm... isn't that making it more complicated, though - requiring strfile on > the builder's computers? dat files are noarch, and tiny - why not just > include them? Every fortune addon rpm that I have on my system includes the > dat file in the package. It's not really more complicated for the builder. If anything, it ensures that the dat file matches the latest human readable text file.
(In reply to comment #21) > Regarding comment #20 - OK, where is the documentation saying that packages > should install to /usr/share/ instead of /usr? The packaging guidelines do not repeat Linux standards because you're supposed to know them and follow them without being told. The standard itself is there : http://www.pathname.com/fhs/pub/fhs-2.3.html Existing packages (RHEL, FC) are being slowly migrated by Red Hat to conform to the FHS. New packages (FE, FC, RHEL) have no excuse not to follow it.
(In reply to comment #23) > The packaging guidelines do not repeat Linux standards because you're supposed > to know them and follow them without being told. The standard itself is there : > > http://www.pathname.com/fhs/pub/fhs-2.3.html > > Existing packages (RHEL, FC) are being slowly migrated by Red Hat to conform to > the FHS. New packages (FE, FC, RHEL) have no excuse not to follow it. Regardless, until fortune-mod is changed, this addon has to use /usr/games/fortune.
(In reply to comment #19) > Hmm... isn't that making it more complicated, though - requiring strfile on > the builder's computers? dat files are noarch, and tiny - why not just > include them? Every fortune addon rpm that I have on my system includes the > dat file in the package. Include it in the package, yes. But generate it at build time - when rpmbuild is called, not beforehand. Supposing there is a vulnerability in fortune that a carefully crafted .dat file could exploit. By including the .dat file in the src.rpm - there isn't a way to adequately audit the .dat file. By instead generating the .dat file when the rpm is built, the file it is generated from can be audited. It isn't any more difficult for the user - the rpm they install still has the .dat file. It is better for Fedora because Fedora knows exactly where the .dat file came from - it came from the included text file, generated on the build machine using the strfile from the Fedora approved and maintained fortune-mod package.
Ok. I don't see how a dat file, which is really just a header and a list of quote offsets could pose a threat to anything, and I can't find a single other fortune package that is distributed that way (including fortune itself) among about two dozen fortune packages on my system, but if that's really what you want, I'll change it to be distributed that way when I get home this evening. :)
I don't know what other packagers do. If they package for Fedora Extras and do not generate the .dat file inside the build process, that needs to be brought to attention because it is not proper. I can't read the .dat file with a text reader, which poses a problem because there is not a way to verify that it was generated from the text file. The fortune-mod package in Fedora Extras does this: # Recreate random access files for the added fortune files. for i in \ kernelnewbies bofh-excuses tao hitchhiker \ osfortune humorix-misc humorix-stories \ ; do util/strfile $RPM_BUILD_ROOT%{CookieDir}/$i ; done It generates the .dat files in the rpm. That is the proper way to do it. What other fortune packages that are not reviewed by Extras do doesn't matter, but I suspect that many of them generate the .dat file in the spec file as well. If they don't, they aren't properly packaged.
http://mpeters.us/fc_extras/fortune-firefly-1.7-2.mpeters.src.rpm http://mpeters.us/fc_extras/fortune-firefly.spec The above spec file generates the .dat file during build. I also changed how it is packaged - you don't need to use a src tarball, you can just use two text files for sources - the firefly file and the README. Your original tarball I unpacked into ~/delete_me (that's a folder where I unpack stuff I don't want to keep around - nothing personal) I ran diff on the .dat file generated by the rpm file and your .dat file - and they differ: [mpeters@laptop tmp]$ diff --brief fortune-firefly-1.7-2.mpeters-root-mpeters/usr/share/games/fortune/firefly.dat ~/delete_me/fortune-firefly-1.7/firefly.dat Files fortune-firefly-1.7-2.mpeters-root-mpeters/usr/share/games/fortune/firefly.dat and /home/mpeters/delete_me/fortune-firefly-1.7/firefly.dat differ [mpeters@laptop tmp]$ Why they differ I don't know, it could be as simple as a different encoding timestamp in the .dat file. But the point is that there is no way to validate the integrity of the .dat file. By letting it be generated during the rpm building process, it is clear how it was generated and what it was generated from.
Thanks! I'll hook that in tonight. As for the differing, have to tried to diff your copy of the text file with my copy of the text file?
I went ahead and took care of it - done. :) Version's updated, as I just got some quote corrections.
(In reply to comment #28) > http://mpeters.us/fc_extras/fortune-firefly.spec Has fortune-mod been rebuilt using %{_datadir}/games/fortune? If not, you spec file will build, but not run correctly.
Hmm... perhaps I should let you two decide amongst yourselves what is best before I go back and forth again. :) Both work on my system, but that's because I run a mixed system (Fedora, Dries, Dag, etc) and long ago symlinked /usr/games/fortune to /usr/share/games/fortune to deal with this issue. I'll wait until you two agree on how to package it before changing it again.
(In reply to comment #32) > Both work on my system, but that's because I run a mixed system > (Fedora, Dries, Dag, etc) and long ago symlinked > /usr/games/fortune to /usr/share/games/fortune to deal with this issue. I'm guessing most users probably don't have /usr/games/fortune symlinked to /usr/share/games/fortune. And to ship a package that requires a user to symlink the directories to get it to work, is broken in my opinion.
If you can wait a day or two, I will update fortune-mod to install to /usr/share/games instead of /usr/games. So please use /usr/share/games for your path (but hold off on building until the new fortune-mod is built).
It currently installs to /usr/share/games, so I'll leave it as such. Thanks, Jeff!
Ok, new fortune-mod has been built and is waiting to be signed.
(In reply to comment #36) > Ok, new fortune-mod has been built and is waiting to be signed. Devel advocate question: Are *.dat files architecture independent?
LOL, is that devel advocate or devil advocate? :) I guess that there are many devel advocates in FE... I belive that they are arch independent, but I don't have a sparc to be sure... The strfile man page actually describes the file format, and (it claims) it uses network byte order to write the fields, which I think makes the files arch independent, although if someone with more knowledge on the matter could step in, that would be nice.
Re: comment 37 and 38 Download the "ppc" and "i386" binary rpms of fortune-mod, then take a look at a hex-dump, or run md5sum/sha1sum on the files. ;)
Thanks Michael, I should have thought of that :) And, yes, they do have the same checksum.
Karen, can you change Source1 to point to: http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly-%{version}/firefly ?
Good catch, spot - done :)
I caught two minor issues first: - The changelog referred to 1.8.1, but the latest version is 1.8. I'm thinking Michael meant to put "1.8-1". Everytime you increment version (or release) you should put an entry in the changelog explaining why. I added an entry for 1.8-2, otherwise, rpmlint would have complained. - Instead of /usr/sbin, use %{_sbindir}. It's the same thing, but it keeps the rpm spec cleaner and ensures consistent macro use. I changed it out in the two places it was used in the spec file. Review (with above changes made): Good: - rpmlint checks return: nothing - package meets naming guidelines - package meets packaging guidelines - license (GPL) OK, matches source - spec file legible, in am. english - source matches upstream - package compiles on devel (x86) - no missing BR - no unnecessary BR - no locales - not relocatable - owns all directories that it creates - no duplicate files - permissions ok - %clean ok - macro use consistent - content enhances user experience - no need for -docs - nothing in %doc affects runtime - no need for .desktop file With those changes, this package is APPROVED. Thanks for packaging this up, I'm a huge Firefly fan. I will sponsor you, so go ahead and do your paperwork.
Thank you thank you! :) I made the changes you mentioned (sorry about the changelog, it skipped my mind). I'll take care of the paperwork this evening. Also, now I've got a bit of practice, so I may soon be working on packaging Vulture's Eye soon (the active fork of the now-defunct Falcon's Eye - I'm the main graphics/sound developer for that team). Thanks for all of your help!
Hmm.. .any clue why this would happen? "Submit 'Add' action denied. You may need to become a member of the cla_done group first." It's from this page (step 9): https://admin.fedora.redhat.com/accounts/userbox.cgi
That error is new to me. Did you fill out the full page with all information?
Yes - and it said that it was successfully added. It's only when I tried to become a member of the group that the wiki told me to, that it gave me that error (and it's repeatable). Should I report it as a bug?
If memory serves, you fill out the form, then receive an email requesting you to send back a signed copy of the CLA. Once that is received by the system, it flags you as "cla_done". Then (and only then) you can request membership in the fedoraextras group.
Hmm.. I received no email, and my work email address (which is what my bugzilla account is registered under) is quite reliable. There also was no message or instruction telling me to wait for an email. Well, I guess I'll just wait a bit more... perhaps it takes time before they send it.
Still no email (I'm not too surprised, as it didn't tell me to wait for an email the first time, it just said that it was successful). I just tried again... I still get the error. Should I report this as a bug? I don't see a way to delete my account to start over.
What is your user name? And you can re-request the CLA. Have you tried that?
My username is 'meme' I tried requesting cla_done, but it said that was not allowed (I forget the specific error message)
> I tried requesting cla_done No. You misunderstand me. I don't refer to the cla_group. You are not listed as a member of that group yet, which tells me that you have not signed the CLA yet. Log in at https://admin.fedora.redhat.com/accounts/ and click where it says "Request the Contributor License Agreement".
Ah, I bet that's it - I had missed that step in the wiki instructions :) The error messages have been really vague (I've gotten a couple other error messages that I was able to work around, and they were all big, long code traces - for example, putting in too much text in the comments section when creating an account (>1024 characters, if I recall)) Thanks for your help!
Hmm, new problem (step 13): [meme@daughtersoftiresias code]$ export CVSROOT=:ext:meme.redhat.com:/cvs/extras [meme@daughtersoftiresias code]$ export CVS_RSH=ssh [meme@daughtersoftiresias code]$ cvs co common For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs Permission denied (publickey,keyboard-interactive). cvs [checkout aborted]: end of file from server (consult above messages if any) [meme@daughtersoftiresias code]$ The only thing I can think of is the step where they said to give the id_dsa.pub file. The only id-dsa.pub file that I have was /etc/sysconfig/netdump_id_dsa.pub, so I sent that one; however, I have no clue whether that was the right thing or not. I also have three pub files in /etc/ssh - perhaps /etc/ssh/ssh_host_dsa_key.pub would be more proper? (by the way, if there is a different place I should be discussing problems that I encounter while trying to get setup, please let me know)
You need to generate an id_dsa keypair for interacting with the CVS server. You can do that by running: ssh-keygen It will put keys in ~/.ssh/ I don't know if the account system will let you upload a fixed ssh key, but if not, we'll have to put in the good key.
Please read http://www-128.ibm.com/developerworks/library/l-keyc.html. And yes, it would be better to discuss this on the mailing list.
> I don't know if the account system will let you upload a fixed ssh key It's an offered feature, so it's supposed to work.
Got it - thanks, all!
All steps listed in the wiki are now taken. :)