June 2018 - 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] Arch Linux Cloud Images (virtualbox and Qemu)
by Christian Rebischke 07 Nov '18

07 Nov '18

Hello everybody, Some months ago Bartlomiej had the awesome idea to generate qemu and virtualbox images as well. Afterwards we had a small discussion about this topic in #archlinux-projects. I would like to refresh this discussion and move it to this mail thread. So, our vagrant boxes are building automatically and without issues for a few months now. I could just generate virtualbox and qemu images as side products monthly, but I have no idea how we would release them. Another big topic is security. The vagrant images are at the moment not signed and seems like vagrantcloud doesn't support this either. This doesn't mean that we shouldn't sign our qemu or virtualbox images. We could just generate an automated cloud image signing key (only for this purpose) of course and automatically sign the images with that key. Problem with this is: If our build server ever get pwned the person will have these keys for signing cloud images as well. Any opinion about this? In my humble opinion I would be fine with a signing key that follows only this particular purpose. Another idea would be to move the whole production process to a physical server behind a firewall that is physical accessible by one or more Arch Linux Developers. I really would like to push this forward. Any comments? Chris

4 4

[arch-dev-public] Improving the package guidelines
by Morten Linderud 30 Aug '18

30 Aug '18

Yo! In April there was some discussion regarding how to properly do unit testing in Python PKGBUILDs[1]. Felix had some amazing notes that was super useful. But as pointed out we don't really strive to document these things[2]. To try help and spark some interest in improving the current package guidelines, I have spent a some time restructuring and rewriting parts of the Python and Golang package guidelines. I'd appreciate reviews on them! https://wiki.archlinux.org/index.php/User:Foxboron/Python_packaging_guideli… https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines It really doesn't take that much time to note down what you know about packaging and what the current standards are. I think this helps both fellow maintainers and AUR maintainers in writing better PKGBUILDs and sharing knowledge. If people think editing wikis are annoying, maybe we could setup a github repository with example PKGBUILDs we can work on? [1]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029228.html [2]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029233.html -- Morten Linderud PGP: 9C02FF419FECBE16

4 8

[arch-dev-public] Enforcing 2FA in GitHub organization
by Bartłomiej Piotrowski 09 Jul '18

09 Jul '18

Hi all, I want to enable mandatory two-factor authentication in our GitHub organization. Few of you unfortunately don't use it and will be effectively removed when I flip the switch, which I plan to do next week, 6th July. allanbrokeit anthraxx Atsutane Bluewind brain0 City-busz djgera eli-schwartz foutrelis lordheavy phrakture SantiagoTorres seblu shibumi vesath wonder Bartłomiej

3 3

[arch-dev-public] FrOSCon Arch Linux DevRoom
by Jelle van der Waa 07 Jul '18

07 Jul '18

Hi all, I've managed to get a room for Arch Linux on the Sunday of FrOSCon. FrOSCon is a conference ran for a weekend at 25th and 26th August in Bonn-Rhein-Sieg. It's a free event thanks to all the sponsors. We are free to plan our own program on Sunday, however it would be great if we could give some talks or a workshop. Since I'm not sure how much of the TU/Dev's can attend, community members are also welcome to mail me with an proposal for a talk! P.S. I'll hope to bring Arch stickers. -- Jelle van der Waa

3 4

[arch-dev-public] github ci migration from travis-ci.org to travis-ci.com
by Levente Polyak 29 Jun '18

29 Jun '18

Hi folks, As already announced in the devops IRC I started migrating out projects to travis-ci.com via support requests. For that to work both CI's need to be active for all projects that need a migration otherwise its stuck in nirvana (so please don't remove any). I have already successfully migrated arch-securoty-tracker to the new platform, Next will be archweb and others. Once a project is successfully migrated, the old travis-ci.org CI rights can be revoked. I remove them from the migrated projects as well. cheers, Levente

1 0

[arch-dev-public] Removing 'orphan' python2 modules
by Jelle van der Waa 29 Jun '18

29 Jun '18

Hi All, Our repository contains a lot of python2 modules which are required by any package in the repository. I'd like to propose to remove these modules pre-emptively since they serve no purpose and python2 is dead. We should strive to be a modern distro, so promoting Python3 should be a big part of it :) Please reply if you have objections. A list of modules / programs can be obtained as following or viewed here [1] $ pacman -Sqs python2 > list $ expac -S '%n %N' -l ' ' - < list | awk NF==1 [1] http://pkgbuild.com/~jelle/python2_modules.txt -- Jelle van der Waa

3 2

Re: [arch-dev-public] Removing 'orphan' python2 modules
by Antonio Rojas 27 Jun '18

27 Jun '18

> Please reply if you have objections. > A list of modules / programs can be obtained as following or viewed here That list doesn't take makedepends/optdepends into account. There are a few optdepends of sagemath there (pkgconfig, pynormaliz)

3 2

[arch-dev-public] Notice: sip 4.19.{9,10} removed from [testing]
by Antonio Rojas 24 Jun '18

24 Jun '18

Latest release has been withdrawn upstream due to multiple issues.

1 0

[arch-dev-public] [core] / [extra] cleanup
by Jelle van der Waa 23 Jun '18

23 Jun '18

Looking at the packages in the BUILDINFO rebuild list, I've found some packages which are so old that they might not longer suit [core] or our repos in general. So I'd like to propose that we either move or remove the following packages: *Remove* - pcmciautils - Ancient technology - speedtouch - If you are using a linux kernel >= 2.6.10 , you should use the kernel module instead. - bootchart - Replaced by systemd-bootchart - zd1211-firmware - really really old WiFi chip. Move to [extra] or remove - linux-atm - Not sure what this is, but looks old. *Move to [extra]* - ifenslave - Don't see why it is required in core, also orphan - libgssglue/librpcsecgss - move to extra, nothing in [core] deps on it. (archboot and nfs-utils used to dep on it) - b43-fwcutter - Is this still required for more recent broadcom cards? -- Jelle van der Waa

3 5