Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 190247

Summary: Review Request: PyX - Python graphics package
Product: [Fedora] Fedora Reporter: Michael A. Peters <mpeters>
Component: Package ReviewAssignee: Jason Tibbitts <j>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-04 11:37:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779    

Description Michael A. Peters 2006-04-29 07:50:46 UTC
Spec URL:
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.

Comment 1 Michael A. Peters 2006-04-29 08:27:14 UTC
Known bug (blocker) - installing in a buildroot results in broken
pyx/ and pyx/siteconfig.pyc (includes the buildroot)

I'll see if I can fix this.

Comment 2 Michael A. Peters 2006-04-29 11:40:54 UTC
Problem solved:

Comment 3 Jason Tibbitts 2006-04-30 04:52:40 UTC
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
/usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../lib64/libkpathsea.a: could
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).

rpmlint complains:
E: PyX non-executable-script
/usr/lib/python2.4/site-packages/pyx/graph/axis/ 0644
(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/ 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:
   bfab7bbc4f3442c946f489133df515f0  manual.pdf
   bfab7bbc4f3442c946f489133df515f0  manual.pdf-srpm
   5e751cef8d62774a6fc659cc9a03c231  PyX-0.8.1.tar.gz
   5e751cef8d62774a6fc659cc9a03c231  PyX-0.8.1.tar.gz-srpm
* 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.

Comment 4 Michael A. Peters 2006-04-30 08:32:04 UTC
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:
New specfile:

Comment 5 Jason Tibbitts 2006-05-02 02:59:26 UTC
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.


Comment 6 Michael A. Peters 2006-05-04 11:37:05 UTC
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.