From glen at pld-linux.org  Thu Apr  7 08:41:16 2022
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 7 Apr 2022 09:41:16 +0300
Subject: gitlab on cvs machine
In-Reply-To: <c67bea20-8bbc-bcef-5558-84710a575fb8@maven.pl>
References: <c67bea20-8bbc-bcef-5558-84710a575fb8@maven.pl>
Message-ID: <162eaf8a-e1fd-5f84-fb22-ea77c2bb3764@pld-linux.org>

On 29.03.2022 18:20, Arkadiusz Mi?kiewicz via pld-devel-en wrote:

> Hi.
>
> Is gitlab on cvs machine used by anyone for anything? It only eats
> resources otherwise.
>

I'm still having some ideas to setup it for merge request workflows.

you can stop the containers for now, don't remove the data.



From baggins at pld-linux.org  Fri Apr  8 09:01:01 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 8 Apr 2022 09:01:01 +0200
Subject: Problem with qscintilla/Qt5 linking(?)
Message-ID: <Yk/drckgS81EDSb1@starbug.lan>


Python 3.10.4 (main, Apr  1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5 import Qsci
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter

As far as I can see the symbol is there, recompiling qscintilla2 does
not fix it.

Could someone more versed in the linker(?) take a look at it?

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Fri Apr  8 09:53:22 2022
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 8 Apr 2022 09:53:22 +0200
Subject: Problem with qscintilla/Qt5 linking(?)
In-Reply-To: <Yk/drckgS81EDSb1@starbug.lan>
References: <Yk/drckgS81EDSb1@starbug.lan>
Message-ID: <20220408075322.74avcxvplbwi46bt@pine.grzadka>

On 08.04.2022 09:01, Jan R?korajski wrote:
> 
> Python 3.10.4 (main, Apr  1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from PyQt5 import Qsci
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter
> 
> As far as I can see the symbol is there, recompiling qscintilla2 does
> not fix it.
> 
> Could someone more versed in the linker(?) take a look at it?

Unfortunately it has not much to do with linking, but rather with qmake.

Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
module, that's the reason for undefined symbol:

x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o  -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5 /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread

I guess linking to libqscintilla2_qt5.so should come from:

Python/configure.py:
qmake = {'CONFIG': 'qscintilla2'...

but perhaps due to the way we build python module it can't find newly built qscintilla2? No idea.

A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system config.


From atler at pld-linux.org  Fri Apr  8 12:01:02 2022
From: atler at pld-linux.org (Jan Palus)
Date: Fri, 8 Apr 2022 12:01:02 +0200
Subject: Problem with qscintilla/Qt5 linking(?)
In-Reply-To: <20220408075322.74avcxvplbwi46bt@pine.grzadka>
References: <Yk/drckgS81EDSb1@starbug.lan>
 <20220408075322.74avcxvplbwi46bt@pine.grzadka>
Message-ID: <20220408100102.bll3zjtk6mztz6vf@pine.grzadka>

On 08.04.2022 09:53, Jan Palus wrote:
> On 08.04.2022 09:01, Jan R?korajski wrote:
> > 
> > Python 3.10.4 (main, Apr  1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from PyQt5 import Qsci
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter
> > 
> > As far as I can see the symbol is there, recompiling qscintilla2 does
> > not fix it.
> > 
> > Could someone more versed in the linker(?) take a look at it?
> 
> Unfortunately it has not much to do with linking, but rather with qmake.
> 
> Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> module, that's the reason for undefined symbol:
> 
> x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o  -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5 /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> 
> I guess linking to libqscintilla2_qt5.so should come from:
> 
> Python/configure.py:
> qmake = {'CONFIG': 'qscintilla2'...
> 
> but perhaps due to the way we build python module it can't find newly built qscintilla2? No idea.
> 
> A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system config.

Fixed in 2.11.6-2.


From baggins at pld-linux.org  Sat Apr  9 10:57:48 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 9 Apr 2022 10:57:48 +0200
Subject: Problem with qscintilla/Qt5 linking(?)
In-Reply-To: <20220408100102.bll3zjtk6mztz6vf@pine.grzadka>
References: <Yk/drckgS81EDSb1@starbug.lan>
 <20220408075322.74avcxvplbwi46bt@pine.grzadka>
 <20220408100102.bll3zjtk6mztz6vf@pine.grzadka>
Message-ID: <YlFKjD1sjqwUddKX@starbug.lan>

On Fri, 08 Apr 2022, Jan Palus wrote:

> On 08.04.2022 09:53, Jan Palus wrote:
> > On 08.04.2022 09:01, Jan R?korajski wrote:
> > > 
> > > Python 3.10.4 (main, Apr  1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> from PyQt5 import Qsci
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in <module>
> > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter
> > > 
> > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > not fix it.
> > > 
> > > Could someone more versed in the linker(?) take a look at it?
> > 
> > Unfortunately it has not much to do with linking, but rather with qmake.
> > 
> > Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> > module, that's the reason for undefined symbol:
> > 
> > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o  -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5 /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> > 
> > I guess linking to libqscintilla2_qt5.so should come from:
> > 
> > Python/configure.py:
> > qmake = {'CONFIG': 'qscintilla2'...
> > 
> > but perhaps due to the way we build python module it can't find newly built qscintilla2? No idea.
> > 
> > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system config.
> 
> Fixed in 2.11.6-2.

Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
catch it's missing.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From atler at pld-linux.org  Sat Apr  9 11:13:17 2022
From: atler at pld-linux.org (Jan Palus)
Date: Sat, 9 Apr 2022 11:13:17 +0200
Subject: Problem with qscintilla/Qt5 linking(?)
In-Reply-To: <YlFKjD1sjqwUddKX@starbug.lan>
References: <Yk/drckgS81EDSb1@starbug.lan>
 <20220408075322.74avcxvplbwi46bt@pine.grzadka>
 <20220408100102.bll3zjtk6mztz6vf@pine.grzadka>
 <YlFKjD1sjqwUddKX@starbug.lan>
Message-ID: <20220409091317.q3msapqeo7bzziix@pine>

On 09.04.2022 10:57, Jan R?korajski wrote:
> On Fri, 08 Apr 2022, Jan Palus wrote:
> 
> > On 08.04.2022 09:53, Jan Palus wrote:
> > > On 08.04.2022 09:01, Jan R?korajski wrote:
> > > > 
> > > > Python 3.10.4 (main, Apr  1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)] on linux
> > > > Type "help", "copyright", "credits" or "license" for more information.
> > > > >>> from PyQt5 import Qsci
> > > > Traceback (most recent call last):
> > > >   File "<stdin>", line 1, in <module>
> > > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined symbol: _ZTI11QsciPrinter
> > > > 
> > > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > > not fix it.
> > > > 
> > > > Could someone more versed in the linker(?) take a look at it?
> > > 
> > > Unfortunately it has not much to do with linking, but rather with qmake.
> > > 
> > > Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> > > module, that's the reason for undefined symbol:
> > > 
> > > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o  -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5 /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> > > 
> > > I guess linking to libqscintilla2_qt5.so should come from:
> > > 
> > > Python/configure.py:
> > > qmake = {'CONFIG': 'qscintilla2'...
> > > 
> > > but perhaps due to the way we build python module it can't find newly built qscintilla2? No idea.
> > > 
> > > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system config.
> > 
> > Fixed in 2.11.6-2.
> 
> Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
> catch it's missing.

One reason for sure is that we don't consider files not matching *.so.*
glob:

    printf "Searching for shared objects with unresolved symbols..."; \
    for f in $(find $RPM_BUILD_ROOT -type f -name '*.so.*' -print);

and the other reason is likely related to why we don't consider *.so --
these are usually plugins which happen to have plenty of unresolved
symbols which are only resolved at runtime (provided by "loader"). Like
ie python binary extensions which are rarely linked to libpython and
hence would require special handling.


From baggins at pld-linux.org  Sun Apr 17 11:23:32 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 17 Apr 2022 11:23:32 +0200
Subject: Please follow up on your library updates
Message-ID: <YlvclJ/T1JHnb/VL@starbug>

Please check http://ep09.pld-linux.org/~pldth/main-ready-test.txt after
upgrading a library that includes soname change and update packages
with dependencies broken by library upgrade.

I'm more and more inclined to either plain delete packages with broken
dependencies or delete and revert upgaded library, depending on impact.

I'm fed up cleaning up every time someone decides it's fine to upgrade a
library that leaves a lot of packages stranded.

Sincerely,
Your Th maintainer.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From qboosh at pld-linux.org  Mon Apr 18 20:29:27 2022
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 18 Apr 2022 20:29:27 +0200
Subject: python (3.10) dirs
Message-ID: <20220418182927.GA26996@stranger.qboosh.pl>

After recent python3.10 changes meson started to use /usr/share for
purelib, but automake's pythondir is broken now:

pythondir (platform-indepdendent) is wrong:

$ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
/usr/share/python2.7/site-packages

$ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
/usr/lib/python3.10/site-packages

pyexecdir is OK:

$ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
/usr/lib64/python2.7/site-packages

$ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
/usr/lib64/python3.10/site-packages


-- 
Jakub Bogusz    http://qboosh.pl/


From baggins at pld-linux.org  Tue Apr 19 00:26:59 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 19 Apr 2022 00:26:59 +0200
Subject: python (3.10) dirs
In-Reply-To: <20220418182927.GA26996@stranger.qboosh.pl>
References: <20220418182927.GA26996@stranger.qboosh.pl>
Message-ID: <Yl3lsx9KMPfdW7aX@tachikoma.lan>

On Mon, 18 Apr 2022, Jakub Bogusz wrote:

> After recent python3.10 changes meson started to use /usr/share for
> purelib, but automake's pythondir is broken now:
> 
> pythondir (platform-indepdendent) is wrong:
> 
> $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> /usr/share/python2.7/site-packages
> 
> $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> /usr/lib/python3.10/site-packages
> 
> pyexecdir is OK:
> 
> $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> /usr/lib64/python2.7/site-packages
> 
> $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> /usr/lib64/python3.10/site-packages

What package version do you have? Python3 shows /usr/share for me:

$ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3
<string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
<string>:1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
/usr/share/python3.10/site-packages
python3-3.10.4-5.x86_64

On a side note, distutils is deprecated...

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From baggins at pld-linux.org  Tue Apr 19 01:56:04 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 19 Apr 2022 01:56:04 +0200
Subject: python (3.10) dirs
In-Reply-To: <Yl3lsx9KMPfdW7aX@tachikoma.lan>
References: <20220418182927.GA26996@stranger.qboosh.pl>
 <Yl3lsx9KMPfdW7aX@tachikoma.lan>
Message-ID: <Yl36lCSfri2eUVqd@tachikoma.lan>

On Tue, 19 Apr 2022, Jan R?korajski wrote:

> On Mon, 18 Apr 2022, Jakub Bogusz wrote:
> 
> > After recent python3.10 changes meson started to use /usr/share for
> > purelib, but automake's pythondir is broken now:
> > 
> > pythondir (platform-indepdendent) is wrong:
> > 
> > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > /usr/share/python2.7/site-packages
> > 
> > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > /usr/lib/python3.10/site-packages
> > 
> > pyexecdir is OK:
> > 
> > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > /usr/lib64/python2.7/site-packages
> > 
> > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > /usr/lib64/python3.10/site-packages
> 
> What package version do you have? Python3 shows /usr/share for me:
> 
> $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3
> <string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
> <string>:1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
> /usr/share/python3.10/site-packages
> python3-3.10.4-5.x86_64
> 
> On a side note, distutils is deprecated...

The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth
from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From qboosh at pld-linux.org  Tue Apr 26 21:38:30 2022
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 26 Apr 2022 21:38:30 +0200
Subject: python (3.10) dirs
In-Reply-To: <Yl36lCSfri2eUVqd@tachikoma.lan>
References: <20220418182927.GA26996@stranger.qboosh.pl>
 <Yl3lsx9KMPfdW7aX@tachikoma.lan> <Yl36lCSfri2eUVqd@tachikoma.lan>
Message-ID: <20220426193830.GA21122@mail>

On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan R?korajski wrote:
> On Tue, 19 Apr 2022, Jan R?korajski wrote:
> 
> > On Mon, 18 Apr 2022, Jakub Bogusz wrote:
> > 
> > > After recent python3.10 changes meson started to use /usr/share for
> > > purelib, but automake's pythondir is broken now:
> > > 
> > > pythondir (platform-indepdendent) is wrong:
> > > 
> > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > /usr/share/python2.7/site-packages
> > > 
> > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > /usr/lib/python3.10/site-packages
> > > 
> > > pyexecdir is OK:
> > > 
> > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > /usr/lib64/python2.7/site-packages
> > > 
> > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > /usr/lib64/python3.10/site-packages
> > 
> > What package version do you have? Python3 shows /usr/share for me:
> > 
> > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3
> > <string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
> > <string>:1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
> > /usr/share/python3.10/site-packages
> > python3-3.10.4-5.x86_64
> > 
> > On a side note, distutils is deprecated...
> 
> The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth
> from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there.

It's automake's standard AM_PATH_PYTHON that refers to distutils.

Maybe we should rework revert-debian-python-hacks.patch ...


-- 
Jakub Bogusz    http://qboosh.pl/


From baggins at pld-linux.org  Tue Apr 26 23:29:48 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 26 Apr 2022 23:29:48 +0200
Subject: python (3.10) dirs
In-Reply-To: <20220426193830.GA21122@mail>
References: <20220418182927.GA26996@stranger.qboosh.pl>
 <Yl3lsx9KMPfdW7aX@tachikoma.lan> <Yl36lCSfri2eUVqd@tachikoma.lan>
 <20220426193830.GA21122@mail>
Message-ID: <YmhkTM/OPjcjFkUq@tachikoma.lan>

On Tue, 26 Apr 2022, Jakub Bogusz wrote:

> On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan R?korajski wrote:
> > On Tue, 19 Apr 2022, Jan R?korajski wrote:
> > 
> > > On Mon, 18 Apr 2022, Jakub Bogusz wrote:
> > > 
> > > > After recent python3.10 changes meson started to use /usr/share for
> > > > purelib, but automake's pythondir is broken now:
> > > > 
> > > > pythondir (platform-indepdendent) is wrong:
> > > > 
> > > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > > /usr/share/python2.7/site-packages
> > > > 
> > > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > > /usr/lib/python3.10/site-packages
> > > > 
> > > > pyexecdir is OK:
> > > > 
> > > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > > /usr/lib64/python2.7/site-packages
> > > > 
> > > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > > /usr/lib64/python3.10/site-packages
> > > 
> > > What package version do you have? Python3 shows /usr/share for me:
> > > 
> > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3
> > > <string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
> > > <string>:1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
> > > /usr/share/python3.10/site-packages
> > > python3-3.10.4-5.x86_64
> > > 
> > > On a side note, distutils is deprecated...
> > 
> > The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth
> > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there.
> 
> It's automake's standard AM_PATH_PYTHON that refers to distutils.
> 
> Maybe we should rework revert-debian-python-hacks.patch ...

Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From baggins at pld-linux.org  Tue Apr 26 23:31:55 2022
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 26 Apr 2022 23:31:55 +0200
Subject: python (3.10) dirs
In-Reply-To: <YmhkTM/OPjcjFkUq@tachikoma.lan>
References: <20220418182927.GA26996@stranger.qboosh.pl>
 <Yl3lsx9KMPfdW7aX@tachikoma.lan> <Yl36lCSfri2eUVqd@tachikoma.lan>
 <20220426193830.GA21122@mail> <YmhkTM/OPjcjFkUq@tachikoma.lan>
Message-ID: <Ymhky6u6l9HWOa7o@tachikoma.lan>

On Tue, 26 Apr 2022, Jan R?korajski wrote:

> On Tue, 26 Apr 2022, Jakub Bogusz wrote:
> 
> > On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan R?korajski wrote:
> > > On Tue, 19 Apr 2022, Jan R?korajski wrote:
> > > 
> > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote:
> > > > 
> > > > > After recent python3.10 changes meson started to use /usr/share for
> > > > > purelib, but automake's pythondir is broken now:
> > > > > 
> > > > > pythondir (platform-indepdendent) is wrong:
> > > > > 
> > > > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > > > /usr/share/python2.7/site-packages
> > > > > 
> > > > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))"
> > > > > /usr/lib/python3.10/site-packages
> > > > > 
> > > > > pyexecdir is OK:
> > > > > 
> > > > > $ python2 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > > > /usr/lib64/python2.7/site-packages
> > > > > 
> > > > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))"
> > > > > /usr/lib64/python3.10/site-packages
> > > > 
> > > > What package version do you have? Python3 shows /usr/share for me:
> > > > 
> > > > $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3
> > > > <string>:1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
> > > > <string>:1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
> > > > /usr/share/python3.10/site-packages
> > > > python3-3.10.4-5.x86_64
> > > > 
> > > > On a side note, distutils is deprecated...
> > > 
> > > The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth
> > > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there.
> > 
> > It's automake's standard AM_PATH_PYTHON that refers to distutils.
> > 
> > Maybe we should rework revert-debian-python-hacks.patch ...
> 
> Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner

More to the point, python3 has all paths as we want them, but if you install
python3-setuptool it will override stdlib sysconfig with its own
implementation. And that was what was broken.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at pld-linux.org  Thu Apr 28 21:14:31 2022
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 28 Apr 2022 22:14:31 +0300
Subject: [packages/systemd] pass args from
 %systemd_service_{enable,disable} to %systemd_{post,preun}; rel 2
In-Reply-To: <1820298a2883170393ed481ce681e66198884809_refs_heads_master@pld-linux.org>
References: <fb7161037fde715d7c2ac504960271bdf15beeaa_refs_heads_master@pld-linux.org>
 <1820298a2883170393ed481ce681e66198884809_refs_heads_master@pld-linux.org>
Message-ID: <f59c1108-b6e5-225a-242f-c508bd1cb7e5@pld-linux.org>


On 26.04.2022 21:02, atler wrote:
> commit 1820298a2883170393ed481ce681e66198884809
> Author: Jan Palus <atler at pld-linux.org>
> Date:   Tue Apr 26 20:01:38 2022 +0200
>
>      pass args from %systemd_service_{enable,disable} to %systemd_{post,preun}; rel 2
>
>   rpm-macros.patch | 4 ++--
>   systemd.spec     | 2 +-
>   2 files changed, 3 insertions(+), 3 deletions(-)
> ---
> diff --git a/systemd.spec b/systemd.spec
> index a703c84..2c61be6 100644
> --- a/systemd.spec
> +++ b/systemd.spec
> @@ -29,7 +29,7 @@ Summary(pl.UTF-8):	systemd - zarz?dca systemu i us?ug dla Linuksa
>   Name:		systemd
>   # Verify ChangeLog and NEWS when updating (since there are incompatible/breaking changes very often)
>   Version:	250.4
> -Release:	1
> +Release:	2
>   Epoch:		1
>   License:	GPL v2+ (udev), LGPL v2.1+ (the rest)
>   Group:		Base
> diff --git a/rpm-macros.patch b/rpm-macros.patch
> index 6926763..43dd90d 100644
> --- a/rpm-macros.patch
> +++ b/rpm-macros.patch
> @@ -66,8 +66,8 @@
>   +		{{SYSTEMD_UPDATE_HELPER_PATH}} system-reload || : \
>   +%{nil}
>   +
> -+%systemd_service_enable %systemd_post
> -+%systemd_service_disable %systemd_preun
> ++%systemd_service_enable() %systemd_post $*
> ++%systemd_service_disable() %systemd_preun $*
>   +
>   +%systemd_service_start() \
>   +	[ -d /run/systemd/system ] && /bin/systemctl start %{*} || : \
> ================================================================


shouldn't you use rpm args, %{*},? rather shell args, $* like 
%systemd_service_start()?

also when using shell args, always use "$@" to preserve spaces