Bug 523877
| Summary: | Review Request: CBFlib - crystallography binary format library | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Fenn <tim.fenn> |
| Component: | Package Review | Assignee: | Dmitrij S. Kryzhevich <kryzhev> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | bloch, fedora-package-review, j, kryzhev, notting, richardfearn, supercyper1, susi.lehtola, tcallawa, t.matsuu |
| Target Milestone: | --- | Flags: | kryzhev:
fedora-review+
gwync: fedora-cvs+ |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | CBFlib-0.9.2.3-2.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-15 11:26:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 541462 | ||
|
Description
Tim Fenn
2009-09-17 00:37:10 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.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. (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. 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. *** Bug 545044 has been marked as a duplicate of this bug. *** 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. (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 ping? Who are you pinging? At least click the "Need additional information" box and specify someone. (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. (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! (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. 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. (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. (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. (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 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. (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. I find that CBFlib tarball bundled some external python modules(dREL-ply, PyCifRW, ply), maybe we should remove and package those modules separately. (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). (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" Is anyone still reviewing this package? Nobody has ever signed on to do a review. You're not using $RPM_OPT_FLAGS for the utilities. Did you add the soname yourself? (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. 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. (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 Let me see what I can do with this. Btw, remioved BuildFails as Comment 26 shows it builds. 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.5 Could it be resolved? 5. +1 to -lib subpackage. 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. You can mail legal.org with details of the license. (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. 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/ 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 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. 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. OK, I spoke with Takanori - I'll maintain this package with him as co-maintainer. The build in comment 33 is "review ready." ping Dmitrij? Pong. Sorry, my bad. Somehow missed comment 36. I'm here. 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)
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 (-) 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.
(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 Ok. Aproved, New Package SCM Request ======================= Package Name: CBFlib Short Description: crystallography binary format library Owners: timfenn Branches: f15 f16 el6 InitialCC: timfenn Git done (by process-git-requests). git done, packages tagged/built for f15/f16/el6/rawhide. OK to close? 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 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 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 CBFlib-0.9.2.3-2.el6 has been pushed to the Fedora EPEL 6 testing repository. CBFlib-0.9.2.3-2.fc15 has been pushed to the Fedora 15 stable repository. CBFlib-0.9.2.3-2.fc16 has been pushed to the Fedora 16 stable repository. CBFlib-0.9.2.3-2.el6 has been pushed to the Fedora EPEL 6 stable repository. Package Change Request ====================== Package Name: CBFlib New Branches: epel7 Owners: timfenn InitialCC: timfenn Git done (by process-git-requests). |