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

[arch-dev-public] Replacing qt5-webkit
by Antonio Rojas 14 Jun '17

14 Jun '17

Continuing with the trend of replacing insecure packages: qt5-webkit has been deprecated upstream for a long time already. It is still being community released, but it is on life support with only build fixes, and the webkit code itself hasn't been updated since 2013, so it's plagued with security issues by now. The "official" replacement qtwebengine has its own issues (eg. crashes on nouveau) and some projects are reluctant to move to it. In this case removing the package is out of the question, as some important packages (such as Plasma) depend on it. Fontunately someone took up the job of maintaining a fork [1] based on the latest webkit code. The aim is to have this shipped with upstream Qt eventually, but that could still be many months away. I've packaged this fork as qt5-webkit-ng. It should be a drop-in replacement for qt5-webkit, please test it and if it's good enough we can consider replacing the old qt5-webkit package with it. [1] https://github.com/annulen/webkit/wiki

1 2

[arch-dev-public] Moving dbus-c++ from [extra] to [community]
by Baptiste Jonglez 12 Jun '17

12 Jun '17

Hi, dbus-c++ [1] is orphaned, but needs some love to work with GCC 7. Currently, it does not build, and also prevents its reverse dependencies [2,3,4] from building. Apparently, Fedora has patches to fix this [5]. I would be happy to maintain dbus-c++, however it would first need to be moved to [community] (as well as libffado [2]). Is this ok? Baptiste [1] https://www.archlinux.org/packages/extra/x86_64/dbus-c++/ [2] https://www.archlinux.org/packages/extra/x86_64/libffado/ [3] https://www.archlinux.org/packages/community/x86_64/kimtoy/ [4] https://aur.archlinux.org/packages/ring-daemon/ [5] http://pkgs.fedoraproject.org/cgit/rpms/dbus-c++.git/log/?h=f26

2 3

[arch-dev-public] libalpm hook and wrapper for detecting broken perl modules
by Florian Pritz 11 Jun '17

11 Jun '17

Hi, TLDR: Skip to the ##TLDR marker below. We've just had another perl update and as always people with locally built perl modules ran into issues with random perl tools (including cpan) not working. I've looked into this back in 2014 already [1] and back then I chose to implement versioned dependencies to catch such issues. However I have not pushed for those dependencies to get adopted by AUR packages since doing so will force users to remove those packages prior to being able to update and the main goal was to detect incorrectly rebuilt packages in our repository (there were 3 from multiple maintainers IIRC). Naively I thought posting instructions to arch-dev-public on how to find broken modules would be sufficient. Turn out that not all users of the AUR read this list and some have unknowingly installed modules with cpan directly so even if they read the post, they wouldn't expect to have to run the check. ##TLDR Talking to some folks in #perl pointed me towards a hopefully satisfying solution. I plan to version the architecture specific directories and introduce a libalpm hook that checks for old directories and warns the user by printing a list of affected AUR/cpanplus-dist-arch packages, respectively a list of files for modules installed directly with cpan. The new directory layout would be "/usr/lib/perl5/$baseversion/{core,vendor,site}_perl" with $baseversion being "5.26" right now. Currently the layout is "/usr/lib/perl5/{core,vendor,site}_perl". The check for old versions would then be rather simple since it just has to look for directories beside the current version. During the old discussion, Justin raised the issue that if the directories are versioned, perl modules that are not rebuilt will just be missing. This could lead to software not detecting them any more and disabling a feature or using a slower module to do the job. One possibility to counter this would be to replace the perl executable with a wrapper that performs the check and prints errors to stderr. Optionally it could also exit with an error code rather than continuing to run the script. I'm not sure if I want this or not, but I'm leaning towards a yes since exiting will make the error more difficult to miss. If there are no objections I'll start working on this in the next couple of weeks. [1] https://lists.archlinux.org/pipermail/arch-dev-public/2014-June/026380.html Florian

2 2

[arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
by Baptiste Jonglez 11 Jun '17

11 Jun '17

Hi again, Since a few years, I maintain a variant of the linux kernel in the AUR [1] that adds support for Multipath TCP [2]. The most recent version is based on linux 4.4, and the package I maintain tries to follow the "linux" package from [core] as much as possible. There is no short- or medium-term perspective to merge Multipath TCP upstream, so I would like to bring this package to [community]. There are already several kernel variants in the official repos, but I would like to get some feedback before adding another one. Thanks, Baptiste [1] https://aur.archlinux.org/packages/linux-mptcp/ [2] http://www.multipath-tcp.org/

5 5

[arch-dev-public] wxgtk split
by Antonio Rojas 10 Jun '17

10 Jun '17

Hi, As you may have noticed, the wxgtk package is now a split package that build both gtk2 and gtk3 versions. The gtk2 package is a drop-in replacement for the old wxgtk package, so by default all packages will keep building against gtk2. If you maintain a wx-based package, you may want to try switching to build against wxgtk3, which offers some additional features (hipdi, smooth scrolling, touchscreen support). To allow coinstallability, the wx-config script has been renamed to wx- config-gtk3 in the GTK3 package, so in order to build against the gtk3 version the script name needs to be specified at build time (--with-wx- config=/usr/bin/wx-config-gtk3 for autotools, - DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-gtk3 for cmake)

1 1

[arch-dev-public] ArchLinux on Github
by NicoHood 06 Jun '17

06 Jun '17

Hi, we have an organization on Github: https://github.com/archlinux Would it be possible to add my account (NicoHood) also to this organization? This would help other users to identify that i am also an ArchLinux TU Member. Cheers, Nico

3 2

[arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 05-06-2017
by repomaint＠archlinux.org 05 Jun '17

05 Jun '17

Error : the abs tree /srv/abs/rsync/x86_64 does not exist

1 0

[arch-dev-public] Perl 5.26 in [testing]
by Florian Pritz 02 Jun '17

02 Jun '17

Hi, Perl 5.26, as any other new perl version, requires all modules that are not purely perl code to be rebuilt. We did that for all packages in our repos. For a list of upstream changes please refer to `man perldelta`[1]. [1] https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod Please note that the current directory (".") is no longer included by default at the end of the module search path (@INC). This may have widespread implications for the building, testing and installing of modules, and for the execution of scripts. See the section "Removal of the current directory (".") from @INC" in `man perldelta` for the full details. Since our users probably installed some from AUR or with CPANPLUS::Dist::Arch, I wrote a script[2] that generates a local rebuild list. To use it you will also need this[3]. Note that: - some modules simply don't support being loaded directly (Irssi, SVN::_Core, Tk::Entry among others) so also run the test (`perl -M$module -e1`) manually before reporting. - site_perl overrides vendor_perl so if you fix an error for a module in site_perl you have to run the script again afterwards. [2] https://git.server-speed.net/users/flo/bin/plain/find-broken-perl-packages.… [3] https://git.server-speed.net/users/flo/bin/plain/module-to-dist.pl Binaries linking with libperl.so will also need to be rebuilt. You can use lddd from devtools to find those. Please report any issue you encounter. Florian

1 0

[arch-dev-public] Arch Linux Container and Boxes
by Christian Rebischke 01 Jun '17

01 Jun '17

Hello everybody, I am pleased to announce that pierre and me founded the 'Archlinux' Organisation on hub.docker.com and pierre pushed his awesome docker container to this repository. (Big thanks to pierre!). [1][2] His docker container is a huge improvement to the other docker containers in the hub. Most of them are insecure, ship private keys within the container or ship more applications as needed. Moreover I can announce that I did the same for vagrant images and I would like to invite you for contribution. [3] There is a 'archlinux' organisation on atlas.hashicorp.com now that offers vagrant images for libvirt and virtualbox. My goal is at least support for vmare and maybe parallel or Amazon AMI, depends on if I can find somebody with these hypervisors for testing, because I can currently only test virtualbox and libvirt on my machine. [4] So my question to you is now: Can we make this project official? Or do we even want to make this official? I would like to start a discussion with this questions. In case of yes, I would like to have pierre and my project on projects.archlinux.org and would like to found the channel #archlinux-boxes on freenode. Best regards, Chris [1] https://hub.docker.com/r/archlinux/ [2] https://github.com/pierres/archlinux-docker [3] https://atlas.hashicorp.com/archlinux/boxes/archlinux [4] https://github.com/shibumi/arch-boxes

3 8

[arch-dev-public] Perl 5.26 rebuild in progress
by Evangelos Foutras 01 Jun '17

01 Jun '17

A quick heads-up: we are in the process of pushing rebuilds for Perl 5.26 to [staging]. Please avoid starting other rebuilds until this is completed, to avoid possible overlap with the Perl rebuild. Some build or test failures are expected due to Perl 5.26's removal of the current directory from the default include path. [1] These will be dealt with as they appear throughout rebuild process. There does not exist a ToDo for this rebuild, instead it's coordinated using https://rebuilds.foutrelis.com/ which also displays the rebuild progress and any build failures. Florian will follow up with more details before or when Perl 5.26 moves to [testing]. [1] http://search.cpan.org/~xsawyerx/perl-5.26.0/pod/perldelta.pod

1 0