Wouldn’t this be easy to test by trying 6.7 release instead?
bashrc-manjaro
is now merged into bash
Yes, replace bashrc-manjaro
with bash
.
pacman
and pacman-contrib
changes
pacman-contrib
is now split out from pacman
. If you have anything installed that depends on pacman-contrib
, update with:
sudo pacman -Syu pacman-contrib
No risk, no fun!!
Hi , had the same problem, changed kernels, nothing changed, in the end what worked was (in KDE) opening Partition manager and changing drives to uuid and giving it a path. Had to write last part for each drive manualy Maybe it helps sombody.
@Yochanan @philm
That might be an interesting read about default build flags for mesa. As the change Arch made, is basically the same what you guys did to disable HW-acceleration, removing the video-codecs
build flag. It seems at least strange to me, but maybe upstream Mesa changed that just recently?
Edit:
Looking at this commit…
… it seems that there was indeed a change in mesa. For me it looks like Arch is wrong here. To enable patent encumbered codecs the build option -D video-codecs=all
is now needed. And the default is set to all_free
, which means only free codecs are enabled.
Indeed. Phil and I were discussing the same thing last night. I’m sure they’ll figure it out.
When I try to build with -D video-codecs=all, I get:
mesa-23.3.3/meson.build:21:0: ERROR: Options "all" are not in allowed choices: "vc1dec, h264dec, h264enc, h265dec, h265enc"
Because it’s not in 23.3 branch.
Thanks. Curiosity got me on that one.
Hello, when updating SDL2 _Mixer from version 2.6.3.2 to 2.8.0.1, all sound devices (headphones, microphone) disappear in the system. Perhaps the problem is that the LIB32-SDL2_mixer package remains the old version.
And also the question is whether these packages are necessary for something important? Since in the package manager they are not indicated as dependence for other packages.
Thank you.
Yes, it’s an expected behavoir if you build 23.3.x with this flag.
Try:
-D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc
Since upgrade to colord-sane 1.4.7-1
systemd-coredump[]: Process 838 (colord-sane) of user 968 dumped core
EDIT: gone back to stable, removed everything to do with “sane” and downgraded.
==> error gone, but is no solution. Packets now excluded from update.
==> I have an HP-ENVY Photo 6230 (Printer/Scanner)
I’m seeing similar behaviour.
This happens on machine reboot/shutdown though, not while it’s running.
Arch bug report indicating it’s happening on startup:
upstream bug:
I decided to remove the extramodules symlink style we had for years on Manjaro. All regular kernels got adopted to that. Example: [pkg-upd] 6.6.14-1 (e36c8df1) · Commits · Packages / Core / linux66 · GitLab [prepare] extramodules changes (847d4396) · Commits · Packages / Extra / linux66-extramodules / nvidia · GitLab This way the file structure will tell for which exact kernel the module was compiled against.
Hi Everybody,
There’s a bug witch nextcloud-client
.
I’ve open an issue here:
https://github.com/nextcloud/desktop/issues/6389
Wish You well
Just FYI for you update addicts.1 Myself, my sister, @philm, @codesardine, @boredland, @spikerguy and @romangg will be at FOSDEM 2024 this weekend. Everyone else will probably be going home after that, however my sister and I will be vacationing in Europe for a week after. I may sync unstable in the mornings with my coffee, but no guarantees.
https://blog.manjaro.org/fosdem24/
1 By the way, I’m also an update addict
I was planning to be there, but unfortunately not this year.
unstable
sync from Arch is a manual task?
Why? I would have thought this is automated.
Have fun and relax