Bug 973904

QUick notes:

%package -n     devel

Need to remove the -n

BuildRequires:

Why openldap-devel (don't see any ldap stuff in this package, no lber.h, ldap.h or ldif.h include)
Why expat-devel... (no expat.h include)

=> Ok, both are used in the result .so but can probably be omitted, no include of the provided headers, and will be pulled by apr.

Auto dependencies are broken.
Setting right to 755 the library should solves this.

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

I don't really like too large wildcard.
%{_libdir}/libserf-1.so.0*

As this is more explicit, it will also help to detect any soname change.

(In reply to Remi Collet from comment #1)
> QUick notes:
> 
> %package -n     devel
> 
> Need to remove the -n

Fixed.

> BuildRequires:
> 
> Why openldap-devel (don't see any ldap stuff in this package, no lber.h,
> ldap.h or ldif.h include)
> Why expat-devel... (no expat.h include)
> 
> => Ok, both are used in the result .so but can probably be omitted, no
> include of the provided headers, and will be pulled by apr.

Removed.

> Auto dependencies are broken.
> Setting right to 755 the library should solves this.

Which library?

> Which library?
"the" library. AFAIK there is only one in this package... (libserf-1.so.0.0.0)

(In reply to Remi Collet from comment #3)
> > Which library?
> "the" library. AFAIK there is only one in this package...
> (libserf-1.so.0.0.0)

Fixed by changing to -rwxr-xr-x.

NEW SPEC URL: http://cicku.me/libserf.spec 
NEW SRPM URL: http://cicku.me/libserf-1.2.1-2.fc20.src.rpm

Created attachment 761575 [details]
review.txt

Generated by fedora-review 0.4.1 (b2e211f) last change: 2013-04-29
Buildroot used: fedora-rawhide-x86_64
Command line :/usr/bin/fedora-review -b 973904

No blocker.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5506292

== APPROVED ===

(In reply to Remi Collet from comment #6)
> No blocker.
> 
> Koji scratch build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5506292
> 
> == APPROVED ===

Although no blocker, I will try fixing the unused-direct-shlib-dependency warnings via wiki hints.

New Package SCM Request
=======================
Package Name: libserf
Short Description: High-Performance Asynchronous HTTP Client Library
Owners: cicku
Branches: f18 f19
InitialCC:

Git done (by process-git-requests).

libserf-1.2.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libserf-1.2.1-2.fc19

libserf-1.2.1-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libserf-1.2.1-2.fc18

Package Change Request
======================
Package Name: libserf
New Branches: el6
Owners: cicku

Sorry for this coming late.

It will be great to not put headers directly in /usr/include, but in a sub directory.

To be in sync with debian packaging, I propose to use "serf-1"

Notice : this is where pecl_http for example look for them
(which it's stupid, I agree, should use pkg-config output )

Changes:
%configure --includedir=%{_includedir}/%{oname}-1 --with-gssapi=%{_prefix}

%files devel
%{_includedir}/%{oname}-1

(In reply to Remi Collet from comment #12)
> Sorry for this coming late.
> 
> It will be great to not put headers directly in /usr/include, but in a sub
> directory.

Hi,

Can you patch the pecl_http to get it worked?

It's OK to install libserf into subdir. But I don't know why take this name "serf-1"?

I know this weird name since packaging it..It's a confusion. Why should we name it "serf-1", even "serf" is better than that name... Or maybe I'm wrong. But whatever, should we open a new thread on packaging list? I want to know others' ideas.

Thanks.

(In reply to Christopher Meng from comment #13)
> (In reply to Remi Collet from comment #12)
> > Sorry for this coming late.
> > 
> > It will be great to not put headers directly in /usr/include, but in a sub
> > directory.
> 
> Hi,
> 
> Can you patch the pecl_http to get it worked?

Yes, of course (for now libserf is not used yet by pecl_http, just in the dev tree)

> It's OK to install libserf into subdir. But I don't know why take this name
> "serf-1"?

very probably from library name (libserf-1)
pkfconfig file is also serf-1.pc


> I know this weird name since packaging it..It's a confusion. Why should we
> name it "serf-1", even "serf" is better than that name... Or maybe I'm
> wrong.

yes, another name could be used.
sometime being in sync with other distro, which have this lib for a long time, is a good practice (note, debian have both serf-0 and serf-1)

Using a "versionned" directory allow to have 2 major version installed at the same time (if needed). Look in /usr/include, a lot of already exists.

> But whatever, should we open a new thread on packaging list? I want
> to know others' ideas.

I you want

> Thanks.

libserf-1.2.1-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libserf-1.2.1-3.fc18

libserf-1.2.1-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libserf-1.2.1-3.fc19

Git done (by process-git-requests).

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

libserf-1.2.1-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/libserf-1.2.1-3.el6

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

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

libserf-1.2.1-3.el6 has been pushed to the Fedora EPEL 6 stable repository.

Package Change Request
======================
Package Name: libserf
New Branches: epel7
Owners: cicku jorton

Git done (by process-git-requests).