Android SDK Tools in Debian

Description of the project: The Android platform is free software, including the tools used for developing apps for Android. Debian-derivatives are already a preferred platform for Android developers, and since _stretch_, Debian includes core Android SDK tools, enough to build some apps. The Debian Android Tools team is working towards the goal of having the entire Android toolchain and SDK in Debian. That means Android apps can be developed using only free software from easy-to-use packages. In combination with Replicant, this will make the most popular operating system in the world, Android, into a 100% Free Software platform. This project is in conjunction with the Debian Java team, since many tools like gradle are commonly used to build Java software. Since packaging the whole Android SDK is a massive project, we also focus on specific use cases that can be covered by smaller chunks: tools for analyzing APKs, easy setup of standalone pieces that are useful to non-Android developers (Emulator, NDK, etc).

• Confirmed Mentor: Hans-Christoph Steiner (UTC+2), _hc on IRC and @eighthave:matrix.org

• How to contact the mentor: Contact the team via Matrix, IRC or email, since the mentors work as a team: https://wiki.debian.org/AndroidTools#Communication_Channels

• Confirmed co-mentors:

  • Roger Shimizu / rosh (UTC+9)
  • Jochen Sprickerhof / jochensp / jspricke (UTC+2)

• Difficulty level: Mostly medium to difficult, but a small project could be a bit easier.

• Project size: Packaging the Android SDK is a large, multi-faceted effort. A student project can be 90 hour (small), 175 hour (medium) or 350 hour (large).

• Deliverables of the project: The deliverables of this project will mostly be finished packages submitted to Debian sid, both for new packages and updated packages. Whenever possible, we should also try to get patches submitted and merged upstream in the Android sources.

• What the intern will learn: Students will learn to figure out large scale projects like Android, and how to organize their own work within such projects. They will also learn about building and packaging C/C++, Kotlin and Java, as well as some of the guts of Android itself.

• Application tasks:

  • Find out what new/missing components (ndk? emulator?) and the location of their source code

  • Check Android Tools bash completion for bugs and completeness (e.g. for adb, fastboot, etc), file bugs if it doesn't work properly

  • Update 51-android.rules in https://salsa.debian.org/android-tools-team/android-sdk-meta to the latest upstream version.

  • Anything else you think suitable. We also have a list of issues that you could work on, see https://salsa.debian.org/android-tools-team/admin/-/issues?label_name%5B%5D=GSoC

• Related projects: CalyxOS is a free software Android ROM (allows binary blobs). F-Droid is a repository of free software Android apps. Replicant, the 100% free software Android ROM, uses our packages to provide a 100% free software Android SDK.

There are many chunks of work to be done, sorted in priority:

• Upgraded Kotlin, which is heavily used by Gradle and the SDK itself

• Finish packaging newer version of gradle , which is the official build system for Android apps

• Restructure build-tools package based on upstream tags and platform-tools source packaging.

• Make sdkmanager integrate nicely with tools packaged in Debian.

• Package the latest Android Target Platform Framework (WiP)

• Finish packaging all of the core development tools (Install android-sdk and compare /usr/lib/android-sdk with the one downloaded from Google)

• Update android-tools and relevant pkg-java packages to the latest upstream version

• Create a tool to automatically make packages based on Maven Central's reproducible builds and source tarballs.
• Create a tool similar to game-data-packager but for Java: make Debian packages with jdeb based on download location, signed/unsigned tarball, build system, etc. These packages would go into contrib

• Port build systems from Gradle to Maven/make

• Package and improve related tools, like apktool, androguard, fdroidserver, jadx, qark, OWASP Dependency Check, etc.

• Improve android-sdk-helper

• Make all Android Tools packages build reproducibly

• Add Continuous Integration tests

• Improve package build systems to be more tightly integrated with upstream build systems (WiP)

• Package new parts of the Android upstream source, including the NDK, emulators, Android Studio, etc.

Since this project is a large one, multiple mentors and students could work on it simultaneously. You can find relevant documentation in READMEs in each git repo and source package. There is also this wiki section: AndroidTools

There is also a blog post about contributing to this project here

The Debian Android Tools Team works with git and git-buildpackage: PackagingWithGit

Benchmarking Parallel Performance of Numerical MPI Packages

Description of the project: This project aims to set up parallel/HPC performance testing for our MPI numerical packages. The project has two goals. Firstly, to provide benchmarking of debian MPI packages such as fenicsx (finite element computation) to demonstrate scalability of the software in cloud computing environments. Secondly, to provide a type of CI testing ensuring that MPI scalability is maintained as MPI- or computation-related packages such as OpenMPI, PETSc, OpenBLAS are upgraded. We aim to set up benchmarking tests to run regularly and report over varying test conditions, for instance comparing performance with different BLAS implementations. It would be useful to be able to quantify how well our HPC packages actually scale (in cloud computing environments) and monitor if there is any drop in performance (e.g. with version updates). It will also be useful to report their performance with the various BLAS alternatives.

Some packages have benchmarks already at hand. The FEniCS project for instance offers fenicsx-performance-tests (both prebuilt and source). The outcome of the project will be the preparation of a protocol for setting up and launching MPI CI testing on an appropriate cloud computing service, identifying which parameters (test size etc) must be used to get meaningful numbers. A suggested tool for managing test parameters and results might be https://reframe-hpc.readthedocs.io/en/stable/ The report format may be similar to https://fenics.github.io/performance-test-results/ , with a web-based UI (i.e. buttons) to select different reports.

• Confirmed Mentor: Drew Parsons

• How to contact the mentor: dparsons@debian.org

• Confirmed co-mentor: Francesco Ballarin <francesco.ballarin@unicatt.it>

• Difficulty level: Medium

• Project size: Medium sizes (175 hours) with the possibility to split into two small (90 hour) subprojects.

• Deliverables of the project:

  1. Setting up benchmark conditions
     1. Protocol for launching a cloud computing instance and running MPI benchmarks. b. Determining benchmark parameters (job size) suitable for generating meaningful performance comparisons. c. Configuration of a test management system (e.g. reframe).
  2. Implementing and Reporting Benchmarks
     1. Implementation of the 1.a. protocol to commence regular benchmarking on a suitable cloud computing system. b. Setting up data management for test results. c. Setting up web-based reporting of test results

• Desirable skills: Skills that the student has or is willing to develop.

  • unix shell commands and debian package installation
  • launching parallel MPI calculations

• What the intern will learn: The intern will learn how to characterise performance of parallelised computations (speedup, strong and weak scalability) and gain experience configuring and maintain cloud computations.

• Application tasks:

  1. How is a parallel job launched using MPI?
  2. Summarise the difference between strong and weak scaling.
  3. Which MPI implementations does Debian provide? Which one is default?
  4. Which BLAS implementations does Debian provide? How is the preferred BLAS implementation configured on a given installation?
  5. Prepare a bash shell script that installs the packages required for running autopkgtest on fenicsx-performance-tests, then loops through each available BLAS implementation, installing each blas package one by one and running autopkgtest on fenicsx-performance-tests for each BLAS implementation.

• Related projects:

  • Benchmarking for the FEniCS Project

  • Grid5000 academic High Performance Computing network in France

Quality assurance and continuous integration for biological and medical applications inside Debian

Description of the project: The Debian Med Blend has packaged a lot of applications used in medicine and biology for Debian. To enhance and continuously ensure the quality of the packaged software we try to implement Continuous Integration tests for all our packages. This was accomplished thanks to several past interns. These tests are of specific importance since only a very small share of the developers inside the Debian Med project are actual users of the software and thus automated testing is required to provide our users with the quality we like to approach. Interns are also not necessarily comfortable with the topic of medicine and biology - reading documentation or publications or directly contact the authors of the software frequently gives sensible ideas how to write a test for the software.

• Confirmed Mentor: AndreasTille

• How to contact the mentor: tille@debian.org

• Confirmed co-mentors:

• Difficulty level: medium

• Project size: Depending from students availability this project can be medium or large. The advantage of the project is it can be split into small pieces

• Deliverables of the project: Continuous integration tests for Debian Med applications lacking a test, Quality Assurance review and bug fixing if issues might be uncovered

• Desirable skills: Background in bioinformatics, medical imaging could be an advantage, but interest in scientific software and reading relevant documentation and papers might be sufficient. Debian packaging skills are an extra plus but can be taught in the project run.

• What the intern will learn: Detailed insight into the software maintained by the Debian Med team, bug triaging in scientific software, Debian packaging skills, optimising bioinformatics and other scientific tools

• Application tasks: Pick bugs like 1035113, 1035116, 1035121, 1035175, 1035178, 1035182, 1035188, 1035200, 1035258, 1035276, 1035277, 1036289, 1036480, 1036488, 1036500, 1036506 and try fixing it - asking the mentor for help is perfectly fine and actually recommended. This is on one hand proof that the student is able to understand Debian packaging and understands the actual topic at a sufficient level.

• Related projects: SummerOfCode2016/Projects/BioToolsTesting, SummerOfCode2017/Projects/QA_BiologyApps, ?Continuous_Integration_for_biological_applications_inside_Debian, SummerOfCode2019/ApprovedProjects/CIforDebianMed SummerOfCode2020/ApprovedProjects/DebianMedQAGSoC and Outreachy Project Proposal: Quality Assurance and Continuous integration for applications in life sciences and medicine

Debian MobCom

Description of the project: The Osmocom project is an umbrella project regarding Open source mobile communications. This includes software and tools implementing a variety of mobile communication standards, including GSM, GPRS, EDGE, UMTS, HSPA, LTE and their associated interfaces and protocol stacks. The debian-mobcom team is working on creating packages for all parts of the project. At the moment a version of ?OsmoBts (package osmo-bts), a Base Transceiver Station for GSM, and its dependencies are already part of Debian. Further OpenBSC, a software implementation for the GSM/3GPP protocol stack is available. Nevertheless development of the software stack does not stop and new features like support for ISDN or interfaces for USB devices need to be taken care of.

• Confirmed Mentor: Thorsten Alteholz

• How to contact the mentor: IRC (nick ta) or email (debian@alteholz.de)

• Confirmed co-mentors:

• Difficulty level: Medium

• Project size: 175 hour (medium sized) project with the possibility to split into two small (90 hour) subprojects

• Deliverables of the project: packages listed on the package list needs to be updated and about 5 new packages need to be created

• Desirable skills: building software written in C; working with git; basic knowledge with Debian packaging

• What the intern will learn: creating Debian packages from scratch; working with sbuild; doing basic QA stuff with lintian, piuparts; preparing patches for upstream; obtaining some insights in mobile networks

• Application tasks: look at already available packages (libosmo*, osmo*), build one on your own computer, make the resulting packages available to others and discuss possible improvements

Improve support of the Rust coreutils in Debian

Description of the project:

This project has two goals:

1. propose a better way to replace the GNU Coreutils in Debian by the Rust Coreutils

2. Improve the compatibility with GNU by fixing https://uutils.github.io/coreutils/book/test_coverage.html and install/remove all Debian packages to make sure that all necessary features for Debian are well supported

Homepage: https://github.com/uutils/coreutils

An article about it: https://lwn.net/Articles/857599/

To improve your chances to be selected, please contribute a few changes to the project to demonstrate your commitment and understanding of the project.

• Confirmed Mentor: Sylvestre Ledru

• How to contact the mentor: sylvestre@debian.org

• Confirmed co-mentors: Terts Diepraam <terts.diepraam@gmail.com>

• Difficulty level: Large

• Project size: 350 hours

• Deliverables of the project: Better compatibility with the GNU implementation, easier installation

• Desirable skills: Rust, packaging

• What the intern will learn: How the Coreutils work, the low level part of the OS

• Application tasks: Fix one or more GNU test listed on: https://uutils.github.io/coreutils/book/test_coverage.html

Improve support of the Rust findutils in Debian

Description of the project:

This project has two goals:

1. propose a better way to replace the GNU findutils in Debian by the Rust findutils, xargs, etc
2. Improve the compatibility with GNU by fixing the missing/incompatible options

Homepage: https://github.com/uutils/findutils

To improve your chances to be selected, please contribute a few changes to the project to demonstrate your commitment and understanding of the project.

• Confirmed Mentor: Sylvestre Ledru

• How to contact the mentor: sylvestre@debian.org

• Confirmed co-mentors: Terts Diepraam <terts.diepraam@gmail.com>, Daniel Hofstetter <daniel.hofstetter@42dh.com>

• Difficulty level: Large

• Project size: 350 hours

• Deliverables of the project: Better compatibility with the GNU implementation, easier installation

• Desirable skills: Rust, packaging

• What the intern will learn: How the findutils work, Rust

• Application tasks: Fix a GNU test

Debugging ROCm test failures

Description of the project: The Debian ROCm Team operates ci.rocm.debian.net, a CI environment in which the ROCm software stack's unit tests are run on various AMD GPU architectures.

Some of the tests are failing. Failures can result from something as simple as test results deviating beyond some tolerated error, or as complex as amdgpu driver issues. These are often architecture or environment-specific and may require remote access to specialized hardware.

The task would be analyze and report on the failures, and fixing them and/or submitting patches, where possible.

• Confirmed Mentor: Cordell Bloor

• How to contact the mentor: cgmb@slerp.xyz

• Confirmed co-mentors: Christian Kastner ckk@debian.org, Mo Zhou

• Difficulty level: High

• Project size: High (350h)

• Deliverables of the project:

  • Report on all identified test failures
  • Report on individual analyses of test failures
  • Bonus: Submitted fixes

• Desirable skills:

  • Proficiency with Linux-based operating systems (ideally Debian or Ubuntu)
  • C++
  • Debugging with gdb
  • General understanding of how operating systems work and interact with hardware

• What the intern will learn:

  • Working with ROCm, the main challenger to CUDA
  • Hardware

• Application tasks:

  • Collect all failed tests in our CI
  • Analyze each failed test, documenting findings
  • Suggest fixes if possible

Expanding ROCm support within Debian and derivatives

Description of the project:The Debian ROCm Team maintains packages of AMD's ROCm, a collection of libraries for GPGPU programming. The core upstream libraries have already been packaged, but there are still a number of libraries commonly used in machine learning that need to be addressed. There are also tools for debugging and profiling that have not yet been packaged. Furthermore, other packages, like ?PyTorch and Blender, need to be extended to make use of these libraries.

Note: The mentors are willing to continue mentorship beyond GSoC, should the intern be interested in joining the Debian Project

• Confirmed Mentor: Christian Kastner

• How to contact the mentor: ckk@debian.org

• Confirmed co-mentors: Cordell Bloor, Mo Zhou

• Difficulty level: Medium

• Project size: High (350h)

• Deliverables of the project:

  • New Debian packages
  • Patches for existing packages (e.g., expanded hardware support, tuning and optimizations)

• Desirable skills:

  • Strong familiarity with Debian and/or Ubuntu
  • Proficiency with CLIs

  • Some experience with build systems (cmake a plus)

• What the intern will learn:

  • Debian packaging (.deb) and maintenance within the Debian ecosystem

  • Interacting with a broad variety of other groups within Debian, for example the Release Team and ftp-master

  • How to contribute to Debian in general

• Application tasks:

  • Read our New Maintainer's Guide and the Developer's reference
  • Package various ROCm-related libraries and dependencies

Salsa CI in Debian

Description of the project: Salsa CI is a custom-built continuous integration framework that is used in the Debian Gitlab instance (Salsa) and helps Debian maintainers manage roughly 9,000 projects. The Salsa CI pipeline emulates the Debian build process and runs several Debian quality tests, helping to increase the probability that packages can migrate from Debian Unstable to Testing reliably, quickly, and without issue. When new source code triggers a Salsa CI pipeline, 17 different jobs run to build and test it automatically. Salsa CI checks to see whether the to-be-uploaded packages build on multiple architectures (at the moment, amd64 and i386, and optionally on Arm), runs autopkgtest test suites to try to identify potential regressions, and checks for common errors with our custom linter, lintian, among other tests.

• Confirmed Mentor: Santiago Ruano Rincón

• How to contact the mentor: santiago@debian.org

• Confirmed co-mentors: Emmanuel Arias <eamanu@debian.org>

• Difficulty level: Medium

• Project size: Medium sized (175 hours). Depending on the student's availability, this project can be medium or large. The advantage of the project is it can be split into small pieces.

• Deliverables of the project: Fix and discuss issues reported to Salsa CI. Specially Labels "Nice-to-have", "Accepting MRs".

• Desirable skills: Awareness of Gitlab pipeline. Working with git. Basic knowledge of Debian packaging.

• What the intern will learn: Debian Release process, Debian package building, Debian CI process, Basic QA of Debian packages.

• Application tasks: Pick issues from here, discuss with the team and try to fix them.

• More resources:

  • https://debconf20.debconf.org/talks/47-where-is-salsa-ci-right-now/

  • https://about.gitlab.com/blog/2023/09/19/debian-customizes-ci-tooling-with-gitlab/

  • https://debconf19.debconf.org/talks/148-salsa-ci-debian-pipeline-for-developers/

procps: Development of System Monitoring, Statistics and Information Tools in Rust

Description of the project: Create Rust versions of system monitoring and statistics tools, with a focus on full option compatibility and passing GNU tests.

This project involves the Rust-based development of system monitoring and statistics tools: top, vmstat, tload, w, and watch. And process management and information tools: ps, pgrep, pidwait, pkill, skill, and snice.

The objective is to achieve full compatibility with all options and to pass GNU tests, ensuring these tools provide accurate and reliable system insights.

To improve your chances to be selected, please contribute a few changes to the project to demonstrate your commitment and understanding of the project.

• Confirmed Mentor: Sylvestre Ledru

• How to contact the mentor: sylvestre@debian.org

• Confirmed co-mentors: Terts Diepraam <terts.diepraam@gmail.com>, Daniel Hofstetter <daniel.hofstetter@42dh.com>

• Difficulty level: Large

• Project size: 350 hours

• Deliverables of the project: Robust tools for system monitoring and statistics, fully compatible with existing options and verified by GNU tests.

• Desirable skills: Rust expertise, knowledge of system performance metrics, familiarity with GNU testing frameworks.

• What the intern will learn: How the Coreutils work, the low level part of the OS

• Application tasks: Fix one or more GNU test listed on: https://uutils.github.io/coreutils/book/test_coverage.html

Debian ROCm CI: New frontend

Description of the project: The Debian ROCm Team operates ci.rocm.debian.net, a CI environment in which the ROCm software stack's unit tests are run on various AMD GPU architectures.

The current frontend is provided by Debian's own CI software, debci. However, this frontend is optimized for navigating and displaying information for tens of thousands of packages for a particular operating system (such as Debian or Ubuntu).

Our own CI environment is only interested in a few dozen packages relevant to ROCm: the ROCm libraries, and all of their reverse dependencies, such as ?PyTorch or Blender.

Furthermore, we'd like to see information that is not part of the current frontend, such as: worker status (including metadata), summary of the most recently run tests, visualizations of worker queues, and so on.

• Confirmed Mentor: Christian Kastner

• How to contact the mentor: ckk@debian.org

• Confirmed co-mentors:

• Difficulty level: Easy

• Project size: Medium

• Deliverables of the project:

  • A new web frontend for our CI

• Desirable skills:

  • Templating in Ruby preferred, but Python also possible
  • Javascript frameworks a plus

• What the intern will learn:

  • Aggregation and visualization of large amounts of data
  • UI/UX

• Application tasks:

  • Familiarize with the available data
  • Propose a new frontend, with mockups/wireframes
  • Solicit feedback and consensus on the design
  • Implement the final version

Debian ROCm CI: Worker telemetry

Description of the project: The Debian ROCm Team operates ci.rocm.debian.net, a CI environment in which the ROCm software stack's unit tests are run on various AMD GPU architectures.

Workers run tests either on bare metal, or in containers, or in QEMU virtual machines. In all cases, collecting telemetry on GPU and system health during tests would provide information useful for maintaining system health at runtime as well as enabling higher-level analysis over time and system setups.

• Confirmed Mentor: Christian Kastner

• How to contact the mentor: ckk@debian.org

• Confirmed co-mentors: Cordell Bloor

• Difficulty level: Medium

• Project size: Medium (175h)

• Deliverables of the project:

  • Agents for collecting telemetry bare metal, container, and virtual machine (kvm) use
  • Daemon for receiving collected telemetry

• Desirable skills:

  • Experience with Linux-based operating systems
  • Some experience with Python

• What the intern will learn:

  • Working with isolation technologies (containers, kvm)
  • Visualization of system health data

• Application tasks:

  • Research and basic familiarization with container and kvm isolation

  • Propose design for daemon<->agent communication

  • Implement daemon
  • Implement agents for bare metal, containers, VMs