RPM build error on Rawhide
by Vitaly Zaitsev
Hello all.
RPM build errors:
File must begin with "/": %{_javadir}/pycharm-community
F33 and F34 were built fine.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2 years, 10 months
Strange error from koji
by Ron Olson
Hey all, I’m trying to build my package for EPEL and got a strange error
clang-11: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]
clang-11: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Werror,-Wunused-command-line-argument]
https://kojipkgs.fedoraproject.org//work/tasks/653/69120653/build.log
The relevant section of the spec file is:
%build
export CXX=clang++
export CC=clang
%cmake -G Ninja .
%cmake_build
Is this a bug, or something I’m doing wrong? If it is a bug I’d be happy to file a ticket in Bugzilla, but I’m not sure which project to file it under.
Ron
2 years, 10 months
doxbox-staging package conflict
by Vitaly Zaitsev
Hello all.
doxbox-staging is trying to overwrite the regular dosbox package:
Installing:
dosbox-staging x86_64 0.76.0-2.fc34
fedora 1.4 M
replacing dosbox.x86_64 0.74.3-7.fc34
From its SPEC[1]:
# This package is a drop-in replacement for dosbox
Provides: dosbox = %{version}-%{release}
Obsoletes: dosbox < 0.74.4
Is this Okay? These packages has different maintainers. According to the
Fedora packaging guidelines, one package cannot introduce conflicts with
another.
[1]:
https://src.fedoraproject.org/rpms/dosbox-staging/blob/rawhide/f/dosbox-s...
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
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
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
2 years, 10 months