Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #9847 > unrolled thread

RFS for libimglib2-java and libparsington-java

Back to article view | Back to linux.debian.maint.java

Contents

  RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-04 14:00 +0200
    Re: RFS for libimglib2-java and libparsington-java tony mancill <tmancill@debian.org> - 2017-08-04 16:50 +0200
      Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-04 17:20 +0200
        Re: RFS for libimglib2-java and libparsington-java tony mancill <tmancill@debian.org> - 2017-08-12 17:10 +0200
          Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-13 18:30 +0200
          Re: RFS for libimglib2-java and libparsington-java Markus Koschany <apo@debian.org> - 2017-08-14 22:20 +0200
            Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-14 22:50 +0200
              Re: RFS for libimglib2-java and libparsington-java Markus Koschany <apo@debian.org> - 2017-08-15 00:10 +0200
                Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-15 11:20 +0200
                  Re: RFS for libimglib2-java and libparsington-java Markus Koschany <apo@debian.org> - 2017-08-16 20:50 +0200
                    Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-16 21:30 +0200
                      Re: RFS for libimglib2-java and libparsington-java Markus Koschany <apo@debian.org> - 2017-08-16 22:30 +0200
                        Re: RFS for libimglib2-java and libparsington-java Ghislain Vaillant <ghisvail@gmail.com> - 2017-08-18 10:30 +0200
                          Re: RFS for libimglib2-java and libparsington-java Markus Koschany <apo@debian.org> - 2017-08-18 15:20 +0200

#9847 — RFS for libimglib2-java and libparsington-java

Dear Debian Java Team,

I am undertaking the effort of packaging ImageJ version 2.x for Debian, 
which requires the packaging of quite a few Java libraries as a result 
of the modularization of the code base.

Two of the leaf packages are Imglib2 [1] and Parsington [2] for which I 
have prepared an initial package. Please keep in mind that I am new to 
Java packaging, so mistakes are likely to be made. I followed Markus' 
recent post on Java packaging as the main inspiration.

[1] 
https://mentors.debian.net/debian/pool/main/libi/libimglib2-java/libimglib2-java_4.3.0-1.dsc
[2] 
https://mentors.debian.net/debian/pool/main/libp/libparsington-java/libparsington-java_1.0.1-1.dsc

Please let me know whether there are comments. I don't have access to 
the team's VCS yet, and intend to push the packaging repository once I do.

Cheers,
Ghis

[toc] | [next] | [standalone]

#9848

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 04, 2017 at 12:50:22PM +0100, Ghislain Vaillant wrote:
> Dear Debian Java Team,
> 
> I am undertaking the effort of packaging ImageJ version 2.x for Debian,
> which requires the packaging of quite a few Java libraries as a result of
> the modularization of the code base.
> 
> Two of the leaf packages are Imglib2 [1] and Parsington [2] for which I have
> prepared an initial package. Please keep in mind that I am new to Java
> packaging, so mistakes are likely to be made. I followed Markus' recent post
> on Java packaging as the main inspiration.
> 
> [1] https://mentors.debian.net/debian/pool/main/libi/libimglib2-java/libimglib2-java_4.3.0-1.dsc
> [2] https://mentors.debian.net/debian/pool/main/libp/libparsington-java/libparsington-java_1.0.1-1.dsc
> 
> Please let me know whether there are comments. I don't have access to the
> team's VCS yet, and intend to push the packaging repository once I do.

Hi Ghis,

I approved your request to join pkg-java sometime on August 3rd, so you
should be good go in that regard.  (Let me know if it's not working for
you.)

I'll take a look these new packages in the next few days (if someone
else doesn't beat me to them).

Thank you for your contributions to the Debian Java Team!
tony

[toc] | [prev] | [next] | [standalone]

#9849

On 04/08/17 15:40, tony mancill wrote:
> On Fri, Aug 04, 2017 at 12:50:22PM +0100, Ghislain Vaillant wrote:
>> Dear Debian Java Team,
>>
>> I am undertaking the effort of packaging ImageJ version 2.x for Debian,
>> which requires the packaging of quite a few Java libraries as a result of
>> the modularization of the code base.
>>
>> Two of the leaf packages are Imglib2 [1] and Parsington [2] for which I have
>> prepared an initial package. Please keep in mind that I am new to Java
>> packaging, so mistakes are likely to be made. I followed Markus' recent post
>> on Java packaging as the main inspiration.
>>
>> [1] https://mentors.debian.net/debian/pool/main/libi/libimglib2-java/libimglib2-java_4.3.0-1.dsc
>> [2] https://mentors.debian.net/debian/pool/main/libp/libparsington-java/libparsington-java_1.0.1-1.dsc
>>
>> Please let me know whether there are comments. I don't have access to the
>> team's VCS yet, and intend to push the packaging repository once I do.
> 
> Hi Ghis,
> 
> I approved your request to join pkg-java sometime on August 3rd, so you
> should be good go in that regard.  (Let me know if it's not working for
> you.)

I confirm it all works. I know you guys usually ask for contributions 
first before granting access rights, so I was not expecting it so soon 
anyway. Thanks.

> I'll take a look these new packages in the next few days (if someone
> else doesn't beat me to them).

Brilliant. Looking forward to your comments then.

Ghis

[toc] | [prev] | [next] | [standalone]

#9886

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 04, 2017 at 04:11:07PM +0100, Ghislain Vaillant wrote:
> 
> On 04/08/17 15:40, tony mancill wrote:
> > On Fri, Aug 04, 2017 at 12:50:22PM +0100, Ghislain Vaillant wrote:
> > > Two of the leaf packages are Imglib2 [1] and Parsington [2] for which I have
> > > prepared an initial package. Please keep in mind that I am new to Java
> > > packaging, so mistakes are likely to be made. I followed Markus' recent post
> > > on Java packaging as the main inspiration.
> > > 
> > > [1] https://mentors.debian.net/debian/pool/main/libi/libimglib2-java/libimglib2-java_4.3.0-1.dsc
> > > [2] https://mentors.debian.net/debian/pool/main/libp/libparsington-java/libparsington-java_1.0.1-1.dsc
> 
> > I'll take a look these new packages in the next few days (if someone
> > else doesn't beat me to them).

Hello Ghis,

Once again, please excuse the delay.  Everything looks good with
libparsington-java, so I have uploaded the package into the archive and
pushed the master, pristine-tar, and upstream branches that correspond
to the packaging after "gbp import-dsc" of the packaging you uploaded to
mentors.  Once the package is accepted into the archive, I will push the
debian/1.0.1-1 tag (since it's a pain to rewrite history).

I spoke with Markus yesterday about libimglib2-java and so will wait to
hear back from him before starting on that one.  Again *thank you* for
your patience, and for your contribution to Debian!

Cheers,
tony

[toc] | [prev] | [next] | [standalone]

#9888

On 12/08/17 16:02, tony mancill wrote:
> On Fri, Aug 04, 2017 at 04:11:07PM +0100, Ghislain Vaillant wrote:
>>
>> On 04/08/17 15:40, tony mancill wrote:
>>> On Fri, Aug 04, 2017 at 12:50:22PM +0100, Ghislain Vaillant wrote:
>>>> Two of the leaf packages are Imglib2 [1] and Parsington [2] for which I have
>>>> prepared an initial package. Please keep in mind that I am new to Java
>>>> packaging, so mistakes are likely to be made. I followed Markus' recent post
>>>> on Java packaging as the main inspiration.
>>>>
>>>> [1] https://mentors.debian.net/debian/pool/main/libi/libimglib2-java/libimglib2-java_4.3.0-1.dsc
>>>> [2] https://mentors.debian.net/debian/pool/main/libp/libparsington-java/libparsington-java_1.0.1-1.dsc
>>
>>> I'll take a look these new packages in the next few days (if someone
>>> else doesn't beat me to them).
> 
> Hello Ghis,
> 
> Once again, please excuse the delay.  Everything looks good with
> libparsington-java, so I have uploaded the package into the archive and
> pushed the master, pristine-tar, and upstream branches that correspond
> to the packaging after "gbp import-dsc" of the packaging you uploaded to
> mentors.  Once the package is accepted into the archive, I will push the
> debian/1.0.1-1 tag (since it's a pain to rewrite history).

Oh, so that explained the existing repository on Alioth. I thought it 
was a previous attempt of mine. Anyway, I made a backup of it and pushed 
my initial packaging for libimglib2-java and libparsington-java.

Likewise, I usually leave the tagging of the Debian branch on hold until 
the initial upload is confirmed by the ftp-team.

> I spoke with Markus yesterday about libimglib2-java and so will wait to
> hear back from him before starting on that one.  Again *thank you* for
> your patience, and for your contribution to Debian!

Awesome. Great first experience with the team.

Ghis

[toc] | [prev] | [next] | [standalone]

#9893

[Multipart message — attachments visible in raw view] — view raw

Am 12.08.2017 um 17:02 schrieb tony mancill:
[...]
> I spoke with Markus yesterday about libimglib2-java and so will wait to
> hear back from him before starting on that one.  Again *thank you* for
> your patience, and for your contribution to Debian!
> 

Hi,

I have just reviewed libimglib2-java and I think it is in a good state.
Two remarks/suggestions though:

1. If you want to change the source and compile target to Java 8 in
Maven, you don't need to patch the pom.xml file. Just place a file
called maven.properties in your debian directory and add the following
options:

maven.compiler.source=1.8
maven.compiler.target=1.8

2. I saw the no-doc build profile annotations in debian/control. Is that
something that you specifically need for libimglib2-java or is there
another reason? I believe it would not hurt but I am interested to know
more about the advantages and whether this should be used for other -doc
packages too.

I can upload the package afterwards.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#9894

On 14/08/17 21:11, Markus Koschany wrote:
> Am 12.08.2017 um 17:02 schrieb tony mancill:
> [...]
>> I spoke with Markus yesterday about libimglib2-java and so will wait to
>> hear back from him before starting on that one.  Again *thank you* for
>> your patience, and for your contribution to Debian!
>>
> 
> Hi,
> 
> I have just reviewed libimglib2-java and I think it is in a good state.
> Two remarks/suggestions though:
> 
> 1. If you want to change the source and compile target to Java 8 in
> Maven, you don't need to patch the pom.xml file. Just place a file
> called maven.properties in your debian directory and add the following
> options:
> 
> maven.compiler.source=1.8
> maven.compiler.target=1.8

That's much better indeed. Updated in git.

> 2. I saw the no-doc build profile annotations in debian/control. Is that
> something that you specifically need for libimglib2-java or is there
> another reason?

See 
https://www.debian.org/doc/debian-policy/upgrading-checklist.html#s-4.0.0, 
section 4.9.1:

> I believe it would not hurt but I am interested to know
> more about the advantages and whether this should be used for other -doc
> packages too.

Not sure what the advantages are, but adding support for it is not 
difficult. At least compared to other packages I maintain where explicit 
guards need to be added in the rules file to support nodoc builds.

I took this opportunity to bump the standards version to 4.0.1.

Ghis

[toc] | [prev] | [next] | [standalone]

#9896

[Multipart message — attachments visible in raw view] — view raw

Am 14.08.2017 um 22:45 schrieb Ghislain Vaillant:
> 
> 
> On 14/08/17 21:11, Markus Koschany wrote:
>
>> 2. I saw the no-doc build profile annotations in debian/control. Is that
>> something that you specifically need for libimglib2-java or is there
>> another reason?
> 
> See
> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#s-4.0.0,
> section 4.9.1:
> 
>> I believe it would not hurt but I am interested to know
>> more about the advantages and whether this should be used for other -doc
>> packages too.
> 
> Not sure what the advantages are, but adding support for it is not
> difficult. At least compared to other packages I maintain where explicit
> guards need to be added in the rules file to support nodoc builds.

It's quite late here in Germany and I still suffer from jet lag effects
but I believe we are talking about two different things right now.

Policy 4.9.1 is about the nodoc option to suppress building
documentation at all. So you could basically run something like

DEB_BUILD_OPTION=nodoc gbp buildpackage

and then your -doc packages won't be built at all.

However your annotations in debian/control are for bootstrapping debian
packages. [1] I believe you don't need them if you want to support
building your package without doc packages. This is a more general tool
chain issue for Java packages. At the moment I'm not sure how well it is
supported but it is certainly something we want to support.

> I took this opportunity to bump the standards version to 4.0.1.

Right, good catch.


Regards,

Markus

[1] https://wiki.debian.org/BuildProfileSpec

[toc] | [prev] | [next] | [standalone]

#9899

On 14/08/17 23:03, Markus Koschany wrote:
> Am 14.08.2017 um 22:45 schrieb Ghislain Vaillant:
>>
>>
>> On 14/08/17 21:11, Markus Koschany wrote:
>>
>>> 2. I saw the no-doc build profile annotations in debian/control. Is that
>>> something that you specifically need for libimglib2-java or is there
>>> another reason?
>>
>> See
>> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#s-4.0.0,
>> section 4.9.1:
>>
>>> I believe it would not hurt but I am interested to know
>>> more about the advantages and whether this should be used for other -doc
>>> packages too.
>>
>> Not sure what the advantages are, but adding support for it is not
>> difficult. At least compared to other packages I maintain where explicit
>> guards need to be added in the rules file to support nodoc builds.
> 
> It's quite late here in Germany and I still suffer from jet lag effects
> but I believe we are talking about two different things right now.
> 
> Policy 4.9.1 is about the nodoc option to suppress building
> documentation at all. So you could basically run something like

Actually, that was not the piece of documentation I wanted to refer to, 
the build profiles wiki article was.

> DEB_BUILD_OPTION=nodoc gbp buildpackage
> 
> and then your -doc packages won't be built at all.

I don't think this is true.

> However your annotations in debian/control are for bootstrapping debian
> packages. [1] I believe you don't need them if you want to support
> building your package without doc packages.

My understanding so far:

1) DEB_BUILD_OPTIONS=nodoc: doc packages are built but left mostly empty
2) DEB_BUILD_PROFILES=nodoc: doc packages are not built at all

> This is a more general tool
> chain issue for Java packages. At the moment I'm not sure how well it is
> supported but it is certainly something we want to support.

I believe what I have done only answers 2), and I agree solving 1) is 
more of a toolchain issue. Same comment for nocheck support.

I am happy to take it out from both libimglib2-java and 
libparsington-java if it is an issue anyway. I find it convenient to use 
"nocheck nodoc" when I have got a number of builds of inter-dependent 
packages to run locally, but I could also live without.

Or perhaps I am completely wrong.

Cheers,
Ghis

[toc] | [prev] | [next] | [standalone]

#9903

[Multipart message — attachments visible in raw view] — view raw

Am 15.08.2017 um 11:18 schrieb Ghislain Vaillant:
[...]
> My understanding so far:
> 
> 1) DEB_BUILD_OPTIONS=nodoc: doc packages are built but left mostly empty
> 2) DEB_BUILD_PROFILES=nodoc: doc packages are not built at all
> 
>> This is a more general tool
>> chain issue for Java packages. At the moment I'm not sure how well it is
>> supported but it is certainly something we want to support.
> 
> I believe what I have done only answers 2), and I agree solving 1) is
> more of a toolchain issue. Same comment for nocheck support.
> 
> I am happy to take it out from both libimglib2-java and
> libparsington-java if it is an issue anyway. I find it convenient to use
> "nocheck nodoc" when I have got a number of builds of inter-dependent
> packages to run locally, but I could also live without.
> 
> Or perhaps I am completely wrong.

I never had to use build profiles because for me it was always something
related to bootstrapping Debian as a whole. This is actually the first
Java package I have seen where someone makes use of the build profile
syntax in debian/control.

I still believe what you want is support for DEB_BUILD_OPTIONS=nodoc
similar to DEB_BUILD_OPTIONS=nocheck. The nodoc option will be supported
by maven-debian-helper soon according to one of Emmanuel's last posts on
this list. I assume this will simply suppress the Javadoc step and you
will end up with an empty doc package which is basically the same as
having no documentation at all.

I don't mind uploading the package as is but wanted to point out that
build profiles is probably not what you really want.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#9904

On 16/08/17 19:47, Markus Koschany wrote:
> Am 15.08.2017 um 11:18 schrieb Ghislain Vaillant:
> 
> I never had to use build profiles because for me it was always something
> related to bootstrapping Debian as a whole. This is actually the first
> Java package I have seen where someone makes use of the build profile
> syntax in debian/control.

So far I have mostly packaged Python libraries, where building the 
documentation often requires pulling quite a few extra dependencies, 
including other -doc packages.

On the other hand, if all Javadoc packages only require default-jdk-doc 
as b-dep, then the benefits of supporting nodoc would be pretty small.

> I still believe what you want is support for DEB_BUILD_OPTIONS=nodoc
> similar to DEB_BUILD_OPTIONS=nocheck. The nodoc option will be supported
> by maven-debian-helper soon according to one of Emmanuel's last posts on
> this list. I assume this will simply suppress the Javadoc step and you
> will end up with an empty doc package which is basically the same as
> having no documentation at all.

Indeed, though the extra dependencies for building the docs will be 
pulled, which kind of defeats the purpose IMO.

Basically, I agree with https://wiki.debian.org/DebianBootstrap, in the 
"Documentation loops" section:

"Building without docs usually affects the build-dependencies, so it is 
not quite like other DEB_BUILD_OPTIONS, and using DEB_BUILD_PROFILES 
instead now makes more sense."

and apply the same logic to nocheck too. If I don't intend to build with 
tests enabled, then why pulling the extra dependencies to the build.

Again, for Python, support for nocheck can make sense because the Python 
packaging metadata already make the separation between build, install 
and tests requirements. Perhaps it does not make sense for Java?

> I don't mind uploading the package as is but wanted to point out that
> build profiles is probably not what you really want.

Anyway, if you prefer that I take it out, that's absolutely fine by me.

The package will be team-maintained, so the content of the packaging 
should be normalized as per the team's habits, I guess.

Please let me know.

Ghis

[toc] | [prev] | [next] | [standalone]

#9905

[Multipart message — attachments visible in raw view] — view raw

Am 16.08.2017 um 21:25 schrieb Ghislain Vaillant:
> On 16/08/17 19:47, Markus Koschany wrote:
>> Am 15.08.2017 um 11:18 schrieb Ghislain Vaillant:
>>
>> I never had to use build profiles because for me it was always something
>> related to bootstrapping Debian as a whole. This is actually the first
>> Java package I have seen where someone makes use of the build profile
>> syntax in debian/control.
> 
> So far I have mostly packaged Python libraries, where building the
> documentation often requires pulling quite a few extra dependencies,
> including other -doc packages.
> 
> On the other hand, if all Javadoc packages only require default-jdk-doc
> as b-dep, then the benefits of supporting nodoc would be pretty small.

Sometimes we build-depend on other -doc packages for cross-referencing
other Javadocs but I don't believe the extra dependencies have ever
caused any issues. As mentioned in the recent DebConf thread we plan to
reduce the amount of -doc packages, so it is at least questionable how
relevant nodoc build profiles for Java packages will be in the future.

>> I still believe what you want is support for DEB_BUILD_OPTIONS=nodoc
>> similar to DEB_BUILD_OPTIONS=nocheck. The nodoc option will be supported
>> by maven-debian-helper soon according to one of Emmanuel's last posts on
>> this list. I assume this will simply suppress the Javadoc step and you
>> will end up with an empty doc package which is basically the same as
>> having no documentation at all.
> 
> Indeed, though the extra dependencies for building the docs will be
> pulled, which kind of defeats the purpose IMO.
> 
> Basically, I agree with https://wiki.debian.org/DebianBootstrap, in the
> "Documentation loops" section:
> 
> "Building without docs usually affects the build-dependencies, so it is
> not quite like other DEB_BUILD_OPTIONS, and using DEB_BUILD_PROFILES
> instead now makes more sense."
> 
> and apply the same logic to nocheck too. If I don't intend to build with
> tests enabled, then why pulling the extra dependencies to the build.

The difference between DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES is that
you have to add those nodoc annotations to all debian/control files.
Once DEB_BUILD_OPTIONS=nodoc is supported by maven-debian-helper no
further steps are required. It is unlikely that libimglib2-java or
libparsington-java are affected by bootstrapping issues. If we want to
support bootstrapping we should identify key packages first and then
implement such build profiles in those packages. However at the moment
we simply don't know what Java packages have to implement such build
profiles to break the dependency loop cycle. In my opinion it would be
premature to add those stanzas to all doc packages when nobody is
actively working on this topic.

Not installing extra dependencies is certainly a bonus but the reason
why nocheck and nodoc build options primarily exist is to skip certain
build steps. Skipping OpenJDK tests means hours of time saved but the
installation of extra dependencies is a matter of one or two minutes.

> Again, for Python, support for nocheck can make sense because the Python
> packaging metadata already make the separation between build, install
> and tests requirements. Perhaps it does not make sense for Java?

Nocheck is already supported by all Java packages. You can also use the
maven.test.skip=true option in maven.properties for all Maven based
packages.

>> I don't mind uploading the package as is but wanted to point out that
>> build profiles is probably not what you really want.
> 
> Anyway, if you prefer that I take it out, that's absolutely fine by me.
> 
> The package will be team-maintained, so the content of the packaging
> should be normalized as per the team's habits, I guess.
> 
> Please let me know.

I believe we should keep it simple and try to avoid using build profiles
except someone is really going to work on this stuff and files bug
reports and identifies key packages. If we decide to add build profiles
we should do it in a consistent way though.

I suggest to wait one more day for further feedback. If there are no
objections, please remove the build profiles.

Markus

[toc] | [prev] | [next] | [standalone]

#9916

On 16/08/17 21:29, Markus Koschany wrote:
> I believe we should keep it simple and try to avoid using build profiles
> except someone is really going to work on this stuff and files bug
> reports and identifies key packages. If we decide to add build profiles
> we should do it in a consistent way though.
> 
> I suggest to wait one more day for further feedback. If there are no
> objections, please remove the build profiles.

I have dropped the build profile from libimglib2-java.

Shall I do the same for libparsington-java (which was already submitted 
to NEW, but has yet to be accepted) and ask for a re-upload?

Ghis

[toc] | [prev] | [next] | [standalone]

#9919

[Multipart message — attachments visible in raw view] — view raw

Am 18.08.2017 um 10:22 schrieb Ghislain Vaillant:
> On 16/08/17 21:29, Markus Koschany wrote:
>> I believe we should keep it simple and try to avoid using build profiles
>> except someone is really going to work on this stuff and files bug
>> reports and identifies key packages. If we decide to add build profiles
>> we should do it in a consistent way though.
>>
>> I suggest to wait one more day for further feedback. If there are no
>> objections, please remove the build profiles.
> 
> I have dropped the build profile from libimglib2-java.
> 
> Shall I do the same for libparsington-java (which was already submitted
> to NEW, but has yet to be accepted) and ask for a re-upload?

No, a re-upload is not necessary. This can be done with the next
revision. I am going to upload libimglib2-java today.

Markus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web