April 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] 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

[arch-dev-public] dropping js38
by Eli Schwartz 24 Apr '18

24 Apr '18

The last package to depend on js38 was cjs, and with the completion of the cinnamon 3.8 rollout this too is ported to js52. There's no reason to continue to keep this in the repos AFAICT. ... On the topic of the various js* packages, we've had to rebuild some packages which used the /usr/bin/js tool when moving to js52. Having to patch the package to hardcode a specific version of js seems a bit awkward, perhaps we should move the js command from the js185 package (while we wait for *its* last user to be fixed) to a renamed js52 ==> js package, which would provide js52 for packages which link against a specific version instead of using the CLI? This would more closely match how we handle things like python, ruby, nodejs. -- Eli Schwartz -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Caution when moving packages built against glibc 2.27
by Evangelos Foutras 24 Apr '18

24 Apr '18

Care should be taken when building against glibc 2.27 (which is currently in [staging]). In particular: - While glibc 2.27 is in [staging], new rebuilds should not be started. - After glibc 2.27 migrates to [testing], packages built against it should remain in [testing] until glibc 2.27 lands in [core]. The above considerations must be taken into account because packages built against glibc 2.27 might depend on versioned symbols that are not found in glibc 2.26 and thus will not work. [1] [1] https://bugs.archlinux.org/task/58216

1 1

[arch-dev-public] Archweb (archlinux.org) upgrade
by Jelle van der Waa 20 Apr '18

20 Apr '18

Hi all, Tommorow evening we will be updating https://archlinux.org (archweb), so expect some downtime due to upgrading. Since it's a major version bump 1.8 => 1.11 some issues might occur, but in general it should be a smooth upgrade (tm). P.S. Next up is porting archweb to Python 3, any help is appreciated! -- Jelle van der Waa

3 4

[arch-dev-public] linux-manpages
by Andreas Radke 19 Apr '18

19 Apr '18

In the past we have packaged man9 section of kernel docs. Upstream removed the man pages section in 4.14 release. There are now different types of kernel docs available (make help output): Documentation targets: Linux kernel internal documentation in different formats from ReST: htmldocs - HTML latexdocs - LaTeX pdfdocs - PDF epubdocs - EPUB xmldocs - XML linkcheckdocs - check for broken external links (will connect to external hosts) refcheckdocs - check for references to non-existing files under Documentation cleandocs - clean all generated files make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2 valid values for SPHINXDIRS are: crypto networking input media core-api userspace-api process driver-api sh admin-guide doc-guide filesystems dev-tools kernel-hacking sound gpu make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build2 configuration. This is e.g. useful to build with nit-picking config. Default location for the generated documents is Documentation/output The recent docs are available online here: https://www.kernel.org/doc/html/latest/# Should we keep packaging this at all or drop it? Is there anybody who want to take this package over? I'm not interested in packaging this though maintenance work is low. -Andy

1 1

[arch-dev-public] Unit tests for python packages
by Baptiste Jonglez 18 Apr '18

18 Apr '18

Hi, Does anyone have experience with unit tests for python packages? It's really useful to spot missing runtime dependencies, but it's a pain to get to work. Here is what I saw: 1) just running "python -m unittest discover" or "nosetests" or equivalent in the check() function does not work, because the package is not yet installed (so all imports will fail) 2) setuptools is supposed to have a unittest integration such that "python setup.py test" should work out of the box, but in my case it never finds any tests to run 3) I've seen some more... "creative" solutions :) https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=pack… So far, the only working solution I found is playing with PYTHONPATH: cd "$srcdir/$pkgname-$pkgver/tests" export PYTHONPATH="$srcdir/$pkgname-$pkgver/src" python -m unittest discover But it's a hack, and it probably won't work with things like 2to3. Any better ideas? Baptiste

4 4

[arch-dev-public] glibc 2.27 based toolchain in [staging]
by Bartłomiej Piotrowski 17 Apr '18

17 Apr '18

Hi, I've had too much faith in GCC 8 release schedule. To sweeten the wait (and catch some possible issues sooner), I'm going to push glibc 2.27 and binutils 2.30 to [staging] in the evening. The new glibc doesn't ship libnss_nis{,plus} and RPC interface anymore. Packages that require the last should switch to libtirpc; libnsl shared library is still provided for backwards compatibility with old ABI, but dependent packages should be rebuild against standalone libnsl package (rebuild in archweb will follow soon). As some users may have used NIS in their nsswitch.conf file, news post wouldn't hurt. Here's a draft: Title: glibc 2.27-2 removes support for NIS and NIS+ The new version of glibc removes support for NIS and NIS+. The default `/etc/nsswitch.conf` file provided by `filesystem` package already reflects this change. Please make sure to merge pacnew file if it exists prior to upgrade. NIS functionality can still be enabled by installing `libnss_nis` package. There is no replacement for NIS+ in the official repositories.

1 1

[arch-dev-public] Deprecation of pam_unix2
by Bartłomiej Piotrowski 16 Apr '18

16 Apr '18

Hi team, During libnsl rebuild heftig pointed out that we are shipping pam_unix2 that has been dead upstream for a long time (to the point that it's being built from our own mirror now). I'm also unwilling to spend time to fix its configure.ac to make it build with libnsl and libtirpc correctly. Unless someone's life depends on it, I'd like to drop it from repositories. Bartłomiej

2 2

[arch-dev-public] Removing gksu
by Bartłomiej Piotrowski 16 Apr '18

16 Apr '18

What a day! gksu has been deprecated for years. Applications that require elevated privileges should use PolicyKit instead - and it seems that everything in our repositories do. I plan to remove gksu (and libgksu) from repositories this week. Bartłomiej

1 0