Bug 194519

Adding back the commends and reapplying the status changes lost in the crash:

------- Additional Comments From tibbs.edu  2006-06-10 15:49 EST -------
This is really a packaging of RC2, correct?  I think it would be good to
indicate that in the version.  According to the naming guidelines, you should
use q-7.1-0.1.rc2. and increment the second "1" for each RPM release until 7.1
is released, at which you can call it q-7.1-1.

Unfortunately I'm having trouble building in mock:

gcc -DYEAR=\"2006\" -DSYSINFO=\"x86_64-redhat-linux-gnu\"
-DQPATH=\".:/usr/share/q/lib:/usr/lib64/q\" -DQEXEC=\"/usr/bin/q\"
-DLIBTOOL=\"/usr/lib64/q/libtool\" -DCC=\"gcc\" -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buf
fer-size=4 -m64 -mtune=generic -o qcc qcc-qcc.o qcc-qbase.o qcc-sys.o
qcc-getopt.o qcc-getopt1.o  -lgmp -lcrypt -lutil -lnsl -lm
PATH=".:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
QPATH="../stdlib:../modules/clib:../modules/clib" ./q ./qcwrap.q ./qcwrap.q
def: error loading module
Warning: 268 unresolved external symbols
! File def, line 297: Value mismatch in definition
make[2]: *** [qcwrap.c] Error 2 

Finally, with so many modules packaged, this package is probably giong to have a
monster dependency list.  Is it possible to split the packaging a bit?  Or are
you not building all of the modules listed in the %descsription?

------- Additional Comments From gemi  2006-06-10 17:00 EST -------
(In reply to comment #1)
> This is really a packaging of RC2, correct?  I think it would be good to
> indicate that in the version.  According to the naming guidelines, you should
> use q-7.1-0.1.rc2. and increment the second "1" for each RPM release until 7.1
> is released, at which you can call it q-7.1-1.
Ok.

> Unfortunately I'm having trouble building in mock:
> 
> gcc -DYEAR=\"2006\" -DSYSINFO=\"x86_64-redhat-linux-gnu\"
> -DQPATH=\".:/usr/share/q/lib:/usr/lib64/q\" -DQEXEC=\"/usr/bin/q\"
> -DLIBTOOL=\"/usr/lib64/q/libtool\" -DCC=\"gcc\" -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buf
> fer-size=4 -m64 -mtune=generic -o qcc qcc-qcc.o qcc-qbase.o qcc-sys.o
> qcc-getopt.o qcc-getopt1.o  -lgmp -lcrypt -lutil -lnsl -lm
>
PATH=".:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> QPATH="../stdlib:../modules/clib:../modules/clib" ./q ./qcwrap.q ./qcwrap.q
> def: error loading module
> Warning: 268 unresolved external symbols
> ! File def, line 297: Value mismatch in definition
> make[2]: *** [qcwrap.c] Error 2 
Maybe this is due to the bundled libtool. Is there policy how to replace this
with the fedora libtool during building?

> Finally, with so many modules packaged, this package is probably giong to have a
> monster dependency list.  Is it possible to split the packaging a bit?  Or are
> you not building all of the modules listed in the %descsription?
Not all modules are built, e.g., dx and ggi are not built. The description
needs to be modified to only included the bundled ones.
I am reluctant to make separate packages. Users normally expect the
advertised functionality and do not want to search for optional packages.

------- Additional Comments From tibbs.edu  2006-06-10 17:22 EST -------
(In reply to comment #2)
> Maybe this is due to the bundled libtool. Is there policy how to replace this
> with the fedora libtool during building?

I've used make LIBTOOL=/usr/bin/libtool.  Be sure to add a BR: libtool.

> I am reluctant to make separate packages. Users normally expect the
> advertised functionality and do not want to search for optional packages.

The problem is that normally users don't expect the installation a little
language compiler to pull in a web server.  (Note that since I don't have a
built version, I'm only guessing that the apache module would pull in apache; I
can't really comment fairly until I see the final dependency list.)

------- Additional Comments From tibbs.edu  2006-06-10 17:28 EST -------
By the way, just defining LIBTOOL on the make line doesn't work; it redefines it.

------- Additional Comments From gemi  2006-06-10 17:42 EST -------
This happens on x86_64, right? On i386 there is not such problem.
In the install I remove the .la files of the modules. This works
with i386, but I have read several times that on x86_64 these are
necessary from dynamic loading...

------- Additional Comments From gemi  2006-06-10 17:46 EST -------
(In reply to comment #4)
> By the way, just defining LIBTOOL on the make line doesn't work; it redefines it.
Could you try building manually on x86_64, but before running configure,
do 'libtoolize -c --ltdl --force'. If the compilation then works, then I
think this should be included in the .spec file.

------- Additional Comments From tibbs.edu  2006-06-10 18:39 EST -------
Unfortunately this doesn't help; the build still fails with the same error.

I do note that the configure script summary output includes "Libltdl:
uninstalled"; I'm not sure if that is useful.  I can attach build.log if you like.

------- Additional Comments From gemi  2006-06-10 19:46 EST -------
Here are some posts from the mailing list:
http://sourceforge.net/mailarchive/message.php?msg_id=16299225
http://sourceforge.net/mailarchive/message.php?msg_id=16299878
http://sourceforge.net/mailarchive/message.php?msg_id=12407077
http://sourceforge.net/mailarchive/message.php?msg_id=10938506

So there seems to some incompatibility with x86_64.

------- Additional Comments From tibbs.edu  2006-06-10 22:27 EST -------
I read up a bit and it does look like this is hopeless on any 64-bit arch.  So I
suggest just doing an ExcludeArch and opening the usual tracking bug.  Maybe
some 64-bit experts would be able to lend a hand.

In the meantime I've build on i386 development.  rpmlint has a few things to
complain about:

W: q symlink-should-be-relative /usr/bin/gqbuilder
/usr/share/q/gqbuilder/gqbuilder.q

Should be easy to fix up.

E: q info-dir-file /usr/share/info/dir

Don't package this file.

W: q-devel no-documentation

Ignorable.

Having a build, I can look at the dependency list.  It looks like this will pull
in all of TCL and Tk, plus Imagemagick and unixODBC.  That's pretty heavy, but
not insane as if it pulled in octave or a web server.  By the way, it doesn't
look like you build the Apache module.  I doubt it's worth it to do so,
honestly, but you probably want to take that out of the description.

------- Additional Comments From gemi  2006-06-11 06:27 EST -------
(In reply to comment #9)
> I read up a bit and it does look like this is hopeless on any 64-bit arch.  So I
> suggest just doing an ExcludeArch and opening the usual tracking bug.  Maybe
> some 64-bit experts would be able to lend a hand.
Ok.

> W: q symlink-should-be-relative /usr/bin/gqbuilder
> /usr/share/q/gqbuilder/gqbuilder.q
In fact this script depends on gnocl (GTK/Gnome bindings for Tcl), which
I intend to submit some time. Probably best to remove this for now.

> E: q info-dir-file /usr/share/info/dir
> Don't package this file.
How is it that this file is sometimes created, sometimes not?

> Having a build, I can look at the dependency list.  It looks like this will pull
> in all of TCL and Tk, plus Imagemagick and unixODBC.  That's pretty heavy, but
> not insane as if it pulled in octave or a web server.  By the way, it doesn't
> look like you build the Apache module.  I doubt it's worth it to do so,
> honestly, but you probably want to take that out of the description.
The octave module is built, however it isn't linked agains liboctave, so
there is no dependency. However using the module requires octave to be present.
Should we leave it as is, or create a separate package with the module,
that depends on octave?
Also, I try to build the apache module as a separate package, with the
name q-httpd.


------- Additional Comments From gemi  2006-06-11 10:14 EST -------
I have called the apache module "mod_q" following the usual naming rules.
I refrained from separating the octave package, since using the octave
module simply fails with an error that octave could not be found.

http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/q-7.1-0.2.rc2.src.rpm

------- Additional Comments From tibbs.edu  2006-06-11 22:49 EST -------
Hmmm.  Things are looking good, but what's /usr/lib/q/libtool?

------- Additional Comments From gemi  2006-06-12 06:06 EST -------
I now make it use the system libtool. 
The final version 7.1 has been released:
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/q-7.1-1.src.rpm

------- Additional Comments From tibbs.edu  2006-06-12 23:18 EST -------
The only thing I see now is:
W: mod_q doc-file-dependency /usr/share/doc/mod_q-7.1/myreq.q /usr/bin/q

myreq.q shouldn't be executable.  I'll just assume you'll fix this.

Some of the provides of the main q package are a bit scary because they are
named similarly to other libraries.  I checked them all and they don't cause any
conflicts but it's best to be careful.  I've marked them with a question mark in
the dependency list below.

I'm going to go ahead and approve this because the only blocker is the myreq.q
thing.  But let's think about how to deal with those odd library provides.

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
  5fe46c40dc8530d4bf1ce23acc42d57a  q-7.1.tar.gz
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (i386, development).
X rpmlint complains about myreq.q and has another ignorable warning.
? final provides and requires are sane:
  mod_q-7.1-1.fc6.i386.rpm
   mod_q.so
   mod_q = 7.1-1.fc6
  =
X  /usr/bin/q (this is the doc file dependency I'm assuming you'll fix)
   httpd >= 2.0.40
   libqint.so.2

  q-7.1-1.fc6.i386.rpm
?  clib.so
?  curl.so
?  gdbm.so
   libq.so.8
   libqint.so.2
?  magick.so
?  octave.so
?  odbc.so
?  swig.so
?  tk.so
?  xml.so
   q = 7.1-1.fc6
  =
   /bin/sh
   /sbin/install-info
   /sbin/ldconfig
   libMagick.so.10
   libX11.so.6
   libcurl.so.3
   libgdbm.so.2
   libgmp.so.3
   libncurses.so.5
   libodbc.so.1
   libq.so.8
   libqint.so.2
   libreadline.so.5
   libtcl8.4.so
   libtermcap.so.2
   libtk8.4.so
   libxml2.so.2
   libxslt.so.1
   libz.so.1

  q-devel-7.1-1.fc6.i386.rpm
   q-devel = 7.1-1.fc6
  =
   /bin/sh
   libgmp.so.3
   libncurses.so.5
   libq.so.8
   libqint.so.2
   libreadline.so.5
   libtermcap.so.2
   libtool
   libutil.so.1
   q = 7.1-1.fc6

* shared libraries are present; ldconfig is called and where necessary,
unversioned libraries are in the devel package.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions are appropriate (myreq.q in mod_q as above)
* %clean is present.
* %check is not present; no test suite upstream.
* scriptlets present and sane.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers present and in -devel package.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

APPROVED

------- Additional Comments From gemi  2006-06-13 03:16 EST -------
(In reply to comment #14)
> The only thing I see now is:
> W: mod_q doc-file-dependency /usr/share/doc/mod_q-7.1/myreq.q /usr/bin/q
> 
> myreq.q shouldn't be executable.  I'll just assume you'll fix this.
Ok.

> Some of the provides of the main q package are a bit scary because they are
> named similarly to other libraries.  I checked them all and they don't cause any
> conflicts but it's best to be careful.  I've marked them with a question mark in
> the dependency list below.
These provides are are quite useless. Is it possible to make rpmbuild
not generate them?

------- Additional Comments From paul  2006-06-13 06:17 EST -------
(In reply to comment #15)
> > Some of the provides of the main q package are a bit scary because they are
> > named similarly to other libraries.  I checked them all and they don't cause any
> > conflicts but it's best to be careful.  I've marked them with a question mark in
> > the dependency list below.
> These provides are are quite useless. Is it possible to make rpmbuild
> not generate them?

This sort of issue crops up quite often in perl packages, so the Packaging/Perl
page on the wiki has some suggestions for how to get rid of unwanted Requires
and Provides.

http://fedoraproject.org/wiki/Packaging/Perl

Just a note that I spent some time trying to get those unwanted Provides:
filtered out and I didn't have any luck.  I verified that RPM isn't calling the
script I name in __find_provides; I have no idea why.

Built on FC4, FC5 and FC6.
The following got rid of the unwanted provides:
%define _use_internal_dependency_generator 0
cat > %{name}-prov <<EOF
#!/bin/sh
%{__find_provides} $* |\
  sed -e '/\.so[ \t]*$/d'
EOF

%define __find_provides %{_builddir}/%{name}-%{version}/%{name}-prov
chmod +x %{__find_provides}

Ah, it was _use_internal_dependency_generator, which you don't have to set when
you're working with Perl modules.

More specifically, unlike for __find_provides and __find_requires to take
effect, __perl_provides and __perl_requires don't require disabling the internal
dep generator.