I maintain / administer the ungoogled-chromium project and its Arch
Last year I asked about the submission rules for an
ungoogled-chromium-bin package as previous packages have all been
removed. Since then our GitHub Actions workflow for releases has been
adjusted to hopefully comply with the requirements.
At the moment updates will be handled manually by me but the code for
automating this already exists.
Now it has come to my attention that the ungoogled-chromium-bin package
is blacklisted due contentious violations by people not affiliated with
the project itself. Would it be possible to remove this blacklist entry
to be able to submit our binaries? I imagine that providing an official
package will also stop people submitting packages with workaround names.
1: The previous conversation regarding this topic
2: The commit updated our release workflow
My name is Campbell Jones, my online handle is serebit, and this is my application to become a
Trusted User. I've been graciously sponsored by Jonas Witschel (diabonas) and Leonidas
Spyropoulos (artafinde). I'm 22 years old, I live in Maryland (though I'm in Ireland for a couple
more weeks), and I've been developing software to some degree for about a decade now. My hobbies
involve software development, playing video games (some favorites being Titanfall 2 and ULTRAKILL),
critiquing my friends' art and animation pieces, building computers, learning about space, and
hugging my dogs. My favorite movies are Into the Spider-Verse and Interstellar.
=============== HISTORY ===============
Feel free to skip reading this if it gets boring!
My exploits with programming started with programs on my TI-84 calculator to aid me in
math class, and have culminated in closing in on a Bachelor's degree in Computer Science, which I'll
have by the end of this year. I've also landed a post-grad position as a software engineer working
on non-classified software used by the Navy and Coast Guard, which will primarily involve working
with RHEL and aiding with improvements to build systems and version control. I'm the sole developer
of Wraith Master, an open-source application to configure the RGB LEDs on the Wraith Prism CPU
cooler, and one of the core developers of the Budgie desktop environment.
My first experience with Unix was with my family's iMac, which I used to begin my programming
journey with software like QB64, then Python, Processing, and Java. In early 2017, after building a
computer of my own, I elected to dual boot Windows 10 and Ubuntu, so I could continue to use a
Unix-like environment for the purposes of developing software. However, dissatisfaction with the
Unity desktop led me to install Mint instead at the suggestion of others, followed by Solus. I ended
up liking Solus enough to stick with it for the next four years and change.
Soon after installing Solus, I began to investigate its processes for package submission and
updating, and I decided to participate. I started with submitting packages for inclusion, then began
to build packages myself, and eventually took up volunteer maintainership of packages. By the time I
left Solus, I was maintaining the entire JVM stack, including handling the large-scale migration
from JDK 8 to JDK 11 and patching software to facilitate that migration; in one excruciating case, I
spent two full days patching modelio to build on JDK 11. I had also taken up maintainership of the
Intel GPU compute stack, aka "neo", and several other miscellaneous packages like Kitty, libwacom,
and shotcut. Occasionally, I would find reason to submit patches for packages to the upstream
projects as well.
In any case, I left Solus in January 2022, along with Joshua Strobl, one of the prior "core team"
members. I would rather not air dirty laundry in a publicly available thread, so I won't go into
details here, but it ultimately came down to a split between the "core team" members over serious
issues with development and conduct that had been festering for some time. With the departure of
Josh came the departure of Budgie, which became a standalone project backed by prior contributors,
including myself. I had previously swapped out the system tray backend in Budgie for my own
implementation of the XEMBED spec, which resolved numerous longstanding issues with the tray applet,
and I wanted to continue moving Budgie forward now that it had been freed from the shackles of
Upon leaving Solus, I decided to find a new distribution that could replace it on my personal
machines. It had to satisfy the criteria of being rolling release, having up-to-date software in its
repositories, having a fast package manager, and having Budgie as an option in its installer - so I
elected to install EndeavourOS as a way of getting a somewhat curated experience on Arch. I had
already been maintaining a couple AUR packages for Wraith Master for some time, so I had some
experience with the PKGBUILD format already, and I decided to take up maintainership of Budgie's
various AUR packages (mostly -git variants of existing packages) in order to update them to the new
repository that had been set up under Buddies of Budgie.
=============== END HISTORY ===============
Ultimately, my motivation with applying to be a Trusted User is an extension of my prior motivation
to aid with Solus packaging, and my motivation to maintain Budgie's AUR packages. Arch doesn't have
a dedicated maintainer for Budgie's community packages, and I believe I would be an ideal candidate
to fill that role. Though I haven't been on Arch for long, I have been maintaining packages for
years, and I'm more than willing to learn and abide by the standards that Arch has set for its
community and repositories.
To address the minimum requirements:
- I'm well acquainted with bash, sh, and csh (the latter not by choice...)
- I maintain a few packages in the AUR with what I believe to be clean and quality PKGBUILDs
- I've recently joined the Arch Matrix channel and plan to stay
- I like to think my Google-Fu is well-trained! It had to be after the years I've spent being the
dedicated technical support person for my family and friends...
- I know exactly what packages I want to maintain as a start - the Budgie stack!
As for the extra requirements:
- I've reported some issues with Budgie packages on the bug tracker, so a little bit of involvement
- I have not submitted patches for Arch projects
- I've been contributing to and maintaining open-source projects for years
My first order of business after becoming a Trusted User would be to clean up the PKGBUILDs for the
following Budgie packages:
Second order of business would be to move the AUR package "budgie-control-center" into the community
repository, as it is a necessary component of the Budgie stack and has additionally reached the
minimum requirements for inclusion. Finally, I would begin discussions of how the "budgie-extras"
package could be modified or split, with cooperation from upstream if necessary. I'd also like to
push for SPDX license ID support in the PKGBUILD format after having discussed it with Jonas.
Thank you for reading this massive email, and I look forward to receiving your feedback!
=============== LINKS ===============
I'm currently trying to adapt my AUR packages to the new PEP 517 based
build workflow . Some users of the telegram-tg  package reported
after I changed it to PEP 517, that they are missing the actual python
files in the final package. I investigated a bit further and found out
if I build with makechrootpkg (like I usually do) the files are inside
the package (that's why I didn't notice), but if I use yay for example
(which uses makepkg without a clean chroot), the package does not
contain the files. Now I'm a bit confused and don't know how to debug
this further, could somebody please help me or at least give me a hint?
Thanks in advance