[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-88b6d1940a apptainer-1.3.0-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a08edbaebf amavis-2.12.3-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-27eced8f48 tcpreplay-4.4.4-5.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5253d48b14 w3m-0.5.3-63.git20230121.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing chromium-122.0.6261.128-1.el7 perl-Data-UUID-1.227-1.el7 Details about builds: chromium-122.0.6261.128-1.el7 (FEDORA-EPEL-2024-6e2c9aa156) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: upstream security release 122.0.6261.128 High CVE-2024-2400: Use after free in Performance Manager ChangeLog: * Wed Mar 13 2024 Than Ngo - 122.0.6261.128-1 - upstream security release 122.0.6261.128 * High CVE-2024-2400: Use after free in Performance Manager * Mon Mar 11 2024 Than Ngo - 122.0.6261.111-2 - enable ppc64le build References: [ 1 ] Bug #2269307 - CVE-2024-2400 chromium: chromium-browser: Use after free in Performance Manager [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2269307 perl-Data-UUID-1.227-1.el7 (FEDORA-EPEL-2024-1c85d457ef) Globally/Universally Unique Identifiers (GUIDs/UUIDs) Update Information: This update fixes CVE-2013-4184 (possible symlink attack due to use of predictable temporary file names). The module no longer saves state in temporary files at all. ChangeLog: * Tue Mar 19 2024 Paul Howarth - 1.227-1 - Update to 1.227 - New maintainer, GTERMARS - Add basic GitHub Actions setup for testing - Typo corrections in POD - Eliminated use of state/node files in temp directory (CVE-2013-4184) * Thu Jan 25 2024 Fedora Release Engineering - 1.226-16 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Sun Jan 21 2024 Fedora Release Engineering - 1.226-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Tue Aug 29 2023 Jitka Plesnikova - 1.226-14 - Update license to SPDX format * Thu Jul 20 2023 Fedora Release Engineering - 1.226-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Jul 11 2023 Jitka Plesnikova - 1.226-12 - Perl 5.38 rebuild * Fri Jan 20 2023 Fedora Release Engineering - 1.226-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Fri Jul 22 2022 Fedora Release Engineering - 1.226-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Tue May 31 2022 Jitka Plesnikova - 1.226-9 - Perl 5.36 rebuild * Fri Jan 21 2022 Fedora Release Engineering - 1.226-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Dec 16 2021 Paul Howarth - 1.226-7 - BR: perl(blib) for smp-test/collision.t * Thu Jul 22 2021 Fedora Release Engineering - 1.226-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Fri May 21 2021 Jitka Plesnikova - 1.226-5 - Perl 5.34 rebuild * Wed Jan 27 2021 Fedora Release Engineering - 1.226-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 1.226-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Tue Jun 23 2020 Jitka Plesnikova - 1.226-2 - Perl 5.32 rebuild * Sun Apr 12 2020 Paul Howarth - 1.226-1 - Update to 1.226 - Set umask before fopen in destructor (GH#35) * Wed Jan 29 2020 Fedora Release Engineering - 1.224-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering - 1.224-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Fri May 31 2019 Jitka Plesnikova - 1.224-2 - Perl 5.30 rebuild * Sun Mar 3 2019 Paul Howarth - 1.224-1 - Update to 1.224 - Properly quote C strings passed in DEFINE - Fix memory leak by decreasing reference count - Use File::Spec to get tmpdir instead of hardcoding * Fri Feb 1 2019 Fedora Release Engineering - 1.221-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 1.221-12 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jun 28 2018 Jitka Plesnikova -
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0e36aae9a6 apptainer-1.3.0-1.el9 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-2fb51140b6 amavis-2.13.1-1.el9 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-d438d87b45 tcpreplay-4.4.4-5.el9 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c23f6cf8c2 podman-tui-0.18.0-1.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0398ebbbfa w3m-0.5.3-63.git20230121.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing chromium-122.0.6261.128-1.el9 perl-Fuse-0.16.1-27.el9 rust-bitflags-2.5.0-1.el9 rust-brotli-3.5.0-1.el9 rust-darling-0.20.8-1.el9 rust-darling_core-0.20.8-1.el9 rust-darling_macro-0.20.8-1.el9 rust-derive_builder-0.20.0-1.el9 rust-derive_builder0.12-0.12.0-1.el9 rust-derive_builder_core-0.20.0-1.el9 rust-derive_builder_core0.12-0.12.0-1.el9 rust-derive_builder_macro-0.20.0-1.el9 rust-derive_builder_macro0.12-0.12.0-1.el9 rust-git2-0.18.3-1.el9 rust-os_pipe-1.1.5-3.el9 rust-sha1collisiondetection-0.3.4-1.el9 rust-test-log-0.2.15-1.el9 rust-test-log-macros-0.2.15-1.el9 rust-toml_edit-0.22.8-1.el9 rust-tree_magic_mini-3.1.4-1.el9 rust-uuid-1.8.0-1.el9 Details about builds: chromium-122.0.6261.128-1.el9 (FEDORA-EPEL-2024-879bfd3d5b) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: upstream security release 122.0.6261.128 High CVE-2024-2400: Use after free in Performance Manager ChangeLog: * Wed Mar 13 2024 Than Ngo - 122.0.6261.128-1 - upstream security release 122.0.6261.128 * High CVE-2024-2400: Use after free in Performance Manager * Mon Mar 11 2024 Than Ngo - 122.0.6261.111-2 - enable ppc64le build References: [ 1 ] Bug #2269307 - CVE-2024-2400 chromium: chromium-browser: Use after free in Performance Manager [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2269307 perl-Fuse-0.16.1-27.el9 (FEDORA-EPEL-2024-b9c3804d4d) Write filesystems in Perl using FUSE Update Information: Added to EPEL 9 ChangeLog: * Thu Jan 25 2024 Fedora Release Engineering - 0.16.1-27 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Sun Jan 21 2024 Fedora Release Engineering - 0.16.1-26 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Thu Jul 20 2023 Fedora Release Engineering - 0.16.1-25 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Tue Jul 11 2023 Jitka Plesnikova - 0.16.1-24 - Perl 5.38 rebuild * Fri Jan 20 2023 Fedora Release Engineering - 0.16.1-23 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Fri Jul 22 2022 Fedora Release Engineering - 0.16.1-22 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Mon May 30 2022 Jitka Plesnikova - 0.16.1-21 - Perl 5.36 rebuild References: [ 1 ] Bug #2267346 - Please branch and build perl-Fuse for EPEL9 https://bugzilla.redhat.com/show_bug.cgi?id=2267346 rust-bitflags-2.5.0-1.el9 (FEDORA-EPEL-2024-45ac4e6da1) Macro to generate structures which behave like bitflags Update Information: Update to version 2.5.0. ChangeLog: * Tue Mar 19 2024 Fabio Valentini - 2.5.0-1 - Update to version 2.5.0; Fixes RHBZ#2270212 rust-brotli-3.5.0-1.el9 (FEDORA-EPEL-2024-6c731808ca) Brotli compressor and decompressor with no_std support Update Information: Update to version 3.5.0. ChangeLog: * Tue Mar 19 2024 Fabio Valentini -
[Bug 2267346] Please branch and build perl-Fuse for EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2267346 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2024-b9c3804d4d has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b9c3804d4d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2267346 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202267346%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2269007] perl-Alien-pkgconf-0.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2269007 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Alien-pkgconf-0.20-1.f |perl-Alien-pkgconf-0.20-1.f |c41 |c41 |perl-Alien-pkgconf-0.20-1.f |perl-Alien-pkgconf-0.20-1.f |c38 |c38 ||perl-Alien-pkgconf-0.20-1.f ||c39 --- Comment #9 from Fedora Update System --- FEDORA-2024-599045059e (perl-Alien-pkgconf-0.20-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2269007 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202269007%23c9 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2268933] perl-LWP-Protocol-https-6.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268933 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-LWP-Protocol-https-6.1 ||4-1.fc39 Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2024-03-20 02:03:59 --- Comment #6 from Fedora Update System --- FEDORA-2024-4f64847ee4 (perl-LWP-Protocol-https-6.14-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268933 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268933%23c6 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270256] perl-DBD-MySQL-5.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270256 --- Comment #4 from Fedora Update System --- FEDORA-2024-277e98e1b9 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-277e98e1b9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-277e98e1b9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270256%23c4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270204] perl-Variable-Magic-0.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270204 --- Comment #4 from Fedora Update System --- FEDORA-2024-fef134e490 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-fef134e490` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-fef134e490 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270204%23c4 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2269007] perl-Alien-pkgconf-0.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2269007 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Alien-pkgconf-0.20-1.f |perl-Alien-pkgconf-0.20-1.f |c41 |c41 ||perl-Alien-pkgconf-0.20-1.f ||c38 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2024-03-20 01:55:41 --- Comment #8 from Fedora Update System --- FEDORA-2024-db7ade355e (perl-Alien-pkgconf-0.20-1.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2269007 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202269007%23c8 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ld: error: triggering the generation of an executable stack
With a recent update, plplot is failing to build with: cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -frecursive CMakeFiles/x16af.dir/x16af.f90.o -o x16af -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: No such file or directory I have no idea what is up here. Seems to have started with: gcc 14.0.1-0.7.fc41 glibc 2.39.9000-3.fc41 util-linux 2.40-0.9.rc1.fc41 binutils 2.42.50-4.fc41 and lots of others, but that seems the most likely. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora Linux 40 Beta Blocker Bug Summary Report: 2024-03-19
Hi all, We are very close to the Fedora 40 Beta Go/No-Go meeting (Thursday 21st March @ 1700 UTC in #meeting:fedoraproject.org on Matrix), so your help reviewing, reproducing, and help in finding and verifying proposed fixes would be greatly appreciated. Below is a summary report of the current proposed and accepted blocker bugs for Fedora Linux 40 Beta release. Please visit the blocker bugs app page for more details https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist Summary 2024-03-19 == Proposed Blocker == 1. mesa - Raspberry Pi 4/400: some GUI assets won't load - NEW ACTION: Upstream to diagnose issue 2. xorg-11-server - Basic Graphics Mode seems to be broken on Fedora Workstation RC 1.9 - NEW ACTION: Maintainers to diagnose issue == Accepted Blockers == 1. bcm283x-firmware - Raspberry Pi 400 shows nothing on screen when booting Fedora 40 images (even before grub) - ON_QA ACTION: QA to verify fix https://bodhi.fedoraproject.org/updates/FEDORA-2024-38764db413 2. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards - VERIFIED ACTION: N/A 3. shim-unsigned-aarch64 - Fedora fails to boot via BOOT/bootaa64->fbaa64 on UEFI machines with EFI_MEMORY_ATTRIBUTES_PROTOCOL - VERIFIED ACTION: N/A 4. uboot-tools - u-boot doesnt find and load the Fedora provided DTBs from /boot/dtb - ON_QA ACTION: QA to verify fix https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f5380bab6 Accepted Previous Release Blocker 1. distribution - dnf system-upgrade fails on some RPi4 due to system boot date that pre-dates gpg key - NEW ACTION: Maintainer to diagnose = Bug by Bug Detail = == Proposed Blockers == 1. mesa - Raspberry Pi 4/400: some GUI assets won't load - https://bugzilla.redhat.com/show_bug.cgi?id=2269412 - NEW When running workstation on the RC 1.2, the graphics on the title bar and nautilus are missing on Raspberry Pi hardware. The graphics are visible on x86_64 machines. The issue also appears on aarch64 running the RC 1.8 and seems to affect GTK 4 applications only. Running RC 1.8 also does not crash on login, however the issue of the missing graphics is still present. The issue is believed to be upstream. More testing would be appreciated to verify if the bug exists in other desktop offerings. 2. xorg-11-server - Basic Graphics Mode seems to be broken on Fedora Workstation RC 1.9 - https://bugzilla.redhat.com/show_bug.cgi?id=2270301 - NEW Booting to live sessions from basic graphics mode does not seem to reliably work on some bare metal environments, however other hardware seems to work as expected. Additional testing would be helpful to understand if this is a reproducible bug or an edge case. Please vote in the blocker bug app https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist == Accepted Blockers == 1. bcm283x-firmware - Raspberry Pi 400 shows nothing on screen when booting Fedora 40 images (even before grub) - https://bugzilla.redhat.com/show_bug.cgi?id=2267968 - ASSIGNED Raspberry Pi 400 doesn't boot at all with 40-20240223.n.0 and 40-20240304.n.0 when tested both as is and with the firmware update, the display is black from the start even with the display on. 40-20240219.n.0 shows the same behaviour and on 40-20240304.n.0 when downgraded u-boot to 2024.01-2.fc40, the RPi400 behaves the same. A fix has been submitted and is now pushed to the Fedora 40 testing repo https://bodhi.fedoraproject.org/updates/FEDORA-2024-38764db413 which reportedly fixes the issue. 2. shim - Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards - https://bugzilla.redhat.com/show_bug.cgi?id=2113005 - NEW UEFI LoadOptions that start with NUL cause boot failure. This is fixed upstream in https://github.com/rhboot/shim/pull/505 but the SecureBoot signing process requires NX support in the kernel. This is now in kernel 6.7 and unsigned shim builds showed up recently, so this is moving closer to being resolved once signed shim builds can be procured. The sign request can be seen here https://github.com/rhboot/shim-review/issues/386 and is yet to be merged 3. shim-unsigned-aarch64 - Fedora fails to boot via BOOT/bootaa64->fbaa64 on UEFI machines with EFI_MEMORY_ATTRIBUTES_PROTOCOL - https://bugzilla.redhat.com/show_bug.cgi?id=2259264 - POST Fedora boots that are going via the bootaa64->fbaa64 path (installers) fail to boot on machines that have the EFI_MEMORY_ATTRIBUTES_PROTOCOL. shim 15.8 is available upstream and has been built for x86 (shim-unsigned-x64-15.8-1) but not aarch64 as of yet and is waiting on this action to be resolved. 4. uboot-tools - u-boot doesnt find and load the Fedora provided DTBs from /boot/dtb - https://bugzilla.redhat.com/show_bug.cgi?id=2247873 - ASSIGNED Fedora Server images do not boot on the Jetson Nano. Non-Server images are not affected as they can use the kernel DTBs, and they boot OK. There is a similar root cause in https://bugzilla.redhat.com/show_bug.cgi?id=2246428 for this
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tuesday, March 19, 2024 9:22:23 AM EDT Allan via devel wrote: > > OK, but how do I run kwin-x11 instead of -wayland? > > You need plasma-workspace-x11 too. Thanks. That did it. -- Garry T. Williams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
F41 Change Proposal: Enable Consistent Device Naming in Cloud Images (self-contained)
Wiki -> https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud 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. = Enable Consistent Device Naming in Cloud Images = == Summary == This proposal aims to remove the `net.ifnames=0` kernel command line entry from the Fedora cloud kickstarts so that consistent device naming is enabled for cloud instances. This change brings Fedora Cloud in line with Fedora Server, Workstation, and CoreOS. == Owner == * Name: [[User:mhayden|Major Hayden]] * Email: ma...@redhat.com == Detailed Description == Fedora cloud images currently set `net.ifnames=0` on the kernel command line during the [https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_35 kickstart] process. This disables consistent device naming and ensures that ethernet devices retain the old-style names of `eth0`, `eth1`, `eth2`, and so on. Removing the `net.ifnames=0` configuration allows Fedora cloud instances to use consistent device names for network devices. This brings Cloud images in line with Fedora Server, Workstation, and CoreOS. == Feedback == One of the proposed alternatives is to leave `net.ifnames=0` in the kernel command line to remain consistent between releases. Although RHEL allows for `net.ifnames=0` for KVM instances, it is [https://access.redhat.com/solutions/2435891|strongly recommended not to use it] with OpenStack or RHV environments. Fedora Cloud images are used for multiple types of clouds, including public clouds and private clouds. This approach is less disruptive, but it pushes off the consistent device naming change until a later date and causes cloud images to operate differently than other Fedora deployments. Other distributions have taken different turns with this configuration. [https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039325.html| Ubuntu] removed it in 2016, Debian [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863385| added it back in 2017], and [https://documentation.suse.com/sles/15-SP4/pdf/article-minimal-vm_en.pdf| SUSE has had it] for some time. There were issues with cloud-init during the early days of network device naming in 2016/2017, but [https://github.com/canonical/cloud-init/blob/d8e3a4b4d4ca443227bf06bdaa5d9b47bd84e326/cloudinit/net/__init__.py#L480-L491| cloud-init supports consistent network names] since 2017. RHEL currently uses `net.ifnames=0`, but there is a debate about whether it should be removed in a future major release. == Benefit to Fedora == The main benefit comes from bringing cloud instances inline with other deployment types in how they name network devices. It also helps with cloud providers that offer up different types of network interfaces to an instance. For example, an emulated network device would present itself differently than one offered via SRIOV and it would allow an instance administrator to easily tell which network interface corresponds to each network device. This is especially important for certain clouds, such as OpenStack clouds. == Scope == * Proposal owners: * Other developers: * 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) * Alignment with Community Initiatives: == Upgrade/compatibility impact == '''Upgrades:''' Users who are upgrading to the next Fedora release will not notice a change in their instances since the `net.ifnames=0` change is only applied during the kickstart process. Their instances will continue using the old network names. '''New deployments:''' If a user has older Fedora deployments and they deploy a new Fedora release with this change applied, their network devices will use consistent network names instead of the old `eth0` and `eth1` style names. Although this won't impact software like cloud-init, it will impact users who have deployment scripts (Terraform or Ansible, for example) that need to set network configuration based on the network adapter's name. They will need to adjust the name of the network device in their deployment scripts. == How To Test == Use an image built without `net.ifnames=0` or take an existing cloud instance and remove `net.ifnames=0` from the kernel command line: grubby --update-kernel=current_kernel --remove-args="kernel_args" After a reboot, the device names should change from `eth0` to reflect the consistent device names based on the hardware: $ ip link | grep ^[0-9] 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 2: enp2s0f0: mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 3: eno1: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 4: enp2s0f1: mtu 1500 qdisc
F41 Change Proposal: Enable Consistent Device Naming in Cloud Images (self-contained)
Wiki -> https://fedoraproject.org/wiki/Changes/EnableConsistentDeviceNamingCloud 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. = Enable Consistent Device Naming in Cloud Images = == Summary == This proposal aims to remove the `net.ifnames=0` kernel command line entry from the Fedora cloud kickstarts so that consistent device naming is enabled for cloud instances. This change brings Fedora Cloud in line with Fedora Server, Workstation, and CoreOS. == Owner == * Name: [[User:mhayden|Major Hayden]] * Email: ma...@redhat.com == Detailed Description == Fedora cloud images currently set `net.ifnames=0` on the kernel command line during the [https://pagure.io/fedora-kickstarts/blob/main/f/fedora-cloud-base.ks#_35 kickstart] process. This disables consistent device naming and ensures that ethernet devices retain the old-style names of `eth0`, `eth1`, `eth2`, and so on. Removing the `net.ifnames=0` configuration allows Fedora cloud instances to use consistent device names for network devices. This brings Cloud images in line with Fedora Server, Workstation, and CoreOS. == Feedback == One of the proposed alternatives is to leave `net.ifnames=0` in the kernel command line to remain consistent between releases. Although RHEL allows for `net.ifnames=0` for KVM instances, it is [https://access.redhat.com/solutions/2435891|strongly recommended not to use it] with OpenStack or RHV environments. Fedora Cloud images are used for multiple types of clouds, including public clouds and private clouds. This approach is less disruptive, but it pushes off the consistent device naming change until a later date and causes cloud images to operate differently than other Fedora deployments. Other distributions have taken different turns with this configuration. [https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039325.html| Ubuntu] removed it in 2016, Debian [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863385| added it back in 2017], and [https://documentation.suse.com/sles/15-SP4/pdf/article-minimal-vm_en.pdf| SUSE has had it] for some time. There were issues with cloud-init during the early days of network device naming in 2016/2017, but [https://github.com/canonical/cloud-init/blob/d8e3a4b4d4ca443227bf06bdaa5d9b47bd84e326/cloudinit/net/__init__.py#L480-L491| cloud-init supports consistent network names] since 2017. RHEL currently uses `net.ifnames=0`, but there is a debate about whether it should be removed in a future major release. == Benefit to Fedora == The main benefit comes from bringing cloud instances inline with other deployment types in how they name network devices. It also helps with cloud providers that offer up different types of network interfaces to an instance. For example, an emulated network device would present itself differently than one offered via SRIOV and it would allow an instance administrator to easily tell which network interface corresponds to each network device. This is especially important for certain clouds, such as OpenStack clouds. == Scope == * Proposal owners: * Other developers: * 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) * Alignment with Community Initiatives: == Upgrade/compatibility impact == '''Upgrades:''' Users who are upgrading to the next Fedora release will not notice a change in their instances since the `net.ifnames=0` change is only applied during the kickstart process. Their instances will continue using the old network names. '''New deployments:''' If a user has older Fedora deployments and they deploy a new Fedora release with this change applied, their network devices will use consistent network names instead of the old `eth0` and `eth1` style names. Although this won't impact software like cloud-init, it will impact users who have deployment scripts (Terraform or Ansible, for example) that need to set network configuration based on the network adapter's name. They will need to adjust the name of the network device in their deployment scripts. == How To Test == Use an image built without `net.ifnames=0` or take an existing cloud instance and remove `net.ifnames=0` from the kernel command line: grubby --update-kernel=current_kernel --remove-args="kernel_args" After a reboot, the device names should change from `eth0` to reflect the consistent device names based on the hardware: $ ip link | grep ^[0-9] 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 2: enp2s0f0: mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 3: eno1: mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 4: enp2s0f1: mtu 1500 qdisc
F41 Change Proposal: Change Compose Settings (system-wide)
= Upgrade systems to createrepo_c 1.0 and change repositories metadata
settings =
{{Change_Proposal_Banner}}
Wiki -> https://fedoraproject.org/wiki/Changes/ChangeComposeSettings
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 ==
This is a proposal for upgrading systems which produce composes to
createrepo_c > 1.0 and changing some options used to create Fedora
repositories metadata. Note that some of these changes are inevitable
due to createrepo_c >= 1.0 behavioral change. We aim to change both
Rawhide/F41, then move all following releases to the new settings,
while preserving most of the current settings for releases <= 40.
== Owner ==
* Name: [[User:mattia| Mattia Verga]], [[User:kevin| Kevin Fenzi]]
* Email: mat...@fedorapeople.org, ke...@fedorapeople.org
== Detailed Description ==
With createrepo_c < 1.0 we're currently using different settings for
Rawhide repository metadata and stable releases repository metadata.
* Rawhide
** gzip compression for all metadata
** no updateinfo.xml file is generated (no updates repository exists)
** sqlite database of repodata is generated and compressed with gzip as well
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled
* F40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled (approved change for F40)
* F<40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs enabled
With createrepo_c > 1.0 moving to zstd as the default compression
type, we want to have consistent settings for all new releases and to
specify those settings manually, so that possible future changes of
defaults don't cause unexpected breakages. So we propose the following
settings:
* Rawhide/F>=41
** use `--general-compress-type` set to zstd to compress all metadata to zstd
** updateinfo.xml (for updates repository) compressed with zstd as well
** disable generating the additional sqlite database, as it was only
useful for yum
** comps repodata will be available only zstd compressed
** zchunk is active
** DRPMs disabled
* F<=40
** nothing should change by using the `--compatibility` flag of
createrepo_c >= 1.0
Note that updating bodhi-composer to use createrepo_c >= 1.0 will also
introduce an unavoidable change into EPEL8 updates repositories: comps
repodata will be made available only in compressed format (which is
set to XZ in EPEL8). Other EPEL releases (EPEL7 and EPEL9) can use the
`--compatibility` flag to maintain actual settings.
== Feedback ==
The zstd compression type was chosen to match createrepo_c settings.
As an alternative, we might want to choose xz, especially after
zlib-ng has been made the default in Fedora and brought performance
improvements.
The sqlite database distributed alongside the repodata is not useful
for dnf, but it might be used by some external consumer we're not
aware. Please do let us know.
== Benefit to Fedora ==
We're aiming at having consistent defaults for Rawhide and stable
releases and avoid future changes to createrepo_c defaults to cause
unexpected changes to repodata. Also, by using better compression
methods and avoid generating the sqlite database we're reducing
repodata disk usage.
== Scope ==
* Proposal owners:
** change createrepo_c settings for Rawhide in compose-rawhide01
(which is already upgraded to f39)
** upgrade bodhi-composer to f39 and have it using createrepo_c >= 1.0.0
** upgrade (if a new release is released in time) or backport patch
into bodhi to support all createrepo_c settings
** change bodhi's `createrepo_c.ini` in ansible to use the new
settings for F>=41
* Other developers:
* 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)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No change should be noticed while upgrading from previous releases.
== How To Test ==
DNF normal day usage should not be affected: upgrading/installing
packages should work as before, maybe a little faster in downloading
repodata.
== User Experience ==
User experience should not be affected.
Possible external custom repodata consumers might stop working and
will need to adjust to the new compression method.
== Dependencies ==
== Contingency Plan ==
*
F41 Change Proposal: Change Compose Settings (system-wide)
= Upgrade systems to createrepo_c 1.0 and change repositories metadata
settings =
{{Change_Proposal_Banner}}
Wiki -> https://fedoraproject.org/wiki/Changes/ChangeComposeSettings
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 ==
This is a proposal for upgrading systems which produce composes to
createrepo_c > 1.0 and changing some options used to create Fedora
repositories metadata. Note that some of these changes are inevitable
due to createrepo_c >= 1.0 behavioral change. We aim to change both
Rawhide/F41, then move all following releases to the new settings,
while preserving most of the current settings for releases <= 40.
== Owner ==
* Name: [[User:mattia| Mattia Verga]], [[User:kevin| Kevin Fenzi]]
* Email: mat...@fedorapeople.org, ke...@fedorapeople.org
== Detailed Description ==
With createrepo_c < 1.0 we're currently using different settings for
Rawhide repository metadata and stable releases repository metadata.
* Rawhide
** gzip compression for all metadata
** no updateinfo.xml file is generated (no updates repository exists)
** sqlite database of repodata is generated and compressed with gzip as well
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled
* F40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs disabled (approved change for F40)
* F<40
** gzip compression for primary metadata
** updateinfo.xml (for updates repository) is compressed with XZ
** sqlite database of repodata is generated and compressed with BZ2
** comps repodata is made available both as uncompressed xml and gzipped
** zchunk is active
** DRPMs enabled
With createrepo_c > 1.0 moving to zstd as the default compression
type, we want to have consistent settings for all new releases and to
specify those settings manually, so that possible future changes of
defaults don't cause unexpected breakages. So we propose the following
settings:
* Rawhide/F>=41
** use `--general-compress-type` set to zstd to compress all metadata to zstd
** updateinfo.xml (for updates repository) compressed with zstd as well
** disable generating the additional sqlite database, as it was only
useful for yum
** comps repodata will be available only zstd compressed
** zchunk is active
** DRPMs disabled
* F<=40
** nothing should change by using the `--compatibility` flag of
createrepo_c >= 1.0
Note that updating bodhi-composer to use createrepo_c >= 1.0 will also
introduce an unavoidable change into EPEL8 updates repositories: comps
repodata will be made available only in compressed format (which is
set to XZ in EPEL8). Other EPEL releases (EPEL7 and EPEL9) can use the
`--compatibility` flag to maintain actual settings.
== Feedback ==
The zstd compression type was chosen to match createrepo_c settings.
As an alternative, we might want to choose xz, especially after
zlib-ng has been made the default in Fedora and brought performance
improvements.
The sqlite database distributed alongside the repodata is not useful
for dnf, but it might be used by some external consumer we're not
aware. Please do let us know.
== Benefit to Fedora ==
We're aiming at having consistent defaults for Rawhide and stable
releases and avoid future changes to createrepo_c defaults to cause
unexpected changes to repodata. Also, by using better compression
methods and avoid generating the sqlite database we're reducing
repodata disk usage.
== Scope ==
* Proposal owners:
** change createrepo_c settings for Rawhide in compose-rawhide01
(which is already upgraded to f39)
** upgrade bodhi-composer to f39 and have it using createrepo_c >= 1.0.0
** upgrade (if a new release is released in time) or backport patch
into bodhi to support all createrepo_c settings
** change bodhi's `createrepo_c.ini` in ansible to use the new
settings for F>=41
* Other developers:
* 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)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No change should be noticed while upgrading from previous releases.
== How To Test ==
DNF normal day usage should not be affected: upgrading/installing
packages should work as before, maybe a little faster in downloading
repodata.
== User Experience ==
User experience should not be affected.
Possible external custom repodata consumers might stop working and
will need to adjust to the new compression method.
== Dependencies ==
== Contingency Plan ==
*
Re: Fedora Linux 40 Beta NO-GO
Apologies, there is a typo in the body of the email. To confirm, the new Beta target date is scheduled for Tuesday 26th March. Aoife Moloney Fedora Operations Architect On Thu, Mar 14, 2024, 9:49 PM Aoife Moloney wrote: > Due to outstanding blocker bugs[1], the Fedora Linux 40 Beta RC -1.4 was > declared NO-GO in today's meeting[2]. > > The next Fedora Linux 40 Beta Go/No-Go meeting[3] will be held at 1700 UTC on > Thursday 21st March in #meeting:fedoraproject.org on Matrix. > > The new target date for the F40 Beta release is now Tuesday 26th April. The > schedule[4] has been updated accordingly. > > > > > [1] https://qa.fedoraproject.org/blockerbugs/milestone/40/beta/buglist > [2] > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-14/f40-beta-go-no-go-meeting.2024-03-14-17.01.html > [3] https://calendar.fedoraproject.org/meeting/10764/ > [4] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html > > > -- > > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > > -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2024-03-20 from 18:00:00 to 19:00:00 UTC At fedora-meet...@chat.fedoraproject.org The meeting will be about: https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/10737/ -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: glibc32 in rawhide is now built from glibc
On Tue, Mar 19, 2024 at 04:36:03PM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
>
> > So, seems glibc32 was updated to update license headers?
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535
> >
> > So, it's in f40-updates-testing now.
> >
> > It's not in rawhide or f40 composes because pungi filters it out, but
> > it's currently not filtered in updates-testing. I can fix that, but...
> > isn't this package just going to be retired/blocked now?
>
> Uh-oh? Does this mean that glibc32 (the binary package) will land in
> updates-testing as well, each time we have glibc in gating?
Yep. So I will filter it there too...
> I planned to retire glibc32 after my vacation, in early April, but I can
> retire it now if that's better.
Naw, I can add it to filter out and then it shouldn't matter.
However, our filter config is... quite possibly out of date. :)
Currently it is:
filter_packages = [
("^.*$", {
"*": ["glibc32", "libgcc32"],
"s390x": ["rust-std-static-wasm*"],
}),
('(Server)$', {
'*': [
'kernel*debug*',
'kernel-kdump*',
'kernel-tools*',
'syslog-ng*',
'astronomy-bookmarks',
'generic*',
'GConf2-dbus*',
'bluez-gnome',
'java-11-openjdk',
'community-mysql*',
'jruby*',
'gimp-help-*',
]
}),
]
Does libgcc32 exist anymore?
Do we need that exclude on wasm on s390x?
Those sever ones look... weird.
Anyhow, I have filed:
https://pagure.io/releng/issue/12023
on this, so if you want something to stay in there that's listed above,
please note it there. ;)
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: User SSH access to Copr builders
That's great news ! Thanks. On Tue, Mar 19, 2024 at 12:56 PM Jakub Kadlcik wrote: > Hello, > this may be a useful feature for many people, so I wanted to announce it > separately. > > Debugging failed Copr builds became much easier with the last release. > https://docs.pagure.org/copr.copr/release-notes/2024-03-07.html > > You can now enable SSH access to the builder, connect using your pubkey, > and run any commands you need to debug the issue. Everything is explained > in my blog post. > https://frostyx.cz/posts/ssh-access-to-copr-builders > > Jakub > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: QGIS rebuild needed after GRASS GIS update
Hi Sandro, On Tue, Mar 19, 2024 at 2:34 PM Sandro Mani wrote: > > Hi Markus > > I'm happy to help coordinating the grass update. Thanks! > Note however that: > > - If the update does not carry ABI changes (and hence soname bumps), a > rebuild of QGIS is not needed > - If The update does carry a soname bump, it should be avoided in stable > releases It is a patch release only without ABI changes, so I don't expect any soname bump. Then no QGIS recompilation should be needed at all. I didn't submit any builds yet to avoid problems unless having this clarified. Markus > Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: glibc32 in rawhide is now built from glibc
* Kevin Fenzi: > So, seems glibc32 was updated to update license headers? > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535 > > So, it's in f40-updates-testing now. > > It's not in rawhide or f40 composes because pungi filters it out, but > it's currently not filtered in updates-testing. I can fix that, but... > isn't this package just going to be retired/blocked now? Uh-oh? Does this mean that glibc32 (the binary package) will land in updates-testing as well, each time we have glibc in gating? I planned to retire glibc32 after my vacation, in early April, but I can retire it now if that's better. Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora 40 compose report: 20240319.n.0 changes
OLD: Fedora-40-20240318.n.0 NEW: Fedora-40-20240319.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 2 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 10.27 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -192.92 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: plymouth-24.004.60-4.fc40 Old package: plymouth-24.004.60-3.fc40 Summary: Graphical Boot Animation and Logger RPMs: plymouth plymouth-core-libs plymouth-devel plymouth-graphics-libs plymouth-plugin-fade-throbber plymouth-plugin-label plymouth-plugin-script plymouth-plugin-space-flares plymouth-plugin-two-step plymouth-scripts plymouth-system-theme plymouth-theme-charge plymouth-theme-fade-in plymouth-theme-script plymouth-theme-solar plymouth-theme-spinfinity plymouth-theme-spinner Size: 5.24 MiB Size change: 1.99 KiB Changelog: * Sun Mar 17 2024 Adam Williamson - 24.004.60-4 - Revert upstream 48881ba to fix minimal installs (#2269385) Package: ufraw-0.23-0.21.20210425.fc40 Old package: ufraw-0.23-0.17.20210425.fc39 Summary: Raw image data retrieval tool for digital cameras RPMs: ufraw ufraw-common ufraw-gimp Size: 5.03 MiB Size change: -194.91 KiB Changelog: * Wed Nov 01 2023 Yaakov Selkowitz - 0.23-0.18.20210425 - Drop GConf2 schemas - Register freedesktop thumbnailer * Sat Jan 27 2024 Fedora Release Engineering - 0.23-0.19.20210425 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Sat Mar 09 2024 Nils Philippsen - 0.23-0.20.20210425 - Fix build failure (rhbz#2261764) * Tue Mar 12 2024 Zbigniew Jedrzejewski-Szmek - 0.23-0.21.20210425 - Fix version confusion preventing installation (rhbz#2268806) = DOWNGRADED PACKAGES = -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: glibc32 in rawhide is now built from glibc
On Fri, Mar 15, 2024 at 05:10:52PM +0100, Florian Weimer wrote:
> Joseph Myers enhanced glibc.spec so that we no longer need the separate
> glibc32 source package which its tarball of pre-built glibc binaries.
>
> As part of the DNF5 adjustment to the removal of filelists, I believe
> some reverse dependencies (including gcc) have been adjusted to use the
> package name explicitly, as in:
>
> %ifarch x86_64
> BuildRequires: (glibc32 or glibc-devel(%{__isa_name}-32))
> %endif
>
> Most packages have dropped the glibc32 dependency because it was
> unneeded (or should do so).
>
> This new package only contains the glibc files needed to build gcc.
> Other shared objects, such as libcrypt.so.2 or libgcc_s.so.1, are no
> longer included.
>
> There is a pungi configuration which is expected to filter out glibc32
> from the compose. We'll see how that works out. The new glibc32
> package does not have any ELF dependency information, so the risk of it
> being installed by accident is reduced compared to the old one.
>
> Once we have a compose without glibc32, I will retire the glibc32 source
> package because we no longer need it. Currently, glibc32 is still
> tagged in, but it has a lower version than the glibc-built package, so
> the latter is installed in the buildroot.
So, seems glibc32 was updated to update license headers?
https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535
So, it's in f40-updates-testing now.
It's not in rawhide or f40 composes because pungi filters it out, but
it's currently not filtered in updates-testing. I can fix that, but...
isn't this package just going to be retired/blocked now?
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, Mar 19, 2024 at 6:49 AM Jonathan Wakely wrote: > > On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel > wrote: > > > > I have just found another essential feature that is missing in Plasma > > Wayland: > > The big one for me is that Synergy and similar tools barrier and > input-leap don't work under Wayland. I don't see that mentioned at > https://community.kde.org/Plasma/Wayland_Known_Significant_Issues > > My understanding is that it's now possible using libEI, but only Gnome > makes use of that. Support for KDE is tracked by > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but > doesn't look close to being ready. It is targeted for Plasma 6.1, with the first step written for kwin: https://invent.kde.org/plasma/kwin/-/merge_requests/5412 -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel wrote: > > I have just found another essential feature that is missing in Plasma > Wayland: The big one for me is that Synergy and similar tools barrier and input-leap don't work under Wayland. I don't see that mentioned at https://community.kde.org/Plasma/Wayland_Known_Significant_Issues My understanding is that it's now possible using libEI, but only Gnome makes use of that. Support for KDE is tracked by https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but doesn't look close to being ready. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: QGIS rebuild needed after GRASS GIS update
Hi Markus I'm happy to help coordinating the grass update. Note however that: - If the update does not carry ABI changes (and hence soname bumps), a rebuild of QGIS is not needed - If The update does carry a soname bump, it should be avoided in stable releases Sandro On 19.03.24 13:44, Markus Neteler wrote: Hi, While being a maintainer of the GRASS GIS rpms for years, I am not fully sure about the procedure to get QGIS rebuilds triggered (in a side-tag with GRASS GIS). I have updated GRASS GIS to the latest stable: https://bugzilla.redhat.com/show_bug.cgi?id=2268514 and submitted it to - https://src.fedoraproject.org/rpms/grass/commits/rawhide - https://src.fedoraproject.org/rpms/grass/commits/f40 - https://src.fedoraproject.org/rpms/grass/commits/f39 What would be the next step? I don't have write access for QGIS (https://src.fedoraproject.org/rpms/qgis). Sorry if this is RTFM, the procedure isn't fully clear to me :) Thanks, Markus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tue, 2024-03-19 at 14:22 +0100, Allan via devel wrote: > På Tue, 19 Mar 2024 09:09:26 -0400 > "Garry T. Williams" skrev: > > On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote: > > > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote: > > > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via > > > > devel wrote: > > > > > Garry T. Williams wrote: > > > > > > I hope my report can be resolved before I am forced to use > > > > > > Wayland. > > > > > > > > > > You will not be forced to use Wayland. Stay tuned. > > > > > > > > In an effort to test a Wayland bug I reported upstream, I > > > > upgraded my laptop to f40. (I am holding off on upgrading my > > > > workstation.) My reported bug is still there, but here I am > > > > without x11. I installed kwin-x11. My login screen no longer > > > > offers to run it instead of kwin-wayland. Is there a way to > > > > run > > > > x11 on f40? (There are still several annoying bugs in Wayland > > > > that I would like to avoid.) > > > > > > "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading > > > to > > > Fedora 40 > > > > > > you may reinstall the package, it will not be obsoleted anymore. > > > > > > I don't agree with this behavior > > > > OK, but how do I run kwin-x11 instead of -wayland? > > > > You need plasma-workspace-x11 too. After reinstall kwin-x11 and plasma-workspace-x11 , in desktop display manager (for example sddm) you should have the option to login in plasma-x11 -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Fedora rawhide compose report: 20240319.n.0 changes
OLD: Fedora-Rawhide-20240318.n.0 NEW: Fedora-Rawhide-20240319.n.0 = SUMMARY = Added images:3 Dropped images: 1 Added packages: 6 Dropped packages:0 Upgraded packages: 97 Downgraded packages: 0 Size of added packages: 3.69 MiB Size of dropped packages:0 B Size of upgraded packages: 7.84 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 8.32 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20240319.n.0.iso Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240319.n.0.x86_64.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240319.n.0.aarch64.iso = DROPPED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240318.n.0.iso = ADDED PACKAGES = Package: hyprcursor-0.1.4-1.fc41 Summary: The hyprland cursor format, library and utilities RPMs:hyprcursor hyprcursor-devel Size:516.16 KiB Package: python-arm-preprocessing-0.2.1-1.fc41 Summary: Data preprocessing for Association Rule Mining (ARM) RPMs:python3-arm-preprocessing Size:30.91 KiB Package: python-cmap-0.2.0-1.fc41 Summary: Scientific colormaps for python, without dependencies RPMs:python3-cmap Size:1.16 MiB Package: python-openneuro-2024.2.0-1.fc41 Summary: A Python client for OpenNeuro RPMs:python3-openneuro Size:54.66 KiB Package: python-pytest-qt-4.4.0-1.fc41 Summary: pytest support for PyQt and PySide applications RPMs:python3-pytest-qt Size:98.38 KiB Package: xnvme-0.7.4-2.fc41 Summary: Unified API and tools for traditional and emerging I/O interfaces RPMs:xnvme xnvme-devel xnvme-static xnvme-tools Size:1.85 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 90-Second-Portraits-1.01b-22.fc41 Old package: 90-Second-Portraits-1.01b-21.fc40 Summary: Frantic street painting game RPMs: 90-Second-Portraits Size: 4.95 MiB Size change: 27 B Changelog: * Fri Feb 23 2024 Songsong Zhang - 1.01b-22 - Add riscv64 support Package: Lmod-8.7.37-1.fc41 Old package: Lmod-8.7.32-3.fc40 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.03 MiB Size change: 6.53 KiB Changelog: * Mon Mar 18 2024 Orion Poplawski - 8.7.37-1 - Update to 8.7.37 Package: NetworkManager-ssh-1.2.13-1.fc41 Old package: NetworkManager-ssh-1.2.12-5.fc38 Summary: NetworkManager VPN plugin for SSH RPMs: NetworkManager-ssh NetworkManager-ssh-gnome Size: 478.62 KiB Size change: 36.83 KiB Changelog: * Wed Jul 19 2023 Fedora Release Engineering - 1.2.12-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 1.2.12-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Mon Jan 22 2024 Fedora Release Engineering - 1.2.12-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Mar 15 2024 Dan Fruehauf - 1.2.13-1 - Fix build - Update to gtk4 version Package: arm-none-eabi-newlib-4.4.0.20231231-1.fc41 Old package: arm-none-eabi-newlib-4.3.0.20230120-6.fc40 Summary: C library intended for use on arm-none-eabi embedded systems RPMs: arm-none-eabi-newlib Size: 40.49 MiB Size change: -480.83 KiB Changelog: * Mon Mar 18 2024 Michal Hlavinka - 4.4.0.20231231-1 - updated to 4.4.0.20231231 Package: armacycles-ad-0.2.9.2.3-1.20240318gitv0.2.9.2.3.fc41 Old package: armacycles-ad-0.2.9.2.1-1.20240312gitv0.2.9.2.1.fc41 Summary: A lightcycle game in 3D RPMs: armacycles-ad armacycles-ad-dedicated Size: 9.01 MiB Size change: 707 B Changelog: * Mon Mar 18 2024 Gwyn Ciesla - 0.2.9.2.3-1 - 0.2.9.2.3 Package: auditwheel-6.0.0-1.fc41 Old package: auditwheel-5.4.0-3.fc40 Summary: Cross-distribution Linux wheels auditing and relabeling RPMs: auditwheel Size: 108.64 KiB Size change: -25.54 KiB Changelog: * Sun Mar 17 2024 Charalampos Stratakis - 6.0.0-1 - Update to 6.0.0 - Resolves: rhbz#2262516 Package: awscli2-2.15.30-1.fc41 Old package: awscli2-2.15.10-3.fc40 Summary: Universal Command Line Environment for AWS, version 2 RPMs: awscli2 Size: 12.51 MiB Size change: 127.40 KiB Changelog: * Sat Mar 16 2024 Packit - 2.15.30-1 - [packit] 2.15.30 upstream release - Resolves rhbz#2259063 Package: bash-completion-1:2.12-1.fc41 Old package: bash-completion-1:2.11-15.fc41 Summary: Programmable completion for Bash RPMs: bash-completion bash-completion-devel Size: 457.56 KiB Size change: 88.54 KiB Changelog: * Mon Mar 18 2024 Siteshwar Vashisht - 1:2.12-1 - Update to version 2.12.0 Package: bcd-1.1
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
På Tue, 19 Mar 2024 09:09:26 -0400 "Garry T. Williams" skrev: > On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote: > > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote: > > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via > > > devel wrote: > > > > Garry T. Williams wrote: > > > > > I hope my report can be resolved before I am forced to use > > > > > Wayland. > > > > > > > > You will not be forced to use Wayland. Stay tuned. > > > > > > In an effort to test a Wayland bug I reported upstream, I > > > upgraded my laptop to f40. (I am holding off on upgrading my > > > workstation.) My reported bug is still there, but here I am > > > without x11. I installed kwin-x11. My login screen no longer > > > offers to run it instead of kwin-wayland. Is there a way to run > > > x11 on f40? (There are still several annoying bugs in Wayland > > > that I would like to avoid.) > > > > "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to > > Fedora 40 > > > > you may reinstall the package, it will not be obsoleted anymore. > > > > I don't agree with this behavior > > OK, but how do I run kwin-x11 instead of -wayland? > You need plasma-workspace-x11 too. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: QGIS rebuild needed after GRASS GIS update
Hello Markus, From my understanding, you either have to be the maintainer / co-maintainer of QGIS or a provenpackager to initiate the build. If you are neither of those, then you need to ask the maintainers of QGIS or a provenpackager to do the rebuild in your side-tag. Hussein Am 19.03.24 um 13:44 schrieb Markus Neteler: Hi, While being a maintainer of the GRASS GIS rpms for years, I am not fully sure about the procedure to get QGIS rebuilds triggered (in a side-tag with GRASS GIS). I have updated GRASS GIS to the latest stable: https://bugzilla.redhat.com/show_bug.cgi?id=2268514 and submitted it to - https://src.fedoraproject.org/rpms/grass/commits/rawhide - https://src.fedoraproject.org/rpms/grass/commits/f40 - https://src.fedoraproject.org/rpms/grass/commits/f39 What would be the next step? I don't have write access for QGIS (https://src.fedoraproject.org/rpms/qgis). Sorry if this is RTFM, the procedure isn't fully clear to me :) Thanks, Markus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
[Bug 2270256] perl-DBD-MySQL-5.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|MODIFIED|CLOSED Fixed In Version||perl-DBD-MySQL-5.004-1.fc41 Last Closed||2024-03-19 13:11:42 --- Comment #3 from Fedora Update System --- FEDORA-2024-75074892af (perl-DBD-MySQL-5.004-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270256%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote: > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote: > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via devel > > wrote: > > > Garry T. Williams wrote: > > > > I hope my report can be resolved before I am forced to use > > > > Wayland. > > > > > > You will not be forced to use Wayland. Stay tuned. > > > > In an effort to test a Wayland bug I reported upstream, I upgraded my > > laptop to f40. (I am holding off on upgrading my workstation.) My > > reported bug is still there, but here I am without x11. I installed > > kwin-x11. My login screen no longer offers to run it instead of > > kwin-wayland. Is there a way to run x11 on f40? (There are still > > several annoying bugs in Wayland that I would like to avoid.) > > "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to > Fedora 40 > > you may reinstall the package, it will not be obsoleted anymore. > > I don't agree with this behavior OK, but how do I run kwin-x11 instead of -wayland? -- Garry T. Williams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
[Bug 2270256] perl-DBD-MySQL-5.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270256 --- Comment #2 from Fedora Update System --- FEDORA-2024-75074892af (perl-DBD-MySQL-5.004-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-75074892af -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270256%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270256] perl-DBD-MySQL-5.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-277e98e1b9 (perl-DBD-MySQL-5.004-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-277e98e1b9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270256%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: gloox soname bump
> On Tuesday, 19 March 2024 at 09:41, David Bold wrote: > > Builds completed. I think you can submit the updates yourself now. > Next time, I'd suggest opening a pull request against > each of the packages you want to rebuild. That saves time for PPs. > > Regards, > Dominik Submitting updates did indeed work without PP powers. I didn't know that submitting PRs works for rebuilds as well, I will do it in the future. Thanks a lot, David -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
QGIS rebuild needed after GRASS GIS update
Hi, While being a maintainer of the GRASS GIS rpms for years, I am not fully sure about the procedure to get QGIS rebuilds triggered (in a side-tag with GRASS GIS). I have updated GRASS GIS to the latest stable: https://bugzilla.redhat.com/show_bug.cgi?id=2268514 and submitted it to - https://src.fedoraproject.org/rpms/grass/commits/rawhide - https://src.fedoraproject.org/rpms/grass/commits/f40 - https://src.fedoraproject.org/rpms/grass/commits/f39 What would be the next step? I don't have write access for QGIS (https://src.fedoraproject.org/rpms/qgis). Sorry if this is RTFM, the procedure isn't fully clear to me :) Thanks, Markus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
[Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!
According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/40 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab All Beta priority test cases for each of these [test pages][2] must pass in order to meet the [Beta Release Criteria][3]. Help is available on [the Fedora Quality chat channel][4], [the Fedora Quality tag on Discourse][5], or on [the test list][6]. Current Blocker and Freeze Exception bugs: https://qa.fedoraproject.org/blockerbugs/current [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria [4]: https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team [6]: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@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/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
User SSH access to Copr builders
Hello, this may be a useful feature for many people, so I wanted to announce it separately. Debugging failed Copr builds became much easier with the last release. https://docs.pagure.org/copr.copr/release-notes/2024-03-07.html You can now enable SSH access to the builder, connect using your pubkey, and run any commands you need to debug the issue. Everything is explained in my blog post. https://frostyx.cz/posts/ssh-access-to-copr-builders Jakub -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Package conflict management advice
Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar :
>
> Dear all,
>
> I'm looking for options/advice here. See [1], and a bit of context:
>
> - RStudio (now Posit.co) publishes two packages named rstudio (with RStudio
> Desktop) and rstudio-server (with RStudio Server). They are independent and
> have many files in common. Recent versions are based on Electron (for
> Desktop) and have Quarto support.
>
> - In Fedora, we decided to package all the common files in the rstudio
> package, then build rstudio-desktop and rstudio-server for these products,
> with just the specific files. In our build, we rely on QtWebEngine for the
> Desktop version and disable Quarto, because it would be a nightmare to
> package (requires Deno).
>
> Now the issue [1]: there's always been confusion among users that at some
> point install the rstudio package provided by Posit (which provides
> everything), many times because RStudio prompts that there's a new version
> available and they just go click unknowingly. After some time, the package
> manager "updates" it to our version when we hit stable, and RStudio Desktop
> is gone (because rstudio-desktop is not present). Some time ago, I disabled
> the "new version" notification dialog to mitigate this, but these days this
> happens more and more frequently because users want Quarto and specifically
> opt for the package provided by Posit.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
>
> What do you think is the best way to mitigate this? Options:
>
> 1. Keep things as they are, just tell the users to exclude the rstudio
> package in the dnf configuration. Pros: no changes required. Cons: it's clear
> that users don't know how to do this. And more documentation rarely solves
> this kind of problem.
>
> 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager
> updates to our version, at least there's a working version of RStudio
> installed. Cons: Server users shouldn't need Desktop installed. Still
> confusing to users.
>
> 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that just
> Requires rstudio-desktop. Pros: Same as before + Server doesn't need Desktop.
> Cons: Still confusing to users.
>
> 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio. Pros:
> You either install rstudio from Posit, or rstudio-desktop from Fedora. And
> I'm not sure about this, but does installing one remove the other? Or does
> dnf at least show the conflict and the user decides? Cons: `dnf install
> rstudio` doesn't work anymore, so it's less discoverable. And we have a
> similar issue with rstudio-server anyways that cannot be easily solved. But I
> suppose that admins installing rstudio-server know how to prevent package
> updates.
>
> 5. Introduce some version component that makes our package versions be sorted
> < than Posit's. Pros: Upgrades never happen when a user opts for packages
> provided by Posit. Cons: I don't know how to do this without breaking our
> updates. Probably other issues?
>
> Any advice? Other options not considered here?
Wow, contrived situation. I guess this shows again that packaging
should be left to packagers, not upstream :)
4. seems to be the only solution where "problematic but typical" user
behaviour leads to explicit conflicts rather than "funny" behaviour.
`dnf` will bail out and explain the conflicts ("cannot install both
...") and even suggest to use "allow-erasing", which cleans things up.
dnf will not offer "rstudio" updates if there is no such package in
Fedora repos.
Even in this case, one can only hope that users don't switch
inadvertently between "upstream" and Fedora. At least it requires
extra steps with 4 (though I don't now about pkgkit).
Cheers
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: gloox soname bump
On Tuesday, 19 March 2024 at 09:41, David Bold wrote: > > Hi Fedorians, > > > > I intend to update gloox to 1.0.28 which comes with a soname bump. > > 0ad and uwsgi depend on gloox [0]. > > > > I have successfully rebuild both in copr [1]. > > > > I will rebuild gloox in the following side tags: > > fedpkg build --target=f41-build-side-85385 > > fedpkg build --target=f40-build-side-85387 > > > > Help with the rebuilds would be greatly appreciated, as I do not have > > permission for those > > two packages. > > > > Best, David > > It has been a bit over a week. Could I please get some help from a > provenpackager to rebuild the two dependencies and submit the update? Builds completed. I think you can submit the updates yourself now. Next time, I'd suggest opening a pull request against each of the packages you want to rebuild. That saves time for PPs. 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 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Package conflict management advice
Dear all, I'm looking for options/advice here. See [1], and a bit of context: - RStudio (now Posit.co) publishes two packages named rstudio (with RStudio Desktop) and rstudio-server (with RStudio Server). They are independent and have many files in common. Recent versions are based on Electron (for Desktop) and have Quarto support. - In Fedora, we decided to package all the common files in the rstudio package, then build rstudio-desktop and rstudio-server for these products, with just the specific files. In our build, we rely on QtWebEngine for the Desktop version and disable Quarto, because it would be a nightmare to package (requires Deno). Now the issue [1]: there's always been confusion among users that at some point install the rstudio package provided by Posit (which provides everything), many times because RStudio prompts that there's a new version available and they just go click unknowingly. After some time, the package manager "updates" it to our version when we hit stable, and RStudio Desktop is gone (because rstudio-desktop is not present). Some time ago, I disabled the "new version" notification dialog to mitigate this, but these days this happens more and more frequently because users want Quarto and specifically opt for the package provided by Posit. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191 What do you think is the best way to mitigate this? Options: 1. Keep things as they are, just tell the users to exclude the rstudio package in the dnf configuration. Pros: no changes required. Cons: it's clear that users don't know how to do this. And more documentation rarely solves this kind of problem. 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager updates to our version, at least there's a working version of RStudio installed. Cons: Server users shouldn't need Desktop installed. Still confusing to users. 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that just Requires rstudio-desktop. Pros: Same as before + Server doesn't need Desktop. Cons: Still confusing to users. 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio. Pros: You either install rstudio from Posit, or rstudio-desktop from Fedora. And I'm not sure about this, but does installing one remove the other? Or does dnf at least show the conflict and the user decides? Cons: `dnf install rstudio` doesn't work anymore, so it's less discoverable. And we have a similar issue with rstudio-server anyways that cannot be easily solved. But I suppose that admins installing rstudio-server know how to prevent package updates. 5. Introduce some version component that makes our package versions be sorted < than Posit's. Pros: Upgrades never happen when a user opts for packages provided by Posit. Cons: I don't know how to do this without breaking our updates. Probably other issues? Any advice? Other options not considered here? Best, -- Iñaki Úcar -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
[Bug 2270204] perl-Variable-Magic-0.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270204 --- Comment #3 from Fedora Update System --- FEDORA-2024-fef134e490 (perl-Variable-Magic-0.64-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-fef134e490 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270204%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270204] perl-Variable-Magic-0.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Fixed In Version||perl-Variable-Magic-0.64-1. ||fc41 Last Closed||2024-03-19 10:35:18 --- Comment #2 from Fedora Update System --- FEDORA-2024-f088df2c01 (perl-Variable-Magic-0.64-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270204%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270204] perl-Variable-Magic-0.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-f088df2c01 (perl-Variable-Magic-0.64-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f088df2c01 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270204 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270204%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2270256] New: perl-DBD-MySQL-5.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Bug ID: 2270256 Summary: perl-DBD-MySQL-5.004 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DBD-MySQL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, msch...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 5.004 Upstream release that is considered latest: 5.004 Current version/release in rawhide: 5.003-3.fc40 URL: https://metacpan.org/dist/DBD-mysql/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2807/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-DBD-MySQL -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2270256 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270256%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: gloox soname bump
> Hi Fedorians, > > I intend to update gloox to 1.0.28 which comes with a soname bump. > 0ad and uwsgi depend on gloox [0]. > > I have successfully rebuild both in copr [1]. > > I will rebuild gloox in the following side tags: > fedpkg build --target=f41-build-side-85385 > fedpkg build --target=f40-build-side-85387 > > Help with the rebuilds would be greatly appreciated, as I do not have > permission for those > two packages. > > Best, David It has been a bit over a week. Could I please get some help from a provenpackager to rebuild the two dependencies and submit the update? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
[Test-Announce] Re: Fedora 40 Candidate Beta-1.8 Available Now!
On Tue, 2024-03-19 at 05:58 +, rawh...@fedoraproject.org wrote: > According to [the schedule][1], Fedora 40 Candidate Beta-1.8 is now > available for testing. Please help us complete all the validation > testing! For more information on release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Test coverage information for the current release can be seen at: > https://openqa.fedoraproject.org/testcase_stats/40 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.8_Summary Note on this: a 1.9 will be coming which should be identical to 1.8 except with Cinnamon and Budgie fixed (they were broken by the GNOME 46 FE in 1.8, and their images are missing). Testing on 1.8 is still useful and can mostly be transferred to 1.9, but you might want to wait 6-7 hours for 1.9 to show up before starting testing. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@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/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
