Thread: [q-lang-devel] Status of debian packaging
Brought to you by:
agraef
From: Kari P. <ka...@sa...> - 2004-02-22 03:46:35
|
I've begun building a Debian package of Q. Some things I've changed to make it conform more to Debian's standards: I moved stuff away from share/q/etc and share/q/examples. I moved that stuff to /usr/share/doc/q-lang/ and /usr/share/doc/q-lang/examples/. I installed q-mode.el to where emacs can find it. Directory name "etc" implies system-wide configuration files. None of the stuff in there was that. Single-letter package names aren't allowed. I named the package as q-lang. I changed the info file to have the right section in it. It was originally like this: START-INFO-DIR-ENTRY * Q: (qdoc). The Q programming language and system. END-INFO-DIR-ENTRY In the package: @dircategory Development @direntry * Q: (qdoc). The Q programming language and system. @end direntry Most of the packaging is done, but I'm stuck with the libraries. Things work fine until I run automake again. The .so files seem to lose their suffix, I don't know if that's significant. The contents of /usr/lib/q/ are: clib curl.a gdbm.la libtool octave odbc.a tk.la clib.a curl.la ggi magick octave.a odbc.la clib.la gdbm ggi.a magick.a octave.la tk curl gdbm.a ggi.la magick.la odbc tk.a The files without suffix have their executable bit set too. This doesn't seem to be related to the debian packaging I've done, running automake and autoconf on the pristine source yields the same result. A few diagnostics on this: $ q Error /usr/lib/q/clib, line 1: parse error at or near symbol `_' $ file /usr/lib/q/clib /usr/lib/q/clib: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped $ file /usr/local/lib/q/clib.so /usr/local/lib/q/clib.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Looks like /usr/lib/q/clib.la has libraries from the build directory listed in it, under my home directory. As an example, the file /usr/lib/q/curl.la: # curl.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.2 (1.922.2.53 2001/09/11 03:18:52) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='curl' # Names of this library. library_names='curl curl curl' # The name of the static archive. old_library='curl.a' # Libraries that this one depends upon. dependency_libs=' -L/home/kari/dl/debian/q-lang-5.0/libq /usr/lib/libq.la /usr/l ib/libcurl.la -lz -lssl -lcrypto -ldl -lcrypt -lutil -lnsl -lm' # Version information for curl. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib/q' I tried automake versions 1.4, 1.6, 1.7 and 1.8 (you used 1.5 but that wasn't packaged in Debian). I need to be able to run automake again to get the needed changes properly done. |
From: Kari P. <ka...@sa...> - 2004-02-22 12:51:25
|
On Sun, Feb 22, 2004 at 05:39:21AM +0200, Kari Pahula wrote: > Most of the packaging is done, but I'm stuck with the libraries. > Things work fine until I run automake again. The .so files seem to Things work still after running automake, running aclocal again starts all the trouble. |
From: Kari P. <ka...@sa...> - 2004-02-22 18:48:32
|
On Sun, Feb 22, 2004 at 02:40:59PM +0200, Kari Pahula wrote: > On Sun, Feb 22, 2004 at 05:39:21AM +0200, Kari Pahula wrote: > > Most of the packaging is done, but I'm stuck with the libraries. > > Things work fine until I run automake again. The .so files seem to > > Things work still after running automake, running aclocal again starts > all the trouble. Of course I had to run libtoolize too. There may still be issues with it, but it seems to be in usable state already. I put the Debian package available at http://users.utu.fi/~kaolpa/debian/. I had to change a number of things in Q build process to make it conform more to the Debian standards. It'd be a good idea to build the included libraries only conditionally. glob and regex are part of libc6, thus available on linux systems universally. ltdl and readline are commonly present too. Only ltdl was configurable to use the library present in the system. There's still a few things I could say about the build process, but that'll have to wait for another time. As well as packaging the add-ons. |
From: <Dr....@t-...> - 2004-02-23 23:28:16
|
Kari Pahula wrote: > Of course I had to run libtoolize too. There may still be issues with > it, but it seems to be in usable state already. I put the Debian > package available at http://users.utu.fi/~kaolpa/debian/. Kari, I really have to thank you a lot for all your work on this. :) I'll provide a pointer to your page on the Q website asap. BTW, on which Debian system(s) will that package work? I guess that the different library versions available will make it necessary to distribute separate packages for woody, sarge and sid, no? I know that this is asking too much, but if you have some spare time maybe you could try to port the latest version, 5.1, as well? The installation layout hasn't changed much (just one new binary, qcwrap, going to <prefix>/bin). The new interpreter has some important new features, though, (e.g., full tail call elimination, Haskell-like [X..Y] enumeration syntax, Q->C translator) which should make the upgrade worthwhile. ;-) I hope that I soon have the time to install Debian on my development box so that I can try out your port myself. Then we can see whether we can get the other packages ported, too. > It'd be a good idea to build the included libraries only > conditionally. glob and regex are part of libc6, thus available on > linux systems universally. ltdl and readline are commonly present > too. Only ltdl was configurable to use the library present in the > system. Building the libraries *is* conditional. Configure will check what libraries are there and will then only build the modules for which the corresponding libraries are available. Concerning readline: You can force configure to use the installed library with --with-rl=-lreadline. Actually, that's what I do to build the system on other Linux distros, where I use a configure line like the following: CFLAGS="-O3" ./configure --prefix=/usr --with-rl=-lreadline (BTW, if you didn't use -O3 with your build, consider doing that, too, it makes a *great* difference, the interpreter will run much faster than with the default "-g -O2" flags.) Concerning glob and regex: I originally included these to resolve portability issues, specifically with Solaris and OSX which have system libs which are incompatible with the GNU versions. I could add configure flags to use the libc versions, or even make that the default behaviour on Linux, but as these libs are only a few KB I don't know whether it's really worth the effort. Cheers, Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-23 22:37:16
|
Kari Pahula wrote: > I've begun building a Debian package of Q. Some things I've changed > to make it conform more to Debian's standards: Ok. I have my gripes with scattering stuff belonging to a package all over the place, but if that's the standard under Debian, then so be it... > I moved stuff away from share/q/etc and share/q/examples. Did you move *all* the stuff in examples? (I'm asking because a FreeBSD porter did more or less the same thing, but forgot the examples in subdirs like examples/curl, etc.) > I installed q-mode.el to where emacs can find it. Yeah, actually automake has a target to do that automatically. I'm not using this right now, because it will only install to the GNU emacs directory, not xemacs, so I'm leaving that up to the users right now. > Single-letter package names aren't allowed. I named the package as > q-lang. Ok. > In the package: > @dircategory Development > @direntry > * Q: (qdoc). The Q programming language and system. > @end direntry Hmm, is that standard across different distros? Then I might add it to the qdoc.texi in cvs. Otherwise, if those categories are something Debian-specific, I'll just leave the source as it is now. > Most of the packaging is done, but I'm stuck with the libraries. > Things work fine until I run automake again. Yes, cvs had some files which should rather be regenerated when bootstrapping with a different set of autotools. That should be fixed now. If you check out the latest cvs and run autogen.sh then all autotools-related stuff should be regenerated from scratch. Unfortunately, this doesn't work with the source tarball which includes the autotools-generated files so that ppl can just run ./configure && make && make install. So you'll have to check out the sources from cvs to make this work (use tag 'R5_1' to get the latest release). -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-02-29 01:34:56
|
On Mon, Feb 23, 2004 at 11:28:35PM +0100, Albert Graef wrote: > Kari Pahula wrote: > >I've begun building a Debian package of Q. Some things I've changed > >to make it conform more to Debian's standards: > > Ok. I have my gripes with scattering stuff belonging to a package all > over the place, but if that's the standard under Debian, then so be it... It's nice to have programs follow a uniform standard once you have thousands of them. > >I moved stuff away from share/q/etc and share/q/examples. > > Did you move *all* the stuff in examples? (I'm asking because a FreeBSD I didn't touch the example installation parts of the makefiles, I just let it install everything under /usr/share/q/examples and then mv it where I like afterwards. That should get them all. > >In the package: > >@dircategory Development > >@direntry > >* Q: (qdoc). The Q programming language and system. > >@end direntry > > Hmm, is that standard across different distros? Then I might add it to The nearest thing you got to a standard is the "Installing Info Directory Files" page in texinfo's doc and the dir-example file included with texinfo. It has "Software development" category listed in it, Q would fit under that. That'd be better than leaving it unspecified, IMHO. I don't know why Debian has chosen to put most of its info docs under "Development". "Software development" is used too. This isn't really something anybody has bothered to make any official decision on. > >Most of the packaging is done, but I'm stuck with the libraries. > >Things work fine until I run automake again. > > Yes, cvs had some files which should rather be regenerated when It's been a while since I've touched libtool, all my troubles were mostly due to my own neglicience. If in doubt, rebuild scripts... > I'll provide a pointer to your page on the Q website asap. BTW, on which I've put packages of 5.1 at mentors.debian.net. It's compiled now with -O3. > Debian system(s) will that package work? I guess that the different > library versions available will make it necessary to distribute separate > packages for woody, sarge and sid, no? It's only for sid for now, but I'll try to find a sponsor for it and get it included in Debian proper. That'll take care of having packages for sarge, too. I wouldn't bother with backporting the package to woody, sarge should be released in the near future anyway. I hope you don't mind if I say a few things about the build system. All of this is IMHO, of course. I wouldn't bother to include readline with Q. Trivial replacement for readline is scanf. That's what I've seen other projects do. I wouldn't provide those --with-*-includes options. The configure script is supposed to find the required flags without user intervention. Ideally the only things the user should have to concern himself with are where to install (--prefix and friends) and what to install (--enable-* and --with-*). And --with-libname is for a 'yes' or 'no' input from the user, not the flag to pass to the compiler. If you are using GNU extensions in glob and regex, then I guess it's ok to include them. I'm still changing the build system to use the ones in glibc for my packages. I would make a --with-ltdl option, which would use the system's version if it's 'yes' and use the included one if 'no'. That would be a more uniform semantics than the special --with-installed-ltdl used now. And there's one genuine problem with the build system. You are building modules which use a library built in the same build. You have specified SUBDIRS = ... libq modules ... and rely on the order of make in subdirectories for libq to be built. You then add -L$(top_builddir)/libq -lq in _la_LIBADD in the modules' Makefile.am files. This works, but that same flag ends up in dependency_libs in the final installed .la file. This may be an security risk, if that path is writable by an user. This is what dependency_libs in clib.la looks like in a pristine build: dependency_libs=' -L/home/kari/dl/q-5.1/libq /usr/local/lib/libq.la /usr/lib/libgmp.la -lpthread -lcrypt -lutil -lnsl -lm' I can think of two ways of preventing that extra -L ending up in there. The right way: build first anything but the modules, install them, then build the modules, no need for any extra -L flags as libq is already installed. Or the hack: change the .la files themselves. I did this for myself. I did this after everything was installed: for a in $(CURDIR)/debian/q-lang/usr/lib/q/*.la;\ do sed 's/-L[^ ]+libq//' -r < $$a >$$a.fixed;\ mv $$a.fixed $$a; done You might want to do something like that in your build too. |
From: <Dr....@t-...> - 2004-02-29 07:03:06
|
Kari Pahula wrote: > The nearest thing you got to a standard is the "Installing Info > Directory Files" page in texinfo's doc and the dir-example file > included with texinfo. It has "Software development" category listed > in it, Q would fit under that. That'd be better than leaving it > unspecified, IMHO. Agreed. I'll add that in the next release. > I've put packages of 5.1 at mentors.debian.net. It's compiled now > with -O3. And Q 5.2 has just been released. ;-) It's only a couple of bug fixes this time, though. > It's only for sid for now, but I'll try to find a sponsor for it and > get it included in Debian proper. That'll take care of having > packages for sarge, too. I wouldn't bother with backporting the > package to woody, sarge should be released in the near future anyway. Sounds good. > I wouldn't bother to include readline with Q. Trivial replacement for > readline is scanf. That's what I've seen other projects do. Well, you're probably right, by now readline seems to be available almost everywhere. > I wouldn't provide those --with-*-includes options. The configure > script is supposed to find the required flags without user > intervention. Ideally the only things the user should have to concern > himself with are where to install (--prefix and friends) and what to > install (--enable-* and --with-*). And --with-libname is for a 'yes' > or 'no' input from the user, not the flag to pass to the compiler. Yes, that's exactly how my configure is supposed to work, too. I just added some functionality so I don't have to edit Makefiles and scripts just because, e.g., some lib is in /opt/sfw (SUN) or libpthread is actually called libc_r (FreeBSD). It's a convenience, and it doesn't break the standard --with-xyz={yes,no} behaviour, so why remove it? > This is what dependency_libs in clib.la looks like in a pristine build: > dependency_libs=' -L/home/kari/dl/q-5.1/libq /usr/local/lib/libq.la /usr/lib/libgmp.la -lpthread -lcrypt -lutil -lnsl -lm' Ouch. Yes, this definitely has to be fixed. On the TODO list. Thanks, Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-29 17:26:40
|
All right, the following changes are in cvs now: 2004-02-29 Albert Graef <Dr....@t-...> * qdoc.texi: added @dircategory/@direntry (suggested by Kari Pahula) * configure.in: use installed libreadline if available * src/Makefile.am: rebuild qcwrap at installation time s.t. library paths are properly set in the installed executable * ./Makefile.am: change directory order s.t. src is built last * Makefile.am (various): avoid -L<builddir>/libq flag which ends up in the installed .la files (reported by Kari Pahula) I used Programming Languages as the @dircategory (that's what, e.g., Ocaml shows up under on my system, I think that's reasonable). Kari, could you please try the latest cvs sources and let me know whether this works for you? Albert -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: <Dr....@t-...> - 2004-02-29 18:29:49
|
Albert Graef wrote: > * src/Makefile.am: rebuild qcwrap at installation time > s.t. library paths are properly set in the installed executable > > * ./Makefile.am: change directory order s.t. src is built last Forget about those, they were broken so I reverted them. -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-03-01 13:06:51
|
On Sun, Feb 29, 2004 at 06:13:53PM +0100, Albert Graef wrote: > Kari, could you please try the latest cvs sources and let me know > whether this works for you? gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl -DYEAR=2004 -DSYSINFO=i686-pc-linux-gnu -DQPATH=.:/usr/local/share/q/lib:/usr/local/lib/q -DQEXEC=/usr/local/bin/q -DLIBTOOL=/usr/local/lib/q/libtool -DCC=gcc -g -O2 -c qmlex.c qmlex.l: In function `__qq__peek': qmlex.l:399: error: `yytext_ptr' undeclared (first use in this function) qmlex.l:399: error: (Each undeclared identifier is reported only once qmlex.l:399: error: for each function it appears in.) make[2]: *** [qmlex.o] Error 1 make[2]: Leaving directory `/home/kari/download/q/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kari/download/q' make: *** [all-recursive-am] Error 2 |
From: <Dr....@t-...> - 2004-03-01 17:09:09
|
Kari Pahula wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl -DYEAR=2004 -DSYSINFO=i686-pc-linux-gnu -DQPATH=.:/usr/local/share/q/lib:/usr/local/lib/q -DQEXEC=/usr/local/bin/q -DLIBTOOL=/usr/local/lib/q/libtool -DCC=gcc -g -O2 -c qmlex.c > qmlex.l: In function `__qq__peek': > qmlex.l:399: error: `yytext_ptr' undeclared (first use in this function) > qmlex.l:399: error: (Each undeclared identifier is reported only once > qmlex.l:399: error: for each function it appears in.) > make[2]: *** [qmlex.o] Error 1 > make[2]: Leaving directory `/home/kari/download/q/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/kari/download/q' > make: *** [all-recursive-am] Error 2 Yes, that seems to be a silly bug in some flex versions, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189332 What flex version do you have on your system? Unfortunately, I don't know a workaround for this which doesn't break with the "good" flex versions. :( So I guess that you'll just have to get a working flex or use the tarball version which includes the .c's for the .l's. I meanwhile updated the q-5.2.tar.gz tarball and the other 5.2 packages on SourceForge to include the latest fixes. -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-03-06 23:27:31
|
On Mon, Mar 01, 2004 at 05:53:18PM +0100, Albert Graef wrote: > What flex version do you have on your system? I tried both versions 2.5.31 and 2.5.4a, both failed with the same error. The earlier version was packaged to Debian to provide a POSIX-compliant version of flex. As long as non-CVS versions do not die for odd flex versions, I'm not that bothered with this one. I'll see if things break when the next release comes. > for the .l's. I meanwhile updated the q-5.2.tar.gz tarball and the other > 5.2 packages on SourceForge to include the latest fixes. Having two different releases with the same version number is bad karma. I packaged 5.2 some time ago already; update your web page. I would recommend against telling the complete directories of the .deb packages, those are internal to apt-get and not really intented for human use. apt-get is the standard way for getting packages for Debian, not with dpkg -i on individual .debs. Also, please don't link my home page. |
From: <Dr....@t-...> - 2004-03-07 04:44:22
|
Kari Pahula wrote: > I tried both versions 2.5.31 and 2.5.4a, both failed with the same > error. The earlier version was packaged to Debian to provide a > POSIX-compliant version of flex. Hmm, I'm running 2.5.4 here, which doesn't exhibit this problem (but maybe SuSE patched it). Will have to look into this for the next release. > As long as non-CVS versions do not die for odd flex versions, I'm not > that bothered with this one. I'll see if things break when the next > release comes. No, the source tarball always includes the .c sources, so that should be ok. > I packaged 5.2 some time ago already; update your web page. I would Thanks. > recommend against telling the complete directories of the .deb > packages, those are internal to apt-get and not really intented for > human use. apt-get is the standard way for getting packages for > Debian, not with dpkg -i on individual .debs. > > Also, please don't link my home page. Done. Is linking to mentors.debian.net/ enough, or is there some other (package-specific) page I could link to? -- Dr. Albert Gr"af Email: Dr....@t-..., ag...@mu... WWW: http://www.musikwissenschaft.uni-mainz.de/~ag |
From: Kari P. <ka...@sa...> - 2004-03-12 03:59:15
|
On Sun, Mar 07, 2004 at 05:27:20AM +0100, Albert Graef wrote: > Done. Is linking to mentors.debian.net/ enough, or is there some other > (package-specific) page I could link to? Debian has per-package information on their web server, but mentors.debian.net doesn't. I asked for similar pages for the mentors from the admins, but it's up to them if and when they implement them. So far no Debian Developer has offered to take the package. Things have been silent, one DD just complained of a broken upload (the problem is on mentors' side). It'd be best to get Q into Debian, not just host the packages at mentors', but that's completely up to some individual DD's interest. With some luck it'd get in in time to be included in sarge. |