Bug 200941

Hi Fernando --

I tried building this on FC5 and got...

Making all in src
make[2]: Entering directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c/src'
 cd .. && /bin/sh /usr/src/redhat/BUILD/sooperlooper-1.0.8c/missing --run
automake-1.9 --foreign  src/Makefile
configure.ac:27: version mismatch.  This is Automake 1.9.6,
configure.ac:27: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:27: comes from Automake 1.9.4.  You should recreate
configure.ac:27: aclocal.m4 with aclocal and run automake again.
make[2]: *** [Makefile.in] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.96186 (%build)

Do you not see this?

AG

== Not an official review as I'm not yet sponsored ==
   Mock build for rawhide i386 is successfull with errors.
   Maybe you try adding autoconf in BR
   
* MUST Items:
      - dist tag is present.
      - rpmlint is silent
      - The package is named according to the Package Naming Guidelines.
      - The spec file name matching the base package sooperlooper, in the
format sooperlooper.spec.
      - This package meets the Packaging Guidelines.
      - The spec file for the package is legible.
      - The package is licensed with an open-source compatible license GPL.
      X This package dont have any License file.
      - The sources used to build the package matches the upstream source,
as provided in the spec URL. md5sum is correct (9b34c7cb8fc6daa4c7a9c17004680dac
 sooperlooper-1.0.8c.tar.gz)
    - This package successfully compiled and built into binary rpms for i386
architecture.
      - This package did not contain any ExcludeArch.
      - This package owns all directories that it creates. 
      - This package did not contain any duplicate files in the %files
listing.
      - This package  have a %clean section, which contains %{__rm} -rf
%{buildroot}.
      - This package used macros.
      - Document files are included.
      - Package did NOT contained any .la libtool archives.
      - Desktop file installed correclty.

Also,
      * Source URL is present and working.
      * BuildRoot is correct BuildRoot:       
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
      * I did not test package functionality

However i have question, when i saw build.log i found configure was called
nearly 5 times. What kind of this configuration script?

I think you should add NEWS,AUTHORS,Changelog files to your source code thru'
adding patch. then changes in %build
%build
# remove compiler option unrecognized by gcc4x
find . -type f -exec %{__perl} -p -i -e "s|-fmove-all-movables||g" {} \;
aclocal
autoheader
automake
autoconf
%configure
%{__make} %{?_smp_mflags}

(In reply to comment #1)
> I tried building this on FC5 and got...
> 
> Making all in src
> make[2]: Entering directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c/src'
>  cd .. && /bin/sh /usr/src/redhat/BUILD/sooperlooper-1.0.8c/missing --run
> automake-1.9 --foreign  src/Makefile
> configure.ac:27: version mismatch.  This is Automake 1.9.6,
> configure.ac:27: but the definition used by this AM_INIT_AUTOMAKE
> configure.ac:27: comes from Automake 1.9.4.  You should recreate
> configure.ac:27: aclocal.m4 with aclocal and run automake again.
> make[2]: *** [Makefile.in] Error 1
> make[2]: Leaving directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/redhat/BUILD/sooperlooper-1.0.8c'
> make: *** [all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.96186 (%build)
> 
> Do you not see this?

Not on my build system, but see below...

(In reply to comment #2)
> However i have question, when i saw build.log i found configure was called
> nearly 5 times. What kind of this configuration script?

Yes, I see that in my logs, I don't know what is triggering this. In my case the
build finishes successfully even with the warnings and repeated configure calls.
 And the software works. Weird. 

(In reply to comment #3)
> I think you should add NEWS,AUTHORS,Changelog files to your source code thru'
> adding patch. then changes in %build
> %build
> # remove compiler option unrecognized by gcc4x
> find . -type f -exec %{__perl} -p -i -e "s|-fmove-all-movables||g" {} \;
> aclocal
> autoheader
> automake
> autoconf
> %configure
> %{__make} %{?_smp_mflags}

Hmmm, if I do this to try to fix things then a make does trigger the error that
Anthony sees. Of course if I run aclocal/automake as suggested the error happens
again. Buggy auto* scripts?

(In reply to comment #4)
> > (In reply to comment #2)
> > However i have question, when i saw build.log i found configure was called
> > nearly 5 times. What kind of this configuration script?
> 
> Yes, I see that in my logs, I don't know what is triggering this. In my case the
> build finishes successfully even with the warnings and repeated configure calls.
>  And the software works. Weird. 
> 
> (In reply to comment #3)
> > I think you should add NEWS,AUTHORS,Changelog files to your source code thru'
> > adding patch. then changes in %build
> > %build
> > # remove compiler option unrecognized by gcc4x
> > find . -type f -exec %{__perl} -p -i -e "s|-fmove-all-movables||g" {} \;
> > aclocal
> > autoheader
> > automake
> > autoconf
> > %configure
> > %{__make} %{?_smp_mflags}
> 
> Hmmm, if I do this to try to fix things then a make does trigger the error that
> Anthony sees. Of course if I run aclocal/automake as suggested the error happens
> again. Buggy auto* scripts?

I had not realized that autogen.sh was there (that is what should be used in
these cases, I think). Running it managed to bring everything up to date with
the newer autotools versions and pointed to a missing build requirement
(gettext-devel). 

After adding that I'm getting a complete build with no configure repeats or
other warnings. I'll actually test the resulting packages and will post newer
.spec and srpms when done. 

(In reply to comment #2)
> == Not an official review as I'm not yet sponsored ==
>       X This package dont have any License file.

Added COPYING file to %doc

>       * I did not test package functionality
> 
> However i have question, when i saw build.log i found configure was called
> nearly 5 times. What kind of this configuration script?

Fixed by calling autogen.sh (and including the proper build requirements)
New spec and source rpm available at:

Spec URL: http://ccrma.stanford.edu/planetccrma/extras/sooperlooper.spec
SRPM URL:
http://ccrma.stanford.edu/planetccrma/extras/sooperlooper-1.0.8-0.2.c.src.rpm

Still errors in this package

Checking basic compilation tools ...

You do not have pkg-config correctly installed. You cannot build SooperLooper
without this tool.

Try adding pkgconfig in BuildRequires

(In reply to comment #7)
> Still errors in this package
> 
> Checking basic compilation tools ...
> 
> You do not have pkg-config correctly installed. You cannot build SooperLooper
> without this tool.
> 
> Try adding pkgconfig in BuildRequires

If that fixes the build, then it probably points to a bug in one of the devel
packages required to build this one. Any devel package containing a pkgconfig
data file (.pc file) should itself Require: pkgconfig, so anything building
using that devel package shouldn't need a buildreq of pkgconfig itself.

The packaging committee recently voted to add this to the packaging guidelines:
http://fedoraproject.org/wiki/Packaging/IRCLog20060706

So if you find any devel package pulled in as a buildreq by this package (look
in the root.log from a mock build for a list of packages) that has a .pc file
but no dependency on pkgconfig, I suggest you raise a bug on that package and
add that bug to the "Bug 200941 depends on" field below.

(In reply to comment #7)
> Still errors in this package
> 
> Checking basic compilation tools ...
> 
> You do not have pkg-config correctly installed. You cannot build SooperLooper
> without this tool.

You are corrrect but pkgconfig is being pulled in by other dependencies. See
below for more details. 

> Try adding pkgconfig in BuildRequires

This is not happening in my build system (mach based). 

In my case pkgconfig is being pulled in by either:
  jack-audio-connection-kit-devel
  libsigc++-devel
  libsndfile-devel
  libsamplerate-devel
  alsa-lib-devel
(I tested this by installing the build dependencies one by one manually in my
build system and checking on whether pkgconfig was installed as well)

Looks like liblo-devel is _not_ pulling in pkgconfig but has a .pc file:
  /usr/lib/pkgconfig/liblo.pc
(version liblo-devel-0.23-6.fc5)
Also appears to be the case for libxml2-devel (libxml2-devel-2.6.23-1.2)

What I don't understand is why, in your case, pkgconfig is not being pulled in
by the _other_ build requirements? It is happening in my build system. 

Exactly what build system are you using and how is it configured?

I did mock build for development version for FC6. There i get that error but
when i check my build system strange i found pkg-config is installed/pulled
already and installed under
/var/lib/mock/fedora-development-i386-core/root/usr/bin/pkg-config

I am really confused on this.

(In reply to comment #10)
> I did mock build for development version for FC6. 

Does this happen on fc5?

> There i get that error but
> when i check my build system strange i found pkg-config is installed/pulled
> already and installed under
> /var/lib/mock/fedora-development-i386-core/root/usr/bin/pkg-config
> 
> I am really confused on this.

Could you please post the error log from the build? I don't get that error so I
can't know where it is happening and what is the surrounding context. It could
be that the name of the pkgconfig script of one of the dependencies has changed
in > fc5 and that's why an error is being reported. 

i have FC5 system when i give
rpmbuild -ba sooperlooper.spec it worked fine. Created SRPM,RPMS
when i did mock build using FC6 development repository i got following errors in
build.log
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.52473
+ umask 022
+ cd /builddir/build/BUILD
+ cd sooperlooper-1.0.8c
+ LANG=C
+ export LANG
+ unset DISPLAY
+ find . -type f -exec /usr/bin/perl -p -i -e 's|-fmove-all-movables||g' '{}' ';'
+ ./autogen.sh

----------------------------------------------------------------------
Checking basic compilation tools ...

You do not have pkg-config correctly installed. You cannot build SooperLooper
without this tool.
error: Bad exit status from /var/tmp/rpm-tmp.52473 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.52473 (%build)

I'm updating the -devel versions of my libraries (dssi, liblo, etc) to Require
pkgconfig as per the recent decision.  This should also solve the mock build
problem here.

Created attachment 135893 [details]
Updated spec file

The attached spec file builds cleanly in mock on rawhide.

A few other problems/questions....

1. glibc reports a bug in liblo when you run it.  I have a patch for liblo and
will respin a new one for Fedora Extras shortly.

2. The gui comes up and starts the engine, however, very soon afterwards it
reports a Lost Connection: "Lost connection to SooperLooper engine.  See the
Preferences->Connections tab to start a new one".  Has anybody seen this
before?

(In reply to comment #14)
> 2. The gui comes up and starts the engine, however, very soon afterwards it
> reports a Lost Connection: "Lost connection to SooperLooper engine.  See the
> Preferences->Connections tab to start a new one".  Has anybody seen this
> before?

This was a DNS problem on my system.  Ignore.

I think there are only a couple of minor issues.  See the lines that start with
'X'.  This assumes the tweaks in my uploaded spec file are accepted.

* package meets packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.  
* build root is correct.
      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
* license field matches the actual license.
* license is open source-compatible.
* License text included in package.
* source files match upstream. md5sum...
9b34c7cb8fc6daa4c7a9c17004680dac  sooperlooper-1.0.8c.tar.gz
* latest version is being packaged.
X BuildRequires are almost proper.
  - Look at the changes I made in the spec file I attached in Comment #14 to 
    handle FC releases > 5.
* package builds in mock.
* rpmlint says:
  W: sooperlooper mixed-use-of-spaces-and-tabs
  I just use the emacs untabify command to clean these things up.
* final provides and requires are sane:
sooperlooper-1.0.8-0.2.c.fc6.i386.rpm
  sooperlooper = 1.0.8-0.2.c.fc6
  =
  libasound.so.2
  libasound.so.2(ALSA_0.9)
  libjack.so.0
  liblo.so.0
  libncurses.so.5
  libsamplerate.so.0
  libsamplerate.so.0(libsamplerate.so.0.0)
  libsigc-1.2.so.5
  libsndfile.so.1
  libsndfile.so.1(libsndfile.so.1.0)
  libstdc++.so.6
  libstdc++.so.6(CXXABI_1.3)
  libstdc++.so.6(GLIBCXX_3.4)
  libwx_baseu-2.6.so.0
  libwx_baseu-2.6.so.0(WXU_2.6)
  libwx_baseu_net-2.6.so.0
  libwx_baseu_xml-2.6.so.0
  libwx_gtk2u_adv-2.6.so.0
  libwx_gtk2u_adv-2.6.so.0(WXU_2.6)
  libwx_gtk2u_core-2.6.so.0
  libwx_gtk2u_core-2.6.so.0(WXU_2.6)
  libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)
  libwx_gtk2u_html-2.6.so.0
  libwx_gtk2u_html-2.6.so.0(WXU_2.6)
  libwx_gtk2u_qa-2.6.so.0
  libwx_gtk2u_xrc-2.6.so.0
  libxml2.so.2
  libz.so.1
* shared libraries not present.
* package is not relocatable.
* owns the directories it creates.
X Should Require hicolor-icon-theme since it places an icon in a directory owned
by that package.  This is something I just learned about myself, and plan on
cleaning up my old packages.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present
* scriptlets OK.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
X .desktop file is installed properly, but should refer to "SooperLooper", not
"Sooperlooper".
* not a web app.

(In reply to comment #16)
> I think there are only a couple of minor issues.  See the lines that start with
> 'X'.  This assumes the tweaks in my uploaded spec file are accepted.
> 
> X BuildRequires are almost proper.
>   - Look at the changes I made in the spec file I attached in Comment #14 to 
>     handle FC releases > 5.

Should this be "%{fedora}" >= 4 or just ommit it? I think current Fedora Extras
for 4 and 5 has wxGTK as the name of the package with the proper
obsoletes/provides for wxGTK2, right? Is this the version being used by your
build system?

> * rpmlint says:
>   W: sooperlooper mixed-use-of-spaces-and-tabs
>   I just use the emacs untabify command to clean these things up.

Fixed now in my copy, thanks.

> X Should Require hicolor-icon-theme since it places an icon in a directory owned
> by that package.  This is something I just learned about myself, and plan on
> cleaning up my old packages.

First time I hear about this. Makes sense as this is not something that could be
done automatically by rpm, right? Lots of packages will need this...

> X .desktop file is installed properly, but should refer to "SooperLooper", not
> "Sooperlooper".

Fixed, thanks again. 

I'll wait to hear from you on the wxGTK/wxGTK2 name before releasing another
spec/srpm. 

(In reply to comment #17)
> (In reply to comment #16)
> > I think there are only a couple of minor issues.  See the lines that start with
> > 'X'.  This assumes the tweaks in my uploaded spec file are accepted.
> > 
> > X BuildRequires are almost proper.
> >   - Look at the changes I made in the spec file I attached in Comment #14 to 
> >     handle FC releases > 5.
> 
> Should this be "%{fedora}" >= 4 or just ommit it? I think current Fedora Extras
> for 4 and 5 has wxGTK as the name of the package with the proper
> obsoletes/provides for wxGTK2, right? 

Yes, I think that's right.

> Is this the version being used by your
> build system?

Yes.

Hi nando... it's been a few months now.  Were you going to send an updated
package?  We were close to wrapping this up...

AG

Any word on this package review? 

Anthony: Under the new procedure, the fedora-review flag should be ? if you are
in the process of reviewing the package. I will go ahead and set it now. 

Fernando: Do you still wish to submit this package? 
If I don't hear back from you in a week I will go ahead and close this... 

Fernando: I am going to go ahead and close this now. 

If you decide you want to continue this submission, please feel free to re-open
this request or file a new one.