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

TommyC7 · 03-29-2024, 05:57 PM

I mentioned this here: https://www.linuxquestions.org/quest...ml#post6492794 as well but it seems like this may be the better place to ask.

Are the python-tomli{,-w} packages still necessary? It feels like we had them to have a toml parser for PEP-517 but python-3.11 comes with a toml parser in the standard library (tomllib).

Nobby6 · 03-29-2024, 08:02 PM

Pat,

/source/d/perl/DBD-mysql-4.051.tar.gz

Can DBD::mysql please be replaced with DBD::MariaDB

DBD-mysql is DITW. As of v5 (current versions) are cripple-ware no longer supporting greater than mysql v8 - not even mysql's own greater versions.

DBD-MariaDB supports not only the obvious, but also mysql10+ designed with backward compatibility.

Moving forward, I think this is a better solution, since the decision taken wont be reversed.

Thus far I've no issues with DBD::MariaDB having installed it

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

mmm ... investigating the python lib mismatch on x64 suffix.

I think we no have nothing to do ...

https://docs.python.org/3/library/sys.html#sys.path

Quote:

sys.platlibdir
Name of the platform-specific library directory. It is used to build the path of standard library and the paths of installed extension modules.

It is equal to "lib" on most platforms. On Fedora and SuSE, it is equal to "lib64" on 64-bit platforms which gives the following sys.path paths (where X.Y is the Python major.minor version):

/usr/lib64/pythonX.Y/: Standard library (like os.py of the os module)

/usr/lib64/pythonX.Y/lib-dynload/: C extension modules of the standard library (like the errno module, the exact filename is platform specific)

/usr/lib/pythonX.Y/site-packages/ (always use lib, not sys.platlibdir): Third-party modules

/usr/lib64/pythonX.Y/site-packages/: C extension modules of third-party packages

New in version 3.9.

Lockywolf · 03-29-2024, 09:48 PM

Can we have python under l/, not d/?

Some stuff depends on the Python interpreter, even for people who don't use the machine for development.

Code:

./x/marisa/marisa.SlackBuild:  python3 setup.py build_ext \
./x/marisa/marisa.SlackBuild:  python3 setup.py install \
./ap/undervolt/undervolt.SlackBuild:python3 setup.py install --root=$PKG || exit 1
./ap/hplip/hplip.SlackBuild:zcat $CWD/setup.py.lc_all.c.diff.gz | patch -p1 --verbose || exit 1
./n/nmap/nmap.SlackBuild:sed -i "s,share/man/man1,man/man1,g" ndiff/setup.py
./n/pssh/pssh.SlackBuild:cp -a $CWD/setup.py .
./n/pssh/pssh.SlackBuild:chmod 755 setup.py
./n/pssh/pssh.SlackBuild:python3 setup.py build install --root=$PKG
./n/getmail/getmail.SlackBuild:python3 setup.py build || exit 1
./n/getmail/getmail.SlackBuild:python3 setup.py install --root=$PKG || exit 1

gwhl · 03-30-2024, 09:05 AM

Quote:

Originally Posted by Lockywolf

Can we have python under l/, not d/?

Some stuff depends on the Python interpreter, even for people who don't use the machine for development.

Code:

./x/marisa/marisa.SlackBuild:  python3 setup.py build_ext \
./x/marisa/marisa.SlackBuild:  python3 setup.py install \
./ap/undervolt/undervolt.SlackBuild:python3 setup.py install --root=$PKG || exit 1
./ap/hplip/hplip.SlackBuild:zcat $CWD/setup.py.lc_all.c.diff.gz | patch -p1 --verbose || exit 1
./n/nmap/nmap.SlackBuild:sed -i "s,share/man/man1,man/man1,g" ndiff/setup.py
./n/pssh/pssh.SlackBuild:cp -a $CWD/setup.py .
./n/pssh/pssh.SlackBuild:chmod 755 setup.py
./n/pssh/pssh.SlackBuild:python3 setup.py build install --root=$PKG
./n/getmail/getmail.SlackBuild:python3 setup.py build || exit 1
./n/getmail/getmail.SlackBuild:python3 setup.py install --root=$PKG || exit 1

Python is absolutely not a library, it's an interpreter for a programming language. It does not belong into l/

reddog83 · 03-30-2024, 09:09 AM

Quote:

Originally Posted by USUARIONUEVO

mmm ... investigating the python lib mismatch on x64 suffix.

I think we no have nothing to do ...

https://docs.python.org/3/library/sys.html#sys.path

I was just wondering the same thing. I noticed that some of my modules are going into the /usr/lib directory instead of the /usr/lib64 directory.

USUARIONUEVO · 03-30-2024, 09:49 AM

Quote:

Originally Posted by reddog83

I was just wondering the same thing. I noticed that some of my modules are going into the /usr/lib directory instead of the /usr/lib64 directory.

If im not wrong ,fedora use the same 64 suffix fro lib .. --> lib64

I inspectioning some ilttle numbers of python things and all goes to /usr/lib64

And today rebuilding things , isee how python stuff in /usr/lib64 ... now goes to /usr/lib

But no found the cause.

Fedora is on python 3.11 like slackware current ...im not sure if forcing the modules to go on lib64 with some python export.

chrisretusn · 03-30-2024, 09:57 AM

Regarding /usr/lib/ and /usr/lib64 with python3-3.12.8, see this post: https://www.linuxquestions.org/quest...ml#post6492807

audriusk · 03-30-2024, 09:57 AM

Quote:

Originally Posted by TommyC7

I mentioned this here: https://www.linuxquestions.org/quest...ml#post6492794 as well but it seems like this may be the better place to ask.

Are the python-tomli{,-w} packages still necessary? It feels like we had them to have a toml parser for PEP-517 but python-3.11 comes with a toml parser in the standard library (tomllib).

Indeed, running

Code:

grep 'Requires-Dist: tomli' /usr/lib*/python3.11/site-packages/*-info/METADATA

shows that anything requiring tomli also has a clause python_version < "3.11" or something similar. Also on tomli GitHub page there's a note:

Quote:

A version of Tomli, the tomllib module, was added to the standard library in Python 3.11 via PEP 680. Tomli continues to provide a backport on PyPI for Python versions where the standard library module is not available and that have not yet reached their end-of-life.

But tomli-w is still needed (from tomlib docs):

Quote:

This module provides an interface for parsing TOML (Tom’s Obvious Minimal Language, https://toml.io). This module does not support writing TOML.

See also

The Tomli-W package is a TOML writer that can be used in conjunction with this module, providing a write API familiar to users of the standard library marshal and pickle modules.

reddog83 · 03-30-2024, 10:00 AM

Quote:

export PYTHONPATH="/usr/lib64/python3.11/site-packages:$PYTHONPATH"

A friend of mine has mentioned that we mite have to do this now.

fulalas · 03-30-2024, 10:16 AM

Quote:

Originally Posted by USUARIONUEVO

If im not wrong ,fedora use the same 64 suffix fro lib .. --> lib64

I inspectioning some ilttle numbers of python things and all goes to /usr/lib64

And today rebuilding things , isee how python stuff in /usr/lib64 ... now goes to /usr/lib

But no found the cause.

Fedora is on python 3.11 like slackware current ...im not sure if forcing the modules to go on lib64 with some python export.

The moment I edit /usr/lib64/python3.11/sysconfig.py and change this:

Code:

'purelib': '{base}/lib/python{py_version_short}/site-packages',

To this:

Code:

'purelib': '{base}/lib64/python{py_version_short}/site-packages',

Then every python package I compile now gets into /usr/lib64

USUARIONUEVO · 03-30-2024, 10:26 AM

Quote:

Originally Posted by fulalas

The moment I edit /usr/lib64/python3.11/sysconfig.py and change this:

Code:

'purelib': '{base}/lib/python{py_version_short}/site-packages',

To this:

Code:

'purelib': '{base}/lib64/python{py_version_short}/site-packages',

Then every python package I compile now gets into /usr/lib64

This do the trick , tested with wheel builds . and now all go --> /usr/lib64

The line to change appears two times .i change the two ..and all fine.

Probably a patch ...or sed command when builds on x64.

audriusk · 03-30-2024, 10:30 AM

There's another one that seems to be not needed any longer - pytz. It was added in this -current cycle for babel, but the babel version we have has this:

Code:

Requires-Dist: pytz >=2015.7 ; python_version < "3.9"

Also on pytz PyPI page there's this note:

Quote:

Projects using Python 3.9 or later should be using the support now included as part of the standard library, and third party packages work with it such as tzdata. pytz offers no advantages beyond backwards compatibility with code written for earlier versions of Python.

audriusk · 03-30-2024, 10:36 AM

To all people looking for ways to bring Python stuff from /usr/lib back to /usr/lib64 - I believe this is deliberate as Pat already posted here, besides everything's working fine. If you find something broken, please report it here.

USUARIONUEVO · 03-30-2024, 10:40 AM

Quote:

Originally Posted by audriusk

To all people looking for ways to bring Python stuff from /usr/lib back to /usr/lib64 - I believe this is deliberate as Pat already posted here, besides everything's working fine. If you find something broken, please report it here.

Hope multilib are agree with this ...

/usr/lib is used on x64 machines to have multilib for wine or steam ..or other things.