Re: Kotlin: looking for a DD to review/upload
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
Reply to: