Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into Debian. We need a DD willing to upload it.
The actual upload needs to wait for openjdk-8, which is currently in the
NEW queue, to be accepted first.
However, the wait time can be used to do any final reviews.
- There are no lintian errors/warnings except for need of manpages.
On Thu, 29 Apr 2021, Sunil Mohan Adapa wrote:
The actual upload needs to wait for openjdk-8, which is currently in the
NEW queue, to be accepted first.
Again, please only do the actual uploading *after* openjdk-8 8u292-b10-1
(or higher) has been built for all architectures. This is a version I
have NOT yet uploaded because ftpmasters must first ACCEPT 8u282-b08-2
(which is a rather hackish upload containing self-built binaries) so the
B-D for future uploads will be available again. 8u292-b10-1 will be the
first upload that’ll be built on the buildds again then.
- There are no lintian errors/warnings except for need of manpages.
$ lintian -vIiE --pedantic --color=auto *.changes
This often finds many more than one’s standard invocations do.
Manpages are important (now’s the time to write some ☺) but
not a conditio-sine-qua-nōn. I delivered the one for Jamulus
later, too (lack of time to write one for the hurried upload
to NEW).
- There are no lintian errors/warnings except for need of manpages.
$ lintian -vIiE --pedantic --color=auto *.changes
This often finds many more than one’s standard invocations do.
Manpages are important (now’s the time to write some ☺)
FWIW, help2man is often a really good starting point.
On Sat, 1 May 2021, Olek Wojnar wrote:
FWIW, help2man is often a really good starting point.
REALLY not; that produces really bad-quality man(7)-format manpages.
These days you want semantical markup via mdoc(7) instead (see, for
example, the manpage I wrote for jamulus or others).
Hello,
Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into Debian. We need a DD willing to upload it.
The actual upload needs to wait for openjdk-8, which is currently in the
NEW queue, to be accepted first. However, the wait time can be used to
do any final reviews.
On 4/29/21 5:01 PM, Sunil Mohan Adapa wrote:
Hello,
Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into
Debian. We need a DD willing to upload it.
The actual upload needs to wait for openjdk-8, which is currently in the
NEW queue, to be accepted first. However, the wait time can be used to
do any final reviews.
- please can we have a sane upstream version? Like 1.3.31
and then document in debian/README.source about the additional
components added? Is it likely that these other components
need updates without a kotlin update?
- debian/bootstrap creates a deb, which has the deb itself
in the root directory.
- debian/rules has
export JDK_16="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_17="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_18="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_9="/usr/lib/jvm/java-11-openjdk-amd64"
which are meaningless, as every command is executed in its
own subshell.
- after installing the bootstrap deb, and trying the build,
I get:
[ERROR] Failed to execute goal on project kotlin-maven-plugin: Could not resolve
dependencies for project org.jetbrains.kotlin:kotlin-maven-plugin:maven-plugin:1.3.31: The following artifacts could not be resolved: org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31, org.jetbrains.kotlin:kotlin-scripting-compiler:jar:1.3.31: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31 has not been downloaded from it
before. -> [Help 1]
[...]
- debian/rules has
export JDK_16="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_17="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_18="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_9="/usr/lib/jvm/java-11-openjdk-amd64"
which are meaningless, as every command is executed in its
own subshell.
I will do this cleanup.
- after installing the bootstrap deb, and trying the build,
I get:
[ERROR] Failed to execute goal on project kotlin-maven-plugin: Could not resolve
dependencies for project
org.jetbrains.kotlin:kotlin-maven-plugin:maven-plugin:1.3.31: The following >> artifacts could not be resolved:
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31,
org.jetbrains.kotlin:kotlin-scripting-compiler:jar:1.3.31: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31 has not been downloaded from it
before. -> [Help 1]
This must be because of the recent changes to build two additional jar
files needed by other projects. Since these missing dependencies are
part of the built kotlin deb after stage1 and we didn't test the full bootstrap with the recent changes, we didn't face this issue. I will fix
this on priority.
With that, I can build a deb. However the deb has *no* dependencies.
On 06/05/21 9:32 am, Matthias Klose wrote:
On 4/29/21 5:01 PM, Sunil Mohan Adapa wrote:
Hello,
Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into
Debian. We need a DD willing to upload it.
The actual upload needs to wait for openjdk-8, which is currently in the >>> NEW queue, to be accepted first. However, the wait time can be used to
do any final reviews.
- please can we have a sane upstream version? Like 1.3.31
and then document in debian/README.source about the additional
components added? Is it likely that these other components
need updates without a kotlin update?
The two small components were added to the package only to make the bootstrapping process simpler. After the bootstrapping process is done
and kotlin is in Debian, we can separate out the two components into
their own deb packages and have a clean version number for kotlin (along
with new version packaging). Can we tolerate this until then?
- debian/bootstrap creates a deb, which has the deb itself
in the root directory.
This was known but ignored as bootstrap process is only used as input
for stage1 (stage3/4 output will be uploaded into Debian). This
lingering deb is the result of creating the output deb file in a
directory that is being packed into the deb.
- debian/rules has
export JDK_16="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_17="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_18="/usr/lib/jvm/java-8-openjdk-amd64"
export JDK_9="/usr/lib/jvm/java-11-openjdk-amd64"
which are meaningless, as every command is executed in its
own subshell.
I will do this cleanup.
- after installing the bootstrap deb, and trying the build,
I get:
[ERROR] Failed to execute goal on project kotlin-maven-plugin: Could not resolve
dependencies for project
org.jetbrains.kotlin:kotlin-maven-plugin:maven-plugin:1.3.31: The following >> artifacts could not be resolved:
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31,
org.jetbrains.kotlin:kotlin-scripting-compiler:jar:1.3.31: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact
org.jetbrains.kotlin:kotlin-compiler:jar:1.3.31 has not been downloaded from it
before. -> [Help 1]
This must be because of the recent changes to build two additional jar
files needed by other projects. Since these missing dependencies are
part of the built kotlin deb after stage1 and we didn't test the full bootstrap with the recent changes, we didn't face this issue. I will fix
this on priority.
To work around:
- An older commit 8455d719 will likely not have the issue.
- Using a pre-build binary[1] will likely not have the issue.
Le 07/05/2021 10:12, Matthias Klose a crit:
sure. but maybe remove the "plus" signs from the upstream version, so that the
final 1.31.1 version is newer than the current version? or will it be a
1.31.1+dfsg version?
I also agree with Matthias on the version, the '+' could be removed so
we can upload a clean 1.3.31 version later.
Did you start working on packaging kotlinx coroutines and atomicfu
separately yet? That will be the next step once kotlin is uploaded.
- debian/bootstrap creates a deb, which has the deb itself
in the root directory.
Is there any reason to use debhelper 13? Does it have anything that is relevant
for java packages? Just asking because that's usually something which needs to
be downgraded for backports.
I disagree on the version numbering. As described in README.source and
the commit messages for the watch file, this is the standardised format
for MUT support in uscan, admittedly more often seen in javascript.
There is an alternative, checksum '1.3.31+~cs1.11.13', but that does
not
support uscan --download-current-version which is needed until we can
bump them all to their latest tags.
Is there any reason to use debhelper 13? Does it have anything that
is relevant for java packages? Just asking because that's usually
something which needs to be downgraded for backports. But I assume
there are enough dependency requiring debhelper v13 as well ...
Are you planning to upload to stretch
On Fri, 7 May 2021, Matthias Klose wrote:
Is there any reason to use debhelper 13? Does it have anything that
is relevant for java packages? Just asking because that's usually
something which needs to be downgraded for backports. But I assume
there are enough dependency requiring debhelper v13 as well ...
That’s Ubuntu you’re talking about. I’m still totally annoyed for
my PPA builds that bionic and focal don’t have debhelper 13 available.
Debian backports, at least for the last 3+ years, have had reasonably up-to-date debhelper, as downgrading the version just for backporting
is really undesired as backports change and hindering things in sid. 13~bpo10+1 has a changelog date of 27 Apr 2020…
- debian/bootstrap creates a deb, which has the deb itself
in the root directory.
This was known but ignored as bootstrap process is only used as input
for stage1 (stage3/4 output will be uploaded into Debian). This
lingering deb is the result of creating the output deb file in a
directory that is being packed into the deb.
lintian reports unused paragraph in debian/copyright but that's fairly
minor. The paragraphs with the same license can be merged to simplify
the layout.
Did you start working on packaging kotlinx coroutines and atomicfu
separately yet? That will be the next step once kotlin is uploaded.
Also, are all the jar files downloaded by debian/bootstrap rebuilt? None
is copied directly into the stage 2 .deb, right?
On Thu, 29 Apr 2021, Sunil Mohan Adapa wrote:
Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into Debian. We need a DD willing to upload it.
The actual upload needs to wait for openjdk-8, which is currently in the NEW queue, to be accepted first.
Again, please only do the actual uploading *after* openjdk-8 8u292-b10-1
(or higher) has been built for all architectures. This is a version I
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 61:15:04 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,094 |
Messages: | 5,274,431 |