Setting to depends on PYTHON37.

"This change will be done after the switch to Python 3.7 to avoid work on one change from interfering with work on the other."

Prepared in https://src.fedoraproject.org/rpms/python2/pull-request/20

Build in progress https://koji.fedoraproject.org/koji/taskinfo?taskID=28001290

218 packages list one of the following in %files:

%{python_sitearch}/*

%{python_sitelib}/*


Unfortunately, both statements currently evaluate to /*.

I think we should mass patch those, as this is a kind of error that passes silently. Thoughts?

Are they actually defined to empty, or are they just undefined? I always thought any undefined macros are not replaced, leading to a non-absolute path, and consequently an error from rpm…

+1 to mass patching, though, as usual ;)

They are basically defined to undefined:

(I know this is bash, but it behaves similarly here)

$ value=$(nonexisting command is here)
bash: nonexisting: command not found
$ echo "$value"
(empty)

Also, plenty of those use python or %__python and will fail to build.

So I'd only patch 42 that don't:

abiword
afflib
cwiid
denyhosts
did
dtc
gitosis
gr-air-modes
gr-fcdproplus
gr-iqbal
gr-osmosdr
gtts
langtable
libdasm
libpfm
mathgl
player
pocketsphinx
pyserial
python-alsaaudio
python-ansi
python-anyconfig
python-atomicwrites
python-bottle
python-guppy
python-lyricwiki
python-nitrate
python-openoffice
python-optcomplete
python-ordered-set
python-pygraphviz
python-pylcdsysinfo
python-pymilter
python-repoze-tm2
python-trml2pdf12
python-vkontakte
python-xmpp
python-yenc
stgit
sugar-datastore
sugar-toolkit
wordxtr

(In reply to Miro Hrončok from comment #7)
> They are basically defined to undefined:
/usr/lib/rpm/macros:%python_sitelib %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper sitelib)
/usr/lib/rpm/macros:%python_sitearch %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper sitearch)

That's ugly. I think we should update those definitions to something like this:
%python_sitelib %{__python} -Es %{_rpmconfigdir}/python-macro-helper sitelib 2>/dev/null || echo %%python_sitelib
%python_sitearch %{__python} -Es %{_rpmconfigdir}/python-macro-helper sitearch 2>/dev/null || echo %%python_sitearch

That would work.

https://github.com/rpm-software-management/rpm/pull/469

FTBFS of python-jnius:

<snip>
BUILD SUCCESSFUL
Total time: 0 seconds
python setup.py build_ext --inplace -f -g
make: python: Command not found

The above output is a result of calling: CFLAGS="$RPM_OPT_FLAGS" %py2_build

https://koji.fedoraproject.org/koji/taskinfo?taskID=28222392
https://github.com/kivy/pyjnius/blob/a7e791aa26c84645c53dac985dd97183071f7bc4/setup.py

Raphael, the above output is a result of calling "make":

https://github.com/kivy/pyjnius/blob/master/Makefile#L20

If you really need to call make, set PYTHON=%{__python2}.

Also note that you don't need to set CFLAGS with %py2_build, the macro does that for you.

Note that I see no reason to call "%py_build" and follow it with "make" that calls python setup.py build_ext, as they both do essentially the same thing.

Raphael, here is a PR https://src.fedoraproject.org/rpms/python-jnius/pull-request/1

(In reply to Zbigniew Jędrzejewski-Szmek from comment #11)
> https://github.com/rpm-software-management/rpm/pull/469

https://src.fedoraproject.org/rpms/rpm/pull-request/14

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

This has happened in F29.