Google Summer of Code/2023/Ideas

From Gentoo Wiki
Jump to:navigation Jump to:search
GSoC 2022 logo

Want to spend your summer contributing full-time to Gentoo, and get paid for it? Gentoo is in its 11th year in the Google Summer of Code. In the past, most of our successful students have become Gentoo developers, so your chances of becoming one are very good if you're accepted into this program.

Most ideas listed here have a contact person associated with them. Please get in touch with them earlier rather than later to develop your idea into a complete application. You can find many of them on Libera.Chat's IRC network under the same username. If there is no contact information, please join the gentoo-soc mailing list or #gentoo-soc on the Libera.Chat IRC network, and we will work with you to find a mentor and discuss your idea.

You don't have to apply for one of these ideas! You can come up with your own, and as long as it fits into Gentoo, we'll be happy to work with you to develop it. Remember, your project needs to have deliverables in less than 3 months of work in most cases. Be ambitious but not too ambitious ;)

Students, please read this first

We have a custom application template that we will ask you to fill out. Here it is:

Congratulations on applying for a project with Gentoo! To improve your chances of succeeding with this project, we want to make sure you're sufficiently prepared to invest a full summer's worth of time on it. In addition to the usual application, there are 2 specific actions and 2 pieces of info we would like to see from you:

  • Use the tools that you will use in your project to make changes to code (e.g., source code management [SCM] software such as CVS, Subversion, or git). Please use the same SCM as you will use for your project to check out one of our repositories, make a change to it, and post that change as a patch on a mailing list or bug. Please fix a real bug reported in Bugzilla to show that you can use the tools to make a meaningful change. Your contact in Gentoo can help you determine which SCM and repository you should use for this as well as a good bug to fix. If your idea doesn't have a contact, please get in touch with us on the gentoo-soc mailing list or in real-time on IRC. Once you've made your change, link to it from your application.
  • Participate in our development community. Please make a post to one of our mailing lists and link to it from your application ( holds past postings). The gentoo-soc list would be a good starting point, if you aren't subscribed to any others already. The best posts would be an introduction of the project you're applying for and a little background about you, to introduce yourself to the community and get some broader input about your project.
  • Give us your contact info and working hours. Please provide your email address, home mailing address, and phone number. This is a requirement and provides for accountability on both your side and ours. Also, please tell us what hours you will be working and responsive to contact via email and IRC; these should sum to at least 35 hours a week.

These actions are things you will do extremely commonly as an open-source developer, and they really aren't that hard, so don't let them hold you back! The remainder of the application is free-form. Please read our application guidelines and Google's FAQ to complete it. Good luck!


Adding Ideas
First, enter the idea title into the form box below. Next, fill in all the information and save the article. Finally, edit this page and include a link to it. For assistance, talk to Blueknight on IRC.

Create new idea

Existing ideas

Your Idea Here (example)

Our best proposals, and a significant proportion of our total acceptances every year, come from student-initiated ideas rather than those suggested by Gentoo developers. We highly encourage you to suggest your own idea based on what you think would make Gentoo a better distribution. If you do so, we strongly recommend you work with a potential mentor to develop your idea before proposing it formally. You can find a potential mentor by contacting BlueKnight or via discussion on the gentoo-soc mailing list or #gentoo-soc IRC channel.

Contacts Required Skills
  • Initiative
  • Independence
  • Enthusiasm
Expected Project Size Expected Outcomes

175 hours/350 hours

  • Anything that would make Gentoo a better distribution
Project Difficulty


Automated Gentoo system updater

The overall target experience should be to create an easy to install tool that Gentoo users can use to keep their systems up-to-date. In GSoC 2023, we created gentoo_update with an associated mobile app! This year we can pick up where that project left off and make the mobile app's back-end fully self-hosted on a Gentoo Linux system.

Notification to users when something goes wrong was an important part of the 2023 project and improving the mobile app would help easy of user of Gentoo users.

Contacts Required Skills
  • Initiative
  • Independence
  • Enthusiasm
Expected Project Size Expected Outcomes
  • 175 hours for basic functionality
  • 350 hours for mobile app part of the idea
  • A fully self-hosted back-end for gentoo_update that can be deployed on a Gentoo Linux system.
  • Ability for the back-end to serve notifications to IRC and email.
  • Update gentoo_update to take hints from Gentoo news items and pass on actionable notifications to users.
Project Difficulty


Better testing infrastructure for Gentoo Prefix

Gentoo has a CI system (the tinderbox) to automatically test installation of packages with various configurations. However, during development, changes to ebuilds may break packages in ways that only affect Gentoo prefix and which are not caught by the regular testing. It would be great to have some CI infrastructure in place for Gentoo Prefix bootstraps, but also a similar CI system to the tinderbox running not on vanilla Gentoo, but on Gentoo prefix, to quickly identify problems with new packages as they are introduced into the tree.

Contacts Required Skills
  • Bash
  • Python
Expected Project Size Expected Outcomes

350 hours

Running CI system testing Gentoo prefix packages and automated bootstraps of Gentoo Prefix on a few host platforms.

Project Difficulty


netifrc modernization

What should the future of Gentoo networking configuration be? Explore potential improvements within the aegis of netifrc & other network configuration systems.

Can all of netifrc configurations be represented by systemd-networkd, netplan or other systems? Can other network configuration systems successfully integrate in all variations of Gentoo init systems (openrc, systemd, epoch, runit).

Contacts Required Skills
  • shell scripting
  • client-side network configuration
  • ability to read C of other projects (netplan & systemd-networkd are written in C)
Expected Project Size Expected Outcomes


  • Comparative documentation on network configuration: HOWTO do $X in each network configuration system
  • Recommendations on future network configuration for Gentoo systems
  • Code as needed to reach parity between netifrc and other network configuration systems
Project Difficulty


portage machine readability

This project will add structured/machine-readable formats for emerge views.

Various example steps:

  • `emerge -p $PKG` should show a structured output about the change, package, version, slots, use flags etc.
  • Emerge errors should have structured output, making them easier to understand what's wrong, and the boundaries of each error (because many errors seem to flow together if there are multiple errors).
  • Structured progress output for other tools to watch build status, esp during parallel package building.

Contacts Required Skills


  • Python
  • structured output systems
Expected Project Size Expected Outcomes
  • Structured output options for Emerge commands
Project Difficulty

Portage code modernization

Portage's codebase is aging (as old as Gentoo!) and needs modernization for contemporary Python style and techniques. This project involves picking components of the Portage codebase, understanding it, annotating it (with extensive comments), and then refactoring as appropriate.

A lot of this technical code debt makes implementing new GLEPs and features more expensive and time-consuming than it needs to be. This project is to work on modernizing the codebase in appropriately-sized chunks. Rewriting whole modules is less important than documenting the existing code, as well as researching the reasons for its existing behaviour, and refactoring (even small amounts) in the course of that work.

Contacts Required Skills
  • Python
  • Familiarity with git (including finding why code was added in the first place, relevant bugs, etc)
Expected Project Size Expected Outcomes

175 hours or 350 hours, depending on appetite for larger refactoring.

  • Documenting (inc. commenting) sufficient files, modules, and components of Portage
  • Important modules within the agreed-upon component(s), e.g. would be documented, with appropriate code-cleanups made, and refactored & split into appropriate abstractions, allowing further work to be done in future (e.g. incorporating different dependency resolvers).
  • Refactoring segments once understood. The aim is to first document the reason for existence of functions, conditions, edge cases, and so on, and then to refactor (even only locally/scoped only to within function(s) as-you-go) to improve readability, efficiency, and correctness.
Project Difficulty

Easy or Medium. Some sections will be easier and the codebase is large enough so that people can choose components according to the appropriate difficulty.

Probabilistic programming with Anglican on Clojure, Java and Gentoo

Probabilistic programming is a new paradigm of Bayesian statistics to automatically compile generative models into inference ones. Anglican is a Turing-complete academic probabilistic programming language with practical applications, built on top of Clojure. Clojure (dev-lang/clojure::gentoo) is a dialect of LISP hosted on Java virtual machine, with its libraries including Anglican collected into a maven repository "Clojars".

This project aims to offer Gentoo users with Turing-complete probabilistic programming, by building a repository of Clojure and Anglican libraries using java-ebuilder (app-portage/java-ebuilder::gentoo).

Contacts Required Skills
Benda Xu An applicant should:
  • have used Gentoo for at least 1 year;
  • have authored at least 1 ebuild;
  • be proficient with Git and Bash;
  • have first-hand experience with Java and LISP.
Expected Project Size Expected Outcomes
350 hours. Anglican, its dependencies and necessary auxiliary libraries in an overlay or ::gentoo.
Project Difficulty

Modern C porting of Gentoo packages

Newer versions of compilers are planning on becoming significantly stricter with the C code they will accept or reject. This is a huge problem for the general Linux ecosystem.

Even worse is that some of these failures are silent and lead to incorrect behaviour at runtime. Extra care must be taken to detect this and we must prioritise these cases because they're the most harmful. With the release of Clang 16 (expected March 2023), the following specified warnings will be treated as errors:

  • -Werror=implicit-function-declaration
  • -Werror=implicit-int
  • -Werror=int-conversion (been enabled in clang 15)
  • -Werror=incompatible-function-pointer-types (for GCC a student might have to use -Werror=incompatible-pointer-types instead)

Also, in the coming years with C2x (likely C23) additional changes like removing certain deprecated prototypes will be made.

The above changes will affect affect Gentoo packages in the following ways:

  • Lots of packages fail to build with these settings
  • Sometimes packages build successfully but their ./configure scripts have misdetected features or otherwise made the wrong conclusion about the system because they expect a test to succeed when it now fails.

Please read Modern C porting in detail and see also bug #870412.

Students can test and provide patches for affected packages on both glibc and musl systems in parallel, but keeping glibc as the primary target might help fixes reach users faster.

Contacts Required Skills
  • Familiarity with C programming
  • Familiarity with build system and configuration scripts
  • Knowledge of bumping ebuilds and applying patches in ebuild
  • Git
  • Patience

Expected Project Size Expected Outcomes
  • Bring down the bug list
  • Keep primary focus on glibc to help faster reach of bug fixes to end users
  • While focusing on musl, the tasks can be divided into smaller sub tasks. Such as first installing a desktop environment like GNOME or KDE to ensure a basic desktop is usable and can be built on musl. Then starting to emerge some of the affected/already fixed packages on musl to ensure that they can be built and patch works on musl too.
  • Send patches upstream so that other users and distributions can take advantage (this is critical)
  • Provide patches for both glibc and musl systems if possible
  • Report other broken packages not in the bug list
Project Difficulty