Orphaned python2-django1.11
by Petr Viktorin
Hello,
Back when [Django 2.0] was released in Fedora 28, I took over Django
1.11 LTS as some important (to me) packages depended on it. I'm no
longer interested in maintaining it, so I've orphaned it.
Let me know if you want to take it. If no one does, it may be removed
from Rawhide in 6 weeks.
Depending packages and their maintainers are:
- fts-monitoring (andreamanzi, simonm)
- python-oauth2client (mbaldessari, ralph)
- cobbler-web (jimi, kwizart, orion, shenson)
Let me know if you need help with these packages.
[Django 2.0]: https://fedoraproject.org/wiki/Changes/Django20
4 years, 9 months
Fedora 31 System-Wide Change proposal: No More i686 Kernels
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.
== Owner ==
* Name: [[User:jforbes| Justin Forbes]]
* Email: jforbes(a)fedoraproject.org
== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing,
and issues frequently appear upstream. These tend to go unnoticed for
long periods of time. When issues are found, it is often a long time
before they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel.
With this proposal, the i686 kernel will no longer be built. A kernel
headers package will still exist, and all 32bit packages should
continue to build as normal. The main difference is there would no
longer be bootable 32bit images.
This was last proposed with Fedora 27, but it was deferred as an i686
SIG was to be created to handle issues going forward. That SIG has
been largely unresponsive. The only thread so far this year has been
a thread starting with "Hello, I noticed that the x86 group hasn't had
any reports in a while. As the absentee sponsor of the group, I would
like to remind people on the list and interested in keeping x86_32 in
Fedora releases that there is general work which needs to be done by
people interested. " And the only response was one person saying they
would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
More testable kernel updates, faster fixes for security bugs, and
lowered exposure.
== Scope ==
* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: Drop i686 based images
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test ==
N/A Nothing to test, we simply stop producing a flavor of the kernel
package. As there is no direct upgrade path from i686 -> x86_64, users
with capable hardware will have to reinstall.
== User Experience ==
The few 32bit users will have the full lifecycle of Fedora 30 to
choose a time to upgrade to a 64bit installation. Some old hardware
will no longer be supported by fedora.
== Dependencies ==
32 bit x86 images can no longer be built.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
* Contingency deadline: As QA requires for image candidates
* Blocks release? Yes
* Blocks product? product Fedora 31
== Documentation ==
The lack of an i686 image will need to be documented.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 9 months
F31 Self-Contained Change proposal: Include several modules in the
EFI build of Grub2 for security use-cases
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
== Summary ==
Include Grub's "verify," "cryptodisk" and "luks" modules (and if
necessary, relevant "gcry" modules) in grubx64.efi of the
'grub2-efi-x64' package.
== Owner ==
* Name: [[User:pjones| Peter Jones]]
* Email: pjones(a)redhat.com
* Name: [[User:javierm| Javier Martinez Canillas]]
* Email: fmartine(a)redhat.com
== Detailed Description ==
Users utilising secure boot functionality on the UEFI platform cannot
insert modules that aren't in grubx64.efi. Paradoxically, this means
that security-conscious users cannot use grub's verify module, or
employ (near) full disk encryption using cryptodisk and luks.
The security benefits of signature verification would reach more users
if Fedora automated it by incorporating the process into
grub2-mkconfig.
For the long-term, to grant flexibility with grub2 modules on secure
boot instances, it may be advisable to sign the .mod files in the
'grub2-efi-x64-modules' package, modify grub2-mkconfig (or -install)
to copy the necessary modules into the EFI partition when required by
the user's configuration and then allow inserting of signed modules in
secure boot instances.
== Benefit to Fedora ==
This change will allow users to gain trust in the integrity of
early-launch code either through verification of signatures
(particularly useful for initramfs, which is particularly vulnerable
to possible offline modification) or encryption of the boot partition.
== Scope ==
* Proposal owners: Modify grub.macros file to include the
above-mentioned modules in the GRUB_MODULES variable.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Change only adds modules, so existing users should have no problems.
== How To Test ==
<b>For "verify":</b>
1. Generate a signing key with "gpg --gen-key" and copy it to the EFI partition
2. Add "trust <gpg key>" (but grub may inherit this from shim's MOK)
and "set check_signatures=enforce" to /etc/default/40_custom
3. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
4. Create a file, /tmp/pass, with the key's passphrase, then execute:
for x in $(find /boot -name "*.cfg" -or -name "*.mod" -or -name
"vmlinuz*" -or -name "initramfs*" -or -name "grubenv"); do gpg --batch
--detach-sign --passphrase-fd 0 $x < /tmp/pass; done. Then, shred
/tmp/pass
5. Reboot. If system starts, change is successful
<b>For cryptography modules:</b>
1. Backup boot partition
2. Run cryptsetup luksFormat <boot partition's block device, for
example, /dev/sda2> --type luks1
3. Open luks container and restore backup
4. Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub
5. Confirm that /etc/fstab has the correct UUID for /boot
6. Run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
7. Reboot. Grub should ask for the password created in step 2. If
system then starts, change is successful
(If filesystem root is also encrypted, user may be asked for a
password twice. This can be mitigated with a keyfile for filesystem
root, or use of the clevis package, and likely, a tpm.)
== User Experience ==
Users may optionally elect to verify the integrity of boot code either
through verification of digital signatures or encryption of the boot
partition.
== Dependencies ==
Grub2-efi-x64-modules and grub2-tools-* depend on this package, but
require no change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
shipped configuration
* Contingency deadline: Beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? No
== Documentation ==
https://www.gnu.org/software/grub/manual/grub/html_node/Using-digital-sig...
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system...
== Release Notes ==
Fedora now supports Grub's detached verify and cryptodisk
functionality natively, even on secure boot systems.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
4 years, 9 months
Fedora 31 System-Wide Change proposal: Python means Python3
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Python_means_Python3
== Summary ==
In package and command names, "Python" will mean "Python 3".
Users installing and running Python or Python packages without
specifying a version will get Python 3.
Running <code>python</code> will run <code>python3</code>. Running
<code>pytest</code> will run the Python 3 version of pytest, and
similarly for <code>pydoc</code>, <code>pylint</code>, etc.
<code>dnf install python</code> will install {{package|python3}}, and
similarly for other <code>python-*</code> provides, e.g. <code>dnf
install python-requests</code> will install
{{package|python3-requests}}.
This is the final preparation for
[https://fedoraproject.org/wiki/Changes/RetirePython2 the retirement
of Python 2 in Fedora 32] done in line with the
[https://github.com/python/peps/pull/989 soon to be finalized]
upstream recommendations.
== Owner ==
* Name: [[User:Churchyard| Miro Hrončok]]
* Name: [[User:Pviktori| Petr Viktorin]]
* Email: <python-maint(a)redhat.com>
== Detailed Description ==
=== Motivation ===
The final upstream release of Python 2 is planned for January 2020. No
further fixes will be made upstream. Most of Fedora 31's lifetime is
after that date. Python 2 will be maintained only by its Fedora
maintainers.
In preparation for removing Python 2 from Fedora entirely, we will
make the unqualified name "Python" refer to the fully supported
version.
This is in line with upstream changes to
[https://www.python.org/dev/peps/pep-0394/ PEP 394] recommendations.
(At the time of this writing, these changes are still
[https://github.com/python/peps/pull/989 being finalized], but
recommendations for Linux distributions are accepted.)
This completes the work started with Fedora 23's
[https://fedoraproject.org/wiki/Changes/Python_3_as_Default "Python 3
as Default"] change, with only
[https://fedoraproject.org/wiki/Changes/RetirePython2 removing Python
2] left to do.
=== What is being changed ===
The following changes will be made both in the
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Python packaging guidelines] and the actual packages.
==== Package provides ====
'''Before:''' Packages with Python 2 modules used to provide the
unversioned <code>python-</code> name. Users could do <code>dnf
install python-requests</code> and the {{package|python2-requests}}
package would be installed.
'''After:''' Packages with Python 3 modules will provide the
unversioned <code>python-</code> name. Users can do <code>dnf install
python-requests</code> and the {{package|python3-requests}} package
will be installed.
This applies to the {{package|python3}}/{{package|python2}} package as
well as packages with Python modules. <code>dnf install python</code>
will install {{package|python3}}.
The vast majority of packages will be updated by changing
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_py...
the %python-provide macro], with no changes in the individual spec
files. The change owners will change the macro before the mass
rebuild.
==== Python command ====
'''Before:''' The <code>/usr/bin/python</code> command was a symbolic
link to <code>/usr/bin/python2</code> living in the
{{package|python-unversioned-command}} subpackage of
{{package|python2}}. {{package|python2}} recommended
{{package|python-unversioned-command}}, so most users got the command
by default when {{package|python2}} was installed.
'''After:''' The <code>/usr/bin/python</code> command will be a
symbolic link to <code>/usr/bin/python3</code> living in the
{{package|python-unversioned-command}} subpackage of
{{package|python3}}. {{package|python3}} will recommend
{{package|python-unversioned-command}}, so most users will get the
command by default when {{package|python3}} is installed (and it is
installed by default).
==== Other commands ====
Similarly, the Python-specific commands will switch from Python 2 to
Python 3. This includes at least the following commands:
* pip
* python-config
* wheel
* idle
* pydoc
* pytest
* nosetest
* pycodestyle
* pylint
* epylint
* pyreverse
* symilar
* unit2
* msgfmt.py
* pygettext.py
* flask
* ipython
* f2py
* ipdb
* easy_install
* ...
This list is incomplete, automation is yet to be created to discover
all such commands.
Note that applications like <code>pygmentize</code> or
<code>cython</code>, whose behavior doesn't depend on the Python
version, are not affected. (By current guidelines, they should be
already using Python 3 if possible.)
=== Changes needed by Python package maintainers ===
This section of the change covers action needed from Python package
maintainers. Most of the packages need no change, but there are
several exceptions.
==== Packages with ambiguous names ====
Tracked at: https://fedora.portingdb.xyz/namingpolicy/
If your package with a Python 2 module or plugin is named with
unversioned <code>python</code> (such as for example
<code>claws-mail-plugins-python</code> or <code>PyQt4</code>), it
needs to be removed or renamed to have <code>python2</code> in the
name (such as, for example, <code>claws-mail-plugins-python2</code> or
<code>python2-PyQt4</code>).
If your package is an application that happens to be written in Python
2 (such as {{package|calibre}}), no renaming is needed (applications
don't need the <code>python-</code>, <code>python2-</code> or
<code>python3-</code> prefix).
==== Packages with ambiguous requires ====
Tracked at: https://fedora.portingdb.xyz/namingpolicy/
If your package depends on (Requires, BuildRequires, Recommends, etc.)
a Python package with unversioned Python name (such as for example:
systemd-python, python-setuptools, PyQt5, pycairo), it will now get
resolved to the Python 3 version. Such dependencies need to be updated
to specific Python 2 or Python 3 names (such as for example:
pythonX-systemd, pythonX-setuptools, pythonX-qt5, pythonX-cairo where
X is either 2 or 3).
==== Packages with ambiguous provides ====
Most of the backwards compatibility <code>python-*</code> provides are
handled by the %python_provide macro and the change owners will change
the macro behavior, so you don't have to worry about those.
However, sometimes manual provides were added. If your package has
some manual backwards compatibility provides for Python 2 packages,
those need to be moved to the Python 3 packages or removed.
For example, before this change, the {{package|python2-m2crypto}}
package provided and obsoleted <code>m2crypto</code>. Instead, the
{{package|python3-m2crypto}} package should do that after this change.
==== Packages with missing %python_provide ====
The <code>%python_provide</code> macro used to do nothing for Python 3
packages. As such, it was often forgotten and only used with the
Python 2 packages.
Packagers of Python 3 packages should make sure to use the
<code>%python_provide</code> macro according to the guidelines:
%package -n python3-%{srcname}
...
%{?python_provide:%python_provide python3-%{srcname}}
==== Packages with Python versioned commands and tools ====
Some packages have two versions of the provided commands. For example,
the {{package|python2-pytest}} package has
<code>/usr/bin/pytest-2</code> and <code>/usr/bin/pytest-2.7</code>,
the {{package|python3-pytest}} package has
<code>/usr/bin/pytest-3</code> and <code>/usr/bin/pytest-3.X</code>.
The unversioned <code>/usr/bin/pytest</code> command used to be a
symbolic link to <code>/usr/bin/pytest-2</code>. Now it needs to be
changed to <code>/usr/bin/pytest-3</code> and moved to the
{{package|python3-pytest}} package.
For some packages, such duplication makes no sense, because the user
sees no difference. For example, there should be just one
<code>/usr/bin/pygmentize</code> -- the user doesn't care if it runs
on Python 3, Python 2 or if it is written in Rust. This is not a new
rule, but if your package is not following it, now is a good time to
make sure the tool uses Python 3.
==== Packages that need unversioned Python to be Python 2 ====
Since Fedora 29, a
[https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_...
specific workaround is needed] to use the <code>python</code> command
as Python 2.
This workaround will now bring Python 3.
If that does not work for your package, you'll need to fix it (patch
it) or retire it from Fedora.
If you only need the <code>python</code> command to mean Python 2
during package build, you can do something like this:
mkdir tmp_path
ln -s %{__python2} tmp_path/python
PATH=$(pwd)/tmp_path:$PATH make ...
However, if your package uses the <code>python</code> command during
runtime, this ugly workaround won't work.
== Benefit to Fedora ==
The name "Python" will not refer to software that will be unmaintained
upstream for most of Fedora 31's lifetime and
[https://fedoraproject.org/wiki/Changes/RetirePython2 retired from
Fedora 32].
== Scope ==
* Proposal owners:
** Changes in {{package|python3}}, {{package|python2}} packages:
*** make <code>/usr/bin/python</code> link to
<code>/usr/bin/python3</code> instead of <code>/usr/bin/python2</code>
(+ the same for other executables there)
*** make {{package|python-unversioned-command}} a subpackage of
{{package|python3}} instead of {{package|python2}}
*** make {{package|python3}} (instead of {{package|python2}})
recommend {{package|python-unversioned-command}}
** Changes in other commands:
*** switch pytest, nosetests, ipython, pip... to python3 (see Detailed
Description for the actual list)
** Changes in {{package|python-rpm-macros}}:
*** make <code>%python_provide</code> provide <code>python-foo</code>
for <code>python3-foo</code> instead of for <code>python2-foo</code>
** Let the mass rebuild change the provides based on the
<code>%python_provide</code> change
** Examine the failures and provide help to package maintainers
** File bugs for remaining packages that provide <code>python-x</code>
or <code>x-python</code> for Python 2
* Other developers (Python package maintainers, see Detailed Description):
** Everybody: Make sure that you require and use python2 or python3
packages explicitly
** If your package provides <code>python-*</code> or
<code>*-python</code> for a Python 2 package by other means than the
<code>%python_provide</code> macro, move that to the Python 3 package
(or remove entirely if not applicable)
** Fix or retire your package if it requires the unversioned
<code>python</code> command to be Python 2
* Release engineering: [https://pagure.io/releng/issue/8482 #8482]
* Policies and guidelines:
** Slightly adapt
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_py...
the %pyton_provide macro] section of the Python packaging guidelines
and the [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/
Python Appendix].
* Trademark approval: not needed
== Upgrade/compatibility impact ==
Custom scripts with <code>python</code> shebangs will invoke Python 3
by default, whereas previosuly they invoked Python 2 by default. See
the User Experience section for details.
== How To Test ==
For your favorite Python 3 package, check that it can be installed
with the ambiguous Python name. For example, check that <code>dnf
install python-pip</code> installs {{package|pyhon3-pip}} instead of
{{package|pyhon2-pip}}.
For your favorite Python command, check that it invokes the Python 3
version. For example, check that <code>python</code> runs Python 3.
== User Experience ==
Users who run <code>python</code> directly will get Python 3.
Users who run <code>pip</code> directly will get pip for Python 3.
Users who run <code>pytest</code> directly will get Python 3 pytest
for Python 3.
...
Scripts with ambiguous Python shebangs (<code>#!/usr/bin/python</code>
or <code>#!/usr/bin/env python</code>) will be executed by Python 3 by
default.
If users need the <code>python</code> command or the
<code>#!/usr/bin/env python</code> shebang to run Python 2, they can
easily do that by:
ln -s /usr/bin/python2 ~/.local/bin/python
Similarly, sysadmins can do that system-wide:
ln -s /usr/bin/python2 /usr/local/bin/python
If users don't want the python command at all, they can <code>dnf
remove python-unversioned-command</code>.
== Dependencies ==
Most packages that provide Python version-specific functionality will
be affected. However, the Change owners include proven packagers and
they maintain python-rpm-macros, so most will not need packager
attention.
We depend on the Fedora mass rebuild to adjust macro-generated package provides.
(Also, the PEP 394 update could be delayed, or even rejected/changed.
Even if that happens, this Change will not be affected: Fedora would
depart from following the upstream recommendations.)
There are currently (2019-06-25)
[https://fedora.portingdb.xyz/namingpolicy/ 90 packages left with
ambiguous Python requires]. Those need to be adapted. Lot of them
unfortunately Fail to Build From Source and will be retired before the
Fedora 31 branching.
== Contingency Plan ==
* Contingency mechanism: revert the changes, mass rebuild packages
with the original <code>%python_provide</code> macro
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* Updated Packaging guidelines
* This Change page
== Release Notes ==
TBD. Check User Experience section.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 9 months
Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
== Summary ==
Make Qt applications to run natively on Gnome Wayland session, using
the Qt Wayland platform plugin instead of the XCB plugin which is used
for X11/XWayland. Other desktop environments already run natively on
Wayland sessions, only Gnome is excluded by Qt.
== Owner ==
* Name: [[User:jgrulich| Jan Grulich]]
* Email: <jgrulich(a)redhat.com>
* Product: Spins / Workstation
* Responsible WG: Desktop
== Detailed Description ==
Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols and has
been enabled by default for non-Gnome Wayland sessions.
With Qt Wayland on Gnome Wayland session we need to support CSD, it's
actually the only way how decorations are going to work in Qt apps
right now. Qt Wayland implements basic decorations, which really
doesn't match Gnome Adwaita theme, therefore there are new CSD being
implemented as part of QGnomePlatform.
To make Qt applications run natively on Wayland we need to modify Qt
5, specifically '''qt5-qtbase''' module, where we allow the Wayland
plugin to be used also for Gnome sessions. The new decorations from
QGnomePlatform will be used automatically once they are fully
implemented and updated in Fedora.
== Benefit to Fedora ==
Qt applications running with the Wayland plugin run generally faster
and smoother on Wayland enabled sessions like Gnome Wayland and better
support HiDPI displays (respects desktop scale) .
== Scope ==
* Proposal owners:
# Modify Qt 5 (qt5-qtbase) to not exclude Gnome when deciding whether
to use the wayland platform plugin
# Update QGnomePlatform with upcoming upstream release including
window decorations
* Other developers:
# Test and watch for regressions.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Run any Qt application on Gnome Wayland session and check any issues
you may see.
== User Experience ==
* Smoother font rendering compared to Qt applications using XCB plugin
* Honor display scale, better user experience on HiDPI and semi-HiDPI desktops.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Switch back default to XCB plugin.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? product No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 9 months
rpmlint: library-not-linked-against-libc (parts of Python stdlib,
after gcc 9)
by Miro Hrončok
I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
python3-libs.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
python3-test.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
(Note that there are plenty of other extension modules that do not raise this
error.)
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
library-not-linked-against-libc:
That isn't helpful either.
I found a similar Debian thing [1] that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 9 months
always update the bootloader during major upgrades
by Chris Murphy
Hi,
This is not a formal proposal, this is for discussion and identifying
liabilities. This email has an x86 GRUB bias only because that's the
bootloader regime I'm most familiar with. I think it should apply to
other archs as well, i.e. their bootloaders shouldn't be permitted to
become stale.
Short version: Fedora should take responsibility for the bootloader
being up to date, by updating it during major version upgrades. This
is already the case on UEFI with conventional installations. I'd like
to make sure it always happens on major version upgrades for BIOS
installations. What's the problem? This would step on any custom
bootloader configuration a user has for multiboot. There is no
reasonable mechanism on BIOS systems to determine if the bootloader is
a Fedora bootloader, and somehow only update a Fedora bootloader and
not touch any other bootloader.
Fedora should be responsible for keeping the bootloader it installs in
~80% of the use cases up-to-date; and ignore the fallout from the ~20%
who have a custom setup that would be stepped on by a forced
bootloader update. The former is a feature and security risk, by
allowing the bootloader to go stale over time. The latter is an
inconvenience.
Longer version:
terms:
bootloader - this is the pre-boot bootloader binaries; on BIOS it's
embedded in the MBR, and the MBR gap or BIOS Boot partition, and
modules found in /boot/grub2 on Fedora. On UEFI, this is the
/EFI/fedora/shimx64.efi and /EFI/fedora/grubx64.efi which in the
typical installation are built and signed by the Fedora build system.
Other bootloaders have different names but generally follow a similar
convention, the point here is to distinguish between the "bootloader"
which runs in the pre-boot environment, and the installed package
containing user space tools that are used to install (or contain) the
bootloader.
Fedora bootloader - this is a bootloader that is derived from Fedora
packages and effort; as contrasted to merely upstream GRUB, or
Ubuntu's GRUB, etc. as these derivatives can actually be substantially
different from each other.
Discussion:
Both gnome-software (pk-offline-update), and dnf system-upgrade, on
BIOS firmware x86 computers, do not update the bootloader. That is, we
do not run 'grub2-install' either before starting an upgrade, or as a
post install operation following an upgrade. Therefore the bootloader
will become stale if the user does not manually run 'grub2-install'
periodically.
On conventional Fedora installations on UEFI computers, the bootloader
is included in the shim and grub2 packages as a file, and is therefore
updated. This happens sporadically within a Fedora release, not only
at major upgrade time. This updating of the bootloader files doesn't
happen on Silverblue on UEFI, so it ends up being subject to the same
problem under discussion.
In the most recent release, Fedora 30, we saw quite a lot of people
run into a problem we knew about before release, directly related to
the bootloader becoming stale. And it only affected BIOS systems (and
Silverblue on both firmware types).
https://fedoraproject.org/wiki/Common_F30_bugs#blscfg-fail
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1652806
In the bug, you can find some dups as well but also quite a bit of
user aggravation. I'd like to avoid this going forward.
Windows and macOS never involved users in this stuff. They always
asserted complete and total domain over the bootloader, there wasn't
even an option to avoid updating it. And I think Fedora needs to do
the same. Just update it. That benefits most users. It's the
responsible thing to do. And those who need custom setups, can still
do that. It would only get stepped on at major upgrade time. And it's
decently likely we can warn them in advance.
There are some gotchas I'm already thinking of: MBR gap is too small,
there are multiple drives and it's ambiguous which one should get the
bootloader, and so on. I think it's sane to have a test for reasonable
certainty we can and should update the bootloader, and warn and not
update it in the cases that fail that test.
Thoughts?
--
Chris Murphy
4 years, 9 months
Automating R package dependencies
by Elliott Sales de Andrade
Hi R-interested packagers and others,
Recently, I've been looking at how RPM can automatically determine
Provides and Requires [1]. I have since implemented this for R using
an R script [2] and some file attributes [3]. Following other
languages' Provides, I have namespaced them as R(packageName). It then
adds corresponding Requires, Suggests, and Enhances.
Additionally, R package versions commonly contain dashes. In order to
work in RPM, these are replaced with dots. For the automated
Provides/Requires, I have used the *real* versions instead.
So now the question is how to apply this. I expect there are social
concerns, i.e., discussing with the R maintainer, making a
Self-contained Change, etc. But for this email, I am mostly concerned
with the technical aspects:
1. Is R-devel the right place to put the script and RPM attribute file
(all R packages would normally depend on this)?
2. Does this namespacing make sense?
3. Are dashes in *namespaced* versions going to be a problem?
4. Python had a flag to enable the automatic generator; do we need
this for R, and how was it implemented?
5. I expect this would need a rebuild of all packages to get the
dependencies right (because the regular rebuild is unordered); would
this need a side tag? Or would leaving it for the normal mass rebuild
just be fine?
6. R only has two levels of dependencies (hard-require or suggested,
but not installed by default). Thus both build- and runtime-optional
packages are in Suggests; do we care about the extra Suggests?
[1] https://rpm.org/user_doc/dependency_generators.html
[2] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R
[3] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R.attr
--
Elliott
4 years, 9 months
The state of Python 3.8 in Fedora 31
by Miro Hrončok
Hello,
When I filed the Python 3.8 [change] for Fedora 31, we knew that the schedule
would be tight.
For that very reason, we have not yet started to build for Python 3.8 in a f31
side tag, but instead we've only been doing it in [copr] so far.
The mass rebuild happens on 2019-07-24, according to the Fedora 31 [schedule].
That gives us about 1 month + 1 week to be able to merge the side tag back in
case we decide to start building it now.
There are several challenges:
- there are ~200 build failures that block this, tracked on [bugzilla]
- further there are about ~300 packages that are blocked by the above,
possibly more
- some of the packages are quite crucial to make this happen (tornado, pygobject3)
- the 3.8.0 [releases] have been delayed so far, so continuing the trend, we
could very well end up with the first RC just one day before the F31 Final
Freeze or even after that (risking 3.8 beta in Fedora 31 GA)
I've met with Petr Viktorin and Tomáš Orsava today and we are prepared to deffer
this change to Fedora 32, unless there is a large push-back against that.
However we don't want this to be an internal decision behind closed doors, so we
are sharing it with you and we are happy to reconsider, in case there is
something that we haven't anticipated.
What would that mean:
- we would continue to build the packages in [copr] as new Python 3.8 beta
versions are released
- we would continue to report build failures and to provide pointers to
affected maintainers
- right after the F32 branching (2019-08-13 according to the [schedule]), we
would start with the side tag builds
- the Koji builds would start ~2 months later
Benefits:
- we would not be stressed by the immediate mass rebuild deadline
- we would not need to care about ABI incompatibilities between beta releases,
because the last beta should be out when we start
Negatives:
- the users would get 3.8 as the main python3 about 6 months later, but they
already have Python 3.8 interpreter in Fedora to develop on
We could of course just start building now and than decide not to merge the side
tag, but we are worried that it would leave a big mess in git repos and RPM
changelogs.
If you think this is not a wise decision and would prefer to have Python 3.8 in
Fedora 31 (as the main python3), please discuss quickly. The F31 mass rebuild is
approaching fast and there's a lot to be done, so every day counts now; in other
words, the later you present your argument, the stronger it must be ;)
[change] https://fedoraproject.org/wiki/Changes/Python3.8
[copr] https://copr.fedorainfracloud.org/coprs/g/python/python3.8/
[schedule] https://fedoraproject.org/wiki/Releases/31/Schedule
[bugzilla]
https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON38&hide_resol...
[releases] https://www.python.org/dev/peps/pep-0569/#schedule
Miro Hrončok,
on behalf of the Fedora's Python SIG
and Red Hat's Python Maintenance team
--
Phone: +420777974800
IRC: mhroncok
4 years, 9 months