No, only the Manjaro unstable branch thus far.
If you want to use Manjaro and stay close to Arch updates, use the unstable branch.
No, only the Manjaro unstable branch thus far.
If you want to use Manjaro and stay close to Arch updates, use the unstable branch.
OpenBLAS >= 0.3.23-2 update requires manual intervention
2023-06-14 - Felix Yan
The
openblas
package prior to version 0.3.23-2 doesn’t ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc.The default BLAS implementation will be used for most packages like NumPy or R. Please install
blas-openblas
andblas64-openblas
to make OpenBLAS the default BLAS implementation, just like the old behavior.Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation:
error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency 'blas' required by cblas :: installing openblas (0.3.23-2) breaks dependency 'blas' required by lapack
Please append your preferred default BLAS implementation to the regular
-Syu
command line to get around it. For example:sudo pacman -Syu blas-openblas
or
sudo pacman -Syu blas
Well thanks for making me look.
Now I realized I was using blas
when I want blas-openblas
instead.
The Time Has Come:
Testing finished changing in the repos since “15.06.2023”
( [Testing Update] 2023-06-15 - Kernel, Systemd, Mesa, GNOME 44.2, NVIDIA, ZFS, LibreOffice, PipeWire - #7 by Lila-Kuh )
Thanks for letting me know. I never would have found out unless you told me.
TeX Live package reorganization
2023-06-18 - Antonio Rojas
Starting from version 2023.66594-9, TeX Live packages have been reorganized to mirror upstream collections. Even though the new
texlive-basic
replaces the oldtexlive-core
, many of the texlive-core contents (including language specific files) are now split between different packages. To find out which Arch package contains a specific CTAN package, you can use thetlmgr
utility, eg.$ tlmgr info euler | grep collection collection: collection-latexrecommended
which means the euler CTAN package is contained in
texlive-latexrecommended
. You may also usepacman -F
to query for specific files.A new metapackage
texlive-meta
is available to install all subpackages (except for language specific ones), and the newtexlive-doc
package provides the full documentation for offline use.
This broke latexmk
:
$ pamac search --files /usr/bin/latexmk
/usr/bin/latexmk is owned by texlive-bin
$ pamac info texlive-bin
Name : texlive-bin
Version : 2023.66984-7
[...]
Build Date : Sa 17 Jun 2023 01:29:09 CEST
Install Date : Mo 19 Jun 2023 09:57:19 CEST
$ which latexmk
latexmk not found
Edit: You have to install texlive-binextra
to actually install latexmk
.
The file that texlive-bin
provides is a broken symlink to /usr//share/texmf-dist/scripts/latexmk/latexmk.pl
which can only be resolved by installing the binextra package.
It’s fixed with 2023.66594-13.
systemd
in it’s current state has a regression which leads to (some) problems with libvirtd
and other services:
It seems to be resolved now by reverting the offending commit:
Arch has already released a fixed systemd
package with this single cherry-pick:
As we do not inherit systemd
from arch, I’m hoping for an updated package…
edit: Thanks to @Yochanan the patch has landed:
The
pamac-gtk
Gtk 4 port is finally finished!
Make sure you’re fully up to date first:
sudo pacman -Syu
Then choose which version you prefer:
Install Gtk 4 version:
sudo pacman -S pamac-gtk
Install Gtk 3 version:
sudo pacman -S pamac-gtk3
I get a lot of GTK critical messages when clicking on Pamac menu in the GUI in KDE Plasma, this is pamac-gtk
. but pamac-gtk3
has no issue. I can reproduce the issue on my system and VM without custom config.
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.950: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.950: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.964: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_x: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
(pamac-manager:3193): Gtk-CRITICAL **: 21:52:34.993: _gtk_css_corner_value_get_y: assertion 'corner->class == >K_CSS_VALUE_CORNER' failed
...
I reported the issue.
How will the gtk4 version affect the Flatpak and Snap plugins?
They’re not related as they’re part of libpamac
.
pamac-gtk
and pamac-gtk3
should properly conflict reach other.
edit: Ah, the current pamac-gtk3
package conflicts with pamac-gtk
but the current pamac-gtk
doesn’t conflict with pamac-gtk3
.
It still has to interact with them.
The description of pamac-gtk (gtk4 version) still notes gtk3 in the description. I have installed the gtk4 version and it seems to function well for my use case. Nice work and thank you.
Changing some Pamac preferences can not be saved when using pamac-gtk
(gtk4)
pamac-manager
Presumably through libpamac
.