OpenCPN Build on Debian

[antonm]

I am working on Debian package of OpenCPN. The one on SourceForge is fine, but I think that OpenCPN is nice and should be pushed into the Debian distribution. Since no "debian" folder is provided neither in tarball nor in CVS, I had to recreate those packaging things from scratch.

During the building I met the problem with glib and wxWidgets2.8 both declaring GSocket, there are some notices on this forum from people that also met this problem. Meanwhile the bug on Debian wxWidgets2.8 package has been created (#568006) as it looks like that it is broken there.

Of cause after some hacking of source code, this can be solved even now, but it does not look to be proper way of doing things and I would better wait for #568006 bug to be clarified. But it is still interesting how the deb package available at SourceForge has been built and was the above mentioned problem somehow dealt with?

Can the "debian" folder used for building deb package be published in CVS along with other code if possible?

[idpnd]

There has been some work on a fix at the opencpn end of things akin to what was done at amarok to overcome the wxwidgets issue. HamishB (this forum) was also interested in getting the debian package going. Certainly also a means of attracting more geeks

[antonm]

Originally Posted by idpnd

There has been some work on a fix at the opencpn end of things akin to what was done at amarok to overcome the wxwidgets issue.

That thread has people that are able to build on Ubuntu fine. Most likely the deb on SourceForge is also built on it.

According to the changelog for Ubuntu wx package and my best guesses:

Add debian/patches/svn61009_fix_ftbfs.dpatch patch taken from upstream
SVN rev 61009, fix FTBFS caused by new versions of glib.

This patch should do it, but it looks to be already included to the Debian.

Anybody tried to build OpenCPN on Debian besides me?

[antonm]

Originally Posted by idpnd

There has been some work on a fix at the opencpn end of things akin to what was done at amarok to overcome the wxwidgets issue.

Yeah! The patch lin_patch.zip.doc solves this and I was able to build OpenCPN on Debian.

The only wondering remains still is about the deb on SourceForge. Anybody knows how it was built? Did I get right that this particular problem with the build that I faced appeared in the code after the deb was built (05 Jan 2010)?

[cagney]

The GSocket problem has been apparent in OpenCPN since October, when building 1.3.4 on Ubuntu 9.10.
We have to ask Dave, but I think that he builds the .deb using an older version of Ubuntu, so he never has the problem with the newer version of glib and conflicting GSocket's.

Thomas

[HamishB]

Hi there,

Originally Posted by antonm

I am working on Debian package of OpenCPN.

I'm glad to hear it!

Can the "debian" folder used for building deb package be published in CVS along with other code if possible?

yes please

Anybody tried to build OpenCPN on Debian besides me?

yes I have built it and am running it on Lenny.


some points:

• I think the GSocket thing doesn't affect Debian the way it does Ubuntu. There's a critical clash of versions which was not present in Lenny (too old) and the updated wx has already flowed into sid+testing; so it's only an issue with the version of wx they are shipping with Ubuntu Karmic/Lucid (although I expect Lucid's pkg will get updated before they release) [I could be totally wrong of course]
• I'm a member of the DebianGIS team and can put the debian/ folder into our SVN repo at Alioth. Even better would be for us to recruit you then you can take the lead on maintaining it . Please join the DebianGIS mailing list. DebianGis - Debian Wiki
• It would help if you ran your package through lintian to check for common issues.
• I'm keen to see this happen.

what version of debian do you use?


regards,
Hamish

[idpnd]

Hello Hamish, the "GSocket issue" (I assume youre referring to the wxwidgets issue) is fixed for ubuntu-wxwidgets now thanks to Cagneys efforts, this should be fine..

[hackoon]

Maybe you can include my patch to solve the UPPERcase problem in linux

[Psyches]

Originally Posted by hackoon

Maybe you can include my patch to solve the UPPERcase problem in linux

Thanks hackoon...looks like this patch has problems on win32. Is there a bug for the uppercase problem, or a full description of it? I'm not as familiar with cm93 charts, or what their case is expected to be.

If someone else can also confirm that it solves cm93 problems on linux, we can go from there.

Mark

[idpnd]

There was some discussion of it in one of the older threads, the case sensitive nature of linux file management doesn't permit using C-MAP files with all uppercase names or something along those lines. Does it upset your windows build?

[hackoon]

The problem lies in the distinction of UPPER and lower case in linux. mounting vfat, ntfs and isofs shows CM93 files in lower case. There is not much voodoo in the patch so I'm surprised it gives problems under win32 (can you specify them?)

[Psyches]

Originally Posted by idpnd

There was some discussion of it in one of the older threads, the case sensitive nature of linux file management doesn't permit using C-MAP files with all uppercase names or something along those lines. Does it upset your windows build?

Thanks idpnd & hackoon, I haven't tried the build yet - a quick review of the patch shows it won't work as expected on win32 case insensitive filesystems. That can be addressed, I just want to fully understand the problem first. For example, are cm93 names sometimes mixed case, and this is a well known issue that somehow has slipped through the cracks for a long time? I thought Dave had addressed this earlier, and I don't have much context.

If you have an sf.net bug report handy and links to forum posts, I can educate myself.

Mark

[hackoon]

some filenames on my cm93-isofs mounted in linux

/Cm93/Limits.dic
/Cm93/cm93obj.dic
/Cm93/00300000/a/00300000.a

the last one is quite important to recognise CM93.
Can you show me where exactly it breaks win32?

some previous discussion:
http://www.cruisersforum.com/forums/f134/how-to-make-c-maps-work-in-opencpn-31931.html

[HamishB]

this may cause a dupe on ms windows, as both lines may pass the test:

--- opencpn-1.3.6.old/src/chartdbs.cpp  2010-01-02 02:01:52.000000000 +0000
+++ opencpn-1.3.6/src/chartdbs.cpp      2010-01-07 20:46:12.000000000 +0000
@@ -777,6 +777,7 @@
 
 #ifdef USE_CM93
       nAdd += SearchDirAndAddCharts(dir_path, _T("00300000.A"), pprog);     // for cm93
+      nAdd += SearchDirAndAddCharts(dir_path, _T("00300000.a"), pprog);     // for cm93
 #endif

how linux uppercases vfat file names depends on the mount options.
See the man page for `mount`. You can set shortname=[lower|win95|winnt|mixed], and different distros and people probably have different settings.

I'd suggest adding tolower() before any string comparisons, but I don't think that helps you with wx findfile tasks.. maybe wx has a built in library function to deal with this?


Hamish

[hackoon]

use some:
"#ifndef __WXMSW__"
as with kap/KAP files

Originally Posted by HamishB

I'd suggest adding tolower() before any string comparisons, but I don't think that helps you with wx findfile tasks.. maybe wx has a built in library function to deal with this?


Hamish

unfortunately there aren't any string comparison, and I didn´t find any functions in wx to solve the problem. It needs a bit of additional code to make it work with all upper/lower case combinations!