Bug 523877 - Review Request: CBFlib - crystallography binary format library
Summary: Review Request: CBFlib - crystallography binary format library
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dmitrij S. Kryzhevich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 545044 (view as bug list)
Depends On:
Blocks: 541462
TreeView+ depends on / blocked
 
Reported: 2009-09-17 00:37 UTC by Tim Fenn
Modified: 2014-10-01 09:46 UTC (History)
10 users (show)

Fixed In Version: CBFlib-0.9.2.3-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-15 11:26:41 UTC
kryzhev: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Tim Fenn 2009-09-17 00:37:10 UTC
Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.8.1-1.fc10.src.rpm
Description: 
CBFlib (Crystallographic Binary File library) is a library of ANSI-C
functions providing a simple mechanism for accessing Crystallographic
Binary Files (CBF files) and Image-supporting CIF (imgCIF) files. The
CBFlib API is loosely based on the CIFPARSE API for mmCIF files. Like
CIFPARSE, CBFlib does not perform any semantic integrity checks;
rather it simply provides functions to create, read, modify and write
CBF binary data files and imgCIF ASCII data files.

also see:

http://www.bernstein-plus-sons.com/software/CBF/

note: there isn't any autotools support for this package at the moment, I'm working on some patches for upstream to accomplish this.

Comment 1 Jason Tibbitts 2009-09-23 22:15:46 UTC
Legal folks, skip down a bit.

This builds fine; here's what rpmlint says:

  CBFlib.x86_64: W: shared-lib-calls-exit /usr/lib64/libcbf.so.0.0.0 
   exit@GLIBC_2.2.5
Not a problem.

  CBFlib-devel.x86_64: W: hidden-file-or-dir
   /usr/share/doc/CBFlib-devel-0.8.1/doc/.symlinks
  CBFlib-devel.x86_64: W: spurious-executable-perm
   /usr/share/doc/CBFlib-devel-0.8.1/doc/.symlinks
  CBFlib-devel.x86_64: W: hidden-file-or-dir
   /usr/share/doc/CBFlib-devel-0.8.1/doc/.undosymlinks
  CBFlib-devel.x86_64: W: spurious-executable-perm
   /usr/share/doc/CBFlib-devel-0.8.1/doc/.undosymlinks
Any idea what these are for?  Is there any reason to ship them in the package?

  CBFlib-devel.x86_64: W: file-not-utf8
   /usr/share/doc/CBFlib-devel-0.8.1/doc/cif_img_1.5.3_8Jul07.dic
Lines 2046 and 2099 contain degree symbols and an a ringed A, respectively.  A pass through iconv -f iso8859-15 -t utf-8 fixes this up.

  CBFlib.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libfcb.so.0.0.0 
   /lib64/libm.so.6
  CBFlib.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libfcb.so.0.0.0 
   /lib64/libgcc_s.so.1
Neither of these is a particularly big deal.

The licensing situation is a bit complicated.  Indeed, everything is GPLv2+, but some of it is also LGPLv2+.  That would give a license tag of "GPLv2+ and (GPLv2+ or LGPLv2+)" but you also need to indicate which parts of the code are under which license.  The documentation says that you can distribute the cbflib API under the LGPL, but honestly I'm not sure what they consider to be the API.  There's also some truly public domain code in there, though I doubt the compiled result preserves any of it uncombined with GPL code.

There's also a potentially troubling notice in some code:

 *                           The IUCr Policy                          *
 *      for the Protection and the Promotion of the STAR File and     *
 *     CIF Standards for Exchanging and Archiving Electronic Data     *
 *                                                                    *
 * Overview                                                           *
 *                                                                    *
 * The Crystallographic Information File (CIF)[1] is a standard for   *
 * information interchange promulgated by the International Union of  *
 * Crystallography (IUCr). CIF (Hall, Allen & Brown, 1991) is the     *
 * recommended method for submitting publications to Acta             *
 * Crystallographica Section C and reports of crystal structure       *
 * determinations to other sections of Acta Crystallographica         *
 * and many other journals. The syntax of a CIF is a subset of the    *
 * more general STAR File[2] format. The CIF and STAR File approaches *
 * are used increasingly in the structural sciences for data exchange *
 * and archiving, and are having a significant influence on these     *
 * activities in other fields.                                        *
 *                                                                    *
 * Statement of intent                                                *
 *                                                                    *
 * The IUCr's interest in the STAR File is as a general data          *
 * interchange standard for science, and its interest in the CIF,     *
 * a conformant derivative of the STAR File, is as a concise data     *
 * exchange and archival standard for crystallography and structural  *
 * science.                                                           *
 *                                                                    *
 * Protection of the standards                                        *
 *                                                                    *
 * To protect the STAR File and the CIF as standards for              *
 * interchanging and archiving electronic data, the IUCr, on behalf   *
 * of the scientific community,                                       *
 *                                                                    *
 * * holds the copyrights on the standards themselves,                *
 *                                                                    *
 * * owns the associated trademarks and service marks, and            *
 *                                                                    *
 * * holds a patent on the STAR File.                                 *
 *                                                                    *
 * These intellectual property rights relate solely to the            *
 * interchange formats, not to the data contained therein, nor to     *
 * the software used in the generation, access or manipulation of     *
 * the data.                                                          *
 *                                                                    *
 * Promotion of the standards                                         *
 *                                                                    *
 * The sole requirement that the IUCr, in its protective role,        *
 * imposes on software purporting to process STAR File or CIF data    *
 * is that the following conditions be met prior to sale or           *
 * distribution.                                                      *
 *                                                                    *
 * * Software claiming to read files written to either the STAR       *
 * File or the CIF standard must be able to extract the pertinent     *
 * data from a file conformant to the STAR File syntax, or the CIF    *
 * syntax, respectively.                                              *
 *                                                                    *
 * * Software claiming to write files in either the STAR File, or     *
 * the CIF, standard must produce files that are conformant to the    *
 * STAR File syntax, or the CIF syntax, respectively.                 *
 *                                                                    *
 * * Software claiming to read definitions from a specific data       *
 * dictionary approved by the IUCr must be able to extract any        *
 * pertinent definition which is conformant to the dictionary         *
 * definition language (DDL)[3] associated with that dictionary.      *
 *                                                                    *
 * The IUCr, through its Committee on CIF Standards, will assist      *
 * any developer to verify that software meets these conformance      *
 * conditions.                                                        *
 *                                                                    *
 * Glossary of terms                                                  *
 *                                                                    *
 * [1] CIF:  is a data file conformant to the file syntax defined     *
 * at http://www.iucr.org/iucr-top/cif/spec/index.html                *
 *                                                                    *
 * [2] STAR File:  is a data file conformant to the file syntax       *
 * defined at http://www.iucr.org/iucr-top/cif/spec/star/index.html   *
 *                                                                    *
 * [3] DDL:  is a language used in a data dictionary to define data   *
 * items in terms of "attributes". Dictionaries currently approved    *
 * by the IUCr, and the DDL versions used to construct these          *
 * dictionaries, are listed at                                        *
 * http://www.iucr.org/iucr-top/cif/spec/ddl/index.html               *
 *                                                                    *
 * Last modified: 30 September 2000                                   *
 *                                                                    *
 * IUCr Policy Copyright (C) 2000 International Union of              *
 * Crystallography                                                    *

This actually seems to be somewhat common-sense; if you wish to make the claim that you can read or parse certain files, you must actually be able to do so.  We're used to dealing with things like this in the form of trademarks, but I'm not sure what we do when patents on the file format are involved.  Blocking FE-Legal for guidance.

Comment 2 Tim Fenn 2009-09-24 23:07:33 UTC
(In reply to comment #1)
> 
> The licensing situation is a bit complicated.  Indeed, everything is GPLv2+,
> but some of it is also LGPLv2+.  That would give a license tag of "GPLv2+ and
> (GPLv2+ or LGPLv2+)" but you also need to indicate which parts of the code are
> under which license.  The documentation says that you can distribute the cbflib
> API under the LGPL, but honestly I'm not sure what they consider to be the API.
>  There's also some truly public domain code in there, though I doubt the
> compiled result preserves any of it uncombined with GPL code.
> 

I've notified upstream and received clarification (anything in the src/ folder is LGPLv2+, everything else is GPLv2+), and asked later versions of the package to differentiate this a bit better.

> There's also a potentially troubling notice in some code:
> 

I've also brought this up with upstream, hopefully they can provide information as needed for the fedora legal folks if necessary.

Comment 3 Tom "spot" Callaway 2009-12-01 00:45:13 UTC
I'm pretty sure that license is non-free, but I'll run it past Red Hat Legal.

Assuming I'm wrong, we'd definitely need for the IUCr to give us an unrestricted patent grant that applies to us and all possible users and downstream users/modifiers/distributors.

Comment 4 Susi Lehtola 2009-12-09 12:30:47 UTC
*** Bug 545044 has been marked as a duplicate of this bug. ***

Comment 5 Tom "spot" Callaway 2009-12-09 15:55:57 UTC
Hey, even I'm wrong sometimes. :)

This isn't really a license, this is actually a patent grant. The maintainer of this Fedora package should be careful to ensure that they do not apply patches which would cause this software to be out of compliance with the STAR/CIF data format standards (even though the copyright license permits it), because we would no longer have permission to use the patent(s).

Lifting FE-Legal.

Comment 6 Tim Fenn 2009-12-09 20:04:45 UTC
(In reply to comment #5)
> 
> This isn't really a license, this is actually a patent grant. The maintainer of
> this Fedora package should be careful to ensure that they do not apply patches
> which would cause this software to be out of compliance with the STAR/CIF data
> format standards (even though the copyright license permits it), because we
> would no longer have permission to use the patent(s).
> 
> Lifting FE-Legal.  

I'll do my best - if there is anything additional to make note of anywhere, let me know.

Here's a version with most of the above comments/suggestions taken into account:

Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.8.1-2.fc12.src.rpm

Comment 7 Chen Lei 2010-03-05 13:49:11 UTC
ping?

Comment 8 Jason Tibbitts 2010-03-05 14:53:48 UTC
Who are you pinging?  At least click the "Need additional information" box and specify someone.

Comment 9 Chen Lei 2010-03-06 03:18:16 UTC
(In reply to comment #8)
> Who are you pinging?  At least click the "Need additional information" box and
> specify someone.    

Oh sorry, next time I'll be more specfic. I ping Tim - the reporter of this bugzilla. I want to review this package since I'm also a rasmol user.

Comment 10 Tim Fenn 2010-03-06 22:21:00 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Who are you pinging?  At least click the "Need additional information" box and
> > specify someone.    
> 
> Oh sorry, next time I'll be more specfic. I ping Tim - the reporter of this
> bugzilla. I want to review this package since I'm also a rasmol user.    

Feel free to help review and provide suggestions for the package - I'd like to see it officially approved for fedora!

Comment 11 Chen Lei 2010-03-08 12:40:59 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Who are you pinging?  At least click the "Need additional information" box and
> > > specify someone.    
> > 
> > Oh sorry, next time I'll be more specfic. I ping Tim - the reporter of this
> > bugzilla. I want to review this package since I'm also a rasmol user.    
> Feel free to help review and provide suggestions for the package - I'd like to
> see it officially approved for fedora!    

I recommand you split out two more subpackages, cbflib-utils and cbflib-doc. 

See http://packages.debian.org/source/squeeze/cbflib
Also cbflib 0.9 now was released already.

Comment 12 Tim Fenn 2010-03-08 21:42:53 UTC
Here's the updated 0.9.0 version:

Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.0-1.fc12.src.rpm

I also included some of the bin programs, but I'm wondering if it would be best to prepend "cbf" to them, as names like "convert_image" are a bit ambiguous and potentially conflicting.

I didn't split off -doc and -utils, I'd like to get some feedback from fedora review people on that.

Comment 13 Chen Lei 2010-03-09 03:39:28 UTC
(In reply to comment #12)
> Here's the updated 0.9.0 version:
> Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
> SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.0-1.fc12.src.rpm
> I also included some of the bin programs, but I'm wondering if it would be best
> to prepend "cbf" to them, as names like "convert_image" are a bit ambiguous and
> potentially conflicting.
> I didn't split off -doc and -utils, I'd like to get some feedback from fedora
> review people on that.    

Please do not add utils to main package, it'll lead to multilib conflict.

Comment 14 Tim Fenn 2010-03-10 02:11:46 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Here's the updated 0.9.0 version:
> > Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
> > SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.0-1.fc12.src.rpm
> > I also included some of the bin programs, but I'm wondering if it would be best
> > to prepend "cbf" to them, as names like "convert_image" are a bit ambiguous and
> > potentially conflicting.
> > I didn't split off -doc and -utils, I'd like to get some feedback from fedora
> > review people on that.    
> 
> Please do not add utils to main package, it'll lead to multilib conflict.    

How will it lead to a multilib conflict? Its fine to install both the 32 and 64 bit binaries and libraries and run/use either.

Comment 15 Chen Lei 2010-03-11 05:58:52 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Here's the updated 0.9.0 version:
> > > Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
> > > SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.0-1.fc12.src.rpm
> > > I also included some of the bin programs, but I'm wondering if it would be best
> > > to prepend "cbf" to them, as names like "convert_image" are a bit ambiguous and
> > > potentially conflicting.
> > > I didn't split off -doc and -utils, I'd like to get some feedback from fedora
> > > review people on that.    
> > 
> > Please do not add utils to main package, it'll lead to multilib conflict.    
> How will it lead to a multilib conflict? Its fine to install both the 32 and 64
> bit binaries and libraries and run/use either.    

Hi Tim,

See http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#Splitting_libraries_into_separate_packages

Comment 16 Michael Schwendt 2010-03-11 06:13:07 UTC
Take that with a grain of salt, please. It's a draft and not a mandatory item in the guidelines. Ordinary binary executables don't cause multilib conflicts. Tim is right about that.

Further, there's a conditional: *If* you have a file conflict in a library package due to other files in the same package, splitting of the libs into their own package *may* help. Doing that doesn't prevent all multiarch problems, though, such as conflicts in the -devel package.

Comment 17 Chen Lei 2010-03-11 06:39:38 UTC
(In reply to comment #16)
> Take that with a grain of salt, please. It's a draft and not a mandatory item
> in the guidelines. Ordinary binary executables don't cause multilib conflicts.
> Tim is right about that.
> Further, there's a conditional: *If* you have a file conflict in a library
> package due to other files in the same package, splitting of the libs into
> their own package *may* help. Doing that doesn't prevent all multiarch
> problems, though, such as conflicts in the -devel package.    

You are right Michael, this is not a mandatory item in reviewing a package. We should be lenient with multilib conflicts if the package mainly act as a program such as qt-creator.

Howerver, the main role of CBFlib is act as a dynamic lib, the programs included in the CBFlib are only utilities. So I think we should be careful with multilib conflicts in CBFlib, it's easy to split out a -utils subpackage.

Comment 18 Chen Lei 2010-03-11 08:32:36 UTC
I find that CBFlib tarball bundled some external python modules(dREL-ply, PyCifRW, ply), maybe we should remove and package those modules separately.

Comment 19 Tim Fenn 2010-03-12 02:34:29 UTC
(In reply to comment #18)
> I find that CBFlib tarball bundled some external python modules(dREL-ply,
> PyCifRW, ply), maybe we should remove and package those modules separately.    

I'm not bothering with any of the python stuff with cbflib, and I don't plan to unless there is a strong demand/need for it (which I don't forsee).

Comment 20 Chen Lei 2010-03-12 04:02:57 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > I find that CBFlib tarball bundled some external python modules(dREL-ply,
> > PyCifRW, ply), maybe we should remove and package those modules separately.    
> I'm not bothering with any of the python stuff with cbflib, and I don't plan to
> unless there is a strong demand/need for it (which I don't forsee).    

OK, but I still recommand you split -doc and -utils subpackage. CBFlib has a lot of documentation in it and  both doc and html_graphics dirs need to be included in -doc subpackage. Also, The gpl.txt should not move out of doc dir, 

grep gpl\.txt CBFlib.html

CBFlib.html:<b>YOU MAY REDISTRIBUTE THE CBFLIB PACKAGE UNDER THE TERMS OF THE <a href=gpl.txt>GPL</a>.

grep \.jpg index.html

<img alt="[IUCr Home Page]" src="../html_graphics/iucrhome.jpg" ALIGN=MIDDLE></a>
<img alt="[CIF Home Page]" src="../html_graphics/cifhome.jpg" ALIGN=MIDDLE></a>
<a href="cbf_definition_rev.html"><IMG SRC="../html_graphics/CBFbutton.jpg"
<a href="CBFlib.html"><IMG SRC="../html_graphics/cbflibbutton.jpg"

Comment 21 Tim Fenn 2010-07-06 00:16:31 UTC
Is anyone still reviewing this package?

Comment 22 Jason Tibbitts 2010-07-06 04:14:01 UTC
Nobody has ever signed on to do a review.

Comment 23 Susi Lehtola 2010-08-25 05:47:42 UTC
You're not using $RPM_OPT_FLAGS for the utilities.

Did you add the soname yourself?

Comment 24 Tim Fenn 2010-08-26 03:06:10 UTC
(In reply to comment #23)
> You're not using $RPM_OPT_FLAGS for the utilities.
> 
> Did you add the soname yourself?

Yes - there is no autoconf/automake support for the package, unfortunately. So I simply assigned an soname of 0.

Comment 25 Jason Tibbitts 2010-11-03 16:50:22 UTC
This fails to build for me on rawhide:

+ gcc convert_image.c -I../include ../src/libcbf.so.0.0.0 -o convert_image
/tmp/ccg58RIq.o: In function `main':
convert_image.c:(.text+0x1483): warning: the use of `mktemp' is dangerous, better use `mkstemp'
/usr/bin/ld: /tmp/ccg58RIq.o: undefined reference to symbol 'rint@@GLIBC_2.2.5'
/usr/bin/ld: note: 'rint@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line
/lib64/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

A scratch build showing the failure: http://koji.fedoraproject.org/koji/taskinfo?taskID=2574534

Please clear the whiteboard if providing a package which builds.

Comment 26 Tim Fenn 2010-11-15 03:04:35 UTC
(In reply to comment #25)
> 
> A scratch build showing the failure:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2574534
> 
> Please clear the whiteboard if providing a package which builds.

fixed/updated:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2601008

Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.1-1.fc14.src.rpm

Comment 27 Dmitrij S. Kryzhevich 2010-12-09 13:07:45 UTC
Let me see what I can do with this.

Btw, remioved BuildFails as Comment 26 shows it builds.

Comment 28 Dmitrij S. Kryzhevich 2010-12-09 13:31:54 UTC
1. What with License? "GPLv2+ and (GPLv2+ or LGPLv2+)" is rather strange one. May be it should be just "GPLv2+ and LGPLv2+"?
2. For clearity, split "iconv" string into 2, uniting them with "\".
3. Looks like everybody wants it's own copy of md5. Ok. Let it be so.
4. rpmlint claims on
shared-lib-calls-exit /usr/lib64/libcbf.so.0.0.0 exit@GLIBC_2.2.5
Could it be resolved?
5. +1 to -lib subpackage.

Comment 29 tjyuviaej 2011-01-06 04:04:09 UTC
drel.py is called at the line 8471 in src/cbf.c (line number from 0.9.1.1rc2 tarball). And drel.py (src/drel.py) python script imports CifFile and StarFile which are provided by PyCifRW.

I'm afraid that this means CBFlib requires PyCifRW which has a unique license.

I have a private package for PyCifRW and can submit it for package preview.
However I don't know how to request the assessment of new licenses.

Comment 30 Jason Tibbitts 2011-01-06 12:57:46 UTC
You can mail legal@lists.fedoraproject.org with details of the license.

Comment 31 Tim Fenn 2011-01-07 19:03:10 UTC
(In reply to comment #29)
> drel.py is called at the line 8471 in src/cbf.c (line number from 0.9.1.1rc2
> tarball). And drel.py (src/drel.py) python script imports CifFile and StarFile
> which are provided by PyCifRW.
> 
> I'm afraid that this means CBFlib requires PyCifRW which has a unique license.
> 
> I have a private package for PyCifRW and can submit it for package preview.
> However I don't know how to request the assessment of new licenses.

Ah, I hadn't noticed the internal system calls to python - Ugh.

OK, this will have to go on hold until the dependence on PyCifRW is removed or we can add it as a dependency.  tjyuviaej - let me know if you need assistance submitting/requesting PyCifRW as a package.

Comment 32 Takanori MATSUURA 2011-01-13 09:24:59 UTC
After the discussion at legal ML, current PyCifRW is not free and not acceptable by Fedora.

I'll try to the following approach.
* Ask developer of PyCifRW to change license to Fedora-acceptable free one.
* Ask developer of CBFlib that he can remove the dependency of PyCifRW.

I already prepared PyCifRW package and I can request a package preview if PyCifRW is released with free license.

If anyone interests PyCifRW package, please visit my repoview page at
http://t-matsuu.sakura.ne.jp/install-memo/fedora/

Comment 33 Tim Fenn 2011-07-05 22:38:31 UTC
Talked with upstream, pycifrw is no longer required.  I've updated the builds here:

Spec URL: http://www.stanford.edu/~fenn/packs/CBFlib.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/CBFlib-0.9.2.2-1.fc15.src.rpm

Comment 34 Takanori MATSUURA 2011-07-06 14:10:28 UTC
Just for information.
My CBFlib package is available from
Spec file: http://t-matsuu.sakura.ne.jp/mock/CBFlib/CBFlib.spec
SRPM file: http://t-matsuu.sakura.ne.jp/mock/CBFlib/CBFlib-0.9.2.2-1.fc15.src.rpm

The build procedure is based on upstream Makefile with modifications.

%check section is now disabled because the process requires modified version of libtiff which has not been upstreamed yet.

If you are interested in my spec file, please freely use it.

Comment 35 Tim Fenn 2011-07-06 20:45:18 UTC
Takanori, since you're also interested in PyCIFRW, would you like to take the lead on this package?  I'd be glad to help co-maintain, if/when it gets through package review.

(In reply to comment #34)
> Just for information.
> My CBFlib package is available from
> Spec file: http://t-matsuu.sakura.ne.jp/mock/CBFlib/CBFlib.spec
> SRPM file:
> http://t-matsuu.sakura.ne.jp/mock/CBFlib/CBFlib-0.9.2.2-1.fc15.src.rpm
> 
> The build procedure is based on upstream Makefile with modifications.
> 
> %check section is now disabled because the process requires modified version of
> libtiff which has not been upstreamed yet.
> 
> If you are interested in my spec file, please freely use it.

Comment 36 Tim Fenn 2011-07-12 00:51:23 UTC
OK, I spoke with Takanori - I'll maintain this package with him as co-maintainer.  The build in comment 33 is "review ready."

Comment 37 Susi Lehtola 2011-12-16 10:13:04 UTC
ping Dmitrij?

Comment 38 Dmitrij S. Kryzhevich 2011-12-19 03:40:54 UTC
Pong.

Sorry, my bad. Somehow missed comment 36.
I'm here.

Comment 39 Dmitrij S. Kryzhevich 2011-12-22 04:44:26 UTC
1) Are you sure that doc is under GPL2 (%files section, -devel)?
2) Two adscimg2cbf in %files
3) You still wants utils (which are from examples btw) in main CBF_lib_ package but not to do CBFlib-utils subpackage. Just tell me you realy insist on it.
4) cbf.c contain two exit calls (both are memory allocation error) that going to shared library. Could it be easy handled? I suppose "no" but still. It is not a blocker.
5) Typo in %changelog: first string contain "0.9.2.1-1" but not "0.9.2.2-1".
6) Please use %{optflags} and %{buildroot}.
7) gpl.txt is to be in doc dir. Do not move it, you could copy it if you want it in root. (%doc doc/gpl.txt will work)

Comment 40 Tim Fenn 2011-12-30 23:56:34 UTC
Sorry for my late reply, holidays and what not.

(In reply to comment #39)
> 1) Are you sure that doc is under GPL2 (%files section, -devel)?

Yes - this was discussed with upstream in Sept. 2009 (!) - all the API calls are LGPLv2+, all else is GPLv2+.

> 2) Two adscimg2cbf in %files

fixed

> 3) You still wants utils (which are from examples btw) in main CBF_lib_ package
> but not to do CBFlib-utils subpackage. Just tell me you realy insist on it.

see comments 12-16 (unless something changed recently?)

> 4) cbf.c contain two exit calls (both are memory allocation error) that going
> to shared library. Could it be easy handled? I suppose "no" but still. It is
> not a blocker.

I'll mention this to upstream and suggest some ideas and try to get this handled by the author(s).

> 5) Typo in %changelog: first string contain "0.9.2.1-1" but not "0.9.2.2-1".

fixed

> 6) Please use %{optflags} and %{buildroot}.

done

> 7) gpl.txt is to be in doc dir. Do not move it, you could copy it if you want
> it in root. (%doc doc/gpl.txt will work)

fixed

http://sites.google.com/site/timfenn/CBFlib.spec
http://sites.google.com/site/timfenn/CBFlib-0.9.2.3-1.fc16.src.rpm

Comment 41 Dmitrij S. Kryzhevich 2012-01-23 09:56:39 UTC
(-) rpmlint output:
CBFlib-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/CBFlib-0.9.2.3/examples/cbf2adscimg.c
CBFlib-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/CBFlib-0.9.2.3/examples/cbf2adscimg_sub.c

Need to fix permissions.

(+) Name ok.
(+) Spec ok.
(+) The package meets the Packaging Guidelines.
(+) License ok.
(+) Sources are matched upstream ones.
(+) The package was compiled on at least on x86_64, ok.
(+) Package post (un)install scrips call ldconfig.
(+) Package owns its directories, not owns others.
(+) %files section ok 

(-) Permissions are not set properly.

Fix permissions for debuginfo package. 
 
(+/-) Devel package contain all needed .so and headers, it has Requires: %{name} = %{version}-%{release} string.

Goudelines ask "Requires: %{name}%{?_isa} = %{version}-%{release}".
 
Fix that isues - and I'l close review.

Comment 42 Tim Fenn 2012-01-30 04:12:19 UTC
(In reply to comment #41)
> (-) rpmlint output:
> CBFlib-debuginfo.x86_64: W: spurious-executable-perm
> /usr/src/debug/CBFlib-0.9.2.3/examples/cbf2adscimg.c
> CBFlib-debuginfo.x86_64: W: spurious-executable-perm
> /usr/src/debug/CBFlib-0.9.2.3/examples/cbf2adscimg_sub.c
> 
> Need to fix permissions.
> 

Fixed.

> 
> (+/-) Devel package contain all needed .so and headers, it has Requires:
> %{name} = %{version}-%{release} string.
> 
> Goudelines ask "Requires: %{name}%{?_isa} = %{version}-%{release}".
> 
> Fix that isues - and I'l close review.

Done.

http://sites.google.com/site/timfenn/CBFlib.spec
http://sites.google.com/site/timfenn/CBFlib-0.9.2.3-2.fc16.src.rpm

Comment 43 Dmitrij S. Kryzhevich 2012-01-30 04:56:30 UTC
Ok.

Aproved,

Comment 44 Tim Fenn 2012-02-01 03:26:57 UTC
New Package SCM Request
=======================
Package Name: CBFlib
Short Description: crystallography binary format library
Owners: timfenn
Branches: f15 f16 el6
InitialCC: timfenn

Comment 45 Gwyn Ciesla 2012-02-01 13:21:11 UTC
Git done (by process-git-requests).

Comment 46 Tim Fenn 2012-02-04 22:13:08 UTC
git done, packages tagged/built for f15/f16/el6/rawhide.

OK to close?

Comment 47 Fedora Update System 2012-02-04 22:15:40 UTC
CBFlib-0.9.2.3-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/CBFlib-0.9.2.3-2.fc15

Comment 48 Fedora Update System 2012-02-04 22:15:51 UTC
CBFlib-0.9.2.3-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/CBFlib-0.9.2.3-2.el6

Comment 49 Fedora Update System 2012-02-04 22:16:00 UTC
CBFlib-0.9.2.3-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/CBFlib-0.9.2.3-2.fc16

Comment 50 Fedora Update System 2012-02-05 19:31:55 UTC
CBFlib-0.9.2.3-2.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 51 Fedora Update System 2012-02-15 11:26:41 UTC
CBFlib-0.9.2.3-2.fc15 has been pushed to the Fedora 15 stable repository.

Comment 52 Fedora Update System 2012-02-15 11:30:02 UTC
CBFlib-0.9.2.3-2.fc16 has been pushed to the Fedora 16 stable repository.

Comment 53 Fedora Update System 2012-02-20 19:01:41 UTC
CBFlib-0.9.2.3-2.el6 has been pushed to the Fedora EPEL 6 stable repository.

Comment 54 Tim Fenn 2014-10-01 01:54:41 UTC
Package Change Request
======================
Package Name: CBFlib
New Branches: epel7
Owners: timfenn
InitialCC: timfenn

Comment 55 Gwyn Ciesla 2014-10-01 09:46:14 UTC
Git done (by process-git-requests).


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