Avoiding the automatic /usr/bin/python3 dep
by Richard Hughes
Hi all,
In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and
other people working with low level firmware blobs. In
https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was
suggested we split them off as a subpackage to avoid the
/usr/bin/python3 dep which is unwanted on CoreOS. It does seem a bit
crazy to split off a subpackage when the rpm header will be bigger
than the contents. Given these are such small files and certainly not
warranting dragging python3 onto the image, I did hope I could use
%{?python_disable_dependency_generator} to tell rpmbuild to basically
ignore the .py files and not add a /usr/bin/python3 dep on my package
automatically. Unfortunately that seems not to work. Ideas welcome,
thanks!
Richard.
3 years, 10 months
Fedora 33 Self-Contained Change proposal: Deprecate python-pytoml
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DeprecatePytoml
== Summary ==
The {{package|python-pytoml}} ({{package|python3-pytoml}}) package
will be [https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated] in [[Releases/33|Fedora 33]]. Pytoml is deprecated
upstream in favor of [https://pypi.org/project/toml/ toml]
({{package|python-toml}}), but existing Fedora packages depend on it,
so we cannot remove it yet. Packagers are encouraged to work with
upstream to switch to {{package|python-toml}}, but
{{package|python-pytoml}} remains available until it is a leaf
package, it will be removed then (possibly not yet in Fedora 33).
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python-pytoml}} package is
[https://pypi.org/project/pytoml/ deprecated upstream]:
> The pytoml project is no longer being actively maintained. Consider using the [https://pypi.org/project/toml/ toml] package instead.
We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require {{package|python3-pytoml}}, hence we want
to have it [https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated].
Packagers are encouraged to switch to {{package|python3-toml}} with
upstream involvement. Downstream patches to switch from pytoml to toml
are not encouraged.
Note that <code>repoquery</code> gives many packages that BuildRequire
{{package|python3-toml}}:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-pytoml
ilua-0:0.2.1-1.fc33.src
pyproject-rpm-macros-0:0-15.fc33.noarch
pyproject-rpm-macros-0:0-15.fc33.src
python-black-0:19.10~b0-3.fc33.src
python-chaospy-0:3.2.12-1.fc33.src
python-copr-0:1.102-1.fc33.src
python-decopatch-0:1.4.6-3.fc33.src
python-elementpath-0:1.4.0-4.fc33.src
python-flit-0:2.3.0-3.fc33.src
python-latexcodec-0:2.0.1-1.fc33.src
python-makefun-0:1.6.11-3.fc33.src
python-numpoly-0:0.2.3-2.fc33.src
python-openqa_client-0:4.1.0-2.fc33.src
python-pint-0:0.13-1.fc33~bootstrap.src
python-pybtex-docutils-0:0.2.2-4.fc33.src
python-pytest-cases-0:1.11.1-3.fc33.src
python-pytest-harvest-0:1.7.2-3.fc33.src
python-pytest-steps-0:1.7.2-2.fc33.src
python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
python-requests-download-0:0.1.2-3.fc33.src
python-sphinx-copybutton-0:0.2.12-1.fc33.src
python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
python-wikitcms-0:2.6.3-2.fc33.src
python-xmlschema-0:1.0.18-3.fc33.src
python-xmlsec-0:1.3.8-1.fc33.src
python3-flit-0:2.3.0-3.fc33.noarch
python3-flit-core-0:2.3.0-3.fc33.noarch
But many of them are only there because the dependency was generated
by {{package|pyproject-rpm-macros}} BuildRequires generator which was
since already updated to use {{package|python3-toml}}. When rebuilt
with updated {{package|pyproject-rpm-macros}}, the dependency will be
replaced with {{package|python3-toml}}.
$ repoquery --repo=rawhide{,-source} --whatrequires pyproject-rpm-macros
ansible-lint-0:4.2.0-4.fc33.src
ilua-0:0.2.1-1.fc33.src
python-PyGithub-0:1.51-2.fc33.src
python-black-0:19.10~b0-3.fc33.src
python-chaospy-0:3.2.12-1.fc33.src
python-copr-0:1.102-1.fc33.src
python-decopatch-0:1.4.6-3.fc33.src
python-elementpath-0:1.4.0-4.fc33.src
python-latexcodec-0:2.0.1-1.fc33.src
python-makefun-0:1.6.11-3.fc33.src
python-numpoly-0:0.2.3-2.fc33.src
python-openqa_client-0:4.1.0-2.fc33.src
python-pep517-0:0.7.0-4.fc33.src
python-pint-0:0.13-1.fc33~bootstrap.src
python-pybtex-docutils-0:0.2.2-4.fc33.src
python-pytest-cases-0:1.11.1-3.fc33.src
python-pytest-harvest-0:1.7.2-3.fc33.src
python-pytest-steps-0:1.7.2-2.fc33.src
python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
python-requests-download-0:0.1.2-3.fc33.src
python-sphinx-copybutton-0:0.2.12-1.fc33.src
python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
python-tox-current-env-0:0.0.2-5.fc33.src
python-wikitcms-0:2.6.3-2.fc33.src
python-xmlschema-0:1.0.18-3.fc33.src
python-xmlsec-0:1.3.8-1.fc33.src
The only really affected package is {{package|python-flit}}. Upstream
already discusses the transition:
https://github.com/takluyver/flit/issues/255
Once all dependencies are removed, we plan to retire
{{package|python-pytoml}}, whether it will be in Fedora 33 or later.
== Feedback ==
The intent was announced at
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
but there was no feedback. The primary point of contact for the
{{package|python-pytoml}} and {{package|python-toml}} packages is on
board.
== Benefit to Fedora ==
An upstream deprecated package will not be depended upon by new packages.
== Scope ==
* Proposal owners: Deprecate {{package|python3-pytoml}}. Work with
flit upstream to make the transition as well. Once the dependency is
removed from flit, rebuild remaining packages using
{{package|pyproject-rpm-macros}} and retire {{package|python-pytoml}}
(possibly later than Fedora 33).
* Other developers: No action needed. Don't add new dependencies on
{{package|python3-pytoml}}.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
The package will remain available. Only new packages cannot depend on it.
Once retired, we don't plan to provide <code>python3-pytoml</code>
from {{package|python3-toml}}, because it cannot work as drop-in
replacement (the Python module has a different name). The package will
eventually be obsoleted by {{package|fedora-obsolete-packages}} once
Python is updated to 3.10 to avoid broken upgrades.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-pytoml
...
deprecated()
...
== User Experience ==
No changes.
== Dependencies ==
N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Default editor for LXQt spin
by Raphael Groner
Hi,
writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun.
Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream.
@lupinix Could you remove lxqt-sig from the members in pagure?
Regards, Raphael
3 years, 10 months
Intent to orphan jbig2dec EPEL branch(es)
by Michael J Gruber
Hi there
I intend to orphan the EPEL branches which I'm maintaining.
In fact: "I'm maintaining" is an exaggeration. The EPEL requirements simply do not match my time constraints as soon as EPEL gets behind maintained Fedora versions. For upstreams without any maintenance branches nor ABI stability (Artifex type ...) this leads to an amount of backporting (or ignoring of EPEL criteria) which I cannot handle responsibly.
With the current infra I don't even know how to find branch ownerships proper (the EPEL field in src apparantly is useless, apps is down) but here's my packages:
https://src.fedoraproject.org/user/mjg
And I think the only one left with an EPEL branch (for me) is jbig2dec.
The EPEL7 branch is getting a pile of automatic bug reports (for bugs long fixed in maintained Fedora releases).
The EPEL8 branch was supposed to come one day but RHEL shipped half of the package which did not help progress.
3 years, 10 months
Heads up - %configure and %cmake changes affecting MPI packages
by Orion Poplawski
This change in redhat-rpm-config:
* Wed Jun 03 2020 Igor Raits <ignatenkobrain(a)fedoraproject.org> - 158-1
- Add option to choose C/C++ toolchain
changed %_set_build_flags to also set the CC/CXX compiler variables:
CC=%{__cc}; export CC ; \
CXX=%{__cxx}; export CXX ; \
This breaks the relatively common construct for building MPI versions of
packages:
export CC=mpicc
export CXX=mpicxx
%configure
For %configure you can change to:
%configure CC=mpicc CXX=mpicxx
For %cmake (this will also work with %configure) you'll need to do:
%define __cc mpicc
%define __cxx mpicxx
%cmake
With koschei down (I presume it is due to the move) I think this has
gone mostly unnoticed so far.
HTH,
Orion
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
3 years, 10 months
Fedora 33 Self-Contained Change proposal: No more automagic Python
bytecompilation phase 3
by Ben Cotton
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompi...
== Summary ==
See [[Changes/No_more_automagic_Python_bytecompilation]] and
[[Changes/No_more_automagic_Python_bytecompilation_phase_2]]. Now,
<code>%global _python_bytecompile_extra 1</code> won't be allowed
anymore and raises an error with a link to this change.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
See the [[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of the previous Change Proposal]] and the
[[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of its phase 2]].
Currently, Fedora rawhide contains ~130 packages with `%global
_python_bytecompile_extra 1` in their specfiles but surprisingly only
42 of them actually ship any .pyc files outside the standard location
<code>/usr/lib(64)?/python[0-9]\.[0-9]+</code>. That might be caused
by either of the following:
* there is nothing to byte-compile — the statement is a leftover to be removed
* The automagic bytecompilation uses <code>/usr/bin/python</code> by
default (for historical reasons) but <code>/usr/bin/python</code> is
not present in the buildroot by default.
Our plan is to finish the announced removal of this automagic Python
bytecompilation, remove it from packages where it's not necessary and
fix it with <code>%py_byte_compile</code> for packages where it's
needed.
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix...
documentation] already contains the following paragraph:
If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/
directories and you require those files to be byte compiled (e.g. it’s
an importable Python module) you MUST compile them explicitly using
the %py_byte_compile macro. Note that not all Python files are
importable Python modules; when in doubt, grep the sources for the
appropriate import statement.
so no changes have to be made there.
=== Affected packages ===
From 2020-05-20.
bugzilla
calamares
ceph
chromium
cinnamon-screensaver
edk2
eog-plugins
fish
fleet-commander-admin
fleet-commander-client
freecad
gaupol
gazebo
gdb
gedit
gedit-latex
gedit-plugins
git-cola
glusterfs
gnome-code-assistance
gnome-devel-docs
grass
gtk-doc
gtranslator
ibus
ibus-anthy
ibus-hangul
ibus-libpinyin
ibus-libzhuyin
ibus-pinyin
ibus-table
ibus-typing-booster
ibus-uniemoji
insight
kajongg
kdevelop-python
klatexformula
libpeas
libreoffice
libsmbios
libunity
lirc
lyx
mate-menu
mingw-glib2
mirrormanager2
odcs
onboard
otf2
paraview
pcs
php-opencloud-openstack
pygobject2
pygtk2
python-cherrypy
python-flask-silk
python-genshi
python-pycurl
python-reportlab
qpid-dispatch
rhythmbox
sems
sigul
soundconverter
sugar
sugar-abacus
sugar-browse
sugar-calculator
sugar-castle
sugar-chat
sugar-clock
sugar-colordeducto
sugar-countries
sugar-deducto
sugar-distance
sugar-finance
sugar-flip
sugar-flipsticks
sugar-fototoon
sugar-fractionbounce
sugar-getiabooks
sugar-imageviewer
sugar-implode
sugar-infoslicer
sugar-jukebox
sugar-kuku
sugar-labyrinth
sugar-locosugar
sugar-log
sugar-maze
sugar-measure
sugar-memorize
sugar-moon
sugar-nutrition
sugar-paint
sugar-physics
sugar-pippy
sugar-playgo
sugar-portfolio
sugar-pukllanapac
sugar-read
sugar-recall
sugar-record
sugar-ruler
sugar-speak
sugar-srilanka
sugar-starchart
sugar-stopwatch
sugar-story
sugar-terminal
sugar-turtleart
sugar-typing-turtle
sugar-view-slides
sugar-visualmatch
sugar-words
sugar-write
sugar-xoeditor
sugar-xoirc
sugar-yupana
synfigstudio
system-config-repo
system-switch-java
system-switch-mail
texlive
totem
transmageddon
ufw-kde
variety
virt-manager
vtk
xed
== Benefit to Fedora ==
More explicit specfiles when it comes to Python byte compilation. This
change also supports the dropping of unversioned
<code>%{__python}</code> macro.
== Scope ==
* Proposal owners: Change the brp-python-bytecompile script and macros
in redhat-rpm-config package, help with transforming the packages. See
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/87
* Other developers: Maintainers of the mentioned python packages will
have to change their packages to use explicit
<code>%py_byte_compile</code>
* Release engineering: No Release engineering work is needed for this change
* Policies and guidelines: nothing to be changed
* Trademark approval: not needed
== Upgrade/compatibility impact ==
None expected.
== How To Test ==
Build a package with <code>%global _python_bytecompile_extra 1</code>.
The build should fail with an actionable error message.
== User Experience ==
The users of this change are packagers. The new behavior should make
byte-compilation more obvious, explicit, and discoverable.
Users of Fedora should not feel this (except if this change uncovers a
packaging bug).
== Contingency Plan ==
* Contingency mechanism: revert the changes in redhat-rpm-config
* Contingency deadline: none (not a System Wide Change)
* Blocks release? no (not a System Wide Change)
* Blocks product? no
== Documentation ==
The guidelines already contain up-to-date documentation.
== Release Notes ==
This change does not deserve Release Notes, it is not user-facing.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Schedule for Wednesday's FESCo Meeting (2020-06-24)
by Igor Raits
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2020-06-24 14:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
F33 System-Wide Change: Aarch64 Pointer Authentication & Branch Target
Enablement
https://pagure.io/fesco/issue/2403
APPROVED (+6, 0, -0)
New FESCo rep to Fedora Council needed
https://pagure.io/fesco/issue/2405
dcantrell willl be a new representative (+9, 0, -0)
F33 System-Wide Change: swap on zram
https://pagure.io/fesco/issue/2408
APPROVED (+7, 0, -0)
= Followups =
#topic #2390 Request to permit module default streams in ELN
https://pagure.io/fesco/issue/2390
#topic #2407 Find a new meeting time slot
https://pagure.io/fesco/issue/2407
= New business =
#topic #2409 F33 System-Wide Change: CompilerPolicy Change
https://pagure.io/fesco/issue/2409
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7yPJgACgkQEV1auJxc
Hh4sPA//em6sOv4mugq2qEcya409mXHp6Q19yWMp44rYjyeAgVv/TZzQceol2IxG
mEMfLpI8qsE1COyP7+IOBVqmfHhpBNVN0Fjy7hCnpcWfRiiRqgN4ZYva5eZIQdI3
YJKQe1Uh2/wrJZcplaP8aa7tDL4KlV7zDd3IvULRle1TBtYGU3byTCYxHeXmj3ou
ldKL86tpcc6Vyk3eh1qb4iiwEvKDOvQT1WRLYq7wUxlj6DIofvrNxwsNcs8JEr9x
kv2JhRxtwyI2qxgc+mHshYNg+DD/pZiotkNjJSUeRzfNUxo+jP8VV9V4TogfMMR/
d8XKx64QfpkGFggeHPU5vOJMc3VL1hVJUu7QPbqh+eDXt7/H9IpGxlAzipYHdf1X
blwFYttl0ng8RqrVuzFONGcic0UF+SSW5cSC88mGd/VxIUZ7UwXmSSh8E0LV9fNF
dvGo5cY4IFUsssxuI/gGvPE2y6XlNH/Fptb+TZKaC/xPNB8F6qUUBqAVFxDUCrC8
KTr301JqK5rgVzF+dlJalOI62uj1hLyIcfFjSQLUM63KbLvo/FXfBenu9efG5FIm
Uh3g/9p9ungJvJX+BI/0LHVx0aBN/oRFfxcJ3NjfoeUESj9dOF5QujXXyNPFqKXV
ssS6fnnuIGfO52ozB7396CxRfP7jUKEm7lsrHuraTiU2vFoBksU=
=G87X
-----END PGP SIGNATURE-----
3 years, 10 months
protobuf update coming to rawhide
by Adrian Reber
I prepared a protobuf update for rawhide to 3.12. It requires a rebuild
of all dependencies and of the 55 dependencies currently 10 fail to
rebuild. The following packages are failing:
clementine
closure-compiler
fawkes
gazebo
hidviz
kismet
libgadu
mir
mozc
pokerth
and the failures do not seem to be protobuf related. See
https://copr.fedorainfracloud.org/coprs/adrian/protobuf-3-12/
I requested a side-tag to do the rebuilds.
Adrian
3 years, 10 months
Fedora 33 System-Wide Change proposal: Use %make_build and
%make_install macros
by Ben Cotton
https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
== Summary ==
This change will update all spec files in Fedora that use make and replace
the make invocations with either the %make_build or %make_install macros.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The goal of this change is to standardize the usage of make in Fedora. All
make invocations in spec files that don't use the install target will be
modified to use the %make_build macro, and all make invocations that use
the install target will be updated to use the %make_install macro. Any
additional arguments to make that are not included in either the
%make_build and %make_install will be preserved.
The %make_build macro enables parallel make builds using the -j option. In
case a package does not build correctly with parallel make, then parallel
make will be disabled for that package by redefining the %_smp_mflags macro
like this:
%global _smp_mflags -j1
All changes will be submitted to dist-git repositories via pull requests.
Pull requests will be merged after 1 week if there are no objections or
earlier if approved by the package maintainers.
A script will be used to apply the necessary changes to the spec files, and
the result will be manually inspected before being merged.
All packages updated by this change request will be rebuilt after the spec
file changes are merged.
Some packages already use the %make_build and %make_install macros. These
packages will be left unchanged.
== Benefit to Fedora ==
* Reduced build times: Using the %make_build macros enables parallel make
builds which will reduce build times for Fedora packages.
* This will make it easier to enforce consistent build flag usage across
all of Fedora.
== Scope ==
* Proposal owners: Update spec files and submit pull requests and do new
package builds. Optional: Merge pull requests (Proposal Owner would need
to request to be added to provenpackagers group)
* Other developers: Package owners may merge pull requests and submit new
builds if they want, but this is not required for them. A member of the
provenpackagers group will be needed to merge pull requests.
* Release engineering: [https://pagure.io/releng/issues/9533 #9533]
* Policies and guidelines: Package guidelines already specify that packages
should use these macros when possible. Documentation will be updated to
clarify that %make_build should be used for all make invocations (besides
make install), and also with instructions for packages that fail to build
with parallel make.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
End-users will not notice any changes.
== Dependencies ==
No real dependencies, each package can be updated independently.
== Contingency Plan ==
* Contingency mechanism: None. If not all packages are updated in time,
then the work can continue into the next release.
* Contingency deadline: All work will be done in the rawhide branch, and
will not be backported into the f33 branch once it is created, so whatever
gets done before the branch date will make it into the release.
* Blocks release? No
== Documentation ==
The packaging guidelines will be updated as described in the Scope Section.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
