Installing OpenCPN in OpenSUSE 12.2_x86-74

[larsed]

A quickie: It was beta31_stable, now I'm fetching master and will get back when I tried it!
Lars

btw saw you reduced my list of dependencies a lot.

Lars

[larsed]

Hmmm, I posted a Quick Reply short after your last. wonder where it went?
It just said that I earlier used the beta-stable and now was downloading the master-branch and would be back. Perhaps also a notion about your reduction of dependencies in your site, compared to our suggestion?

Hi Jean-Eaudes!

Well, 'after seven sorrows and eight grieves' (as we say in Sweden): building worked!
..but not with the cmake default (/usr/local) only with
cmake cmake -DPREFIX=/usr ../

Saw you had removed the whole BuildRequires:-section from opencpn.spec.in.

All the build-trials I've made have also included

CPackRPM:Warning: CPACK_SET_DESTDIR is set (=ON) while requesting a relocatable package (CPACK_RPM_PACKAGE_RELOCATABLE is set): this is not supported, the package won't be relocatable.

among the error messages.
I've wondered about that? After the installation of my own build I'm prepared to make a guess: You must install the rpm from the directory where it was built! Moving it and installing from elsewhere will cause a corrupt installation?

When I moved it into my ordinary /rpm-directory (that I maintain as one zypper-repo)and installed it from there it made OpenCPN not being able to change chart-scales, nor discovering my /dev/ttyUSB0 (only /dev/ttyS0). Moving it back to /build made it install and work correct. -Interpretation right?
And if: Can I change CPACK_SET_DESTDIR is set (=ON) to OFF and make the rpm relocatable? In that case: in which file: /OpenCPN/CMakeLists.txt, OpenCPN/build/CPackSourceConfig.make or CPackConfig.make?

Again I must say, it's an excellent navigation application you've created, the best I've seen in the Linux-world!! I hope you maintain it!

Finally a question I've asked before, you don't plan to make OpenCPN read other chart or map formats (f i wci, fx3 rik...)

Best regards
Lars
(Ok, when I submitted, there it was, my Quick reply, on page 2 ;-*)

[larsed]

PS. Found your /ocpn/chart_formats and read about wci, but still wonder about your plans about chart formats? DS.

[nohal]

Lars...

The plan has always be the same - to implement all the formats that make sense and are documented enough to be understood or have a reasonably licensed SDK. Even that takes time with the resources available.

Pavel

[larsed]

Perhaps it's up to me to try to finalize this thread?

At least, I'll give it a try concerning relocatability!
I most certainly misunderstood the meaning of

the package won't be relocatable

above!

After looking around I'm almost certain that I can install my built rpm from wherever.
I think not being relocatable means that I cannot destinate the installation to any other directory than that for which it was built (in my case -and Jean-Eaudes builds, the /usr-directory). Not optionally install it in f.i. /usr/local- or /opt-directories.

Now, with two heavy reservations (I'm no compiler AND I do not have the git-OpenCPN-dirs and files in front of me) in mind:
Could it be that make only reports a contradiction in the cmake-build with telling:

CPackRPM:Warning: CPACK_SET_DESTDIR is set (=ON) while requesting a relocatable package (CPACK_RPM_PACKAGE_RELOCATABLE is set): this is not supported, the package won't be relocatable.

?
that is "You can't set destdir and on the same time demand relocatability!"

In that case
1. Could I set CPACK_SET_DESTDIR=OFF or simply comment it out in CMakeLists.txt or in the cmake script (seen the latter suggestion in a discussion about cmake somewhere)?
And in that way make it possible to install the final rpm where I want to /usr, /usr/local or /opt.

2. Could it be just the cmake option CPACK_SET_DESTDIR=ON that makes it mandatory to use the argument -DPREFIX to cmake that Jean-Eaudes had found above:

I encountered this problem once, cmake had messed up it's internal rules. The easiest way to get it right is to remove the whole build cache and start from scratch:
cd opencpn/build/
rm -fr CMake*
cmake -DPREFIX=/usr ../
make
make package

?
-And that leaving CPACK_SET_DESTDIR ON perhaps only makes it mandatory to set any destination directory by using --DPREFIX? That is could it have worked as well with /usr/local, or /opt as it did with /usr?

The latter may contradict what Jean-Eaudes says above in the same reply:

Warning: you should set prefix to /usr as above or cpack will raise an error. I'm still searching for a correct solution for this...

If anyone is wrong here it's me with my assumption above! I've got all respect for the skill of Jean-Eaudes.

3. But anyway, what about getting rid of the cmake option CPACK_SET_DESTDIR (I think I saw it in a script section beginning with if=UNIX, then ...)?
Perhaps it could make it optional to use --DPREFIX and perhaps the location of the rpm could be set at installation?

Best regards
Lars

[nohal]

Lars...
Yes, relocatable means you can choose TO where, FROM where is not important at all.

CPACK_SET_DESTDIR=OFF (or omitting it completely) has a consequence for the DEB packages (at least): -DPREFIX has no effect on the built package and it always targets /usr
While it is actually a good thing as it's compliant with the LSB and all the "official" packages should behave like that, we want the flexibility and that's the reason CPACK_SET_DESTDIR is set to ON.
Is there actually something so much important about having a relocatable RPM that would justify changing the behaviour while generating the RPMs? Or can we just ignore that warning and live with the non-relocatable package? I personally don't think that a relocatable RPM is worth any effort, to be honest (I never ever needed it at least)...

Pavel

[larsed]

Pavel!

My intensions with the lines above were in no way to affect the way you configure your official builds!
After, with Jean-Eaudes help getting past the problem with the build requirements in OpenSuse
"BuildRequires:-section from opencpn.spec.in
bzip2-devel behövs av(needed by) opencpn-3.1.1328-1.x86_64
mesa-libGLU-devel behövs av(needed by) opencpn-3.1.1328-1.x86_64
mesa-libGL-devel behövs av(needed by) opencpn-3.1.1328-1.x86_64[/"
it was to clear out one of my misunderstandings about "relocatability".

But merely my intensions with the lines above were a way of trying to understand the cmake configuration, the "make package"-complaint and another contradiction with cmake:
The fact that if I (and my friend) used it to make a direct install:
cmake ../
make
su
passwd
make install
the installation was located in /usr/local (where I should prefer it)
And besides, there were no problems with the build requirements above!

But if we used the --DPREFIX and tried to make a package:
cmake -DPREFIX=/usr ../
make
make package
(beside the initial build requirement-problems) the created package was designated to install in /usr.

But Pavel, as you say, there is really no big problem with that!
I can live with the non-relocatable package designated to install in /usr.

Just trying to understand cmake, and if I could change the configuration for personal use!

Regards
Lars

[nohal]

Originally Posted by larsed

The fact that if I (and my friend) used it to make a direct install:
cmake ../
make
su
passwd
make install
the installation was located in /usr/local (where I should prefer it)
And besides, there were no problems with the build requirements above!

But if we used the --DPREFIX and tried to make a package:
cmake -DPREFIX=/usr ../
make
make package
(beside the initial build requirement-problems) the created package was designated to install in /usr.

But Pavel, as you say, there is really no big problem with that!
I can live with the non-relocatable package designated to install in /usr.

Just trying to understand cmake, and if I could change the configuration for personal use!

Lars,
sorry if it felt like I was offended, I definitely wasn't... Some basic facts to help you understand that the behavior you observe is actually exactly how we should behave:
According to LSB, the locally built software belongs to /usr/local - that's why it's the default behavior of most of the opensource SW, including opencpn, no matter if they use autotools or cmake - if you don't specify -DPREFIX, we install into /usr/local (and your "personal" package would also install into /usr/local) It's correct as far as I can tell.
The "official" packages, on the contrary, install to /usr - anything you install from your distro's repositories, Launchpad, OBS or whatever else I can remember installs there. So with -DPREFIX=/usr the behavior is also absolutely right
Our build process allows to produce packages that install to both /usr and /usr/local - also correct. The default is to build "local" way and you have to specify the prefix to build a "distribution" package, which is also correct as the ratio between debug and release builds is many:few.

To be LSB compliant (all the distros including SuSE are heading that direction with moderate success), you should have all the SW you built yourself in /usr/local and all the software you got from "official" sources in /usr

I would say we can forget about that one and get to the dependencies. To be honest, I got totally lost in whether there still is a problem or not. Is there?

Cheers

Pavel

[larsed]

Dear Pavel!

Glad you didn't mind! That was never my intension.

Thank you for sorting out LSB to me! I've of course noticed it, but never really thought or reflected about it.

Now to

I would say we can forget about that one and get to the dependencies. To be honest, I got totally lost in whether there still is a problem or not. Is there?

Well, i really can understand that! I myself feel totally messed up in my brain by now!
-Sometimes I wish my English would be better so I could in a few words distinctively describe what I aim at! But I can't!
-Your question first: No, the dependencies are no problem since Jean-Eaudes cut out the "rpm requires"-section from opencpn.spec.in!

But about the mess in my brain, can you have a little more patience with me? -'cause there are some things that do not "fall into place". Maybe that also explains why you got lost about the dependencies among all my words?

With the current beta my friend and I could easily make direct installations (in /usr/local) but not make packages. The dependencies were no problem here, they occurred only when we tried to build rpm's.

After Jean-Eaudes had cut out the "rpm requires"-section from opencpn.spec.in we now could build rpm, but not without --DPREFIX=/usr ../!
That is, we could not simply run
cmake ../
make package failed!
cmake --DPREFIX=/usr/local ../ we never tried.
Partly because Jean-Eaudes had said:

Warning: you should set prefix to /usr as above or cpack will raise an error. I'm still searching for a correct solution for this...

I thought this also was a warning for using any other directory!

And perhaps that was the "core" of my previous post (the one you just replied to):
Is it possible to set --DPREFIX=/usr/local, or if it isn't:, is it possible to set CPACK_SET_DESTDIR=OFF (or omitting it completely)? The latter you have already answered.

If I try to concentrate what I write above:
Dependencies were only a problem when I tried to build a package.
I still haven't succeeded in making a package that installs in /usr/local, I can only make a package that installs to /usr -and that's where my experiences contradicts what you just wrote:

Our build process allows to produce packages that install to both /usr and /usr/local

if you by package mean f.i rpm/txz/deb. -If you on the other hand by package mean the src that is the result of configure-make or cmake-make there is absolutely no contradiction!

But really Pavel, I meant what I said in my previous post: It's really no problem! I can live with OpenCPN in /usr! -It's a marvellous application that I can use in Linux!

You really have been kind enough already and I don't want to take up more of your time! If you leave my question open it is quite all right! Seriously! -But if you feel for answering me: Please don't mind all my words, is there a way I can build a rpm that installs in /usr/local?

My best regards

Lars

[larsed]

Hello again!
Below some surplus information about some experients I've made.

Since I got curious about the cmake build-process and the use of --DPREFIX -up to now I had only installed src the ordinary way; unpack, ./configure, make, make install and the src installs in /usr/local- I decided to make a few experiments.
I'll give you a brief summary of the outcome here, though it in a sence is really surplus to this thread.

To make this I set up 2 32-bit virtual machines, SuSE12.2_x86 and LinuxMint14_Nadia_x86 and updated both to yesterdays status.
I used the current Beta from git: v. 3.1.1417 (the ordinary branch, not master), and installed the recommended dependencies according to the resp Debian/Ubuntu and OpenSuSE descriptions.

In both VM's I tried to build packages, using the ordinary "recipe"
cmake ../
make
make package
and additionally changed cmake ../
to
cmake --DPREFIX=/usr/local ../ and finally
cmake --DPREFIX=/usr ../
and if the package built, I installed it to see where it installed?
In each case I simply refer to how I ran cmake, that is without DPREFIX or with DPREFIX=/usr/local or DPREFIX=/usr.

All builds were made from "scratch", that is from a restored clean VM.

And here's what I found:

In LinuxMint_Nadia_x86		Built/Failed	Installed to
cmake ../			Built		/usr/local/bin
cmake --DPREFIX=/usr/local ../	Built		/usr/local/bin
cmake --DPREFIX=/usr ../	Built		/usr/local/bin

In OpenSuSE12.2_x86		Built/Failed	Installed to
cmake ../			Failed			-
cmake --DPREFIX=/usr/local ../	Failed			-
cmake --DPREFIX=/usr ../	Failed			-

As in my "ordinary" OpenSuSE12.2_x86-64 a direct "make install" of 3.1.1417 in x86-VM succeeded, but installed in /usr/local/bin though I had set --DPREFIX=/usr (in my "ordinary" SuSE12.2_x86-64 it installed in /usr/bin).
And an ordinary build of the current Stable OpenCPN 3.0.2 without use of DPREFIX in the x86-VM succeeded -as in the "ordinary" x86-64- and created a rpm.
This finalizes my efforts to understand the cmake process, I simply give up!
Anyway this was far beyond the problem that initially made me open this thread.

Great many thanks to both Jean-Eaudes and Pavel for all your help with the initial problem, dependencies and Beta-build problems in OpenSuSE12.2_x86-64.
I now have got a working, homemade build i /usr/bin in my ordinary machine that works well!
On the way you helped me with a lot of information about cmake and also LSB as an explanation of my previous experiences.

My very best regards
Lars

[SethDart]

Well, well, well,

Just to be clear: Linux Mint is a Debian derivative and, being so, creates .deb on "make package" while OpenSuSE is a rpm based distro.
As stated is a previous message, "make package" for all rpm platforms now only support PREFIX=/usr
If you want to install to /usr/local, please use "make install"

The reason for this change is the use of a rpm template file. We had to do this because Fedora 18 uses latest rpm version that is very strict on conflicts (and all others rpm distro will follow sometimes). Packages built with default cpack cannot install on Fedora 18. There's nothing we can do on the cmake/cpack problem (I sent a patch that address some of the problems but it'll probably never be merged, the rpm template is the way to go for now)

[SethDart]

Okay, I may have found a solution. Can you try this patch:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0232fb3..78786bc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1094,6 +1094,9 @@ IF(UNIX AND NOT APPLE)
     SET(CPACK_RPM_PACKAGE_ARCHITECTURE  ${ARCH})
     SET(CPACK_RPM_PACKAGE_REQUIRES  ${PACKAGE_DEPS})
     SET(CPACK_RPM_USER_BINARY_SPECFILE "${CMAKE_SOURCE_DIR}/opencpn.spec.in")
+    SET(CPACK_OPENCPN_RPM_BINDIR "${CMAKE_INSTALL_PREFIX}/${PREFIX_BIN}")
+    SET(CPACK_OPENCPN_RPM_LIBDIR "${PREFIX_LIB}")
+    SET(CPACK_OPENCPN_RPM_DATADIR "${CMAKE_INSTALL_PREFIX}/${PREFIX_DATA}")
     SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "OpenSource Chart Plotter/Navigator")
     SET(CPACK_PACKAGE_DESCRIPTION "OpenCPN is a concise ChartPlotter/Navigator. The application supports: GPS/GPDS Position Input, BSB Raster Chart Display, S57 Vector ENChart Display, AIS Input Decoding, Waypo
     SET(CPACK_SET_DESTDIR ON)
diff --git a/opencpn.spec.in b/opencpn.spec.in
index 47d6147..3ce61c8 100644
--- a/opencpn.spec.in
+++ b/opencpn.spec.in
@@ -22,6 +22,10 @@ Vendor:         @CPACK_RPM_PACKAGE_VENDOR@
 %define _rpmfilename @CPACK_RPM_FILE_NAME@
 %define _unpackaged_files_terminate_build 0
 %define _topdir @CPACK_RPM_DIRECTORY@
+# This is a hack to change platform default path with our cmake/cpack ones
+%define _bindir @CPACK_OPENCPN_RPM_BINDIR@
+%define _libdir @CPACK_OPENCPN_RPM_LIBDIR@
+%define _datadir @CPACK_OPENCPN_RPM_DATADIR@
 @TMP_RPM_SPEC_INSTALL_POST@
 @CPACK_RPM_SPEC_MORE_DEFINE@
 @CPACK_RPM_COMPRESSION_TYPE_TMP@

It works for me: I can create packages with either PREFIX=/usr/local or PREFIX=/usr

I'll ping Dave to see if we can it included in our rc. Doesn't changes anything but rpm packaging

[nohal]

J-E...
It looks like you really got it right in 32d301283d8dca2c4b18014ce6fc7f6f90f54377. Congratulations!

Lars...
Are you SURE about

 cmake --DPREFIX=/usr ../    Built        /usr/local/bin

I can see absolutely no reason for why there should be any difference between the following and the behavior on Nadia x86

nohal@knut ~/source/opencpn/build $ cmake -DPREFIX=/usr .. >/dev/null  && cmake --build . --target package >/dev/null &&  sudo dpkg -i opencpn_3.1.1417-1_amd64.deb
(Reading database ... 284977 files and directories currently installed.)
Preparing to replace opencpn 3.1.1417 (using opencpn_3.1.1417-1_amd64.deb) ...
Unpacking replacement opencpn ...
Setting up opencpn (3.1.1417) ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for bamfdaemon ...
Rebuilding /usr/share/applications/bamf.index...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...

nohal@knut ~/source/opencpn/build $ whereis opencpn
opencpn: /usr/bin/opencpn /usr/lib/opencpn /usr/bin/X11/opencpn /usr/share/opencpn

nohal@knut ~/source/opencpn/build $ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=13
DISTRIB_CODENAME=maya
DISTRIB_DESCRIPTION="Linux Mint 13 Maya"

Pavel

[larsed]

Well, Well, Well

Jean-Eaudes and Pavel. Suppose you never noticed the line

I simply give up!

First to Pavel:
Yes! I'm sure about that! I even made it twice to be sure. -I really can't tell why my 14_x86 behaves differently than 13_x86-64?
On the other hand I can see no reason why my OpenSuSE12.2_x86 should behave differently than my x86-64, but it does. At least when it comes to build packages from current beta.
-I would'nt have written my post if I wasn't certain of my results. I've never aimed at casting any shadow over your software! I came to the conclusion that I simply didn't understand the cmake build process. Think I even said that?

And Jean-Eaudes:
I know I've overstressed that I'm no compiler, but I do know the difference between .deb and .rpm.

As stated is a previous message, "make package" for all rpm platforms now only support PREFIX=/usr
If you want to install to /usr/local, please use "make install"

-I respect what you say, in all ways (don't know how many times I've said that), but my outcome didn't quite confirm that. DPREFIX=/usr worked with beta in my x86-64 SuSE and installed correctly in /usr/bin. But it didn'nt build in my x86-version. -On the other hand I didn't have to use the DPREFIX at all with your 3.0.2 in x86-64, but used it in x86 and in x86 it installed in /usr/local.
But I really never have aimed to challenge or provoke you in anyway! In fact, when I saw my results I suspected that my x86 SuSE was corrupt in some way, that's why I tried building your stable and install your beta! Even tried to install some ordinary src's. And since everything seemed allright, I reproduced my trials with x86 SuSE and as the outcome were the same I wrote my post and in a way "checked out", giving up.

Since I have not deleted my x86 VM I can try your patch there. You were unclear if you turned to Pavel or to me with your patch? If you meant me, could you be so kind to give me some hints about it? It reminds of some lines in opencpn.spec.in or CMakeLists.txt, do Do I put them there? To replace some other? Do I run it as a script? Where do I do that or do I point it to some script (and in that case which and how?)

Lars

[nohal]

Lars...
The patch is already commited to the master branch, just fetch it from github and give it a try. I don't feel offended, but you can sure imagine how much time and resources it would consume to create a new VM for any edition of all the Linux distributions on all platforms just to test the behavior of the builds - that's why we take advantage of people like you who actually can help us to find the possible problems.

Pavel