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

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

Packaging a ./gradlew upstream?

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

Contents

  Packaging a ./gradlew upstream? Stephen Paul Weber <singpolyma@singpolyma.net> - 2020-12-09 17:00 +0100
    Re: Packaging a ./gradlew upstream? Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-12-09 20:40 +0100
      Re: Packaging a ./gradlew upstream? Stephen Paul Weber <singpolyma@singpolyma.net> - 2020-12-09 20:50 +0100
        Re: Packaging a ./gradlew upstream? Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2020-12-09 21:30 +0100
        Re: Mindustry packaging Phil Morrell <debian@emorrp1.name> - 2020-12-10 01:40 +0100

#11986 — Packaging a ./gradlew upstream?

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

I am interested in packaging https://github.com/Anuken/Mindustry -- it uses the
now somewhat-standard ./gradlew wrapper script style build system.  This system
downloads all kinds of dependencies (including the gradle build system itself)
in binary form as part of running the build.  I'm wondering if others have
experience packaging upstreams using this kind of system and what the usual
strategy is for building it with locally-installed dependencies from Debian
instead of the network access it wants to do?

Thanks for any tips,

[toc] | [next] | [standalone]

#11988

Hi Stephen,

On Wed, Dec 9, 2020 at 3:51 PM Stephen Paul Weber
<singpolyma@singpolyma.net> wrote:
>
> I am interested in packaging https://github.com/Anuken/Mindustry -- it uses the
> now somewhat-standard ./gradlew wrapper script style build system.  This system
> downloads all kinds of dependencies (including the gradle build system itself)
> in binary form as part of running the build.  I'm wondering if others have
> experience packaging upstreams using this kind of system and what the usual
> strategy is for building it with locally-installed dependencies from Debian
> instead of the network access it wants to do?

There is a RFP open for it, https://bugs.debian.org/959466.
Dependencies can not be downloaded during the build. All the
dependencies should already be available in Debian. And the bug lists
the first blocker which then lists the other blocker and the last
blocker is kotlin (or shall I say the first blocker).


-- 
Regards
Sudip

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

#11989

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

>Dependencies can not be downloaded during the build.

Yes, of course, that is the problem described in my OP :)

>And the bug lists the first blocker which then lists the other blocker
>and the last blocker is kotlin (or shall I say the first blocker).

I'm having trouble following the breadcrumbs to see where kotlin becomes the
blocker.  I assume because one of the dependencies is written it kotlin?

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

#11990

On Wed, Dec 9, 2020 at 7:41 PM Stephen Paul Weber
<singpolyma@singpolyma.net> wrote:
>
> >Dependencies can not be downloaded during the build.
>
> Yes, of course, that is the problem described in my OP :)
>
> >And the bug lists the first blocker which then lists the other blocker
> >and the last blocker is kotlin (or shall I say the first blocker).
>
> I'm having trouble following the breadcrumbs to see where kotlin becomes the
> blocker.  I assume because one of the dependencies is written it kotlin?

959466 is blocked by 968471.
968471 is blocked by 968738.
And
968738 is blocked by kotlin (892842).

Please also look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968738#12.


-- 
Regards
Sudip

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

#11991 — Re: Mindustry packaging

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

Hi Stephen,

I'm the one who did the initial triage to discover the surprising kotlin
requirement, but I'll gladly collaborate once that's available. I'm
thoroughly enjoying the new v6 campaign in co-op with some friends, so
keen to be able to play it via debian rather than a .jar download with
e.g. embedded Discord server listings.

On Wed, Dec 09, 2020 at 02:41:57PM -0500, Stephen Paul Weber wrote:
> > Dependencies can not be downloaded during the build.
> 
> Yes, of course, that is the problem described in my OP :)

As you said, many Java projects have switched to gradle so thankfully
the hard work to integrate it with Debian has already been done. The
upstream bundled ./gradlew will be completely ignored and that bit is as
simple as adding gradle-debian-helper to Build-Depends and
--buildsystem=gradle to debian/rules.

https://sources.debian.org/src/gradle-debian-helper/2.1/README.txt/

> > And the bug lists the first blocker which then lists the other blocker
> > and the last blocker is kotlin (or shall I say the first blocker).
> 
> I'm having trouble following the breadcrumbs to see where kotlin becomes the
> blocker.  I assume because one of the dependencies is written it kotlin?

In the summary at the top, you can follow the link in "Fix blocked by"
(and then "Fix blocked by" again, etc.). As for why each dependency is a
blocker, I hope my initial message in each RFP makes that clear. The
current state of kotlin packaging is really promising, with (hopefully)
just normal java packaging issues left.

Help needed! "Make sure you have kotlin-reflect.jar in the classpath"
https://salsa.debian.org/android-tools-team/admin/-/issues/34

[toc] | [prev] | [standalone]

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

csiph-web