The PGPLOT Graphics Subroutine Library is a Fortran- or C-callable, device-independent graphics package for making simple scientific graphs. It is intended for making graphical images of publication quality with minimum effort on the part of the user. For most applications, the program can be device-independent, and the output can be directed to the appropriate device at run time. This library is used in the academic world to create plots. It's license is "freely available for non-commercial use" so I think it could go to the nonfree repo. http://guaix.fis.ucm.es/~spr/pgplot.spec http://guaix.fis.ucm.es/~spr/pgplot-5.2.2-23.fc9.src.rpm
I'll review this package. But the first things you definitely need to do are explaining (in the SPEC file as comments) where Source1-2 and Patches 0-7 come from and what they are for. Also, if they are not strictly-Fedora-specific, please supply (in the SPEC file as comments) the links from upstream's bug tracking system where the patches are submitted. Thanks.
Well, pgplot is unmaintained. I can't send my patches to anyone. My only interest in packaging this software is that there exist lots of applications that use this library and rpm & yum make the life of the scientists installing this a lot more easier. The rpm package is also old and there are things that can be made a lot better now. A bunch of the patches were to enable different drivers. I have modified the spec to use sed instead. One of the two extra sources was a set of documents and images extracted from the webpage, I have removed them. The other source was a set of m4 macros to detect pgplot and cpgplot. I have substituted it with pkg-config macros, I think that are a lot better to maintain and write (I did never understand m4...) Here are my updated files: http://guaix.fis.ucm.es/~spr/pgplot.spec http://guaix.fis.ucm.es/~spr/pgplot-5.2.2-23.fc9.src.rpm Thanks, Sergio
Hi again, I saw this notice on the pgplot website: http://www.astro.caltech.edu/~tjp/pgplot/#copyright Copyright PGPLOT is not public-domain software. However, it is freely available for non-commercial use. The source code and documentation are copyrighted by California Institute of Technology, and may not be redistributed or placed on public Web servers without permission. The software is provided ``as is'' with no warranty. As far as I understood, we need permission from CalTech to redistribute pgplot. What kind of a permission do we have?
I saw the copyright.notice file in the original tarball. Please ignore the previous message. The package is in good shape. Let us go through a few minor things: * rpmlint says: pgplot.x86_64: E: non-standard-executable-perm /usr/lib64/libcpgplot.so.5.2.2 0775 pgplot.x86_64: E: non-standard-executable-perm /usr/lib64/libpgplot.so.5.2.2 0775 pgplot-tk.x86_64: E: non-standard-executable-perm /usr/lib64/libtkpgplot.so.5.2.2 0775 These need fixed (to 755) * Please package the Changelog files. If you want, you can concatenate them with something like (for i in $(find . -name "ver*.txt" |sort -r); do cat $i; done) > ChangeLog * We prefer defattr(-,root,root,-) * Please make use of macros extensively and consistenly, especially the %{name} macro, also e.g. %{__rm} -rf %{buildroot} in one line and rm -fr %{buildroot} on the other breaks consistency. ! Parallel make must be supported whenever possible. Write a comment on the spec file if parallel make is not supported. See: http://fedoraproject.org/wiki/Packaging/Guidelines#Parallel_make * Don't we need to put the copyright notice to all the subpackages, as is told by the copyright notice itself? * You are supplying external .pc files. I don't understand why you're editing (sed'ding) them again. * Everything that is in the %build section until the "./makemake" line should be moved into %prep . * Definitions such as %define lvfull 5.2.2 %define lvmajor 5 are usually put to the very beginning of the SPEC file. At least, somewhere closer to the Version tag. By the way, %{version} = %{lvfull} = 5.2.2 . Why are you defining the same thing twice? I think you should do something like: %define lvmajor 5 Name: pgplot Version: 5.2.2 ... and then use %{version} below instead of %{lvfull}. * The tcl conventions have changed in Fedora 9. Please follow: http://fedoraproject.org/wiki/Packaging/Tcl see naming, installation locations etc.
Before submitting a new version, I would like to comment a few things: * I edit the pkgconfig file templates because they have the libdir harcoded. Depending on whether we are compiling in 32 or 64 bits we have to write /usr/lib or /usr/lib64 inside the files. * I'm not quite sure that the tcl guidelines apply here. What pgplot provides is a driver that a allows to embed the plots in tcl applications, but only using a C interface. This means that a supposed tcl/pgplot application has to be linked with the libtkpgplot.so library. Hence, the library has to be installed in %{libdir} so that it can be found at runtime (or we have to make a link from %{libdir}/tcl8/pgplot/libtkpgplot.so.* to %{libdir}). Notice that pgplot doesn't provide a pkgIndex.tcl and I think that means that pgplot can't be used from inside tcl/tk directly. Regards
(In reply to comment #5) > Before submitting a new version, I would like to comment a few things: > > * I edit the pkgconfig file templates because they have the libdir harcoded. > Depending on whether we are compiling in 32 or 64 bits we have to write > /usr/lib or /usr/lib64 inside the files. > I see that you are just inserting the %{_libdir} macro evaluated. I think it is fine then. > * I'm not quite sure that the tcl guidelines apply here. What pgplot provides > is a driver that a allows to embed the plots in tcl applications, but only > using a C interface. > This means that a supposed tcl/pgplot application has to be linked with the > libtkpgplot.so library. Hence, the library has to be installed in %{libdir} so > that it can be found at runtime (or we have to make a link from > %{libdir}/tcl8/pgplot/libtkpgplot.so.* to %{libdir}). > Notice that pgplot doesn't provide a pkgIndex.tcl and I think that means that > pgplot can't be used from inside tcl/tk directly. > > > Regards > I read this paragraph on the guidelines (towards the bottom): arch-specific packages can be generally grouped into three categories: those that provide a shell, those that provide a fooConfig.sh file and a shared library for linking, and those that only provide a shared library for dlopen(). OK, you might be right (I am -kind of- ignorant when it comes to tcl/tk), but doesn't this package belong to the third category ? And, then why are you explicitly requiring tk? rpmbuild picks some tcl/tk dependencies by itself. Aren't those enough? Please explain.
Well, I think this new package fixes all the issues in comment #4 http://guaix.fis.ucm.es/~spr/pgplot.spec http://guaix.fis.ucm.es/~spr/pgplot-5.2.2-25.fc9.src.rpm Regarding tcl, I have patched the driver to provide some information needed by the tck package system and a new file (pkgIndex.tcl) has to be installed in $libdir/tcl8.5/pgplot Regards
Thank you, I have two last things to ask. * Doesn't this clause from the TCL guidelines apply for this package: "If the extension does not provide a fooConfig.sh file, then the shared library must not be installed directly in %{_libdir} , but in the package-specific installation directory in %{tcl_sitearch} instead. This may require a patch to update the extension's pkgIndex.tcl file to look for the shared library in the correct location." * Whenever we provide "something" we tend to give as much information as possible, e.g. EVR. I think for the Provides in tcl* packages you should add "-%{release}" to the end. This isn't a rule but rather a general convention.
(In reply to comment #8) > Thank you, > I have two last things to ask. > > * Doesn't this clause from the TCL guidelines apply for this package: Well, no. The fooConfig.sh of this package is missing (as was missing the pkgIndex.tcl). The file tk-pgplot.pc provides the same funcionallity in a much more clean way. > > * Whenever we provide "something" we tend to give as much information as > possible, e.g. EVR. > I think for the Provides in tcl* packages you should add "-%{release}" to the > end. This isn't a rule but rather a general convention. > Done, this is the new spec: http://guaix.fis.ucm.es/~spr/pgplot.spec http://guaix.fis.ucm.es/~spr/pgplot-5.2.2-26.fc9.src.rpm
(In reply to comment #9) > (In reply to comment #8) > > Thank you, > > I have two last things to ask. > > > > * Doesn't this clause from the TCL guidelines apply for this package: > > Well, no. The fooConfig.sh of this package is missing (as was missing the > pkgIndex.tcl). The file tk-pgplot.pc provides the same funcionallity in a much > more clean way. > That's where I get confused. It says when the fooConfig.sh is missing the shared library must *not* be installed in %{_libdir}, but right now it *is* installed in %{_libdir} . Where is the catch?
The guidelines presume that the tcl package is properly constructed. A properly constructed tcl package that provides a libdir library usually has a fooConfig.sh file that instructs how to compile against the library. If the package doesn't provide fooConfig.sh one can assume that the library is a plugin not designed to be used directly with programs. But the pgplot driver isn't a properly constructed package. It misses pkgIndex.tcl (and I had to add it). In fact, I needed to patch the source code to include a function that informs tcl that is a tcl package. But libtkpgplot.so is used as a libdir library. One of the examples in the tarball is pgtkdemo. You can check in the makefile that this file is linked with the libtkpgplot.a
I see now. Thanks for taking care of everything. You may ask for CVS now. ------------------------------------------------------------ This package pglot is APPROVED for rpmfusion-nonfree by oget ------------------------------------------------------------ 26 is a number that I like as a string theorist. I think it is a good release number for such a package. :)
> ------------------------------------------------------------ > This package pglot is APPROVED for rpmfusion-nonfree by oget > ------------------------------------------------------------ > I consistently make the same mistake for some unknown reason. To the CVS person: The package is called *pgplot* , not pglot.
For astrophysicists, 42 is a good number also :) Thanks Orcan! Package CVS request ====================== Package Name: pgpplot Short Description: Graphic library for making simple scientific graphs Owners: sergiopr Branches: F-10 F-9 InitialCC: ---------------------- License tag: nonfree
cvs done. note that f-10 branch is not yet available.
> Package Name: pgpplot That was one p too many. ;-)
Built in devel and in F-9
Since there is no component pgplot in Bugzilla yet, let me add a current issue here: When running an application making use of PGPLOT and choosing output device /XWINDOW, no output will happen unless pgxwin_server* has been launched in advance by the user. Instead, the following error message is displayed: "Graphics device/type (? to see list, default /xwin): PGPLOT /xw: Couldn't find program "pgxwin_server" in the directory named PGPLOT /xw: in your PGPLOT_DIR environment variable, or in any directory PGPLOT /xw: listed in your PATH environment variable." This behaviour can be avoided by ensuring that pgxwin_server is found in the current PATH. Traditionally, figdisp* and pgxwin_server* used to live in /usr/bin/ or similar. In this case, they are launched automatically, e.g. when pgdemo1 is invoked. Currently, only /usr/libexec/pgplot/pgxwin_server is provided by pgplot-5.2.2-27.fc10, but this choice does not do the job unless /usr/libexec/pgplot is added to PATH explicitly.
Well, this pgplot is patched to look for pgxwin_server in /usr/libexec/pgplot Your program is compiled statically or dynamically?
Looks like it doesn not work either way: a. All demo executables /usr/bin/pgdemo?* are not linked dynamically against the pgplot library. Yet, above error message appears. b. Some self-built test executable is dynamically linked against the (c)gpgplot libraries, ldd ./test | grep pg libcpgplot.so.5 => /usr/lib64/libcpgplot.so.5 (0x0000000000110000) libpgplot.so.5 => /usr/lib64/libpgplot.so.5 (0x0000000002bb5000) but in this case, the same error message is issued, too.
I'm closing the bug, now there's a pgplot component in bugzilla. Please resubmit this in a new bug report.
Package Change Request ====================== Package Name: pgplot New Branches: EL-5
(In reply to comment #22) > Package Change Request > ====================== > Package Name: pgplot > New Branches: EL-5 done
Package Change Request ====================== Package Name: pgplot New Branches: EL-6