can't install package pipewire-jack-audio-connection-kit
by Martin Gansser
Hi,
when trying to install pipewire-jack-audio-connection-kit i get this error message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- conflicting requests
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
How can i fix this ?
Regards
Martin
1 year, 1 month
Planning to start unifying native and mingw packages
by Sandro Mani
Hi
Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:
eigen3 mingw-eigen3
enchant2 mingw-enchant2
freeimage mingw-freeimage
gdal mingw-gdal
GeographicLib mingw-GeographicLib
geos mingw-geos
giflib mingw-giflib
gtkspell3 mingw-gtkspell3
gtkspellmm30 mingw-gtkspellmm30
jxrlib mingw-jxrlib
leptonica mingw-leptonica
libgeotiff mingw-libgeotiff
libimagequant mingw-libimagequant
libkml mingw-libkml
librttopo mingw-librttopo
libspatialite mingw-libspatialite
libwebp mingw-libwebp
openjpeg2 mingw-openjpeg2
OpenSceneGraph mingw-OpenSceneGraph
osgearth mingw-osgearth
podofo mingw-podofo
proj mingw-proj
python-pillow mingw-python-pillow
qtspell mingw-qtspell
shapelib mingw-shapelib
svg2svgt mingw-svg2svgt
tesseract mingw-tesseract
uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building
there, if there are no objections, I plan to push to F37 and retire all
the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
1 year, 1 month
Assess impact of package changes with the mass prebuilder
by Frederic Berat
Hello Fedora community,
The Christmas period is coming, and soon after the Fedora mass rebuild will
come and may lead to the creation of a bunch of FTBFS bugzillas.
I'd like to share with you the availability of a tool that we started to
develop this year, which aims to help developers to assess the impact a
change in their component will have on other components that depend on
them.
I recently used it in order to prepare for the upcoming Autoconf 2.72
release, and with it uncovered about 84 build failures (out of 1197
packages depending on Autoconf) that would have been missed if I were
following the "classical" workflow. This resulted in few bugs opened in
corresponding components, and even upstream changes toward the Autoconf
community, prior to the official 2.72 release.
In the past weeks, it has also been used to assess the impact of porting
Fedora to Modern C (by Florian Weimer) which tested about 10k packages and
for the make 4.4 update (from DJ Delorie), which tested about 9k
dependencies against this new version to look for breakage.
Yet, the more users there will be, the more this tool will improve and be
useful for the packagers.
This tool is called the mass prebuilder. I've written a blog post for Red
Hat a while ago, which already contains a lot of details about it:
https://developers.redhat.com/articles/2022/09/26/find-errors-packages-th...
There is a COPR package available to ease installation:
https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
And a detailed Howto available in the source README:
https://gitlab.com/fedora/packager-tools/mass-prebuild/-/blob/main/README.md
As of today, the tool provides most of the planned features, although it
only uses COPR as a builder backend, whereas Koji is also planned on the
long run (and likely others).
Since the tool is fairly new, it lacks manpages, may miss features you
would expect and is likely to have bugs (even if we tried to limit them as
much as possible).
Therefore, don't hesitate to open issues in the Gitlab repository if need
be: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues.
Frédéric Bérat
Senior Software Engineer, Platform Tools
Red Hat <https://www.redhat.com>
fberat(a)redhat.com
<https://www.redhat.com>
1 year, 1 month
OpenSSH: hardening hostkeys permissions
by Dmitry Belyavskiy
Dear colleagues,
Many years ago we implemented the patch
https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5
Unfortunately, as it was 11 years ago, we can't find the exact explanation
where the requirement came from. We think that we intended to increase
security, but it probably caused more confusion than gain of the security
over the years.
The patch allows more relaxed permissions for the private keys than
upstream OpenSSH permits - 0640 instead of 0600, and the key file must
belong to the ssh_keys group. The ssh_keysign utility was simultaneously
changed from suid root to sgid ssh_keys.
The side effect of this solution is that ssh with host based auth (HBA)
started to fail after changing group ID ( with newgrp, etc.). In the case
of HBA ssh invokes ssh-keysign that does a lot of sanity checks including
group checks. The workaround is returning setuid bit instead of sgid, and
we recommend it to our clients.
Some more information is available in
https://bugzilla.redhat.com/show_bug.cgi?id=1498845
As this problem affects several clients, and it is a deviation from
upstream (the similar patch was rejected by upstream), we want to drop this
downstream patch in Fedora. We also can get rid of a designated ssh_keys
group
The problem we expect is that after reverting the patch we can lose the
remote access to the hosts because sshd will reject starting because of
group reading permissions. This should be covered by the upgrade scriptlet,
though we still may come across some issues, especially if you use host
keys in non-standard locations. How do we properly implement this feature
to avoid customers' negative feedback? Current upgrade scriptlet covers
standard key locations/names and works well enough at the 1st glance.
The proposed changes are available
https://src.fedoraproject.org/rpms/openssh/pull-request/37
A separate question is whether we want to publish this announcement as a
Fedora change and at what level. For me it looks like a self-contained
change.
--
Dmitry Belyavskiy
1 year, 1 month
Small rant: installer environment size
by Adam Williamson
Hi folks! Today I woke up and found
https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me
down a bit of an "installer environment size" rabbit hole.
As of today, with that new dep in webkitgtk, Rawhide's network install
images are 703M in size. Here's a potted history of network install
image sizes:
Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M)
Fedora 13: 208M
Fedora 17: 162M (last "old UI")
Fedora 18: 294M (first "new UI")
Fedora 23: 415M
Fedora 28: 583M
Fedora 33: 686M
Fedora 37: 665M
Fedora Rawhide: 703M
The installer does not really do much more in Rawhide than it did in
FC8. Even after the UI rewrite in F18, we were only at 294M. Now the
image is well over 2x as big and does...basically the same.
Why does this matter? Well, the images being large is moderately
annoying in itself just in terms of transfer times and so on. But more
importantly, AIUI at least, the entire installer environment is loaded
into RAM at startup - it kinda has to be, we don't have anywhere else
to put it. The bigger it is, the more RAM you need to install Fedora.
The size of the installer environment (for which the size of the
network install image is more or less a perfect proxy) is one of the
two key factors in this, the other being how much RAM DNF uses during
package install.
So, I did a bit of poking about into *what* is taking up all that
space. There's a variety of answers, but there's two major culprits:
1. firmware
2. yelp (which pulls in webkitgtk and its deps)
I've been using du and baobab (the GNOME visual disk usage analyzer,
which is great) to examine the filesystems, but I ran a couple of test
builds to confirm these suspects, especially after the impact of
compression (it's hard to check the *compressed* size of things in the
installer environment directly).
I did a scratch build of lorax which does not pull in firmware
packages, and had openQA build a netinst using that lorax. It came out
at 489M - 214M smaller than current netinsts, a size we last managed in
Fedora 26. I did a scratch build of anaconda with its requirement of
yelp dropped (which would break help pages), and built a netinst with
that; it came out at 662M - 41M smaller than current images. I haven't
run a combined test yet, but it ought to come out around 448M, around
the size of Fedora 24.
Even then we'd still be about 50% larger than the Fedora 18 image, for
not really any added functionality.
I've moaned about the sheer amount and size of firmware blobs in other
forums before, but 214M compressed is *really* obnoxious. We must be
able to do something to clean this up (further than it's already
cleaned up - this is *after* we dropped low-hanging fruit like
enterprise switch 'firmwares' and garbage like that; most of the
remaining size seems to be huge amounts of probably-very-similar
firmware files for AMD graphics adapters and Intel wireless adapters).
I know some folks were trying to work on this (there was talk that we
could drop quite a lot of files that would only be loaded by older
kernels no longer in Fedora); any news on how far along that effort is?
Other obvious things that take up a lot of space:
1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is
224M uncompressed. A quick test just compressing the file with xz on my
system shows it compresses to around 11M, though, so that's probably
all it adds up to after compression (the image is an xz-compressed
squashfs)
2. /usr/lib64/libLLVM-15.so, which is 114M on its own, compresses to
23M. We are, I think, basically stuck with this for mesa-dri-drivers ,
but does it have to be so *big*?
3. libicudata.so.71.1 - 30.4M, compresses to 7M. This is in the
webkitgtk dep chain but seems to still be pulled in without it, not
sure what else is requiring it.
4. /usr/share/locale - 112M in total (uncompressed, not sure how much
compressed) of translated strings from a ton of packages. No idea how
many of these are really *needed* in the installer environment. We can
maybe come up with a way to have lorax strip some, if we can come up
with a viable way to figure out which. Obviously-fairly-large ones are
from gnupg2 and libgweather4. I do recall we have some logic somewhere
to decide which languages have a certain level of translation in
anaconda; perhaps we could only include the strings for these
languages?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 2 months
F38 proposal: Add Fedora Auto Firstboot Services to desktop variants
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
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 ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.
== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.
== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
<code>fedora-autofirstboot.service</code>
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/11148 #11148]
* 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 ==
This will have no impact on upgraded systems, since the firstboot
condition is not true in that case.
== How To Test ==
# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see <code>openh264</code> is installed and
<code>anaconda-core</code> is not.
== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.
== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.
== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.
== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
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 ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt...
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects -ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions -fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches -grecord-gcc-switches
%_flag_pipe -pipe
%_flag_wall -Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9...
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the correct
flags are still being used.
* Other developers:
** Other developers may, but are not required to, update their
packages to use the new macros.
* Release engineering: [https://pagure.io/releng/issues/10819 #10819]
* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None.
== How To Test ==
* This can be tested by inspecting the value of the %{build_cflags},
%{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring
they are the same before and after the change.
* This can be tested by modifying some of the new macros in a spec
file and ensuring that the changes appear in the appropriate macro
mentioned above.
== User Experience ==
This is a change for developers and will have no impact to the user experience.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Change owner
will revert the update to redhat-rpm-config.
* Contingency deadline: Mass Rebuild
* Blocks release? N/A (not a System Wide Change), No
== Documentation ==
None.
== Release Notes ==
None.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
MuseScore 4.0
by Jerry James
MuseScore is music composition and notation software, currently
available from Fedora in the mscore package. Version 4.0 was just
released. If anybody would like to try it out, it is available from
this COPR: https://copr.fedorainfracloud.org/coprs/jjames/MuseScore4/.
I do not intend to build for Fedora until some issues have been worked
out.
WARNING! WARNING! WARNING!
DO NOT TRY THIS IN A WAYLAND SESSION. It will run for anywhere from a
few seconds to a few minutes, then abruptly exit with a "Protocol
error". Run an X session to try MuseScore 4.0.
WARNING! WARNING! WARNING!
WARNING! WARNING! WARNING!
Configuration for MuseScore 3.x and 4.x differs in some important
respects. You may have to do a "factory reset" when switching
versions. Run "mscore -R" or "mscore -F" if it won't start. This
will clear out your list of recently opened scores, for example, so
backup your configuration before you do this.
WARNING! WARNING! WARNING!
To try it out, run:
sudo dnf copr enable jjames/MuseScore4
sudo dnf install musescore
Please try the video export option, which has bitrotted upstream. I
have attempted to update it for current ffmpeg. Please let me know if
it does or does not work for you. If it works well, I will submit my
patch upstream. Do this: "mscore --score-video <path_to_score> -o
filename.mp4", and optionally try the --resolution and --fps
arguments. Run "mscore --help" for more information. This
functionality does not seem to be available via the GUI.
Upstream bundles fluidsynth, apparently for the sole purpose of
implementing a caching soundfont loader that uses internal fluidsynth
APIs. I have unbundled fluidsynth for this repository, which means
there is no soundfont cache. If you switch soundfonts frequently,
please let me know if the performance is acceptable. If you are
familiar with the fluidsynth API and can implement a caching soundfont
loader using only public APIs, please do so and submit it upstream.
Several other products are bundled (beatroot-vamp, dtl, intervaltree,
rtf2html, and KDDockWidgets). Each of them has either been altered by
the MuseScore developers or, in the case of KDDockWidgets, internal
APIs are used so extensively that I cannot see how to unbundle
successfully. Thoughts on how any of these products might be
unbundled are welcome.
The COPR version makes a long-requested change: the package name
changes from mscore to musescore. Let me know if you encounter any
problems arising from that change.
A new font package is needed to build version 4.0 for Fedora. I would
appreciate a review from anybody who feels competent to review a font
package: https://bugzilla.redhat.com/show_bug.cgi?id=2152347. There
is a question about the appropriate foundry name. If you can help
answer that question, please chime in.
Regards,
--
Jerry James
http://www.jamezone.org/
1 year, 2 months
