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

gmgf · 03-27-2024, 02:40 AM

Quote:

Originally Posted by marav

Done

https://git.slackware.nl/current/dif...e385387d3664e3
https://git.slackware.nl/current/dif...e385387d3664e3

Thanks

teoberi · 03-27-2024, 07:04 AM

Zstandard v1.5.6 - Chrome Edition
https://github.com/facebook/zstd/releases

thirdm · 03-27-2024, 10:09 PM

Quote:

Originally Posted by glennmcc

Is there not a better fix than that which would only last till a bit past my 124th birthday ?

Some year 2000 fixes did not expand the number of digits from two but only used a convention for interpretation, e.g. 30 is 2030 not 1930 cause we say so. Not great for an historian using a computer maybe, and really bugs a certain kind of person, but sensible enough in many cases.

If it's useful to keep this field the same size there will always be an interpretation for overflow that would be sensible for most people. For the first transition, code using the fields should special case negative numbers by adding their absolute values to the first overflow time. When the negative numbers hit zero and go positive again, positive numbers are treated like we're in a new epoch with 1970 replaced by it in our interpretation. When back to negative numbers again do the absolute value thing again from the new time of overflow.

bigbadaboum · 03-28-2024, 09:03 AM

@henca
glibc-2.35/include/time.h pass
glibc-2.35/bits/utmp.h fail

Quote:

libc-2.35/build-glibc/login/updwtmp.o
In file included from ../login/utmp.h:29:0,
from ../include/utmp.h:2,
from ../login/updwtmp.c:18,
from ../sysdeps/unix/sysv/linux/updwtmp.c:36:
../bits/utmp.h:79:5: error*: unknown type name «*uint32_t*»
uint32_t tv_sec; /* Seconds. */
^~~~~~~~
../bits/utmp.h:80:5: error*: unknown type name «*uint32_t*»
uint32_t tv_usec; /* Microseconds. */
^~~~~~~~

A solution very Monty Python by Papa Alpha Tango.

https://git.slackware.nl/current/com...e385387d3664e3

Quote:

diff --git a/source/x/x11/configure/gccmakedep b/source/x/x11/configure/gccmakedep
index 181ae81e9..741f8ea6e 100644
--- a/source/x/x11/configure/gccmakedep
+++ b/source/x/x11/configure/gccmakedep
@@ -8,6 +8,7 @@ CXXFLAGS=$SLKCFLAGS \
--infodir=/usr/info \
--mandir=/usr/man \
--disable-static \
+ --enable-year2038 \
--build=$ARCH-slackware-linux
#
# --docdir=/usr/doc/${PKGNAME}-${MODULAR_PACKAGE_VERSION}
diff --git a/source/x/x11/configure/libX11 b/source/x/x11/configure/libX11
index 2f003db4a..625ca2e15 100644
--- a/source/x/x11/configure/libX11
+++ b/source/x/x11/configure/libX11
@@ -10,4 +10,5 @@ CXXFLAGS=$SLKCFLAGS \
--mandir=/usr/man \
--disable-static \
--disable-thread-safety-constructor \
+ --enable-year2038 \
--build=$ARCH-slackware-linux
diff --git a/source/x/x11/configure/xorg-server b/source/x/x11/configure/xorg-server
index e3426aa21..6a536c0d5 100644
--- a/source/x/x11/configure/xorg-server
+++ b/source/x/x11/configure/xorg-server
@@ -69,6 +69,7 @@ CFLAGS="$SLKCFLAGS" \
--with-xkb-output=/var/lib/xkb \
--enable-config-udev \
--disable-config-hal \
+ --enable-year2038 \
$BUILD_SERVERS \
$ROOTLESS_OPTIONS \
--build=$ARCH-slackware-linux

biker_rat · 03-28-2024, 02:09 PM

https://archive.mesa3d.org/mesa-24.0.4.tar.xz ( latest mesa bugfix point release) is available.

henca · 03-28-2024, 03:56 PM

Quote:

Originally Posted by bigbadaboum

@henca
glibc-2.35/include/time.h pass
glibc-2.35/bits/utmp.h fail

Code:

../bits/utmp.h:79:5: error*: unknown type name «*uint32_t*»
uint32_t tv_sec; /* Seconds. */

That was really odd as int32_t is defined in the same stdint.h as uint32_t:

Code:

/usr/include/stdint.h:typedef int                       int32_t;
/usr/include/stdint.h:typedef unsigned int              uint32_t;

On the other hand, stdint.h has not been included by utmp.h, instead sys/types.h has been included which also defines int32_t but not uint32_t:

Code:

/* These types are defined by the ISO C99 header <inttypes.h>. */
# ifndef __int8_t_defined
#  define __int8_t_defined
typedef	char int8_t;
typedef	short int int16_t;
typedef	int int32_t;
#  if __WORDSIZE == 64
typedef long int int64_t;
#  else
__extension__ typedef long long int int64_t;
#  endif
# endif

The above is from sys/types.h in Slackware 14.2, I haven't found those lines on my Slackware 15.0 system. Did you try to compile on a Slackware 14.2 system?

The comment in sys/types.h references the ISO C99 standard, but the ISO C99 standard says that also uint32_t should exist and be defined in stdint.h: https://en.cppreference.com/w/c/types/integer

Two different suggestions for fixes:

Include stdint.h before types.h
Use unsigned int instead of uint32_t

regards Henrik

glennmcc · 03-28-2024, 10:49 PM

Quote:

Originally Posted by bigbadaboum

@henca
glibc-2.35/include/time.h pass
glibc-2.35/bits/utmp.h fail

A solution very Monty Python by Papa Alpha Tango.

https://git.slackware.nl/current/com...e385387d3664e3

Why are you working with glibc-2.35 which is not in any slackware release ?

v14.2 has glibc-2.23, v15.0 has glibc-2.33
current used to have glibc-2.35 but that was 2yrs ago.
current is now at glibc-2.39

http://ftp.dnslb.sjtu.edu.cn/sites/w...slackware64/l/

glibc-2.32-x86_64-2.txt 07-Feb-2021 21:20 313
glibc-2.32-x86_64-2.txz 07-Feb-2021 21:20 5251036
glibc-2.32-x86_64-2.txz.asc 07-Feb-2021 21:20 163
glibc-2.33-x86_64-1.txt 13-Feb-2021 05:52 313
glibc-2.33-x86_64-1.txz 13-Feb-2021 05:52 5290396
glibc-2.33-x86_64-1.txz.asc 13-Feb-2021 05:52 163
glibc-2.33-x86_64-2.txt 01-Apr-2021 23:21 313
glibc-2.33-x86_64-2.txz 01-Apr-2021 23:21 5280640
glibc-2.33-x86_64-2.txz.asc 01-Apr-2021 23:21 163
glibc-2.33-x86_64-3.txt 07-Aug-2021 18:28 313
glibc-2.33-x86_64-3.txz 07-Aug-2021 18:28 5272168
glibc-2.33-x86_64-3.txz.asc 07-Aug-2021 18:28 163
glibc-2.33-x86_64-4.txt 17-Aug-2021 20:04 313
glibc-2.33-x86_64-4.txz 17-Aug-2021 20:04 5270616
glibc-2.33-x86_64-4.txz.asc 17-Aug-2021 20:04 163
glibc-2.33-x86_64-5.txt 24-Jan-2022 20:42 313
glibc-2.33-x86_64-5.txz 24-Jan-2022 20:42 5272216
glibc-2.33-x86_64-5.txz.asc 24-Jan-2022 20:42 163
glibc-2.35-x86_64-1.txt 20-Feb-2022 21:43 313
glibc-2.35-x86_64-1.txz 20-Feb-2022 21:43 5416180
glibc-2.35-x86_64-1.txz.asc 20-Feb-2022 21:43 163
glibc-2.35-x86_64-2.txt 22-Feb-2022 21:10 313
glibc-2.35-x86_64-2.txz 22-Feb-2022 21:10 5419264
glibc-2.35-x86_64-2.txz.asc 22-Feb-2022 21:10 163
glibc-2.36-x86_64-1.txt 02-Aug-2022 03:35 313
glibc-2.36-x86_64-1.txz 02-Aug-2022 03:35 5422124
glibc-2.36-x86_64-1.txz.asc 02-Aug-2022 03:35 163
glibc-2.36-x86_64-2.txt 17-Aug-2022 19:36 313
glibc-2.36-x86_64-2.txz 17-Aug-2022 19:36 5415108
glibc-2.36-x86_64-2.txz.asc 17-Aug-2022 19:36 163
glibc-2.36-x86_64-3.txt 01-Sep-2022 02:33 313
glibc-2.36-x86_64-3.txz 01-Sep-2022 02:33 5417592
glibc-2.36-x86_64-3.txz.asc 01-Sep-2022 02:33 163
glibc-2.37-x86_64-1.txt 02-Feb-2023 18:06 313
glibc-2.37-x86_64-1.txz 02-Feb-2023 18:06 5423488
glibc-2.37-x86_64-1.txz.asc 02-Feb-2023 18:06 163
glibc-2.37-x86_64-2.txt 03-Feb-2023 19:17 313
glibc-2.37-x86_64-2.txz 03-Feb-2023 19:17 5422916
glibc-2.37-x86_64-2.txz.asc 03-Feb-2023 19:17 163
glibc-2.37-x86_64-3.txt 03-Oct-2023 21:40 313
glibc-2.37-x86_64-3.txz 03-Oct-2023 21:40 5472528
glibc-2.37-x86_64-3.txz.asc 03-Oct-2023 21:40 163
glibc-2.38-x86_64-2.txt 03-Oct-2023 21:29 313
glibc-2.38-x86_64-2.txz 03-Oct-2023 21:29 5445772
glibc-2.38-x86_64-2.txz.asc 03-Oct-2023 21:29 163
glibc-2.38-x86_64-3.txt 13-Oct-2023 20:36 313
glibc-2.38-x86_64-3.txz 13-Oct-2023 20:36 5598828
glibc-2.38-x86_64-3.txz.asc 13-Oct-2023 20:36 163
glibc-2.39-x86_64-1.txt 02-Feb-2024 21:24 313
glibc-2.39-x86_64-1.txz 02-Feb-2024 21:24 5637496
glibc-2.39-x86_64-1.txz.asc 02-Feb-2024 21:24 163

bigbadaboum · 03-29-2024, 02:11 AM

Quote:

glennmcc
Member
Why are you working with glibc-2.35 which is not in any slackware release ?

Quote:

glennmcc
Member
If I recall correctly, even the 32bit Linux kernels fixed the 2038 date problem a long time ago.
___

Yep, fixed.
https://www.gnu.org/software/gnulib/...8-problem.html

in your link
"With the ‘year2038-recommended’ module, configure by default should work on the following 32-bit platforms (or 32-bit ABIs in bi-arch systems):
Linux kernel 5.1 (2019) and later with glibc 2.34 (2021) and later"

It's just a compile test, I don't try to install it on 14.2

even if I suspect what Slackware will choose to replace utmp.

USUARIONUEVO · 03-29-2024, 06:55 AM

lxml-5.1.1 is out

https://pypi.org/project/lxml/

This is the changelog

Quote:

5.1.1 (2024-03-28)
==================

Bugs fixed
----------

* LP#2048920: ``iterlinks()`` in ``lxml.html`` rejected ``bytes`` input in 5.1.0.

* High source line numbers from the parser are no longer truncated
(up to a C ``long``) when using libxml2 2.11 or later.

* GH#407: A compatibility test was adapted to recent expat versions.
Patch by Miro Hrončok.

Other changes
-------------

* Binary wheels use the library versions libxml2 2.12.6 and libxslt 1.1.39.

* Windows binary wheels use the library versions libxml2 2.11.7 and libxslt 1.1.39.

* Built with Cython 3.0.9.

glennmcc · 03-29-2024, 11:15 AM

Linux kernel 5.1 (2019) and later with glibc 2.34 (2021) and later"
______________________^^^^^____________________^^^^^_______

Soooo.... it seems to make sense to test with the latest kernel and latest glibc that are already in -current.

USUARIONUEVO · 03-29-2024, 03:29 PM

Hi , today , inspectioning my dmesg i see this

Quote:

No NUMA configuration found

I see rare thing on kernel config ...we have a lot of NUMA things enabled , but later ...

Quote:

# CONFIG_NUMA_BALANCING is not set

Can we get this enabled on kernel config ?

Thanks !

USUARIONUEVO · 03-29-2024, 05:25 PM

Something is wrong with python3-3.11 under x64 packages.

Quote:

/usr/lib/python3.11/site-packages/

miss the suffix , ... folder is empty but , i see a lot of rebuilds go under lib instead lib64

Need revision here.

See samba as example ...he goes on wrong suffix ...

Quote:

/usr/lib/python3.9/site-packages/samba/

marav · 03-29-2024, 05:38 PM

Quote:

Originally Posted by USUARIONUEVO

Something is wrong with python3-3.11 under x64 packages.

miss the suffix , ... folder is empty but , i see a lot of rebuilds go under lib instead lib64
Need revision here.

See samba as example ...he goes on wrong suffix ...

Nothing like that here ... for now
upgrade in progress

volkerdi · 03-29-2024, 05:38 PM

Quote:

Originally Posted by USUARIONUEVO

Something is wrong with python3-3.11 under x64 packages.

miss the suffix , ... folder is empty but , i see a lot of rebuilds go under lib instead lib64

Notice how there are some x86_64 ELF objects under /usr/lib64/python3.11/site-packages but there aren't any under /usr/lib/python3.11/site-packages...

We've always been bucking upstream on x86_64, and since it doesn't look like anyone else is trying to force everything on x86_64 into /usr/lib64, this time I just let python handle these directories in the default way.

USUARIONUEVO · 03-29-2024, 05:52 PM

In first moment i suspect something bad with wheel install ..but no.

As fast test i play with Mako ... he ever goes under /usr/lib ... with wheel , or classic setup.py ... its rare.

I see python3.9 plays with same rules ... then , for now im not have nothing more to say.

I see the *.pc files have correct libdir suffix ...probably this is cause ELF goes on right side.