Offering strongswan for (co)maintaining
by Petr Menšík
Hello,
strongswan and NetworkManager-strongswan packages were passed to me from
previous maintainer. I admit I have little experience with them and do
not run any service based on them. Because IPSsec is quite complex
technology, I am looking for help with its maintenance. I was always
using OpenVPN based solutions myself, so I guess I am not the best
person as main admin. I would like to transfer main admin to anyone
doing a good job, not not immediately. That is why I haven't orphaned it
already.
I would like to keep commit access for a while, but I would share at
least commit access with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.
Regards,
Petr
--
Petr Menšík
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
2 years, 10 months
aom soname bump
by Robert-André Mauchin
Hi,
AOM AV1 version 3 has been published a while ago and I am planning to
update it in Fedora. Due to a CVE affecting versions prior to 2021-04-07
(CVE-2021-30473), I plan to push this update to ALL STABLE RELEASES:
https://bugzilla.redhat.com/show_bug.cgi?id=1961376
I intend to wait until 3.1.1 which fix a few compilation bugs, and wait
for jpeg-xl to be packaged to benefit from the new butteraugli tuning.
Affected packages as follows:
avidemux rpmfusion-free
cinelerra-gg rpmfusion-free
ffmpeg rpmfusion-free
go-avif fedora (should be retired)
gstreamer1-plugins-bad-free fedora
libavif fedora
libheif rpmfusion-free
rust-aom-sys fedora
seamonkey fedora
vlc rpmfusion-free
xine-lib rpmfusion-free
I will rebuild the affected packages using my PP.
Best regards,
Robert-André
p.s.: Leigh, I might need your help not to fuck up the repo in rpmfusion
like last time (if you explain me your process to keep the branches in
sync it would be nice).
2 years, 10 months
Intent to orphan maven-verifier-plugin
by Ben Cotton
I adopted maven-verifier-plugin because it was a transitive dependency
for condor back in December 2019. I did essentially nothing with it.
It is no longer a part of the dependency chain and is about to fall
victim to the Javapocalypse[1]. So I plan on orphan it at the end of
the week.
If anyone wants to pick it up (and thus adopt the dependencies
jackson-bom, jackson-parent, jackson-core, apache-ivy, spice-parent,
hawtjni, jackson-databind, jackson-annotations, aopalliance,
weld-parent, jakarta-server-pages, jansi-native, jakarta-interceptors,
snakeyaml), let me know before then and I'll just hand it over to you
instead.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
F35 Change: Make btrfs the default file system for Fedora Cloud
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FedoraCloudBtrfsByDefault
== Summary ==
For cloud installs of Fedora, we want to provide advanced file system
features to users in a transparent fashion. Thus, we are changing the
file system for the Cloud Edition to Btrfs so we can leverage its
features and capabilities to improve the quality of experience for
Cloud users.
== Owners ==
* Name: [[User:Davdunc|David Duncan]], [[User:Chrismurphy|Chris
Murphy]], [[User:Josef|Josef Bacik]], [[User:Salimma|Michel Alexandre
Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]],
[[User:Dustymabe|Dusty Mabe]], [[User:Malmond|Matthew Almond]]
* Email: davdunc(a)amazon.com, chrismurphy(a)fedoraproject.org,
josef(a)toxicpanda.com, michel(a)michel-slm.name, dcavalca(a)fb.com,
ngompa13(a)gmail.com, dusty(a)dustymabe.com, malmond(a)fb.com
* Products: Fedora Cloud Edition
* Responsible WGs: Fedora Cloud WG
== Detailed Description ==
Fedora Cloud Edition will switch to using Btrfs for its images. The
configuration for the Cloud Edition will match the setup used on the
desktop variants, as this has been very well-tested with production
deployments across multiple Fedora Linux releases now.
This includes the same subvolume layout that is used on the desktop
variants [[Changes/BtrfsByDefault|as introduced in Fedora Linux 33]],
as well as transparent Zstd compression
[[Changes/BtrfsTransparentCompression|as introduced in Fedora Linux
34]].
== Feedback ==
== Benefit to Fedora ==
The benefits are similar to
[[Changes/BtrfsByDefault#Benefit_to_Fedora|the ones for Fedora desktop
variants]]; however, there are specific benefits for Fedora Cloud:
* Adds support to Fedora Cloud for [[Changes/RPMCoW|the Change to
introduce support for Copy-on-Write enhancements to improve
performance to package management]]
* Adds the ability to logically separate contents of the volume
without dividing up the available space
** Transparent compression: significantly reduces write amplification
and improves effective I/O throughput
** Reflinks and snapshots improve efficiency for use cases like
containers (CRI-O, containerd, and Podman support both)
* Storage devices can be flaky, resulting in data corruption; Btrfs
can help mitigate this
** Everything is checksummed and verified on every read
** Corrupt data results in EIO (input/output error), instead of
resulting in application confusion, and isn’t replicated into backups
and archives
* Improves system responsiveness under pressure
** Btrfs has been tested in production to have proper IO isolation
capability via cgroups2
** Completes the resource control picture: memory, cpu, IO isolation
* File system resize
** Online shrink and grow are cornerstones of the Btrfs design
* Complex storage setups are… complicated
** Simple and comprehensive command interface. One master command
** Simpler to boot, all code is in the kernel, no initramfs complexities
** Simple and efficient file system replication, including incremental
backups, with <code>btrfs send</code> and <code>btrfs receive</code>
== Scope ==
* Proposal owners:
** Submit PRs for Cloud Edition kickstarts to produce disk images using Btrfs.
* Release engineering: [https://pagure.io/releng/issue/10129 #10129]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Change will not affect upgrades.
== How To Test ==
Once the change lands in Rawhide, spin up the images in AWS, GCP, and
KVM/OpenStack to test to see systems boot and run.
== User Experience ==
* Mostly transparent.
* Space savings and extend hardware life, via compression.
* Utilities for used and free space are expected to behave the same.
No special commands are required.
* More detailed information can be revealed by <code>btrfs</code>
specific commands.
* <code>cp</code> command will create reflink copies
[https://src.fedoraproject.org/rpms/coreutils/c/5d08d14b/ by default.]
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Owner will revert changes back to the
previous ext4 configuration
* Contingency deadline: Beta freeze
* Blocks release? Yes
* Blocks product? Cloud
== Documentation ==
Strictly speaking, no extra documentation is required reading for users.
== Release Notes ==
The default file system on the cloud is now Btrfs, following the
desktop change in Fedora Linux 33. Fedora Server, IoT, and CoreOS are
still specifically excluded.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
Fedora for WSL
by Greg Hellings
I may be hair-brained to do this, but I've put together an installer for
Fedora on WSL.
It mostly follows the procedures that had been much talked about in a blog
post about running Fedora 33 in the WSL2, but it uses the direct installer
rather than the manual side-loads. It also will install Fedora 34.
Obviously, it's not released into the Windows Store as that requires more
than just some technical bit wrangling. But if you're feeling adventurous,
and you are sometimes relegated to the world of Windows but want to bring
your Fedora along, you can find it here:
https://github.com/greg-hellings/FedoraWSL
Am I crazy? Yep.
Does it work? "Works in dev."
Anything to watch out for? It uses the trustywolf/wslu COPR repository for
installing WSL integration packages. Otherwise it's just raw Fedora bits.
Feel free to flame me if this was a terrible idea.
--Greg
2 years, 10 months
Heads Up: openexr 3.0 coming to Rawhide
by Richard Shaw
I'm currently in the process of testing all deps in my COPR. Assuming no
major issues are found I'll setup a side tag to perform all the builds. I
expect to be done by this coming weekend.
Affected packages are:
alembic
aqsis
bcd
blender
calligra
CTL
darktable
Field3D
freeimage
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
ImageMagick
kdebase3
kdelibs
kde-runtime
kf5-kimageformats
kio-extras
krita
luminance-hdr
luxcorerender
opencv
OpenImageIO
OpenSceneGraph
openshadinglanguage
openvdb
pfstools
povray
prusa-slicer
synfig
synfigstudio
vigra
vips
YafaRay
Thanks,
Richard
2 years, 10 months
RPMLint 2.0 released!
by Neal Gompa
Hey all,
Nearly four years and *754 commits* since rpmlint 1.10, we are
releasing rpmlint 2.0.0!
This new release has a _lot_ of new features, but here are the most notable:
* RPMLint now is a "normal" Python application and now supports being
imported like a standard Python module! This means that all the normal
use-cases for RPMLint are still supported, but now you can make it a
part of larger Python-based applications or services.
* RPMLint uses a declarative TOML-based syntax for configuring RPMLint
policy instead of Python code.
* RPMLint now has an override system for the descriptions shown for
various checks, so that distributions who want to give specific policy
information can do so without patching the code.
* RPMLint includes _many more checks_! Nearly all of the generally
useful checks created by the openSUSE community have been merged into
the tree, so distributions can now benefit from a wider offering of
checks to implement policy enforcement.
* RPMLint is Python 3 only and now supports Python 3.6 and newer.
* RPMLint is now built and installed like a standard Python
application using setuptools.
I want to specifically thank Tomáš Chvátal, Martin Liska, Kristyna
Streitova, Dirk Mueller, Miroslav Suchý, Ondřej Súkup, thisisshub, and
Miro Hrončok as top contributors to make this release happen!
Full author list with number of commits:
309 Tomáš Chvátal
197 Martin Liska
47 Dirk Mueller
26 Kristyna Streitova
24 Neal Gompa (ニール・ゴンパ)
24 marxin
21 Neal Gompa
21 Ondřej Súkup
14 thisisshub
11 Miro Hrončok
9 Kristýna Streitová
8 Miroslav Suchý
6 Markéta Calábková
5 Ville Skyttä
4 Ben Greiner
4 Frank Schreiner
4 Van de Bugger
3 David Greaves
3 Matwey V. Kornilov
2 Daniel Mach
2 Matthias Gerstner
1 Cathy Hu
1 Ludwig Nussel
1 MeggyCal
1 Petr Menšík
1 Stefan Brüns
1 Steve Kowalik
1 Werner Fink
1 Wolfgang Stöggl
1 Yanko Kaneti
1 tpgxyz
--
真実はいつも一つ！/ Always, there's only one truth!
2 years, 10 months
hamcrest update to 2.2 in Fedora rawhide
by Mikolaj Izdebski
Hello,
Next week I'm going to update package hamcrest in Fedora rawhide from
version 1.3 to version 2.2.
The proposed update contains an API change that can affect packages
depending on hamcrest. You may need to rebuild your packages to keep
working with updated hamcrest.
The update has already been checked into dist-git and a Koji build has
already been done, but Bodhi update has not been submitted yet. Bodhi
update is expected after a week, to comply with Updates Policy that
mandates a notification one week in advance before submitting an API
changing update.
Current NVR in rawhide: hamcrest-1.3-31.fc34
Updated NVR: hamcrest-2.2-3.fc35
Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364
Packages depending on hamcrest that are possibly affected by this update:
* eclipse, maintained by lef jerboaa dbhole rgrunber jjohnstn
akurtakov ebaron oliver mbooth arobinso
* freemarker, maintained by filiperosset
* hamcrest, maintained by akurtakov mizdebsk jerboaa
* hdf, maintained by sagitter orion
* hdf5, maintained by deji sagitter orion ignatenkobrain
* icedtea-web, maintained by jvanek dbhole omajid
* jmock, maintained by orphan
* openas2, maintained by sdgathman
* py4j, maintained by raphgro
--
Mikolaj Izdebski
2 years, 10 months
📦 Advice on packaging azure-cli
by Major Hayden
👋🏻 Hello there,
I'm eager to package Azure's CLI tools for Fedora that would allow users
to manage their Microsoft Azure cloud infrastructure. This would help
with CI/CD, information security, monitoring, and of course, deployments.
However, these cloud tools are a bit tricky to package. There are a few
python components in the main repository[0] that make up the CLI itself:
azure-cli
azure-cli-core
azure-cli-telemetry
Those seem fairly straightforward, but things get complicated because
those three depend on *plenty* of little SDK components from another
repository[1]. That repository contains over 220 SDK components that all
release independently from the same git repository. They also have
dependencies on some other bits of python that are already packaged for
Fedora, such as cffi, cryptography, and PyYAML.
To make things a bit more complicated, the core CLI tools have strict
dependencies on specific versions of the SDK components. For example:
'azure-mgmt-datamigration~=4.1.0',
'azure-mgmt-deploymentmanager~=0.2.0',
'azure-mgmt-devtestlabs~=4.0',
'azure-mgmt-dns~=8.0.0',
At first glance, that doesn't seem too bad since the versions of the
core CLI tools and SDK versions move in tandem in the repositories. SDK
components are constantly moving forward, but the CLI releases are tied
to specific SDK component versions which do not change after release.
The dependency tree is fairly long[2], but it's also fairly standard
between most of the SDKs.
I have several questions here:
1) Should I make separate Fedora packages/specs for each CLI
component and the SDK components? The SDK components look
nearly identical from a packaging standpoint (no executables
there, just libraries in each). If so, that would be about
80-100 packages to make and maintain.
2) Should I 'vendor' the SDK components into a single package and
set it as a dependency of the core CLI tools?
3) Should I dynamically generate spec files for the SDK components
based on the requirements from the main CLI tools?
4) Am I making this much, much more difficult than it really is? 🤦🏻♂️
Thanks in advance for any guidance you have. 🤗
[0] https://github.com/Azure/azure-cli
[1] https://github.com/Azure/azure-sdk-for-python
[2] https://gist.github.com/major/821e2f90c8a2b6111a42e35503caa3ad
--
Major Hayden
2 years, 10 months
F35 Change: Replace SDL 1.2 with sdl12-compat using SDL 2.0
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SDL12onSDL2
== Summary ==
This Change proposes to replace SDL 1.2 with sdl12-compat, which uses SDL 2.0.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
SDL 1.2 development ended long ago, with SDL 2.0 replacing it.
However, many older games still use SDL 1.2 and cannot change to SDL
2.0. In order to help move SDL 1.2 games into the modern world, let's
replace SDL 1.2 with sdl12-compat, which uses SDL 2.0.
== Benefit to Fedora ==
Switching SDL 1.2 powered games to use <code>sdl12-compat</code>
offers significant advantages:
* Automatic support for Wayland with SDL 2.0.16+
* Native support for PipeWire for audio
* Massively improved support for inputs (including gamepads)
Ultimately, SDL 2.0 is actively maintained and developed. We want
applications that use SDL to use an actively maintained codebase.
== Scope ==
* Proposal owners:
** Package [https://github.com/libsdl-org/sdl12-compat
libsdl12-compat] ([https://bugzilla.redhat.com/show_bug.cgi?id=1960960
RH#1960960])
** Adjust {{package|SDL}} to not ship the main library package and use
the one from <code>libsdl12-compat</code>
** Once [https://github.com/libsdl-org/sdl12-compat/issues/34
replacement development headers are available], retire {{package|SDL}}
completely.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/10118 #10118]
* 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 ==
The <code>SDL</code> package would be transparently upgraded to
<code>libsdl12-compat</code> package and games using it should just
transparently start using SDL 2.0.
== How To Test ==
1. Swap <code>SDL</code> for <code>sdl12-compat</code>: <code>dnf swap
SDL sdl12-compat</code>
2. Run something that uses SDL 1.2 like {{package|quake3}} and see
that it works.
== User Experience ==
There shouldn't be a noticeable user impact, other than possibly a
smoother experience because applications are using SDL 2.0.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Restore the <code>SDL</code> package in
{{package|SDL}}. If {{package|SDL}} has been fully retired, then
unretire it.
* Contingency deadline: Final Freeze
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Games that use SDL 1.2 will now transparently use SDL 2.0 through the
<code>sdl12-compat</code> package. This makes it so applications that
historically used SDL 1.2 now use SDL 2.0.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
