Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452559 - Review Request: tex-zfuzz - Type-checker and LaTeX style for Z spec language
Summary: Review Request: tex-zfuzz - Type-checker and LaTeX style for Z spec language
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Patrice Dumas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-23 18:17 UTC by David A. Wheeler
Modified: 2008-07-26 13:52 UTC (History)
3 users (show)

Fixed In Version: 0-0.20070911.3.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-15 12:22:19 UTC
pertusus: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description David A. Wheeler 2008-06-23 18:17:12 UTC
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".

Comment 1 David A. Wheeler 2008-06-23 18:19:26 UTC
NOTE: This is my first Fedora package, and I am seeking a sponsor!



Comment 2 David A. Wheeler 2008-06-23 18:23:53 UTC
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.


Comment 3 Jason Tibbitts 2008-06-23 19:42:04 UTC
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?

Comment 4 David A. Wheeler 2008-06-24 02:34:08 UTC
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.


Comment 5 David A. Wheeler 2008-06-24 04:44:06 UTC
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.




Comment 6 Jason Tibbitts 2008-06-24 17:00:16 UTC
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.

Comment 7 David A. Wheeler 2008-06-25 19:30:38 UTC
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.


Comment 8 Patrice Dumas 2008-06-25 20:10:13 UTC
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.

Comment 9 David A. Wheeler 2008-06-25 22:14:29 UTC
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.



Comment 10 David A. Wheeler 2008-06-25 22:33:28 UTC
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" :-).



Comment 11 Patrice Dumas 2008-06-25 22:44:03 UTC
(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...



Comment 12 David A. Wheeler 2008-06-26 00:04:43 UTC
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?



Comment 13 David A. Wheeler 2008-06-26 00:13:02 UTC
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?


Comment 14 David A. Wheeler 2008-06-26 02:13:23 UTC
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.


Comment 15 David A. Wheeler 2008-06-26 19:31:43 UTC
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...


Comment 16 Patrice Dumas 2008-06-27 17:14:12 UTC
* 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?

Comment 17 Patrice Dumas 2008-06-27 17:15:38 UTC
(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.



Comment 18 David A. Wheeler 2008-06-27 19:13:53 UTC
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?


Comment 19 Patrice Dumas 2008-06-27 22:26:41 UTC
(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.


Comment 20 David A. Wheeler 2008-06-28 21:45:03 UTC
>> 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.



Comment 21 Patrice Dumas 2008-06-28 21:59:47 UTC
(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.



Comment 22 David A. Wheeler 2008-06-29 02:53:40 UTC
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?


Comment 23 David A. Wheeler 2008-06-29 03:06:22 UTC
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.



Comment 24 Patrice Dumas 2008-06-29 08:11:35 UTC
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.

Comment 25 David A. Wheeler 2008-06-29 18:28:02 UTC
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.


Comment 26 Patrice Dumas 2008-06-29 18:35:58 UTC
* 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?

Comment 27 David A. Wheeler 2008-06-29 21:50:40 UTC
> 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?



Comment 28 Patrice Dumas 2008-06-29 22:25:32 UTC
(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?


Comment 29 David A. Wheeler 2008-06-30 03:51:06 UTC
(In reply to comment #28)

My account name is "dwheeler".



Comment 30 David A. Wheeler 2008-06-30 04:23:22 UTC
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?



Comment 31 Patrice Dumas 2008-06-30 21:09:36 UTC
(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 +.

Comment 32 David A. Wheeler 2008-07-01 03:00:51 UTC
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



Comment 33 Kevin Fenzi 2008-07-01 16:53:14 UTC
cvs done.

Comment 34 David A. Wheeler 2008-07-02 02:33:28 UTC
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?


Comment 35 Patrice Dumas 2008-07-06 07:55:42 UTC
(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). 

Comment 36 Fedora Update System 2008-07-10 21:40:53 UTC
tex-zfuzz-0-0.20070911.3.fc9 has been submitted as an update for Fedora 9

Comment 37 David A. Wheeler 2008-07-10 21:48:56 UTC
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!!!!


Comment 38 Fedora Update System 2008-07-15 12:22:17 UTC
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.

Comment 39 Fedora Update System 2008-07-26 06:11:40 UTC
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.

Comment 40 David A. Wheeler 2008-07-26 13:52:40 UTC
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 :-(.



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