[ANNOUNCE] src2pkg-2.1 released

ponce · 01-17-2010, 01:26 PM

everything ok with latest release on 64-current

veeall · 01-18-2010, 09:19 AM

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:

Code:

Notice - The configuration files are in a subdirectory: qmmp
Found 'cmake' configuration - Configuring using:
   cmake -DCMAKE_INSTALL_PREFIX:PATH=/tmp/qmmp-0.4.0svn1503-x86_64-1/usr -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=Release

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:

Code:

m@masin:~$ qmmp                                                                       
General: The file '/home/m/1' is not a valid Qt plugin.                               
General: The file '/home/m/2628Creating web pages, the right way.pdf' is not a valid Qt plugin.                                                                             
General: The file '/home/m/dep.log' is not a valid Qt plugin.

etc.

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

Code:

bash-3.1# partitionmanager
error: g_spawn_command_line_sync: Failed to execute child process "/tmp/partitionmanager-1.0.1-x86_64-1/usr/bin/partitionmanager-bin" (No such file or directory)
/usr/bin/partitionmanager: line 29: /tmp/partitionmanager-1.0.1-x86_64-1/usr/bin/partitionmanager-bin: No such file or directory

while both files are there:

Code:

/usr/bin/partitionmanager                                                                                         
/usr/bin/partitionmanager-bin

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.

gnashley · 01-18-2010, 09:39 AM

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:

Code:

CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="${PKG_DIR}/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out )

to this:

Code:

CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out )

Perhaps that will fix it. Have I mentioned lately how I detest cmake?? Very hard to get consistent results using the same options....

Laodiceans · 01-18-2010, 10:02 AM

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.

veeall · 01-18-2010, 10:39 AM

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.

gnashley · 01-18-2010, 10:44 AM

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?

gnashley · 01-18-2010, 10:54 AM

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!

ponce · 01-18-2010, 10:55 AM

in my opinion, experimenting/improving is always fun

cmake is superLOL
(trying to mitigate the drama)

veeall · 01-18-2010, 10:57 AM

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

Code:

Found source archive: partitionmanager-1.0.1.tar.bz2                                   
Creating working directories:                                                          
   PKG_DIR=/tmp/partitionmanager-1.0.1-x86_64-2                                        
   SRC_DIR=/tmp/partitionmanager-1.0.1-src-2                                           
Unpacking source archive - Done                                                        
Correcting source permissions - Done                                                   
Checking for patches - None found                                                      
Found 'cmake' configuration - Configuring using:                                       
   cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DLIB_SUFFIX=64 -DCMAKE_BUILD_TYPE=Release   
Compiling sources - Using: 'make'                                                      
Compiling has been - Successful!                                                       
Checking for Makefile rule: 'install' Okay                                             
Checking support for DESTDIR (or similar) - Found CMAKE_INSTALL_PREFIX                 
grep: partitionmanager-test-make-install.log: No such file or directory                
grep: partitionmanager-test-make-install.log: No such file or directory                
Installing using CMAKE_INSTALL_PREFIX - Using:                                         
   make CMAKE_INSTALL_PREFIX=/tmp/partitionmanager-1.0.1-x86_64-2/usr install          
Notice - Possible error running 'make install'                                         
FATAL! Running make install has failed with error: 1                                   
Try using INSTALL_LINE 'make -i install'  Exiting...

tuxdev · 01-18-2010, 10:58 AM

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.

veeall · 01-18-2010, 10:55 PM

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

gnashley · 01-19-2010, 01:13 AM

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

Code:

--- ./06-configure_source.00	2010-01-17 11:26:42.000000000 +0100
+++ ./06-configure_source	2010-01-19 08:14:55.000000000 +0100
@@ -619,7 +619,7 @@
 		FORCE_ZERO_LENGTH=YES
 		#[[ $INSTALL_TYPE = JAIL ]] && INSTALL_TYPE=DESTDIR
 	elif [[ -f "$CONFIG_DIR"/CMakeLists.txt ]] ; then
-		CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="${PKG_DIR}/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out )
+		CMAKE_OPTIONS=$(echo -DCMAKE_INSTALL_PREFIX:PATH="/${PRE_FIX}" -DLIB_SUFFIX=${LIBDIRSUFFIX} -DCMAKE_BUILD_TYPE=Release ${EXTRA_CONFIGS} |white_out )
 		if ! [[ $(which cmake) ]] ; then
 			echo $RED"FAILED! "$NORMAL"No cmake found in path. "$RED"Exiting..."$NORMAL
 			FAILED="CONFIGURATION - Missing cmake  in: $FUNCNAME"
@@ -642,6 +642,7 @@
 			else
 				cmake .. $CMAKE_OPTIONS
 			fi
+			INSTALL_TYPE=SAFE
 		fi
 		
 	elif [[ -f "$CONFIG_DIR"/Makefile.PL ]] || [[ -f "$CONFIG_DIR"/Build.PL ]] || [[ -f "$CONFIG_DIR"/make.pl ]] ; then

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.

veeall · 01-19-2010, 05:00 AM

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!

gnashley · 01-19-2010, 06:08 AM

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.