Hey everyone!
This mail is an account of the community bonding period spent during the month 
of May 2020 for the
Android SDK Tools in Debian Project for Google Summer of Code 2020.

        the Community bonding period ended on 31st May 2020, and the coding 
period officially began yesterday, i.e 1st June 2020. But the we (Me, Manas 
Kashyap (https://manas-kashyap.github.io/) and Samyak Jain 
(https://samyak-jn.tk/)) had already started working on the project since 2nd 
week of June.

        Coding period is all about knowing your project, the organization, 
fellow students and mentors. We had our first meet over Jitsi a couple of days 
after the the selected students were announced. We introduced ourselves and 
chalked out a brief plan for the project. We decided to start working early on 
the project because we already know the packaging workflow of Debian and the 
project is also quite huge. The project is divided into 3 parts :
        * Kotlin
        * Gradle
        * Android SDK
        Kotlin part mainly includes packaging Koltin for debian and uploading 
it to archives. Major work on this was already done last year by Saif Abdul 
Cassim during GSoC 2019. Details about his work can be found on his blog 
(https://java-team.pages.debian.net/gsoc-kotlin-blog/).

        The things that blocked kotlin’s upload were:
        * libjline3
        * libpicocontainer
        * intellij-community-idea
        * kotlin-bootstrap
        Among these, everything except kotlin-bootstrap needed minor updates or 
changes. Kotlin bootstrap is a bootstrap package that’s needed only once for 
building Kotlin for the first time. We students divided the work among 
ourselves. Intellij-community-idea was assigned to me. It needed only minor 
edits to copyrights file and small tests to make sure the package builds clean. 
An ITP bug was filed before for the package and it as uploaded by Andrej 
Shadura (https://salsa.debian.org/andrewsh).

        Next, I worked on android-platform-libcore. Updated it to latest 
version available from upstream i.e: android-10.0.0+r36 tag. We have decided as 
of now to update all the Android SDK tools to the 10.0.0+r36 tag.

        Here are the changes that I have made:
        * Update new upstream version 10.0.0+r36
        * Use debhelper-compat (=12) .
        * Bump Standards policy compliance version to 4.5.0.
        * Update source and target compatibility to 1.8 in debian/build.gradle. 
This was needed to make sure the updated package builds correctly.
        * Add patches to remove the following annotations from json/. These 
annotations are not required for us as we are only building json and not the 
whole libcore package.
        * Unsupported Appusage
        * NonNull
        * Nullable
        * CorePlatform API
        The merge request for the same can be found here 
(https://salsa.debian.org/android-tools-team/android-platform-libcore/-/merge_requests/3/diffs).

        Another small task that I accomplished during the community bonding 
period is checking the checking the vavr dependency for javaslang. (which again 
is a dependency of Kotlin) The issue can be found here 
(https://salsa.debian.org/android-tools-team/admin/-/issues/8).

        GRADLE

        Now comes the second part of the project, Updating Gradle to latest 
version. This is a bit tricky because latest Gradle depends heavily on Kotlin 
and Kotlin itself depends heavily on Gradle. While I was working on libcore and 
intellij-community-idea, Samyak Jain worked on completing Kotlin part. We have 
managed to build Kotlin locally but it is a bit tricky to upload because of the 
kotlin-bootstrap dependency. I have used the prepared kotlin binary for the 
timebeing and started working on Updating Gradle to latest version which is 
6.4.1. We currently have 4.4.1 in debian archives.

        Latest Gradle depends heavily on Kotlin and hence all the build files 
that were originally in groovy are now build.gradle.kts . After updating to 
6.4.1 using git build package, all the patches needed to be modified so as to 
follow the logic conversion from groovy to kotlin. Some patches like asm7 
patch, CVE fixes, etc were dropped because they are already included upstream. 
Some patches had changes specific to groovy and were no longer required. They 
have been removed. The remaining patches have been edited to follow groovy to 
kotlin conversions. This required quite a lot of digging into older commits to 
understand the patches and a lot of reading was also needed to understand and 
convert patches to kotlin.

        As of now, all the patches have been fixed and the package builds 
correctly using source (i.e a debuild -S completes successfully) with some 
minor lintian warnings. I have uploaded all the work done so far on salsa 
(https://salsa.debian.org/theloudspeaker-guest/gradle).

        The binary build fails as the rules file needs some work. There are a 
few sections that are not required like simlinks to build Gradle 4.4.1 from 
Gradle 3 and the manual created in pom format, etc. I have patched out them 
locally but the basic build tasks which was “assemble” in gradle 4.4.1 has been 
changed to “init” in latest version. I have tried using init task but the build 
still fails due to some other errors. I am currently trying to debug and fix 
them. Will include details in the first week’s report.

        Coming to the 3rd part ot the project, Android SDK tools, we can start 
majorly working on it once we have Kotlin and Gradle in archives. There are 
some parts which can be updated without them and are being seen by Manas 
Kashyap.

        Now that the technical details are sorted, I would like to list the 
things I have learnt during this period:
        * Working of .gradle files and their interlinking in gradle projects.
        * Gradle tasks, builds, and build workflow of gradle projects.
        * Patches and their working in build environment. Quilt rejects, patch 
headers.
        * Effective use of Git Rebase, Lintian warnings and their meanings, etc.

While working, we have developed good team spirit among us students and we try 
to help each other whenever anyone of us gets stuck in a task somewhere. And I 
guess that’s the biggest take away from the community bonding period. It will 
help us work better together during the upcoming months and beyond.

The journey so far has been very intriguing and full of learning experiences. 
Very excited for the upcoming weeks. Thanks for reading. Stay safe. See you in 
the next one!

A blog post regarding community period can also be found here 
(https://theloudspeaker.home.blog/2020/06/02/community-bonding/).
Raman Sarda
theloudspeaker.home.blog

Reply via email to