Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: http://cicku.me/libclens.spec SRPM URL: http://cicku.me/libclens-0.7.0-1.fc20.src.rpm Description: clens is a convenience library to aid in porting code from OpenBSD to different operating systems. Operating systems traditionally have different enough APIs that porting code is painful and can litter pretty code with ugly ifdef goo. In order to keep code readable and drastically reduce the number of ifdefs needed, clens brings other APIs or missing functions into specific OS "focus". Fedora Account System Username: cicku
There's only a static lib generated during %build, which isn't packaged at all. Please get in touch with upstream to have it build a shlib and I'll take another run.
(In reply to Björn Esser from comment #1) > There's only a static lib generated during %build, which isn't packaged at > all. Please get in touch with upstream to have it build a shlib and I'll > take another run. Hi, quoted from upstream: Clens is not intended to be a shared library. There is a library that already provides some BSD compatibility functions (libbsd) which clens does not endeavor to imitate. After discussing this with the other folks, we've decided to keep it static only. We do understand the implications of this and think it is quite unfortunate that Fedora policy doesn't provide support for static libraries, but not everything should be a shared library. So I want to make this package like a -devel like pacakge, only ontains headers. Is it OK?
There's a hint in comment 1: | There's only a static lib generated during %build, | which isn't packaged at all. You cannot simply delete the compiled/built library in %install. You need to package it in accordance with https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
(In reply to Michael Schwendt from comment #3) > There's a hint in comment 1: > > | There's only a static lib generated during %build, > | which isn't packaged at all. > > You cannot simply delete the compiled/built library in %install. You need to > package it in accordance with > https://fedoraproject.org/wiki/Packaging: > Guidelines#Packaging_Static_Libraries The other way would be patching Makefile(.am) to build a shlib instead, regenerate with `autoreconf -vfi` (if applicable) and package it that way. Just having headers is usually (best known exception is boost-base, but it's specially designed this way) not enough in C/C++. There need to be binary-libs to link against. Just packaging the static lib is not such a good approach, since on main goal in development of Fedora is to get rid of them. The other problem I see is, if someone ports a daemon-app from bsd to Fedora using libclens-static, usefully hardening this is close to impossible. Linking against static libs doesn't allow PIE and RELRO with immeditate binding. The next question comming into my mind: What does libclens provide additionally to libbsd? Is it really worth the affort?
In fact this package is a base of assl: https://opensource.conformal.com/wiki/Agglomerated_SSL
Hi Bjorn, what should I do now? Can I only package headers?
Hi all, before update this review, I want to know which name is better? clens(tarball name) or libclens(more like a library)?
(In reply to Christopher Meng from comment #6) > Hi Bjorn, what should I do now? > Can I only package headers? I'm not sure, but there was an attempt to do so: https://bugzilla.redhat.com/show_bug.cgi?id=865116 Unfortunately, the review was never completed, because there was no need anymore for it as a dependency for another package. (In reply to Christopher Meng from comment #7) > Hi all, before update this review, I want to know which name is better? > clens(tarball name) or libclens(more like a library)? There's no unique guideline for, just that: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming You might use the tarball name, but to see directly that it is a library, you might use the "lib" prefix. It is your choice.
We don't apply a "lib" prefix to libraries. We prefer the "upstream tarball or project name", which often means the src.rpm %name matches the tarball name. rpm -qf /usr/lib*/lib*.so*|grep -v ^lib|sort|uniq Sometimes, depending on what components a software project builds, it can make sense to build a -libs subpackage. In other cases, the project may include programs, and then the added "lib" prefix would be a hindrance (and it would be necessary to redefine the binary rpm names completely to be closer to the upstream name).
*** Bug 1036299 has been marked as a duplicate of this bug. ***
Mark, I will push a new spec based on yours. You're welcome to comaintain it(Or let me comaintain it) Thanks. Will you want to review it? ;)
Hi Christopher, Your spec doesn't differ that much from mine so feel free to use whichever you'd prefer. Lemme know what the URL are for the spec and src.rpm and I'd be happy to review it. I dunno how I managed to miss this bug report when I tried to see if there was an existing review for clens, I think I searched for 'clens' instead of '*clens*' .
(In reply to Mark McKinstry from comment #12) > Hi Christopher, > > Your spec doesn't differ that much from mine so feel free to use whichever > you'd prefer. Lemme know what the URL are for the spec and src.rpm and I'd > be happy to review it. > > I dunno how I managed to miss this bug report when I tried to see if there > was an existing review for clens, I think I searched for 'clens' instead of > '*clens*' . Fine, wait a few days.
Mark, I'd like to know some details of this software with mg, can you provide some information? Thanks.
Christopher, Here's the spec for the one I built using clens: http://mmckinst.fedorapeople.org/packages/mg/mg.spec Is this what you're looking for? The author has some background info at http://homepage.boetes.org/software/mg/README_PORTING FWIW.
Hm.. explains a bit. I asked this because I don't want to ship static lib in the package, only headers are preserved. And I don't want to hack it and make it become a shared lib also. Looking forwards to your opinion again.
> I asked this because I don't want to ship static lib in the package, > only headers are preserved. And I don't want to hack it and make it > become a shared lib also. See comment 3. Perhaps you could make clear what you are trying to do? You must not delete the library (containing all of or most of the implementation) when the software consists of headers *and* a library.
Mark, I've updated the spec, please have a look and see if it works, hope you can review it. SPEC URL: http://misc.cicku.me/fedora/clens.spec SRPM URL: http://misc.cicku.me/fedora/clens-0.7.0-1.fc21.src.rpm
1) For what that trick: cat << EOF > configure #!/bin/bash EOF chmod +x configure %configure ? Just drop that lines - it looks like a garbage. 2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC as license field for package? I think it should be BSD and ISC. 3) Shouldn't be it called libclens instead clens? 4) Honestly I've first time review static library. Be aware what according to guideline https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables you must need citing "The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval." So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you firstly request that exception to do not make useless effort.
(In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #19) > 1) For what that trick: > cat << EOF > configure > #!/bin/bash > EOF > chmod +x configure > %configure > ? > > Just drop that lines - it looks like a garbage. I used to agree with you... But I need to set the building flags properly. > 2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC > as license field for package? I think it should be BSD and ISC. Please paste the license check results if possible, this package is ISC licensed described in README.md. > 3) Shouldn't be it called libclens instead clens? No, I insist on naming it based on the tarball name. > 4) Honestly I've first time review static library. Be aware what according > to guideline > https://fedoraproject.org/wiki/Packaging: > Guidelines#Statically_Linking_Executables you must need citing "The packager > must provide rationale for linking statically, including precedences where > available, to FESCO for approval." > So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you > firstly request that exception to do not make useless effort. That's for "Statically Linking Executables", means those linked with static libraries, but not static libraries itself.
(In reply to Christopher Meng from comment #20) > (In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #19) > > 1) For what that trick: > > cat << EOF > configure > > #!/bin/bash > > EOF > > chmod +x configure > > %configure > > ? > > > > Just drop that lines - it looks like a garbage. > > I used to agree with you... But I need to set the building flags properly. Sure. You may just export those env variables like: CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; LDFLAGS="${LDFLAGS:-%__global_ldflags}"; export LDFLAGS; Meantime it only c language, so: make %{?_smp_mflags} CFLAGS="${CFLAGS:-%optflags}" LDFLAGS="${LDFLAGS:-%__global_ldflags}" should be full enough. > > 2) Some files under BSD (2 or 3 clause) and some under ISC. Why you set ISC > > as license field for package? I think it should be BSD and ISC. > > Please paste the license check results if possible, this package is ISC > licensed described in README.md. BSD (2 clause) -------------- clens-0.7.0/include/clens/sys/tree.h BSD (3 clause) -------------- clens-0.7.0/include/clens/glob.h clens-0.7.0/include/clens/sys/queue.h BSD (3 clause) ISC ------------------ clens-0.7.0/src/fgetln.c clens-0.7.0/src/fmt_scaled.c clens-0.7.0/src/glob.c BSD (4 clause) ISC ------------------ clens-0.7.0/src/fparseln.c ISC --- clens-0.7.0/config/freebsd/build-pkg.sh clens-0.7.0/config/prep_release.sh clens-0.7.0/include/clens/clens.h clens-0.7.0/include/clens/readpassphrase.h clens-0.7.0/src/arc4random_buf.c clens-0.7.0/src/arc4random_uniform.c clens-0.7.0/src/clens.c clens-0.7.0/src/strlcat.c clens-0.7.0/src/strlcpy.c clens-0.7.0/src/strtonum.c clens-0.7.0/version.sh Unknown or generated -------------------- clens-0.7.0/buildver.sh Is not it available for you?? > > 4) Honestly I've first time review static library. Be aware what according > > to guideline > > https://fedoraproject.org/wiki/Packaging: > > Guidelines#Statically_Linking_Executables you must need citing "The packager > > must provide rationale for linking statically, including precedences where > > available, to FESCO for approval." > > So, as it packaged as dependency to mg (bz#1010897) i strongly encourage you > > firstly request that exception to do not make useless effort. > > That's for "Statically Linking Executables", means those linked with static > libraries, but not static libraries itself. Yes, there I mention mg. It will be intended to be linked with clens statically. You must request it exception from FESCO. Otherwise it have no sense to packaging that static lib.
> cat << EOF > configure > #!/bin/bash > EOF > chmod +x configure > %configure There have been various forms of that over the years. One other is: %configure || : > You must request it exception from FESCO. You are misreading the guidelines. What you refer to is the case where a packager wants to link statically when a library is available _both_ as a shared and static build. Then it must be justified why the shared lib is not linked with instead. On the contrary, for a static-only library this one applies: https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don.27t_need_to_notify_FESCo
For the license issue, upstream has replied to me: https://github.com/conformal/clens/issues/1
(In reply to Michael Schwendt from comment #22) > You are misreading the guidelines. What you refer to is the case where a > packager wants to link statically when a library is available _both_ as a > shared and static build. Then it must be justified why the shared lib is not > linked with instead. > > On the contrary, for a static-only library this one applies: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Programs_which_don. > 27t_need_to_notify_FESCo Yes, you are right. Sorry. (In reply to Christopher Meng from comment #23) > For the license issue, upstream has replied to me: > > https://github.com/conformal/clens/issues/1 Heh. Cool. But are you looked into files?? There different licenses mostly because they borrowed from different projects! For example: BSD (2 clause) -------------- clens-0.7.0/include/clens/sys/tree.h $OpenBSD: tree.h,v 1.13 2011/07/09 00:19:45 pirofti Exp Copyright 2002 Niels Provos <provos.edu> BSD (3 clause) -------------- clens-0.7.0/include/clens/glob.h clens-0.7.0/include/clens/sys/queue.h /* $OpenBSD: glob.h,v 1.11 2010/09/24 13:32:55 djm Exp $ */ /* $NetBSD: glob.h,v 1.5 1994/10/26 00:55:56 cgd Exp $ */ /* * Copyright (c) 1989, 1993 * The Regents of the University of California. All rights reserved. BSD (3 clause) ISC ------------------ clens-0.7.0/src/fgetln.c clens-0.7.0/src/fmt_scaled.c clens-0.7.0/src/glob.c Copyright (c) 2011 Conformal Systems LLC <info> and so on. In no one I have not found Dave Collins as author. So I assume they have not any rights to relicense it. Bundled issue must be resolved or exceptions requested.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.