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

[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

[arch-dev-public] Boost looking for new maintainer
by Bartłomiej Piotrowski 16 Apr '18

16 Apr '18

Hi team, As I'm absolutely the worst with C++, none of my packages depend on boost and I've spent enough nights terrified of its build system quirks, I'll be orphaning it soon. Feel free to adopt it in archweb. Bartłomiej

4 4

[arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
by Antonio Rojas 12 Apr '18

12 Apr '18

Hi, Currently most of our packages which use the cmake build system are built with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to upstream) set of C(XX)FLAGS defaults which are appended to and override our default C(XX)FLAGS. So, for instance, our cmake packages are being built with -O3 instead of our default -O2. Besides the inconsistency that this brings to our binaries, IMO it's not a good idea to override our default C(XX)FLAGS unless there's a good reason to. This will also cause issues once we start building debug packages by default (-DCMAKE_BUILD_TYPE=Release also adds DNDEBUG). Therefore I'm proposing to drop -DCMAKE_BUILD_TYPE from all our cmake packages, building them with our default C(XX)FLAGS as all other packages. Comments?

8 19

[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] Offline for the next week or so
by Eli Schwartz 30 Mar '18

30 Mar '18

It's the Passover holiday season again... I'll be a combination of offline and difficult to reach for the next week, week and a half. -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] freecad maintainer wanted
by Florian Pritz 22 Mar '18

22 Mar '18

Hi, Since I no longer use freecad myself I am not very interested in continuing to maintain it. If nobody steps up, I will move it to AUR in about a week. Some notes: - The current release is over a year old, a new one should come soonish. - There is an open bug[1] that leads me to believe that freecad might use a bundeled version of coin3d which contains a bundeled version of expat that is very old and may also contain security vulnerabilities. - I haven't yet managed to build freecad from git master with qt5 support. Looks like it needs pyside2 for this, but that doesn't have a stable release and we don't pacakge random commits from a git branch. - freecad 0.16 (current version) blocks opencascade from being updated to >= 7.0. 0.17 should be compatible at least with 7.0, possibly with 7.1. [1] https://bugs.archlinux.org/task/57843 Florian

1 1

[arch-dev-public] LLVM 6.0 rebuild
by Anatol Pomozov 16 Mar '18

16 Mar '18

On Fri, Mar 16, 2018 at 6:20 AM, Arch Website Notification <nobody(a)archlinux.org> wrote: > The todo list "LLVM 6.0" has had the following packages added to it for which you are a maintainer: > > > * community/crystal (x86_64) - https://www.archlinux.org/packages/community/x86_64/crystal/ > > Todo list information: > Name: LLVM 6.0 > URL: https://www.archlinux.org/todo/llvm-60/ > Creator: Evangelos Foutras > Description: > libLLVM-5.0.so -> libLLVM-6.0.so > libclang.so.5 -> libclang.so.6 > > In addition to the above soname changes, our clang package no longer ships > static libraries. Instead, those are built as individual shared libraries > (using CMake's BUILD_SHARED_LIBS flag). > > ** I'll add LLVM 5 packages once it's clear they are needed for software that > hasn't been ported to LLVM 6 yet. Feel free to ping me on IRC for this. ** Hello Evangelos I tried to rebuilt Crystal package with LLVM and hit a compilation issue ./bin/crystal build --release --no-debug -D i_know_what_im_doing -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib _main.o: In function `*Crystal::Compiler#pass_manager_builder:LLVM::PassManagerBuilder': main_module:(.text+0x52dc08): undefined reference to `LLVMInitializeInstCombine' collect2: error: ld returned 1 exit status That described here https://github.com/crystal-lang/crystal/issues/5556 and it turns out to be a LLVM bug https://bugs.llvm.org/show_bug.cgi?id=35947. This LLVM bug is fixed in HEAD (https://reviews.llvm.org/D44140) and should be released in 6.0.1. Or maybe we can pull it to the Arch package?

2 1