Bug 227333

Here is rpm-4.4.8 behavior:

    # rpmbuild --rebuild --force http://pmrb.free.fr/texlive/texlive.spm
    error: cannot open http://pmrb.free.fr/texlive/texlive.spm: Input/output error

The issue is that the server at the URI does not support OPTIONS header, and the error return
missed a reference count (iirc, another bugzilla bug for details).

No matter what, attempting to build from a remote srpm is, well, optimistic. Have fun!

UPSTREAM

Jeff, thanks for analysis. I agree that to build stuff directly from remote srpm
is a bit unusual, but rpm shouldn't segfault in that case anyway ;) So here I go
with a bug.

We agree, which is why I fixed the segfault ;-)

Someone ought to point out to TexLive that their advertised means of
using rpmbuild is unlikely to work anywhere, and that the extension *.spm is unconventional.

There are other problems with the texlive.spm SRPM, try
    rpm -qp --xml texlive.spm
which is triggering an assertion failure that I will sort through this evening.

And, if you're going to use an SRPM as a distribution format, ya really ought
to sign the *.src.rpm.

Bot "you" personally in my comments, but you (personally) might help improve texlive rpm packaging

Here's the assertion failure I see:

$ rpm -qp --xml texlive.spm 
rpmq: header.c:3489: singleSprintf: Assertion `tagN != ((void *)0)' failed.
Aborted

And this query is kinda unconventional (note off version) as well:

$ rpm -qp /tmp/texlive.spm 
texlive-3427-4.src.rpm

Digging now to find out which vendor's rpmbuild produced texlive.spm ...

Well, the texlive.spm is used just as an example. It's not created by me and I
have almost finished the TeXLive packaging based on texjive which is completely
different from the texlive.spm you see here (this one seems to be designed more
for SuSE/Novell distros) and pretty much matches the Fedora standards.

So you can use this only as a reproducer for the segfault, nothing more and
nothing less :)

The assertion failiure was a (lazy;-) fix to control for unidentified tag numbers
while displaying all metadate. A small fix to use snprintf instead shows

  Tag1051:
    - 5
    - 4
    - 3
    - 2
    - 1
    - 0
  Rpmversion: 4.1.1

Hmmm ... 4.1.1 is likely SuSE9 ...

Tag 1051 (if actually RPMTAG_NOSOURCE) should never ever be in headers (from rpmlib.h)

    RPMTAG_REQUIREVERSION       = 1050, /* s[] */
    RPMTAG_NOSOURCE             = 1051, /*!< internal */
    RPMTAG_NOPATCH              = 1052, /*!< internal */

And yes, rpm should not segfault. My rpm-4.4.8 does not, perhaps what other vendors are calling rpm 
does not segfault as well.

Have fun! I'm glad to see texlive getting packagaged. The doxygen doco in rpm and beecrypt is (or was) 
producing LaTeX, which broke in FC6+ in November because of some arcane ghostscript <-> LaTeX 
integration issue.

Here's a reproducer if you care (or just look at a beecrypt build):
Index: Doxyfile.in
===============================================================
====
RCS file: /cvs/devel/rpm/Doxyfile.in,v
retrieving revision 2.70.2.15
diff -u -b -B -w -p -r2.70.2.15 Doxyfile.in
--- Doxyfile.in 14 Jan 2007 21:11:18 -0000      2.70.2.15
+++ Doxyfile.in 5 Feb 2007 17:15:14 -0000
@@ -967,7 +967,7 @@ TREEVIEW_WIDTH         = 250
 # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 
 # generate Latex output.
 
-GENERATE_LATEX         = NO
+GENERATE_LATEX         = YES
 
 # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 
 # If a relative path is entered the value of OUTPUT_DIRECTORY will be 

*** Bug 221532 has been marked as a duplicate of this bug. ***

F7 and rawhide are not affected by this as they don't use neon transport, but
the missing refcount is now in rpm.org tree as well (thanks Jeff) and will be in
4.4.2.1 whether neon is used or not.