devel January 2023

devel@lists.fedoraproject.org

219 participants
291 discussions

Unannounced? lua-libs soname change
by Hans de Goede 10 Jan '23

10 Jan '23

Hi, lua-5.4.4-4.fc37 in F37 release provides both: liblua-5.3.so()(64bit) liblua-5.4.so()(64bit) aka both of: /usr/lib64/liblua-5.3.so /usr/lib64/liblua-5.4.so but the recent update to lua-libs-5.4.4-7.fc37 only provides: liblua-5.4.so()(64bit) /usr/lib64/liblua-5.4.so And the same appears to be happening in F36 (I did not check): This is causing the following fails to install cegui bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2156354 https://bugzilla.redhat.com/show_bug.cgi?id=2156356 https://bugzilla.redhat.com/show_bug.cgi?id=2156626 and the following fails to install megaglest bug: https://bugzilla.redhat.com/show_bug.cgi?id=2156357 I can rebuild cegui (and issue updates of it for f36 + f37), which I think might be easier/better then restoring the liblua compat build. And I guess I can also take care of megaglest while at it, but first I wanted to make sure that this is the right way to move forward with fixing this... ? Regards, Hans

3 4

Non-responsive maintainer check for jhli
by Ali Erdinc Koroglu 10 Jan '23

10 Jan '23

Hello everyone! Does anyone know how to contact Juston Li (jhli)? I have tried to reach out via email but have not received a response. https://bugzilla.redhat.com/show_bug.cgi?id=2159807 -- Ali Erdinc Koroglu Linux OS Systems Engineering

1 0

A late change proposal
by Matthias Clasen 10 Jan '23

10 Jan '23

https://fedoraproject.org/wiki/Changes/UnfilteredFlathub Before xmas, when the deadline for system-wide changes came near, I flipped this change proposal to the ChangePageReadyForWrangler category, and thereby send it to neverneverland, since the correct category is ChangeReadyForWrangler :( I've corrected that today, and I would like to ask that this feature could maybe still be considered, even though it is late by now. The reasons are: - While this is flagged as a system-wide change, really the only system-widge aspect here is policy (there are no releng or other coordination needs) - This is not a new feature, it has been discussed before, so the discussion will hopefully be short and can focus on the changes we made to address the concerns from last time. - It was submitted in time and only missed the deadline due to process gotchas. Matthias

4 3

Donate 1 minute of your time to test upgrades from F36 to F37
by Miroslav Suchý 10 Jan '23

10 Jan '23

Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' dnf --releasever=37 --setopt=module_platform_id=platform:f37 \ --enablerepo=updates-testing \ $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \ --assumeno distro-sync This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. The `--assumeno` will just test the transaction, but does not make the actual upgrade. In case you hit dependency issues, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 37. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu and also there is already bunch of "Fails to install" (F37FailsToInstall) reports: https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109&bug_id_type=anddepen… Thank you Miroslav

51 65

[Modularity] XML format for in-repository modules
by Petr Pisar 10 Jan '23

10 Jan '23

Hello Fedora developers, I'd like to show you a proposal for a new XML format of modular metadata which reside in YUM repositories. In short I propose replacing YAML syntax with XML syntax while removing features which where never implemented or used, while providing a detailed specification leaving small place for implementer's invention. The proposed specification is the "reduced" variant under <https://github.com/fedora-modularity/libmodulemd/tree/main/xml_specs>, for instance <https://github.com/fedora-modularity/libmodulemd/blob/main/xml_specs/reduce…>. Bear in mind that this change is only about how the modules are stored in YUM repositories which are fetched by DNF. It does not change how modules are defined by module maintainers (YAML modulemd-packager-v3 or modulemd-v2 format) and how it is built by MBS and handled by Bodhi. Those who should be concerned most are DNF5 developers and relengs producing composes. Long story: Original modulemd format had a noble property, and that was an input format for MBS is the same as the output format. This is not true anymore because of modulemd-packager-v3 format. It also makes validation difficult as fields optional in an input format are mandatory in the output format, or vice versa. Original modulemd format drags in YAML format into YUM repository which is otherwise XML-only. That requires a YAML parser. Original modulemd format is not handled by DNF directly. Instead, DNF uses libmodulemd library. That library is heavily based on glib. In fact it embeds glib types into its API. Why do I mention it? Because new DNF5 aims to eradicate glib. Mostly to shrink container installations. librepo and libmodulemd are the last pieces with glib. Because it's impossible to remove glib from libmodulemd, there has to be a new library for parsing modular metadata. If there has to be a new library, there could be a transition from YAML to XML which would shrink the minimal installation more by removing libyaml. Original modulemd format possesses some features which nobody uses, or nobody implements, or if implements, than not fully. Do you remember a deprecation of intents from modularity <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…>? There are more things that can be removed and make the format and its parser simpler. Original format is not well specified. DNF and Satellite people complained a lot when they were implementing it. The specification looks more like an example. E.g. a module stream name is probably a string. An arbitrary string. With spaces, with new lines. I think you do not want to see a stream named " :\n". Well, DNF does not even allow you to identify a module like that. There is definitely room for tightening the format. But each change like that is technically an incompatible change. To materialze the change we need at least a new modulemd format version. But if we need a new format version, we can actually come a completely new format. As you can see, there are good reasons to come up with a new in-repository format. Hence here it is <https://github.com/fedora-modularity/libmodulemd/tree/main/xml_specs>. I originally developed the XML format to be able to encode all features we have in the old YAML format. That's kept for your reference in "complete" subdirectory <https://github.com/fedora-modularity/libmodulemd/tree/main/xml_specs/comple…>. Then I removed all unnecessary features and put it into "reduced" subdirectory <https://github.com/fedora-modularity/libmodulemd/tree/main/xml_specs/reduced>. If you are interested in it, I recommend starting with overview.xml file. It shows a skeleton of the format. It's so small I can quote it here: <index xmlns="http://fedoraproject.org/metadata/moduleindex" version="" revision=""> <module name=""> <stream name="">  <build version="" context="" static="" arch="" summary="" description="">  <dependency name=""> <requires></requires>  <conflicts></conflicts>  </dependency> <dependency name=""/>  <license> <module></module> <content></content> </license> <references comunity="" documentation="" tracker=""/> <profile name="" description=""> <package></package> </profile> <api></api> <demodularized></demodularized> <nevra name="" epoch="" version="" release="" arch=""/> </build> <default-profile modified="">  <profile></profile>  </default-profile> <obsolete modified="" context="">  <eol when="" message="">   <replacement module="" stream=""/> </eol> </obsolete> <translation modified="">  <locale name="">  <build summary="" description=""/>  <profile name="" description=""/>  <obsolete context="" message=""/>  </locale> </translation> </stream> <default-stream modified="" stream=""/>   </module> </index> As you can see, there are no separate documents for modules and default streams. Everything is kept inside one document. That enables properties (e.g. obsoletes or default profiles) pertaining the same entity (e.g. a stream) to be placed together. That prevents from repeating the identifiers (e.g. stream names) and makes the format more succinct and easier for querying. That's especially import for DNF which needs quickly to know list of modules, streams of modules, to find out the latest build etc. An example.xml file shows how a real data would look <https://github.com/fedora-modularity/libmodulemd/blob/main/xml_specs/reduce…>. You can see e.g. see that time stamps are encoded as a number of seconds since a Unix epoch. That will save DNF from parsing e-mail date notations, handling time zones etc. There is also a formal specification in a form or XML Schema <https://github.com/fedora-modularity/libmodulemd/blob/main/xml_specs/reduce…>. And tests subdirectory with a preliminary sets of good and bad examples that validates and fails a validation. I'd be glad to hear any comments on the format. A grand plan how to implement and deploy this format is outlined in top-level README.md <https://github.com/fedora-modularity/libmodulemd/blob/main/xml_specs/README…>. Basically it will be injected into createrepo_c tool to produce the XML data in YUM repositories. Then the format will be consumed by DNF5. (Just to clarify, currently missing support for modules in DNF5 is not caused by this new XML format. DNF5 will support modules in the old YAML format soon through libmodulemd library.) According to my consultation with DNF team, DNF5 plans to prefer the XML format if both XML and YAML would exist in a repository. -- Petr

5 8

F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
by Ben Cotton 10 Jan '23

10 Jan '23

https://fedoraproject.org/wiki/Changes/GNUToolchainF38 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 == Update the Fedora 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37. The existing gdb 12.1 will be used as-is. The set of core GNU Toolchain packages for Fedora 38 are as follows: * GNU C Compiler 13.0 ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.39 * GNU C Library 2.37 * GNU Debugger 12.1 (immediately available in Fedora 37) The gcc 13.0 change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.39 change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.37 change will be tracked in this top-level GNU Toolchain system-wide update. == Owner == * Name: [[User:codonell|Carlos O'Donell]] * Email: carlos(a)redhat.com == Detailed Description == The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and the GNU Debugger make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora. The GNU Compiler Collection is expected to release version 13.0, after the Fedora 38 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-13/changes.html. The latest release candidate for gcc 13 will be included in Fedora 38 and will be updated when released. The GNU Binutils version 2.39 was released before Fedora 38; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution for the last 4 months. Given the present schedule for Fedora 38 we will continue to use Binutils 2.39. The GNU C Library version 2.37 is expected to be release before Fedora 38; we have started closely tracking the glibc 2.37 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 38 will branch after the release of glibc 2.37. However, the mass rebuild schedule means Fedora 38 will mass rebuild (if required) before the final release of glibc 2.37, but after the ABI is frozen. The GNU Debugger version 12.1 was released before Fedora 38; and we plan to continue to use this version of the debugger. == Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream. The goal is to track and transition to the latest components of the GNU Toolchain. == Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb, ...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 38 branch. * Other developers: Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. * Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/XX #XX] ** Filed after approval. * 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 == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora. Some source changes may be required for the gcc 13 update. Please refer to the latest changes here: https://gcc.gnu.org/gcc-13/changes.html Any source level changes required for glibc 2.37 will be noted here: https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes == How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own testsuite which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. The GNU Binutils has its own testsuite which is run during the package build and examined by binutils developers before being uploaded. The regression testsuite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own testsuite which is run during the package build and examined by gdb developers before being uploaded. The regression testsuite is run to verify the correct operation of the debugger. == User Experience == Fedora developers as well as developers using the distribution will be able to use and develop using the new features offered by the updated components. Developers will need to enable specific compiler features as required e.g. '-mcpu=neoverse-v2'. == Dependencies == All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 38 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime. == Contingency Plan == * Contingency mechanism glibc: If glibc 2.37 proves too disruptive to compiling the distribution we could revert to 2.36, but given that Rawhide has started tracking glibc 2.37, no show-stopper problems are expected. At this point we can still revert to upstream version 2.36 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism binutils: If binutils 2.39 proves too distruptive to assembling and linking the distribution we could revert to 2.38, but given that Rawhide is using 2.39, no show-stopper problems are expected. At this point we can still revert if insurmountable problems appear, but to do so may require a mass rebuild if the defects involve generated binaries. * Contingency mechanism for gcc: If gcc 13 proves too disruptive to compiling the distribution we could revert to gcc 12. * Contingency mechanism for gdb: The gdb 12.1 release is already in all the Fedora releases and it would not be reverted. If any gcc, glibc or binutils changes cause gdb to fail then that would need to be reviewed on a case-by-case basis. * Contingency deadline: Fedora mass rebuild on 2023-01-18. * Blocks release? ** Yes, upgrading to gcc 13.0 does block the release. ** Yes, upgrading to binutils 2.39 does block the release. ** Yes, upgrading to glibc 2.37 does block the release. ** No, upgrading to gdb 12.1 does block the release (already released). == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The binutils manual contains the documentation for the release and doesn't need any more additional work. The glibc manual contains the documentation for the release and doesn't need any more additional work. The gdb manual contains the documentation for the release and doesn't need any more additional work. == Release Notes ==  See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler Collection version 13 release notes.  The GNU C Library version 2.37 will be released at the beginning of February 2023. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD The GNU Binary Utilities version 2.39 was released August 2022. The current release notes will be sent to the developer mailing list: https://sourceware.org/pipermail/binutils/2022-August/122246.html. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

9 16

static USERMODEHELPER_PATH
by Steve Grubb 10 Jan '23

10 Jan '23

Hello, I work on RHEL security problems. I have been looking into a number of exploits and I think we have a problem that has an easy fix. We are not using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number of exploits that overwrite the path to modprobe and then pass something weird that causes modprobe to be invoked. But instead of modprobe, it's their reverse shell. If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/kernel/ core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it limits any exploits to programs that are in /usr. Only root can write here, therefore no escalation. Typically, an exploit changes modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and an area the attacker can control. For this mitigation, we'd need to: 1) set the config option in the kernel build 2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH) 3) update /proc/sys/kernel/core_pattern however it's set If we fix the modprobe path issue, there are a couple other areas that call usermode helper such as handle_initrd, fork_usermode_driver, CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups. The benefit is a lot of privilege escalation attacks are taken away. Does this sound worthwhile? Would people support this? Does this need to be filed as a system wide change? Who could help make this happen if approved? Thanks, -Steve

4 9

Fedora rawhide compose report: 20230109.n.0 changes
by Fedora Rawhide Report 10 Jan '23

10 Jan '23

OLD: Fedora-Rawhide-20230108.n.1 NEW: Fedora-Rawhide-20230109.n.0 ===== SUMMARY ===== Added images: 0 Dropped images: 4 Added packages: 1 Dropped packages: 1 Upgraded packages: 29 Downgraded packages: 0 Size of added packages: 22.08 KiB Size of dropped packages: 125.00 KiB Size of upgraded packages: 234.73 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.30 MiB Size change of downgraded packages: 0 B ===== ADDED IMAGES ===== ===== DROPPED IMAGES ===== Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20230108.n.1.iso Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230108.n.1.x86_64.vagrant-virtualbox.box Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20230108.n.1.iso Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230108.n.1.x86_64.vagrant-libvirt.box ===== ADDED PACKAGES ===== Package: rubygem-memoizer-1.0.3-2.fc38 Summary: Memoize your methods RPMs: rubygem-memoizer rubygem-memoizer-doc Size: 22.08 KiB ===== DROPPED PACKAGES ===== Package: paper-2.3-6.fc38 Summary: Query paper size database and retrieve the preferred size RPMs: paper Size: 125.00 KiB ===== UPGRADED PACKAGES ===== Package: ModemManager-1.20.2-2.fc38 Old package: ModemManager-1.20.2-1.fc38 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 11.87 MiB Size change: -51.46 KiB Changelog: * Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.20.2-2 - Switch to build using meson Package: R-IRkernel-1.3.1-3.fc38 Old package: R-IRkernel-1.3-1.fc38 Summary: Native R Kernel for the 'Jupyter Notebook' RPMs: R-IRkernel Size: 245.32 KiB Size change: 1.72 KiB Changelog: * Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3-3 - Re-enable tests. * Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-1 - Update to latest version (#2139798) * Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-2 - Upload sources and fix typo * Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-3 - Drop support for i686 Package: ags-3.6.0.40-1.fc38 Old package: ags-3.6.0.39-1.fc38 Summary: Engine for creating and running videogames of adventure (quest) genre RPMs: ags Size: 5.49 MiB Size change: 69.18 KiB Changelog: * Sun Jan 08 2023 Dominik Mierzejewski <dominik(a)greysector.net> - 3.6.0.40-1 - update to 3.6.0.40 (#2158889) Package: at-spi2-core-2.47.1-1.fc38 Old package: at-spi2-core-2.46.0-2.fc38 Summary: Protocol definitions and daemon for D-Bus at-spi RPMs: at-spi2-atk at-spi2-atk-devel at-spi2-core at-spi2-core-devel atk atk-devel Size: 6.33 MiB Size change: 1.44 MiB Changelog: * Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 2.47.1-1 - Update to 2.47.1 Package: candy-icon-theme-0-33.20230107gitc27f6da2.fc38 Old package: candy-icon-theme-0-32.20220919gita14330c7.fc38 Summary: Sweet gradient icon theme RPMs: candy-icon-theme Size: 1.04 MiB Size change: 13.16 KiB Changelog: * Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 0-33.20230107gitc27f6da2 - Update to latest upstream snapshot - Migrate License tag to SPDX Package: crosswords-0.3.6-4.fc38 Old package: crosswords-0.3.6-3.fc38 Summary: Solve crossword puzzles RPMs: crossword-editor crosswords crosswords-doc crosswords-puzzle-sets-cats-and-dogs crosswords-puzzle-sets-internal ipuz-convertor Size: 42.65 MiB Size change: 5.74 KiB Changelog: * Mon Jan 09 2023 Davide Cavalca <dcavalca(a)fedoraproject.org> 0.3.6-4 - Add BR for pkgconfig(iso-codes) and reorder Package: dosbox-staging-0.80.1-1.fc38 Old package: dosbox-staging-0.80.0-2.fc38 Summary: DOS/x86 emulator focusing on ease of use RPMs: dosbox-staging Size: 7.60 MiB Size change: 50.32 KiB Changelog: * Sun Jan 08 2023 Otto Liljalaakso <otto.liljalaakso(a)iki.fi> 0.80.1-1 - Update to 0.80.1 (rhbz#2159057) Package: embree-3.13.5-2.fc38 Old package: embree-3.13.5-1.fc38 Summary: Collection of high-performance ray tracing kernels RPMs: embree embree-devel Size: 6.83 MiB Size change: 1.75 KiB Changelog: * Sun Jan 08 2023 Luya Tshimbalanga <luya(a)fedoraproject.org> 3.13.5-2 - Migrate license to SPDX standard Package: ffmpegthumbs-22.12.1-1.fc38 Old package: ffmpegthumbs-22.12.0-1.fc38 Summary: KDE ffmpegthumbnailer service RPMs: ffmpegthumbs Size: 179.56 KiB Size change: 651 B Changelog: * Wed Jan 04 2023 Justin Zobel <justin(a)1707.io> - 22.12.1-1 - Update to 22.12.1 Package: flatbuffers-22.12.06-6.fc38 Old package: flatbuffers-22.12.06-3.fc38 Summary: FlatBuffers: Memory Efficient Serialization Library RPMs: flatbuffers flatbuffers-compiler flatbuffers-devel flatbuffers-doc python3-flatbuffers Size: 4.92 MiB Size change: 3.65 KiB Changelog: * Sun Jan 08 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-4 - Minor spec file tidying * Sun Jan 08 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-5 - Enable Python tests * Mon Jan 09 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-6 - Fix Python big-endian (s390x) issues Package: ghostscript-9.56.1-6.fc38 Old package: ghostscript-9.56.1-5.fc38 Summary: Interpreter for PostScript language & PDF RPMs: ghostscript ghostscript-doc ghostscript-gtk ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing ghostscript-x11 libgs libgs-devel Size: 25.30 MiB Size change: -48.47 KiB Changelog: * Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 9.56.1-6 - rebuild for libpaper v2 Package: gvfs-1.50.3-1.fc38 Old package: gvfs-1.50.2-2.fc37 Summary: Backends for the gio framework in GLib RPMs: gvfs gvfs-afc gvfs-afp gvfs-archive gvfs-client gvfs-devel gvfs-fuse gvfs-goa gvfs-gphoto2 gvfs-mtp gvfs-nfs gvfs-smb gvfs-tests Size: 7.39 MiB Size change: -1.25 KiB Changelog: * Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 1.50.3-1 - Update to 1.50.3 Package: html2ps-1.0-0.45.b7.fc38 Old package: html2ps-1.0-0.44.b7.fc37 Summary: HTML to PostScript converter RPMs: html2ps xhtml2ps Size: 118.92 KiB Size change: 29 B Changelog: * Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1.0-0.45.b7 - update to use "paper" instead of "paperconf" Package: kpublictransport-22.12.1-1.fc38 Old package: kpublictransport-22.04.3-2.fc37 Summary: Library to assist with accessing public transport timetables and other data RPMs: kpublictransport kpublictransport-devel Size: 3.29 MiB Size change: 6.55 KiB Changelog: * Sun Jan 08 2023 Marc Deop <marcdeop(a)fedoraproject.org> - 22.12.1-1 - 22.12.1 Package: latexmk-4.79-1.fc38 Old package: latexmk-4.78-1.fc38 Summary: A make-like utility for LaTeX files RPMs: latexmk Size: 405.44 KiB Size change: 8.22 KiB Changelog: * Sat Jan 07 2023 Jerry James <loganjerry(a)gmail.com> - 4.79-1 - Version 4.79 Package: libmbim-1.28.2-2.fc38 Old package: libmbim-1.28.2-1.fc38 Summary: Support library for the Mobile Broadband Interface Model protocol RPMs: libmbim libmbim-devel libmbim-utils Size: 3.00 MiB Size change: 34.75 KiB Changelog: * Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.28.2-2 - Fix location of completions file - Enable support for Dell DW5931e & DW5823e WWAN 5G Package: libnma-1.10.6-1.fc38 Old package: libnma-1.10.4-1.fc38 Summary: NetworkManager GUI library RPMs: libnma libnma-devel libnma-gtk4 libnma-gtk4-devel Size: 2.51 MiB Size change: -10.69 KiB Changelog: * Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.10.6-1 - Update to 1.10.6 release Package: libpaper-1:2.0.4-1.fc38 Old package: libpaper-1.1.28-5.fc37 Summary: Library and tools for handling papersize RPMs: libpaper libpaper-devel paper Added RPMs: paper Size: 275.11 KiB Size change: -17.86 KiB Changelog: * Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 2.0.4-1 - update to 2.0.4 Package: libqmi-1.32.2-2.fc38 Old package: libqmi-1.32.2-1.fc38 Summary: Support library to use the Qualcomm MSM Interface (QMI) protocol RPMs: libqmi libqmi-devel libqmi-utils Size: 12.00 MiB Size change: -374 B Changelog: * Mon Jan 02 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.32.2-2 - Fix bash completion files path Package: paperwork-2.1.2-1.fc38 Old package: paperwork-2.1.1-3.fc38 Summary: Using scanner and OCR to grep dead trees the easy way RPMs: paperwork python3-paperwork Size: 2.85 MiB Size change: 1.16 KiB Changelog: * Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1 - Update to latest version (#2159153) Package: python-openpaperwork-core-2.1.2-1.fc38 Old package: python-openpaperwork-core-2.1.1-4.fc38 Summary: OpenPaperwork's core RPMs: python3-openpaperwork-core Size: 250.25 KiB Size change: 2.79 KiB Changelog: * Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1 - Update to latest version (#2159151) Package: python-openpaperwork-gtk-2.1.2-1.fc38 Old package: python-openpaperwork-gtk-2.1.1-4.fc38 Summary: OpenPaperwork GTK plugins RPMs: python3-openpaperwork-gtk Size: 181.12 KiB Size change: 4.23 KiB Changelog: * Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1 - Update to latest version (#2159152) Package: python-paperwork-backend-2.1.2-1.fc38 Old package: python-paperwork-backend-2.1.1-6.fc38 Summary: Paperwork's backend RPMs: python3-paperwork-backend Size: 347.95 KiB Size change: 6.81 KiB Changelog: * Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1 - Update to latest version (#2159154) Package: python-whois-0.9.22-1.fc38 Old package: python-whois-0.9.21-1.fc38 Summary: Python module for retrieving WHOIS information of domains RPMs: python3-whois Size: 64.79 KiB Size change: 420 B Changelog: * Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 0.9.22-1 - Update to v0.9.22 Package: sweet-gtk-theme-3.0-8.20230107.fc38 Old package: sweet-gtk-theme-3.0-7.20220915.fc38 Summary: Light and dark, colorful GTK+ theme RPMs: sweet-gtk-theme Size: 3.42 MiB Size change: 9.60 KiB Changelog: * Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 3.0-8.20230107 - Update to latest git snapshots - Migrate License tag to SPDX Package: tali-40.9-1.fc38 Old package: tali-40.8-1.fc37 Summary: GNOME Tali game RPMs: tali Size: 1.71 MiB Size change: -581 B Changelog: * Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 40.9-1 - Update to 40.9 Package: tuxpaint-1:0.9.28-5.fc38 Old package: tuxpaint-1:0.9.28-4.fc38 Summary: Drawing program designed for young children RPMs: tuxpaint tuxpaint-devel Size: 69.69 MiB Size change: -255.13 KiB Changelog: * Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1:0.9.28-5 - rebuild for new libpaper v2 Package: ustreamer-5.36-1.fc38 Old package: ustreamer-5.34-1.fc38 Summary: Lightweight and fast MJPG-HTTP streamer RPMs: python3-ustreamer ustreamer Added RPMs: python3-ustreamer Size: 766.72 KiB Size change: 88.22 KiB Changelog: * Sat Jan 07 2023 Tao Jin <tao-j(a)outlook.com> - 5.36-1 - Update to 5.36 - Add python package build Package: xpdf-1:4.04-3.fc38 Old package: xpdf-1:4.04-2.fc37 Summary: A PDF file viewer for the X Window System RPMs: xpdf xpdf-devel Size: 14.06 MiB Size change: -62.80 KiB Changelog: * Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1:4.04-3 - fix build with libpaper2, rebuild for it ===== DOWNGRADED PACKAGES =====

1 0

python-cryptography license fix
by Charalampos Stratakis 09 Jan '23

09 Jan '23

The license of python-cryptography was changed to SPDX and also fixed after clarification from upstream from "ASL 2.0 or BSD" to "(Apache-2.0 OR BSD-3-Clause) AND PSF-2.0" -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat

1 0

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
by Daan De Meyer 09 Jan '23

09 Jan '23

> I think it would save everyone a bit of time if we restricted the change > to x86-64. We do not have much experience with the -mbackchain flag > that was added at the last minute on s390x. The change owners have > stated that they aren't interested in s390x. IBM doesn't want this. > Platform Tools does not want it. I doubt the desktop team does GNOME > performance analysis on s390x on Fedora. I'm not even sure if the tools > support backchain-based unwinding; it's not a frame pointer after all. > Maybe -mbackchain won't cause any issues in after all, but we just don't > have the time to test this before the mass rebuild. I had a look at the kernel unwinding code for s390 and it seems to use the backchain if it's available and fall back to the frame pointer otherwise. So from our end (change proposal authors) we're OK with dropping mbackchain for s390 and only using fno-omit-frame-pointer for s390. We'll open a PR to change this in the rpm macros. > As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on > i686 is known to break certain packages (although I worked around this > in glibc last year), simply because the reduced number of registers > makes it impossible for GCC to compile certain functions with inline > assembly in them. As with s390x, the concrete impact is not known at > this point, and we are out of time for test builds. Given these issues should manifest as compilation failures, we should notice very clearly once the mass rebuild starts if there's a bigger problem. If there's only a few packages that run into issues, they can opt-out. If there's larger problems, we can remove frame pointers from i686. > Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another > last-minute addition without any clear justification. (On AArch64, the > link register allows one to recover the address of the immediate caller > even if a leaf function does not have a frame pointer. That's not > possible on x86-64, where the caller's address must be read from the > stack, and that has to be based on the frame pointer.) Just because the > compiler option is there to enable doesn't mean it does anything useful > in this context. As I mentioned in the fesco ticket, the kernel unwinder looks at the frame pointer register (x29) first when starting an unwind on aarch64 before looking at the link register. As such, it seems logical to require frame pointers to be available in leaf functions so the frame pointer register is available to start unwinding. I'm happy to be proven wrong here so we can remove mno-omit-leaf-frame-pointer for aarch64. Cheers, Daan De Meyer ________________________________________ From: Daan De Meyer <daandemeyer(a)meta.com> Sent: 09 January 2023 19:21 To: Matthew Miller; Development discussions related to Fedora Subject: Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)] > I think it would save everyone a bit of time if we restricted the change > to x86-64. We do not have much experience with the -mbackchain flag > that was added at the last minute on s390x. The change owners have > stated that they aren't interested in s390x. IBM doesn't want this. > Platform Tools does not want it. I doubt the desktop team does GNOME > performance analysis on s390x on Fedora. I'm not even sure if the tools > support backchain-based unwinding; it's not a frame pointer after all. > Maybe -mbackchain won't cause any issues in after all, but we just don't > have the time to test this before the mass rebuild. I had a look at the kernel unwinding code for s390 and it seems to use the backchain if it's available and fall back to the frame pointer otherwise. So from our end (change proposal authors) we're OK with dropping mbackchain for s390 and only using fno-omit-frame-pointer for s390. We'll open a PR to change this in the rpm macros. > As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on > i686 is known to break certain packages (although I worked around this > in glibc last year), simply because the reduced number of registers > makes it impossible for GCC to compile certain functions with inline > assembly in them. As with s390x, the concrete impact is not known at > this point, and we are out of time for test builds. Given these issues should manifest as compilation failures, we should notice very clearly once the mass rebuild starts if there's a bigger problem. If there's only a few packages that run into issues, they can opt-out. If there's larger problems, we can remove frame pointers from i686. > Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another > last-minute addition without any clear justification. (On AArch64, the > link register allows one to recover the address of the immediate caller > even if a leaf function does not have a frame pointer. That's not > possible on x86-64, where the caller's address must be read from the > stack, and that has to be based on the frame pointer.) Just because the > compiler option is there to enable doesn't mean it does anything useful > in this context. As I mentioned in the fesco ticket, the kernel unwinder looks at the frame pointer register (x29) first when starting an unwind on aarch64 before looking at the link register. As such, it seems logical to require frame pointers to be available in leaf functions so the frame pointer register is available to start unwinding. I'm happy to be proven wrong here so we can remove mno-omit-leaf-frame-pointer for aarch64. Cheers, Daan De Meyer ________________________________________ From: Florian Weimer <fweimer(a)redhat.com> Sent: 09 January 2023 17:54 To: Matthew Miller Cc: devel(a)lists.fedoraproject.org Subject: Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)] !-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! * Matthew Miller: > BUT, I do not think it was done with malice, as "deliberately rigged" > implies. I don't see that at all -- I see excitement and interest in moving > forward on something that already has taken a long time, and looming > practical deadlines. No one spoke out when the tools team was called untrustworthy on the FESCo ticket. We can try explain it as an accident that the toolchain team was sidelined afterwards. But the overall sequence of events certainly looks rather odd. There are infrastructure problems as well. Notifications in the Fedora wiki system are broken (email notifications are spotty, but not completely defunct; that did not matter here because the new FESCo ticket was added to the change page only after the second vote), and missing notifications for label updates on FESCo tickets (so it's hard to spot that an issue is scheduled for discussion). So unless you are in the in-group or invited, it's hard to contribute. All these issues contribute to a work environment that I find very problematic. The individual aspects are probably not deliberate, but there's still an impact. > And, from a practical point of view, since this passed with six +1 votes, > I'm not sure what benefit canceling and re-voting would really add. I'm pretty sure no one considered the impact on non-x86-64 architectures, given that the change as voted and submitted as a PR would have broken the ppc64le and s390x buildroots. I think it would save everyone a bit of time if we restricted the change to x86-64. We do not have much experience with the -mbackchain flag that was added at the last minute on s390x. The change owners have stated that they aren't interested in s390x. IBM doesn't want this. Platform Tools does not want it. I doubt the desktop team does GNOME performance analysis on s390x on Fedora. I'm not even sure if the tools support backchain-based unwinding; it's not a frame pointer after all. Maybe -mbackchain won't cause any issues in after all, but we just don't have the time to test this before the mass rebuild. As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on i686 is known to break certain packages (although I worked around this in glibc last year), simply because the reduced number of registers makes it impossible for GCC to compile certain functions with inline assembly in them. As with s390x, the concrete impact is not known at this point, and we are out of time for test builds. Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another last-minute addition without any clear justification. (On AArch64, the link register allows one to recover the address of the immediate caller even if a leaf function does not have a frame pointer. That's not possible on x86-64, where the caller's address must be read from the stack, and that has to be based on the frame pointer.) Just because the compiler option is there to enable doesn't mean it does anything useful in this context. Thanks, Florian _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

← Newer
1
...
21
22
23
24
25
26
27
...
30
Older →

Jump to page:

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 2023