Red Hat Bugzilla – Bug 190247
Review Request: PyX - Python graphics package
Last modified: 2007-11-30 17:11:31 EST
Spec URL: http://mpeters.us/PyX/PyX.spec
SRPM URL: http://mpeters.us/PyX/PyX-0.8.1-1.fc5.src.rpm
PyX is a Python package for the creation of PostScript and PDF files. It
combines an abstraction of the PostScript drawing model with a TeX/LaTeX
interface. Complex tasks like 2d and 3d plots in publication-ready quality are
built out of these primitives.
Known bug (blocker) - installing in a buildroot results in broken
pyx/siteconfig.py and pyx/siteconfig.pyc (includes the buildroot)
I'll see if I can fix this.
FYI, theres an open ticket for the mkhowto issue:
PyChart is working around it by including a copy of Python's Doc directory. I
see no problems with simply shipping the formatted manual from upstream, but you
should probably treat it as any other upstream source and provide a full URL.
The build fails on x86_64 (both FC5 and development):
gcc -pthread -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
build/temp.linux-x86_64-2.4/pyx/pykpathsea/pykpathsea.o -lkpathsea -o
relocation R_X86_64_32S against `kpse_format_info' can not be used when making a
shared object; recompile with -fPIC
not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
error: Bad exit status from /var/tmp/rpm-tmp.12911 (%build)
I'm afraid I have no idea at all what that means, except for "recompile with
-fPIC", and -fPIC already on all of the gcc command lines so I assume it's
complaining about /usr/lib644/libkpathsea.a. A quick search leads to
Anyway, it builds fine on i386, so you'll need to ExcludeArch: x86_64 at least
(no way to test PPC, sorry) and then open a bug on the failed x86_64 build and
have it block FE-ExcludeArch-x64 (and have 150085 block it).
E: PyX non-executable-script
(and 41 additional complaints about other files)
These files all contain #!/blah/python lines. Those scripts aren't intended to
be executable, so those shebang lines need to be removed. Note that they aren't
consistent; graph/axis/timeaxis.py is the only .py file not to have such a line.
This is the only blocker that I can see.
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* license field matches the actual license.
* license is open source-compatible and included in the package.
* source files match upstream:
* latest version is being packaged.
* BuildRequires are proper.
O package builds in mock (development, i386) but fails on x86_64.
X rpmlint complains about errant shebang lines in all but one .py file.
* final provides and requires are sane.
* shared libraries are present, but internal to python so no need to call ldconfig.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* .pyo files are properly %ghosted.
* %clean is present.
* %check is not present; no test suite.
* code, not content.
* documentation is not exactly small, but not large enough that a -docs
subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
Note on documentation - full path url is in comment about Source1
I changed the name of the source for the src.rpm because the upstream filename
was way to generic - manual.pdf
I have fixed the rpmlint error - the way I fixed it was simply to run sed on all
non executable .py scripts and change ^#! to ##
Is that acceptable or would refer the enture shebang lines just be removed?
I think I have temporarily fixed it for x86_64 by simply not building the
kpathsea C extension for x86_64 - the kpathsea part of the package should still
work on x86_64, just with a performance hit.
New src.rpm: http://mpeters.us/PyX/PyX-0.8.1-4.fc5.src.rpm
New specfile: http://mpeters.us/PyX/PyX.spec
This is much better. The package builds OK on i386 and x86_64 and rpmlint is
I understand about the manual; generally we name things the way they come from
upstream, but in this case upstream isn't even versioned so you might not get
what you expect when you fetch the file. Hopefully 177349 will be fixed one of
these days and this issue will go away.
I don't have a preference for fixing the shebang lines; If I were doing it I'd
probably delete them, but the main goal here is to quiet rpmlint.
I'm glad you were able to work around 150085 without sacrificing functionality.
Been through build system for FC-4/FC-5
fails on devel due to broken devel build system
closing as next-release, I'll recue for devel when I've seen other compiled
packages get through devel build system.