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

[arch-dev-public] TexLive 2020 packages
by Rémy Oudompheng 02 Apr '20

02 Apr '20

Hello, TexLive 2020 is frozen upstream and will be officially released in the coming days. Packages have been uploaded to [testing] and [community-testing] (for biber). Please let me know if you encounter issues with these. Regards, Rémy.

1 0

[arch-dev-public] Looking for an Arch ISO maintainer
by Jelle van der Waa 30 Mar '20

30 Mar '20

Hi all, Gerardo has stepped down as Arch ISO maintainer, which makes archiso unmaintained. I've asked Pierres if he was interested in maintaining the project and he is willing to do bug fixes when required but no major maintenance. Which means that we are looking for a new maintainer :-) To be completely honest, I am not sure what maintenance archiso requires but there are a few things I would love to see: - Proper CI / automated testing of the archiso - Reproducible archiso (patches on the mailing list) [1] - Support secure boot [2] - Accessibility improvements (patches available on the mailing list) [3] Please reply if you are interested in becoming an archiso maintainer, so far Alad has shown interested. [1] https://bugs.archlinux.org/task/63683?project=6 [2] https://bugs.archlinux.org/task/53864?project=6 [3] https://bugs.archlinux.org/task/63166?project=6 -- Jelle van der Waa

6 9

[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