Are there any plans to replace mkinitcpio with dracut in Manjaro?
I have this warning in journald too.
When I use kernel linux63 I have this warnings:
kernel zswap: compressor lz4 not available, using default zstd
kernel zswap: loaded using pool zstd/z3fold
But, when using kernel linux62:
kernel zswap: loaded using pool lz4/z3fold
I have set in /etc/grub to use “zswap.compressor=lz4” and “zswap.zpool=z3fold”. As is in the Arch zswap wiki. Manjaro uses zstd as default, I will change this to use zstd, by removing this parametres. But when I remove them:
kernel zswap: loaded using pool zstd/zsmalloc
Then, this is the defaults for Manjaro.
I read somewhere that lz4 and z3fold is better for zswap compression.
yay has been dropped from the repos. It is no longer a viable AUR helper if it can’t rebuild packages because the same version is cached.
octopi will also be dropped as we no longer have any of the AUR helpers it supports in the repos.
Reminder: Neither Arch nor Manjaro officially support the AUR let alone AUR helpers. However, both still still have dedicated sections of the forum for assistance.
EDIT: I’ve reverted the changes.
octopi are back in the repos.
Damn, that was a fast drop from repo. The bug was just reported.
I’ve been using yay for a few years. Hopefully they fix that.
There are many “firmware” things in the AUR - needed to get a working System…
Seems it would be a rather rare case.
…but…it still doesnt change anything about AUR’s status as unofficial,third-party,unsupported.
Feel like elaborating on the first part about yay, cause I just replaced pikaur cause I didn’t feel like building it by hand?
As for Octopi you don’t have pikaur in the Manjaro repos? I switched switched to it when I thought yay was end of life and refused and still refuse to use paru.
That said Seeing Octopi dropped won’t hurt my feelings. Never been a fan of it. Years back when I first tried out Manjaro it came with Octopi and because if it and something else which I don’t remember I dropped Manjaro like a hot potato. Since then I learned I could simply install any number of software managers. Any Arch distro I install gets pamac with aur, snap, and flatpak support even though I update through the terminal and us pacseek for finding software.
Bug in yay causes it to even ignore explicit flags such as
--rebuild --answerclean All
(a workaround is to manually clean the cache … then yay will have to clean build)
Nonsense! if you remove the applications with a bug, manjaro will be empty!
Why not also remove pamac at the first bug? yay’s engine was rewritten a few weeks ago, so it’s normal to have bugs right now and they are fixed very fast. If manjaro doesn’t trust the developers anymore, they better stop the distribution right away.
If manjaro doesn’t trust the developers anymore, they better stop the distribution right away.
Why we have branches? I thought it was for this case ???
Why block testing when plasma or gnome is a problem when it is easier to remove them.
yay -S "package_name" --answerclean All not work ? it’s your solution last year for python 3.9 to 3.10 and, i can’t found issue in forum eos and arch for this python update with yay …
This depends on which hardware components are used on your System.
and not what is the weather like -Microsoft Answer, fully coorect but not helpful.
Folks, you’re free to use any AUR helper you like. There are binary releases of Yay and Paru if you don’t want to build them from source.
This implies that if
yay fixes the current issue, that it will be re-added to the repos. Is this the case? (If so, I agree that’s a weird reason to remove a long-time staple package from all Manjaro branches).
If that’s not the case, maybe be more straight-forward with the reasoning? i.e. Manjaro devs offer and support
pamac, which is probably seen as having feature-parity with
yay for most general use-cases, so maintaining
yay in the repos is no longer easy to justify.
I don’t really have much skin in this - I mainly use
pikaur, which can also be used for rebuilds as follows:
pikaur -Sa --rebuild $(pacman -Qqo /usr/lib/python3.10)
or all AUR packages (not just python) that need a rebuild (depends on
pikaur -Sa --rebuild $(checkrebuild|grep -oP '^foreign\s+\K(?!.*-bin$)([\w\.@\+\-]*)$')
That’s a very good explanation. Also, other team members had mentioned we shouldn’t even have any AUR helpers in the repos (well, besides Pamac).
Last time I tried pamac it was the cause of Ark failing to open zst files. I hope it doesn’t mess with file associations anymore…
20230505-1 causes conflicts due to an existing file:
manjaro-kde-settings: /etc/xdg/konsolerc exists in filesystem (owned by konsole)
Methinks something like this happened just a few weeks ago?
edit: Ah, some work to remedy the problem has already begun:
Fixed with 20230505-2.
One nice thing about yay was, that it practically has the same cli as
Some major UX glitches make the
pamac-cli not really a valid competitor for me.
For example this mind-bending duality of parameters (without an indication of what is the default):
--aur, -a also search in AUR --no-aur do not search in AUR
- it should install when no command is provided
- it should just search if it doesn’t find stuff when installing
I don’t like this decision. I still want a nice aur-including package-helper. After all, that is the only reason I use an arch-based distro.
I’ve reverted the changes.
octopi are back in the repos.