Sorry for not including this in the original description, but the koji build for EPEL 6 can be found here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5515092
And for EPEL 5 it can be found here (yes, and I used the .el6 source rpm just for ease):
http://koji.fedoraproject.org/koji/taskinfo?taskID=5515098

Hi Dave!

Here are some remarks/recommendations/improvement about the spec-file.  This applies to your ascending/blocked pkgs, too:

  * Your links are not direct linking.  You should upload them to somewhere
    direct linking is possible.  If you don't have own webspace for this, you
    possibly want to follow the instructions given here:
    http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Upload_Your_Package
    After your request got approved, upload spec/srpm to there and update the
    Spec/SRPM URL-Tag in your bugs, please.

  * There are lots of obsolete BRs is the spec.  Remove them, please, so the
    spec-file focusses on the real, additionally needed ones.  See:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2

  * doc-subpkg explicitly requires main-pkg.  This should not be the case,
    because the docs don't need binaries.  Usually someone wants to read
    the docs BEFORE installing the software.

  * For the above reason LICENSE should be packaged withing doc-subpkg, too.
    According to the guidelines this is OK.  See:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Duplicate_Files

  * %defattr(-,root,root,-) is obsoleted and was only needed on rpm < 4.4.
    Even el5 shippes a more recent version of rpm.  See:
    https://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions

Cheers,
  Björn

* Run "rpmlint -I" on all packages, the src.rpm *and* the built rpms. Apply fixes for obvious errors/warnings, ignore false positives, preferably comment on what rpmlint reports.


> Name:           libcutl
> Group:          Development/Libraries

Rather "System Environment/Libraries" for base library packages, since those contain run-time libs as opposed to -devel packages.


> License:        Boost

This needs a closer look, because the file LICENSE contains the MIT terms, and several source files mention MIT licensing, too.


> # Other BuildRequires from auto-buildrequires
> # NOTE: The Packaging Guidelines say that some of these can be exclude, but just
> # keep them here because it's easy and then they're include for completeness

Hmmm, I'm certain lots of reviewers would insist on having you remove these. Saying "it's easy" isn't convincing, because it's even easier to not list anything expected to be available within the minimum build environment:
http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2


> %package        doc
> Requires:       %{name}%{?_isa} = %{version}-%{release}

Separate documentation -doc packages typically don't require the base package. It should be possible to install documentation without having to install a program and all its dependencies.


> %files
> %{_libdir}/*.so

The *.so symlink belongs into the -devel package, because typically it's only needed/used when building software:
http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

There are only few exceptions where external programs would dlopen a library via the non-versioned symlink (expect a few symbols only) and could not be patched to open the versioned lib instead.


> %files devel
> %{_includedir}/cutl/*

Directory /usr/include/cutl is not included.

http://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
http://fedoraproject.org/wiki/Packaging:UnownedDirectories


> %files doc
> %{_datadir}/doc/libcutl/*

Directory /usr/share/doc/libcutl is not included.

Further, the size of the libcutl-doc package is 5496 bytes. Unless large API docs are missing, I wouldn't split off these few and tiny files into a separate -doc package, but include them within the base package.
http://fedoraproject.org/wiki/Packaging:Guidelines#Documentation

$ rpmls -p libcutl-doc-1.7.1-1.fc19.x86_64.rpm 
-rw-r--r--  /usr/share/doc/libcutl/INSTALL
-rw-r--r--  /usr/share/doc/libcutl/LICENSE
-rw-r--r--  /usr/share/doc/libcutl/NEWS
-rw-r--r--  /usr/share/doc/libcutl/README
-rw-r--r--  /usr/share/doc/libcutl/version

> > License:        Boost
>
> This needs a closer look, because the file LICENSE contains the MIT terms, and > several source files mention MIT licensing, too.

Here is the situation: most of the code in libcutl is MIT-licensed. However, also included is a small subset of Boost (essentially the Boost regex library), which is under the Boost license. While this is done to minimize dependencies, it is possible to ignore the internal Boost subset in libcutl and instead use the external libboost_regex library (the --with-external-boost configure option).

I tend to think that the RPM should be built with the --with-external-boost option and then the license can probably be changed to MIT.

Alternatively, the license should probably be MIT/Boost (the terms of these two licenses are very similar).

Unblocking FE-NEEDSPONSOR - I've just sponsored Dave.

The updated files can be found at:
Spec URL: http://daveisfera.fedorapeople.org/odb_2.2/specs/libcutl.spec
SRPM URL: http://daveisfera.fedorapeople.org/odb_2.2/SRPMS/libcutl-1.7.1-1.fc19.src.rpm

OK, this is a lot of info, but here's all of the comments and the response. Hopefully, it's organized well enough to be readable/manageable.

>  * Your links are not direct linking.  You should upload them to somewhere
>    direct linking is possible.  If you don't have own webspace for this, you
>    possibly want to follow the instructions given here:
>    http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Upload_Your_Package
>    After your request got approved, upload spec/srpm to there and update the
>    Spec/SRPM URL-Tag in your bugs, please.

I tried following those instructions, but they appear to be outdated and the link goes to Trac page that doesn't appear related to setting up hosting. Now, that I'm sponsored, I put them in my fedorapeople.org location, but what's the proper instructions? I wouldn't mind updating the instructions if I knew what the right answer was.


>  * There are lots of obsolete BRs is the spec.  Remove them, please, so the
>    spec-file focusses on the real, additionally needed ones.  See:
>    https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2

Fixed, but it still lists binutils, glibc-common, net-tools and pkgconfig because auto-buildrequires recommended them. Should I include those? Or just remove them?


>  * doc-subpkg explicitly requires main-pkg.  This should not be the case,
>    because the docs don't need binaries.  Usually someone wants to read
>    the docs BEFORE installing the software.

Removed doc subpkg and included it with the main package based on other feedback.


>  * For the above reason LICENSE should be packaged withing doc-subpkg, too.
>    According to the guidelines this is OK.  See:
>    https://fedoraproject.org/wiki/Packaging/Guidelines#Duplicate_Files

N/A based on removal of doc subpkg.


>  * %defattr(-,root,root,-) is obsoleted and was only needed on rpm < 4.4.
>    Even el5 shippes a more recent version of rpm.  See:
>    https://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions

Fixed. Sorry I read this in the guidelines before submitting, but it just didn't click that I needed to remove that line. Could this check be added to rpmlint?


> * Run "rpmlint -I" on all packages, the src.rpm *and* the built rpms. Apply fixes for obvious errors/warnings, ignore false positives, preferably comment on what rpmlint reports.

Did this and the only warnings now are about the spelling of "runtime" which appears to be a valid spelling ( http://en.wikipedia.org/wiki/Runtime_library ). Is it ok to just ignore these warnings and leave the text as is because that's how it appear upstream? If so, then is it possible to get "runtime" added as a valid spelling in the check that rpmlint does?


> Rather "System Environment/Libraries" for base library packages, since those contain run-time libs as opposed to -devel packages.

Fixed.


> This needs a closer look, because the file LICENSE contains the MIT terms, and several source files mention MIT licensing, too.

Now built with --with-external-boost so that it doesn't use the Boost code that is used when external Boost is not used and the license is just MIT as the .spec file now states. The source rpm also includes a patch to remove the mention of the boost code/license from the LICENSE file that is included as documentation.


> Hmmm, I'm certain lots of reviewers would insist on having you remove these. Saying "it's easy" isn't convincing, because it's even easier to not list anything expected to be available within the minimum build environment:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

Fixed based on previous feedback.


> Separate documentation -doc packages typically don't require the base package. It should be possible to install documentation without having to install a program and all its dependencies.

Removed -doc packages based on other feedback.


> The *.so symlink belongs into the -devel package, because typically it's only needed/used when building software:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

> There are only few exceptions where external programs would dlopen a library via the non-versioned symlink (expect a few symbols only) and could not be patched to open the versioned lib instead.

Fixed


> Directory /usr/include/cutl is not included.

> http://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
> http://fedoraproject.org/wiki/Packaging:UnownedDirectories

Based on those two sites, my understanding was that the issue was that the directories could become orphaned, so I believe that I have fixed this now by including them in the files section. Please let me know if there's something else/more that I need to do for this.


> Further, the size of the libcutl-doc package is 5496 bytes. Unless large API docs are missing, I wouldn't split off these few and tiny files into a separate -doc package, but include them within the base package.
> http://fedoraproject.org/wiki/Packaging:Guidelines#Documentation

Included the documentation in the base package and removed the doc subpkg. I removed all of the files that I thought were unnecessary (INSTALL, README, version) and then added NEWS as the %doc of the -devel packages. This seemed like the idea that most closely matched my understanding of the packaging guidelines, but please let me know if I should change it further.

Ok, this looks good to me. However I found another one issue - you listed header files twice in the %files section of a *-devel subpackage. Please replace

%{_includedir}/cutl/
%{_includedir}/cutl/*

with 

%{_includedir}/cutl/

Apart fro that everything is ok. so here is my formal

REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is silent

sulaco ~/rpmbuild/SPECS: rpmlint ../RPMS/ppc/libcutl-* ../SRPMS/libcutl-1.7.1-1.fc20.src.rpm 
4 packages and 0 specfiles checked; 0 errors, 0 warnings.
sulaco ~/rpmbuild/SPECS: 

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (MIT).
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.

sulaco ~/rpmbuild/SOURCES: sha256sum libcutl-1.7.1.tar.bz2*
2b712ff82c8be878bbb77bde767b6775dfbbf4b141ac63de4a2a2437a5cc18af  libcutl-1.7.1.tar.bz2
2b712ff82c8be878bbb77bde767b6775dfbbf4b141ac63de4a2a2437a5cc18af  libcutl-1.7.1.tar.bz2.1
sulaco ~/rpmbuild/SOURCES:

+ The package successfully compiles and builds into binary rpms on at least one primary architecture.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
+ The package stores shared library files in some of the dynamic linker's default paths, and it calls ldconfig in %post and %postun.
+ The package does NOT bundle copies of system libraries.
0 The package is not designed to be relocatable.
+ The package owns all directories that it creates.

- The package must NOT list a file more than once in the spec file's %files listings. See my comment above.

+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
+ Header files are stored in a -devel package.
0 No static libraries.
+ The pkgconfig(.pc) files are stored in a -devel package (necessary runtime requirement picked up automatically).
+ The devel library file(s) is(are) stored in a -devel package.
+ The -devel package requires the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.

Please fix the only remaining issue before uploading to Fedora Git. This package is


APPROVED.

> I tried following those instructions, but they appear to be outdated
> and the link goes to Trac page that doesn't appear related to setting
> up hosting.

Hmmm, what makes you think so?


> but what's the proper instructions?

They are accurate:

| you can request sufficient access to use fedorapeople space
| by visiting the sponsors trac instance and filing a ticket in
| the "Initial package hosting request" component. 

https://fedorahosted.org/packager-sponsors/
 -> https://fedorahosted.org/packager-sponsors/newticket
   -> Component "Initial package hosting request"


> binutils, glibc-common, net-tools and pkgconfig because
> auto-buildrequires recommended them. Should I include those?

You should drop
 * binutils, because it's required by gcc and rpm-build
 * glibc-common, because it's required by glibc, which is too essential

> pkgconfig

That's a valid BuildRequires.

> net-tools

Unusual. But what is it used for during the build?


Peter wrote:

> %{_includedir}/cutl/
> %{_includedir}/cutl/*
> 
> with 
> 
> %{_includedir}/cutl/

That's related to what I've pointed out before. Before my comment, there
only was /usr/include/cutl/* which didn't include the directory
/usr/include/cutl 

I recommend revisiting the
  http://fedoraproject.org/wiki/Packaging:UnownedDirectories#Common_Mistakes
page section, because it explains this in detail. If those instructions aren't
enough, please tell what is unclear.

Dave, ping!

> > I tried following those instructions, but they appear to be outdated
> > and the link goes to Trac page that doesn't appear related to setting
> > up hosting.
>
> Hmmm, what makes you think so?
>
>
> > but what's the proper instructions?
>
> They are accurate:
>
> | you can request sufficient access to use fedorapeople space
> | by visiting the sponsors trac instance and filing a ticket in
> | the "Initial package hosting request" component.
>
> https://fedorahosted.org/packager-sponsors/
>  -> https://fedorahosted.org/packager-sponsors/newticket
>    -> Component "Initial package hosting request"

Sorry! I guess that I didn't read the last part of the last line well enough or something, because I was expecting there to be instructions on the linked to wiki. Stupid user error on my part.


> > binutils, glibc-common, net-tools and pkgconfig because
> > auto-buildrequires recommended them. Should I include those?

> You should drop
>  * binutils, because it's required by gcc and rpm-build
>  * glibc-common, because it's required by glibc, which is too essential

Fixed

> > net-tools
 
> Unusual. But what is it used for during the build?

That was just listed in the auto-buildrequires output when I ran it on CentOS 6. When I just re-ran auto-buildrequires on Fedora 19, it didn't list it, so I just removed it.


> > %{_includedir}/cutl/
> > %{_includedir}/cutl/*
> >
> > with
> >
> > %{_includedir}/cutl/
>
> That's related to what I've pointed out before. Before my comment, there
> only was /usr/include/cutl/* which didn't include the directory
> /usr/include/cutl
>
> I recommend revisiting the
>   http://fedoraproject.org/wiki/Packaging:UnownedDirectories#Common_Mistakes
> page section, because it explains this in detail. If those instructions aren't
> enough, please tell what is unclear.

Sorry again! Another dumb mistake on my part. I read the first part and saw that I needed to added the line to include the directory, so I did that. I guess I didn't read the rest of that section well enough and didn't realize that including the directory also included the contents, so I fixed that now.

New Package SCM Request
=======================
Package Name: libcutl
Short Description: C++ utility library from Code Synthesis
Owners: daveisfera
Branches: f18 f19 el5 el6
InitialCC: peter

What's the approval/submission process for the rest of the odb/libodb packages?
Do I need to add that template to each of the Bugzilla's for the packages? Or can I add all of the packages in a single request?

Also, I posted a comment about an rpmlint warning against the odb package in that bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=975310

I asked this question before, but just to make sure it's covered, here is is again:
In the libodb packages, rpmlint outputs that "runtime" is a spelling error in the source rpms. It appears that's a valid spelling ( http://en.wikipedia.org/wiki/Runtime_library ), so can those warnings be safely ignored? Also, is it possible/ok to try and get this added as a valid spelling in the check that rpmlint does?

Git done (by process-git-requests).

I just submitted the package using fedpkg and the build was successful on Fedora 18-20 and EL 6, but on ppc for EL 5 it failed with the following error for the ppc build ( http://koji.fedoraproject.org/koji/getfile?taskID=5654037&name=build.log ):

checking if we should use external boost... yes
checking for boost base headers... yes
checking for boost regex library... no
checking for boost system library... no
configure: error: boost regex is not found; consider using CPPFLAGS/LDFLAGS or --with-boost=DIR to specify its location
error: Bad exit status from /var/tmp/rpm-tmp.39047 (%build)
    Bad exit status from /var/tmp/rpm-tmp.39047 (%build)

It looks like the Boost headers are there but that the Boost regex and system libraries are either not there or the check is incorrectly returning "no".

Is this an issue with in the spec file and EL 5? Or is there something else going on with the system side of things that is causing this issue?

I think you can drop support for EL5.

For better or worse, I still work on systems that use RHEL 5 and would like to get the support working there as well.

[For some reason my earlier email reply never made it]

To understand what's going on here, we need to look into the config.log file generated by configure and see what C++ compiler/linker errors are there for the boost regex (and boost system) tests. Dave, if you can email me or attach this file, I can take a look.

Here are the available outputs from the build process:

  http://koji.fedoraproject.org/koji/getfile?taskID=5654037&name=build.log
  http://koji.fedoraproject.org/koji/getfile?taskID=5654037&name=mock_output.log
  http://koji.fedoraproject.org/koji/getfile?taskID=5654037&name=root.log
  http://koji.fedoraproject.org/koji/getfile?taskID=5654037&name=state.log

If that's not enough, then I'll see if I can reproduce this issue on RHEL 5 for x86 because I don't have access to PowerPC hardware.

It looks like it might be a problem with the Boost packages on EL 5. Here's the root.log from the PowerPC build on EL 6 and it shows all the boost packages being installed:

http://koji.fedoraproject.org/koji/getfile?taskID=5654025&name=root.log

DEBUG util.py:264:  Getting requirements for libcutl-1.7.1-1.el6.src
DEBUG util.py:264:   --> boost-devel-1.41.0-17.el6_4.ppc64
DEBUG util.py:264:   --> Already installed : 1:pkgconfig-0.23-9.1.el6.ppc64
DEBUG util.py:264:  ================================================================================
DEBUG util.py:264:   Package                    Arch       Version                 Repository  Size
DEBUG util.py:264:  ================================================================================
DEBUG util.py:264:  Installing:
DEBUG util.py:264:   boost-devel                ppc64      1.41.0-17.el6_4         build      5.3 M
DEBUG util.py:264:  Installing for dependencies:
DEBUG util.py:264:   boost                      ppc64      1.41.0-17.el6_4         build       18 k
DEBUG util.py:264:   boost-date-time            ppc64      1.41.0-17.el6_4         build       39 k
DEBUG util.py:264:   boost-filesystem           ppc64      1.41.0-17.el6_4         build       45 k
DEBUG util.py:264:   boost-graph                ppc64      1.41.0-17.el6_4         build       78 k
DEBUG util.py:264:   boost-iostreams            ppc64      1.41.0-17.el6_4         build       38 k
DEBUG util.py:264:   boost-program-options      ppc64      1.41.0-17.el6_4         build      109 k
DEBUG util.py:264:   boost-python               ppc64      1.41.0-17.el6_4         build      122 k
DEBUG util.py:264:   boost-regex                ppc64      1.41.0-17.el6_4         build      465 k
DEBUG util.py:264:   boost-serialization        ppc64      1.41.0-17.el6_4         build      246 k
DEBUG util.py:264:   boost-signals              ppc64      1.41.0-17.el6_4         build       46 k
DEBUG util.py:264:   boost-system               ppc64      1.41.0-17.el6_4         build       24 k
DEBUG util.py:264:   boost-test                 ppc64      1.41.0-17.el6_4         build      380 k
DEBUG util.py:264:   boost-thread               ppc64      1.41.0-17.el6_4         build       43 k
DEBUG util.py:264:   boost-wave                 ppc64      1.41.0-17.el6_4         build      194 k
DEBUG util.py:264:   libicu                     ppc64      4.2.1-9.1.el6_2         build      4.9 M
================================================================================


But on the previously given EL 5 root.log for PowerPC, it only installs the base boost package and not boost-regex and boost-system:

DEBUG util.py:264:  Getting requirements for libcutl-1.7.1-1.el5.src
DEBUG util.py:264:   --> boost-devel-1.33.1-16.el5_9.ppc
DEBUG util.py:264:   --> 1:pkgconfig-0.21-2.el5.ppc
DEBUG util.py:264:  ================================================================================
DEBUG util.py:264:   Package             Arch        Version                    Repository     Size
DEBUG util.py:264:  ================================================================================
DEBUG util.py:264:  Installing:
DEBUG util.py:264:   boost-devel         ppc         1.33.1-16.el5_9            build         4.3 M
DEBUG util.py:264:   pkgconfig           ppc         1:0.21-2.el5               build          63 k
DEBUG util.py:264:  Installing for dependencies:
DEBUG util.py:264:   boost               ppc         1.33.1-16.el5_9            build         908 k
DEBUG util.py:264:   libicu              ppc         3.6-5.16.1                 build         5.6 M
DEBUG util.py:264:  Transaction Summary
DEBUG util.py:264:  ================================================================================


As a workaround for EL 5, I'll try manually specifying boost-regex and boost-system as requirements and see if that fixes the issue.

Created attachment 778379 [details]
Log from ./configure on EL 5

This is the log from running ./configure on a EL 5 system and it is failing the check for the regex libraries. It appears the issue is that EL 5 uses Boost 1.33 and the regex header is in /usr/include/boost/regex.hpp instead of Boost 1.41 that's on EL 6 that has the file in /usr/include/boost/tr1/regex.hpp.

1.33 is very old and doesn't provide tr1 (which is what libcutl uses). Surely there has to be newer version of Boost packaged for EL5?

The other option would be to use internal Boost on EL5. In fact, this kind of situations is exactly the reason why we have the internal Boost subset in the first place.

Yes, Boost 1.41 is packaged for EL 5: https://admin.fedoraproject.org/pkgdb/acls/name/boost141

So I'll look into updating the spec file to make us of it on EL 5 so it can build without using the internal Boost subset and requiring a change to the license.

I got it to use the boost141-devel packages on EL 5, so it now builds on all off the targets.

(In reply to Dave Johansen from comment #24)
> I got it to use the boost141-devel packages on EL 5, so it now builds on all
> off the targets.

Good! Now, please submit them to Bodhi:

* https://admin.fedoraproject.org/updates/new/

libcutl-1.7.1-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/libcutl-1.7.1-1.el5

libcutl-1.7.1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libcutl-1.7.1-1.fc18

libcutl-1.7.1-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libcutl-1.7.1-1.fc19

libcutl-1.7.1-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/libcutl-1.7.1-1.el6

I had chosen newpackage for the type and stable for the request, but it appears that it changed it to testing and update. Is that ok/expected? Or did I do something wrong?

(In reply to Dave Johansen from comment #30)
> I had chosen newpackage for the type and stable for the request, but it
> appears that it changed it to testing and update. Is that ok/expected? Or
> did I do something wrong?

Yes, that's ok - an ordinary maintainer can't submit packages directly to stable.

Ok, since this package is already available in Rawhide, I'm going to start reviewing a dependent packages.

Package libcutl-1.7.1-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libcutl-1.7.1-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13834/libcutl-1.7.1-1.fc18
then log in and leave karma (feedback).

libcutl-1.7.1-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

libcutl-1.7.1-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

libcutl-1.7.1-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

libcutl-1.7.1-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.