Spec URL: http://www.dwheeler.com/zfuzz.spec SRPM URL: http://www.dwheeler.com/zfuzz-20070911-1.fc9.src.rpm Description: The zfuzz (Z fuzz, previously "fuzz") package is a collection of tools that help you to (1) format and print good-looking specifications in the Z ("zed") formal specification language using LaTeX, and (2) check them for compliance with the Z scope and type rules. The package defines a LaTeX style with extra LaTeX commands for laying out Z specifications, and includes font definitions for Zās special symbols. The type-checker includes a new "use before definition" (-d) option; with this enabled, you can put the paragraphs of a specification in whatever order best suits your exposition (instead of having to present material in a stricter definition-before-use order). It also includes a "Lisp-style echoing" option, which echos input in a Lisp-like format for further analysis. This package is useful if you want to create formal specifications using the Z specification language. The Z language accepted is that of the Z Reference Manual, second edition, which is not exactly the same as the Z ISO standard (see http://www.cs.york.ac.uk/hise/cadiz/standard.html for the differences). Historically, this package was called "fuzz", but there is another program ALSO called fuzz that users might simultaneously install. So the name of this package and command-line type-checker has been changed to "zfuzz". The LaTeX style itself continues to be named "fuzz" so LaTeX documents will continue to work. Much of the documentation refers to this package by the name "fuzz".
NOTE: This is my first Fedora package, and I am seeking a sponsor!
Note: rpmlint gives no errors, and mock works. I've walked through the Packaging Guidelines, Package Naming Guidelines, and Reviewer Guidelines, and I _believe_ I've complied with them. The spec file includes comments that justifies some of the decisions I made while packaging this.
Unfortunately this failed to build for me in mock on x86_64, rawhide: In file included from <stdout>:758: /usr/include/unistd.h:327: error: conflicting types for 'read' zscan.l:38: error: previous declaration of 'read' was here In file included from /usr/include/unistd.h:1100, from <stdout>:758: /usr/include/bits/unistd.h:35: error: conflicting types for 'read' zscan.l:38: error: previous declaration of 'read' was here make[1]: *** [zscan.o] Error 1 make[1]: *** Waiting for unfinished jobs.... rm zscan.c make[1]: Leaving directory `/builddir/build/BUILD/fuzz-2007-09-11/src' make: *** [src] Error 2 What release did you build against?
I built against 32-bit x86 on Fedora 9; it worked there. If necessary, I could exclude the 64-bit architecture and require running the 32-bit version on x86. Unfortunately, the comments in the source package make me suspect that this has not been tested on a 64-bit architecture. If porting to 64-bit is non-trivial, I plan to limit the architectures to start with, and then expand over time.
I patched the one line noted as a problem on x86_64. Available as: http://www.dwheeler.com/zfuzz.spec http://www.dwheeler.com/zfuzz-20070911-2.fc9.src.rpm http://www.dwheeler.com/zfuzz-20070911-2.fc9.i386.rpm Unfortunately, I don't have an x86_64 machine with F9+ that I can use as a test, so I don't know if that fixes the problem. Let me know if it does; otherwise, I'll exclude the architecture, and later once I get Koji access I can fix it for other archs.
If you have a Fedora account, you already have koji access. Just download your cert and run fedora-packager-setup. I did build the updated package on my x86_64 rawhide box and it worked fine, though, so this package should be ready for review. I can't promise I'll be able to do that any time soon, though, so anyone else is welcome to review this.
I used koji; the current package builds on ALL supported platforms for Fedora 9 (dist-f9). Thus... This package is ready for review! Do I have any reviewers? Note: I fixed the Wiki page PackageMaintainers/Join so that it clearly shows that you CAN use Koji before being sponsored, and the basics of how to use it. The page was very misleading originally; it seemed to say that you had to have a sponsor and CVS access before you could use Koji. Obviously that's not true! It also didn't show how to use Koji for simple scratch builds, and that was sad. Done.
Some remarks on the spec file: * I think it is better to use sed instead of perl for one-liners * gcc is not needed in BuildRequires (see the exceptions in guidelines) * use the virtual provides like tex(tex) and tex(latex) instead of explicitely depending on texlive * coments are good, but some of your comments are, in my opinion, (much) too long. For example the one about not splitting the package could be # the package contains few glyphs, but separating a font subpackages would # seemed unnecessary and confusing since it should be the only package using # the fonts * also some comments are redundant. For example you comment twice that mf and pk files are installed such that they don't have to be recreated. * paraphrasing the whole INSTALL file is not useful either. * you could split out the latex part, in tex-zfuzz. * the %description is much too long. * regarding the .pdf it is better to have the source and be able to rebuild from source in fedora. But even if it cannot be regenerated it is better to package it. There is no license issue because it is BSD, and it can be allowed in fedora because it is content. * The %build section has too much comments. Most of your code is self-documented * I think that a patch for adding the DESTDIR would be better than the substitution and I hope that upstream would accept it. * I don't think that CFLAGS can be defined when make is launched.
I've responded to comment 8 - the new release (number 3) is at: http://www.dwheeler.com/zfuzz-20070911-3.fc9.src.rpm http://www.dwheeler.com/zfuzz-20070911-3.fc9.i386.rpm http://www.dwheeler.com/zfuzz.spec This new zfuzz.spec file is rpmlint-clean, just like the previous ones were. I also did: koji build --scratch dist-f9 zfuzz-20070911-3.fc9.src.rpm and all architectures successfully completed (5 done, 0 failed) with this release (3) on Fedora 9. Here's how I handled each comment in comment 8: >* I think it is better to use sed instead of perl for one-liners Ok, done (with sed -i). BuildRequires: perl removed, because of this. >* gcc is not needed in BuildRequires (see the exceptions in guidelines) It's not NEEDED, but it is PERMITTED, so I thought it'd be better to be explicit. But I don't really care, so I've removed it. >* use the virtual provides like tex(tex) and tex(latex) instead of > explicitely depending on texlive Ah! Good point! Done. >* coments are good, but some of your comments are, in my opinion, (much) > too long. For example the one about not splitting the package could be ># the package contains few glyphs, but separating a font subpackages would ># seemed unnecessary and confusing since it should be the only package using ># the fonts > >* also some comments are redundant. For example you comment twice that > mf and pk files are installed such that they don't have to be recreated. > >* paraphrasing the whole INSTALL file is not useful either. Okay, shortened comments significantly. >* you could split out the latex part, in tex-zfuzz. True, but as I commented, I saw little point in doing so. The type-checker and latex style are meant to be used together, and are combined in upstream anyway. If that's wrong, they could be split later, but I doubt anyone will want it that way. >* the %description is much too long. Ok, shortened. >* regarding the .pdf it is better to have the source and be able to > rebuild from source in fedora. But even if it cannot be regenerated > it is better to package it. > There is no license issue because it is BSD, and it can be allowed in > fedora because it is content. Good! That was my exactly my thinking as well, which is why I packaged it this way. >* The %build section has too much comments. Most of your code is > self-documented Ok, comments removed/shortened. >* I think that a patch for adding the DESTDIR would be better than the > substitution and I hope that upstream would accept it. Done. I would hope that too, but I don't control upstream :-). I _will_ send the patches (and the spec file) to upstream once it's passed review. >* I don't think that CFLAGS can be defined when make is launched. Sure it can, it works just fine. CFLAGS is just yet another make variable. Easy test: if you remove the CFLAGS text in this .spec file, the options passed to gcc change radically.
I've fiddled with the spec file comments further, including removing 2 now-spurious ones. New SRPM and spec file (release 4) here: http://www.dwheeler.com/zfuzz-20070911-4.fc9.src.rpm http://www.dwheeler.com/zfuzz.spec Okay, hopefully that's the "last one" :-).
(In reply to comment #9) > It's not NEEDED, but it is PERMITTED, so I thought it'd be better to be > explicit. But I don't really care, so I've removed it. It is permitted, but for gcc it is discouraged. > True, but as I commented, I saw little point in doing so. The type-checker and > latex style are meant to be used together, and are combined in upstream anyway. > If that's wrong, they could be split later, but I doubt anyone will want it that > way. Now that I have read the fuzz manual I understand that I was wrong, the fuzz checker needs the latex part. In fact this is a latex package with a syntax checker. It seems to me that it should better be called tex-zfuzz and there is no reason to split it. > >* I think that a patch for adding the DESTDIR would be better than the > > substitution and I hope that upstream would accept it. > > Done. I would hope that too, but I don't control upstream :-). > I _will_ send the patches (and the spec file) to upstream once it's > passed review. Right. > >* I don't think that CFLAGS can be defined when make is launched. > > Sure it can, it works just fine. CFLAGS is just yet another make variable. > Easy test: if you remove the CFLAGS text in this .spec file, the options passed > to gcc change radically. Sure, I was referring to "${CFLAGS:-%optflags}", here $CFLAGS cannot be defined and if they were they should be overwritten anyway. There are still some comments that can be shortened a lot. For example, for the INSTALL file, suffice to say that the license is in the INSTALL file, everybody will understand why it has to be shipped. The BuildConflict is not right. You should arrange for things to build right with or without zfuzz installed. The comment about running mktexlsr is not useful, nor the one describing the manuals. It is in INSTALL which can be read by the user. Regarding the version, I am not sure that using the date is wise. Indeed if the versioning scheme changes, the new version may become newer. I think that using 0 as version and putting the date in the release is better, like Version: 0 Release: 0.X.20070911 This has a disadvantage, namely when release changes, the version doesn't change (similar with development snapshots). (In reply to comment #10) > Okay, hopefully that's the "last one" :-). Not this one...
In reply to comment #11) >Now that I have read the fuzz manual I understand that I was wrong, the >fuzz checker needs the latex part. In fact this is a latex package with >a syntax checker. It seems to me that it should better be called >tex-zfuzz >and there is no reason to split it. I'm don't think that's a good idea. It's not part of any typical TeX distribution, and the upstream name is "fuzz" not "tex-zfuzz". Besides, when I contacted upstream, he recommended "zfuzz". I'd prefer to keep its name as "zfuzz", to make it more likely that people who know what it is will find it, and to honor upstream request. >Sure, I was referring to "${CFLAGS:-%optflags}", here $CFLAGS cannot be >defined and if they were they should be overwritten anyway. Oh, _that's_ what you meant! You mean use: make CFLAGS="%{optflags}" Okay, I'll do that. >There are still some comments that can be shortened a lot. For example, >for the INSTALL file, suffice to say that the license is in the INSTALL >file, everybody will understand why it has to be shipped. Ok, shortened. >The BuildConflict is not right. You should arrange for things to >build right with or without zfuzz installed. Ok, done. > The comment about running mktexlsr is not useful, nor the one describing > the manuals. It is in INSTALL which can be read by the user. The point was to justify some decisions for people reading the .spec file, not for end-users. I rewrote/shortened the text to (hopefully) make that clearer. > Regarding the version, I am not sure that using the date is wise. Indeed > if the versioning scheme changes, the new version may become newer. I > think that using 0 as version and putting the date in the release is > better, like > Version: 0 > Release: 0.X.20070911 > This has a disadvantage, namely when release changes, the version doesn't > change (similar with development snapshots). I agree with the problems of using the date. But as you noted, putting it in the release has its own problems. Upstream uses a date as the version number and is unlikely to change, so it seemed reasonable to be consistent with upstream. Is this critically important?
Okay, new version. I haven't changed the package name (per my comments above), but I did change other things (as noted above). New SRPM and spec file (release 5) here: http://www.dwheeler.com/zfuzz-20070911-5.fc9.src.rpm http://www.dwheeler.com/zfuzz.spec rpmlint clean. koji clean for all f9 architectures. Comments?
Sigh, release 5 had a bug; if zfuzz was already installed, it wouldn't always rebuild. Irrelevant in a mock build, but now it should work all the time. Since I had to fix it, I also added a patch that eliminated a compiler warning. New release 6 available here: http://www.dwheeler.com/zfuzz-20070911-6.fc9.src.rpm http://www.dwheeler.com/zfuzz.spec rpmlint, koji build clean on all architectures.
Any more reviewer comments? I've addressed every one posted above. The only ones I haven't done at all are using a different name and a different version numbering scheme, for reasons noted above. I'd like to think this is ready to go...
* it is not needed to put the name in the summary, I mean you can remove 'Z fuzz -' from the Summary. * Regarding the patch file names, I have a recommendation you can ignore, I use name like zfuzz-20070911-read-decl.patch to know in which version the patch was added. * regarding the version, if the versioning scheme was changed and the version became less recent that the latest date (the ordering is the ascii ordering), then you'll have to use an epoch. Not the end of the world but prone to easy errors when forgetting to specify the epoch in a version-release string. * regarding the name, having tex-zfuzz as a name really means that the name of the upstream software is zfuzz, but that it is a tex package. The fact that it is a tex package does not means that it is in a tex distribution (besides, I am quite sure that it could easily be incorporated in tex distributions). Users who knows that teh zfuzz package name is zfuzz and that it is a tex package should in fact expect that it is called tex-zfuzz. So naming it tex-zfuzz doesn't means that upstream choice is not honoured, but that honouring upstream choice in the fedora context means adding tex- in front. That being said, adding tex- in front of tex packages was agreed by the packaging commitee, it is in the guidelines: http://fedoraproject.org/wiki/PackagingNamingGuidelines#Addon_Packages_.28TeX.29 but it was also said that not having tex- was not a big deal so I would not considering it as a blocker, but I think that you should really take into account consistency with the remaining of the distribution and user expectations. For the sponsoring, could you please point me to other works you've done in fedora?
(In reply to comment #15) > Any more reviewer comments? I've addressed every one posted above. The only > ones I haven't done at all are using a different name and a different version > numbering scheme, for reasons noted above. > > I'd like to think this is ready to go... Never forget that fedora is volunteer based, so being patient is often necessary... But this also means that othere should be patient with you.
Here's a new version of the package, which I believe resolves all issues raised above: http://www.dwheeler.com/tex-zfuzz-7.09-7.fc9.src.rpm http://www.dwheeler.com/tex-zfuzz.spec rpmlint is clean on specs, SRPMs, and binary RPMs. koji builds on all dist-f9 architectures without error. Here are my responses to comment 16: >* it is not needed to put the name in the summary, I mean you can remove > 'Z fuzz -' from the Summary. Ok, done. >* Regarding the patch file names, I have a recommendation you can ignore, > I use name like zfuzz-20070911-read-decl.patch > to know in which version the patch was added. Sounds reasonable! Done. I know you said I could ignore it, but I did it anyway :-). >* regarding the version, if the versioning scheme was changed and the > version became less recent that the latest date (the ordering is the > ascii ordering), then you'll have to use an epoch. Not the end of the > world but prone to easy errors when forgetting to specify the epoch > in a version-release string. Yes, I know about epoch and its problems. But I don't like the idea of creating an arbitrary "1.0"; it doesn't convey any information, and if it were completely arbitrary and disconnected from upstream, other distributions might use a different version numbering system... leading to confusion. So here's my proposal: version numbering is of the form "(yyyy-2000).mm[dd]". Since this was released on 2007-09-11, this is version "7.09". Thus we have a normal-looking version number, yet one that easily syncs with upstream. Ubuntu uses this format, so it's not unknown in the world. >* regarding the name, having tex-zfuzz as a name really means that the > name of the upstream software is zfuzz, but that it is a tex package. > The fact that it is a tex package does not means that it is in a tex > distribution... Ah, okay. Package renamed to "tex-zfuzz". > For the sponsoring, could you please point me to other works you've > done in fedora? * I created and wrote the majority of the content of: http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo * I'm the upstream developer for two Fedora packages, sloccount and flawfinder I've done a lot of stuff related to Free-Libre / open source software that isn't Fedora-specific: * http://www.dwheeler.com/oss_fs_why.html "Why OSS/FS? Look at the Numbers!" had a major impact years ago. This was the first paper to show, through _quantitative_ studies, that FLOSS was worth considering. Basically, it's a survey of many different quantitative studies, and when it came out there was nothing like it. * http://www.dwheeler.com/essays/high-assurance-floss.html is a survey of FLOSS tools that can help high assurance * http://www.dwheeler.com/ has lots more. * I'm well-known in OSS circles; you can see some of my presentations (http://www.dwheeler.com/presentations.html). * Worse comes to worse, ask Bruce Perens, Eric Raymond, or Michael Tiemann; they can vouch for me. Does that help?
(In reply to comment #18) > >* regarding the version, if the versioning scheme was changed and the > > version became less recent that the latest date (the ordering is the > > ascii ordering), then you'll have to use an epoch. Not the end of the > > world but prone to easy errors when forgetting to specify the epoch > > in a version-release string. > > Yes, I know about epoch and its problems. But > I don't like the idea of creating an arbitrary "1.0"; it doesn't convey > any information, and if it were completely arbitrary and > disconnected from upstream, other distributions might use a different > version numbering system... leading to confusion. I don't propose 1.0 as version number, but a plain 0. That way any versioning scheme chosen later will be newer. It is still possible to switch to another scheme, for example to be consistent with what other distros do if 0 is chosen for now. The informative part would be in the release tag. > So here's my proposal: version numbering is of the form "(yyyy-2000).mm[dd]". > Since this was released on 2007-09-11, this is version "7.09". Thus we have > a normal-looking version number, yet one that easily syncs with upstream. > Ubuntu uses this format, so it's not unknown in the world. I don't really object to that, but I think that using a plain 0 and having the date in the release tag leaves more room for flexibility and allow any change. If you really don't like that 0, I won't make it blocking, however. I think I will submit this issue on the packaging list, it is not the first time something like that happens, and though I don't think it should be a guideline, some recommendations may be interesting. > > For the sponsoring, could you please point me to other works you've > > done in fedora? > > * I created and wrote the majority of the content of: > http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo Ok, I'll sponsor you, that's an interesting initiative.
>> here's my proposal: version numbering is of the form "(yyyy-2000).mm[dd]". >> Since this was released on 2007-09-11, this is version "7.09". Thus we have >> a normal-looking version number, yet one that easily syncs with upstream. >> Ubuntu uses this format, so it's not unknown in the world. >I don't really object to that, but I think that using a plain 0 >and having the date in the release tag leaves more room >for flexibility and allow any change. For the _first_ version number, "0" is doable, and it will allow us to wait a little while in case there's another/better approach that comes to light. So I'll update this package to use version "0" as its initial release. But version "0" is really just a useful delaying tactic. For the _next_ version it won't be obvious what the new value should be (other than "greater than 0"). Having it continuously "0" _works_, but it seems awkward for the long term. Sooner or later a "real" solution needs to be determined, one that "obviously works" across distributions. Otherwise, no one will be able to tell if (for example) the Debian and Fedora versions are the same, or they'll be hideously ugly. Some way of synchronizing version numbers seems like a good idea. >I think I will submit this issue on the packaging list, it is not the >first time something like that happens, and though I don't think it should >be a guideline, some recommendations may be interesting. I agree. I'm currently packaging minisat2, and it has the same problem - its "version number" is the release date. If you don't get a chance to post this version-date topic to the list within a day or so, I plan to post it. I'd definitely like to hear others' views about this, and maybe even get a rough consensus. Let me know if there's some reason I shouldn't do so. >Ok, I'll sponsor you, that's an interesting initiative. Excellent! Thanks.
(In reply to comment #20) > For the _first_ version number, "0" is doable, and it will allow us to > wait a little while in case there's another/better approach that comes to > light. So I'll update this package to use version "0" as its initial release. > > But version "0" is really just a useful delaying tactic. > For the _next_ version it won't be obvious what the > new value should be (other than "greater than 0"). Having it > continuously "0" _works_, but it seems awkward for the long term. > Sooner or later a "real" solution needs to be determined, > one that "obviously works" across distributions. > Otherwise, no one will be able to tell if (for example) the > Debian and Fedora versions are the same, or they'll be hideously ugly. > Some way of synchronizing version numbers seems like a good idea. Indeed, but point is that it is upstream who should be taken the lead here. It is just a workaround that leave us flexibility. Dates are, in my opinion, just as meaningless as 0 in any case. > I agree. I'm currently packaging minisat2, and it has the same problem - > its "version number" is the release date. > > If you don't get a chance to post this version-date topic > to the list within a day or so, I plan to post it. I'd definitely like to > hear others' views about this, and maybe even get a rough consensus. > Let me know if there's some reason I shouldn't do so. Go ahead. I think that the right list is the packaging list and not the devel list, for such issues the signal over noise is much better. If nobody cares, then the devel list could be used then.
Ah, a thought. If we're to have: > Version: 0 then instead of: > Release: 0.X.20070911 I suggest: > Release: 20070911.X%{?dist} (where "X" is the traditional release number.) That way, it sorts correctly; a 2008-based release will always be later than 2007. Sound reasonable?
BTW, I'm aware that https://fedoraproject.org/wiki/Packaging/NamingGuidelines has the "0.X.20070911" for 'pre-release' packages, but this isn't pre-release (or a snapshot, or post-release). The guidelines presume that everyone does "1.0" version formats. Anyway, let me know which you'd prefer: 1. 0.X.20070911 because it matches the pre-release format, or 2. 20070911.X%{?dist} because it sorts well, or 3. 0.20070911.X%{?dist} as a third alternative. And I'll put it that way.
2. tight you to a in-release scheme, 1. is the most flexible, but 3. is also possible, indeed, if the scheme changes, one can afterward use 1.7.09.X So I'd prefer 1. or 3., as you like.
Okay. Between 1 and 3 I'd prefer 3, because if the scheme NEVER changes, it will sort correctly into the indefinite future. So: 0.20070911.X%{?dist} it is. I'll add a comment line explaining it. I don't know of any other issues with the package, let me know if there are any.
* rpmlint is silent * follow guidelines * free software, license included. * match upstream 4e4d00d8571b14919f95f041a927f71b fuzzman-2up.pdf e3eb1467804bf4bf5b8dcf8eed773c69 fuzzman.pdf c3145cea9c6f16fb02e068fd1ea669a9 refcard-2up.pdf 082297daa993c97d8e35fb75f8bb2810 refcard-3up.pdf be69ba14a3b997bcde65828a34909e67 refcard.pdf 9f021c0e68f8f4616095f57ff2192c6f fuzz-2007-09-11.tar.gz * %files section right APPROVED Did you apply to sponsorship?
> Did you apply to sponsorship? Not sure what you mean. I used the FE-NEEDSPONSOR bug in bugzilla, and "applied" to the cvsextras group on the Fedora accounts system (which seems to know I don't have a sponsor). Do I need to do something else?
(In reply to comment #27) > and "applied" to the cvsextras group on the Fedora accounts system > (which seems to know I don't have a sponsor). That's what I meant. What is your account name?
(In reply to comment #28) My account name is "dwheeler".
Here's the package, same as the old one except that I redid the version/release numbering as noted above. Also, I shortened the "ChangeLog" considerably; I doubt anyone wants great detail about what happened before it entered the repository. I reset the release number to 1; this release number format is completely different (and incompatible) from the previous ones anyway, so we may as well start fresh at 1. SRPM and .spec file at: http://www.dwheeler.com/tex-zfuzz-0-0.20070911.1.fc9.src.rpm http://www.dwheeler.com/tex-zfuzz.spec rpmlint is clean on .spec, binary i386 RPM, _and_ SRPM. "koji build --scratch dist-f9" is clean on all 5 architectures. Did I misunderstand anything? Or see anything else that needs doing?
(In reply to comment #30) > Here's the package, same as the old one except that I redid the > version/release numbering as noted above. Also, I shortened the > "ChangeLog" considerably; I doubt anyone wants great detail about what > happened before it entered the repository. I prefer to have the full changelog, it also documents what was taken care of during the review. I won't make it a blocker, though. > I reset the release number to 1; > this release number format is completely different (and incompatible) > from the previous ones anyway, so we may as well start fresh at 1. Agreed. > SRPM and .spec file at: > http://www.dwheeler.com/tex-zfuzz-0-0.20070911.1.fc9.src.rpm > http://www.dwheeler.com/tex-zfuzz.spec > > rpmlint is clean on .spec, binary i386 RPM, _and_ SRPM. > "koji build --scratch dist-f9" is clean on all 5 architectures. > > Did I misunderstand anything? Or see anything else that needs doing? I have sponsored you. Just proceed with the cvs request. I already have approved the package by setting fedora-review to +.
New Package CVS Request ======================= Package Name: tex-zfuzz Short Description: Type-checker and LaTeX style for Z spec language Owners: dwheeler Branches: F-8 F-9 InitialCC: pertusus Cvsextras Commits: yes
cvs done.
Good news - I have CVS access. Bad news - I'm having trouble with the weird Fedora-unique CVS build process, and can't get my SRPM in. Any suggestions? I got set up using: ssh-add mkdir ~/cvs cd ~/cvs fedora-cvs tex-zfuzz cd tex-zfuzz All of that seemed to work fine. I did: ./common/cvs-import.sh ~/rpmbuild/SRPMS/tex-zfuzz-0-0.20070911.2.fc9.src.rpm ./common/cvs-import.sh -b F-9 ~/rpmbuild/SRPMS/tex-zfuzz-0-0.20070911.2.fc9.src.rpm This at least gave the APPEARANCE of working correctly, though I'm not sure if I was supposed to do separate imports for "default" and "F-9". But that's where the docs led me to go, and it didn't complain. Then I tried to do the following, where it seemed to hang: cd F-9/ make tag make build After both "make tag" and "make build", it hung after giving these error messages: rpmq: no arguments given for query rpmq: no arguments given for query In fact, even "make help" when my current directory was the "F-9" subdirectory produced those error messages, instead of something useful. The documentation on the interaction with Fedora CVS could at best be labelled "needs work" :-(. Suggestions?
(In reply to comment #34) > Bad news - I'm having trouble with the weird Fedora-unique CVS build process, > and can't get my SRPM in. Any suggestions? I had a package just accepted so I could try to reproduce, but it works for me. > This at least gave the APPEARANCE of working correctly, though I'm not sure if I > was supposed to do separate imports for "default" and "F-9". But that's where > the docs led me to go, and it didn't complain. Yes, you are supposed to do separate imports. > Then I tried to do the following, where it seemed to hang: > cd F-9/ > make tag > make build A possibility is that you didn't run cvs co prior from make tag, make build, and so the imports are not reflected in your working copy. > After both "make tag" and "make build", it hung after giving these > error messages: > rpmq: no arguments given for query > rpmq: no arguments given for query > > In fact, even "make help" when my current directory was the "F-9" subdirectory > produced those error messages, instead of something useful. The documentation > on the interaction with Fedora CVS could at best be labelled "needs work" :-(. The fedora docs are always in a needs work state since the build system, the auth system, the wiki... are always in a state of permanent change (with improvements most of the time, and sometime usability regressions but I don't think it is the case now).
tex-zfuzz-0-0.20070911.3.fc9 has been submitted as an update for Fedora 9
As you can see, I've submitted it. The big problem seems to be that the submission docs are out-of-sync with the scripts. "make tag" seems to be no longer necessary; tagging is part of the import. HOWEVER, the importing does _NOT_ update the local copy, which is weird. You have to do "cvs update" after the import. (You can tell this is necessary, because after the import, when you do "cvs update" you actually get updated files... a truly weird result!!!!) So, instead of: cd F-9/ make tag make build You need to do: cd F-9/ cvs up make build That is bizarre; "cvs up" should be part of the import!!!!
tex-zfuzz-0-0.20070911.3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
As you can see, this package has been pushed to "stable" on Fedora 9, and it will be in F-10. I have fixed the packaging documentation to note that import automatically does "make tag", and that you need to do "cvs up" after an import. I still think that the "cvs up" should be part of the import, but as long as it's documented it's a trivial inconvenient extra step. What causes trouble is when key steps are undocumented :-(.