[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FreeDiams (no) qmake Problem ;)



On Sat, Mar 27, 2010 at 11:31:39PM +0100, Eric MAEKER wrote:
> 3) correcting debian/rules (read freediams build process documentation) :


Well, as I said, I have read the doc and I took over your old rules
files with this commend in the first place.

> From
> override_dh_auto_configure:
> 	qmake-qt4 -r -config release "CONFIG+=LINUX_INTEGRATED" freediams.pro
> #	qmake-qt4 -r -config release "CONFIG+=LINUX_INTEGRATED"  
> "INSTALL_ROOT_PATH=$(CURDIR)/debian/tmp/usr/" freediams.pro

This was just my first try to fix the problem.

> To
> override_dh_auto_configure:
> 	qmake-qt4 -r -config release "CONFIG+=LINUX_INTEGRATED"  
> "INSTALL_ROOT_PATH=$(CURDIR)/debian/tmp/usr/" freediams.pro

This just reintroduces the old behaviour which does show the problem
for me.  I attached a build log for your inspection.  It contains this
very call and ends up in the very strange installation path which
simply duplicates $(CURDIR).

> 	Will install in /tmp/buildd/freediams-0.3.0/debian/tmp/usr/ as shown in 
> project messages
> 	[...]
> 	Project MESSAGE: Binary :
> 	Project MESSAGE: * From : /tmp/buildd/freediams-0.3.0/bin
> 	Project MESSAGE: * To : /tmp/buildd/freediams-0.3.0/debian/tmp/usr//bin
> 	[...]

Are the files *really* installed in $(CURDIR)/tmp/usr/bin?  Could
somebody please give it a try if there is something wrong on my
side (which I can not believe, because I tested on three different
machines in pbuilder and with plain debuild.

> ...
> W: freediams: binary-or-shlib-defines-rpath ./usr/lib/freediams/ 
> libUtils.so plugins
> W: freediams: binary-or-shlib-defines-rpath ./usr/lib/freediams/ 
> libUtils.so.1 plugins
> W: freediams: binary-or-shlib-defines-rpath ./usr/lib/freediams/ 
> libUtils.so.1.0 plugins
> W: freediams: binary-or-shlib-defines-rpath ./usr/lib/freediams/ 
> libUtils.so.1.0.0 plugins
> ...

I can confirm this rpath issue from previous version (I think freediams
0.1.0) but that's not an important problem.

> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> pixmap/16x16/filesaveas.png
> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> pixmap/16x16/pencil.png
> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> translations/qt_fr.qm
> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> pixmap/16x16/unlock.png
> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> translations/qt_de.qm
> W: freediams-data: executable-not-elf-or-script ./usr/share/freediams/ 
> pixmap/16x16/lock.png

You probably should fix the permissions in your upstream tarball.  But
that's also a simple thing compared to the build problem.

> 13) Errors to be corrected
>
> 	When dpkg -i freediams-0.3.0_i386.deb
> 		--> no dependence to datas ? FreeDiams can not work without its  
> databases.
> 	Documentation path is wrong in the application :
> 		Doc is installed in ./usr/share/doc/freediams-doc/html
> 		not in ./usr/share/freediams/doc/freediams/html
> 		I'll give you a patch soon (bug is in plugins/coreplugin/settings.cpp 
> when setting path).

If you want to spend your time on this it is OK, but I cen perfectly
deal with this.  The only problem I seem to be unable to solve is the
strange installation path issue.

> 	Some bugs I've pleasure to think they are already corrected now in  
> v0.4.0 ;)

IMHO we should target at this version anyway.

> As a conclusion, everything works fine. Build process does only give  
> warnings. No special patch are needed.
>
> Can you confirm ?

No, unfortunately not.  Feel free to commit your changes to SVN and I
will perhaps try again - perhaps I have overlooked something.  Anybody
else able to confirm success or failure?

Thanks for testing anyway

     Andreas.

-- 
http://fam-tille.de


Reply to: