Make the unversioned %{__python} macro error by default - Fedora 33
Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PythonMacroError
== Summary ==
The <code>%{__python}</code> RPM macro (currently defined to
<code>/usr/bin/python</code> for backwards compatibility reasons) will be
defined to raise an error when used. Any derived macros
(<code>%{python}</code>, <code>%{python_version}</code>,
<code>%{python_sitleib}</code> etc.) will propagate the error. Packagers
can redefine the macro to any actual value to suppress the error. This is
consistent with RHEL 8 behavior. Using <code>/usr/bin/python</code> in
Fedora packages remains forbidden.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <mhroncok(a)redhat.com>
== Detailed Description ==
For years, the unversioned <code>/usr/bin/python</code> Python interpreter
MUST not be used when building RPM packages in Fedora. However, for
backwards compatibility reasons, the <code>%{__python}</code> macro was
defined to <code>/usr/bin/python</code>. As a direct consequence, all
derived macros:
* <code>%{python}</code>
* <code>%{python_version}</code>
* <code>%{python_version_nodots}</code>
* <code>%{python_sitelib}</code>
* <code>%{python_sitearch}</code>
* <code>%py_shebang_fix</code>
* <code>%py_build</code> variants
* <code>%py_install</code> variants
used <code>/usr/bin/python</code> as well, unless redefined to custom value
different than <code>/usr/bin/python</code>. Some of the macros
unfortunately evaluated to empty string when <code>/usr/bin/python</code>
was not installed in the buildroot.
We wanted to define <code>%{__python}</code> to an error previously, but
unfortunately, this was not yet possible due to backwards compatibility wrt
automagic byte-compilation. Hence we have done:
* [[Changes/No_more_automagic_Python_bytecompilation]]
* [[Changes/No_more_automagic_Python_bytecompilation_phase_2]]
* [[Changes/No_more_automagic_Python_bytecompilation_phase_3]]
Now, we can define the macro to an error by default. Packagers can still
define it to any custom value.
We will define the macro as follows:
%__python %{error:attempt to use unversioned python, define %%__python to
%{__python2} or %{__python3} explicitly}
This is technically consistent with RHEL 8.
We will also define <code>%{python}</code> to <code>%{__python}</code> (we
will drop the current Lua logic that is designed to prevent
<code>%{python}</code> usage when <code>%{__python}</code> is
<code>/usr/bin/python</code>).
The default behavior will be an error:
$ rpm --eval '%__python'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python_sitelib'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
As advised, when redefined, the macros continue to work as currently:
$ rpm --define '__python %__python3' --eval '%python'
/usr/bin/python3
$ rpm --define '__python %__python3' --eval '%python_version'
3.9
Despite the error message not actually promoting this, packagers can even
explicitly define the macro to <code>/usr/bin/python</code> to mimic the
previous behavior. However, this remains forbidden in Fedora.
$ rpm --define '__python /usr/bin/python' --eval '%python'
/usr/bin/python
$ rpm --define '__python /usr/bin/python' --eval '%python_sitelib'
/usr/lib/python3.9/site-packages
== Feedback ==
* More consistent behavior between RHEL and Fedora.
* Avoids hard to debug mistakes when <code>/usr/bin/python</code> is not
present and macros like <code>%{python_sitelib}</code> are used.
* Doing the wrong thing is not the easiest default any more.
== Scope ==
* Proposal owners:
** Redefine <code>%__python</code> and <code>%python</code>
* Other developers: nothing, AFAIK packages in Fedora already dropped this
construct, however when not, packagers will need to define
<code>%__python</code> in spec to make it work. We believe the error
message is self-explanatory.
* Release engineering: no impact
* Policies and guidelines: Mostly already exist. The [
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros
macro definition] will need to be updated in the Python guidelines to match
reality.
* Trademark approval: not needed
== Upgrade/compatibility impact ==
No user impact. Some spec files might start to fail to build with this
change, but the error is self-explanatory.
== How To Test ==
See examples in Detailed Description.
== User Experience ==
No user impact. Some spec files might start to fail to build with this
change, but the error is self-explanatory.
== Dependencies ==
[[Changes/No_more_automagic_Python_bytecompilation_phase_3]]
== Contingency Plan ==
* Contingency mechanism: the change owners can revert the changes
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
This page is the documentation. The updated [
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros
macro list] will also serve as documentation.
--
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-07-01)
by Clement Verna
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-07-01 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: CMake to do out-of-source builds
https://pagure.io/fesco/issue/2411
APPROVED (+7, 2, -0)
F33 Self-Contained Change: Distribute .repo files for modular repositories
from a separate package
https://pagure.io/fesco/issue/2412
APPROVED (+8, 0, -0)
F33 Self-Contained Change: Default animated background for Fedora
Workstation
https://pagure.io/fesco/issue/2413
APPROVED (+8, 0, -0)
F33 Self-Contained Change: LXQt 0.15.0
https://pagure.io/fesco/issue/2414
APPROVED (+8, 0, -0)
Request to be a provenpackager sponsor/administrator (churchyard)
https://pagure.io/fesco/issue/2404
APPROVED (+6, 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 #2416 Update 3rd party repo policy
https://pagure.io/fesco/issue/2416
#topic #2418 Formalize updated policies for what spins can change without
asking (and what can be changed with FESCo clearance)
https://pagure.io/fesco/issue/2418
#topic #2419 F33 System-Wide Change: LLVM 11
https://pagure.io/fesco/issue/2419
#topic #2420 F33 System-Wide Change: Use %make_build and %make_install
macros
https://pagure.io/fesco/issue/2420
#topic #2421 F33 System-Wide Change: Zanata removal
https://pagure.io/fesco/issue/2421
= 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.
3 years, 10 months
Package Review SELinux help
by Robert-André Mauchin
Hello,
I know next to nothing about SELinux so I'd like some help about the Bitcoin
Package Review by negativo17:
https://bugzilla.redhat.com/show_bug.cgi?id=1834731
Notably: are the bitcoin.{te,fc,if} files are sane?
Are they installed properly in the SPEC? Especially these parts:
%post server
%systemd_post %{name}.service
for selinuxvariant in %{selinux_variants}
do
/usr/sbin/semodule -s ${selinuxvariant} -i \
%{_datadir}/selinux/${selinuxvariant}/%{name}.pp \
&> /dev/null || :
done
# FIXME This is less than ideal, but until dwalsh gives me a better way...
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8332 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8333 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18332 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18333 2> /dev/null
/sbin/fixfiles -R %{name}-server restore &> /dev/null || :
/sbin/restorecon -R %{_localstatedir}/lib/%{name} || :
%postun server
%systemd_postun_with_restart %{name}.service
if [ $1 -eq 0 ] ; then
# FIXME This is less than ideal, but until dwalsh gives me a better way...
/usr/sbin/semanage port -d -p tcp 8332
/usr/sbin/semanage port -d -p tcp 8333
/usr/sbin/semanage port -d -p tcp 18332
/usr/sbin/semanage port -d -p tcp 18333
for selinuxvariant in %{selinux_variants}
do
/usr/sbin/semodule -s ${selinuxvariant} -r %{name} \
&> /dev/null || :
done
/sbin/fixfiles -R %{name}-server restore &> /dev/null || :
[ -d %{_localstatedir}/lib/%{name} ] && \
/sbin/restorecon -R %{_localstatedir}/lib/%{name} \
&> /dev/null || :
fi
Please comment in the RR if you can help.
I find the documentation at https://fedoraproject.org/wiki/SELinux rather old
and not really focused on the packaging side of it. Is there guidelines
anywhere else?
Best regards,
Robert-André
3 years, 10 months
Remove device-mapper-multipath from the Fedora workstation livecd -
Fedora 33 System-Wide Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWor...
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org
advices people to download.
As such most Fedora workstation installs will be done from the livecd. This
means that any package which is part of the livecd will be part of the
default install for most users.
device-mapper-multipath is 1 of only 2 packages in the default install
which still Requires the long obsoleted systemd-udev-settle.service, which
waits for all device-detection to be done + some extra waiting just to be
sure. This significantly slows down booting on various systems.
Multipath support is only necessary for installations in data-centers or
other enterprise setups, as such having device-mapper-multipath on the
livecd is not really necessary. For installations which do actually need
this device-mapper-multipath the server installation iso can be used and
this is a better fit for such installations.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
device-mapper-multipath is 1 of only 2 packages in the default install
which still Requires the long obsoleted systemd-udev-settle.service. The
other package is dmraid see [[Changes/DisableDmraidOnFirstRun|Disable
dmraid.service on first run]].
Multipath support is only necessary for installations in data-centers or
other enterprise setups, as such having device-mapper-multipath on the
livecd is not really necessary. For installations which do actually need
this device-mapper-multipath the server installation iso can be used and
this is a better fit for such installations.
Note then when installing from the server or everything netboot isos,
device-mapper-multipath depending on the obsolete udev-settle service is
not a problem, because then it will not be installed at all. Anaconda (the
installer) adds storage related packages such as device-mapper-multipath to
the installation package-set as necessary for the storage found at
installation time. So any installs done through the netinst isos already
will not have device-mapper-multipath installed.
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose
not to accept proposed alternatives. This section is optional for all
change proposals but is strongly suggested. Incorporating feedback here as
it is raised gives FESCo a clearer view of your proposal and leaves a good
record for the future. If you get no feedback, that is useful to note in
this section as well. For innovative or possibly controversial ideas,
consider collecting feedback before you file the change proposal. -->
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long
delay during boot. Removing / disabling the last 2 services depending on
this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Change the livecd packagelist (comps) to no longer include the
device-mapper-multipath package
* Other developers:
** No action is required by other developers
** Except if another package still brings in device-mapper-multipath
through dependencies, then this needs to be solved / coordinated with that
other packages maintainers
* Release engineering: [https://pagure.io/releng/issue/9560 #9560] (a check
of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This only affects new installs, upgrades of installs which have
device-mapper-multipath installed will still have it installed after the
upgrade.
== How To Test ==
# Install F33 on a machine / VM
# Do "rpm -q device-mapper-multipath", the output should be
"device-mapper-multipath" is not installed
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or
which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Re-add device-mapper-multipath to the livecd if
the dropping of it causes problems.
* Blocks release? No
== Documentation ==
This change does not require any documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
file system for desktop variants
by Gerald B. Cox
I was an early adopter and used BTRFS for many years, singing its praises.
I was particularly interested in the RAID capabilities. Then in 2016 the
bomb was dropped that:
"It turns out the RAID5 and RAID6 code for the Btrfs file-system's built-in
RAID support is faulty and users should not be making use of it if you care
about your data.
There has been this mailing list thread
<https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55161.html>
since the end of July about Btrfs scrub recalculating the wrong parity in
RAID5. The wrong parity and unrecoverable errors has been confirmed by
multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally
flawed
<https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg55179.html> --
"more or less fatally flawed, and a full scrap and rewrite to an entirely
different raid56 mode on-disk format may be necessary to fix it. And what's
even clearer is that people /really/ shouldn't be using raid56 mode for
anything but testing with throw-away data, at this point. Anything else is
simply irresponsible."
The current situation as I understand it is the problem is "mostly fixed" -
whatever that means.
So, BTRFS is great, ready for prime time... many people are using it, etc.
etc. etc. until something goes wrong and then you get... well, it's
experimental and not intended for production. Sucks to be you.
At some point you have to fish or cut bait. I was under the impression
that Redhat had done exactly that with the announcement and direction of
Stratis.
Why are we not concentrating on Stratis and XFS? Seems to me after waiting
for almost a decade for the promise of BTRFS to be fulfilled and then
having so many
people be burned, we should be turning the page rather than continuing to
rehash the same old arguments.
3 years, 10 months
Cleanup GNOME Hidden Boot Menu Integration - Fedora 33 System-Wide
Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
== Summary ==
GNOME integrates with Fedora's [[Changes/HiddenGrubMenu|hidden boot
menu feature]] to signal to the bootloader that boot was successful
and to request the menu to be shown the next boot when "Boot Options"
is selected in the Shutdown/Reboot dialog. Currently Fedora carries
downstream patches for this, which directly call the Fedora specific
grub2-set-bootflag helper. The goal of this change is to replace these
downstream patches with a clean bootloader agnostic solution which can
be submitted upstream.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
GNOME has 2 integration points with the
[[Changes/HiddenGrubMenu|hidden boot menu feature]]:
# Requesting the menu to be shown the next boot when "Boot Options" is
selected in the Shutdown/Reboot dialog.
# Signalling the bootloader that the boot was successful.
To replace our downstream patches for 1. we can use the new(ish)
systemd DBUS API used by "systemctl reboot --boot-loader-menu=60".
This currently only works with sd-boot, but systemd has hooks to allow
integration with other bootloaders, see the
[https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md
SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU env. variable documentation]. So we
can support this in grub2 with some relatively simply changes and then
replace our downstream patches for this with new patches using the
systemd DBUS API for this.
Replacing our downstream patches for 2. with an upstreamable
bootloader agnostic solution is somewhat involved. systemd has its
[https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ Automatic Boot
Assessment] feature, which is somewhat similar in that it to deals
with boot success detection, but its behavior on failure is different
(auto fallback to an older kernel) and it is a sd-boot specific
feature. Still we can use some parts of this. The boot-complete.target
and the concept of having a systemd-bless-boot.service which Requires
that target to be reached before it runs. So replacing out downstream
patches for 2. will consists of 2 parts:
# grub2 changes: Add a grub2-bless-boot.service which Requires
boot-complete.target and which does the equivalent of
"grub2-set-bootflag boot_success" when that target is reached
# GNOME changes: Add a oneshot gnome-wait-for-boot-success.service to
boot-complete.target, this will start a simple helper which listens on
a unix socket until signalled, thus delaying the completion of
boot-complete.target until it is signalled; and in the places where
the downstream patches are currently directly calling
"grub2-set-bootflag boot_success" signal (write a byte) this unix
socket instead.
Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html
mailinglist discussion].
== Benefit to Fedora ==
This change will remove some technical-debt in the form of a couple of
quick-and-dirty downstream patches from Fedora and will align GNOME's
integration with the [[Changes/HiddenGrubMenu|hidden boot menu
feature]] with our upstream first policy.
== Scope ==
* Proposal owners:
Create the necessary changes ASAP and submit these to Fedora's
[https://github.com/rhboot/grub2/ grub2] and
[https://gitlab.gnome.org/GNOME/ GNOME] upstreams.
* Other developers:
The bootloader team needs to do a new grub2 build with the changes
added and the desktop team needs to add the GNOME changes to the GNOME
packages. I will coordinate this with both teams.
* Release engineering: [https://pagure.io/releng/issue/9557 #9557] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change does not impact upgrades, the interface between the OS and
grub2 still goes through the same unmodified grubenv settings. The
only changes are in how we make the grubenv changes and all parts
involved in that will be updated together.
== How To Test ==
# Tests
## Install Fedora Workstation in a fresh vm or select reclaim
diskspace -> delete all in the installer (do a single os install).
## Boot the system the grub menu should NOT show
## Login, wait 2 minutes then presss "CTRL + ALT + F6" followed by
"CTRL + ALT + DEL" to do a reboot from the text-console without going
through the GNOME reboot dialog. The grub menu should NOT show on the
new boot.
## Reboot from the GNOME reboot dialog inside gdm. The grub menu
should NOT show on the new boot.
## Open the GNOME reboot dialog, then press alt to change the "Reboot"
button into "Boot Options" and click the "Boot Options" button (while
keeping alt pressed). You should now get the grub menu, with a
countdown of 60 seconds.
## Boot the system and then press "CTRL + ALT + F6" followed by "CTRL
+ ALT + DEL" to do a reboot from the text-console without logging in,
this counts as a failed boot, so the menu should now show.
# EFI vs Classic PC BIOS boot
## All above tests should be done twice, once on an EFI system and
once on a system using Classic PC BIOS boot
== User Experience ==
The user experience will be unchanged, the goal of this change is to
remove some technical debt and reduce the number of downstream changes
Fedora carries.
== Dependencies ==
There are no dependencies outside of the grub2 and GNOME changes.
== Contingency Plan ==
* Contingency mechanism: If this is not ready / complete when we near
the beta freeze, then revert to using our downstream patches
* Blocks release? No (assuming we do the revert so we do not regress)
== Documentation ==
There are no functional changes, so no documentation changes are necessary.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
RHEL 9 and modularity
by Josh Boyer
Hello Fedora Community!
I am a long-time Fedora Community member, and may be familiar to many
through previous FESCo or devel list discussions and passionate
debates. However I write to you today with a different community hat
on, as a lead Architect for Red Hat Enterprise Linux. The RHEL
organization has been following the modularity discussions within
Fedora, particularly around ELN, and often the question of what plans
we have for modularity in RHEL 9 has come up. Our Fedora Project Lead
and a number of FESCo members have reached out and asked if we can
provide some perspective here, and I am both happy and excited to have
that opportunity.
As the Fedora Council has pointed out [1], we certainly acknowledge
there are improvements to be made and have a team already working on
them. They recently outlined their plans in conjunction with our
Product Management team in a Fedora Council call as well [2]. We’re
continuing to invest time and effort in this packaging solution and
are confident that the team can deliver against their plan. It is
somewhat of a new experience for all of us when Red Hat is direct with
our product intentions, but we discussed the larger gaps we see with
usage in RHEL and are putting our efforts towards solving those gaps
with this plan.
Modularity is important to RHEL and those efforts are already
underway. We will be leveraging modularity in RHEL 9 where it most
makes sense. This is primarily centered around our Application
Streams concept, which has been well received by our customer base.
Providing a consistent but improved experience is the base
requirement, which allows us to have continuity from RHEL 8 to RHEL 9
and lowers the hurdle for our customers when upgrading from one major
version to another.
It is always good to push the boundaries and search for better ideas
and improvements, and that is part of what makes Fedora great. We are
doing this in the context of the RHEL 9 release as well, so our near
term timeline and requirements mean we are working on evolving
modularity, not a revolution or a replacement. We are excited by ELN,
as it presents a possible space to allow those that want to continue
to iterate on modules a place to do so without necessarily impacting
the broader Fedora distribution in its entirety. It is my personal
hope that we can use that opportunity to improve modules and
modularity in the open source, Fedora-first way we’d prefer. Our near
term effort to improve the existing modularity implementation ahead of
RHEL 9 needs to occur, and we’d like to do that work in Fedora, rather
than in closed product development. Longer term, we are open to
contributing to a better replacement that meets many of the same
goals. This is what makes our distribution ecosystem work well, and
not having that upstream lessens the value we all get from such
experimentation in the open.
Hopefully that provides some context and helps FESCo and the wider
community understand where Red Hat is headed with modularity on the
Enterprise side.
josh
[1] https://communityblog.fedoraproject.org/fedora-council-and-the-future-of-...
[2] https://bluejeans.com/s/W_P0D
3 years, 10 months
Remove me as comaintainer/commiter - orphaning packages
by Johan Cwiklinski
Hello,
I'm going to stop packaging, so I've orphaned the following packages I
was "maintaining":
- iipsrv
- glpi
- php-elvanto-litemoji
- php-IDNA_Convert
- php-markdown
- php-scssphp-scssphp
- php-simplepie
- php-true-punycode
I've removed myself on all packages I was "admin" on, I'd also like to
be removed as commiter on:
- php-pear-CAS
- php-PHPMailer
- php-Smarty
- php-zendframework-zend-config
- php-zendframework-zend-crypt
- php-zendframework-zend-db
- php-zendframework-zend-escaper
- php-zendframework-zend-eventmanager
- php-zendframework-zend-filter
- php-zendframework-zend-http
- php-zendframework-zend-hydrator
- php-zendframework-zend-i18n
- php-zendframework-zend-inputfilter
- php-zendframework-zend-json
- php-zendframework-zend-loader
- php-zendframework-zend-math
- php-zendframework-zend-serializer
- php-zendframework-zend-servicemanager
- php-zendframework-zend-session
- php-zendframework-zend-uri
- php-zendframework-zend-validator
- php-zendframework-zend-view
- swatch
I did not find any way to do that.
Thank you :)
--
Johan
3 years, 10 months
