devel August 2022

devel@lists.fedoraproject.org

196 participants
284 discussions

can't install package pipewire-jack-audio-connection-kit
by Martin Gansser 12 Mar '23

12 Mar '23

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

11 17

Planning to start unifying native and mingw packages
by Sandro Mani 09 Mar '23

09 Mar '23

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/

9 35

F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
by Ben Cotton 10 Feb '23

10 Feb '23

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.s… 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/0ee9a8… 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

8 19

F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth 07 Feb '23

07 Feb '23

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 == The `systemd-udev` package installs `"/usr/lib/systemd/network/99-default.link"`, which sets `Link.MACAddressPolicy=persistent`. This proposal is to change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address. This is particularly important for bridge and bond devices. This change can either only apply to bridge/bond devices, or to various software devices. That is to be discussed. == Owner == * Name: [[User:thaller|Thomas Haller]] (NetworkManager) * Email: <thaller(a)redhat.com> * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: <dmabe(a)redhat.com> == Detailed Description == On Fedora, udev by default changes the MAC address of a wide range of software devices. This was introduced by systemd 242 in early 2019 (Fedora 31), when `MACAddressPolicy=` was extended to affect more types of devices. With `MACAddressPolicy=persistent` udev's aim is to provide a stable MAC address, otherwise the kernel will assign a random one. However, that can cause problems: Firstly, software devices are always created by some tool that has plans for the device. The tool may not expect that udev is going to change the MAC address and races against that. The best solution for the tool is to set the MAC address when creating an interface. This will prevent udev from changing the MAC address according to the MACAddressPolicy. Otherwise, the tool should wait for udev to initialize the device to avoid the race. In theory, a tool is always advised to wait for udev to initialize the device. However, if it were not for MACAddressPolicy, in common scenarios udev doesn't do anything relevant for software devices to make that necessary. Secondly, for interface types bridge and bond, an unset MAC address has a special meaning to the kernel and the MAC address of the first port is used. If udev changes the MAC address, that no longer works. Now the generated MAC address is not directly discoverable as it is based on `/etc/machine-id` ([https://www.man7.org/linux/man-pages/man5/machine-id.5.html machine-id(5)]), among other data. Even if there were a tool to easily calculate the MAC address, it could be cumbersome to use it without logging into the machine first. The MAC address can directly affect the assigned IP address, for example when using DHCP. When booting a new virtual machine, the user might know the MAC address of the (virtual) "physical" interfaces. When bonding/bridging those interfaces, the bond/bridge would get one of the well known MAC addresses. `MACAddressPolicy=persistent` interferes with that. The goal of persistent policy is to provide a stable MAC address. Note that if the tool or user who created the interface would want a certain MAC address, they have all the means to set it already. That applies regardless whether the tool is iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor systemd-networkd rely on udev's MACAddressPolicy for setting the MAC address. This behavior is mostly useful for plain `ip link add`, but it's unclear which real world user wants this behavior. Of course, the user is welcome to configure the MAC address in any way they want. Including, dropping a link file that sets `MACAddressPolicy=persistent`. The problem is once udev sets a MAC address, it cannot be unset. Which makes this problematic to do by default. While Fedora inherited this behavior from upstream systemd, RHEL-9 does not follow this behavior ([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e… centos9], [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For RHEL-8, this doesn't apply because the systemd there is too old to change the MAC address of most software devices. This could be either implemented by patching `/usr/lib/systemd/network/99-default.link` to have a different policy, or by dropping a link file with higher priority. In the latter case, that override could be shipped either by udev or even by NetworkManager. Another option is to change the scope of this proposal to only change to `MACAddressPolicy=none` for the device types where this causes the most issues (bridge/bond/team). == Feedback == This was also discussed on upstream systemd mailing list [https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html here]. The upstream systemd maintainers' opinion is that the current udev behavior is desirable, but accepts that distributions (or network stacks such as NetworkManager) may choose to change the default depending on their needs ([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html reference]). The goal here is to find out what the Fedora community thinks is the most appropriate default. The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 [rh#1921094]]. == Benefit to Fedora == Pros: - Consistent behavior with RHEL8 and RHEL9. - Avoid race of udev and the tool that creates the interface. - Bridge and bond interfaces can get the MAC addresses from their first port. In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will get a MAC related to one of its physical NIC devices. In the case of provisioning new systems (especially in a large datacenter) information about the server can be used to configure the network environment (DHCP, Firewall, etc) before the server is ever even powered on. This does mean that you may have to update your network environment configuration if you replace a NIC (con), but that you won't have to update your network environment configuration if you re-install your server (pro), which is what you'd have to do now with `MACAddressPolicy=persistent`. Cons: - Deviate from upstream systemd. It is desirable that RHEL and Fedora behaves similar. A possible outcome could be the current behavior stays and RHEL 10 would change behavior. On the other hand, different distributions (or even Fedora spins) have different uses and needs. Deviating might be fine. In the same vein, there is also a desire to stay close to upstream systemd behavior. But the uses of systemd project go beyond Fedora/RHEL, so deviating here may also be fine. == Scope == * Proposal owners: The main goal of this request is to generate productive discussion and find the desired behavior. The implementation/changes are either way very simple. * Other developers: Other projects that wish a certain MAC address are welcome to set it for their devices. Including using udev's MACAddressPolicy. * Release engineering: Not needed for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == After the change, the MAC address for the affected device types changes. == How To Test == 1) Create a software device two times, for example `ip link add type bridge`. Note that the MAC address is either stable or random, depending on the `MACAddressPolicy=`. 2) Note that if the software device has the MAC address set initially, udev does not change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on `/sys/class/net/$dev/addr_assign_type`. 3) Create a bridge/bond interface without setting the MAC address. Note that if `MACAddressPolicy=none`, the MAC address is random at first. Note that attaching the first port will update the controller's MAC address. On the other hand, with `MACAddressPolicy=persistent`, the MAC address of the controller is fixed and not inherited from the port. 4) Run ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done to reproduce the race between a simple tool and udev changing the MAC address. == User Experience == Bond/bridge devices would again get assigned the MAC address of the first NIC added to the device. If we chose to not limit the scope of this change to just bonds/bridges then all software devices would get randomly assigned MAC addresses. == Dependencies == None. == Contingency Plan == If the change is rejected, nothing needs to be done. The change itself will be simple to implement. Contingency deadline: beta freeze Blocks release? No == Documentation == TODO. == Release Notes == -- Vipul Siddharth He/His/Him FPgM team member

13 28

x86_64-v2 in Fedora
by Neal Gompa 02 Feb '23

02 Feb '23

Hey all, Earlier this week, I was helping with processing features for openSUSE Leap 15.4[1] and I discovered that they're planning on introducing x86_64-v2 to openSUSE soon. The reference for this change was that RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions have been considering bumping up to v2 or v3[3][4]. Some cursory examination of the new x86_64 sublevels seem to indicate that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the first couple of generations of x86_64 CPUs from Intel and AMD. I personally don't have any computers that don't have support for x86_64-v2 anymore. Does anyone know if anyone is planning to propose this for Fedora anytime soon, either as an addon architecture (like what Arch is doing) or an upgrade of our x86_64 baseline like RHEL is doing? [1]: https://en.opensuse.org/Feature_Planning_15.4 [2]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-l… [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html [4]: https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-x86-64-v3-Po… -- 真実はいつも一つ！/ Always, there's only one truth!

32 61

FESCo wants to know what you use i686 packages for
by David Cantrell 17 Jan '23

17 Jan '23

Hi, Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?" Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information. Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds. NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~ If you use i686 packages for something now, please respond to this thread. Thanks, -- David Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

44 59

"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy 04 Jan '23

04 Jan '23

Summary---------- Most all Fedora variants (except Cloud) have a GRUB menu entry containing the word "rescue". This kernel+initramfs pair are never updated for the life of a Fedora installation. And they quickly become stale as a Fedora installation ages. This kernel's modules are eventually deleted, and if selected at boot time, the typical user experience is a dracut shell. Basic background------------- (skip this section if you know how it works) During a new installation, a single kernel version is installed. e.g. vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g. vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e. Each of those (identical) kernels has an initramfs file: initramfs-5.17.0-0.rc4.96.fc36.x86_64.img initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img The sole difference is the first one is a smaller host-only initramfs, the second one is a larger no host-only initramfs created with `dracut -N`. The bigger one just contains a bunch of extra kernel modules and dracut scripts, ostensibly to make it more likely to boot a system with some change in hardware that the host-only initramfs doesn't contain. The size of this rescue initramfs is around 100 MiB, with the common day to day "host only" initramfs being around 33 MiB. [1] As the system is updated, additional kernel versions are installed. dnf.conf contains installonly_limit=3, which results in a maximum of three kernel versions being installed at a time. Once a fourth kernel is installed, the first kernel and its modules are removed from /usr/lib/modules. The rescue kernel+initramfs pair are never updated or upgraded, even during system upgrades. Observations------------ This has been discussed by the Workstation working group [2] but since this functionality is present in all of Fedora, we're moving the discussion for greater visibility. There's two separate complaints, if you will: (a) that the kernel+initramfs pair are never update or upgraded for the life of the installation; and (b) that even during one release cycle, the user experience when booting the rescue entry, changes, i.e. when the matching /usr/lib/modules for the rescue entry are present early on, you do get a full runtime behavior, you will get to a graphical environment. But then once the version matched /usr/lib/modules are removed, you get a completely different behavior when booting the rescue entry. An important note from that ticket from Justin Forbes, the Fedora kernel maintainer: " Remember, the only real purpose of the rescue kernel is to get your system out of something completely unusable. It isn't meant to be a full runtime." Questions------------ * Considering the very narrow purpose of the entry, maybe the current behavior is adequate? * Does the rescue entry reliably get users to a dracut prompt, rather than indefinite hang? I don't know whether it does. * Is there any way to improve the situation without increasing the risk that the rescue entry becomes totally non-functional? * The chosen kernel version needs to be based on one that is known to boot. Currently we know the kernel+initramfs pair work because it's the same version used to boot the installation media when doing the initial provisioning. We don't actually know an updated replacement "no host-only" initramfs will work until it's tried. Is it possible to automate this? And is it worth the risk, or even figuring out how to assess the risk? * At Flock 2021, Zbyszek proposed "Building Initrd Images from RPMs" to reduce the complexity of building initramfs, maybe there's a role for it here? More: https://www.youtube.com/watch?v=GATg_bqmASc * What happens if we accept some scope creep, and go for many improvements that make the extra work worth it? * What about the unsigned nature of the initramfs? Should we be creating initramfs's in Fedora infra and signing them? * Stuff a graphical rescue environment into the initramfs? (This might be ten leaps too far, but it's intended to encourage thinking with a vivid imagination.) [1] both values from a recent Fedora 36 Workstation installation [2] https://pagure.io/fedora-workstation/issue/259 -- Chris Murphy

6 7

Orphaned X11 packages
by Adam Jackson 24 Dec '22

24 Dec '22

The following packages, previously owned by xgl-maint, are now up for grabs: xorg-x11-xfs xorg-sgml-doctools xorg-x11-drv-v4l xorg-x11-xsm xorg-x11-twm xorg-x11-drv-sisusb xorg-x11-xdm xorg-x11-docs Upstream development on all of these is pretty much nil, so if you're serious about picking up any of these you may also wish to take on the module upstream: https://gitlab.freedesktop.org/xorg - ajax

3 2

[apt-cacher-ng] Resurrect dead package
by Frédéric Pierret 23 Dec '22

23 Dec '22

Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb2… with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?r… still available for such case? Thank you. Best regards, Frédéric Pierret

3 3

Inactive packagers to be removed after the F37 release
by Ben Cotton 02 Dec '22

02 Dec '22

Hello everyone! I just completed the first run of FESCo's newly approved Inactive Packager Policy[1]. Packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the F37 final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) Since this is the first time we've done something like this, it could be a little rough. I appreciate your patience and understanding. If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: 2550 users checked 913 of those had no activity on src.fedoraproject.org or pagure.io 835 of those had no activity in Bodhi 812 of those had no activity on the mailing lists 606 of those (~24% of packagers) had no activity in Bugzilla. The script took a little under three hours to run. [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&sta… [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ 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.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

47 166

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2022