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

[arch-dev-public] Discussion - Increasing our CPU requirements
by Allan McRae 30 Mar '20

30 Mar '20

Remember when Arch Linux was optimized out of the box. We have the blazingly fast i686 port while other distros hung out in i386 land. Those were the days where the idea of Arch being fast started. Now it has degraded to stuff of legend. Now, x86_64 is old. We should continue to push forward and add further optimization. Reasonable optimizations to consider: AVX2 FMA SSE4.2 AVX2 is Intel Haswell and newer or AMD Ryzen and newer. This CPUs released 2013 to 2015. So 5 - 7 years old. Discuss.

9 16

Re: [arch-dev-public] Discussion - Increasing our CPU requirements
by Allan McRae 29 Mar '20

29 Mar '20

On 29/3/20 9:27 pm, Amish wrote: > Also if I am not wrong Arch philosophy talks only about latest software > and no where there is mention of latest hardware being a compulsion. It used to. One of the original selling points was i686 optimization. Then we got lazy, and stopped innovating. A

1 0

[arch-dev-public] News draft: hplip 3.20.3-2 update requires manual intervention
by Andreas Radke 18 Mar '20

18 Mar '20

News draft - https://bugs.archlinux.org/task/61329 The hplip package prior to version 3.20.3-2 was missing the compiled python modules. This has been fixed in 3.20.3-2, so the upgrade will need to overwrite the untracked pyc files created. If you get errors like these hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in filesystem hplip: /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in filesystem ...many more... when updating, use pacman -Suy --overwrite /usr/share/hplip/\* to perform the upgrade. -Andy

2 1

[arch-dev-public] Proposal to remove PyGTK
by Balló György 17 Mar '20

17 Mar '20

Hi all, I would propose to remove PyGTK from the official repositories. PyGTK was used to create GTK2 applications in python2. It's deprecated and unmaintained since 2011 in favor of PyGObject, and does not receive any fixes since then. The following packages are in progress to be ported from PyGTK to PyGObject, but not released yet: - diffuse: a fork with python3 support is in progress: https://github.com/MightyCreak/diffuse - gimp: GTK3/python3 port is very slow, python extensions support can be disabled with the --disable-python switch - ibus-sunpinyin: python3 port was merged - mcomix: a fork with python3 support is available: https://github.com/multiSnow/mcomix3 - nmap: python3 port of ndiff is available, zenmap is not ported yet (can be disabled with --without-ndiff --without-zenmap switches): https://github.com/nmap/nmap/pull/1807 - nicotine+: python3 port is in progress: https://github.com/Nicotine-Plus/nicotine-plus/pull/106 The following packages were not ported yet and have inactive upstream: - gutenpy: last released in 2006 - ibus-googlepinyin: last released in 2012 - pyneighborhood: last released in 2011 - wifi-radar: last released in 2015 Any objections? -- György Balló Trusted User

4 3

Re: [arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 11 Mar '20

11 Mar '20

On Sun, 23 Feb 2020 at 13:57, Sven-Hendrik Haase <sh(a)lutzhaase.com> wrote: > On Wed, 18 Jul 2018 at 01:40, Sven-Hendrik Haase <sh(a)lutzhaase.com> wrote: > >> I don't run nvidia-390xx on any of my devices. I would appreciate it if >> somebody could take those drivers. I will continue maintaining the mainline >> nvidia package. >> > > This is still a problem. Somebody please over the fricken 390xx packages. > Since I was unable to trick anyone into maintaining these packages despite the best attempts, I'll be dropping them to AUR soon.

1 1

[arch-dev-public] News draft: firewalld>=0.8.1-2 update requires manual intervention
by Jan Alexander Steffens 29 Feb '20

29 Feb '20

The firewalld package prior to version 0.8.1-2 was missing the compiled python modules. This has been fixed in 0.8.1-2, so the upgrade will need to overwrite the untracked pyc files created. If you get errors like these firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/__init__.cpython-38.pyc exists in filesystem firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/client.cpython-38.pyc exists in filesystem firewalld: /usr/lib/python3.8/site-packages/firewall/__pycache__/dbus_utils.cpython-38.pyc exists in filesystem ...many more... when updating, use pacman -Suy --overwrite /usr/lib/python3.8/site-packages/firewall/\* to perform the upgrade.

2 1

[arch-dev-public] "date" C++ library packaging
by Brett Cornwall 24 Feb '20

24 Feb '20

I made the silly mistake of posting first to [arch-general]. Sorry! On 2020-02-13 09:24, Morten Linderud wrote: >On Thu, Feb 13, 2020 at 12:09:27AM -0800, Brett Cornwall via arch-general wrote: >> Waybar [1] just had an update where it pulled in a project called "date" >> [2]. I'm hesitant to package this under the name "date" since GNU coreutils >> shares a binary with that name. But this isn't a totally obscure library. >> >> Should I persuade upstream to change the name? Should I package it under >> another name? Or should I lay claim to the unused "date" package name and go >> on with my life? > >"chrono-date" could maybe work as an alternative name? > >I'm unsure why this is in [arch-general] and not [arch-dev-public] :) On 2020-02-13 02:24, David C. Rankin wrote: >And with the note that much of Howard Hinnant's date/time library is being >incorporated into the next C++ standard. Quite a feather in anyone's cap. Does anyone have any strong opinions?

2 1

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

[arch-dev-public] Potential removal of Chromium in ~2 months
by Evangelos Foutras 22 Feb '20

22 Feb '20

Just a quick heads up that I am considering dropping Chromium from [extra] a week or two before the Chromium 82 stable release (~April 28). The reason for this is that our API keys no longer work for geolocation requests and there is no clear upstream guidance on how to resolve this issue. [1] When I created these API keys back in 2013, there was a semi-official effort by the Chrome Team to support distro builds of Chromium in regard to accessing Google APIs; a few minor hiccups along the way were quickly resolved. I feel this arrangement is starting to fall apart (in spite of some upstream Chrome developers' best efforts). To make a long story short, I consider broken geolocation sufficient reason for removal. I don't mind it being broken for my own use, but shipping a package with broken functionality due to lack of upstream support does not sit well with me. To protect against systems with outdated Chromium (following the stable release of version 82), at the beginning of April I intend to post a news item about the need to switch to another browser. That is assuming no solution is found and nobody objects to the removal or wishes to continue maintenance of the package with reduced functionality. [1] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/Z…

3 5

[arch-dev-public] Vacationing
by David Runge 21 Feb '20

21 Feb '20

Hi all, I'll be out until Wednesday (2020-02-26) in a location with likely very limited internet access and will not be updating packages. If there are any urgent updates required, of course feel free to do them! In the case of libgit2 rebuilds, I got stuck on ruby-rugged, as a subset of the integration tests fail with the new version of libgit2 (and a different subset with the current version of libgit2). I will not be touching this until then. Again: If the upgrade proves to be urgent, feel free to spend time on this. Thanks! :) Best, David -- https://sleepmap.de

1 0