devel January 2024

devel@lists.fedoraproject.org

163 participants
254 discussions

intent to hand over or orphan several scientific packages and their build requirements
by Dominik 'Rathann' Mierzejewski 05 Jan '24

05 Jan '24

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

2 4

Non responsive maintainer check for marxin
by Ankur Sinha 05 Jan '24

05 Jan '24

Hi folks, Would anyone know how to contact @marxin? They only maintain the one package, python-pebble, but it doesn't look like they've been active in a while. The package did not see to have been updated at all since the initial import: https://bugzilla.redhat.com/show_bug.cgi?id=2227456 and there are now new pending bugs that have not seen responses too: https://bugzilla.redhat.com/show_bug.cgi?id=2250914 We've waited for responses to PRs in the past and then had to use proven packager rights to update and maintain the package: https://src.fedoraproject.org/rpms/python-pebble/pull-request/2 https://src.fedoraproject.org/rpms/python-pebble/commits/rawhide Since a Neuro-SIG package depends on it, we're happy to take it over. Here's what I could get from fedora-active-user: python fedora_active_user.py --user marxin --email mliska(a)suse.cz --nofas Last action on koji: Fri, 15 Sep 2023 tag_package_owners entry created by humaton [still active] Last package update on bodhi: 2020-06-29 07:10:30 on package python-pebble-4.5.3-1.fc33 Last actions performed according to fedmsg: Last email on mailing list: ERROR:active-user:name 'mailinglist' is not defined Here's the tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=2256491 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

3 7

Un-retire python-pyngus
by Hirotaka Wakabayashi 05 Jan '24

05 Jan '24

Hello everyone, I would like to become the owner of python-pyngus[1]. This package was retired half a year ago as a FTBFS/FTI bugs[2]. python-qpid-proton, which is a dependent package of python-pyngus and was the reason for the installation failure, is now provided in Fedora39 and Rawhide, and I have successfully built the package on Fedora39[3] and Rawhide[4]. ---[1] https://src.fedoraproject.org/rpms/python-pyngus[2] https://bugzilla.redhat.com/show_bug.cgi?id=2184027 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=111316391[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=111315058 Best Regards, Hirotaka

1 0

Turning a XImage * into a Drawable for use with XRenderCreatePicture
by Florian Weimer 05 Jan '24

05 Jan '24

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

2 1

ARM PAC on koji vs COPR
by Jarek Prokop 04 Jan '24

04 Jan '24

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/fedo… https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedo… 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 6

Schedule for Thursday's FESCo Meeting (2024-01-04)
by Stephen Gallagher 04 Jan '24

04 Jan '24

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.

1 1

RISC-V ABI issue with ULEB128
by Richard W.M. Jones 04 Jan '24

04 Jan '24

I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ... Here's the bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects It refers to this change in binutils 2.41: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d… As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41. Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true. There's been discussion about adding an ELF tag, but that seems very problematic to me: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

5 11

Packed relative ELF relocations (DT_RELR) enabled by default in rawhide
by Florian Weimer 04 Jan '24

04 Jan '24

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

3 4

Error updating libvirt-dbus in F38
by Peter Boy 04 Jan '24

04 Jan '24

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

2 1

F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
by Aoife Moloney 04 Jan '24

04 Jan '24

Wiki -> https://fedoraproject.org/wiki/Changes/Enable_IPv4_Address_Conflict_Detecti… 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.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

4 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2024