F37 proposal: Supplement of Server distributables by a KVM VM disk
image (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Virtualization has long been a steadily growing use case of Fedora
Server Edition, but it is still time consuming and tedious for the
system administrator to create a Fedora Server VM. Supplementing the
downloads by a KVM VM image remedies the deficiency.
== Owner ==
* Name: [[User:pboy| Peter Boy on behalf of Server WG]]
* Email: pboy(a)uni-bremen.de
== Detailed Description ==
The creation of the VM disk image, uses the same kickstart files and
installation groups as the standard full installation, except of
course for the hardware-specific items. The image is optimized for
KVM.
That way, the VM resembles a default server installation as closely as possible.
All administrative tools are available reliably from the beginning,
all administrative routines and helps (scripts) can be used in the
same way. All application services work in the identical way.
A default VM installation takes 1-2 minutes instead of about 30 mins.
== Feedback ==
The change proposal is based on an extensive discussion of the server
WG and has become part of its work program. For example, the server
documentation on virtualization has already been significantly
expanded in parallel and will continue to be supplemented and updated
on an ongoing basis. This is a response to the importance of the
topic.
== Benefit to Fedora ==
Significantly improves usability for Fedora Server Edition
administrators when deploying a Fedora Server Edtion VM. It thus makes
Fedora Server Edition more attractive, especially for new users
without extensive experience with Fedora. It thus helps to expand our
user base.
Fedora finally provides an installation path for a Fedora Server VM
that is built entirely on Fedora Resources, subject to Fedora quality
control, and compliant with Fedora principles. Until now, if a system
administrator has to install a VM preferable without the hassles of a
full default installation, we could only recommend third party binary
blob (e.g. virt-builder), which is a violation of our own core
principles. In addition, the third party products do not provide a
'Fedora Server Edition', but their own different concept and vision of
a server, under the name Fedora Server.
== Scope ==
* Proposal owners:
A kickstart file for ImageFactory is completed and locally tested.
* Other developers:
n/a
* Release engineering: [https://pagure.io/releng/issues #10768]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
n/a
== Upgrade/compatibility impact ==
none
== How To Test ==
Basically, the same test procedures as for the full install apply.
1. Install a Fedora Server Edition including virtualization, follow
the Server documentation
2. Import the Fedora Server disk image following the Server
documentation (staging), either using Cockpit or cli virt-install
3. Use the VM with your intendend server applications.
== User Experience ==
Users (system administrators) will have a VM install method available,
which saves them a lot of time and efforts.
== Dependencies ==
none
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No
== Documentation ==
N/A (not a System Wide Change)
Fedora Server documentation is available.
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 8 months
Retiring the pcre package from Fedora
by Lukas Javorsky
Hi,
As from the pcre-8.45, the upstream stopped supporting this library. The
recommended procedure is to switch onto the new pcre2 library that has full
upstream support. [1]
As a result of this announcement, the older PCRE library in Fedora will be
retired.
Without upstream support, we don't have enough capacity to keep up with the
security and bugs-related issues, and thus we will support only the new
PCRE2 library. [2]
The retirement procedure will happen in the upcoming weeks, so if you would
like to take over the package let us know.
The list of affected packages:
389-ds-base
389-ds-base-libs
EMBOSS-libs
Falcon
GMT
Io-language
Thunar
adanaxisgpl
aide
aircrack-ng
anope-pcre
bti
ccze
cegui
cegui06
clisp
clover2
clover2-devel
clover2-libs
coccinelle
compton
condor
condor-classads
cppcheck
cppcheck-gui
cyrus-imapd-libs
eterm
ettercap
freeradius
freeradius-utils
ganglia
ganglia-gmond
ghc-highlighting-kate
ghc-pcre-light
ghc-regex-pcre
gnome-builder
gnome-text-editor
grep
groonga-httpd
haxe
hydra
i3
i3-gaps
imapfilter
kdelibs
kdelibs3
kf5-kjs
kismet
libast
libeplplot
liblognorm
libmodsecurity
libprelude
lnav
mle
mod_auth_openid
mod_auth_openidc
mod_qos
mod_security
mod_security-mlogc
monotone
ncid
nekovm
ngrep
nmap
ocaml-pcre
octave
openCOLLADA
openscap
openscap-engine-sce
opensips
opensips-regex
pads
pcre-cpp
pdfgrep
perl
perl-HTML-Template-Pro
perl-re-engine-PCRE
picom
pl
poco-debug
poco-foundation
postfix-pcre
powwow
prboom-plus
prelude-lml
privoxy
python3-qutepart
python3-scss
rasqal
regexxer
remctl
root-core
rudiments
slang-slsh
sord
sslh
suricata
sway
swig
syncevolution-libs
syncevolution-libs-akonadi
syslog-ng
syslog-ng-mqtt
syslog-ng-slog
the_foundation
the_silver_searcher
tin
tintin
tinyfugue
trafficserver
uwsgi
vdr-epgfixer
watchman
wmweather+
xastir
xfce4-verve-plugin
xgrep
xmlcopyeditor
zabbix
zabbix-agent
zabbix-proxy-mysql
zabbix-proxy-pgsql
zabbix-proxy-sqlite3
zabbix-server-mysql
zabbix-server-pgsql
zsh
---
Thank you for understanding.
Lukas
[1] https://www.pcre.org/
[2] https://github.com/PCRE2Project/pcre2
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
1 year, 8 months
Need to rename package? libphidget -> libphidget22
by Richard Shaw
I am trying to update the libphidget package which has not been updated in
Fedora since 2014.
Apparently in 2017 the name was changed to "libphidget22" I'm guessing the
soversion being embedded in the library name, seems awfully Debian centric.
The bigger problem is the version was reset from something 2.x back to
1.0.0, the current version being 1.10.
I can bump the epoch easy enough but it still feels wrong. Should I rename
the package to libphidget22 and obsoletes/provide the original package?
The supplementary libraries also have "22" on the end:
https://www.phidgets.com/docs/OS_-_Linux#Source_Install-0
Click "Source Install" tab.
Thoughts?
Thanks,
Richard
1 year, 8 months
Missing LLVM stack bugfix updates in stable Fedora branches
by Fabio Valentini
Hi all,
Today I encountered another LLVM-specific bug that affects at least
one Rust package and causes non-working code to be produced, which
prompted this question:
Why are stable releases not getting bugfix releases of LLVM?
Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released.
Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have
been released.
Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet
(released over 3 weeks ago).
However, the llvm13 compat package that exists on Fedora 36+ *has*
been updated to version 13.0.1, so I'm not sure why this update wasn't
also pushed to Fedora 35, where LLVM 13 is the default, and would
benefit much more from bugfixes provided by 13.0.1.
Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc
on some architectures, mesa/llvmpipe) are an important part of our
stack, it seems bad that stable releases are missing out on several
bugfix updates for those critical packages.
I appreciate that updating ~a dozen packages for new LLVM point
releases is work, but I don't think having outdated LLVM components on
stable releases of Fedora is a good idea, either.
What can we do to improve this situation?
Fabio
1 year, 8 months
Help needed: build failure trying to upgrade healpix
by Mattia Verga
Hello folks,
I've been trying to update healpix package to latest version, so that I
can submit a PR to the package maintainer. Current version is a couple
of years old.
Unfortunately, the automated build process available in the package
itself isn't suitable for our needs, so each component (currently the
package provides Fortran, C, C++ and Java) must be compiled on its own.
Moreover, a library is bundled (libsharp), which is needed by the C++
component... there are some reasons why not unbundle it, I will not list
them here as they're not related to my request.
I did an heavy rewrite of the spec file to adapt to the new version and
I can build everything fine locally, but when I try a koji scratch build
it fails because the configure script of the C++ component cannot find a
cfitsio header. That's weird, because the C component is able to find
cfitsio and the header, while the C++ component finds cfitsio but not
the header...
I'm at a dead end, can someone have a look at the scratch build [1] and
explain me where's the fault?
Thanks
Mattia
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90263817
1 year, 8 months
future of dual booting Windows and Fedora, redux
by Chris Murphy
Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result:
1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer.
2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place.
The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849
It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration:
a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.
b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)
c. Change the release criterion.
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_d...
Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.
Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.
d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.
Thoughts?
--
Chris Murphy
1 year, 8 months
[HEADS UP] wxGTK 3.2.0 in Rawhide
by Scott Talbert
At long last wxWidgets 3.2.0 has been released and I'm getting it into
Rawhide. This comes with an soname bump (but this should be the last one
as 3.2.x should now be ABI stable).
NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged
to move their packages to use wxWidgets 3.2.
I've rebuilt these existing users in a side tag (f37-build-side-55557):
- CubicSDR
- audacity
- wxmacmolplot
I see that erlang also snuck in as a user recently. :) @Peter, can you
please rebuild erlang in side tag f37-build-side-55557? It should rebuild
fine without any changes (I tested in copr).
Thanks,
Scott
1 year, 8 months
GNOME 43.alpha builds in rawhide
by Kalev Lember
Hi all,
I'm back from my vacation and taking over GNOME builds and coordination
again this cycle (David King handled GNOME 42 builds during the last cycle).
Upstream is busily releasing 43.alpha and we need to get our downstream
builds done as well. We have a f37-gnome side tag for builds, which
should help make sure we keep rawhide breakage minimum (we can verify
that things roughly work before merging it).
This cycle the complicating elements seem to be:
- continued porting from gtk 3 to gtk 4
- libsoup to libsoup3 transition
- gnome-desktop3 and gnome-desktop4 soname bumps
The last two in particular affect much more consumers than just GNOME so
we need to be a bit careful here. Michael already filed a Change
Proposal for libsoup3 and it should hopefully get approved by FESCo
soon: https://pagure.io/fesco/issue/2829
Once we have FESCo approval for libsoup3 transition, I intend to go full
steam ahead with GNOME 43.alpha and libsoup3 builds. I have already done
a few in the side tag, but the rest is so tangled up that I think it's
easier to wait a bit.
If you are helping with builds, please use 'fedpkg build --target
f37-gnome'. There's no need to use it if the update really is stand
alone, but if it's tangled up in the rest of the GNOME update in some
way, please use the side tag so we can ensure we don't break rawhide.
Thanks for attention and thanks for the help!
Kalev
1 year, 8 months
Heads-up: libgnome-desktop soname bump
by Kalev Lember
Hi all,
libgnome-desktop (gnome-desktop3 rpm package) bumps its soname in
43.alpha release. This breaks the following packages that are currently
FTBFS in rawhide:
budgie-control-center-1.0.2-3.fc37.src.rpm
chatty-0.6.7-1.fc37.src.rpm
gala-6.3.1-3.fc37.src.rpm
gnome-flashback-3.44.0-1.fc37.src.rpm
phosh-0.20.0~beta2-1.fc37.src.rpm
These all already failed to build in the F37 mass rebuild last week. I
briefly looked at the build logs and most of these are failing due to
changed gnome_desktop_thumbnail_factory_generate_thumbnail() API that
now has grown GCancellable and GError out params. It should be fairly
straightforward to patch.
The gnome-desktop3 43.alpha update is already in rawhide, however it
currently has an ugly-ugly hack in place that provides the old soname
so that the packages that aren't rebuilt don't (yet) fail to install. My
plan is to remove that hack in 1 week's time which is going to properly
break the packages above.
Thanks for understanding and sorry for the trouble,
Kalev
1 year, 8 months
