Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: q - Equational programming language https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194519 tibbs@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink@xxxxxxxxxxxxx |tibbs@xxxxxxxxxxx OtherBugsDependingO|163776 |163779 nThis| | ------- Additional Comments From tibbs@xxxxxxxxxxx 2006-06-14 10:52 EST ------- Adding back the commends and reapplying the status changes lost in the crash: ------- Additional Comments From tibbs@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxx 2006-06-11 22:49 EST ------- Hmmm. Things are looking good, but what's /usr/lib/q/libtool? ------- Additional Comments From gemi@xxxxxxxxxx 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@xxxxxxxxxxx 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@xxxxxxxxxx 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@xxxxxxxxxxxx 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 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review