RFS for libimglib2-java and libparsington-java

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFS for libimglib2-java and libparsington-java

Ghislain Vaillant
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

tony mancill
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Ghislain Vaillant


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

tony mancill
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Ghislain Vaillant
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Markus Koschany-2
In reply to this post by tony mancill
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


signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Ghislain Vaillant


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Markus Koschany-2
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



signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Ghislain Vaillant
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Markus Koschany-2
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


signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

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.

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Markus Koschany-2
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


signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

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?

Ghis

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFS for libimglib2-java and libparsington-java

Markus Koschany-2
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


signature.asc (981 bytes) Download Attachment
Loading...