• Kotlin: looking for a DD to review/upload

    From Sunil Mohan Adapa@21:1/5 to All on Thu Apr 29 17:10:01 2021
    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. The status of the package is as follows:

    - debian/bootstrap script provides a convenient way to download upstream binaries and turn them into .deb package. This is used to build Kotlin
    in stage1. debian/README.source explains how.

    - Kotlin can rebuild itself using the output of stage1. It has been
    tested up to stage 5/6 (repeated rebuild using previous stage output).

    - Kotlin is almost reproducible with only minor diff due to a couple of
    bugs related to stable order in code generation.

    - debian/copyright file went through multiple rounds of review including
    one recently.

    - There are no lintian errors/warnings except for need of manpages.

    - debian/patches have been reorganized so that they can be easily
    cleaned up when uploading a newer version.

    Links:

    1) https://salsa.debian.org/java-team/kotlin/
    2) https://salsa.debian.org/java-team/kotlin/-/issues/11

    Thank you,

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to Sunil Mohan Adapa on Thu Apr 29 17:20:01 2021
    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
    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.

    However, the wait time can be used to do any final reviews.

    Yes, definitely. (Not something I see me helping with, though.)

    - 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).

    bye,
    //mirabilos
    --
    Infrastrukturexperte • tarent solutions GmbH
    Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to Thorsten Glaser on Thu Apr 29 22:00:01 2021
    On 29/04/21 8:12 am, Thorsten Glaser wrote:
    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.

    I half-forgot about that. Thank you for the reminder.

    [...]
    - 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).

    Will try to get these done.

    Thanks,

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Olek Wojnar@21:1/5 to t.glaser@tarent.de on Sun May 2 00:00:02 2021
    On Thu, Apr 29, 2021 at 11:12 AM Thorsten Glaser <t.glaser@tarent.de> wrote:


    - 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.

    -Olek

    <div dir="ltr"><div dir="ltr">On Thu, Apr 29, 2021 at 11:12 AM Thorsten Glaser &lt;<a href="mailto:t.glaser@tarent.de">t.glaser@tarent.de</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;
    border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
    &gt; - There are no lintian errors/warnings except for need of manpages.<br>

    $ lintian -vIiE --pedantic --color=auto *.changes<br>

    This often finds many more than one’s standard invocations do.<br>

    Manpages are important (now’s the time to write some ☺) </blockquote><div><br></div><div>FWIW, help2man is often a really good starting point.</div><div><br></div><div>-Olek</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to Olek Wojnar on Sun May 2 00:00:01 2021
    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).

    bye,
    //mirabilos
    --
    Infrastrukturexperte • tarent solutions GmbH
    Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Olek Wojnar@21:1/5 to t.glaser@tarent.de on Tue May 4 21:30:02 2021
    On Sat, May 1, 2021 at 5:59 PM Thorsten Glaser <t.glaser@tarent.de> wrote:

    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).


    Note that I didn't say it was a perfect solution, merely that it was a good starting point. :) Your point is certainly valid but I personally think
    that a man-format manpage that someone can quickly create is better than no manpage at all.

    -Olek

    <div dir="auto"><div dir="ltr"><div dir="ltr">On Sat, May 1, 2021 at 5:59 PM Thorsten Glaser &lt;<a href="mailto:t.glaser@tarent.de" target="_blank" rel="noreferrer">t.glaser@tarent.de</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="
    gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 1 May 2021, Olek Wojnar wrote:<br>

    &gt; FWIW, help2man is often a really good starting point.<br>

    REALLY not; that produces really bad-quality man(7)-format manpages.<br>

    These days you want semantical markup via mdoc(7) instead (see, for<br> example, the manpage I wrote for jamulus or others).<br></blockquote><div><br></div><div>Note that I didn&#39;t say it was a perfect solution, merely that it was a good starting point. :) Your point is certainly valid but I personally think that a man-
    format manpage that someone can quickly create is better than no manpage at all.</div><div dir="auto"><br></div><div dir="auto">-Olek</div></div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Olek Wojnar@21:1/5 to All on Tue May 4 22:00:02 2021
    PS If anyone wants an easy mdoc solution, I just pushed a trivial local
    Python 3 fix [1] I had for cli2man [2] to upstream. Unfortunately, this is
    not actually in Debian ATM so not quite as convenient. But it is
    certainly more correct, to the point mirabilos made.

    [1] https://github.com/tobimensch/cli2man/pull/12
    [2] https://github.com/tobimensch/cli2man



    <div dir="ltr"><div>PS If anyone wants an easy mdoc solution, I just pushed a trivial local Python 3 fix [1] I had for cli2man [2] to upstream. Unfortunately, this is not actually in Debian ATM so not quite as convenient. But it is certainly more
    correct, to the point mirabilos made.</div><div><br></div><div>[1] <a href="https://github.com/tobimensch/cli2man/pull/12">https://github.com/tobimensch/cli2man/pull/12</a></div><div>[2] <a href="https://github.com/tobimensch/cli2man">https://github.
    com/tobimensch/cli2man</a></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    </blockquote></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Klose@21:1/5 to Sunil Mohan Adapa on Thu May 6 18:40:02 2021
    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]

    Matthias

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to Matthias Klose on Fri May 7 03:20:01 2021
    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.

    Links:

    1) https://www.emorrp1.name/kotlin/

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to Sunil Mohan Adapa on Fri May 7 08:10:01 2021
    On 06/05/21 6:14 pm, Sunil Mohan Adapa wrote:
    [...]

    - 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.
    [...]

    The two issues should be fixed now with changes I just pushed. I built
    up to three stages with the changes starting from the bootstrap.

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Fri May 7 10:50:01 2021
    Le 07/05/2021 à 10:12, Matthias Klose a écrit :

    With that, I can build a deb. However the deb has *no* dependencies.

    I've started reviewing the package and I stumbled on this issue as well,
    the kotlin .deb should indeed declare its dependencies, otherwise the
    symlinks in /usr/share/kotlin/kotlinc/lib/ are broken and kotlinc fails
    with a FileNotFoundException.

    I also agree with Matthias on the version, the '+' could be removed so
    we can upload a clean 1.3.31 version later.

    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.

    The are also two (unused?) android-support-v4.jar files that could be
    removed from the source package.

    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?

    Emmanuel Bourg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Klose@21:1/5 to Sunil Mohan Adapa on Fri May 7 10:20:01 2021
    On 5/7/21 3:14 AM, Sunil Mohan Adapa wrote:
    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?

    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?

    - 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.

    using the pre-built binary, I get:

    BUILD SUCCESSFUL in 4m 16s
    575 actionable tasks: 575 executed
    dh_auto_configure --buildsystem=maven
    ln: failed to create symbolic link '/packages/kotlin/x/kotlin-1.3.31+~1.0.1+~0.11.12/debian/maven-repo/org/gnu/gettext/libintl/0.21':
    File exists
    dh_auto_configure: error: /usr/share/maven-debian-helper/copy-repo.sh /packages/kotlin/x/kotlin-1.3.31\+\~1.0.1\+\~0.11.12/debian returned exit code 1
    make[1]: *** [debian/rules:51: override_dh_auto_build] Error 25
    make[1]: Leaving directory '/packages/kotlin/x/kotlin-1.3.31+~1.0.1+~0.11.12' make: *** [debian/rules:10: binary] Error 2

    works, when discarding the directory, unpacking freshly, and restarting. So apparently the package doesn't clean properly. Try building with dpkg-buildpackage -b twice.

    With that, I can build a deb. However the deb has *no* dependencies.

    I get a successful build, you can find a test package at https://launchpad.net/~doko/+archive/ubuntu/kotlin

    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 ...

    Matthias

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Morrell@21:1/5 to Emmanuel Bourg on Fri May 7 15:00:01 2021
    On Fri, May 07, 2021 at 10:40:31AM +0200, Emmanuel Bourg wrote:
    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.

    Hi both, thanks for the reviews.

    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.

    Relatedly, I'm not convinced by the plan to package them separately, as
    the purpose of the components was to break the Build-Depends cycle.
    After the initial upload, it makes sense to allow kotlinised gradle into
    the cycle so we can drop a lot of custom build patches. However, we
    could choose to keep (and CI) debian/bootstrap for the long run,
    producing separate binary packages, but not necessarily source.

    If you still disagree, then I ask that we not change it until after the
    upload, since separate source packages will naturally restore the clean
    version numbering as you go. That will also make it easier to handle the
    file collisions from shifting those jar's source package.

    - debian/bootstrap creates a deb, which has the deb itself
    in the root directory.

    Again from the commit messages, this too was deliberate and only
    partially lazy to simplify the implementation code:

    * default name is debian/tmp.deb, so output into BUILD_DIR to auto name
    * because the dir is simultaneously written and read, there's a useless
    tiny file embedded into the generated kotlin_*.deb

    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.

    Are you planning to upload to stretch or ubuntu 18.04? 13 is in buster-backports and I believe these changes are relevant for java:

    v13 This is the recommended mode of operation.
    - The third-party gradle build system (from gradle-debian-helper
    package) now runs the upstream-provided test suite automatically.
    - The dh_missing command will now default to --fail-missing.
    - The dh command sequencer will now skip all hook and override targets
    for dh_auto_test when DEB_BUILD_OPTIONS lists the relevant nocheck /
    nostrip options.

    -----BEGIN PGP SIGNATURE-----

    iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYJU40AAKCRDbymUJHySO bOxFAP9tgjS0fw+TZv2EieLq9DDBr/QdCAVS/tU7lQ9zqYt9xgD/RYETuRMGExTm ngpdaGtCScd/7GvdAkSB3U7eNp940Qc=
    =9X8k
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Fri May 7 16:40:02 2021
    Le 2021-05-07 14:55, Phil Morrell a écrit :

    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.

    If the '+' is required, maybe mangling the kotlin version would work?
    Something like this for example:

    1.3.31~bootstrap+~cs1.11.13

    Emmanuel Bourg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to Matthias Klose on Fri May 7 17:40:01 2021
    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…

    bye,
    //mirabilos
    --
    Infrastrukturexperte • tarent solutions GmbH
    Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to Phil Morrell on Fri May 7 17:50:01 2021
    On Fri, 7 May 2021, Phil Morrell wrote:

    Are you planning to upload to stretch

    stretch is closed; backports only follow normal release cycles and
    desupport LTS. (This is a thing I’m hoping to change when I might
    be able to at some point in the future, but nothing’s decided yet.)

    bye,
    //mirabilos

    PS: You can build a .orig.tar.?z for bootstrapping without needing
    to go through uscan, if *that* is what keeps us from having a
    sane version number…
    --
    Infrastrukturexperte • tarent solutions GmbH
    Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Klose@21:1/5 to Thorsten Glaser on Fri May 7 18:20:01 2021
    On 5/7/21 5:36 PM, Thorsten Glaser wrote:
    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…

    please see https://wiki.ubuntu.com/UbuntuBackports if you want to contribute a backport.

    backports for stable release updates can't be used.

    Matthias

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to Sunil Mohan Adapa on Sat May 8 00:40:01 2021
    On 06/05/21 6:14 pm, Sunil Mohan Adapa wrote:
    [...]

    - 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.


    This is now fixed[1].

    Links:

    1) https://salsa.debian.org/java-team/kotlin/-/commit/a52807034b3b3f5b78e6754808b4f9b29d7713f4

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to Emmanuel Bourg on Sat May 8 01:10:01 2021
    On 07/05/21 1:40 am, Emmanuel Bourg wrote:
    [...]
    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.

    Some of these will need fixes, while some like the copyright paragraphs
    for testData will likely be useful in future when we import testData and
    run tests.

    [...]

    Did you start working on packaging kotlinx coroutines and atomicfu
    separately yet? That will be the next step once kotlin is uploaded.

    I have not started that work yet. I got back to packaging Jitsi
    Videobridge during the wait as that was my original goal. Jitsi needed
    Kotlin and I found that Kotlin could use some push with finishing up. I
    am also tinkering a bit with Gradle on the side to help with the
    circular dependency and eventual patch cleanup in Kotlin.


    Also, are all the jar files downloaded by debian/bootstrap rebuilt? None
    is copied directly into the stage 2 .deb, right?


    To verify that none of the jar files in the upstream bootstrap binaries
    are getting copied, I did the following:

    1. For every file (jar and pom) in the bootstrap .deb, I verified that
    the file in output .deb is different.

    2. For every jar file in the bootstrap .deb:

    ~ I found a corresponding sub-project in the source code that is
    responsible for generating the jar. For example, for kotlin-scripting-embedabble-1.3.31.jar there is a sub-project
    responsible for generating it ./plugins/scripting/scripting-embeddable/.

    ~ I found that the sub-project is generating the jar file under build/ directory of the sub-project. For example, ./plugins/scripting/scripting-embeddable/build/libs/kotlin-scripting-compiler-embeddable-1.3.31.jar

    ~ I verified that jar generated during the build is one that ended in
    the output .deb. Since debhelper seems to modify the jar a bit (removing non-determinism?), I did the comparison by unzipping the jars being
    compared. For example, jar in
    ./plugins/scripting/scripting-embeddable/build/ was compared to jar in debian/tmp/usr/share/java/

    3. Also, we were earlier using 1.3.30 upstream binaries to build 1.3.31
    which gave some more confidence that we are not copying from source.

    Although the complex build system in theory could still be copying bits
    (if not for entire jars), I have not found anything like that during my
    work on it. Note that most of build system was converted from
    Gradle+Kotlin to Gradle+Groovy by the contributors to this packaging
    work. Presumably, they didn't catch anything like that either.

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to All on Mon Jun 14 13:30:01 2021
    Dixi quod…

    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

    This has happened now. Enjoy!

    Architecture Version Status For Buildd State Section [12]Logs Actions
    [13]Buildd exposure stats [14]all 8u292-b10-1 [15]Installed 2d 16h 48m [16]x86-grnet-02 misc [17]old | [18]all (1) [19]giveback
    [20]Buildd exposure stats [21]amd64 8u292-b10-1 [22]Installed 2d 16h 39m [23]x86-ubc-01 misc [24]old | [25]all (1) [26]giveback
    [27]Buildd exposure stats [28]arm64 8u292-b10-1 [29]Installed 2d 14h 9m [30]arm-conova-01 misc [31]old | [32]all (1) [33]giveback
    [34]Buildd exposure stats [35]armel 8u292-b10-1 [36]Installed 21h 39m [37]hoiby misc [38]old | [39]all (2) [40]giveback
    [41]Buildd exposure stats [42]armhf 8u292-b10-1 [43]Installed 2d 14h 29m [44]arm-arm-01 misc [45]old | [46]all (1) [47]giveback
    [48]Buildd exposure stats [49]i386 8u292-b10-1 [50]Installed 2d 15h 49m [51]x86-conova-01 misc [52]old | [53]all (1) [54]giveback
    [55]Buildd exposure stats [56]mips64el 8u292-b10-1 [57]Installed 2d 2h 14m [58]mipsel-manda-04 misc [59]old | [60]all (1) [61]giveback
    [62]Buildd exposure stats [63]mipsel 8u292-b10-1 [64]Installed 1d 12h 10m [65]mipsel-aql-02 misc [66]old | [67]all (1) [68]giveback
    [69]Buildd exposure stats [70]ppc64el 8u292-b10-1 [71]Installed 2d 17h 29m [72]ppc64el-unicamp-01 misc [73]old | [74]all (1) [75]giveback
    [76]Buildd exposure stats [77]s390x 8u292-b10-1 [78]Installed 2d 13h 9m [79]zandonai misc [80]old | [81]all (1) [82]giveback

    It’s not available for any of the debian-ports architectures,
    unfortunately. This should not be a problem for your use case.
    If needed, porters can probably make the old packages available
    for a rebuild so it can be built on ports architectures again,
    though not all build (the m68k patch for example needs updating
    as it no longer applies and was disabled).

    bye,
    //mirabilos
    --
    Infrastrukturexperte • tarent solutions GmbH
    Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sunil Mohan Adapa@21:1/5 to All on Wed Jun 16 06:10:01 2021
    Hi,


    I have a brand new infant to take care of and will take a few weeks to
    fix the remaining review comments. I am glad to see that openjdk-8 has
    moved in to Debian unstable again.

    Thanks,

    --
    Sunil

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)