October 2017 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 06 Feb '19

06 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] New build server in Singapore
by Bartłomiej Piotrowski 04 Apr '18

04 Apr '18

Hi all, for those of you that are living closer to Asia than Europe, there is new build server available, located in Singapore. It is considerably less beefy than soyuz, but should be okay for regular builds. All packagers should be able to ssh into it with username and the key used on other servers. The address is sgp.pkgbuild.com. You can compare fingerprints below: SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519) SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA) SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA) It also hosts a mirror available at https://sgp.mirror.pkgbuild.com Enjoy, Bartłomiej

3 4

[arch-dev-public] Orphan mono packages
by Antonio Rojas 24 Oct '17

24 Oct '17

After Daniel's resignation, mono related packages became orphan. anthraxx and grazzolini adopted nuget and mono itself, but the following packages still don't have a maintainer: monodevelop xsd mod_mono mono-basic boo mono-debugger mono-upnp gtk-sharp-beans gettext-mono and others I may have missed. mono stuff breaks frequently (in fact most of these packages don't build currently) so they need a dedicated maintainer. Please adopt them if you're interested (or reply here so they're moved to community if you're a TU), otherwise I'll drop them in a few days.

2 2

[arch-dev-public] Away 31.10 - 5.11
by Bartłomiej Piotrowski 22 Oct '17

22 Oct '17

Hi all, as I'll be traveling in the beginning of November, you will have to bear building for i686 one week more. I'll prepare news draft before I'm gone and changes to devtools are ready, so it won't take long after my return. Bartłomiej

1 0

[arch-dev-public] Stepping back as Arch Linux developer
by Daniel Isenmann 17 Oct '17

17 Oct '17

Hi there, that wasn't an easy decision, but after months of inactivity and only sporadic checks of the mailing lists and emails, I have decided to step back. My interests moved and my free time is limited and Arch Linux deserves more time than I can actually offer. It was a fantastic and excited journey over all these years. It was great to be part of this community. I have met interesting people along the way, had interesting discussions and learned a lot. I wish Arch Linux and each of you all the best. Nevertheless I will be around as a user. Keep Arch Linux rolling.... Cheers Daniel

5 4

[arch-dev-public] systemd, kernel keyring and pam_keyinit
by Christian Hesse 06 Oct '17

06 Oct '17

Hello everybody, systemd v233 introduced code that makes use of the kernel keyring, initializing a private keyring for every service and adding a protected key named "invocation_id". This caused some trouble and we reverted it since then. Things will change with systemd v235, which adds a new option "KeyringMode=" for units. The values are "inherit", "private" and "shared". The commit [0] message and changes give the details. Now cryptsetup units are generated with "KeyringMode=shared", which unbreaks this use case. Other services that use the kernel keyring and want to share secrets with other services have to add this as well. However login sessions where user context is changed can not be handled by systemd. Looks like we have to update our PAM configurations and add a line for every service where session is expected to use the kernel keyring: session optional pam_keyinit.so force revoke This is required for eCryptfs to function properly. Any comments on this? Any concerns? I would like to keep the upstream keyring behavior with release version 235. Would be nice to have this sorted before. [0] https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3f… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2