Conflicting build-ids in nekovm and haxe
by Andy Li
Hi list,
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c".
The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib".
Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it.
Please advice.
Best regards,
Andy
11 months, 2 weeks
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
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
F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth
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/c8953519504bf...
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
1 year, 2 months
FESCo wants to know what you use i686 packages for
by David Cantrell
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
1 year, 3 months
"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy
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
1 year, 3 months
Orphaned X11 packages
by Adam Jackson
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
1 year, 3 months