Hi I'm a tad confused whats happening with mesa, are we regressing or have mesa thrown a spanner in the works. And forgot next release would be mesa-26.1.1 or do they go straight to mesa-26.1.2. Or has some one been at our Cider/Beer/Lager/Wine/Spirits/water for none alcohol drinkers but the defo have no excuses.

ChangeLog.txt
Fri May 15 02:12:09 UTC 2026
x/mesa-26.0.7-x86_64-1.txz: Upgraded.

Wed May 6 22:38:32 UTC 2026
x/mesa-26.1.0-x86_64-1.txz: Upgraded.

1 members found this post helpful.

I don't know, but I reported a mesa regression in this thread https://www.linuxquestions.org/quest....php?p=6632468 (Intel Sandy Bridge i5-2400). I bisected it to a commit about Intel BLORP.

3 members found this post helpful.

We were regressing but now we aren't. :-)

3 members found this post helpful.

librsvg-2.62.2

https://download.gnome.org/sources/l...-2.62.2.tar.xz
https://download.gnome.org/sources/l...62.2.sha256sum

well and gimp but thats besides the point....

No, GIMP didn't need this new version without this patch:

in the SlackBuild

# Allow a newer gexiv2:

0001-build-macos-Do-not-require-gexiv2-0.14-on-homebrew.patch

It's just an anecdote

Ok then i didnt ask for this new version others did. I just provided the fix that was already out there.
@volkerdi chose to upgrade it. It is his choice not mine.

Yes, I know, no problem

1 members found this post helpful.

would it be possible to build the kernel with CONFIG_OBJTOOL_WERROR=n, so that compiling things like NVIDIA proprietary drivers wouldn't fail because of warnings from objtool?

5 members found this post helpful.

Hi , i ask for curiosity , why default rust is frozen on 1.88 ?

Archlinux are in 1.95 , then if the problem is for need patches , probably exists now.

And YES , i see we have same version in /testing ... but curiosity about why stuck in 1.88

Thanks for the work!

EDIT: python-maturin builds with rust-1.95 , but cant build with 1.88 (too old) , as a informational only purpouse.

I install 1.95 from /testing and test some builds...stock system nothing need to be rebuild , extra packages builds fine with 1.95 , some fails with 1.88.

Please , WAKE UP NEO. ;=)

1 members found this post helpful.

IIRC, we follow, more or less, this :
https://firefox-source-docs.mozilla....te-policy.html

1 members found this post helpful.

I'm sure you're well aware, but rust-opt still exists in ponce's repo for the example you just provided.

1 members found this post helpful.

Yes , i know , but ..think this ... slackbuilds provide more newer rustr for 15.0 than -current for /main ... in -current im not want to install 2 rust versions, like not 2 ffmpeg versions ...2 kernel-versions ... etc etc etc.


I install rust-1.95 from testing ....build what i need (some python bindings) , and return to 1.88 , all fine , but strange to see slackbuild have more recent versions of rust than /main -current. :=)

Imagin install qt6 from slackbuilds cause is more modern than -current version ;=)


Including linux from scratch are in 1.95 ... all except slackware -current xD
https://www.linuxfromscratch.org/blf...eral/rust.html

As i say , is not big problem .... install from /testing ..and return to default after build python bindings.

1 members found this post helpful.

In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.

Introduced by: https://github.com/sudo-project/sudo...9df121931d4ff5 (SUDO_1_9_4p1)
Fixed by: https://github.com/sudo-project/sudo...a4e20e8c81bb69
https://nvd.nist.gov/vuln/detail/CVE-2026-35535

The SlackBuild in Current truncates BASH_LOADABLES_PATH to a single entry: either /usr/lib64/bash or /usr/lib/bash.
It was originally /usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.
Of course, lib needs to be changed to lib64 on 64-bit platforms.
But you really want "." (current directory) in there as well when developing a new loadable: that's where the provided development environment will put the new shared object.
And you want /usr/local/lib/bash for the new loadable once it's finished, because upgradepkg will blow it away if you put it in /usr/lib/bash.
The patch below (and attached) gets bash.SlackBuild to change lib/bash to lib64/bash wherever it occurs in source and documentation.
@volkerdi: please apply.

--8<--8<--8<--8<--8<

--- a/bash.SlackBuild 2026-04-04 07:29:11.000000000 +1100
+++ b/bash.SlackBuild 2026-05-12 13:42:29.000000000 +1000
@@ -31,7 +31,7 @@

PKGNAM=bash
VERSION=${VERSION:-$(echo bash-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
-BUILD=${BUILD:-1}
+BUILD=${BUILD:-2}

# Automatically determine the architecture we're building on:
MARCH=$( uname -m )
@@ -107,9 +107,13 @@
autoreconf -vif
fi

-# Set default BASH_LOADABLES_PATH. Yes, there's -DDEFAULT_BASH_LOADABLES_PATH,
-# but good luck getting it to behave.
-sed -i "s|/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:.|/usr/lib${LIBDIRSUFFIX}/bash|g" config-top.h
+# On 64-bit systems, change the default BASH_LOADABLES_PATH
+# and fix documentation accordingly.
+if [ -n "$LIBDIRSUFFIX" ]; then
+ for i in config-top.h doc/bashref.html doc/bash.info; do
+ sed -i "/lib\/bash/s+lib/bash+lib${LIBDIRSUFFIX}/bash+g" $i
+ done
+fi

CFLAGS="$SLKCFLAGS" \
./configure \

Attached Files

bash.SlackBuild.patch.txt (983 Bytes, 2 views)