December Adventure 2023
Ok, lets try something different this year: I will spend 30min/day on improving Alpine Linux by working on issues from the issue tracker. This can be commenting, tracing package related problems upstream, fixing documentation issues, creating small code patches, or just helping to reconstruct issues and finding the root cause.
Alpine Linux Issue Tracker
Day 1
gpk del --purge will not delete .pkg-new files. I commented my thoughts on this, because this needs some code change in apk-tools -- or it is intended for some reason I don't know. If this is the case, the documentation need to adjust a little.Issue #10950: `apk del --purge` does not delete "apk-new" files
Day 2
The .apk-new features lead me to another ticket, which seems kind of stuck in a feature creep. I tried to resolve this.Further, I've discovered the "protected_paths.d" feature, which is not well documented. For that, I"ve created an account for the wiki, but did not found a suitable place to document that feature. Maybe a task for tomorrow :)
Issue #10829: Understanding .apk-new protected files behavior
Day 3
Found a suitable place to describe the .apk-new files (in the user handbook). I've created a fork, adjust the documentation and created a merge request. Documenting the package developer part of that feature need to find a better place.Merge Request on user-handbook
User Documentation: Installing Packages
Day 4
Back to something familiar: Maintaining packages. I maintain a bunch of packages on ArchLinux and the PKGBUILD format is quite similar to apk, so it looks fairly easy to adopt some packages or fix some package related issues. Along the way I found a package request for an abandoned project. I've commented this, so it can be closed. The package request for yextend (a zip extension for yara, a malware search tool) seems to be essential as a companion tool to yara. This seems to be the ideal candidate for a start. To actually build some packages, I need some build environment, which I've created.Issue #12875: Package Request: stagit-gemini (abandoned)
Issue #9625: Package Request: yextend (yara zip extension)
My little abuild helper script
Day 5
Time to build some packages. I've started by reading through the wiki entry for creating Alpine Linux packages, which is fairly comprehensive. yextend (the package I want to build) is not on ArchLinux, so I can not cheat and have a look at the PKGBUILD from ArchLinux to find out which dependencies are needed, how to build the package, what files need to be installed after build and so on. Its a perfect start to do all from scratch.The "newapkbuild" command gives me a starting point. First obstacle: The makedepends, which need to be installed before building the package. In order to find all dependencies, I ran ./configure in a loop and search missing pieces on the package file search. Some times I consult the APKBUILD files itself to find the subpackages. This is a really nice system on Alpine Linux: Each package is split into the binary distribution, a "-dev" package which contain all headers (like -devel on Debian) and a "-doc" package which contain all documentation (manpages, infopages, example configuration, ...). Also nice is the "abuild checksum" tool, which will update the sha512sums in the APKBUILD file itself.
After a while, "./configure" exits without an error, so next step was "make" -- which failed right after the start. And this is probably the hardest part of creating and maintaining packages on Alpine Linux: Make it work on musl lib. I need to fix yextend to work with musl, but that's a task for tomorrow.
Wiki-Entry for creating Alpine Linux packages
Alpine Linux package file search
musl libc
Day 6
After poking around a little bit, the first issue was the off64_t type, which is not needed (and non existent in musl) because it is already 64 bit. So changing this to off_t solved the first problem.The next issue was several undefined "TRUE" and "FALSE" defines. These are also not part of musl and was easily fixed by changing this to "true" and "false".
The third problem was a weird one. It seemed that this is not an Alpine Linux or musl related problem because a function had a missing parameter. After a long journey to m4, automake and autoconf, I ended up by the "yara" dependency. And indeed, the function got a third parameter years ago. After checking the issue tracker of yextend, the problem was obvious: There are several branches for several versions of yara, up to 4.0.0. But Alpine Linux is shipped with version 4.4.0, which is nowhere compatible with yextend.
So, the main problem here is that yextend need to be fixed to work with yara 4.4.x in order to get this thing compiled nicely. At this point I am not sure if I want to go deeper into yara and fix all the problems here upstream. I will create a new issue in the issue tracker for that and move on. Same goes for the Alpine Linux issue, so everybody is informed of the current status and the next action which need to be taken. But this is a part for tomorrow.
off64_t problem
autoconf Loop constructs
Different yextend branches for different yara versions
Day 7
I've documented my findings from yesterday and created two tickets on the yextend projects and commented it on the Alpine Linux yextend package request ticket. I could fix the compatibility issues with musl, but I will wait how active the project is. The different branches mess need to be fixed first in order to work with it. If there is no movement in that direction, I may need to fork the repo.So, let's grab something more promising today: rinetd, a ip/port forwarder, which seemed active. Creating the APKBUILD file was easy, but "abuild" hang on entering the fakeroot. Could not find the issue in time, so this is the task for tomorrow.
Issue #9625: yextend package request
yextend issue: Update codebase to yara 4.4.0
yextend issue: musl compatiblility
Issue #15304: rinetd package request
Day 8
My Docker solution to build a dev environment to create Alpine Linux packages did not worked well and I thought to myself: "I can't be the only one with that problem", so I searched a little bit and found a blogpost from Orhun Parmaksız, which already build a nice tool for exactly that. I get it up and running, but I struggled with zellij a little (a tiling terminal window manager like screen or tmux).orhun: alpkg tool
zellij
Day 9
I had two issues with the alpkg tool. I fixed it locally for now and created two issues on the alpkg issue tracker for that. Maybe I will create proper merge requests for that tomorrow.With that out of the way, I was able to create the APKBUILD file for the rinetd project. No longer than an hour after I pushed it to the Alpine Linux gitlab repo and created a merge request, Patrycja Rosa (@ptrcnull) gave me some very valuable suggestions for improving the package. And that's what I love about open source software: Random people working together and helping each other out to create even better software.
(alpkg) Issue #4: terminals other than bash not supported
(alpkg) Issue #5: alpkg update ignores other files
(aports) Merge Request !56949: testing/rinetd: new aport
Day 10
My rinetd package got merged into master, so it is officially part of Alpine Linux now (testing repo, edge), nice! I've skimmed through the other issues with the "type:package-request" label, and found "wyrd" (a TUI frontend for reminder), "cytopia" (a city building game) and "tilde" (a terminal editor) which matches my taste. No idea how to build and test software with a graphical user interface, so this is a nice challenge.Along the way I found an issue which I had myself just last friday: Blender segfaults on my AMD Ryzen. The problem was identified in the issue, but no workaround/fix yet. Because I had that problem on my ArchLinux installation, I contributed my findings and a possible workaround.
I need to set up a VM with a working X11/Wayland, but that's a task for tomorrow.
Issue #15511: Blender 4.0.1 segfault
Issue #13934: Package request: cytopia
Day 11
In order to work on the cytopia package, I had to set up wayland with a window manager. For that I used the standard Alpine Linux image, spin up a KVM VM with virt-manager and install Alpine Linux on it. After that, I set up sway to actually run GUI applications.To get a feeling what's missing, I clone the cytopia project from Github and run cmake to see, how far I get. Result: not that far :) So I checked the prerequisites in the README and tried to find matching Alpine Linux packages. For the following packages, I had no luck:
* conan (a python lib to manage C/C++ dependencies)
* libnoise (a noice generator for C++)
* imgui (a UI lib for C++)
So, I guess I need to create these packages first :)
conan
libnoise
imgui
Day 12
After investigating the dependencies a little, I found out that the libnoise is more or less abandonware. No update in the CVS(!) for a decade. That leads me wonder how active the cytopia game actually is. And sadly, this seems also a little dusty. The only "active" member is the Dependabot, so I've wrote an email to the most active members according to the git history. For the time being, I've documented this in the related cytopia issue and went on to some other issue.Lets try something different: Finding the root cause of some issues. First will be partitionmanager exist with some dbus error messages. With my VM, I can easily check if the problem exists on a fresh installation. I was not able to reproduce the problem, so I commented this and gave some hints how to debug this further on the "faulty machine".
Issue #15569: partitionmanager list no devices
Issue #13934: cytopia package request
Day 13
Today, I've searched through all existing packages, who does not have an active maintainer. A lot of packages are not of my interest (meaning: I don't know/use them), so it's hard to adopt and maintain such a package. FreeGLUT, jumped out of the masses, because I used that lib in the past for some OpenGL stuff, so I know it well enough to take care for it. So I adopted it.Next, I wanted to add the imgui lib. The reason for that is that a member from the cytopia team wrote me. The project is not completely abandoned and will be more active in the coming months. So there is some hope. Even if cytopia never got a clean release, imgui is used in many open source projects, it is not a waste of time to add that package.
But before that, I want to fix the two bugs in alpkg. So, it is just a matter of creating the branches, apply my patches and create some merge requests for it. No big deal.
Search result for all packages without maintainer
Merge Request !57192: Adopt freeglut
Pull Request #6: force shell to be bash
Day 14
Had a stressful day, so not much time to fiddle with Alpine Linux issues. But I keep cranking! My pull request for the orhun/alpkg project got merged into master, that's nice. Also my adoption for the community/freeglut package got accepted after a small correction (and I messed up the commit message).Next in line might be gedit, which does not have a maintainer and need an upgrade to version 46.1, but that might be a task for tomorrow.
Merged PR on orhun/alpkg
Merged MR on alpine/aports
Day 15
Took a day off. It's half way done, so time for some rest :)Day 16
Did some email work for the ongoing issues. Answer Elizabeth from cytopia, clarify some details on that partitionmanager issue, check the status on the Blender segfault issue and so on.One issue got my attention: putting user/group creation/deletion into the package definition itself and let apk manage /etc/passwd and /etc/group. This is an interesting topic, because it is tricky to solve it the simple way. Currently, packages which need a specific user, will creat it within a post install trigger script and execute adduser directly. Putting this into the package definition will make this part a lot cleaner, but apk would need to create the passwd/group files dynamically, keep an internal list of users and so on. Most other Systemd distributions uses userdb, which is a complex beast. What will Alpine Linux do? Implement something similar to userdb or find a better/cleaner/simpler way to solve that problem? I will definitively keep an eye on that issue.
Another IMHO important ticket got not that much attention (document package policies), so I added a comment on this. Generally the Developer Handbook for Alpine Linux looks empty and abandoned. This is also a thing I could improve.
Issue #10956: deferring chowns to unknown users until after triggers
Issue #3 (developer handbook): Document package policies
Empty Developer Handbook for Alpine Linux
Day 17
The ideal day to play around with the Antora site generator, which is the "base" of the generated documentation. I've installed antora, checked out the documentation playbook, forked the developer handbook and tried to generate the documentation locally on my machine. This worked surprisingly well with the "site-workspace.yml" playbook.Kevin Daudt kindly opened several issues with an outline for the developer documentation. I've started to create the structure and filling in the commitstyle. More on this tomorrow.
Documentation related issues
Day 18
Nothing special to show today. I continued working on the developer handbook, carving the navigation, filling in already present information, fixing typos, linking to relevant documents and such. This is a great task to get familiar with the internal structure of Alpine Linux, the used tools, workflows and naming conventions. I don't know most of that, so it's a task in itself to figure it out, collecting the information and verify it.Day 19
Still working on the outline for the developer handbook. I work my way through numerous README's, the Wiki, git repos and other documents, which all contains small bits of information useful for developer/maintainer/contributors. Most information are for endusers (especially in the Wiki) and it is not easy to distinguish between information need to operate Alpine Linux and information need to contribute to Alpine Linux itself. Because of that, I spend most of the time outlining the headlines and pages for the developer handbook.Along the way I find cool projects like Anitya for release monitoring, some internal development like the Alpine Configuration Framework, but also some hidden/unwritten information like how Alpine Linux deal with CVEs or what's the current status of apk Version 3.
Anitya release monitoring
Alpine Configuration Framework
Day 20
Time goes by really fast and December is the most stressful month in the year for me, so it is hard to carve some time for this project. But no complains, we are getting somewhere :) Today I've corrected an already opened merge request and open a new one with the outline for the developer handbook. I am curious what the Alpine Linux devs say.Merge Request: add protected paths feature
New Merge Request #1: outline navigation
Day 21
Nobody commented on my merge requests so far, so I think I just continue working on the documentation. Today, I collect more bits and bytes on various sources.Day 22
I like to work on the developer documentation, so I just continue on that. Today, I wrote a little about the Code of Conduct, the fundamental philosophy of Alpine Linux and tried to find out under what license Alpine Linux actually is. Surprise: This is still a point of discussion! It is not that easy to define, because such a big open source project consists of thousands od contributors and even more projects with different licenses.Licensing discussion
Day 23
Not much time today, but I took a couple of minutes to dig deeper into that licensing "issue". It seems that nobody wants to tackle that problem. To get a better understanding who is working actively on the development (so I can start a discussion on that licensing topic), I subscribed to the Alpine Linux development mailinglist.Alpine Linux Development mailinglist
The end?
The last 3 days where too chaotic to do some work here, but I will not drop my unfinished work. I leaned a lot about the internals of Alpine Linux, but I just scratched the surface. My December adventure will continue to go on for a couple of days. I will continue working a little on the developer documentation, get my open merge requests into master and continue to watch interesting issues and tasks. I also continue to follow the development mailing list.Here are my learnings from this adventure:
* Alpine Linux is still a new project compared to well established distributions like Debian or RedHat. It is refreshing that decisions do not take years. Natanael Copa -- the creator of Alpine Linux -- is still very active on the project and chances are good that your contributions will recognized and commented by him.
* Generally, contributions are welcome and the developers are kind and active. It's just so much fun to work with those talented people. The community is more diverse than in most other linux related projects. No grumpy old graybeards telling you how to behave and how the world works. I think the crystal clear code of conduct which all must agree on helps on this a lot.
* It was hard to find reliable information or any information at all for various topics. Things like the licensing or some guidelines for developers are just missing. The wiki is IMHO a very chaotic haystack of bits and bytes of information. Some parts are very well documented (like the Alpine Configuration Framework, which nobody is aware of), some parts are just non existent or inaccurate. I think this part of the project need a little more love in the future.
* As always, there is more work than the current staff/team/community can handle. There are unanswered issues which are years old, non existent documentation, outdated and abandoned packages, spam on the mailinglists, unanswered questions on IRC and UI/UX nightmares. I scratched just the surface of the issue tracker, read a little in the wiki, working a little on packages, read through some sourcecode of internal projects, tried to collect information, extend the documentation and interact with the community. I also joined the IRC channels, subscribed to mailinglists and read about some "meta" topics like licensing or security handling. So I think I have a rough understanding of Alpine Linux now. I saw the weaknesses, but also the strengths of Alpine Linux compared to flagships like Debian/Ubuntu or RedHat/Fedora. There are so much ways to contribute to the project. No need to be a kernel hacker. It is a huge project, small contributions might feel like nothing, but in the end, together, it makes a difference.