For the wireplumber (pipewire pkg) docs to build consider adding the following:

sphinx-rtd-theme https://github.com/readthedocs/sphinx_rtd_theme
breathe https://github.com/breathe-doc/breathe

Also, here's a couple patches to Heinz's slackbuilds you might want to apply:

python-flit-core
-simpler method of building I found
-no need to update BUILD


python-wheel
-was still using setup.py instead of the new method
-built after python-flit-core and python-installer
-no need to update BUILD (only .pyc files change)

Attached Files

	python-flit-core.txt (864 Bytes, 10 views)
	python-wheel.txt (578 Bytes, 8 views)

1 members found this post helpful.

OK, but isn't that probably a good idea, at least for a while? Otherwise if you don't have python-wheel already you can't build it.

I think nobodino would agree.

2 members found this post helpful.

That's where "python3 -m flit_core.wheel" comes in and solves that problem.

1 members found this post helpful.

I don't see a reason to change from setup.py to wheels as long as it's working. python-wheel isn't needed by anything for the PEP 517/PEP 660 build stuff, so it would probably be safe to update it to use even build+installer, but I wanted to keep those "pillars" as independent from each other as possible.

2 members found this post helpful.

vala-0.56.11
https://download.gnome.org/sources/v...0.56.11.tar.xz

1 members found this post helpful.

How long it's going to keep working is the issue(setup.py will be removed) and if we can fix it from breaking in the future now...

Also python-installer uses the flit_core.wheel method already...at least that's my thought process.

As long as PV wants it to be that way.

It's the problem of the chicken and egg: SFS won't be able to build that package.

1 members found this post helpful.

Just to clear that up, there is no chicken and egg problem with python-wheel. It *could* be built with python-build and python-installer just fine, it wouldn't introduce any recursive dependency (at the moment). I just didn't because there is a setup.py still present that works. I'm not trying to set a precedent either, that *if* there is a setup.py in the source you should use it. It was just a choice I made to keep the fundamental packages that comprise the new python build process as independent from each other as possible (and retain the possibility to bootstrap them). It also made it easier for me to package it before it was in -current, because it had less extra dependencies.

I understand what you're trying to say here, and you're not wrong. It's just not that big of an issue. To me, anyway.


Because *that* is a chicken and egg situation. Can't use python-installer to install python-installer before python-installer is installed. That's why we use flit.

3 members found this post helpful.

That's the same reasoning I was applying to python-wheel.

But you're right it is just splitting hairs and the package doesn't change. Personally I'd just prefer to be consistent and why I went that way when I submitted the python3-wheel slackbuild on SBo.

Hello,
I use little 6 inch computer as backup and in case of main computer failure.
I had problem with keyboard on it. It needs the 'button' module loaded to get the keyboard working.
To install Slackware on it I had to use Arch Linux iso and manually copy installed Slackware from another computer.
I read that the keyboard in GPD MicroPC will work when the module button will be loaded. Could you add the 'button' module to installer's initrd image?

It is already there.

Thunderbird 115.1.1
https://www.thunderbird.net/en-US/th.../releasenotes/

Another query for our BDFL

Several distros have already dropped 32bit.

Is it your plan to continue to have both 32bit & 64bit releases of v15.1 ?

Or are you planning to drop 32bit ?

If I was planning to drop 32-bit for 15.1, I wouldn't be wasting my time with a 32-bit -current.

11 members found this post helpful.

Try it again with today's -current.

1 members found this post helpful.