Re: RFS: jmapviewer/1.02+dfsg1-1 [ITP]

[Felix Natter <fnatter@gmx.net>]

Andreas Tille <andreas@an3as.eu> writes:

> Hi Felix,

hello Andreas,

thanks for your review.

> 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?

>   2. Priority: extra
>      In Debian Med we have put into policy to set all packages (except
>      for instance *-dbg packages or so) Priority: optional.  The
>      rationale is that packages in extra will not be includet into
>      all QA checks etc.  There is no real sense in using extra
>      otherwise and finally if we want to make metapackages dependent
>      from our packages they should not have any lower priority as
>      the metapackage.  So if you do not have any good reason for
>      extra please change to optional.

Done.

> 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?

>   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.

> 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

(I don't know why it worked with gbp buildpackage since that also calls
debian/rules build...)

Thanks and Best Regards,
-- 
Felix Natter