Bug 169716 - Review Request: fortune-firefly
Review Request: fortune-firefly
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
David Lawrence
http://www.daughtersoftiresias.org/pr...
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-10-01 19:52 EDT by Karen Pease
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-11 18:27:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Spec file patch (1.86 KB, patch)
2005-10-03 18:29 EDT, Brian Pepple
no flags Details | Diff
Spec patch for Tarball hierarchy change (1.46 KB, patch)
2005-10-03 20:30 EDT, Brian Pepple
no flags Details | Diff

  None (edit)
Description Karen Pease 2005-10-01 19:52:28 EDT
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.
Comment 1 Aurelien Bompard 2005-10-02 16:28:38 EDT
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.
Comment 2 Michael Schwendt 2005-10-03 07:37:20 EDT
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.
Comment 3 Tom "spot" Callaway 2005-10-03 10:23:56 EDT
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.
Comment 4 Karen Pease 2005-10-03 12:59:50 EDT
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. 
 
Comment 5 Aurelien Bompard 2005-10-03 13:07:53 EDT
> 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.
Comment 6 Karen Pease 2005-10-03 13:19:41 EDT
Ah, ok.  It's created now. 
 
URL: 
http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly-1.6-1.src.rpm 
 
Comment 7 Jeff Sheltren 2005-10-03 17:15:25 EDT
Currently the fortune-mod package installs to /usr/games/fortune, not
/usr/share/games/fortune, so you may want to install there instead.
Comment 8 Brian Pepple 2005-10-03 18:29:36 EDT
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.
Comment 9 Brian Pepple 2005-10-03 18:51:45 EDT
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.

Comment 10 Karen Pease 2005-10-03 19:22:50 EDT
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! 
 
Comment 11 Karen Pease 2005-10-03 19:30:29 EDT
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.   
 
Comment 12 Michael A. Peters 2005-10-03 19:57:27 EDT
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.
Comment 13 Brian Pepple 2005-10-03 20:28:21 EDT
(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.

Comment 14 Brian Pepple 2005-10-03 20:30:12 EDT
Created attachment 119572 [details]
Spec patch for Tarball hierarchy change
Comment 15 Karen Pease 2005-10-04 03:38:53 EDT
Thanks Brian, Michael - I've incorporated all of that now.  :) 
Comment 16 Michael A. Peters 2005-10-04 04:44:03 EDT
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.
Comment 17 Jeff Sheltren 2005-10-04 08:44:07 EDT
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.
Comment 18 Michael A. Peters 2005-10-04 10:16:50 EDT
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.
Comment 19 Karen Pease 2005-10-04 12:07:35 EDT
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. 
 
Comment 20 Nicolas Mailhot 2005-10-04 12:15:01 EDT
(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
Comment 21 Jeff Sheltren 2005-10-04 12:24:18 EDT
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.
Comment 22 Tom "spot" Callaway 2005-10-04 12:28:04 EDT
(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.
Comment 23 Nicolas Mailhot 2005-10-04 12:41:22 EDT
(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.
Comment 24 Brian Pepple 2005-10-04 12:47:34 EDT
(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.
Comment 25 Michael A. Peters 2005-10-04 13:26:57 EDT
(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.
Comment 26 Karen Pease 2005-10-04 14:14:20 EDT
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.  
:) 
 
Comment 27 Michael A. Peters 2005-10-04 14:44:26 EDT
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.
Comment 28 Michael A. Peters 2005-10-04 15:52:43 EDT
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.
Comment 29 Karen Pease 2005-10-04 15:55:53 EDT
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? 
 
Comment 30 Karen Pease 2005-10-04 16:15:38 EDT
I went ahead and took care of it - done.  :)  Version's updated, as I just got 
some quote corrections. 
 
Comment 31 Brian Pepple 2005-10-04 16:55:20 EDT
(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.
Comment 32 Karen Pease 2005-10-04 17:11:25 EDT
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. 
 
Comment 33 Brian Pepple 2005-10-04 17:22:26 EDT
(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.
Comment 34 Jeff Sheltren 2005-10-04 17:40:51 EDT
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).
Comment 35 Karen Pease 2005-10-04 18:49:30 EDT
It currently installs to /usr/share/games, so I'll leave it as such.  Thanks, 
Jeff! 
 
Comment 36 Jeff Sheltren 2005-10-04 21:26:33 EDT
Ok, new fortune-mod has been built and is waiting to be signed.
Comment 37 Ralf Corsepius 2005-10-04 22:12:04 EDT
(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?
Comment 38 Jeff Sheltren 2005-10-05 06:46:32 EDT
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.
Comment 39 Michael Schwendt 2005-10-05 08:47:08 EDT
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. ;)
Comment 40 Jeff Sheltren 2005-10-05 08:55:06 EDT
Thanks Michael, I should have thought of that :)

And, yes, they do have the same checksum.
Comment 41 Tom "spot" Callaway 2005-10-05 15:11:15 EDT
Karen, can you change Source1 to point to:
http://www.daughtersoftiresias.org/progs/firefly/fortune-firefly-%{version}/firefly
?
Comment 42 Karen Pease 2005-10-05 16:03:49 EDT
Good catch, spot - done  :) 
 
Comment 43 Tom "spot" Callaway 2005-10-05 18:56:27 EDT
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.
Comment 44 Karen Pease 2005-10-05 19:31:50 EDT
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! 
Comment 45 Karen Pease 2005-10-06 01:46:24 EDT
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 
 
Comment 46 Tom "spot" Callaway 2005-10-06 08:37:22 EDT
That error is new to me. Did you fill out the full page with all information?
Comment 47 Karen Pease 2005-10-06 12:26:15 EDT
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? 
 
Comment 48 Tom "spot" Callaway 2005-10-06 13:02:20 EDT
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.
Comment 49 Karen Pease 2005-10-06 13:31:19 EDT
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. 
 
Comment 50 Karen Pease 2005-10-07 14:03:30 EDT
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. 
 
Comment 51 Michael Schwendt 2005-10-08 07:31:00 EDT
What is your user name?

And you can re-request the CLA. Have you tried that?
Comment 52 Karen Pease 2005-10-08 23:35:17 EDT
My username is 'meme' 
I tried requesting cla_done, but it said that was not allowed (I forget the 
specific error message) 
 
Comment 53 Michael Schwendt 2005-10-09 05:55:38 EDT
> 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".
Comment 54 Karen Pease 2005-10-10 12:25:23 EDT
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! 
 
Comment 55 Karen Pease 2005-10-10 13:15:17 EDT
Hmm, new problem (step 13): 
 
[meme@daughtersoftiresias code]$ export 
CVSROOT=:ext:meme@cvs.fedora.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) 
 
Comment 56 Tom "spot" Callaway 2005-10-10 13:30:55 EDT
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.
Comment 57 Ignacio Vazquez-Abrams 2005-10-10 13:37:33 EDT
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.
Comment 58 Michael Schwendt 2005-10-10 14:39:54 EDT
> 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.
Comment 59 Karen Pease 2005-10-10 15:35:22 EDT
Got it - thanks, all! 
Comment 60 Karen Pease 2005-10-11 18:27:16 EDT
All steps listed in the wiki are now taken. :) 

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