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
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100328183933.ga21...@an3as.eu
