[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

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:

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:


- ${misc:Depends} is used by debhelper in general, and it's required by
  debhelper, see:

- ${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

=> should be correct as is.

Thanks and Best Regards,  
Felix Natter

Reply to: