Re: RFS: jmapviewer/1.02+dfsg1-1 [ITP]
Andreas Tille <andreas@an3as.eu> writes:
hi Andreas,
> 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.
Still it seems a bit strange to do that because you've got the filtered
source at your fingertips ;-)
>> > 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.
How can I use the new uscan?
I guess it's here:
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=tree;f=scripts;h=ab0fe34c78f07dc30ed48536b7314b0b0fe24ff1;hb=HEAD
but how would I make every user of the package use the new uscan? Is the
"Files-Excluded: ..." hack already included in the current uscan? Sorry
for the stupid question, but I couldn't find the answer here:
https://wiki.debian.org/UscanEnhancements
Or is it that $USER only gets the "Files-Excluded:" functionality if
he/she has a new uscan, and we ignore the rest?
>> > 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?
Do you really want to add the overhead of pbuilder on every single
build? Or do you use dpkg-buildpackage instead of gbp buildpackage for
intermediate builds? Just curious :-)
> 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.
I received a reply and I think I've got it worked out:
jmapviewer declares:
Depends:
openjdk-7-jre,
${misc:Depends}
- ${misc:Depends} is used by debhelper in general, and it's required by
debhelper, see:
http://lintian.debian.org/tags/debhelper-but-no-misc-depends.html
- ${java:Depends} is only used by the 'javahelper' java build system (a
simple build system that is to be used if there is no ant script or
similar) --> for example 'libjsyntaxpane-java' depends on
${misc:Depends} and ${java:Depends}.
=> jmapviewer uses an dh/ant build system, so this is not
necessary/applicable
=> should be correct as is.
Thanks and Best Regards,
--
Felix Natter
Reply to: