The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
2 years, 5 months
Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim
Hi all,
Neal and I are looking at getting ButterManager packaged, and it
depends on sip and PyQt5-sip:
https://github.com/egara/buttermanager/blob/master/requirements.txt
Now, this is where things get a bit odd:
- the current sip (4.19.24) does not have autogenerated Python
provides, but sip5 does:
$ sudo dnf repoquery --provides sip
Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53
PM PST.
sip = 4.19.24-1.fc33
sip(x86-64) = 4.19.24-1.fc33
sip-macros = 4.19.24-1.fc33
$ sudo dnf repoquery --provides sip5
Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53
PM PST.
python-sip5 = 5.5.0-1.fc33
python3-sip5 = 5.5.0-1.fc33
python3.9-sip5 = 5.5.0-1.fc33
python3.9dist(sip) = 5.5
python3dist(sip) = 5.5
sip5 = 5.5.0-1.fc33
sip5(x86-64) = 5.5.0-1.fc33
- sip ships PyQt5 bindings with matching version, but sip 5 seems to no
longer do so
$ sudo dnf info python3-pyqt5-sip
Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53
PM PST.
Installed Packages
Name : python3-pyqt5-sip
Version : 4.19.24
Release : 1.fc33
Architecture : x86_64
Size : 244 k
Source : sip-4.19.24-1.fc33.src.rpm
Repository : @System
From repo : fedora
Summary : SIP - Python 3/C++ Bindings Generator for pyqt5
URL : https://riverbankcomputing.com/software/sip/intro
License : GPLv2 or GPLv3 and (GPLv3+ with exceptions)
Description : This is the Python 3 build of pyqt5-SIP.
- https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but
https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in
Fedora (available since last month)
- there's a lot of packages that depend on python3-pyqt5-sip (though
none use the canonical python3dist(pyqt5-sip) unfortunately)
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
'python3dist(pyqt5-sip)'
Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020
04:28:29 PM PST.
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
python3-pyqt5-sip
Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020
04:28:29 PM PST.
calibre-0:4.23.0-3.fc34.x86_64
krita-0:4.4.1-1.fc34.i686
krita-0:4.4.1-1.fc34.x86_64
libarcus-0:4.8.0-1.fc34.src
mingw-python-qt5-0:5.15.0-4.fc34.src
pyqtwebengine-0:5.15.0-2.fc33.src
python-pyface-0:7.1.0-1.fc34.src
python-pynest2d-0:4.8.0-1.fc34.src
python-qt5-0:5.15.0-5.fc34.src
python3-arcus-0:4.8.0-1.fc34.x86_64
python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64
python3-poppler-qt5-0:0.75.0-6.fc33.x86_64
python3-pyqtchart-0:5.15.2-1.fc34.i686
python3-pyqtchart-0:5.15.2-1.fc34.x86_64
python3-qgis-0:3.16.1-2.fc34.i686
python3-qgis-0:3.16.1-2.fc34.x86_64
python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64
python3-qt5-base-0:5.15.0-5.fc34.i686
python3-qt5-base-0:5.15.0-5.fc34.x86_64
qhexedit2-0:0.8.9-2.fc33.src
scidavis-0:2.3.0-2.fc33.src
veusz-0:3.3.1-1.fc34.src
veusz-0:3.3.1-1.fc34.x86_64
Any idea what's the best way to handle this? and/or why PyQt5-sip's
versioning get so far ahead of sip?
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
2 years, 7 months
Fedora's GPG key in DNS(SEC)
by Miroslav Suchý
All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified
using DNSSEC.
Why? How it can be used? That is long story and you can read about it in my blog entry:
http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_sign...
Few last minutes notes here:
- there are still some gotchas which should be fixed. But enough code is already in production - you can play with it
now. Relevant issues are linked in the blog post.
- the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be
migrating - so we are far from enabling this by default.
Comments are welcomed.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
2 years, 8 months
thinking journal retention timelimits
by Matthew Miller
As we start a new year, I'm thinking about data retention in general. :)
In my experience, it's pretty rare on an end-user laptop or desktop system for
logs from much more than the previous boot to be interesting. Maybe I
occasionally want to look back a little while to see if a problem just
started. It's exceedingly rare that I need (or want) to look back more than
a month.
Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is
entirely based on disk usage.
Logs can accidentally contain sensitive data, and it's just plain faster to
work with them when there's less. I propose we set this to something like
six months by default.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 8 months
Donate 1 minute of your time to test upgrades from F33 to F34
by Miroslav Suchý
Do you want to make Fedora 34 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
--enablerepo=updates-testing --enablerepo=updates-testing-modular \
distro-sync
This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf
upgrade` before running this command.
If you have have rdma-core.i686 installed you have to pass `--allowerasing`.
https://bugzilla.redhat.com/show_bug.cgi?id=1919864
If you get this prompt:
...
Total download size: XXX M
Is this ok [y/N]:
you can answer N and nothing happens, no need to test the actual upgrade.
But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or
against fedora-obsolete-packages if that package should be removed in Fedora 34. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" reports:
https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall
Thank you
P.S. sent from workstation successfully upgraded to F34 :)
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
2 years, 8 months
Please clarify master vs main vs rawhide branches
by Steven A. Falco
I see that the master to main conversion has happened. I'd like to know the recommended way to deal with that.
Currently, I'm doing:
git fetch --all
git remote prune origin
git remote set-head origin -a
git checkout main
The above sets origin/HEAD to rawhide
Question 1: Is that the right set of steps, or is there a better way to update my local repos?
Question 2: For the packages I maintain, should I put changes in main or rawhide? Should I keep main and rawhide in sync?
Steve
2 years, 8 months
Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Power4kPageSize
== Summary ==
On ppc64le, the kernel is currently compiled for 64k page size.
This change proposes using the more common 4k page size.
Some HPC workloads may be disadvantaged slightly. Workstation users
are likely to encounter fewer bugs.
Some things, like the AMD Radeon GPU drivers, firmware or related
code, appear to be completely non-functional on the 64k page size.
Insufficient upstream developers are testing such issues on this
architecture.
== Owner ==
* Name: [[User:pocock|Daniel Pocock]]
* Email: daniel(a)pocock.pro
== Detailed Description ==
== Feedback ==
Discussed several times on devel,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
latest here]
[https://forums.raptorcs.com/index.php/topic,248.msg1852.html
discussed upstream in the Raptor forum]
== Benefit to Fedora ==
Better first impression for users of ppc64le workstations.
Users can focus on reporting ppc64le bugs without being sidetracked by
page size bugs.
== Scope ==
* Proposal owners: [[DanielPocock]]
* Other developers: please volunteer by adding your name here
* Release engineering: [https://pagure.io/releng/issue/9939 #9939]
** wait for 5.12 kernel, verify that it includes the Btrfs patches for
arbitrary 4k / 64k sector size, independent of the page size
** create a kernel with 4k page size to run on the ppc64le build servers
** ensure the default kernel RPM in the distribution has 4k page size
** perform the mass rebuild running on the 4k page size
** create an installer ISO based on the revised kernel with 4k page size
* Policies and guidelines: no, as it is an arch-specific issues, most
other architectures already have a 4k page size
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: none of the current objectives relate to
this change
== Upgrade/compatibility impact ==
If the user has already formatted their root filesystem with Btrfs and
a 64k sector size, they need to be using a Fedora kernel that supports
both 4k and 64k. This is anticipated in a future kernel release, 5.12
and will hopefully be ready for F34 or
F35[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje....
== User Experience ==
New GPUs are more likely to just work on this non-x86 architecture, as
long as the latest firmware, mesa, llvm are also used.
Btrfs, the default filesystem, will use the sector size identical to
the running kernel's page size. As the 4k page size is more common,
this will ensure Btrfs filesystems created on ppc64le hosts can be
used on x86 and other hosts without hassle.
== Dependencies ==
All RPMs must be rebuilt on a server running the final page size (4k)
== Contingency Plan ==
* Contingency mechanism: Prepare a kernel with the original 64k
config, install it on the build server, rebuild all the packages for
this architecture
* Contingency deadline: whenever the last time for a full rebuild or
kernel change is possible
* Blocks release? Yes, full rebuild of all packages must be completed
before release
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
