OpenCPN Build on Debian

[HamishB]

note that Frankie has added a new "tarballs" dir in the alioth svn repo, so for now we can just do it by hand and stash the stable releases there. (plus our current 2.4.beta bootstrapping attempts)


Hamish

[HamishB]

Originally Posted by antonm

Ok. I than taking on my behalf figuring out a way to produce a tarball with dlls removed. Looks easy from first sight, but the problem is that quilt assumes those removed items to be part of debian changes made to git tree and tries to create a patch for it. I asked help on mentors and got few suggestions that I need to try:

Stripping non-free/unnecessary files out of orig.tar.gz

In future we may consider migrating from quilt to a new experimental git-buildpackage tool since both opencpn upstream and allioth now using git.

as an experiment I have made this script:
[pkg-grass] Contents of /packages/opencpn/tarballs/get_latest_from_git.sh


I have not tried a fresh `debuild` with just that and the debian/ dir from svn yet, but I wonder if a 100% fresh dir will get rid of the stale quilt problem for you? Quilt dotfiles are not stored in the debian/patches/ dir or the .orig.tar.gz. So if building from a fresh tarball + debian/ checkout, how would it ever know that the git files ever existed before?


Hamish

[HamishB]

Originally Posted by antonm

Thus I will resubmit for another peer review [...]

with most of the old stuff taken care of in the latest emails to the debian mentors and debiangis mailing lists, I'm happy for you to do that now.

probably the standards version update should happen first. (feel free to take that one)


Hamish

[antonm]

Originally Posted by HamishB

with most of the old stuff taken care of in the latest emails to the debian mentors and debiangis mailing lists, I'm happy for you to do that now.

probably the standards version update should happen first. (feel free to take that one)

Ok. Cool. I am going to check the latest ones than run lintian and if that is fine than upload for another peer review.

I will also wipe the changelog to a clean state.

[HamishB]

Originally Posted by antonm

Ok. Cool. I am going to check the latest ones than run lintian and if that is fine than upload for another peer review.

actually a couple small things from the last day or two to take care of first, mainly to make it use the OS's tinyxml instead of the embedded one.

I will also wipe the changelog to a clean state.

there's no need to throw that away, so please don't.


thanks,
Hamish

[antonm]

Originally Posted by HamishB

there's no need to throw that away, so please don't.

I think we need just to include "UNRELEASED" for existing entries in changelog than.

[HamishB]

Originally Posted by antonm

I think we need just to include "UNRELEASED" for existing entries in changelog than.

closing the ITP bug# would indicate that point in history?

another [recommended?] nice way is to change the version numbers in the changelog to all x.y.z-0, from x.y.z-1. (we should probably have been doing that anyway). AFAICT there are no x.y.z-2s to worry about.


Hamish

[HamishB]

ok, all's clear at my end. tinyxml dep is in place, and older changelog entries changes to "-0" (current one is at "-1" to keep lintian happy).

running the standards compliance update checklist to 3.9.2(?) is still needed.

a few compiler warnings remain.

valgrind analysis would be nice.

you'll want to run Lintian using sid, it shows up a bunch more. I'm doing that here using a virtual machine.


over to you,
Hamish

[antonm]

Originally Posted by HamishB

running the standards compliance update checklist to 3.9.2(?) is still needed.

Yes. But it should not be a problem.

Originally Posted by HamishB

a few compiler warnings remain.
valgrind analysis would be nice.

This should not block inclusion IMO.

Originally Posted by HamishB

you'll want to run Lintian using sid, it shows up a bunch more. I'm doing that here using a virtual machine.

I usually pin lintian to the version in unstable, also I build packages using pbuilder so it builds agains the clean state in unstable.

So, well. Got it. Will check everything and resubmit for inclusion.

[antonm]

Originally Posted by HamishB

ok, all's clear at my end. tinyxml dep is in place, and older changelog entries changes to "-0" (current one is at "-1" to keep lintian happy).

Looks like there are some upstream changes in 2.4.708 that make tinyxml dep patch fail to apply. Will have to check that.

[antonm]

Well. There are few things that we need to do more. I have made several updates in svn:

1. Fixed tinyxml patch to work fine with 2.4.708
2. Included "dfsg" to version number since we using stripped tarballs. I also updated the script to strip out zlib and bzip sources since it is not really needed as we use debian libs.
3. Added DEP-5 compatible copyright header. Actually this was requested from Paul and the debian will most like be moving to them in the future. I also think that such file is valuable for us since it clear out copyright issues of all the files.

For the item 3 we will need more work. Please have a look and the copyright file:

[pkg-grass] Contents of /packages/opencpn/trunk/debian/copyright

it's should be clear how it is structured. I did a first round over the code and collected the copyright info. I am sure there are missing files and/or errors. We need to review it one more time and make corrections.

4. While patched build creates /usr/lib/opencpn-plugins directory it still install plugins to /usr/lib/opencpn and opencpn-plugins is empty. We will need to fix this.

[HamishB]

Originally Posted by antonm

Well. There are few things that we need to do more. I have made several updates in svn:

thanks

2. Included "dfsg" to version number since we using stripped tarballs. I also updated the script to strip out zlib and bzip sources since it is not really needed as we use debian libs.

tarball making script:
I would not bother to remove bzip2 and zlib there, as it is done by
'rules' already and is not needed for dfsg-ness, which is the reason
for making the tarball.


+dfsg into binary package version number:
as our build will be bit-for-bit identical to one built from a non-
stripped version of the source (the only difference between the
source tarballs being unused code), I don't see a point in adding
the +dfsg to the binary package version, it clutters for no reason.


instead of putting the new tarballs in svn, the latest idea is to
put their md5sum in svn and put the tarball at
Index of /tarballs
(get_latest_from_git.sh updated with details which I hadn't checked in)

4. While patched build creates /usr/lib/opencpn-plugins directory it still install plugins to /usr/lib/opencpn and opencpn-plugins is empty. We will need to fix this.

I'll try and take care of that today.

Also I will check if docs/images are still dispersed correctly after the path renames there.


Hamish

[antonm]

Originally Posted by HamishB

tarball making script:
I would not bother to remove bzip2 and zlib there, as it is done by
'rules' already and is not needed for dfsg-ness, which is the reason
for making the tarball.

That's ok. The only concern might be occupied space, but since it is one source for all arch and small data looks like it is not an issue. We will have to list zlib and bzip2 in the copyright file then.

Originally Posted by HamishB

+dfsg into binary package version number:
as our build will be bit-for-bit identical to one built from a non-
stripped version of the source (the only difference between the
source tarballs being unused code), I don't see a point in adding
the +dfsg to the binary package version, it clutters for no reason.

I am not sure if it will be build by autobuilder fine. For some reason pbuilder was not able to find the original tarball on my side. Not sure if there is a way to tell it find tarball with dfsg. I can ask on mentors.

Originally Posted by HamishB

instead of putting the new tarballs in svn, the latest idea is to
put their md5sum in svn and put the tarball at
Index of /tarballs
(get_latest_from_git.sh updated with details which I hadn't checked in)

Ok. That's perfectly fine and even better then svn. Maybe we need to move all tarballs there and remove the directory out of svn so no confusion? I can do it if no objections.

Please also check my message:

Re: Bug#538067: RFS: opencpn

I know that there are some info about it in this forum thread and mailing lists,
just I did not reread them yet and put to copyright what I found out by now.

[HamishB]

Originally Posted by antonm

Ok. That's perfectly fine and even better then svn. Maybe we need to move all tarballs there and remove the directory out of svn so no confusion? I can do it if no objections.

to keep an audit trail I thought to put the tarball on the alioth webspace, and for the uploader to commit the md5sum to the debiangis svn.

I had not bothered to delete the old tarballs from alioth svn, as those bits are now in the SCM db forever, but no objection to removing them now. (done.) I would like to keep the md5sums and stripping script there though, so anyone coming across it knows where to look for our source.. the url is not entirely intuitive if you didn't have historic knowledge of debiangis.


thanks,
Hamish

[HamishB]

Good news, opencpn-2.5.0-1 has been uploaded to the Debian "NEW" queue to be reviewed by the ftpmasters.

keep an eye on http://packages.debian.org/opencpn in the coming weeks.


Thanks for Anton for his help in packaging it, and Frankie from DebainGIS for the upload.


fingers crossed,
Hamish