May 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] Archive cleanup (2013, 2014, 2015)
by Florian Pritz 14 Jun '18

14 Jun '18

Hi, So far we haven't ever cleaned up the archive (https://archive.archlinux.org/), but it's getting too big and I don't think we have any use for packages from years ago. Next week I will remove the years 2013, 2014 and 2015. Florian

3 10

[arch-dev-public] Moving gcc7 into [community] for CUDA
by Sven-Hendrik Haase 29 May '18

29 May '18

Hey, I would like to move gcc7 (based on the latest version 7 commit of gcc [0]) into [community] because of cuda 9.2 and in return drop gcc54. I tried to make it work with current gcc but to no avail. In earlier releases of cuda the incompatibilities could be patched with header hacks but not this time. I tested the whole setup with cuda 9.2 locally and it seems to work fine. I just want to get somebody's ok on this as apparently not everyone is stoked about having yet another old version of gcc in there for some time. Sven [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gcc…

4 6

[arch-dev-public] Replacing pkg-config with pkgconf
by Jan Alexander Steffens 24 May '18

24 May '18

I want to replace pkg-config with pkgconf, an implementation that's actively maintained. https://github.com/pkgconf/pkgconf/ pkgconf is reportedly both faster and has saner behavior. For example, right now `pkg-config --exists OpenEXR` fails if glu is not installed, since OpenEXR has a "private" dependency on glu. However, `pkg-config --libs OpenEXR` works since pkg-config ignores private dependencies here. Private dependencies are relevant for static linking, analogous to a shared library's DT_NEEDED tags. `pkg-config --static --libs OpenEXR` lists the libraries necessary to statically link OpenEXR. pkgconf is more consistent and follows private dependencies only if --static is given, regardless of whether --libs or --exists is used. pkgconf is in use by at least FreeBSD, NetBSD, Fedora and Mageia; so we wouldn't be the first ones making the switch. There's already a package in [community] owned by demize. I would make some adjustments before releasing it to [testing]. Any objections?

2 1

[arch-dev-public] HEADS UP: Qt 5.11 in [testing]
by Antonio Rojas 22 May '18

22 May '18

As usual, due to Qt's ABI versioning, everything compiled against Qt 5.11 will get a runtime dependency on it, so it will have to stay in testing until Qt itself moves. Keep it in mind if you plan to build Qt stuff against testing or staging. Other changes of interest for packagers: - qdoc now relies on the clang code parser to generate docs. Since qt5-tools contains many other unrelated stuff I've only made it an optdepend. If your package uses qdoc to generate docs you'll need to explicitely add clang as a makedepend. - there's been a huge header cleanup in Qt modules. Expect build failures for applications that rely on transitive includes instead of declaring all required headers. Those need to be fixed upstream by explicitely adding the missing includes.

1 0

[arch-dev-public] New build server in the US?
by Baptiste Jonglez 19 May '18

19 May '18

Hi, OSUOSL [1] in the US has several "new" refurb servers with dual Xeon E5-2660. Each machine has a total of 16 cores / 32 threads and 140 GB RAM, so that would make nice build machines. Would this be useful to the dev community? Soyuz is a bit overloaded at times, and people in the US/Canada might appreciate the lower latency. The hosting conditions are described here: http://osuosl.org/services/hosting/ Regarding money, OSUOSL works through donation: if we ask for a server and we have money, it would be nice to support them financially. I honestly have no idea about Arch's financial situation, or how soyuz is paid for in practice. Let's discuss this! Baptiste [1] http://osuosl.org

5 5