Requests for current-next (15.0-->15.1)

opty · 05-25-2024, 01:50 PM

Change

Code:

if [ -r ChangeLog ]; then

to

Code:

if [ -r ChangeLog.md ]; then

in sysklogd.SlackBuild to make it work in the future and (typo?)

Code:

# For other options, see syslog(8).

to

Code:

# For other options, see syslogd(8).

in config/syslogd.new.

saxa · 05-26-2024, 09:00 AM

vte-0.76.2
https://download.gnome.org/sources/v...-0.76.2.tar.xz

lostintime · 05-26-2024, 11:07 AM

Noticed with e2fsprogs that e2scrub_all_cron is now installed in /libexec/e2fsprogs/ rather than /lib64/e2fsprogs/. Is this be design or an oopsie?

glennmcc · 05-26-2024, 11:56 AM

Quote:

Originally Posted by lostintime

Noticed with e2fsprogs that e2scrub_all_cron is now installed in /libexec/e2fsprogs/ rather than /lib64/e2fsprogs/. Is this be design or an oopsie?

Good catch.

Had not noticed that /libexec is a brand-new directory which did not exist till now.

lostintime · 05-26-2024, 12:04 PM

Quote:

Good catch.

For years I have run a simple script to check the root file system for rogue directories. Mostly caused by less robust programs that presume a full shell environment and create directories such as /.cache, /.config, etc. A full environment seldom exists when programs are run from within cron.

Anyway, perhaps Pat will explain whether or not the new /libexec is intentional.

LuckyCyborg · 05-26-2024, 12:56 PM

Quote:

Originally Posted by lostintime

Anyway, perhaps Pat will explain whether or not the new /libexec is intentional.

I for one I bet that's a result of the merged-usr strategy applied by the major Linux distributions.

gmgf · 05-26-2024, 01:01 PM

A little too much beer, perhaps.

ponce · 05-26-2024, 01:11 PM

Quote:

Originally Posted by lostintime

Noticed with e2fsprogs that e2scrub_all_cron is now installed in /libexec/e2fsprogs/ rather than /lib64/e2fsprogs/. Is this be design or an oopsie?

I think it's because of this commit

https://github.com/tytso/e2fsprogs/c...bba187e5431d7c

without anything I think the default is what we have ATM, but to follow our conventions we could pass

Code:

--libexecdir=/usr/libexec

glennmcc · 05-26-2024, 01:12 PM

Let's just hope that it's _Not_ as a result of something that's being done on systemD systems
which is now "polluting" the Slackware sysvinit system

LuckyCyborg · 05-26-2024, 01:16 PM

Quote:

Originally Posted by glennmcc

Let's just hope that it's _Not_ as a result of something that's being done on systemD systems
which is now "polluting" the Slackware sysvinit system

It has nothing to do with the systemd, but with another invention of Mr. Poettering - widely adopted by the major Linux distributions.

Technically, they put everything on /usr and the /bin, /lib64 and /sbin are just symlinks to the /usr counterparts.

glennmcc · 05-26-2024, 02:05 PM

Ah ha... today's upgrades will fix it

Sun May 26 18:29:25 UTC 2024
a/e2fsprogs-1.47.1-x86_64-2.txz: Rebuilt.
Define a proper --libexecdir. ;-) Thanks to lostintime.

____

Upgrades done.

/libexec is gone.

e2scrub_all_cron is now in /usr/libexec/e2fsprogs/

bigbadaboum · 05-26-2024, 03:02 PM

Quote:

glennmcc
Ah ha... today's upgrades will fix it

Sun May 26 18:29:25 UTC 2024
a/e2fsprogs-1.47.1-x86_64-2.txz: Rebuilt.
Define a proper --libexecdir. ;-) Thanks to lostintime.

Oops!

e2fsprogs.SlackBuild

Quote:

In file included from /usr/include/fuse/fuse.h:26:0,
from /usr/include/fuse.h:9,
from fuse2fs.c:29:
/usr/include/fuse/fuse_common.h:33:2: erreur*: #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags!
#error Please add -D_FILE_OFFSET_BITS=64 to your compile flags!

glennmcc · 05-26-2024, 03:37 PM

Quote:

Originally Posted by bigbadaboum

Oops!

e2fsprogs.SlackBuild

No such errors here.

Is your system a fully-upgraded -current ?

bigbadaboum · 05-26-2024, 04:16 PM

Quote:

glennmcc
No such errors here.

Is your system a fully-upgraded -current ?

No, I'm a big coward.

Whenever something is strange, I freeze the package

.

example:
/var/log/snmpd.log

Quote:

NET-SNMP version 5.9.4.pre2
Received TERM or STOP signal... shutting down...

NET-SNMP version 5.9.3
Received TERM or STOP signal... shutting down...

"Someday they'll remember how to cut a new release"
It is not me who writes it
https://mirror.slackbuilds.org/slack...rub.SlackBuild

fulalas · 05-26-2024, 05:13 PM

Has anything changed the way mesa is built since 24.0.7 up to current 24.1.0? I noticed A LOT of stutter in some AV1 files using dav1d since this mesa version. If I revert mesa to 24.0.6 (keeping everything else the same) everything plays smoothly.

I'm using the downloaded version of this video: https://www.youtube.com/watch?v=LXb3EKWsInQ (for yt-dlp users: yt-dlp -f 701+140 https://www.youtube.com/watch?v=LXb3EKWsInQ)

I have AMD 780M video card and mpv is using vaapi acceleration.

EDIT: it seems this is ffmpeg's fault: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11197. Updating to ffmpeg 7.0.1 should fix the issue. Is it possible to do it in current?