Re: RFS: jmapviewer/1.02+dfsg1-1 [ITP]
Hi Felix,
On Sat, Oct 19, 2013 at 10:09:19PM +0200, Felix Natter wrote:
> > On Fri, Oct 18, 2013 at 07:15:45PM +0200, Felix Natter wrote:
> >> I reuploaded to mentors with the above changes.
> >
> > I have checked out the Git repository and have the following remarks:
> >
> > debian/control:
> > 1. Build-Depends: default-jdk
> > Depends: openjdk-7-jre
> >
> > I have only basic Java experience but this looks suspicious to
> > me. Shouldn't the Depends rather be: ${java:Depends}
>
> I'm not sure: I have two other packages that also have Depends:
> openjdk-7-jre (or default-jre which also catches gcj) and no
> ${java:Depends}.
>
> - libjlatexmath-java has Depends: ${misc:Depends}
>
> - libjsyntaxpane-java has Depends: ${java:Depends}, ${misc:Depends}
> but this uses javahelper instead of ant build (like jmapviewer does)
>
> Unfortunately I couldn't find any documentation regardings this.
> I checked google and
> https://wiki.debian.org/Java
> https://wiki.debian.org/Java/Packaging
>
> Do you want me to check this with the debian-java folks?
Yes, please check this. The problem is that in the future default-jre
could be openjdk-8 and you get a conflict with your depends.
> > 2. Priority: extra
> > ...
> > the metapackage. So if you do not have any good reason for
> > extra please change to optional.
>
> Done.
Nice.
> > debian/rules:
> > While in README.source you are declaring that some file was removed
> > this is not reflected inside the get-orig-source target. While you
> > do the trick in the import orig step this will work when building
> > via git-buildpackage but I do not consider this good style. Simply
> > assume somebody (perhaps from some derivative distribution wants
> > to do an upgrade of the package and just uses the source he might
> > get via "apt-get source jmapviewer" and is ignoring the Git
> > repository. He will end up with the to be excluded file.
>
> When I build with:
> $ gbp buildpackage -us -uc --git-pristine-tar
>
> I get those files:
>
> $ ls -lh
> insgesamt 228K
> -rw-r--r-- 1 felix felix 135K Okt 19 21:38 jmapviewer_1.02+dfsg1-1_all.deb
> -rw-r--r-- 1 felix felix 3,8K Okt 19 21:38 jmapviewer_1.02+dfsg1-1_amd64.build
> -rw-r--r-- 1 felix felix 1,6K Okt 19 21:38 jmapviewer_1.02+dfsg1-1_amd64.changes
> -rw-r--r-- 1 felix felix 5,0K Okt 19 21:38 jmapviewer_1.02+dfsg1-1.debian.tar.gz
> -rw-r--r-- 1 felix felix 1,2K Okt 19 21:38 jmapviewer_1.02+dfsg1-1.dsc
> -rw-r--r-- 1 felix felix 68K Okt 19 21:38 jmapviewer_1.02+dfsg1.orig.tar.gz
>
> and:
> $ tar -tzf jmapviewer_1.02+dfsg1.orig.tar.gz | grep bing
> <no output>
>
> while the upstream source contains the file:
> $ tar -tzf JMapViewer-1.02-Source.tar.gz | grep bing
> jmapviewer-1.02/src/org/openstreetmap/gui/jmapviewer/images/bing_maps.png
>
> => since the .orig.tar.gz will be uploaded to the Debian archive, you
> will get the cleaned source when you run "apt-get source jmapviewer".
>
> Excluding things in this way seems to be best practice in debian-java:
> https://wiki.debian.org/Java/JavaGit#Import_upstream
>
> Am I missing something?
Yes. Assume somebody else does the following:
$ apt-get source jmapviewer
$ cd <maindir>
$ uscan --verbose
---> results in a new version tarball *including* the files that
needs to be removed.
> > However, there is a quite simple solution if you might like to
> > try the enhanced uscan[1] I have written just for the sake of
> > simplifying the deletion of files in upstream sources. I'm quite
> > positive that these changes will migrate into official uscan in
> > the not so far future. Any additional tester would be welcome.
>
> That's definitely the way to go for svn packages. I don't know whether
> it's absolutely necessary for git packages, since the cleaned source
> is both in the package and in the Debian archive.
Uscan is orthogonal to the used version control system. You should
either provide a get-orig-source target doing the removal of the file or
take the new uscan.
> > Besides those things the package also does not build for me in a clean
> > pbuilder. I have attached my build log - seems some build-depends is
> > missing.
>
> I couldn't see the missing build-depend, only the issue below.
>
> > It might be even worse: If I read
> > Cannot run program "svn": error=2, No such file or directory
> > this might lead to the suspicion that the build process might try to
> > access the internet - which is forbidden. A package should build on
> > a box on its own with out any connection.
>
> The problem was that upstream has some svn targets and targets that
> create distributions. I have now configured dh_auto_build such that
> it only executes the necessary targets:
>
> dh_auto_build -- build pack create_run_jar
Seems that's the solution - now the build works for me.
> (I don't know why it worked with gbp buildpackage since that also calls
> debian/rules build...)
My git-buildpackage is configured to call pbuilder - may be that's not
the case on your side?
So I think the last remaining issue is the question what Java-Depends to
use. Please try to contact debian-java@lists.debian.org about this.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: