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

Re: [arch-dev-public] Changing compilation flags
by Evangelos Foutras 07 Jul '17

07 Jul '17

On 7 July 2017 at 16:39, Jordan Glover <Golden_Miller83(a)protonmail.ch> wrote: > FYI clang devs don't want to take 1 line patch adding another no-op flag > upstream. > https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html Thanks for trying to push the change upstream. I'm sorry they weren't very receptive of it; your responses were on point and further clarified our intended use case. I'm not sure what Joerg meant by saying "Arch Linux can't do compiler-specific flag definitions". He could be thinking of a regular project that can check for supported compiler flags, but AFAIK that concept is not readily transferable to distro-wide flags. (Even if it was, it would also apply to stack-check and friends so it's a weak argument in my opinion.) At the end of the day, it's not an issue to carry this patch downstream in Arch. :-)

1 0

[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] switching to systemd-stable
by Dave Reisner 06 Jul '17

06 Jul '17

Hey all, This should be pretty much a no-brainer, but wanted to be sure I wasn't missing anything. Systemd upstream publishes a "systemd-stable" repo [1] which branches at each tag and cherry-picks backports. I'd like to switch our systemd package to this repo to avoid some of the duplication of work that Jan, Christian and myself have done in the past. The repo sees a bunch more activity than what our own backporting strategy has been, and I see that as a positive. One potentially bikeshed-worthy question is versioning. Do we count commits and modify the pkgver every time we build from the repo, e.g. 233.23-1 (meaning pkgrel=1 of a v233 build containing 23 backports), or do we simply keep the base pkgver true to upstream and increment pkgrel every time we release, e.g. 233-5 (meaning pkgrel=5 of some build of the v233 stable branch). Regards, Dave [1] https://github.com/systemd/systemd-stable

8 11

[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] orion/rsync.archlinux.org maintenance
by Florian Pritz 04 Jul '17

04 Jul '17

Hi, Due to a bad disk orion is currently offline as the RAID is rebuilding. This will take several more hours to complete. Services affected by this include: - rsync.archlinux.org - sources.archlinux.org - svn - dbscripts Florian

2 1

Re: [arch-dev-public] [arch-general] Sébastien Luttringer and Tobias Powalowski
by Bartłomiej Piotrowski 03 Jul '17

03 Jul '17

In case you haven't noticed, despite being told this many times, every time you can't resist being an alerted meerkat about checksums, you make people care less about whatever you have to say. We DO have EVEN MORE SERIOUS issues, not only about SECURITY, that we are not doing because we are wasting time responding to you or fnodeuser. I really feel inclined to moderate your messages as well. Want to do something useful? Start from fixing remaining community and multilib packages from the todo[1] we created because of you. But don't be surprised if maintainers will revert your changes or CRC in general. Sometimes I wonder if you aren't making all of this noise on purpose so we stop caring about it completely. [1] https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/

1 1

[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