Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adélie Linux request for infrastructure #59

awilfox opened this issue May 22, 2018 · 2 comments


None yet
2 participants
Copy link

commented May 22, 2018

If you are interested in filing a request for access to the Works on Arm test and
CI infrastructure, please fill out the details below, or contact Ed Vielmetti at with questions.

If you are just making a comment, ignore/delete those fields and file your issue.

Name, email, project role

Note that projects with two or more participants are preferred.

Project Title and description

Adélie Linux

Adélie Linux is a binary Linux distribution that focuses on the following unique goals:

  • Full POSIX® compliance (we are working with the Open Group)
  • Multi-architecture compatibility (we are already running on x86, PowerPC, and 32-bit ARM)
  • High-quality installation routine

We are vaguely related to the Alpine Linux distribution, as we are using the APK package manager. It is lightweight and relatively easy to hack on compared to the others, and fits very well with our goals. We also try to submit package changes to them that we feel would be useful to their goals. However, we have a focus on POSIX conformance, desktop software, and long-term support that Alpine does not.

For example, we ship coreutils instead of busybox by default; we have many diverged packages from Alpine to ensure a good experience for desktop users, and are shipping OpenSSL instead of LibreSSL so we can be closer to upstreams such as Qt and OpenLDAP; we are shipping Qt 5.9 LTS and Firefox ESR instead of the newer, less stable releases.

Which members of the community would benefit from your work?

  • Anyone who wants to run a desktop or laptop with an ARM64 chip.
  • Potentially postmarketOS, if they want to use our KDE packaging (we have discussed this with them).
  • Eventually, when we have ironed out the last remaining nits in musl, anyone who wants a POSIX certified server on ARM64.

Is the code that you’re going to run 100% open source? If so, what is the URL or URLs where it is located?


We have a "WIP" fork of the musl libc that we are using for staging our POSIX conformance patches.

All of our package recipes are in our Git repository, and we only ship packages that are themselves libre.

Other repositories, including our handbooks (in DocBook XML), gcompat (glibc compatibility library for musl), and more can be found on our GitLab group.

What infrastructure (computing resources and network access) do you need? (see:

The only ARMv8 server I see is:

c1.large.arm | Compute | Cavium ThunderX (2x) | Armv8 | 96 Cores @ 2.0 GHz | 128 GB | 250 GB

This would be enough to the point of excess. Realistically, our builders are typically configured with 8 or 16 GB RAM. 128 GB RAM would probably allow us to build all of our packages using a tmpfs (in RAM) instead of on-disk, which would make the time to port even shorter, but we do not need such amounts if you have a smaller RAM system that would otherwise meet our needs (lots of CPU and disk).

We would definitely need an IPv6 address, as the inbound rsync path to our mirror infrastructure is exclusively run over IPv6. Otherwise we would not ned anything special out of the network (100Mbit or 1Gbit is plenty).

Let us know if you need short-term (one time) support, or if this is a request for
continuous ongoing support. If possible, please identify foundations or other
support organizations that can help with long-running projects.

It would be very nice to have continuous support so that we have a way to build packages and updates as they need to be, however, the initial port would likely take 2-4 weeks based on our experiences with ARMv7 and PPC64. That would be the most critical time, as packages such as LLVM and Qt are infrequently updated and take a great number of resources we would not be able to provide ourselves.

Please state your contributions to the open source community and any other relevant initiatives

Brag a little bit about yourself, please!

Myself personally? I contribute to the KDE project regularly. I also try very hard to upstream patches to packages that I find do not build or work properly instead of making one-off patches for Adélie; patches I made have been applied to exiv2, PulseAudio, ConsoleKit, gphoto2, TigerVNC, efivar, and more.

Unrelated to my Linux endeavours, my friends and I wrote a portable, libre Game Boy emulator in C.

If you are wanting to know Adélie's contributions: we've made the aforementioned gcompat library, which is also shipping in VoidLinux and Alpine Linux. This allows many more glibc binaries to run unmodified on musl than is possible with musl's own glibc emulation. It currently has been tested to run binary RAID utilities, Intel's binary IPMI tool, Android Studio, and a few other packages. Our eventual goal is to have gcompat passing the LSB-5.0 Core test suite. We've also written documentation for Alpine's package building system (since we use it as well), but that has not yet been merged upstream.

@vielmetti vielmetti added the approved label May 23, 2018


This comment has been minimized.

Copy link

commented May 23, 2018

Approved! I've set things up with a reserved 32GB variant of the normal c1.large.arm for now.


This comment has been minimized.

Copy link

commented Jun 1, 2018

Closing the issue as all of the appropriate systems appear to be in good functioning order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.