*** Bug 810875 has been marked as a duplicate of this bug. ***

Some comments:

 o choose %{buildroot} or $RPM_BUILD_ROOT, use only one variant
 o change %{_datadir}/guayadeque/* to %{_datadir}/guayadeque
 o why is _pkgbuilddir needed? If needed: use %global
 o change  svn1830.1%{?dist} to 1.svn1830%{?dist} :
   http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Version_in_Release
 o some source files are under GPLv2+, however MD5.cpp and hmac/* are not and
   maybe more. Please have a closer look.

Could you do a koji scratch build?

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque.spec?a=ZK1IIr7oO60

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-2.svn1830/guayadeque-0.3.6-2.svn1830.fc17.src.rpm?a=0tythsdteBc

%changelog
* Thu Sep 4 2012 Martin Gansser <linux4martin> - 0.3.6-2.svn1830
- changed to buildroot variante
- removed uneeded macro _pkgbuilddir
- added Provides: bundled(md5-polstra)

don't know how to handle licens type of files:
HMAC-SHA-224/256/384/512 implementation in src/hmac/hmac_sha2.c
FIPS 180-2 SHA-224/256/384/512 implementation in src/hmac/sha2.c

> Could you do a koji scratch build?

koji build --scratch rawhide ../rpmbuild/SRPMS/guayadeque-0.3.6-2.svn1830.fc17.src.rpm

fails on:
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4453040

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-3.svn1830/guayadeque.spec?a=i7Qf1UNneuA

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-3.svn1830/guayadeque-0.3.6-3.svn1830.fc17.src.rpm?a=AJ4R9vjgZQ0

%changelog
* Fri Sep 7 2012 Martin Gansser <linux4martin> - 0.3.6-3.svn1830
- added patch for DSO linker problem
- added missing build requirements

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-4.svn1830/guayadeque.spec?a=bOIAY1VMCsM

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-4.svn1830/guayadeque.spec?a=5VUFUh0smfQ

%changelog
* Sat Sep 8 2012 Martin Gansser <linux4martin> - 0.3.6-4.svn1830
- removed  gcc-c++ build requirement
- removed %%defattr from file section

Sorry correct link again:

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-4.svn1830/guayadeque.spec?a=5VUFUh0smfQ

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-4.svn1830/guayadeque-0.3.6-4.svn1830.fc17.src.rpm?a=yfxHjA6eW1Y

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-5.svn1830/guayadeque.spec?a=416FXyjkgDc

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-5.svn1830/guayadeque-0.3.6-5.svn1830.fc18.src.rpm?a=curGqhWziec

%changelog
* Mon Sep 10 2012 Martin Gansser <linux4martin> - 0.3.6-5.svn1830
- added BSD license for HMAC-SHA implementation

Hi Martin,

just a few comments:
 - use %{name} in your files section
 - remove all your unnecessary Requires. RPM will determine all of these correctly, so no need to explicitly include them [1]

I also get a build error when building in mock (F17). I will submit a scratch build for f18 and post the results

-- Found Subversion: /usr/bin/svn (found version "1.6.18") 
CMake Error at /usr/share/cmake/Modules/FindSubversion.cmake:83 (MESSAGE):
  Command "/usr/bin/svn info /builddir/build/BUILD/guayadeque-svn1830" failed
  with output:
  svn: The path '/builddir/build/BUILD/guayadeque-svn1830' appears to be part
  of a Subversion 1.7 or greater
  working copy.  Please upgrade your Subversion client to use this
  working copy.
Call Stack (most recent call first):
  CMakeLists.txt:122 (Subversion_WC_INFO)
Current revision is 
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
-- Configuring incomplete, errors occurred!
error: Bad exit status from /var/tmp/rpm-tmp.mvv1Fs (%build)
    Bad exit status from /var/tmp/rpm-tmp.mvv1Fs (%build)
RPM build errors:
Child return code was: 1


[1] http://fedoraproject.org/wiki/Packaging:Guidelines#Requires

On closer inspection of the source there seems to be some bundled libraries here - wxsqlite and wxcurl (wxMD5?).

I recommend asking the packaging list for advice

You need to determine wether this code has been significantly altered by upstream and detremin wether an exception to [1] is warranted or submit those packages separately.


[1] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Brendan,

thanks for your comments


1. i do not understand your notes regarding subversion, have you a patch ?

2. i see no libraries in the mentioned dirs.

[martin@fc17-64 guayadeque-svn1830]$ ll src/wxsqlite3/ src/curl/ /srv/wx
ls: Zugriff auf /srv/wx nicht möglich: Datei oder Verzeichnis nicht gefunden
src/curl/:
insgesamt 40
-rw-r--r--. 1 martin martin 26007  1. Nov 2011  base.cpp
-rw-r--r--. 1 martin martin 10017  1. Nov 2011  http.cpp

src/wxsqlite3/:
insgesamt 80
-rwxr-xr-x. 1 martin martin 79509  1. Nov 2011  wxsqlite3.cpp

(In reply to comment #10)
> Brendan,
> 
> thanks for your comments
> 
> 
> 1. i do not understand your notes regarding subversion, have you a patch ?

There may be a problem with the SVN version of the build system. Worry asbout this later - see point below.

> 
> 2. i see no libraries in the mentioned dirs.
> 
> [martin@fc17-64 guayadeque-svn1830]$ ll src/wxsqlite3/ src/curl/ /srv/wx
> ls: Zugriff auf /srv/wx nicht möglich: Datei oder Verzeichnis nicht gefunden
> src/curl/:
> insgesamt 40
> -rw-r--r--. 1 martin martin 26007  1. Nov 2011  base.cpp
> -rw-r--r--. 1 martin martin 10017  1. Nov 2011  http.cpp
> 
> src/wxsqlite3/:
> insgesamt 80
> -rwxr-xr-x. 1 martin martin 79509  1. Nov 2011  wxsqlite3.cpp

This package is including copies of the source of those libraries and statically linking them at compile time. You need to create two separate review requests for each unless this project has significantly altered them from upstream. You will then need to patch the build system of this package and send upstream. 

If theses libraries are signifiicantly altered from there respective projects, you need to apply for an excemption (see link above). From what I can see they are not altered.

(In reply to comment #11)
It is somewhat unclear for me, should i create a bug review for wxsqlite and wxcurl or not?

You need to download the source from e.g. http://sourceforge.net/projects/wxcode/files/Components/ and compare to the code bundled in Guayadeque.

If it is not different yes, you need to package separate review requests ,and patch guayadeque to use this library. 

Repeat for each bundled library.

the recent version of wxsqlite3 differs from the wxsqlite3.cpp from Guayadeque.

guayadeque-svn1830/src/wxsqlite3/wxsqlite3.cpp wxsqlite3-3.0.0/src/wxsqlite3.cpp

diff file
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/wxsqlite3.diff?a=IhLN2VIn8OI

created bug review for wxsqlite3
https://bugzilla.redhat.com/show_bug.cgi?id=858998

but need help for patching guayadeque to find external library from wxsqlite3.

@Martin, a review request shouldn't point to a specific Fedora version. If we would do so, some requests could be closed once the given version has reached EOL. I've set it to Rawhide.

reported a bug on guayadeque website, with title:
wxsqlite3 lib is bundled, blocks packaging.
https://sourceforge.net/p/guayadeque/bugs-reports/110/

hm ... what's mean 'they dont support thirt party developers.'?

Have a look at polititcs in other distributions with bundled libraries.

You can write a patch for optional external wxsqlite3 and apply it for the package. Also send the patch to Juan.

(In reply to comment #19)
> Have a look at polititcs in other distributions with bundled libraries.
> 
> You can write a patch for optional external wxsqlite3 and apply it for the
> package. Also send the patch to Juan.

the problem is that I am not a programmer and can not write the patch.

So I can help you. I will write such patch for your package.

(In reply to comment #21)
> So I can help you. I will write such patch for your package.

great Ivan !

wxsqlite3 doesn't provide .pc file. please add it to simplify my task. It is good when ever -devel subpackage provides flags for gcc compiler.
https://fedoraproject.org/wiki/Packaging:Guidelines#Pkgconfig_Files_.28foo.pc.29

Created attachment 630022 [details]
wxsqlite3-3.0.0.1-pkgconfig.patch

I have tried to create a patch, but this unfortunately does not work because
I  haven't deep experience with configure and Makefile.
Can someone have a look over it.

# you need the wxCode/build/bakefiles in your local repository to generate a configure
# script from this configure.ac file since wxcode.m4 is required....
m4_include(../../../build/autoconf/wxcode.m4)

You need wxCode in Fedora. Do you want to make yet one a package?
Just use workaround. Add prepared wxsqlite3.pc as source to wxsqlite3 package and cp it in %install stage.

oh ... wxsqlite3 it is a part of wxcode ...

also open a bugreport on wxsqlite3 with wxsqlite3.pc

(In reply to comment #28)
> also open a bugreport on wxsqlite3 with wxsqlite3.pc

i have build a new wxsqlite3-3.0.0.1-7.fc17 package with the wxsqlite3.pc file
as you mention.
http://koji.fedoraproject.org/koji/taskinfo?taskID=4611259

i don't see wxsqlite3.pc in git tree 
http://pkgs.fedoraproject.org/cgit/wxsqlite3.git/tree/
sources file must contains only sources files. i mean that files under Source$ sections. in your case it will be wxsqlite3-3.0.0.1.tar.gz and wxsqlite3.pc

I think we can just pass the lib through the cmake line. Remove the wxsqlite3 sources and add the following to the spec (see attachment)


Patch1:         %{name}-unbundl-wxsqlite3.patch

%prep
%setup -q -n %{name}-svn1830
%patch0 -p1
%patch1 -p1
# deleting Unity parts in guayadeque.desktop files
sed -i '18,38d' guayadeque.desktop
# remove bundled libraries
rm -rf src/wx/wxsql* src/wxsqlite3

%build
mkdir -p build-guayadeque && pushd build-guayadeque
%cmake \
    -DCMAKE_VERBOSE_MAKEFILE=TRUE \
    -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
    -DCMAKE_SKIP_RPATH=TRUE \
    -DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE \
    -DWXSQLITE3_LIB=wxcode_gtk2_wxsqlite3-2.8 \
..

Created attachment 630787 [details]
CMake patch wxsqlite3

Spec URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-7.svn1830/guayadeque.spec?a=Ntrj_2u3E34

SRPM URL:
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-7.svn1830/guayadeque-0.3.6-7.svn1830.fc17.src.rpm?a=rqr7F0HcRZM

%changelog
* Sun Oct 21 2012 Martin Gansser <linux4martin> - 0.3.6-7.svn1830
- added unbundle-wxsqlite3.patch
- added command to remove src/wx/wxsql* src/wxsqlite3 from source

* Sat Sep 15 2012 Martin Gansser <linux4martin> - 0.3.6-6.svn1830
- used %%{name} in file section
- removed unnecessary Requires

it is strange for me. why spec hasn't wxsqlite3 build requires?

bad unbandle patch. you should to use cmake commands to check system wxsqlite3.

The wxsqlite3 lib name is dependant on the version of GTK it is built against.

So using find_library(wxcode_gtk2_wxsqlite3-2.8 ) seems to me to be more restrictive than simply passing a cmake variable at configuration time. That way you can build against any version of gtk.

This is not the case for the other wxWidgets as they are handled by the FindwxWidgets macro (which in turn relies on wxconfig rather than pkgconfig)

The patch I proposed is a flexible one

Use pkg_search_module instead of find_library.

Have a look at pkg-config module for CMake.

the current version of guayadeque-svn1845 is looking for an external version of wxSQLite3-2.8
On Fedora 17 q.e. wxsqlite3-devel-3.0.0.1-7.fc17.x86_64 and
wxsqlite3-3.0.0.1-7.fc17.x86_64 are installed.

cmake reports that wxsqlite3-2.8 was missing.

-- checking for module 'wxsqlite3-2.8'
--   package 'wxsqlite3-2.8' not found
CMake Error at CMakeLists.txt:116 (MESSAGE):
  libwxsqlite3-2.8 not found!

in CMakeLists.txt PKG_CHECK_MODULES was defined as:

PKG_CHECK_MODULES( LIBWXSQLITE3 wxsqlite3-2.8 )
IF( NOT LIBWXSQLITE3_LIBRARIES )
        MESSAGE( FATAL_ERROR "libwxsqlite3-2.8 not found!" )
ENDIF( NOT LIBWXSQLITE3_LIBRARIES )

how can i solve the problem ?

PKG_CHECK_MODULES( LIBWXSQLITE3 wxsqlite3 )
For version checking use LIBWXSQLITE3_VERSION

the compilation fails now with the following error messages:

https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-8.svn1845/guayadeque_buildlog.txt?a=_22ag5z68tU

show your patch and .spec

did you install wxGTK-devel?

rpm -qa |grep wxGTK
wxGTK-gl-2.8.12-4.fc17.x86_64
wxGTK-media-2.8.12-4.fc17.x86_64
wxGTK-devel-2.8.12-4.fc17.x86_64
wxGTK-2.8.12-4.fc17.x86_64

guayadeque-CMakeLists.patch
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-8.svn1845/guayadeque-CMakeLists.patch?a=ZpQd4Id4lAc

guayadeque.spec
https://www.disk.dsl.o2online.de/FclyPlh/RPMS/guayadeque/guayadeque-0.3.6-8.svn1845/guayadeque.spec?a=CbZerwHKmSA

As I mentioned earlier, wx* packages don't support pkg-config but use wxconfig instead. There is no wxGTK-devel.pc and I doubt there will be

The wxsqlite3 library is named in such a way that wx-config does not pick it up which is why I supplied the much simpler cmake patch above.

wx-config --libs wxsqlite3
-pthread -Wl,-z,relro   -lwx_gtk2u_wxsqlite3-2.8 -lwx_baseu-2.8

2.8 below refers to the GTK version it was built against and has nothing to do with the version numebr associated with wxsqlite3.

 $ rpm -ql wxsqlite3
/usr/lib64/libwxcode_gtk2_wxsqlite3-2.8.so.0
/usr/lib64/libwxcode_gtk2_wxsqlite3-2.8.so.0.0.0
/usr/share/doc/wxsqlite3-3.0.0.1
/usr/share/doc/wxsqlite3-3.0.0.1/LICENCE.txt
/usr/share/doc/wxsqlite3-3.0.0.1/Readme.txt

As you can see this does not match the wxsqlite3 library nor that specified in your .pc file. You could create a sym link and wx-config and FindwxWidgets(wxsqlite3) would then find the package but that sounds like a waste of tiem to me. I still recommend using the simple, manual patch I provided

Brendan, thanks for your comment.

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-8.svn1845.fc17.src.rpm

%changelog
%changelog
* Sat Nov 24 2012 Martin Gansser <linux4martin> - 0.3.6-8.svn1845
- added wxsqlite3 build requirenment
- added CMakeLists.patch
- changed cmake flags
- spec file cleanup
- rebuild for new svn release

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-9.svn1845.fc17.src.rpm

%changelog
* Sat Nov 24 2012 Martin Gansser <linux4martin> - 0.3.6-9.svn1845
- update CMakeLists.patch and unbundle-wxsqlite3.patch for fedora 17 / 18

(In reply to comment #38)
> Have a look at pkg-config module for CMake.

Hi Ivan,

can you show me exactly the way how to use pkgconfig to
to check system wxsqlite3.

I just submitted a local build (no a machine where no Mock/Plague is needed) for
guayadeque-0.3.6-9.svn1845.fc17.src.rpm

The spec file contains a missing 'u' in the cmake setup:
    -DWXSQLITE3_LIB=wxcode_gtk2u_wxsqlite3-2.8 \

('gtk2u' instead of 'gtk2')

and after repairing the wxsqlite3.pc file, the build succeeds. Of course that is only because the src.rpm guayadeque-unbundle-wxsqlite3.patch adds to the linker options, but you're getting closer. ;)

The linker options for wxqslite3 and gdk-pixbuf2 are duplicated somewhere, however:

[...]
s/guayadeque.dir/hmac/hmac_sha2.o CMakeFiles/guayadeque.dir/hmac/sha2.o  -o guayadeque -rdynamic -pthread -Wl,-z,relro -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8 -lwx_baseu_net-2.8 -lwx_gtk2u_html-2.8 -lwx_baseu_xml-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_qa-2.8 -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -lsqlite3 -lcurl -ltag -lFLAC -lm -ldbus-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgpod -lwxcode_gtk2u_wxsqlite3-2.8 -lgdk_pixbuf-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lsqlite3 -lcurl -ltag -lFLAC -lm -ldbus-1 -lgio-2.0 -lgpod -lwxcode_gtk2u_wxsqlite3-2.8 -lgdk_pixbuf-2.0 
make[2]: Leaving directory `/home/…/tmp/rpm/BUILD/guayadeque-svn1845/build-guayadeque'
[...]

(In reply to comment #49)
> I just submitted a local build (no a machine where no Mock/Plague is needed)
> for
> guayadeque-0.3.6-9.svn1845.fc17.src.rpm
> 
> The spec file contains a missing 'u' in the cmake setup:
>     -DWXSQLITE3_LIB=wxcode_gtk2u_wxsqlite3-2.8 \
> 
> ('gtk2u' instead of 'gtk2')

yes this is true, it comes with the newer wxsqlite3-3.0.1 version.

With the recent guayadeque-0.3.6-9.svn1858 the additional cmake flag wxcode_gtk2u_wxsqlite3-2.8 isn't needed any longer.

> and after repairing the wxsqlite3.pc file, the build succeeds. Of course
> that is only because the src.rpm guayadeque-unbundle-wxsqlite3.patch adds to
> the linker options, but you're getting closer. ;)
> 
> The linker options for wxqslite3 and gdk-pixbuf2 are duplicated somewhere,
> however:

I need to investigate further

> [...]
> s/guayadeque.dir/hmac/hmac_sha2.o CMakeFiles/guayadeque.dir/hmac/sha2.o  -o
> guayadeque -rdynamic -pthread -Wl,-z,relro -lwx_baseu-2.8
> -lwx_gtk2u_core-2.8 -lwx_gtk2u_adv-2.8 -lwx_baseu_net-2.8
> -lwx_gtk2u_html-2.8 -lwx_baseu_xml-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_qa-2.8
> -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2
> -lglib-2.0 -lsqlite3 -lcurl -ltag -lFLAC -lm -ldbus-1 -lgio-2.0
> -lgobject-2.0 -lglib-2.0 -lgpod -lwxcode_gtk2u_wxsqlite3-2.8
> -lgdk_pixbuf-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lsqlite3 -lcurl
> -ltag -lFLAC -lm -ldbus-1 -lgio-2.0 -lgpod -lwxcode_gtk2u_wxsqlite3-2.8
> -lgdk_pixbuf-2.0 
> make[2]: Leaving directory
> `/home/…/tmp/rpm/BUILD/guayadeque-svn1845/build-guayadeque'
> [...]

the file /usr/lib64/pkgconfig/wxsqlite3.pc looks now as following and work for
the compilation. Is this ok now ?

prefix=/usr
libdir=/usr/lib64
includedir=/usr/include

Name: wxsqlite3
Description: C++ wrapper around the SQLite 3.x database
URL:  http://wxcode.sourceforge.net/components/wxsqlite3/
Version: 3.0.1

Libs: -L${libdir} -lwxcode_gtk2u_wxsqlite3-2.8
Cflags: -I${includedir}/wx

Created attachment 668200 [details]
proposed spec patch for wxsqlite3

As a followup to the conversation outside this ticket:

> Cflags: -I${includedir}/wx

This isn't correct yet, and guayadeque only compiles because it includes the "wx/wxsqlite3" headers via standard search path instead.

wxsqlite3.spec could be changed to install into /usr/include/wx-2.8/wx like wxGTK and extensions. The attached spec is one way how to do that. The patch also uses wx-config to fetch the "2.8" version of wxGTK.

[...]

Debian's package adds a pkgconfig file:
http://packages.debian.org/wheezy/libwxsqlite3-2.8-0

  $ cat wxsqlite3-2.8.pc.in 
  # Package Information for pkg-config

  prefix=/usr
  wxver=2.8
  includedir=${prefix}/include/wx-${wxver}/
  libdir=${prefix}/@LIBDIR@

  Name: wxsqlite3-2.8
  Description: SQLite3 C++ wrapper for use in programs based on the wxWidgets
  Version: @VERSION@
  Requires: sqlite3
  Libs: -L${libdir} -lwxsqlite3-2.8
  Libs.private: -lpthread 
  Cflags: -I${includedir}

They substitute the two variables in their "rules" file. It could be adapted to Fedora. Note the different file name, for example: wxsqlite3-2.8.pc

So, no surprise that guayadeque relies on such a .pc file to be present when detecting wxsqlite and must be patched to disable the check.

guayadeque-svn1858 builds now against wxsqlite3-3.0.1-4.fc18 (available on koji and updates-testing a day later). There is still a patch for the dso link problem necessary, for this i need assistance.

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-12.svn1858.fc18.src.rpm

%changelog
* Wed Dec 26 2012 Martin Gansser <martinkg> - 0.3.6-12.svn1858
- removed %%cmake flags for wxsqlite3
- rebuild
- specfile cleanup

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-13.svn1872.fc18.src.rpm

%changelog
* Sat Feb 16 2013 Martin Gansser <martinkg> - 0.3.6-13.svn1872
- rebuild

@Brendan
thanks for the answer and the solution.
Is the package already ok in your opinion or is there something to do ?

Hi,

I'd like to see this nice player getting into Fedora.

Can you update the svn version to the latest and push a new package to here, I'd like tpo help review if possible.

BTW its homepage is: http://guayadeque.org/, not sf.net page. Please change.

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-14.svn1885.fc19.src.rpm

%changelog
* Mon Oct 14 2013 Martin Gansser <martinkg> - 0.3.6-14.svn1885
- rebuild
- corrected url address

hi christoper you are welcome.

(In reply to MartinKG from comment #55)
> Spec URL:
> http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec
> 
> SRPM URL:
> http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-14.svn1885.
> fc19.src.rpm

These links are not reachable for me.
Please, check them.

(In reply to Antonio Trande from comment #56)
> (In reply to MartinKG from comment #55)
> > Spec URL:
> > http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec
> > 
> > SRPM URL:
> > http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-14.svn1885.
> > fc19.src.rpm
> 
> These links are not reachable for me.
> Please, check them.

permission problem solved, links now available.

There is a problem during the fedora 19+ package building related to svn:

-- Found Subversion: /usr/bin/svn (found version "1.8.3") 
CMake Error at /usr/share/cmake/Modules/FindSubversion.cmake:83 (message):
  Command "/usr/bin/svn info /builddir/build/BUILD/guayadeque-svn1885" failed
  with output:
  svn: E155036: Please see the 'svn upgrade' command
  svn: E155036: The working copy at
  '/builddir/build/BUILD/guayadeque-svn1885'
  is too old (format 29) to work with client version '1.8.3 (r1516576)'
  (expects format 31).  You need to upgrade the working copy first.

You need to upgrade the working copy with a 'svn upgrade' command in the %prep section if you build the package in fedora >= 20, otherwise building fails.

I don't know if this issue can be fixed only inside the RPM building or can be done even outside.

Upstream's CMakeLists.txt does this:
        FIND_PACKAGE(Subversion)
        IF(Subversion_FOUND)
          Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
          MESSAGE("Current revision is ${GUAYADEQUE_WC_REVISION}")
          SET( _GUREVISION_ ${GUAYADEQUE_WC_REVISION})
        ELSE(Subversion_FOUND)
          SET( _GUREVISION_ "" )
        ENDIF(Subversion_FOUND)

In particular, this line:
          Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
runs "svn info" on the current directory to obtain the revision and store it in the CMake variable GUAYADEQUE_WC_REVISION, which is then copies to the CMake variable _GUREVISION_, presumably to show it in some about dialog or something. And the tarball they ship is a working copy in an outdated format (outdated SVN version). (IMHO, shipping SVN working copies rather than exports as tarballs is broken in the first place.)

IMHO, just removing the .svn directories (i.e. converting the working copies to a clean export) is the best fix, but you could also run "svn upgrade" in the specfile (with BuildRequires: subversion) if you think it's important to have the revision show up (but you could also manually specify -D_GUREVISION_:STRING=1885 on the cmake command line to get that).

(In reply to Kevin Kofler from comment #59)
> Upstream's CMakeLists.txt does this:
>         FIND_PACKAGE(Subversion)
>         IF(Subversion_FOUND)
>           Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
>           MESSAGE("Current revision is ${GUAYADEQUE_WC_REVISION}")
>           SET( _GUREVISION_ ${GUAYADEQUE_WC_REVISION})
>         ELSE(Subversion_FOUND)
>           SET( _GUREVISION_ "" )
>         ENDIF(Subversion_FOUND)
> 
> In particular, this line:
>           Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
> runs "svn info" on the current directory to obtain the revision and store it
> in the CMake variable GUAYADEQUE_WC_REVISION, which is then copies to the
> CMake variable _GUREVISION_, presumably to show it in some about dialog or
> something. And the tarball they ship is a working copy in an outdated format
> (outdated SVN version). (IMHO, shipping SVN working copies rather than
> exports as tarballs is broken in the first place.)
> 
> IMHO, just removing the .svn directories (i.e. converting the working copies
> to a clean export) is the best fix, but you could also run "svn upgrade" in
> the specfile (with BuildRequires: subversion) if you think it's important to
> have the revision show up (but you could also manually specify
> -D_GUREVISION_:STRING=1885 on the cmake command line to get that).

@kevin

i have set a find .. command in prep section and the -D_GUREVISION_ option
in the command line, is this ok ?

%prep
%setup -q -n %{name}-svn%{svnrev}
%patch0 -p1
# deleting Unity parts in guayadeque.desktop files
sed -i '18,38d' guayadeque.desktop
# remove bundled libraries
rm -rf src/wx/wxsql* src/wxsqlite3
# remove .svn dirs
find -type d -name .svn | xargs rm -rf .svn

%build
mkdir -p build-guayadeque && pushd build-guayadeque
%cmake \
    -DCMAKE_VERBOSE_MAKEFILE=TRUE \
    -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
    -DCMAKE_SKIP_RPATH=FALSE \
    -DCMAKE_BUILD_WITH_INSTALL_RPATH=FALSE \
    -D_GUREVISION_:STRING=%{svnrev} \
..
make %{?_smp_mflags}
popd

find -type d -name .svn | xargs rm -rf .svn

Can be

find -type d -name .svn -delete

> i have set a find .. command in prep section and the -D_GUREVISION_ option
> in the command line, is this ok ?

Yes, that looks right.

(In reply to Christopher Meng from comment #61)
> find -type d -name .svn | xargs rm -rf .svn
> 
> Can be
> 
> find -type d -name .svn -delete

did not work
find -type d -name .svn -delete
find: cannot delete './.svn': Directory not empty

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-15.svn1885.fc19.src.rpm

%changelog
* Mon Oct 21 2013 Martin Gansser <martinkg> - 0.3.6-15.svn1885
- added command to remove .svn dirs
- added %%cmake option for svn revision

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- update-desktop-database is invoked in %post and %postun if package contains
  desktop file(s) with a MimeType: entry.
  Note: desktop file(s) with MimeType entry in guayadeque
  See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-
  database

- Please, fix the License tag.

- Some files (probably the most common like mp3) can't be played because of some 
  GStreamer plugins not available in the Fedora repositories.
  You can also consider the RPMFusion repositories.

- rpmlint advises of a mixed use of space and tabs in the .spec file:
  guayadeque.src:17: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 17)
  Please, fix it.


===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[!]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Public domain", "BSD (3 clause)", "LGPL (v2.1 or later) (with incorrect
     FSF address)", "Unknown or generated", "GPL (v3 or later) (with incorrect
     FSF address)". 160 files have unknown license. Detailed output of
     licensecheck in /home/sagitter/853553-guayadeque/licensecheck.txt

The compilation involves files with three different licenses.
   GPLv3+ and BSD and LGPLv2+
      

[!]: If the package is under multiple licenses, the licensing breakdown must
     be documented in the spec.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 40960 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or desktop-
     file-validate if there is such a file.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: SourceX tarball generation or download is documented.
     Note: Package contains tarball without URL, check comments
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[-]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
     Note: Arch-ed rpms have a total of 1699840 bytes in /usr/share
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: guayadeque-0.3.6-15.svn1885.fc21.i686.rpm
          guayadeque-0.3.6-15.svn1885.fc21.src.rpm
guayadeque.i686: W: no-manual-page-for-binary guayadeque
guayadeque.src:33: W: unversioned-explicit-provides bundled(md5-polstra)
guayadeque.src:17: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 17)
guayadeque.src: W: invalid-url Source0: guayadeque-svn1885.tar.bz2
2 packages and 0 specfiles checked; 0 errors, 4 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint guayadeque
guayadeque.i686: W: no-manual-page-for-binary guayadeque
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'



Requires
--------
guayadeque (rpmlib, GLIBC filtered):
    libFLAC.so.8
    libc.so.6
    libcurl.so.4
    libdbus-1.so.3
    libgcc_s.so.1
    libgcc_s.so.1(GCC_3.0)
    libgdk_pixbuf-2.0.so.0
    libgio-2.0.so.0
    libglib-2.0.so.0
    libgmodule-2.0.so.0
    libgobject-2.0.so.0
    libgpod.so.4
    libgstreamer-0.10.so.0
    libgthread-2.0.so.0
    libm.so.6
    libpthread.so.0
    libsqlite3.so.0
    libstdc++.so.6
    libstdc++.so.6(CXXABI_1.3)
    libtag.so.1
    libwx_baseu-2.8.so.0
    libwx_baseu-2.8.so.0(WXU_2.8)
    libwx_baseu_net-2.8.so.0
    libwx_baseu_xml-2.8.so.0
    libwx_baseu_xml-2.8.so.0(WXU_2.8)
    libwx_gtk2u_adv-2.8.so.0
    libwx_gtk2u_adv-2.8.so.0(WXU_2.8)
    libwx_gtk2u_aui-2.8.so.0
    libwx_gtk2u_aui-2.8.so.0(WXU_2.8)
    libwx_gtk2u_aui-2.8.so.0(WXU_2.8.5)
    libwx_gtk2u_core-2.8.so.0
    libwx_gtk2u_core-2.8.so.0(WXU_2.8)
    libwx_gtk2u_html-2.8.so.0
    libwx_gtk2u_html-2.8.so.0(WXU_2.8)
    libwx_gtk2u_qa-2.8.so.0
    libwx_gtk2u_qa-2.8.so.0(WXU_2.8)
    libwxcode_gtk2_wxsqlite3-2.8.so.0
    libxml2.so.2
    rtld(GNU_HASH)



Provides
--------
guayadeque:
    bundled(md5-polstra)
    guayadeque
    guayadeque(x86-32)
    mimehandler(application/ogg)
    mimehandler(application/x-flac)
    mimehandler(audio/mp4)
    mimehandler(audio/mpeg)
    mimehandler(audio/mpegurl)
    mimehandler(audio/ogg)
    mimehandler(audio/x-ape)
    mimehandler(audio/x-flac)
    mimehandler(audio/x-m4a)
    mimehandler(audio/x-mod)
    mimehandler(audio/x-mp3)
    mimehandler(audio/x-mpeg)
    mimehandler(audio/x-mpegurl)
    mimehandler(audio/x-ms-asf)
    mimehandler(audio/x-ms-asx)
    mimehandler(audio/x-ms-wax)
    mimehandler(audio/x-ms-wma)



Generated by fedora-review 0.5.0 (920221d) last change: 2013-08-30
Command line :/usr/bin/fedora-review -m fedora-rawhide-i386 -b 853553
Buildroot used: fedora-rawhide-i386
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, SugarActivity, Perl, R, PHP, Ruby
Disabled flags: EPEL5, EXARCH, DISTTAG

I would have expected you to simply remove the .svn director when you are building the tarball to keep the SRPM small.

Spec URL:
http://martinkg.fedorapeople.org/Review/SPECS/guayadeque.spec

SRPM URL:
http://martinkg.fedorapeople.org/Review/SRPMS/guayadeque-0.3.6-16.svn1885.fc19.src.rpm

%changelog
* Tue Oct 22 2013 Martin Gansser <martinkg> - 0.3.6-16.svn1885
- added correct license type
- removed tabs in the spec file
- added %%desktop-database because desktop entry has a 'MimeType key.
- removing. svn directory will now used before building the tarball

Package approved.

New Package SCM Request
=======================
Package Name: guayadeque
Short Description: Audio player and organizer
Owners: martinkg
Branches: f19 f20
InitialCC:

Git done (by process-git-requests).

the package built successfully
http://koji.fedoraproject.org/koji/taskinfo?taskID=6091805
http://koji.fedoraproject.org/koji/taskinfo?taskID=6091834
http://koji.fedoraproject.org/koji/taskinfo?taskID=6091893

guayadeque-0.3.6-16.svn1885.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/guayadeque-0.3.6-16.svn1885.fc19

guayadeque-0.3.6-16.svn1885.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/guayadeque-0.3.6-16.svn1885.fc20

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

guayadeque-0.3.6-16.svn1885.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

guayadeque-0.3.6-16.svn1885.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.