[ANNOUNCE] src2pkg-2.1 released
 

I've released src2pkg-2.1 today after fixing a few issues which prevented compilation of the src2pkg-helpers on Slackware-current.

This release includes a very few other changes which have been incorporated over the last 3 weeks since the last release. Anyone running a system with glibc>=2.10 and/or gcc-4.4.x will want to upgrade to this latest release.

The installable Slackware package is here:
http://distro.ibiblio.org/pub/linux/...1-noarch-7.tgz

Edit: The above link is updated from the original, after weeding out even more quirks with the 64-bit build of src2pkg-helpers.

The ChangeLog is available here:
http://distro.ibiblio.org/pub/linux/...2pkg/ChangeLog

Thanks to LQ members ponce, zhoun, veall, mlangdn, and Daedra for reporting and/or testing pre-release packages until we (hopefully) got everything fixed.

As usual, if anyone has any problems with src2pkg, I can be contacted directly at: < amigo AT ibiblio DOT org >

thanks to you gnashley for the quick update :)

btw, for that package I tested src2pkg with, was only for testing :D
your replies were interesting indeed, I'll try the methods you suggest :)

Thanks for the upgrade and announce it right here. I'm already using it.

BTW: I receive this:

Can you help me in that?

Hmm, still having problems... What version of Slackware are you using?

I use Slackware 13 - stable 64 bits but now I have KDE 4.3.1 installed.

New version installed fine and even successfully created a partitionmanager package(how come?!) for me, but after reading Laodiceans post i did 'cat /var/log/packages/src2pkg-helpers-0.9-x86_64-1' and it only listed these files:

I did a reinstall, end keeped an eye better on whole process, it really failed to compile 'tar' here too, on a updated slackware64-current box (without multilib and with old 2.6.29.6 kernel - if it matters:

I'm going back to src2pkg-1.9.9. I used it before and it works.

Thanks again gnashley!

Hi,

Same error (tar) here on Slackware64-current.

eddyvp

Thanks for reporting fellows - ponce has been helping out by running some tests and I think we have found the problem with tar-1.13.

I would like to mention, though, that even if the build fails for src2pkg's 'private' copy of tar-1.13, it will just use the copy already installed with teh Slackware tar package. This is why the src2pkg-helpers build doesn' fail and exit if the build of tar-1.13 fails. And, in fact, the same is true for the build of coreutils-5.2.1 -scr2pkg will just use the normal copies on your system. libsentry is the only thing that is cosidered essential. Even it could be done without, but it would limit the INSTALL_TYPE options of src2pkg. And, src2pkg is set up to not run if libsentry is not found.

I'll send out the latest changes to a couple of those have been testing to make sure we have gotten all the problems resolved before updating and announcing here.

Tks! I hope seeing this new version working fine. I use a lot your software, it is very nice and useful.

For what it is worth, today's issue of distrowatch

suggests that:
however,
the "get slack" web site lists the latest edition as 13.0, which dates, I don't recall exactly, from last summer, or early Autumn.

It may be worth a minute of time to update the version, once the bugs are worked out, else, to put a one liner at the "get slack" web site, reminding folks who visit the site, that the "current" version, is actually NOT the version described in the most recent issue of distrowatch.

Thanks,
CAI ENG

Thanks gnashley for your excellent work. Installing now. :)

Still working on some errors -this has to work for a wide variety of systems, so it is not so easy and takes some testing. The worst is that I have no 64-bit hardware to test with. I really should break down and buy some 64-bit hardware or setup a qemu installation for the purpose.

My kernel is 2.6.29.6 with Slackware 13 64 bits with upgrades until Sat Dec 19 00:09:53 UTC 2009.

Lets see, that means you are not yet using glibc-2.11.1 and gcc-4.4.2, right?

This is what I got when running src2pkg --setup:

However, I did run src2pkg on a huludesktop rpm with absolutely no problems. It seemed to work just fine. The package installed and works just fine.

I'm still with src2pkg 1.9.9. It's working fine where in my slackware 13 64 bits with updates until 19Dez.
This the slackware that I use to work. I have another partition with slackware 13 64 bits current (updated), but its only for experimental use.

The problem starts with the next update (Jan 4) in current after Dec 19, when the whole toolchain gets updated.

I'm with 13 - 64bits current from Dec 19 and received that error in tar

Hi,

A belated Happy New Year and thank you for src2pkg.

I'm using both Slackware 13.0 32- and 64-bit and have the same problem on both building netcdf-3.6.3 (http://www.unidata.ucar.edu/download..._6_3/index.jsp). netCDF is required by The Generic Mapping Tools (GMT) (http://gmt.soest.hawaii.edu). I install both in /opt so they're completely stand-alone; i.e., executables, libraries, documentation and stuff are not spread all over the system.

It seems that src2pkg ignores --exec-prefix for the library installation path but honors it for documentation, manuals, info and other stuff. Hmm.

So, what I had to do was
to get stuff installed where I wanted it to; i.e., I had to explicitly include the --libder= argument (the executables, docs and all that got put where they were supposed to be, apparently with --exec-prefix).

Did I miss something?

Thanks again for src2pkg

P.S. I'm not trying to build GMT as a package (yet) -- it's a little on the complicated side what with all the geographic data sets that need to be installed. That'll be next week...

I don't really see a better way to deal with that than what you've done. src2pkg doesn't do anything specifically with 'exec-prefix'. It's libdir that it deals with in an automatic fashion -as a way of allowing the same script to be used for both 32 and 64-bit builds without having to specify libdir in the options at all. It *does* check to see if you have specified libdir, though and doesn't arbitrarily set it if you have.

The only other alternative would be to never set libdir at all -which means you'd have to include it in the options more often -not always, but more often. The automatic setting of libdir could be done away with, but i think it would break more builds than it would fix. As it is, it nearly always does the Right Thing automatically, unless you explicitly set it. But, I'll definitely give this some thought -it probably should be basing its' automatic location on the value for prefix (or exec-prefix), but currently just does what is the most normal thing. I have looked at this before, because some configure scripts (or other build systems like rpm) use 'libdir' and 'usrlibdir', 'bindir' and 'usrbindir', etc.

At least you can be glad that I did think it through enough to not set libdir if you have already given it. I'll chew on this some more and see what I come up with. Thanks for bringing it up.

Thanks for the thoughts and, mostly, I agree but... I build non-system software; i.e., software that is not a part of Slackware, to install in the /usr/local or /opt trees. I've just never liked the idea of installing add-on software in system directories simply because it's too easy to get burned that way. So, if I build something with, say, src2pkg I'll want all of it to install in the /usr/local tree if I set --prefix=/usr/local (or just let it default for most "configure-make-make install" software).

I just remember a two-long-long-day bug finding session when somebody (twern't me!) installed a package (on a Sun production server) that just happened to have a library with the same name as a system library (we all know that that never happens, eh?) and it took too many guys too much effort for too long a time to find out why applications were blowing up. That may not be the best reason for isolation installation but it sure feels right to me -- once burned, three times shy or something like that. Never had any similar problems since.

Anyway, now that I know I'll just add the extra option when I build stuff.

Thanks again.

I am going to look at this today -it does make sense to follow the prefix or exec-prefix directives. As for using prefix=/usr/local, src2pkg is already *supposed* to trun of lots of arbitrary actions when you use it. And the libdir setting should follow that.

You really should save and use a build script for builds like that, where you add extra options:
src2pkg -N \
-p=/opt/netcdf-3.6.3 \
-e='--exec-prefix=/opt/netcdf-3.6.3 \
--libdir=/opt/netcdf-3.6.3/lib \
--enable-shared \
--enable-docs-install' \
netcdf-3.6.3.tar.gz
will create it for you. Then you can simply run:
src2pkg -X -C -A -DEST
to execute it.

Okay, I've looked at this again. It actually is doing the Right Thing by default. If you are building packages which do not use --prefix=/usr, the best thing to do is to set:
FHS_POLICY=NONE
either from the command-line:
FHS_POLICY=NONE src2pkg ...
or in your src2pkg.conf file:
[[ $FHS_POLICY ]] || FHS_POLICY=NONE

By doing that, then everything will work as expected. Your example build can be done simply like this:
FHS_POLICY=NONE src2pkg -p=/opt/netcdf-3.6.3 -e='--enable-shared --enable-docs-install' netcdf-3.6.3.tar.gz

If you want to understand the FHS_POLICY option more, have a look at the code around lines 883-988 in /usr/libexec/src2pkg/01-pre_process.

Gilbert,

You know, every time I use src2pkg I'm more impressed -- you have done a job of work, sir (and I need to spend some time carefully reading the documentation!).

I rebuilt netCDF with FHS_POLICY=NONE as you've indicated, everything installed in /opt, and I am a happy, happy camper.

Wow, zowie.

Thanks,

Thomas

Still having problems

Going back to 1.9.9.

Laodiceans, I'm going to upload a new version in a little while, but perhaps it would be good if you tested it first. I mailed a copy to a couple of people 2-3 days ago, but there was still one un-fixed problem on 64-bit, but tar-1.13 was fixed.
Did I get an email from you before? Please shoot me an email and I'll send you a copy of what I'm about to upload.

I went ahead and uploaded the new version as the testers all reported success over the lastfew days. Hopefully everything is fixed now...

Thank you, gnashley! :) Downloading, upgrading now.

everything ok with latest release on 64-current :hattip:

Just a question - is this normal when 'src2pkg -X -A -DEST' command with '-N'-generated and unmodified qmmp.src2pkg.auto script sets that -DCMAKE_INSTALL_PREFIX:

Because i twice had some strange issue with qmmp that it doesn't find its plugins after a computer restart, and if launched from commandline it seems to look for them at my home directory:


At the same time something also happened with src2pkg packaged 'partitionmanager' which also worked earlier, but now is giving this error:

while both files are there:
Reinstalling qmmp with previously compiled tgz didn't help, so i recompiled it with 'src2pkg -X -A -REAL' as root and now qmmp launched fine again.

It very well might be something in my box, because i have kdm crashing upon restart of a computer, so that i do 'Alt+F6', login as root, telinit 3 and telinit 4 to get into X and KDE.

Oh boy! Here we go again with cmake!
Is partitionmanager also using cmake? What version of cmake do you have installled.

Try this and see ifit fixes it -I don't have QT-4 installed right now in order to check this:
cd into /usr/libexec/src2pkg and make a copy of 06-configure_source
Then open the original and go down to line 622 and change this:
to this:
Perhaps that will fix it. Have I mentioned lately how I detest cmake?? Very hard to get consistent results using the same options....

With all different configurations is still wise continue to develop src2pkg? I use the 1.9 version and I like it. I hope that gnashley could do the same on 2.1.

EDIT: I upgraded to 2.1 and the tar error don't appears anymore. And all src2pkg --setup "tests" give it ok to me. I hope that now src2pkg will work fine.

Thanks.

I've restarted again to see if this problem reappear as it once did. But for now qmmp is fine.

Partitionmanager mystically 'got healed' after i reinstalled it, checked to see that it didn't really fix the problem, then recompiled the program with 'src2pkg partitionmanager-1.0.1.tar.bz2' but before even installing the newly created package i tried (just in case) to launch the app once more and it fired up. After restart previously posted error is back. So if you, Gnashley, think this is build problem rather than something fishy with my computer i'll modify the '06-configure_source' and recompile using the same command as earlier(?).

And, to mention, i'm using fully updated slackware64-current.

Well, I'm not sure it is 'wise' to do such development, but it is usually a bit of fun and good for keeping my old brain active. I do wish that cmake had not been invented, though, as supporting it has been a royal pain from the very first. I could quit working on src2pkg at any point, but if I had quit at 1.9, then anyone running Slackware current would be stuck -they'd have to downgrade or keep an old stable-13.0 installed in order to be able to build src2pkg itself -assuming that if built on an old OS it would run on the newer one -but that is not always the case.

I'd be happy if everything on our OS was not a moving target, but other folks like having their 'fun' too, so things move along whether I like it or not. Unfortunately, the 'latest' is not always the 'greatest' at a given moment -even for src2pkg. As you have discovered the last few days when *you* were better off with an older stable version. But it was *others*, who suddenly found that 2.0 wouldn't build on current who caused me to scramble to fix the problems -I had to update to the latest glibc and gcc on my development box in order to duplicate the problems.

Very glad that you have reported success with the latest build of 2.1 -now I must go fix the cmake problem ...again. I may have to write code which checks the version of cmake being used and have a separate routine for each of cmake-2.4, 2.6(but less than 2.6.2) and 2.8 as each of them behaves a different way regarding CMAKE_INSTALL_PREFIX and DESTDIR. Either that or onyl support the 'latest greatest' version of cmake...

Are we having fun yet?

This: "launch the app once more and it fired up. After restart previously posted error is back" is exactly the case. cmake and other build systems have to do something special when 'installing' a program -running a compiled program from the directory where it si compiled is not the same as running it from its *installed location*. It has to do with the linking of libraries and is too compley to try to explain here. Suffice it to say that the fact that the program will run from the compile location does not mean that it will run from the installed location.

I'll have to try and find some more sources which use cmake and run more tests to see if I can find a more definitive fix. The problem is that sources which have been prepared to be built using cmake-2.4 or cmake-2.6.(0 or 1), will not always respond the same as sources which have been correctly setup to be built using cmake-2.6.2 or 2.8. src2pkg used to work fine with cmake-2.4, until 2.6 came along. Then it was fixed for 2.6, but not 2.4. Maybe now it will consistently *not* work for any version of cmake.... Oh yes, we are having fun!

in my opinion, experimenting/improving is always fun :D

cmake is superLOL
(trying to mitigate the drama)

This time command 'bash-3.1$ src2pkg -b=2 /home/m/Download/partitionmanager/partitionmanager-1.0.1.tar.bz2' failed with:

It's really strange how badly CMake's been behaving for installs.. when I'm in "normal upstream dev" mode it handles everything else really, really well.

Oh, i get it, partitionmanager was working till i haven't deleted the build directories from /tmp.

Here's what should be the definitive fix for the cmake prefix problems, no matter what version of cmake is being used:
fix-cmake-for-good.diff
To apply the patch:
cp fix-cmake-for-good.diff /usr/libexec/src2pkg
cd /usr/libexec/src2pkg
patch -p0 < fix-cmake-for-good.diff
rm fix-cmake-for-good.diff

It does mean you'll have to be root to create the package, though. Any other fix for this would depend on detecting the version of cmake, but would probably still break sometimes if the sources were written to work with some other version of cmake than that being used.

Yep, now as root it created the proper tgz. And i didn't see the -DCMAKE_INSTALL_PREFIX with path '/tmp/.../usr' anywhere in the log any more, also.

Thanks a lot!

The fix (INSTALL_TYPE=SAFE) makes it install everything to the real root filesystem while tracking the file creation. It could use INSTALL_TYPE=REAL which is nearly the same thing, except SAFE backs up any files which might be overwritten and then restores them. It's unfortunate that you have to be root, but I don't see another way to make it work consistently -maybe in a couple of years when we might assume that everyone is using cmake newer than 2.6.1 -and only then if cmake finally settles on a single way of handling DESTDIR.
Thanks for reporting your problem so it could be fixed.