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
1 year, 8 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!
1 year, 8 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
1 year, 8 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
1 year, 8 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
1 year, 8 months
IRC Announcement
by Nick Bebout
Since its beginnings, the Fedora Project has used the freenode IRC network
for our project communications. Due to a variety of recent changes to that
network, the Fedora Project is moving our IRC communications to Libera.Chat.
If you are a current IRC user, please go and register your nick(s) on
Libera.Chat ( https://libera.chat/guides/registration#registering ) and
rejoin the #fedora related channels you wish to. You can take this
opportunity to choose a new secure password and make sure you are
connecting via SSL. There is good documentation about choosing an IRC
client at https://libera.chat/guides/clients
If you are a Matrix user, we ask for your patience as we get bridges setup
on the new network. If you were joined to rooms via the generic freenode
bridge, you will need to leave them and rejoin the fedora rooms in matrix
(which will be plumbed with the Libera channels)
As of 2021-05-28 our official IRC presence is on irc.libera.chat.
Many Fedora channels have moved over and are ready on Libera.Chat. However,
less-used channels have not be automatically setup. If you need a specific
#fedora-* IRC channel setup, please file a ticket at http://pagure.io/irc
requesting the channel.
New channels should have the same name as they did on freenode. For
example: #fedora, #fedora-admin, #fedora-devel, and #fedora-join.
If you would like a fedora IRC ‘cloak’ you can request it at:
https://fedoraproject.org/wiki/LiberaCloaks
(an IRC cloak obfuscates your client host address and shows ‘fedora’
instead). Please note that cloaks are not foolproof, there are ways for
people to still get your IP, but they do make it more difficult for people
to obtain your IP.
Also, look for upcoming exciting announcements around Fedora’s Matrix
presence.
nb
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1 year, 8 months
Building for EPEL-8 and CMake (again)
by Ron Olson
Hey all-
Awhile back I asked about the status of CMake in CentOS so I could build my packages for EPEL-8; they require a version of CMake that is greater than 3.11.4 which is currently available. CentOS Stream has a later version, as does RHEL 8.4. I get that CentOS Stream is the future of CentOS, but when I run a koji build for EPEL 8 it uses CentOS 8, not CentOS Stream and thus all my builds fail.
TL;DR: How can I build anything for EPEL 8 with CMake if the package is too old?
Thanks!
Ron
1 year, 8 months
F35 Change: Support using a GPT partition table in Kickstart
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
== Summary ==
Add support for configuring GPT partition table in kickstart without
requiring a custom pre-installation script or a custom boot script.
[[Category:SystemWideChange]]
== Owners ==
* Name: [[User:Davdunc|David Duncan]], [[User:Chrismurphy|Chris
Murphy]], [[User:Salimma|Michel Alexandre Salim]],
[[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]],
[[User:Dustymabe|Dusty Mabe]]
* Email: davdunc(a)amazon.com, chrismurphy(a)fedoraproject.org,
michel(a)michel-slm.name, dcavalca(a)fb.com, ngompa13(a)gmail.com,
dusty(a)dustymabe.com
* Products: Fedora Cloud Edition
* Responsible WGs: Fedora Cloud WG
== Detailed Description ==
Fedora Cloud Edition wants to use a GPT partition table; however, it
is not possible
to force the creation of an image with the GPT partition table with
our current tooling
because Anaconda requires setting <code>inst.gpt</code> as a kernel
boot parameter
to do it. This Change proposes to add a way to declare this via kickstart so
that the Cloud Edition image builds can create images using the GPT
partition table
using the current tooling (which is built on Anaconda).
== Benefit to Fedora ==
Users will be able to install systems with a GPT partition table via
kickstart without
requiring an extensive custom pre-installation script or a custom boot
script. Disk images
produced using the Anaconda tooling (Oz/ImageFactory, Lorax) can also
trivially make
images with GPT partition tables. This makes it possible to create
hybrid BIOS+UEFI boot
images, given [[Changes/UnifyGrubConfig|the changes to GRUB
configuration from Fedora Linux 34]].
== Scope ==
* Proposal Owners
** Review and discuss with the Anaconda maintainers and determine the
next steps for support of the inst.gpt in pykickstart
** Work with Anaconda maintainers to implement in Anaconda
* Release engineering: [https://pagure.io/releng/issue/10137 #10137]
* Policies and guidelines: N/A
* Trademark approval: N/A
== How to test ==
Build images using virt-install with kickstarts that have the option
set. Verify that the disk partition table is properly configured as
GPT. Verify that without the option set, it uses legacy MBR.
== User Experience ==
* Allows for the use of the standard pykickstart directive for
specifying the preference for GPT partition.
== Dependencies ==
* Anaconda [https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#ins...
inst.gpt]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 8 months
texlive 2021 landing in Rawhide
by Tom Callaway
Hi Fedorans,
Just a heads-up, texlive-base (where the compiled code and immediate
dependencies lives) and texlive (where the thousands of other noarch
components live) have been updated to TeXLive 2021 in Rawhide (and the
latest available components from CTAN at the time I did the work).
I've done local testing and everything seems to still work, but inevitably,
the act of updating TeXLive breaks things, so if your packages have TeX
dependencies and stop building in rawhide, let me know.
Also, FWIW, I have no plans to bring this back to any stable branches.
TL2020 is doing well enough there for now.
Thanks in advance for your patience,
~spot
P.S. Please don't start the "WHY THE #$%& does texlive make so many
subpackages" thread unless you're sending me money, fine alcohol, or
patches.
1 year, 8 months
Intent to retire - findbugs / findbugs-bcel / findbugs-contrib / eclipse-findbugs
by Richard Fearn
Hi everyone,
I'm writing to say that I intend to retire the following packages:
* findbugs
* findbugs-bcel
* findbugs-contrib
* eclipse-findbugs
The rationale behind this is:
* The last FindBugs release was in March 2015 [1].
* Upstream has been dead since 2016 [2].
* The project was forked in 2017 [3] as SpotBugs [4].
* FindBugs depends on an old snapshot of Apache Commons BCEL (packaged as
findbugs-bcel). I don't think it's possible (or worthwhile) to get FindBugs
to build against upstream BCEL.
* It no longer builds against the latest rawhide versions of ASM and
Hamcrest.
* Trying to maintain FindBugs and keep it building/working against the
latest versions of Java libraries isn't really a good use of anyone's time
(and there is no upstream to contribute patches back to).
* findbugs-contrib (known upstream as fb-contrib [5]) is a FindBugs plugin
that provides additional detectors, and is of no use without FindBugs
itself.
* Likewise, eclipse-findbugs makes FindBugs available in the Eclipse IDE,
and is of no use without FindBugs being available.
As far as I can tell, nothing else depends on this set of packages:
$ sudo dnf repoquery --recursive --whatrequires findbugs
Last metadata expiration check: 1:11:19 ago on Sat 29 May 2021 23:00:52 BST.
ant-findbugs-0:3.0.1-25.fc34.noarch
eclipse-findbugs-0:3.0.1-23.fc34.noarch
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
findbugs-tools-0:3.0.1-25.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires findbugs-bcel
Last metadata expiration check: 1:11:24 ago on Sat 29 May 2021 23:00:52 BST.
ant-findbugs-0:3.0.1-25.fc34.noarch
eclipse-findbugs-0:3.0.1-23.fc34.noarch
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-0:3.0.1-25.fc34.noarch
findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
findbugs-tools-0:3.0.1-25.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires findbugs-contrib
Last metadata expiration check: 1:11:31 ago on Sat 29 May 2021 23:00:52 BST.
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires eclipse-findbugs
Last metadata expiration check: 1:11:39 ago on Sat 29 May 2021 23:00:52 BST.
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
It's been interesting keeping FindBugs alive since I picked it up in 2010
(11 years ago... where has the time gone?!), but the world has moved on (to
SpotBugs), and I think it's time to let it go.
Regards,
Rich
[1] http://findbugs.sourceforge.net/
[2]
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/00432...
[3]
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2017-September/0043...
[4] https://spotbugs.github.io/
[5] https://github.com/mebigfatguy/fb-contrib
--
Richard Fearn
richardfearn(a)gmail.com
1 year, 8 months
