June 2017 - 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] TeXLive 2017 packages are now available in [testing]
by Rémy Oudompheng 17 Jul '17

17 Jul '17

Hello, TexLive 2017 has been released at the beginning of the month and is now packaged in [testing]. No particular issue is expected when upgrading to this release. Note that a few packages disappear in this release, following upstream changes in structure: * texlive-genericextra (merged in texlive-core) * texlive-htmlxml (merged in texlive-core and formatsextra) * texlive-plainextra (merged in texlive-core) Pacman hooks for TeXLive, which were in texlive-bin, are now in texlive-core, which should fix bugs like FS50238, FS20423 and FS51918. I expect to move them to [extra] early July. Happy TeXing, Regards, Rémy.

2 3

[arch-dev-public] Outdated orphans
by Antonio Rojas 06 Jul '17

06 Jul '17

The following packages are orphan and outdated, some of them for months or even years, and some have been broken for a while (FS#54615). If you're interested, please adopt them and fix them, otherwise they should be removed so they can be properly maintained in AUR - xen (xenstore, xe-guest-utilities, python2-xenstore) - openvas (-cli,-libraries,-manager,greenbone) - ironpython - gdc (we already ship 2 other D compilers also unmaintained, do we need 3? - taskjuggler3 - xbase - xmind - ypbind,ypserv,yp-tools (dep of archboot, is it useful?)

2 2

[arch-dev-public] Changing compilation flags
by Allan McRae 05 Jul '17

05 Jul '17

Hi all, The results from the test-sec-flags [1] suite are in. Many thanks to those that wrote this and those that submitted results. I'm not going to list the summaries here, but the results show that at worst enabling a bunch of security flags in our packages will have a <1% impact on performance (and more likely a fraction of a percent). That means we will add all of these to our default CFLAGS/LDFLAGS etc. The changes are: 1) building gcc to enable PIE by default 2) add -z,now to LDFLAGS 3) and -fno-plt and -fstack-check to our CFLAGS Adding PIE means that programs get loaded at a random address, preventing an attacker from manipulating global data or hijacking control by reusing code. Without this, ASLR is ineffective. Enabling this by default in our compiler (there is a configure flag) means we will need to rebuild all packages with static libraries (which should be a fairly limited set). Adding -z,now to LDFLAGS disables lazy loading. This means all function symbols are loaded at startup (with minor performance hit), but that means our RELRO support will make everything ro instead of some of the things. Doing this enables us to use -fno-plt in our CFLAGS, which is a run-time optimisation allowing faster use of libraries. Adding -fstack-check to our CFLAGS guarantees stack overflows aren't exploitable. Note that any of these flags can be disabled in a PKGBUILD if really needed... But if that is the case, bug reports should be filed. Given an assumed lack of objection, I will enable the build flags in our pacman.conf and rebuild gcc to enable pie and put them in [staging] at the end of this week (what better way to celebrate Halloween). We will need a new devtools release then too. Then the packages with static libraries will need rebuilt. After that, I would like to see [core] completely rebuilt, and audited to ensure our CFLAGS/LDFLAGS are actually being used in the build. Cheers, Allan [1] https://www.archlinux.org/news/test-sec-flags-call-for-assistance/

6 26

[arch-dev-public] Drop sqlite2 and webkitgtk{,2}
by Balló György 25 Jun '17

25 Jun '17

Hi all, I think we can drop sqlite2 and webkitgtk{,2} from the official repositories now. sqlite2 was replaced by sqlite 3. The last application which still use it is Freevo, which was last released in 2009, and is currently unmaintained. webkitgtk{,2} has many CVEs[1][2], and was replaced by webkit2gtk. The last application which still use it is GNUCash, which is still maintained by upstream, but unlikely to get ported to gtk3 soon, porting is not started yet.[3] Packages to be removed: - freevo - gambas3-gb-db-sqlite2 - gnucash - goffice0.8 - kaa-imlib2 - python2-beautifulsoup3 - python2-pysqlite-legacy - sqlite2 - webkitgtk - webkitgtk2 Packages that need to be rebuilt: - gambas3 - libdbi-drivers - python-lxml - wxgtk (already in testing) - wxpython (already in community-testing) Is there any objections? [1] https://security.archlinux.org/AVG-171 [2] https://security.archlinux.org/AVG-234 [3] https://bugzilla.gnome.org/show_bug.cgi?id=751635 -- György Balló Trusted User

2 1

[arch-dev-public] Maintenance window for luna
by Bartłomiej Piotrowski 17 Jun '17

17 Jun '17

Hi all, tomorrow around 22:00 CET, the server that hosts forums, wiki and AUR will be offline for planned maintenance. The downtime will take up to 2 hours; the plan is to reboot it into linux-hardened, then see if it is possible to switch from Percona to MariaDB (and if the mysterious crash from the past still happens, gather debug data for reporting it upstream). Sorry for the inconvenience, Bartłomiej

1 1

[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