Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Adélie Linux request for infrastructure #59
If you are interested in filing a request for access to the Works on Arm test and
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 is a binary Linux distribution that focuses on the following unique goals:
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
Which members of the community would benefit from your work?
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: https://www.packet.net/bare-metal/)?
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
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.