intent to hand over or orphan several scientific packages and their
build requirements
by Dominik 'Rathann' Mierzejewski
Hello!
I intend to hand over primary maintainership of the following packages
or orphan them if nobody steps up:
arpack
chemtool
cp2k
elpa
inchi
python-colorspacious
python-fypp
python-GridDataFormats
python-gsd
python-kaitaistruct
python-mmtf
python-mrcfile
python-Pympler
tachyon
wxmacmolplt
xdrawchem
I don't use them anymore, so I'm not a good maintainer for them.
Most, if not all above, are co-maintained by SciTech SIG already.
Please contact me if you want to take over one of these. Otherwise,
I will orphan them in the first week of the new year.
The packages are mostly in good shape, with the notable exceptions of
cp2k and elpa, but there's an open PR for cp2k to update and fix current
FTBFS.
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
5 months, 3 weeks
Turning a XImage * into a Drawable for use with XRenderCreatePicture
by Florian Weimer
The pcb-rnd package contains a call:
XRenderCreatePicture(display, lpm->img_scaled, XRenderFindVisualFormat(display, DefaultVisual(display, screen)), 0, 0);
The issue here is that lpm->img_scaled is an XImage *, but
XRenderCreatePicture expected a Drawable as its second argument.
Any idea how to turn an XImage into a Drawable?
Not sure how this currently works, but GCC 14 refuse to compile this, as
a C type error (using a pointer as an integer).
Thanks,
Florian
5 months, 3 weeks
ARM PAC on koji vs COPR
by Jarek Prokop
Hi,
recently Ruby 3.3 was released, we have noticed a failure to build on
COPR's aarch64:
https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fe...
https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fe...
But we do not observe these failures on koji (see e.g.
https://koji.fedoraproject.org/koji/taskinfo?taskID=111230891 )
What i have observed is that the hw_info.log reports different flags,
visually I'd say koji has half the CPU flags, despite koji reporting to be
the equal CPU model Neoverse-N1 of the vendor ID of ARM as does copr report.
More details regarding the failures:
According to upstream bug report [0] the culprit is change introducing
PAC/BTI support in some arm64 assembly [1] and the fix
to no longer have Ruby segfault is including
`ASFLAGS=-mbranch-protection=pac-ret` [2] in addition to the same flag
in XCFLAGS.
This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both CFLAGS
and ASFLAGS, I am unsure how it interacts with the Fedora defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the flag
with pac-ret seems to be appended to libruby.so in the case of the
upstream fix [2].
From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?
2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
up in the .so library and Ruby binary extensions link against that solib,
do the binary extensions also have to be compiled with that exact option?
3. If we do not fix this bug in Ruby 3.3.0 but wait with this for 3.3.1
where the fix will most probably land, will we by effect exclude a
subset of ARM CPUs,
that actually have the PAC capability, for that in-between period?
4. Why do koji and copr have CPU flag set that differs so much? Is our
koji infra OK?
5. Why does it fail on copr and does not fail on koji? It seems the
paca/pacg have to be present and set on the CPU flags for the segfaults
to occur.
I tried answering the last question when reading on that in kernel docs
[3], but I can't say I understand the text 100%.
Thanks,
Jarek Prokop
[0] https://bugs.ruby-lang.org/issues/20085
[1] https://github.com/ruby/ruby/pull/9306
[2] https://github.com/ruby/ruby/pull/9371
[3] https://www.kernel.org/doc/html/v6.4/arm64/pointer-authentication.html
5 months, 3 weeks
Schedule for Thursday's FESCo Meeting (2024-01-04)
by Stephen Gallagher
Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2024-01-04 17:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
Change: Wget2 as wget
https://pagure.io/fesco/issue/3118
APPROVED (+5, 0, -0)
Change: 389 Directory Server 3.0.0
https://pagure.io/fesco/issue/3120
APPROVED (+4, 0, -0)
Change: Systemd Security Hardening
https://pagure.io/fesco/issue/3117
APPROVED (+4, 0, -0)
Change: Linker Error On Security Issues
https://pagure.io/fesco/issue/3110
APPROVED (+4, 0, -0)
= Followups =
#3101 Change: Remove OpenSSL Compat
https://pagure.io/fesco/issue/3101
= New business =
#topic New Meeting Time
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
5 months, 3 weeks
Packed relative ELF relocations (DT_RELR) enabled by default in
rawhide
by Florian Weimer
This changed was originally planned and approved for Fedora 39. It
reduces startup time somewhat for large objects with lots of function
and object pointers in global data.
It should be a transparent change, internal to the toolchain. Within
glibc itself, we started using this linker feature in glibc 2.36 (Fedora
37), and no issues surfaced. A few dozen test rebuilds of core packages
did not show any issues, either.
Thanks,
Florian
5 months, 3 weeks
Error updating libvirt-dbus in F38
by Peter Boy
Just started to update one of our Fedora Servers (F38)
I got the message:
> Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
> Cleaning up : libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
> Executed scriptlet: libvirt-dbus-1.4.1-1.fc38.x86_64 124/132
> /var/tmp/rpm-tmp.BXEIBt: Zeile 1: fg: No Job control in this shell.
> Warning: %postun(libvirt-dbus-1.4.1-1.fc38.x86_64) Scriptlet failed, Exit-status 1
>
> Error in POSTUN scriptlet in rpm package libvirt-dbus
> Cleaning up : libacl-2.3.1-6.fc38.x86_64 125/132
Warning or error, what is it?
Can I be sure that a reboot will be successful?
My experiences with reports of this kind are quite mixed. From problem-free reboots to total failure, everything is possible. Unfortunately, reports of this kind do not exactly boost confidence in the reliability and usability of our Fedora.
We should improve this and make reports of problems clearer.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
5 months, 3 weeks
F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
by Aoife Moloney
Wiki -> https://fedoraproject.org/wiki/Changes/Enable_IPv4_Address_Conflict_Detec...
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 ==
Enable IPv4 Address Conflict Detection by default in NetworkManager.
== Owner ==
* Name: [[User:bengal| Beniamino Galvani]], [[User:ihuguet| Íñigo Huguet ]]
* Email: <bgalvani(a)redhat.com>, <ihuguet(a)redhat.com>
== Detailed Description ==
A common source of networking issues is the presence of duplicate IPv4
addresses in the same physical network. Such problems are quite
common, and at the same time hard to diagnose for users.
To the rescue comes [https://www.rfc-editor.org/rfc/rfc5227 RFC 5227]
(“IPv4 Address Conflict Detection”) which provides a mechanism to
detect address conflicts. A host implementing Address Conflict
Detection (from now on “ACD”) sends ARP probes for each IP address it
wants to use; if another host replies, the address is already in use
and can’t be configured on the interface.
Note that this mechanism applies to both static and DHCP addresses. It
might seem unnecessary for DHCP, as a well-behaving server should give
out unique leases; however, there could be hosts on the network not
using DHCP. Indeed, [https://www.rfc-editor.org/rfc/rfc2131 RFC 2131]
(Dynamic Host Configuration Protocol) specifies that the client should
probe the newly received address and should send a DHCPDECLINE to the
DHCP server if the address is already in use.
In Fedora 39, ACD is disabled by default; it can be enabled by setting
property “ipv4.dad-timeout” to a positive value in a connection
profile. The property name contains “DAD” which stands for “duplicate
address detection” and is another name of ACD. The property specifies
the maximum timeout in milliseconds used to check for the presence of
duplicate IP addresses on the network. If a duplicate is found, a
warning is logged; in the DHCP case, NetworkManager tries to get a
different lease, while in the static case, the address is just
skipped.
This change aims at enabling ACD by default in Fedora 40, by setting
the default value to 3000ms. Note that this change is only about IPV4;
IPv6 always performs a duplicate check for each address that is
configured, as specified by RFC 4862.
== Benefit to Fedora ==
NetworkManager will not configure IPv4 addresses that are detected as
duplicate. This will save users from having to debug weird
connectivity issues. Instead, NetworkManager will report an error and
will indicate the MAC of the conflicting host.
== Scope ==
* Proposal owners: change the default value, test that no regression
is seen in the upstream test suite.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The change in default behavior will affect all users that install or
upgrade to the new Fedora release.
== How To Test ==
To test the effect of the change on F39, add the following
configuration snippet to file
`/etc/NetworkManager/conf.d/20-ipv4-dad.conf` and then restart the
NetworkManager service:
[connection-dad-default]
ipv4.dad-timeout=3000
To trigger a conflict, configure the local machine with a static
address that is already in use by another host. When bringing up the
connection, it will fail and report an address conflict.
== User Experience ==
Enabling ACD will cause an additional delay when bringing up
interfaces, because NetworkManager needs first to probe the address.
The delay is between 1.5 and 3 seconds, because RFC 5227 requires that
the probe interval is randomized. The delay will affect both static
and DHCP connections.
In case users want to avoid this delay, ACD can be disabled for the
specific connection profile by setting property `ipv4.dad-timeout=0`,
or globally by adding the following configuration snippet to
`/etc/NetworkManager/conf.d/20-ipv4-dad.conf`:
[connection-dad-default]
ipv4.dad-timeout=0
Apart from this small delay, the big advantage of this change is that
users will be able to discover the potential conflict immediately. If
the address is static, the activation will fail and report an error.
For DHCP, NetworkManager will send a DHCPDECLINE message to the server
and it will try to get a different lease. In all cases, the
conflicting address will be skipped and the network will not be
brought in an inconsistent state.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The “nm-settings” man page will indicate the new default value. No
other documentation changes are required.
== Release Notes ==
The change needs to be mentioned in the release notes.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
5 months, 3 weeks