June 2016 - Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] signoffs are dead
by Kyle Terrien 26 Jul '16

26 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am replying to arch-general because arch-dev-public is closed to most users. On Tue, 28 Jun 2016 08:09:41 -1000 Gaetan Bisson <bisson(a)archlinux.org> wrote: > Dear all, > > For a while now packages in [testing] have gotten little to no > signoffs and I've been moving mine to [core] after a week without > feedback. I suspect many of you have been doing this too. Here's the > signoff reports over the last ten days: > > - June 19: 0 signoffs > - June 20: 6 from me, 4 from anthraxx > - June 21: 0 > - June 22: 5 from me > - June 23: 2 from demize > - June 24: 1 from me > - June 25: 0 > - June 26: 1 from me > - June 27: 3 from me, 1 from eworm > - June 28: 3 from heftig, 2 from arojas > > So I've decided to shorten the wait in [testing] to 48 hours. Many > updates to [core] packages include security fixes and they have better > move sooner rather than later. We used to be able to gather enough > signoffs to move these within a day or two, and that's what I intend > to do with or without signoffs. > > Any comment, and especially any other idea to fix this situation, is > welcome. > > Cheers. First, I am an Arch user (for 3 years now) not an Arch dev, and I realize I have no right to tell anyone how to run the distribution. What follows is just my personal recommendation based on working software QA professionally. With that said, I think eliminating signoffs is a bad idea. Signoffs ensure some form of quality control. A signoff is an explicit approval from someone that the package is satisfactory to his/her standards. A potential signee has a completely different perspective than the packager and a different way of verifying that the packager's package is correct. This sort of approval process catches errors that would otherwise escape the packager's notice. Simply waiting a period of time without hearing complaints is not equivalent to explicit approval from others. I have personally experienced several breakages in the past several months--more than usual. A few were big enough that simply running 'foo - --version' should have revealed a problem (i.e. linking problems). A signoff process would have very likely caught these problems. IMHO, the correct thing to do is remind other developers of the signoff policy. (And the above post to arch-dev-general certainly does just that.) Encouraging another set of eyes to look at someone's work and say, "This looks good to me," is a very good thing and does wonders in terms of quality control. If getting security fixes pushed out is a concern, then getting the security related fixes signed off should be prioritized. (Maybe by putting in a flag that automatically triggers a mail to arch-dev-public) Respectfully yours, - --Kyle Terrien -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXczI6AAoJEN5rMzXPJBsQASIP+gLGiQbQVrg/mNVDacXaHuEK 8H3QQz9amQMwgQXq8Mh17HWfbiQMQMWD48O9CBP+fUyWLVPOxs6g4H/aXFiIm4G+ Qw6/vWfgQaGjY60nLJ7D8/NVq9PwXSPEYF1cA8/6D7JtuotwXxCFENiNR9Qki7Un 3QCXRI6Z/KKGcpBvpIsa++qDeZuXnSTy00ZJO5EFYxTi+AUBEyffHX/bS2IUCOkC tUWxtoVIix4buD32/tCnPz19wku9MylddYBzNuB1qCD1NG6XLsxmn8WiHGeoiy+E uFwjxPgDx0MaldNNJzubC2LQD/osdTDTTPwDf2M0c802FI+pHxlj/Dk9imz86NFA 9xPH8WJ1cfiVTue0BkRJXlR2eI0VIPSqAbpcDCfzCwYbrFuFoqwszpET03PtF/Y4 5tfZHLODiFpDc9Whu5o4ejzf4p/eMUN3xmwUp+8cguFcSmjBSPvYvRbgI8puiPRm Al5xYxnrmghEf9R5fIRUWoHlsGNNMrmd1MKquJ6i1+Dkf0pmUK4t58G3crWjFb7+ laMUKYRmH+LwYhxvET562E8EM8QYYtow+PietZssC7ZhjGa1sG70FahQWCijmIj6 TdpfCiNgmQ8AF4C4JXhzZvONtdYzUeNSgiv/FkA9T4n9Xje/ZCUhyM+inaqmA/5A ComaWc2SjeM8gTBfdPQa =E42/ -----END PGP SIGNATURE-----

6 5

[arch-general] New TeXLive 2016 packages in [testing]
by Rémy Oudompheng 24 Jul '16

24 Jul '16

Hello, I have published new TeXLive packages for the 2016 release in [testing]. The structure of the packages has been left unchanged (e.g. no introduction of pacman hooks). Feel free to test them and notify me of any problem or weirdness. Cheers, Rémy.

1 1

[arch-general] ML is being sent to Spam by Gmail
by Eli Schwartz 04 Jul '16

04 Jul '16

Recently a (disproportionately) large number of emails from the various Arch Linux mailing lists are getting rerouted to my Spam folder in Gmail. It seems to have started roughly around the time of this change: [arch-devops] Finally fixed DKIM (I hope)[1] dkim header remarks indicate either failed or missing dkim sigs for those messages. Is anyone else seeing this behavior change? @Florian Pritz, whatever you did doesn't seem to be working, in fact it is worse. :( [1] https://lists.archlinux.org/pipermail/arch-devops/2016-May/000066.html -- Eli Schwartz

12 18

[arch-general] PyPI2PKGBUILD: Automated PKGBUILD creation for PyPI packages
by Antony Lee 30 Jun '16

30 Jun '16

I'd like to present PyPI2PKGBUILD (https://github.com/anntzer/pypi2pkgbuild), a new tool for automated PKGBUILD creation for PyPI packages. It is similar in spirit to the venerable pip2arch ( https://github.com/bluepeppers/pip2arch), but with a few improvements: - Python dependencies are found by installation in a temporary virtualenv (as far as I know, this is the simplest way to handle environment markers correctly (https://www.python.org/dev/peps/pep-0496/)); moreover, PyPI2PKGBUILD calls itself recursively for dependencies that are not available as official packages (i.e., you can call `pypi2pkgbuild.py $pkgname` and get all the necessary packages created and built for you). Many packages do not correctly declare `cython` and `numpy` as dependencies so special handling is provided for them. - Non-python (binary) dependencies that are dynamically linked are resolved via `namcap` and `pkgfile`, and added to the `depends` array. Say, for example, that you want to create a package for `pyfftw`, which needs to link against `fftw`, which is provided by the official `fftw` package. You can run `pacman -S --asdeps fftw`, then run `pypi2pkgbuild.py pyfftw`; the PKGBUILD will correctly declare `fftw` as `depends`. - Missing license files are retrieved from Github/Bitbucket if possible. The general intent is to 1) allow one to install packages that are not available on the Arch (official or AUR) repos (I don't think the proliferation of "trivial" PKGUBILDs that simply do `python setup.py build` / `python setup.py install --root="$pkgdir"` on the AUR is a particularly good thing) and 2) allow one to update packages for which a new version is present on PyPI but not on the arch repos yet (by default, the packages are built with a pkgrel of 00, so that they'd be upgraded to official/AUR packages when those become available). Antony PS: Original announcement on the forum at https://bbs.archlinux.org/viewtopic.php?id=213740.

1 0

Re: [arch-general] [arch-dev-public] signoffs are dead
by Jens Adam 30 Jun '16

30 Jun '16

Wed, 29 Jun 2016 21:51:17 +0200 Florian Pritz via arch-dev-public <arch-dev-public(a)archlinux.org>: > Maybe we should look into finding some people that want to help test > stuff and give them permissions to sign off on packages? +1 Sign me up, running [testing] for a decade now anyway, on x86_64 and i686. --byte

1 0

Re: [arch-general] [arch-dev-public] signoffs are dead
by Kyle Terrien 30 Jun '16

30 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 29 Jun 2016 21:51:17 +0200 Florian Pritz via arch-dev-public <arch-dev-public(a)archlinux.org> wrote: > As pointed out on arch-general (not by me) this makes the whole > signoff process useless. Maybe we should look into finding some > people that want to help test stuff and give them permissions to sign > off on packages? > > Florian Yes, this sounds like a very good idea. Until now, I have had no reason to run a container/VM with the testing repos enabled. However, if signoffs are opened up to a wider community, I think I might just try it out. It is great to catch problems before they are pushed to production. - --Kyle -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXdK22AAoJEN5rMzXPJBsQVcIQAI0LrK2wMCGGabqCidDlJ9wC 0M7RD8KQOEe+OtGzZYBr0qRTzsaM5tV/7GVlq/OgX6Wi2l26jsgightfUwj2STHj c2fjJg+VyHZd20YdHCP2Zfvqqq//3TyesCgc/9wvltqE+tB0WPr97K6GS5adIKV4 wGFqDEsf8KXLhPJFE8cHD7gx+RnBLg392NLOpBWwlQJB61hV6cv5IMgjC06ZeQdM UQ3GeUx4gQ3eUByHUFQDsaocFEef3lSqlySw0fM68ZPOlnBeF00tJhWYGBVy6spS 5KTeCVpGW86Zkb0jrxEuEgBYZj8AtMOYSHijCioZRkhKSkUs0rwcfeyf7+dsJgle 4tDZK57nJZZNFmX8+mPBPOyWXr3VCfGQx/ob60vb6Ky2uL+nFhBbs1qgokrvYWMw nIMl7GH1UTo+kgzuMM17I9gUCmg+L4slclCv/6cRzUCVe8tw4t2imZPiUFC6nyPA Xjejd92zNcQApd/tVUap8UDVwJTS1wcGCjKKC+3RX9IH/GdmPOdphDvzCXmmnJHM 0dOM+60+NrUOeda1A3sE2lRyrdhUxVOpfoy4c3FCJIQWiD6ezeMIzAqB3iwISw/B CNy6QH4aEBxhyckFQJk7jZ9P0g8PltZ+nUrrNX+iWNkLpFOXhpn38fy7M66b/aca 08Dz3JiOtzK1A2y1Afi7 =r3gL -----END PGP SIGNATURE-----

1 0

[arch-general] KDE apps using incorrect colors after recent upgrade
by David Rosenstrauch 28 Jun '16

28 Jun '16

I haven't yet been able to pin down the root cause, but some recent upgrade (my best guess is qt5) seems to be messing with my KDE apps' ability to pick up the correct color scheme. If you look at the screenshot at http://darose.net/Screenshot_2016-06-27_12-13-53.png you can see that I have KDE's color scheme set to a custom, dark scheme. However, several of the KDE apps are not picking up this scheme - e.g., the System Settings app itself, as well as Kalarm. But several other KDE apps are picking up the correct scheme correctly - such as Konqueror. Note that I'm using XFCE as my desktop, if that makes a difference Anyone have any idea what might be broken here, and how I might be able to get it fixed? Thanks, DR

4 5

[arch-general] libc++ is outdated (3.7.x) and incompatible with actual clang 3.8.x
by Константин Плотников 27 Jun '16

27 Jun '16

libc++ is outdated (3.7.1 flagged out-of-date on 2016-03-28) and incompatible with actual clang 3.8 If you try to compile simple program which use std::string with clang and libc++ you will get an error: [root@707cd1f92063 /]# cat test.cpp #include <string> int main() { std::string a; } [root@707cd1f92063 /]# clang++ -std=c++11 -stdlib=libc++ -lc++abi test.cpp -o test && ./test In file included from test.cpp:1: /usr/bin/../include/c++/v1/string:1938:44: error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible<allocator_type>::value)' basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& __a) ^ /usr/bin/../include/c++/v1/string:1326:40: note: previous declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a) Is there any reason libc++ 3.8 is not in repo yet? Could I help somehow? Thank you, Konstantin

1 0

[arch-general] Eclipse-java and java7
by Ilya Boka 26 Jun '16

26 Jun '16

When i start eclipse with Java7 i get following error http://pastebin.com/rGnCG5An With Java8 everything work fine.. Maybe eclipse should hava Java8 as dependence?

2 1

Re: [arch-general] Enable translations in transmission-qt
by Alexey Rochev 24 Jun '16

24 Jun '16

2016-05-30 0:18 GMT+03:00, Alexey Rochev <equeim(a)gmail.com>: > Hi, > I posted fixed PKGBUILD in https://bugs.archlinux.org/task/20982 a > week ago, but it seems that no one noticed. > Here is the patch: http://pastebin.com/b483Rqjp > Does transmission package have active maintainers? Last commits by Ionut Biru and Tom Gundersen were three years ago.

2 4