Re: Orphaning packages
I've taken aria2 and thc-ipv6. Thank you for your contributions, Othman! --Neil On 22.06.2023 18:48, Othman Madjoudj wrote: Hello, Please note that I've orphaned by packages, list in the end of the message. Best regards -Othman rpms/aria2 rpms/hydra rpms/libmodsecurity rpms/lynis rpms/mod_limitipconn rpms/mod_qos rpms/mod_ruid2 rpms/mod_security3 rpms/mod_security_crs rpms/python-paramiko rpms/thc-ipv6 rpms/unhide ___ 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 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
[EPEL-devel] Re: Orphaning packages
I've taken aria2 and thc-ipv6. Thank you for your contributions, Othman! --Neil On 22.06.2023 18:48, Othman Madjoudj wrote: Hello, Please note that I've orphaned by packages, list in the end of the message. Best regards -Othman rpms/aria2 rpms/hydra rpms/libmodsecurity rpms/lynis rpms/mod_limitipconn rpms/mod_qos rpms/mod_ruid2 rpms/mod_security3 rpms/mod_security_crs rpms/python-paramiko rpms/thc-ipv6 rpms/unhide ___ devel mailing list -- de...@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/de...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue signature.asc Description: PGP signature ___ 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
Fedora rawhide compose report: 20230622.n.1 changes
OLD: Fedora-Rawhide-20230621.n.0 NEW: Fedora-Rawhide-20230622.n.1 = SUMMARY = Added images:13 Dropped images: 1 Added packages: 5 Dropped packages:0 Upgraded packages: 82 Downgraded packages: 0 Size of added packages: 14.85 MiB Size of dropped packages:0 B Size of upgraded packages: 1.62 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 10.05 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server_KVM qcow2 aarch64 Path: Server/aarch64/images/Fedora-Server-KVM-Rawhide-20230622.n.1.aarch64.qcow2 Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230622.n.1.s390x.qcow2 Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230622.n.1.s390x.raw.xz Image: KDE raw-xz aarch64 Path: Spins/aarch64/images/Fedora-KDE-Rawhide-20230622.n.1.aarch64.raw.xz Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230622.n.1.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230622.n.1.iso Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20230622.n.1.iso Image: Server_KVM qcow2 s390x Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20230622.n.1.s390x.qcow2 Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230622.n.1.iso Image: Server_KVM qcow2 x86_64 Path: Server/x86_64/images/Fedora-Server-KVM-Rawhide-20230622.n.1.x86_64.qcow2 Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230622.n.1.ppc64le.qcow2 Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230622.n.1.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20230622.n.1.iso = DROPPED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20230621.n.0.ppc64le.tar.xz = ADDED PACKAGES = Package: python-pyembroidery-1.4.36-1.fc39 Summary: Library for reading and writing a variety of embroidery formats RPMs:python3-pyembroidery Size:268.73 KiB Package: python-setuptools-git-versioning-1.13.3-3.fc39 Summary: Use git repo data for building a version number according PEP-440 RPMs:python3-setuptools-git-versioning Size:30.59 KiB Package: qxmpp-1.5.5-2.fc39 Summary: Cross-platform C++ XMPP client and server library RPMs:qxmpp-doc qxmpp-qt5 qxmpp-qt5-devel qxmpp-qt6 qxmpp-qt6-devel Size:13.11 MiB Package: rust-bitvec_helpers-3.1.2-1.fc39 Summary: BitVec based bitstream reader and writer RPMs:rust-bitvec_helpers+bitstream-io-devel rust-bitvec_helpers+bitvec-devel rust-bitvec_helpers+default-devel rust-bitvec_helpers-devel Size:35.84 KiB Package: rust-dolby_vision-3.1.2-1.fc39 Summary: Dolby Vision metadata parsing and writing RPMs:libdovi libdovi-devel rust-dolby_vision+capi-devel rust-dolby_vision+default-devel rust-dolby_vision+libc-devel rust-dolby_vision+roxmltree-devel rust-dolby_vision+serde-devel rust-dolby_vision+xml-devel rust-dolby_vision-devel Size:1.41 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: aide-0.18.4-2.fc39 Old package: aide-0.16-22.fc38 Summary: Intrusion detection environment RPMs: aide Size: 583.67 KiB Size change: -27.18 KiB Changelog: * Tue Jun 13 2023 Radovan Sroka - 0.16-23 - migrated to SPDX license * Wed Jun 21 2023 Radovan Sroka - 0.18.4-1 - aide-0.18.4 is available Resolves: rhbz#1910486 - Please port your pcre dependency to pcre2. Pcre has been deprecated Resolves: rhbz#2128267 Package: attract-mode-2.7.0-1.fc39 Old package: attract-mode-2.6.2-6.fc39 Summary: A graphical front-end for command line emulators RPMs: attract-mode attract-mode-data Size: 13.43 MiB Size change: 4.93 MiB Changelog: * Wed Jun 21 2023 Davide Cavalca - 2.7.0-1 - Update to 2.7.0; Fixes: RHBZ#2216385 Package: awscli-1.27.158-1.fc39 Old package: awscli-1.27.156-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.32 MiB Size change: 198 B Changelog: * Wed Jun 21 2023 Gwyn Ciesla - 1.27.157-1 - 1.27.157 * Wed Jun 21 2023 Gwyn Ciesla - 1.27.158-1 - 1.27.158 Package: barman-3.6.0-1.fc39 Old package: barman-3.5.0-3.fc39 Summary: Backup and Recovery Manager for PostgreSQL RPMs: barman barman-cli python3-barman Size: 689.06 KiB Size change: 11.25 KiB Changelog: * Tue Jun 13 2023 Python Maint - 3.5.0-4 - Rebuilt for Python 3.12 * Thu Jun 22 2023 Simone Caronni - 3.6.0-1 - Update to 3.6.0. Package: btrfs-progs-6.3.2-1.fc39 Old package: btrfs-progs-6.3.1-1.fc39 Summary: Userspace programs for btrfs RPMs: btrfs-progs btrfs-progs-devel libbtrfs
Re: Changes to build environment
On Thursday, June 22, 2023 2:11:45 PM EDT Dmitry Belyavskiy wrote: > I usually use smth like > RPM_ARCH=1 RPM_PACKAGE_RELEASE=2 RPM_PACKAGE_VERSION=3 RPM_PACKAGE_NAME=4 > make in this situation and have never got any problem yet. Dmitry, you are a saint. :-) I cannot accept this as the new normal. -Steve ___ 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: Changes to build environment
On Thursday, June 22, 2023 2:14:22 PM EDT Fabio Valentini wrote: > On Thu, Jun 22, 2023 at 7:57 PM Steve Grubb wrote: > > I have switched to F38 and find a couple items annoying. I have a > > workflow that checks things I develop out of github, rolls it up into > > an rpm, builds it, and runs the results through annocheck. > > > > If there is a warning I'd like to investigate, I cd into the build > > directory. But oops, now its gone (problem #1). OK, I use rpmbuild -bc > > to rebuild it. I cd into the build directory make a change and run make. > > > > gcc: fatal error: environment variable 'RPM_ARCH' not defined > > > > (problem #2) > > > > How do I fix these things? > > Not sure if these *can* be fixed in general. This worked fine in F37. There is some intentional change somewhere that causes this. > #1 is a behaviour change of RPM in a recent release, but there's a CLI > switch to turn off cleaning up the build directory. Is there a rpmmacros configuration option that undoes this so I do not have to fix dozens of scripts? > In the case of RPM_ARCH, it's because the CFLAGS / LDFLAGS (I think?) > build flags set in %build use this environment variable. This sounds like something rolled out without proper automake/autoconf support. If rpmbuild is supplying this during build, it should not. It should supply this to configure and it get captured into the Makefile and then into the link targets. This is a very recent problem. I now complain about #1 because we now have #2. > I think trying to recreate the RPM build environment outside of mock > manually (to reproduce issues) is a lost cause though (and you get a > different environment than the one that had the issue!) ...It's not > perfect, but mock is almost always the best way to build RPMs (i.e. > never use "rpmbuild -bb" outside mock), but that's just my opinion > ¯\_(ツ)_/¯ It works fine on F37. This is a recent regression. -Steve ___ 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 2213444] perl-DBIx-RunSQL-0.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2213444 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Fixed In Version||perl-DBIx-RunSQL-0.24-1.fc3 ||8 Last Closed||2023-06-23 01:01:39 --- Comment #8 from Fedora Update System --- FEDORA-2023-915f556cf5 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=2213444 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202213444%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
[Bug 2210861] perl-Array-Unique-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2210861 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Array-Unique-0.09-1.fc ||38 Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2023-06-23 01:01:36 --- Comment #5 from Fedora Update System --- FEDORA-2023-c49f4314f8 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=2210861 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202210861%23c5 ___ 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: What is Fedora?
22/06/23 11:06, Matthew Miller wrote: On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote: In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder. EPEL packagers should have easy access to RHEL through the no-cost subscription program. Why should we keep contributing to EPEL? To be forced to use 16 free RHEL instances maximum? What is the advantage for us volunteer contributors? I mean, we did not do it for personal advantage, we did it to help us each other within the Enterprise Linux distros community, but this Red Hat move will kill the Enterprise Linux distros community, leaving only with RHEL, which is mostly a paid subscription distribution, let's call things with their proper name ___ 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: Fedora-Rawhide testing blocked in Testing Farm (partially)
To mitigate errors, I am proposing to disable Rawhide testing via Zull in dist-git PRs: https://pagure.io/fedora-zuul-jobs-config/pull-request/180 /M On Thu, Jun 22, 2023 at 11:19 PM Miroslav Vadkerti wrote: > Hi, > > A small update, Zuul testing is still blocked, please use the results > `Fedora CI - dist-git test` in the PR testing. > > The upstream bug that will need to be fixed to unblock Zuul testing: > > https://github.com/rpm-software-management/dnf5/issues/549 > > Other problems are hopefully resolved. > > Best regards, > /M > > On Thu, Jun 22, 2023 at 11:16 AM Miroslav Vadkerti > wrote: > >> Hi, >> >> a few more issues appeared: >> >> 1. Testing PRs via Zuul is broken due to missing feature in dnf5 >>https://github.com/rpm-software-management/dnf5/issues/549 >> >>No ETA for fixing this one >> 2. Packit's sanity copr installation test fails due to to dnf5-plugins >> needed for copr plugin. >> >>ETA 30 min. >> >> Best regards, >> /M< >> >> >> On Wed, Jun 21, 2023 at 7:39 PM Miroslav Vadkerti >> wrote: >> >>> Both issues were hot patched, and testing against Rawhide is unblocked >>> again \o/ >>> >>> Thanks to all who helped! >>> >>> /M >>> >>> On Wed, Jun 21, 2023 at 2:51 PM Miroslav Vadkerti >>> wrote: >>> Hi, Fedora Rawhide testing blocked on dnf5 update, which broke Testing Farm. We are trying to hotpatch the problems to bring back testing against Rawhide. ETA 2 hours. For updates watch: https://status.testing-farm.io/issues/2023-06-21-rawhide-outage/ Best regards, /M -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o >>> >>> -- >>> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE >>> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 >>> Remote Czech Republic :: Red Hat Czech s.r.o >>> >>> >>> >> >> -- >> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE >> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 >> Remote Czech Republic :: Red Hat Czech s.r.o >> >> >> > > -- > Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE > IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 > Remote Czech Republic :: Red Hat Czech s.r.o > > > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o ___ 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: Fedora-Rawhide testing blocked in Testing Farm (partially)
Hi, A small update, Zuul testing is still blocked, please use the results `Fedora CI - dist-git test` in the PR testing. The upstream bug that will need to be fixed to unblock Zuul testing: https://github.com/rpm-software-management/dnf5/issues/549 Other problems are hopefully resolved. Best regards, /M On Thu, Jun 22, 2023 at 11:16 AM Miroslav Vadkerti wrote: > Hi, > > a few more issues appeared: > > 1. Testing PRs via Zuul is broken due to missing feature in dnf5 >https://github.com/rpm-software-management/dnf5/issues/549 > >No ETA for fixing this one > 2. Packit's sanity copr installation test fails due to to dnf5-plugins > needed for copr plugin. > >ETA 30 min. > > Best regards, > /M< > > > On Wed, Jun 21, 2023 at 7:39 PM Miroslav Vadkerti > wrote: > >> Both issues were hot patched, and testing against Rawhide is unblocked >> again \o/ >> >> Thanks to all who helped! >> >> /M >> >> On Wed, Jun 21, 2023 at 2:51 PM Miroslav Vadkerti >> wrote: >> >>> Hi, >>> >>> Fedora Rawhide testing blocked on dnf5 update, which broke Testing Farm. >>> >>> We are trying to hotpatch the problems to bring back testing against >>> Rawhide. >>> >>> ETA 2 hours. >>> >>> For updates watch: >>> https://status.testing-farm.io/issues/2023-06-21-rawhide-outage/ >>> >>> Best regards, >>> /M >>> >>> -- >>> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE >>> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 >>> Remote Czech Republic :: Red Hat Czech s.r.o >>> >>> >>> >> >> -- >> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE >> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 >> Remote Czech Republic :: Red Hat Czech s.r.o >> >> >> > > -- > Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE > IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 > Remote Czech Republic :: Red Hat Czech s.r.o > > > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o ___ 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: Changes to build environment
On Thu, 2023-06-22 at 13:56 -0400, Steve Grubb wrote: > Hello, > > I have switched to F38 and find a couple items annoying. I have a > workflow that > checks things I develop out of github, rolls it up into an rpm, > builds it, > and runs the results through annocheck. > > If there is a warning I'd like to investigate, I cd into the build > directory. > But oops, now its gone (problem #1). OK, I use rpmbuild -bc to > rebuild it. I > cd into the build directory make a change and run make. > > gcc: fatal error: environment variable 'RPM_ARCH' not defined > > (problem #2) > > How do I fix these things? I think this is the bug related with you issue : https://bugzilla.redhat.com/show_bug.cgi?id=2043092 IIUC you can add '%undefine _package_note_flags' Best regards, -- 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
Re: Orphaning packages
On Thursday, June 22, 2023 11:48:18 AM CDT Othman Madjoudj wrote: > Hello, > > Please note that I've orphaned by packages, list in the end of the message. > > Best regards > -Othman > > > rpms/aria2 > rpms/hydra > rpms/libmodsecurity > rpms/lynis > rpms/mod_limitipconn > rpms/mod_qos > rpms/mod_ruid2 > rpms/mod_security3 > rpms/mod_security_crs > rpms/python-paramiko > rpms/thc-ipv6 > rpms/unhide I've taken hydra and unhide. -- Robby Callicotte He/His Timezone: US/Central ___ 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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
On Thu, Jun 22, 2023 at 5:02 AM Matthew Miller wrote: > > >> ELN is a build of (some) Fedora packages with EL-specific options, so > >> it requires Fedora. > > ELN can exist off an internal non fedora tree. Just depends who is > > updating the tree. > > Sure, but... that's the _opposite_ of the direction things are going. > Previously, what happened to make a major RHEL release was: > > 1. Some Fedora Linux Release -> an internal bootstrap > 2. ... a year or so of secret work ... > 3. RHEL Beta > 4. RHEL Release > 5. CentOS Linux rebuild > 6. Internal RHEL build process, internal work on minor release > 7. RHEL updates appear in publiuc > 8. CentOS Linux rebuilds of those. > > There's no connection to Fedora beyond the intial fork, and a lot of work > done inside Red Hat without any transparency. > > > Now, CentOS Stream brings that to the surface: > > 1. Fedora Rawhide continually updated > 2. ELN maintained in parallel, as part of Fedora > 3. At some point, ELN branched to new CentOS Stream > 4. ... a year or so of CentOS Stream development in public ... > 5. RHEL Beta forked from that, released > 6. Work on RHEL updates visible in CentOS Stream > 7. Updates appear in CentOS Stream > 8. Updates released to RHEL > > Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git > history from Fedora, which is a big improvement in preserving all of the > incredible, valuable work from Fedora contributors. > > All of this is the exact opposite of Red Hat preparing to make some new base > for RHEL. Additionally, this model provides a clean path for > Red-Hat-opinionated decisions to differ from those we make from Fedora. Take > BTRFS as an example. Or, the increase in CPU baseline. Like this: > > > Fedora Linux: Community Space > - > > * Community engineering decisions > * No special code privileges due to your employer > * Community-run infrastructure with RH investment, significant resources > from Amazon, contributions from other companies > * Community quality engineering with RH investment > * Community support > * No cost > > > CentOS Stream: Shared Space > --- > > * Red Hat Engineering decisions with community input > * Pull requests from the community, approval from Red Hat engineers > * Red Hat-provided and maintained infrastructure > * Red Hat quality engineering with partner and community involvement > * Community support > * no cost > > > Red Hat Enterprise Linux: Product Space > --- > > * Red Hat Engineering decisions with customer input > * Red Hat engineers and only RH engineers do the work > * Red Hat infrastructure > * Red Hat quality engineering (mostly done in Stream, though) > * Enterprise support > * Subscription, including low- and no-cost options > > > Previously, we had a whole convoluted thing which people tried to describe > in terms of MC Escher paintings. This is far better, and Fedora is in a > better place. In the earlier setup, CentOS _was_ sometimes positioned as a > competitor (although generally, those of us working in the actual Fedora and > CentOS communities didn't have any interest in playing that game.) Agree with Matthew fully here. We've been working rather hard internally to adjust the development process for RHEL to be more collaborative and open than it ever has before. josh ___ 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: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
Hi, On 6/22/23 12:28, Zbigniew Jędrzejewski-Szmek wrote: https://fedoraproject.org/wiki/Changes/cleanup_systemd_install == Detailed Description == As a first pass, the 'inst.sdboot' option already in anaconda should work. As it stands, that replaces grub+shim with the systemd-boot loader, and moves the kernel + initrd to the EFI system partition (ESP). In general, I think it's great to see this happening. Thank you! Well thanks for looking at it :) It doesn't attempt to create unified kernel images, so the existing `dnf update`, `kdumpctl`, and `make install` in a kernel source directory should all work. Nitpick: 'make install' invokes /usr/bin/installkernel which (sometimes?) invokes kernel-install which will create a UKI, if the configuration specifies that. This sentence implies that 'make install' has some issue with UKIs, but that is not true. /usr/bin/installkernel does a lot of stuff, most of it probably wrong. We could 'ln -sf --relative /usr/bin/kernel-install /usr/sbin/installkernel' and then 'make install' would work without grubby. Right, which is one of the 1/2 dozen things in the sdubby package, and with my limited testing appears to work fine. The vast majority of this work has been done, leaving only two action items, removing grubby from core, and merging a shimming package (sdubby) into the fedora repos. As I wrote before in the bug, what is really grubby and sdubby needed for? Most of what grubby does is arcane archaic stuff that we don't need. With grubby/sdubby we have an additional layer that adds complexity and is very inflexible. Why can't we have Anaconda write the Boot Loader Specification files directly or invoke kernel-install? The critical missing piece of grubby has been the BLS entry manipulation, usually adding or stripping kernel boot parameters. Which at least in fedora, grubby's shell "API" is the defacto way for other programs (ex: kdumpctl) to perform this. That is what is being provided in the sdubby package, outside of symlinks and packaging stuff. So, your right there is a _LOT_ of seemingly redundant stuff in grubby if the system fits into the somewhat narrow set of criteria already required for systemd-boot. AKA basic UEFI secure boot path without 3rd party kernel modules/etc. Maybe a better name would have been bls-entry-tools, since its largely just shimming between bootctl and everything else with sed. It might make sense from a fedora perspective if something like bootctl did this by default, but at least when it comes to output formats/etc its a bit ugly, and I don't really think the grubby "API" as such is being used by anyone outside of the fedora derived distros. So, it makes sense if that functionality exists, that anaconda would use it, rather than attempting an install only version. Hence why this isn't in anaconda. Thanks again, jlinton ___ 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: Changes to build environment
On Thu, Jun 22, 2023 at 7:57 PM Steve Grubb wrote: > > Hello, > > I have switched to F38 and find a couple items annoying. I have a workflow > that > checks things I develop out of github, rolls it up into an rpm, builds it, > and runs the results through annocheck. > > If there is a warning I'd like to investigate, I cd into the build directory. > But oops, now its gone (problem #1). OK, I use rpmbuild -bc to rebuild it. I > cd into the build directory make a change and run make. > > gcc: fatal error: environment variable 'RPM_ARCH' not defined > > (problem #2) > > How do I fix these things? Not sure if these *can* be fixed in general. #1 is a behaviour change of RPM in a recent release, but there's a CLI switch to turn off cleaning up the build directory. In the case of RPM_ARCH, it's because the CFLAGS / LDFLAGS (I think?) build flags set in %build use this environment variable. I think trying to recreate the RPM build environment outside of mock manually (to reproduce issues) is a lost cause though (and you get a different environment than the one that had the issue!) ...It's not perfect, but mock is almost always the best way to build RPMs (i.e. never use "rpmbuild -bb" outside mock), but that's just my opinion ¯\_(ツ)_/¯ Fabio ___ 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: Red Hat Stream ONLY, Orphaning packages
On 21/06/2023 19:33, Jonathan Wright via devel wrote: If you'll add me as admin/owner on the packages I'll continue to maintain them. FAS jonathanspw Especially interested in remmina since I use it nearly every day. Hi Jonathan, If you want help with remmina, you can add me as a co-maintainer. -- Arthur Bols fas/irc: principis ___ 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: Changes to build environment
Dear Steve, I usually use smth like RPM_ARCH=1 RPM_PACKAGE_RELEASE=2 RPM_PACKAGE_VERSION=3 RPM_PACKAGE_NAME=4 make in this situation and have never got any problem yet. On Thu, Jun 22, 2023 at 7:58 PM Steve Grubb wrote: > > Hello, > > I have switched to F38 and find a couple items annoying. I have a workflow > that > checks things I develop out of github, rolls it up into an rpm, builds it, > and runs the results through annocheck. > > If there is a warning I'd like to investigate, I cd into the build directory. > But oops, now its gone (problem #1). OK, I use rpmbuild -bc to rebuild it. I > cd into the build directory make a change and run make. > > gcc: fatal error: environment variable 'RPM_ARCH' not defined > > (problem #2) > > How do I fix these things? > > -Steve > > ___ > 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 -- Dmitry Belyavskiy ___ 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: Orphaning packages
I've taken lynis and python-paramiko. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Thursday, June 22nd, 2023 at 11:48 AM, Othman Madjoudj wrote: > Hello, > Please note that I've orphaned by packages, list in the end of the message. > > Best regards > -Othman > > > rpms/aria2 > rpms/hydra > rpms/libmodsecurity > rpms/lynis > rpms/mod_limitipconn > rpms/mod_qos > rpms/mod_ruid2 > rpms/mod_security3 > rpms/mod_security_crs > rpms/python-paramiko > rpms/thc-ipv6 > rpms/unhide > > signature.asc Description: OpenPGP digital 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
Changes to build environment
Hello, I have switched to F38 and find a couple items annoying. I have a workflow that checks things I develop out of github, rolls it up into an rpm, builds it, and runs the results through annocheck. If there is a warning I'd like to investigate, I cd into the build directory. But oops, now its gone (problem #1). OK, I use rpmbuild -bc to rebuild it. I cd into the build directory make a change and run make. gcc: fatal error: environment variable 'RPM_ARCH' not defined (problem #2) How do I fix these things? -Steve ___ 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: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
On Thu, Jun 22, 2023 at 05:28:41PM +, Zbigniew Jędrzejewski-Szmek wrote: > > It doesn't attempt to create unified kernel images, so the > > existing `dnf update`, `kdumpctl`, and `make install` in a kernel > > source directory should all work. > > Nitpick: 'make install' invokes /usr/bin/installkernel which (sometimes?) > invokes kernel-install which will create a UKI, if the configuration > specifies that. This sentence implies that 'make install' has some > issue with UKIs, but that is not true. > > /usr/bin/installkernel does a lot of stuff, most of it probably wrong. > We could 'ln -sf --relative /usr/bin/kernel-install /usr/sbin/installkernel' > and then 'make install' would work without grubby. https://src.fedoraproject.org/rpms/grubby/pull-request/8 Zbyszek ___ 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: F39 Change Proposal: LibuserDeprecation (System Wide)
On Thursday, June 22, 2023 12:14:28 PM EDT Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/LibuserDeprecation > > > 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 == > > Libuser is not actively developed. Most of the depending component > have build-time option to work without libuser. I'm all for dropping things to reduce attack surface, but the passwd, shadow, group, and gshadow files have not really changed in forever. Just saying... > == Owner == > > * Name: [[User:THalman| Tomas Halman]] > > * Email: > > > == Detailed Description == > > The libuser provides library and command line utilities to manipulate > user and group information. The purpose of the library > is/was to hide the differences between users in LDAP and files in etc > (passwd, groups...). The support for LDAP > is not complete and there is no plan to extend the functionality. > > The LDAP integration in Fedora is nowadays done by SSSD. > > In the past, the libuser was used by more component including Fedora > installer. Currently the list is short > > * usermode (Requires development, it is not complicated but the > dependency is unconditional) > * util-linux (compile time option) > * passwd (I suggest to ship passwd utility from shadow-utils instead > of passwd and drop passwd package as well) passwd has the distinction of being one of the only selinux userspace object managers. Might want to check if we lose anything with that switch. I also have not audited the code in shadow-utils version of passwd where the one we are using now has been audited several times. -Steve > == Feedback == > > > == Benefit to Fedora == > > The main benefit is to decrease the maintenance and packaging work on > library that does not bring much value while the functionality is > provided by another components. > > == Scope == > * Proposal owners: Dropping the package, move it to EPEL eventually > > > * Other developers: > > ** Update usermode code to make libuser dependency configurable. > ** Update usermode packaging to compile it without libuser > ** Change packaging of util-linux to compile without libuser dependency > ** Change packaging of shadow-utils to provide passwd utility > > > * Release engineering: [https://pagure.io/releng/issue/11492] > > Libuser is part of base image and must be removed. IMO mass rebuild is > not required. > > > * Policies and guidelines: Since this is about dropping packages > release notes must be updated. > > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Community Initiatives: N/A > > > == Upgrade/compatibility impact == > > People who used libuser to manipulate users in LDAP will have to move to > SSSD. > == How To Test == > > 0. no special hardware needed > 1. remove libuser, passwd, install new shadow-utils, usermod and > util-linux 2. try to change password of some user > 3. try to modify user using usermod > 4. expected results: everything works normally > > == User Experience == > This change should not be visible for users. > > > > == Dependencies == > > > * usermod (code modification, packaging to drop libuser dependency) > * shadow-utils (packaging to provide passwd utility > * util-linux (packaging to drop libuser dependency) > * passwd (drop package) > > == Contingency Plan == > > * Contingency mechanism: Revert the shipped configuration > * Contingency deadline: final development freeze > * Blocks release? No > > == Documentation == > > There is no extra documentation for this change except release notes. > > == Release Notes == > > > > > > -- > Aoife Moloney > > Product Owner > > Community Platform Engineering Team > > Red Hat EMEA > > Communications House > > Cork Road > > Waterford > ___ > 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/de...@lists.fedoraproject.or > g 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:
Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
> https://fedoraproject.org/wiki/Changes/cleanup_systemd_install > == Detailed Description == > As a first pass, the 'inst.sdboot' option already in anaconda should > work. As it stands, that replaces grub+shim with the systemd-boot > loader, and moves the kernel + initrd to the EFI system partition > (ESP). In general, I think it's great to see this happening. Thank you! > It doesn't attempt to create unified kernel images, so the > existing `dnf update`, `kdumpctl`, and `make install` in a kernel > source directory should all work. Nitpick: 'make install' invokes /usr/bin/installkernel which (sometimes?) invokes kernel-install which will create a UKI, if the configuration specifies that. This sentence implies that 'make install' has some issue with UKIs, but that is not true. /usr/bin/installkernel does a lot of stuff, most of it probably wrong. We could 'ln -sf --relative /usr/bin/kernel-install /usr/sbin/installkernel' and then 'make install' would work without grubby. > The vast majority of this work has > been done, leaving only two action items, removing grubby from core, > and merging a shimming package (sdubby) into the fedora repos. As I wrote before in the bug, what is really grubby and sdubby needed for? Most of what grubby does is arcane archaic stuff that we don't need. With grubby/sdubby we have an additional layer that adds complexity and is very inflexible. Why can't we have Anaconda write the Boot Loader Specification files directly or invoke kernel-install? Zbyszek ___ 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: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
Hi, On 6/22/23 11:21, Daniel P. Berrangé wrote: On Thu, Jun 22, 2023 at 04:59:38PM +0100, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/cleanup_systemd_install 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 == Fedora default installs with a shim + grub bootloader on EFI platforms, yet has been shipping systemd-boot in various forms for a number of releases. There are a few howto's which describe how to replace grub with systemd-boot with varying levels of functionality. This should be easier with a formalized default method that can be built upon. This proposal aims to complete the work started with anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the "everything" media can install a grub free machine. snip Beyond that there are various enhancements which can be made to remove the /boot partition (leaving the EFI at /boot/efi), enrolling fedora keys if the secure boot mode is "Setup", adding options to enable shim+systemd-boot, assuring that there is a systemd-boot-signed package, etc. This is the $million question to - is there any proposal and/or agreement by relevant maintainers, to start signing systemd-boot with Fedora SecureBoot certs yet ? Without that, sdboot looks destined to remain a niche use case. I think there remain a number of open questions, WRT how systemd-boot will settle down. In this case, AFAIK there is an open fedora infra work item for signing it, per zbyszek, who I've put on CC in case he misses this discussion. Of course due to the fact that not every platform has UEFI, and there are features in grub which aren't/shouldn't be duplicated in systemd-boot means that it will never be capable of 100% replacing grub on every platform. If that's part of this proposal, then it feels more like a system-wide change, than self-contained. Well given it only affects a couple packages, and is optional, I flipped a coin and said its not really system wide, but given its in the boot path I do see the argument the other way as well. But, IMHO the largest change is moving the boot kernel/initrd to the ESP, rather than the use of systemd-boot itself. Given the filesystem layout remains the same outside of those two items and the BLS entries, all the common tools (dracut/etc) seem to be able to deal with it, and random other packages not manipulating kernel/initrd images are behavior should not be affected anymore than putting reFind/whatever in the boot path. Thanks, ___ 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: What is Fedora?
On Thu, Jun 22, 2023, at 6:32 PM, Ralf Corsépius wrote: > But is Red Hat still commited to open source and to the freedom of software? > > I feel no and feel cheated and betrayed. Hey Ralf, why do you feel that way? The sources are still available both upstream (CentOS) and downstream (albeit behind a login wall or through your installed RHEL). Regards, Simon ___ 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: Towards enabling rpm sysusers integration
Hello,
On Thursday, June 22, 2023 11:01:28 AM EDT Zbigniew Jędrzejewski-Szmek wrote:
> > 2. systemd provides users and groups that are actually owned by the setup
> > package. As rpm is now turning non-root file ownership into dependencies,
> > systemd could end up pulled in where setup is needed (eg early install
> > stage) which will not end up well. So systemd will need to stop providing
> > users it does not actually own.
>
> I was hoping we would be make the dependency on setup optional.
> It is a fairly heavyweight package (700+ kb) and with lots of
> not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
> csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
> clutters /etc, which ideally would be empty, and also /etc/services is 700
> kb. setup is currently pulled in by dependencies, but e.g. in the initrd
> we should be fine without it. (And the same applies for e.g. minimal
> container images without login users or a shell.)
There are several trusted databases there that things like getservbyport
consult. I would think csh stuff could be installed by tcsh.
> Maybe the non-essential stuff could be split out into a new
> subpackage, with setup only providing /etc/{passwd,group,shadow,gshadow}
> with the base set of users and groups, and all other files moved to
> setup-clutter.
I think a few more files than that are still needed. But it could use some
pruning.
> > 3. The various %sysuser_()* macros in systemd-rpm-macros need to be
> > phased
> > out. As it'll be a long time before the sysusers feature is in all Fedora
> > versions, it needs a longer term plan. One simple possibility is do what
> > was done with all those ldconfig from %post back then: change the
> > %sysusers_() macros to no-ops in rawhide to let rpm handle it, and only
> > actually bother updating packages once all relevant versions have the
> > sysusers feature.
> +1 to this plan.
>
> > 4. The sysusers "hook" in rpm needs to be enabled (uncomment
> > %__systemd_sysusers macro in rpm). It wont do anything at all before 1)
> > and 3) are done though.
> >
> > 6. The user/group dependencies for non-root users need to be turned into
> > hard requires (initially these are just recommends). I would be suprised
> > if this doesn't cause some disruption somewhere, although the content
> > that is not root:root owned is pretty scarce these days.
> >
> > 7. Packages creating or using non-root user/group need to be rebuilt.
> >
> > 7. One day a few years from now, replace
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
> > with "supply a sysusers file for your needs"
> > In reality, it'll need adjusting long before that and for that, it'll
> > need
> > FPC recommendations and all.
> >
> > 8. Remove all user/group addition related macro and script fubar from
> > specs for good. The first commit in rpm source tree is from 1995, it'd
> > be a nice 30 year celebration... but I don't expect it to happen quite
> > that soon. Maybe in 2035 new people will start look at old specs in
> > horror, "What do you mean they had to deal with all this user/group
> > stuff manually! For 30 years!"
> >
> > I've begun from 1) now:
> >
> > https://src.fedoraproject.org/rpms/systemd/pull-request/109
>
> This is merged now and the package is built. (I guess it's probably in
> gating now.)
>
> > https://src.fedoraproject.org/rpms/rpm/pull-request/45
> >
> > After those have been done, people can start experimenting with the
> > feature. I don't remember seeing an actual Fedora Change for either
> > file-trigger enablement or current %sysuser_* macros so I'm not sure
> > it's needed here either?
>
> https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
I would caution against this whole proposal. Not that I'm against it, but
just saying be careful doing it. People often forget about our security
concerns. Currently, shadow-utils has about 400 places which generate audit
events during the managing of system and user accounts. libuser (I saw the
deprecation email) has 55 places where it sends audit events managing
accounts.
There is a 10 year old (or more) standard published here:
https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events
If %pre getent, useradd, and groupadd are being replaced by something, that
something needs to conform to the expected security safeguards that currently
exist. It needs to match the kind of events and the format that currently
exists.
The system accounts still need to be accessible by the getpw* family of
functions or there could be a lot of breakage.
-Steve
___
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
[EPEL-devel] Orphaning packages
Hello, Please note that I've orphaned by packages, list in the end of the message. Best regards -Othman rpms/aria2 rpms/hydra rpms/libmodsecurity rpms/lynis rpms/mod_limitipconn rpms/mod_qos rpms/mod_ruid2 rpms/mod_security3 rpms/mod_security_crs rpms/python-paramiko rpms/thc-ipv6 rpms/unhide ___ 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
Orphaning packages
Hello, Please note that I've orphaned by packages, list in the end of the message. Best regards -Othman rpms/aria2 rpms/hydra rpms/libmodsecurity rpms/lynis rpms/mod_limitipconn rpms/mod_qos rpms/mod_ruid2 rpms/mod_security3 rpms/mod_security_crs rpms/python-paramiko rpms/thc-ipv6 rpms/unhide ___ 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
F39 Change Proposal: ibus-anthy 1.5.15 (self contained)
https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.15 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 == In ibus-anthy 1.5.15, the icon tag will be added to the metainfo, the Japanese era is updated for 2023, the candidate window is enhanced for OSK(On-Screen Keyboard). == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * ibus-anthy already has the icon but it wasn't indicated in the metainfo. Also screenshots and keywords are updated. * ibus-anthy will convert the Japanese era and "2023" mutually * ibus-anthy determines a clicked item on the candidate window but also will commit the clicked item on the candidate window in case of enabling the OSK(On-Screen Keyboard) mode in GNOME Wayland. == Feedback == == Benefit to Fedora == The metainfo data is updated within the ibus-anthy package, Japanese era is updated in a ibus-anthy dictionary file, the OSK mode is available only if the OSK is enabled and ibus-anthy switches the candidate mode. == Scope == * Proposal owners: ibus-anthy * 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 == == How To Test == 1. Enable ibus-anthy 2. Run gnome-text-editor 3. Type "２０２３" or "れいわ５" and space keys 4. The Japanese era and 2023 is converted mutually 1. Enable OSK and ibus-anthy 2. Run gnome-text-editor 3. Click "a" and space x 2 keys in OSK and show the candidate window 4. Click a candidate string on the candidate window 5. The selected candidate string is committed in gnome-text-editor == User Experience == The metainfo data is relative with gnome-software and I hope the ibus-anthy section will be updated. Japanese era has been rarely used in Japanese documents and the ibus-anthy conversion will be useful. The OSK usability will be enhanced with the mouse. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the change to ibus-anthy. * Contingency deadline: Beta release * Blocks release? No == Documentation == N/A == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-annou...@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-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
F39 Change Proposal: ibus-anthy 1.5.15 (self contained)
https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.15 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 == In ibus-anthy 1.5.15, the icon tag will be added to the metainfo, the Japanese era is updated for 2023, the candidate window is enhanced for OSK(On-Screen Keyboard). == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * ibus-anthy already has the icon but it wasn't indicated in the metainfo. Also screenshots and keywords are updated. * ibus-anthy will convert the Japanese era and "2023" mutually * ibus-anthy determines a clicked item on the candidate window but also will commit the clicked item on the candidate window in case of enabling the OSK(On-Screen Keyboard) mode in GNOME Wayland. == Feedback == == Benefit to Fedora == The metainfo data is updated within the ibus-anthy package, Japanese era is updated in a ibus-anthy dictionary file, the OSK mode is available only if the OSK is enabled and ibus-anthy switches the candidate mode. == Scope == * Proposal owners: ibus-anthy * 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 == == How To Test == 1. Enable ibus-anthy 2. Run gnome-text-editor 3. Type "２０２３" or "れいわ５" and space keys 4. The Japanese era and 2023 is converted mutually 1. Enable OSK and ibus-anthy 2. Run gnome-text-editor 3. Click "a" and space x 2 keys in OSK and show the candidate window 4. Click a candidate string on the candidate window 5. The selected candidate string is committed in gnome-text-editor == User Experience == The metainfo data is relative with gnome-software and I hope the ibus-anthy section will be updated. Japanese era has been rarely used in Japanese documents and the ibus-anthy conversion will be useful. The OSK usability will be enhanced with the mouse. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the change to ibus-anthy. * Contingency deadline: Beta release * Blocks release? No == Documentation == N/A == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
Re: What is Fedora?
Am 22.06.23 um 16:08 schrieb Stephen Gallagher: On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen wrote: On Wed, 21 Jun 2023 21:06:40 +0100, you wrote: Hi all, Obviously many will have seen: https://www.redhat.com/en/blog/furthering-evolution-centos-stream and see, where EL (contributors like you of fedora/EPEL) have been knocked down: https://bugzilla.redhat.com/show_bug.cgi?id=2215299 Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat? My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL. Just to interject, this is an incorrect interpretation. But is Red Hat still commited to open source and to the freedom of software? I feel no and feel cheated and betrayed. Ralf ___ 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
F39 Change Proposal: Sericea and Sway Spin Xorg-less (Self Contained)
https://fedoraproject.org/wiki/Changes/sericea-xorgless 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 == At the moment Sericea and Sway Spin ship with xorg-x11 packages. This proposal aims to remove xorg-x11 packages from such artifacts. == Owner == * Name: [[User:alebastr| Aleksei Bavshin]], [[User:Fale|Fabio Alessandro Locati]], Sway SIG ** Primary contact person: Fabio Alessandro Locati * Email: f...@fedoraproject.org == Detailed Description == At the moment Sericea and Sway Spin require the installation of xorg-x11 due to the use of `sddm-x11`. When we started working on F38 we were not fully convinced on the stability of SDDM-Wayland, so we opted for the safer bet: SDDM-X11. Though, since Sway is Wayland-only, it would make sense for Sericea and Sway Spin to prefer the use of `sddm-wayland-sway`. == Feedback == So far only positive feedback have been provided on this idea. == Benefit to Fedora == This change will allow Sericea and Sway Spin artifacts to ship without xorg-x11. == Scope == * Proposal owners: change the default in comps * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == When the users will update their Fedora installation, the change will occur in their boxes automatically. No direct impact nor configuration change is required. == How To Test == # Install `sddm-wayland-sway` # Reboot and test the login == User Experience == `sddm-wayland-sway` should have a slightly positive experience for users, with less bugs in some edge cases than `sddm-x11`. Majority of users should not be able to notice the difference. == Dependencies == N/A == Contingency Plan == If unexpected issues will be created by this change, we can easily rollback to `sddm-x11` by changing back the comps packages. * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
F39 Change Proposal: Retire Modularity (Self Contained)
https://fedoraproject.org/wiki/Changes/RetireModularity 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 == Fedora will discontinue building [https://docs.fedoraproject.org/en-US/modularity/ modules] for Fedora Linux 39 and further in the Fedora infrastructure and shipping modular content to users. The fedora-repos-modular and fedora-repos-rawhide-modular packages will be retired and obsoleted. The modular repositories will no longer be composed. Once Fedora Linux 38 reaches the end of life, Fedora's [https://mbs.fedoraproject.org/ Module Build Service] will be terminated. Whether or not dnf(5) would still support modularity from 3rd party repository is out of the scope of this proposal. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Name: [[User:Mcurlej|Martin Čurlej]] * Name: [[User:Ppisar|Petr Písař]] * Email: mhron...@redhat.com, mcur...@redhat.com, ppi...@redhat.com == Detailed Description == === Motivation === There are very few modules left in Fedora, nobody is developing modularity anymore and there is an everlasting infrastructure problem with building modules. Similarly to retiring a package that has no maintainers, we are retiring Modularity from Fedora, because it has no maintainers. The latest noticeable activity in [https://pagure.io/modularity pagure.io/modularity] was 3+ years ago. === What will happen === # After Fedora Linux 38 branches from Rawhide, we will disable building modules for Rawhide and future Fedora Linux 39 and later. # We will work with Release Engineering to disable composing of modular repositories, F39 Modular updates in Bodhi etc. # The fedora-repos-modular and fedora-repos-rawhide-modular subpackages of fedora-repos will be removed and obsoleted by fedora-repos and fedora-repos-rawhide. # Once Fedora Linux 38 reaches end of life, we will retire the Fedora instance of [https://mbs.fedoraproject.org/ Module Build Service]. === What might or might not happen === Whether or not the package manager in Fedora Linux (dnf and/or dnf5) will support modular repositories created by 3rd parties is not decided in this change proposal. It is up to the dnf maintainers to make this decision and we intentionally want to make the scope of this proposal as limited as possible. === For maintainers of modules === Please retire your modules appropriately, so users are migrated to suitable non-modular content. If you wish to continue shipping multiple different versions or editions of your packages, please follow [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple '''Multiple packages with the same base name'''], as was [https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_for_modules_in_fedora a recommendation of the policy for many years]. == Feedback == === What will be offered as a replacement === We have been asked internally at Red Hat, what will be offered to users of Fedora Linux if we retire modularity. While we encourage anyone to share ideas they might have on the topic, we intentionally offer no ''new'' alternative to modularity as part of this change proposal. Replacing the retired modularity with something else is intentionally out of scope of this proposal. == Benefit to Fedora == Packager and Infra/Releng resources will not be wasted on Modularity. Instead, we can focus on delivering quality content to our users without it. == Scope == * Proposal owners: ** Work with releng to disable modular builds in f39+ ** Work with releng to disable composing and mirroring of modular repos for f39+ ** Work with Bodhi admins to disable F39+ Modular updates ** Submit changes to fedora-repos package to remove and obsolete the modular subpackages ** (once f38 is EOL) Work with infra to sunset MBS * Other developers: ** Modular packagers: *** Retire your modules *** Ideally package the content as nonmodular * Release engineering: [https://pagure.io/releng/issue/11480 #11480] ** Disable modular builds in f39+ ** Disable composing and mirroring of modular repos for f39+ * 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 == An RPM scriptlet fedora-release might be necessary to deactivate all Fedora-provided modular streams when upgrading to Fedora Linux 39 and 40. This will only happen if all other means of properly EOLing the modules still block upgrades. == How To Test == === Has this landed? === # Check if fedora-repos-modular and fedora-repos-rawhide-modular are missing from the repository and Obsoleted. # Check if the modular repositories are missing from download.fedoraproject.org and mirrormanager. === Does it work? === # Check if upgrading from Fedora
F39 Change Proposal: Further reduce Fedora-specific build flags in non-RPM Python extensions (Self Contained)
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
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 ==
Continuing the work started with
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags, this
change is about further reducing the build and linker flags (CFLAGS
and LDFLAGS) saved internally in the Python interpreter for use by
distutils and other build systems. Compiling non-RPM Python extension
modules will carry only the compiler flags required for binary
compatibility with the interpreter they were built against and not
Fedora specific ones.
Practically that means the only Fedora derived flag will be
-fexceptions and Python will apply its own upstream
hardcoded ones, making the final flag set for a non-RPM compiled
Python extension as follows:
* -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG
-fexceptions
Python C extensions built as rpm's will '''not''' be affected.
The current main Python interpreter on Fedora 39 will be modified
(Python 3.12) and Python 3.6-3.11 will follow.
This change will affect every package that provides support for
extension builders via utilizing the %{extension...flags}
macros which at the time being is only Python.
== Owner ==
* Name: [[User:cstratak| Charalampos Stratakis]]
* Email: python-maint AT redhat.com
== Detailed Description ==
After implementing
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags we
uncoupled some distro specific compilation and linker flags propagated
to C extensions.
However with an ever increasing set of compiler flags being added and
applied distro-wide, as compilers and security standards evolve (e.g.
-D_FORTIFY_SOURCE=3) it becomes an increasingly complex job to vet
each flag that might leak into user-built Python C extensions through
the Python interpreter. Instead of removing only some flags and
letting the rest follow through, we will be taking a more proactive
approach by removing all the compiler and linker flags, except the
ones that are required to maintain the binary compatibility with the
Python interpreter the extensions were built against which is
-fexceptions. We will also preserve the ones that Python
hardcodes itself through the Makefile.
Similarly, when a user builds their own C programs, no compiler flags
are applied by default and the user is free to making their own
decision. Bringing the compilation of Python C extensions closer to
that experience is the next logical step.
Currently a user-built Python C extension will be built with:
CFLAGS:
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2
-fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv
LDFLAGS:
'-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g'
After this change:
CFLAGS:
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions
-fexceptions -fexceptions
LDFLAGS:
None
== Feedback ==
The initial thread that inspired this change was
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/76RV7VLCOZRHIMTG4J3M4NMIBAD4LO76/#76RV7VLCOZRHIMTG4J3M4NMIBAD4LO76
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C
programs. Also new decisions made about the distro-wide compiler flags
won't necessarily affect Python developers building their extension
modules.
In addition any Python developer using Fedora will have the capability
to build the extension on Fedora, test it and later ship it and build
it on a CI or other systems that are not based on Fedora.
== Scope ==
* Proposal owners: Review, merge and build the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/252
redhat-rpm-config PR] and the apply the relevant changes in the Python
interpreters ([https://src.fedoraproject.org/rpms/python3.11/pull-request/111
example from
F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
https://fedoraproject.org/wiki/Changes/NoCustomQtThemingForWorkstation This is a proposed Change for Fedora Linux. 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 == Fedora Workstation has been using [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] and [https://github.com/FedoraQt/adwaita-qt Adwaita-qt] projects to apply GNOME-like configuration and styling to Qt applications to match the environment. These projects are now in a state where they are outdated and semi-occasionally broken for some applications and it would be better to default to what Qt upstream has to offer. == Owner == * Name: [[User:jgrulich| Jan Grulich]] * Email: jgrul...@redhat.com == Detailed Description == [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is a Qt Platform Theme plugin. It reads GNOME configuration, like fonts or icons and applies this configuration to Qt applications. It also provides implementation of Client-Side Window Decorations or native dialogs. This project partially overlaps with Qt's default GTK Platform Theme plugin, but there are some additions that are existing only in QGnomePlatform, like Client-Side Window Decorations. [https://github.com/FedoraQt/adwaita-qt Adwaita-qt] project is a Qt Style plugin. It implements widget styling (e.g. buttons, checkboxes) to match GNOME's Adwaita style. There is no equivalent of such style in Qt, but given the complexity of Qt Style plugins, this project is now outdated and doesn't match the current Adwaita (GTK4) style. It is also responsible for the most of the issues users are facing while using our custom styling. Some additional information about these projects and issues: * [https://jgrulich.cz/2023/03/08/explained-qgnomeplatform-and-adwaita-qt/ Detailed explanation of QGnomePlatform and Adwaita-qt] * [https://theevilskeleton.gitlab.io/2022/12/06/where-fedora-linux-could-improve.html#adwaita-qt Adwaita-qt issues on examples] * [https://pagure.io/fedora-workstation/issue/351 Fedora Workstation bug to reconsider use of Adwaita-qt] With this change we would like to stop shipping and using these projects by default on Fedora Workstation and default to Qt default theming and styling. Also, because the GTK Platform Theme in Qt doesn't support everything we have support for in QGnomePlatform, we would like to contribute it to Qt instead. With this work, there shouldn't be any drawbacks when using Qt's GTK Platform Theme and we believe we would even get broader usage and more contributors for things like Client-Side Window Decorations. For Adwaita-qt replacement, we would default to [https://doc.qt.io/qt-6/qtquickcontrols-fusion.html Fusion] style or possibly to Breeze style for KDE apps. Both styles have benefit of active upstream and broader usage than our custom style that is only used by Fedora Workstation and not tested by developers. == Feedback == == Benefit to Fedora == We will be using more reliable and tested Qt theming/styling instead of our custom solution, which is only used by Fedora Workstation. This brings us closer to upstream with benefit of upstream support for theming and styling issues. This will also eliminate all the issues our users have been experiencing in the past when using Qt applications with Adwaita-qt style on Fedora Workstation. == Scope == * Proposal owners: # Drop QGnomePlatform and Adwaita-qt from Fedora Workstation compose. # Drop our custom patches making Qt to use QGnomePlatform by default. # Upstream some of the QGnomePlatform features to Qt upstream and backport them to Fedora packages (until released upstream). * Other developers: [OPTIONAL] Packagers blacklisting either QGnomePlatform or Adwaita-qt in their packages can stop doing that. * 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 == We will make QGnomePlatform to not be used by default even when installed. Users will still be able to use it by using a Qt env variable or passing an option specifying what platform theme should be used. For this reason there shouldn't be any extra work needed to be done by the users who upgraded to Fedora 39. == User Experience == The user experience should remain the same or be actually better in case Qt apps they were using were not working properly with QGnomePlatform or Adwaita-qt. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System
F39 Change Proposal: LibuserDeprecation (System Wide)
https://fedoraproject.org/wiki/Changes/LibuserDeprecation 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 == Libuser is not actively developed. Most of the depending component have build-time option to work without libuser. == Owner == * Name: [[User:THalman| Tomas Halman]] * Email: == Detailed Description == The libuser provides library and command line utilities to manipulate user and group information. The purpose of the library is/was to hide the differences between users in LDAP and files in etc (passwd, groups...). The support for LDAP is not complete and there is no plan to extend the functionality. The LDAP integration in Fedora is nowadays done by SSSD. In the past, the libuser was used by more component including Fedora installer. Currently the list is short * usermode (Requires development, it is not complicated but the dependency is unconditional) * util-linux (compile time option) * passwd (I suggest to ship passwd utility from shadow-utils instead of passwd and drop passwd package as well) == Feedback == == Benefit to Fedora == The main benefit is to decrease the maintenance and packaging work on library that does not bring much value while the functionality is provided by another components. == Scope == * Proposal owners: Dropping the package, move it to EPEL eventually * Other developers: ** Update usermode code to make libuser dependency configurable. ** Update usermode packaging to compile it without libuser ** Change packaging of util-linux to compile without libuser dependency ** Change packaging of shadow-utils to provide passwd utility * Release engineering: [https://pagure.io/releng/issue/11492] Libuser is part of base image and must be removed. IMO mass rebuild is not required. * Policies and guidelines: Since this is about dropping packages release notes must be updated. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == People who used libuser to manipulate users in LDAP will have to move to SSSD. == How To Test == 0. no special hardware needed 1. remove libuser, passwd, install new shadow-utils, usermod and util-linux 2. try to change password of some user 3. try to modify user using usermod 4. expected results: everything works normally == User Experience == This change should not be visible for users. == Dependencies == * usermod (code modification, packaging to drop libuser dependency) * shadow-utils (packaging to provide passwd utility * util-linux (packaging to drop libuser dependency) * passwd (drop package) == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: final development freeze * Blocks release? No == Documentation == There is no extra documentation for this change except release notes. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
F39 Change Proposal: Golang1.21 (System-Wide)
https://fedoraproject.org/wiki/Changes/golang1.21
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora 39.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora
39. Go 1.21 is expected to be released in August 2023. A mass rebuild
of all of the dependent packages is required.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features.
Therefore Fedora will be providing a reliable development platform for
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.21
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 39, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: It doesn't align directly with
the current objectives but it helps maintain the quality of the
project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.21 from rawhide and use it to build your
application(s)/package(s).
# Scratch build against rawhide.
# Your application/package built using golang 1.21 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed: ~2000.
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.20.X if significant issues are
discovered
* Contingency deadline: Beta freeze
== Documentation ==
https://tip.golang.org/doc/go1.21
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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
F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
https://fedoraproject.org/wiki/Changes/cleanup_systemd_install 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 == Fedora default installs with a shim + grub bootloader on EFI platforms, yet has been shipping systemd-boot in various forms for a number of releases. There are a few howto's which describe how to replace grub with systemd-boot with varying levels of functionality. This should be easier with a formalized default method that can be built upon. This proposal aims to complete the work started with anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the "everything" media can install a grub free machine. == Owner == * Name: [[User:jlinton| Jeremy Linton]] * Email: * Name: Possibly others since it may touch -comps, systemd-boot, etc == Detailed Description == As a first pass, the 'inst.sdboot' option already in anaconda should work. As it stands, that replaces grub+shim with the systemd-boot loader, and moves the kernel + initrd to the EFI system partition (ESP). It doesn't attempt to create unified kernel images, so the existing `dnf update`, `kdumpctl`, and `make install` in a kernel source directory should all work. The vast majority of this work has been done, leaving only two action items, removing grubby from core, and merging a shimming package (sdubby) into the fedora repos. Beyond that there are various enhancements which can be made to remove the /boot partition (leaving the EFI at /boot/efi), enrolling fedora keys if the secure boot mode is "Setup", adding options to enable shim+systemd-boot, assuring that there is a systemd-boot-signed package, etc. The advantages of just enabling the systemd-boot loader without UKIs or restructuring the /boot and /boot/efi mount points result in a wider range of supported machines and a more familiar environment for users and applications. AKA, by not changing the HostOnly/initrd build process the vast majority of UEFI machines are supported. To be clear the intention isn't to replace grub, but to co-exist alongside as an alternative bootloader. == Feedback == == Benefit to Fedora == Fedora is considered a forward looking distro. As systemd-boot and UKIs gain traction it should be straightforward for users/testers to try out this option in their own environments with a well defined configuration. Potentially in the future, once secure boot/etc is straightened out the simpler/cleaner code base may prove to be more secure, or a consistent set of measured boot PCRs may enable a simpler (for the end user) encrypted storage environment. == Scope == * Proposal owners: At the moment two things remain open: https://pagure.io/fedora-comps/pull-request/838 and: https://bugzilla.redhat.com/show_bug.cgi?id=2134972 Both of which are largely in the "needs more discussion" state, but otherwise are complete as they stand. There is also an open kexec-tools + aarch64 zboot set that needs to be merged in order to support kdump properly on aarch64 platforms, although that problem is caused by zboot and affects grub as well. Zboot is required for systemd-boot at the moment. * Other developers: Depending on the results of the discussion above: Its possible the systemd maintainers, kdumpctl, etc may need changes. * 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 == Ideally nothing as we aren't deprecating or changing the shim + grub boot paths. == How To Test == # Have a VM or non critical test machine that can be reinstalled at will. # Assure secure boot is disabled or in setup mode. # Pass `inst.sdboot` on the kernel/grub command line presented on the install media and install as normal. ## possibly adding additional space to the EFI system partition during partitioning to guarantee there is sufficient space for the number of bootable kernels active on the machine (~100MB each should be more than sufficient) ## Alternatively `--sdboot` can be added to the bootloader command in kickstarts, and the partitions/etc adjusted there # Use the machine as normal. # Report issues during upgrades, or with any packages that can't find kernel images. Everything besides the loader entries, kernel image, and generated initrds should remain in /boot. == User Experience == Ideally, after the initial install the fedora experience should generally remain the same. There may be slight differences in boot timings (at least on aarch64 possibly slightly faster) and the bootctl utility may have more information and work properly. == Dependencies == Systemd-boot, described in the comps and sdubby review. == Contingency
F39 Change Proposal: Sericea and Sway Spin Xorg-less (Self Contained)
https://fedoraproject.org/wiki/Changes/sericea-xorgless 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 == At the moment Sericea and Sway Spin ship with xorg-x11 packages. This proposal aims to remove xorg-x11 packages from such artifacts. == Owner == * Name: [[User:alebastr| Aleksei Bavshin]], [[User:Fale|Fabio Alessandro Locati]], Sway SIG ** Primary contact person: Fabio Alessandro Locati * Email: f...@fedoraproject.org == Detailed Description == At the moment Sericea and Sway Spin require the installation of xorg-x11 due to the use of `sddm-x11`. When we started working on F38 we were not fully convinced on the stability of SDDM-Wayland, so we opted for the safer bet: SDDM-X11. Though, since Sway is Wayland-only, it would make sense for Sericea and Sway Spin to prefer the use of `sddm-wayland-sway`. == Feedback == So far only positive feedback have been provided on this idea. == Benefit to Fedora == This change will allow Sericea and Sway Spin artifacts to ship without xorg-x11. == Scope == * Proposal owners: change the default in comps * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == When the users will update their Fedora installation, the change will occur in their boxes automatically. No direct impact nor configuration change is required. == How To Test == # Install `sddm-wayland-sway` # Reboot and test the login == User Experience == `sddm-wayland-sway` should have a slightly positive experience for users, with less bugs in some edge cases than `sddm-x11`. Majority of users should not be able to notice the difference. == Dependencies == N/A == Contingency Plan == If unexpected issues will be created by this change, we can easily rollback to `sddm-x11` by changing back the comps packages. * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: Fedora ELN Plans for Summer 2023
On Fri, Jun 16, 2023 at 6:42 AM Stephen Gallagher wrote: > == Open Questions == > 1) For the "canary" Fedora ELN rebuild, we have two choices on how to > select the git hash to be built for each package in the ELN list: > > Approach 1 (Rawhide-style): > 1. Clone each package > 2. Check for the existence of the `eln` branch. > a. If the `eln` branch exists, build from the HEAD of that branch > into the side-tag. > b. Otherwise, build from the HEAD of the `rawhide` branch into the > side-tag. > > Approach 2 (Conservative-style): > 1. Query Koji for the latest-tagged build of each package in Fedora ELN > 2. Interrogate the build task of that build for the git hash > 3. Build that git hash into the side-tag. > > Approach 2 is more heavyweight, relying on a lot of Koji queries > back-and-forth, whereas Approach 1 will pick up changes that have > appeared in Rawhide since the last build (which is more in line with > how Fedora's mass-rebuilds work). I'm personally leaning towards > Approach 2, but I'm open to good arguments either way. > Sorry for being late with this, but I thought I'd already sent this. I'd like to go with Approach 2 (Conservative-style) I've got a python script that grabs the githash for various builds. Although the initial run takes a couple of hours, after that it's fairly quick. It would make it possible to build using the ELN build source githash. In the long run, I believe it takes less time to get the githash rather than pulling down the git repos. It's also something the can be pre-staged, then just run the script right before you run the mass rebuild, to get the latest. Troy ___ 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
F39 Change Proposal: Retire Modularity (Self Contained)
https://fedoraproject.org/wiki/Changes/RetireModularity 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 == Fedora will discontinue building [https://docs.fedoraproject.org/en-US/modularity/ modules] for Fedora Linux 39 and further in the Fedora infrastructure and shipping modular content to users. The fedora-repos-modular and fedora-repos-rawhide-modular packages will be retired and obsoleted. The modular repositories will no longer be composed. Once Fedora Linux 38 reaches the end of life, Fedora's [https://mbs.fedoraproject.org/ Module Build Service] will be terminated. Whether or not dnf(5) would still support modularity from 3rd party repository is out of the scope of this proposal. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Name: [[User:Mcurlej|Martin Čurlej]] * Name: [[User:Ppisar|Petr Písař]] * Email: mhron...@redhat.com, mcur...@redhat.com, ppi...@redhat.com == Detailed Description == === Motivation === There are very few modules left in Fedora, nobody is developing modularity anymore and there is an everlasting infrastructure problem with building modules. Similarly to retiring a package that has no maintainers, we are retiring Modularity from Fedora, because it has no maintainers. The latest noticeable activity in [https://pagure.io/modularity pagure.io/modularity] was 3+ years ago. === What will happen === # After Fedora Linux 38 branches from Rawhide, we will disable building modules for Rawhide and future Fedora Linux 39 and later. # We will work with Release Engineering to disable composing of modular repositories, F39 Modular updates in Bodhi etc. # The fedora-repos-modular and fedora-repos-rawhide-modular subpackages of fedora-repos will be removed and obsoleted by fedora-repos and fedora-repos-rawhide. # Once Fedora Linux 38 reaches end of life, we will retire the Fedora instance of [https://mbs.fedoraproject.org/ Module Build Service]. === What might or might not happen === Whether or not the package manager in Fedora Linux (dnf and/or dnf5) will support modular repositories created by 3rd parties is not decided in this change proposal. It is up to the dnf maintainers to make this decision and we intentionally want to make the scope of this proposal as limited as possible. === For maintainers of modules === Please retire your modules appropriately, so users are migrated to suitable non-modular content. If you wish to continue shipping multiple different versions or editions of your packages, please follow [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple '''Multiple packages with the same base name'''], as was [https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_for_modules_in_fedora a recommendation of the policy for many years]. == Feedback == === What will be offered as a replacement === We have been asked internally at Red Hat, what will be offered to users of Fedora Linux if we retire modularity. While we encourage anyone to share ideas they might have on the topic, we intentionally offer no ''new'' alternative to modularity as part of this change proposal. Replacing the retired modularity with something else is intentionally out of scope of this proposal. == Benefit to Fedora == Packager and Infra/Releng resources will not be wasted on Modularity. Instead, we can focus on delivering quality content to our users without it. == Scope == * Proposal owners: ** Work with releng to disable modular builds in f39+ ** Work with releng to disable composing and mirroring of modular repos for f39+ ** Work with Bodhi admins to disable F39+ Modular updates ** Submit changes to fedora-repos package to remove and obsolete the modular subpackages ** (once f38 is EOL) Work with infra to sunset MBS * Other developers: ** Modular packagers: *** Retire your modules *** Ideally package the content as nonmodular * Release engineering: [https://pagure.io/releng/issue/11480 #11480] ** Disable modular builds in f39+ ** Disable composing and mirroring of modular repos for f39+ * 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 == An RPM scriptlet fedora-release might be necessary to deactivate all Fedora-provided modular streams when upgrading to Fedora Linux 39 and 40. This will only happen if all other means of properly EOLing the modules still block upgrades. == How To Test == === Has this landed? === # Check if fedora-repos-modular and fedora-repos-rawhide-modular are missing from the repository and Obsoleted. # Check if the modular repositories are missing from download.fedoraproject.org and mirrormanager. === Does it work? === # Check if upgrading from Fedora
PSA: Rawhide - what to do if switch to dnf5 fails because dnf is protected
I've heard a couple of folks report that they tried updating a Rawhide system or container and it failed with: Problem: The operation would result in removing the following protected packages: dnf The problem seems to be caused by doing the upgrade with an older dnf installed. dnf-4.15.1-1.fc39 was tagged into Rawhide on May 18th, and it dropped the protection of dnf (and yum). So there was a month or so where the 'current' dnf package you got on Rawhide update dropped the protection of dnf itself, and if you updated to that version before the dnf5-by-default update arrived this week, your upgrade to dnf5 should go fine. However, if you *didn't* update your system to dnf-4.15.1-1.fc39, you'll encounter this problem when you try to update now, because the older dnf build you have installed still considers itself protected. You have a couple of options if you're stuck in this situation: either update to 4.15.1 first (by grabbing the packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=2202454 and updating them), or rename or edit the file /etc/dnf/protected.d/dnf.conf so dnf is no longer protected. After doing that, the upgrade should work correctly. It's also been reported that using the pre-switchover dnf5 to do the switchover upgrade (the one that makes dnf5 the default and removes dnf) may not work. If it doesn't, then just use dnf to run that upgrade instead. Sorry for any trouble caused by this! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
On Thu, Jun 22, 2023 at 04:59:38PM +0100, Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/cleanup_systemd_install > > 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 == > Fedora default installs with a shim + grub bootloader on EFI > platforms, yet has been shipping systemd-boot in various forms for a > number of releases. There are a few howto's which describe how to > replace grub with systemd-boot with varying levels of functionality. > This should be easier with a formalized default method that can be > built upon. This proposal aims to complete the work started with > anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the > "everything" media can install a grub free machine. snip > Beyond that there are various enhancements which can be made to remove > the /boot partition (leaving the EFI at /boot/efi), enrolling fedora > keys if the secure boot mode is "Setup", adding options to enable > shim+systemd-boot, assuring that there is a systemd-boot-signed > package, etc. This is the $million question to - is there any proposal and/or agreement by relevant maintainers, to start signing systemd-boot with Fedora SecureBoot certs yet ? Without that, sdboot looks destined to remain a niche use case. If that's part of this proposal, then it feels more like a system-wide change, than self-contained. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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
F39 Change Proposal: Further reduce Fedora-specific build flags in non-RPM Python extensions (Self Contained)
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
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 ==
Continuing the work started with
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags, this
change is about further reducing the build and linker flags (CFLAGS
and LDFLAGS) saved internally in the Python interpreter for use by
distutils and other build systems. Compiling non-RPM Python extension
modules will carry only the compiler flags required for binary
compatibility with the interpreter they were built against and not
Fedora specific ones.
Practically that means the only Fedora derived flag will be
-fexceptions and Python will apply its own upstream
hardcoded ones, making the final flag set for a non-RPM compiled
Python extension as follows:
* -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG
-fexceptions
Python C extensions built as rpm's will '''not''' be affected.
The current main Python interpreter on Fedora 39 will be modified
(Python 3.12) and Python 3.6-3.11 will follow.
This change will affect every package that provides support for
extension builders via utilizing the %{extension...flags}
macros which at the time being is only Python.
== Owner ==
* Name: [[User:cstratak| Charalampos Stratakis]]
* Email: python-maint AT redhat.com
== Detailed Description ==
After implementing
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags we
uncoupled some distro specific compilation and linker flags propagated
to C extensions.
However with an ever increasing set of compiler flags being added and
applied distro-wide, as compilers and security standards evolve (e.g.
-D_FORTIFY_SOURCE=3) it becomes an increasingly complex job to vet
each flag that might leak into user-built Python C extensions through
the Python interpreter. Instead of removing only some flags and
letting the rest follow through, we will be taking a more proactive
approach by removing all the compiler and linker flags, except the
ones that are required to maintain the binary compatibility with the
Python interpreter the extensions were built against which is
-fexceptions. We will also preserve the ones that Python
hardcodes itself through the Makefile.
Similarly, when a user builds their own C programs, no compiler flags
are applied by default and the user is free to making their own
decision. Bringing the compilation of Python C extensions closer to
that experience is the next logical step.
Currently a user-built Python C extension will be built with:
CFLAGS:
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2
-fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv
LDFLAGS:
'-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g'
After this change:
CFLAGS:
-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions
-fexceptions -fexceptions
LDFLAGS:
None
== Feedback ==
The initial thread that inspired this change was
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/76RV7VLCOZRHIMTG4J3M4NMIBAD4LO76/#76RV7VLCOZRHIMTG4J3M4NMIBAD4LO76
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C
programs. Also new decisions made about the distro-wide compiler flags
won't necessarily affect Python developers building their extension
modules.
In addition any Python developer using Fedora will have the capability
to build the extension on Fedora, test it and later ship it and build
it on a CI or other systems that are not based on Fedora.
== Scope ==
* Proposal owners: Review, merge and build the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/252
redhat-rpm-config PR] and the apply the relevant changes in the Python
interpreters ([https://src.fedoraproject.org/rpms/python3.11/pull-request/111
example from
F39 Change Proposal: No custom Qt theming for Fedora Workstation (Self Contained)
https://fedoraproject.org/wiki/Changes/NoCustomQtThemingForWorkstation This is a proposed Change for Fedora Linux. 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 == Fedora Workstation has been using [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] and [https://github.com/FedoraQt/adwaita-qt Adwaita-qt] projects to apply GNOME-like configuration and styling to Qt applications to match the environment. These projects are now in a state where they are outdated and semi-occasionally broken for some applications and it would be better to default to what Qt upstream has to offer. == Owner == * Name: [[User:jgrulich| Jan Grulich]] * Email: jgrul...@redhat.com == Detailed Description == [https://github.com/FedoraQt/QGnomePlatform QGnomePlatform] project is a Qt Platform Theme plugin. It reads GNOME configuration, like fonts or icons and applies this configuration to Qt applications. It also provides implementation of Client-Side Window Decorations or native dialogs. This project partially overlaps with Qt's default GTK Platform Theme plugin, but there are some additions that are existing only in QGnomePlatform, like Client-Side Window Decorations. [https://github.com/FedoraQt/adwaita-qt Adwaita-qt] project is a Qt Style plugin. It implements widget styling (e.g. buttons, checkboxes) to match GNOME's Adwaita style. There is no equivalent of such style in Qt, but given the complexity of Qt Style plugins, this project is now outdated and doesn't match the current Adwaita (GTK4) style. It is also responsible for the most of the issues users are facing while using our custom styling. Some additional information about these projects and issues: * [https://jgrulich.cz/2023/03/08/explained-qgnomeplatform-and-adwaita-qt/ Detailed explanation of QGnomePlatform and Adwaita-qt] * [https://theevilskeleton.gitlab.io/2022/12/06/where-fedora-linux-could-improve.html#adwaita-qt Adwaita-qt issues on examples] * [https://pagure.io/fedora-workstation/issue/351 Fedora Workstation bug to reconsider use of Adwaita-qt] With this change we would like to stop shipping and using these projects by default on Fedora Workstation and default to Qt default theming and styling. Also, because the GTK Platform Theme in Qt doesn't support everything we have support for in QGnomePlatform, we would like to contribute it to Qt instead. With this work, there shouldn't be any drawbacks when using Qt's GTK Platform Theme and we believe we would even get broader usage and more contributors for things like Client-Side Window Decorations. For Adwaita-qt replacement, we would default to [https://doc.qt.io/qt-6/qtquickcontrols-fusion.html Fusion] style or possibly to Breeze style for KDE apps. Both styles have benefit of active upstream and broader usage than our custom style that is only used by Fedora Workstation and not tested by developers. == Feedback == == Benefit to Fedora == We will be using more reliable and tested Qt theming/styling instead of our custom solution, which is only used by Fedora Workstation. This brings us closer to upstream with benefit of upstream support for theming and styling issues. This will also eliminate all the issues our users have been experiencing in the past when using Qt applications with Adwaita-qt style on Fedora Workstation. == Scope == * Proposal owners: # Drop QGnomePlatform and Adwaita-qt from Fedora Workstation compose. # Drop our custom patches making Qt to use QGnomePlatform by default. # Upstream some of the QGnomePlatform features to Qt upstream and backport them to Fedora packages (until released upstream). * Other developers: [OPTIONAL] Packagers blacklisting either QGnomePlatform or Adwaita-qt in their packages can stop doing that. * 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 == We will make QGnomePlatform to not be used by default even when installed. Users will still be able to use it by using a Qt env variable or passing an option specifying what platform theme should be used. For this reason there shouldn't be any extra work needed to be done by the users who upgraded to Fedora 39. == User Experience == The user experience should remain the same or be actually better in case Qt apps they were using were not working properly with QGnomePlatform or Adwaita-qt. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System
F39 Change Proposal: LibuserDeprecation (System Wide)
https://fedoraproject.org/wiki/Changes/LibuserDeprecation 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 == Libuser is not actively developed. Most of the depending component have build-time option to work without libuser. == Owner == * Name: [[User:THalman| Tomas Halman]] * Email: == Detailed Description == The libuser provides library and command line utilities to manipulate user and group information. The purpose of the library is/was to hide the differences between users in LDAP and files in etc (passwd, groups...). The support for LDAP is not complete and there is no plan to extend the functionality. The LDAP integration in Fedora is nowadays done by SSSD. In the past, the libuser was used by more component including Fedora installer. Currently the list is short * usermode (Requires development, it is not complicated but the dependency is unconditional) * util-linux (compile time option) * passwd (I suggest to ship passwd utility from shadow-utils instead of passwd and drop passwd package as well) == Feedback == == Benefit to Fedora == The main benefit is to decrease the maintenance and packaging work on library that does not bring much value while the functionality is provided by another components. == Scope == * Proposal owners: Dropping the package, move it to EPEL eventually * Other developers: ** Update usermode code to make libuser dependency configurable. ** Update usermode packaging to compile it without libuser ** Change packaging of util-linux to compile without libuser dependency ** Change packaging of shadow-utils to provide passwd utility * Release engineering: [https://pagure.io/releng/issue/11492] Libuser is part of base image and must be removed. IMO mass rebuild is not required. * Policies and guidelines: Since this is about dropping packages release notes must be updated. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == People who used libuser to manipulate users in LDAP will have to move to SSSD. == How To Test == 0. no special hardware needed 1. remove libuser, passwd, install new shadow-utils, usermod and util-linux 2. try to change password of some user 3. try to modify user using usermod 4. expected results: everything works normally == User Experience == This change should not be visible for users. == Dependencies == * usermod (code modification, packaging to drop libuser dependency) * shadow-utils (packaging to provide passwd utility * util-linux (packaging to drop libuser dependency) * passwd (drop package) == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: final development freeze * Blocks release? No == Documentation == There is no extra documentation for this change except release notes. == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
F39 Change Proposal:
https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.15 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 == In ibus-anthy 1.5.15, the icon tag will be added to the metainfo, the Japanese era is updated for 2023, the candidate window is enhanced for OSK(On-Screen Keyboard). == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * ibus-anthy already has the icon but it wasn't indicated in the metainfo. Also screenshots and keywords are updated. * ibus-anthy will convert the Japanese era and "2023" mutually * ibus-anthy determines a clicked item on the candidate window but also will commit the clicked item on the candidate window in case of enabling the OSK(On-Screen Keyboard) mode in GNOME Wayland. == Feedback == == Benefit to Fedora == The metainfo data is updated within the ibus-anthy package, Japanese era is updated in a ibus-anthy dictionary file, the OSK mode is available only if the OSK is enabled and ibus-anthy switches the candidate mode. == Scope == * Proposal owners: ibus-anthy * 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 == == How To Test == 1. Enable ibus-anthy 2. Run gnome-text-editor 3. Type "２０２３" or "れいわ５" and space keys 4. The Japanese era and 2023 is converted mutually 1. Enable OSK and ibus-anthy 2. Run gnome-text-editor 3. Click "a" and space x 2 keys in OSK and show the candidate window 4. Click a candidate string on the candidate window 5. The selected candidate string is committed in gnome-text-editor == User Experience == The metainfo data is relative with gnome-software and I hope the ibus-anthy section will be updated. Japanese era has been rarely used in Japanese documents and the ibus-anthy conversion will be useful. The OSK usability will be enhanced with the mouse. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the change to ibus-anthy. * Contingency deadline: Beta release * Blocks release? No == Documentation == N/A == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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
F39 Change Proposal: Golang1.21 (System-Wide)
https://fedoraproject.org/wiki/Changes/golang1.21
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora 39.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.21 in Fedora
39. Go 1.21 is expected to be released in August 2023. A mass rebuild
of all of the dependent packages is required.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features.
Therefore Fedora will be providing a reliable development platform for
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.21
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 39, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: It doesn't align directly with
the current objectives but it helps maintain the quality of the
project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.21 from rawhide and use it to build your
application(s)/package(s).
# Scratch build against rawhide.
# Your application/package built using golang 1.21 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed: ~2000.
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.20.X if significant issues are
discovered
* Contingency deadline: Beta freeze
== Documentation ==
https://tip.golang.org/doc/go1.21
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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
F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
https://fedoraproject.org/wiki/Changes/cleanup_systemd_install 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 == Fedora default installs with a shim + grub bootloader on EFI platforms, yet has been shipping systemd-boot in various forms for a number of releases. There are a few howto's which describe how to replace grub with systemd-boot with varying levels of functionality. This should be easier with a formalized default method that can be built upon. This proposal aims to complete the work started with anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the "everything" media can install a grub free machine. == Owner == * Name: [[User:jlinton| Jeremy Linton]] * Email: * Name: Possibly others since it may touch -comps, systemd-boot, etc == Detailed Description == As a first pass, the 'inst.sdboot' option already in anaconda should work. As it stands, that replaces grub+shim with the systemd-boot loader, and moves the kernel + initrd to the EFI system partition (ESP). It doesn't attempt to create unified kernel images, so the existing `dnf update`, `kdumpctl`, and `make install` in a kernel source directory should all work. The vast majority of this work has been done, leaving only two action items, removing grubby from core, and merging a shimming package (sdubby) into the fedora repos. Beyond that there are various enhancements which can be made to remove the /boot partition (leaving the EFI at /boot/efi), enrolling fedora keys if the secure boot mode is "Setup", adding options to enable shim+systemd-boot, assuring that there is a systemd-boot-signed package, etc. The advantages of just enabling the systemd-boot loader without UKIs or restructuring the /boot and /boot/efi mount points result in a wider range of supported machines and a more familiar environment for users and applications. AKA, by not changing the HostOnly/initrd build process the vast majority of UEFI machines are supported. To be clear the intention isn't to replace grub, but to co-exist alongside as an alternative bootloader. == Feedback == == Benefit to Fedora == Fedora is considered a forward looking distro. As systemd-boot and UKIs gain traction it should be straightforward for users/testers to try out this option in their own environments with a well defined configuration. Potentially in the future, once secure boot/etc is straightened out the simpler/cleaner code base may prove to be more secure, or a consistent set of measured boot PCRs may enable a simpler (for the end user) encrypted storage environment. == Scope == * Proposal owners: At the moment two things remain open: https://pagure.io/fedora-comps/pull-request/838 and: https://bugzilla.redhat.com/show_bug.cgi?id=2134972 Both of which are largely in the "needs more discussion" state, but otherwise are complete as they stand. There is also an open kexec-tools + aarch64 zboot set that needs to be merged in order to support kdump properly on aarch64 platforms, although that problem is caused by zboot and affects grub as well. Zboot is required for systemd-boot at the moment. * Other developers: Depending on the results of the discussion above: Its possible the systemd maintainers, kdumpctl, etc may need changes. * 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 == Ideally nothing as we aren't deprecating or changing the shim + grub boot paths. == How To Test == # Have a VM or non critical test machine that can be reinstalled at will. # Assure secure boot is disabled or in setup mode. # Pass `inst.sdboot` on the kernel/grub command line presented on the install media and install as normal. ## possibly adding additional space to the EFI system partition during partitioning to guarantee there is sufficient space for the number of bootable kernels active on the machine (~100MB each should be more than sufficient) ## Alternatively `--sdboot` can be added to the bootloader command in kickstarts, and the partitions/etc adjusted there # Use the machine as normal. # Report issues during upgrades, or with any packages that can't find kernel images. Everything besides the loader entries, kernel image, and generated initrds should remain in /boot. == User Experience == Ideally, after the initial install the fedora experience should generally remain the same. There may be slight differences in boot timings (at least on aarch64 possibly slightly faster) and the bootctl utility may have more information and work properly. == Dependencies == Systemd-boot, described in the comps and sdubby review. == Contingency
Re: Towards enabling rpm sysusers integration
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > I was hoping we would be make the dependency on setup optional. > It is a fairly heavyweight package (700+ kb) and with lots of > not-that-useful-on-a-typical-modern-installation stuff (mail alias support, > csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it > clutters /etc, which ideally would be empty, and also /etc/services is 700 kb. /etc/services and /etc/protocols are AFAIK mandatory if you want to have network services (either client or server). I don't think there's anything else providing that information. -- Chris Adams ___ 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: Towards enabling rpm sysusers integration
On Thu, Jun 22, 2023 at 01:18:27PM +0300, Panu Matilainen wrote:
> Hey all,
>
> Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's
> time to start looking towards enabling the sysusers integration:
> https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
Cool, let's do this!
> We (as in rpm-team) are not pushing for doing all this in Fedora 39, this is
> more to start discussion and lay down the necessary steps. In the 4.19
> builds so far, the sysusers integration has been entirely disabled because
> it needs more coordination than just drop it in. Much of it is between
> systemd and rpm, but any package with non-root ownerships will be affected
> in the end. At least the following, and not necessarily exactly in this
> order:
>
> 1. systemd has it's own user/group provides generator which directly
> conflicts (both on generated content and file level) with the new native
> generator in rpm, and the feature will not work with the provides generated
> by systemd.
I merged your PR to disable this, so this first step is done.
> 2. systemd provides users and groups that are actually owned by the setup
> package. As rpm is now turning non-root file ownership into dependencies,
> systemd could end up pulled in where setup is needed (eg early install
> stage) which will not end up well. So systemd will need to stop providing
> users it does not actually own.
I was hoping we would be make the dependency on setup optional.
It is a fairly heavyweight package (700+ kb) and with lots of
not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
clutters /etc, which ideally would be empty, and also /etc/services is 700 kb.
setup is currently pulled in by dependencies, but e.g. in the initrd we should
be fine without it. (And the same applies for e.g. minimal container
images without login users or a shell.)
Maybe the non-essential stuff could be split out into a new
subpackage, with setup only providing /etc/{passwd,group,shadow,gshadow}
with the base set of users and groups, and all other files moved to
setup-clutter.
> 3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased
> out. As it'll be a long time before the sysusers feature is in all Fedora
> versions, it needs a longer term plan. One simple possibility is do what was
> done with all those ldconfig from %post back then: change the %sysusers_()
> macros to no-ops in rawhide to let rpm handle it, and only actually bother
> updating packages once all relevant versions have the sysusers feature.
+1 to this plan.
> 4. The sysusers "hook" in rpm needs to be enabled (uncomment
> %__systemd_sysusers macro in rpm). It wont do anything at all before 1) and
> 3) are done though.
>
> 6. The user/group dependencies for non-root users need to be turned into
> hard requires (initially these are just recommends). I would be suprised if
> this doesn't cause some disruption somewhere, although the content that is
> not root:root owned is pretty scarce these days.
>
> 7. Packages creating or using non-root user/group need to be rebuilt.
>
> 7. One day a few years from now, replace
> https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
> with "supply a sysusers file for your needs" :P
> In reality, it'll need adjusting long before that and for that, it'll need
> FPC recommendations and all.
>
> 8. Remove all user/group addition related macro and script fubar from specs
> for good. The first commit in rpm source tree is from 1995, it'd be a nice
> 30 year celebration... but I don't expect it to happen quite that soon.
> Maybe in 2035 new people will start look at old specs in horror, "What do
> you mean they had to deal with all this user/group stuff manually! For 30
> years!"
>
> I've begun from 1) now:
>
> https://src.fedoraproject.org/rpms/systemd/pull-request/109
This is merged now and the package is built. (I guess it's probably in
gating now.)
> https://src.fedoraproject.org/rpms/rpm/pull-request/45
>
> After those have been done, people can start experimenting with the feature.
> I don't remember seeing an actual Fedora Change for either file-trigger
> enablement or current %sysuser_* macros so I'm not sure it's needed here
> either?
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
Zbyszek
___
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
[rpms/perl-Lingua-EN-Syllable] PR #4: Package tests
mspacek merged a pull-request against the project: `perl-Lingua-EN-Syllable` that you are following. Merged pull-request: `` Package tests `` https://src.fedoraproject.org/rpms/perl-Lingua-EN-Syllable/pull-request/4 ___ 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
[rpms/perl-Devel-CheckLib] PR #3: Requires: redhat-rpm-config for tests
jplesnik merged a pull-request against the project: `perl-Devel-CheckLib` that you are following. Merged pull-request: `` Requires: redhat-rpm-config for tests `` https://src.fedoraproject.org/rpms/perl-Devel-CheckLib/pull-request/3 ___ 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 2216784] New: perl-HTTP-Tiny-0.086 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216784 Bug ID: 2216784 Summary: perl-HTTP-Tiny-0.086 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Tiny Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.086 Upstream release that is considered latest: 0.086 Current version/release in rawhide: 0.084-1.fc39 URL: http://search.cpan.org/dist/HTTP-Tiny/ 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/2982/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-HTTP-Tiny -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216784 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216784%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
[rpms/perl-Lingua-EN-Fathom] PR #3: 1.23 bump
mspacek opened a new pull-request against the project: `perl-Lingua-EN-Fathom` that you are following: `` 1.23 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Lingua-EN-Fathom/pull-request/3 ___ 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
[rpms/perl-Lingua-EN-Fathom] PR #2: 1.23 bump
mspacek closed without merging a pull-request against the project: `perl-Lingua-EN-Fathom` that you are following. Closed pull-request: `` 1.23 bump `` https://src.fedoraproject.org/rpms/perl-Lingua-EN-Fathom/pull-request/2 ___ 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
[rpms/perl-Lingua-EN-Syllable] PR #4: Package tests
mspacek opened a new pull-request against the project: `perl-Lingua-EN-Syllable` that you are following: `` Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Lingua-EN-Syllable/pull-request/4 ___ 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
[rpms/perl-Devel-CheckLib] PR #3: Requires: redhat-rpm-config for tests
jplesnik opened a new pull-request against the project: `perl-Devel-CheckLib` that you are following: `` Requires: redhat-rpm-config for tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Devel-CheckLib/pull-request/3 ___ 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: What is Fedora?
On Wed, Jun 21, 2023 at 5:46 PM Philip Wyett wrote: > > On Wed, 2023-06-21 at 17:39 -0400, Ben Cotton wrote: > > On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett > > wrote: > > > > > It has much to do. Fedora is a community apparently Red Hat no longer > > > needs. The now ELN > > > backend > > > can satisfy pre testing and could make fedora redundant. > > > > ELN is a build of (some) Fedora packages with EL-specific options, so > > it requires Fedora. > > > > > > ELN can exist off an internal non fedora tree. Just depends who is updating > the tree. Literally anything CAN happen. However Fedora ELN without Fedora Rawhide would be just CentOS Stream and therefore redundant. The fact that Fedora ELN continues to see significant support from Red Hat (they essentially pay several people to work on it full-time) should make it clear that it has value. ___ 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: What is Fedora?
On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen wrote: > > On Wed, 21 Jun 2023 21:06:40 +0100, you wrote: > > >Hi all, > > > >Obviously many will have seen: > > > >https://www.redhat.com/en/blog/furthering-evolution-centos-stream > > > >and see, where EL (contributors like you of fedora/EPEL) have been knocked > >down: > > > >https://bugzilla.redhat.com/show_bug.cgi?id=2215299 > > > >Let us face it our efforts with the Fedora project are not valued and it is > >a means nothing to the > >new corporate IBM/Red Hat enterprise systems that we have to struggle to get > >access to srpms, to > >make a community. What is community now to Red Hat? > > My interpretation of the blog post, combined with recent actions > towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as > the new "Fedora" for basing future versions of RHEL. Just to interject, this is an incorrect interpretation. Red Hat is still highly committed to Fedora (as evidenced by the continued support for Fedora ELN as the integration path from Rawhide to CentOS Stream). ___ 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
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2023-06-23 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: * x86_64-v3 baseline and dropping i686 multilib * Plans for the next 3-6 months Source: https://calendar.fedoraproject.org//meeting/10449/ ___ 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: What is Fedora?
On 6/21/23 22:26, Gerald Henriksen wrote: On Wed, 21 Jun 2023 21:06:40 +0100, you wrote: Hi all, Obviously many will have seen: https://www.redhat.com/en/blog/furthering-evolution-centos-stream and see, where EL (contributors like you of fedora/EPEL) have been knocked down: https://bugzilla.redhat.com/show_bug.cgi?id=2215299 Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to make a community. What is community now to Red Hat? My interpretation of the blog post, combined with recent actions towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as the new "Fedora" for basing future versions of RHEL. CentOS Stream topic is still confusing to many, thus I am going to use the opportunity to mention two talks which I have provided at FOSDEM 2022 [1] and Open Infra Summit 22 [2] on the matter: [1] https://archive.fosdem.org/2022/schedule/event/centos_stream_stable_and_continuous/ [2] https://discussion.fedoraproject.org/t/centos-stream-talk-at-openinfra-summit/40045/1 I also have a leaflet version [3] for those who prefer text. [3] https://gitlab.com/bookwar/centos-leaflet/-/blob/main/centos-leaflet.pdf Part of the confusion comes from the fact that people refer to upstream development, Fedora development and CentOS/RHEL development using just one word - development, while in reality these are three very different activities, and all of them are required for the RHEL existence. You can not replace upstream with RHEL development, you would have to create new upstream for that. The same way you can not replace Fedora development with RHEL/CentOS Stream development, it is a very different thing and you would need to create it. The second part comes from thinking of CentOS Stream as something in the middle, between Fedora and RHEL. CentOS Stream is a rebuild of RHEL. It is a rebuild of exactly RHEL sources taken from the same git tree as RHEL builds take those sources. It is not a middle - it is RHEL. So let's look at the sources story closely: 1) How it was before Stream: there was an internal git tree. RHEL Engineers would commit RHEL changes to that tree, changes would be built into RPM and SRPM. On release, RPM and SRPM would be published for RHEL customers. On that release date CentOS engineers would take the published SRPM, unpack it, and upload the content to the centos git repo. So CentOS git essentially contained the "exploded SRPMS". No git history was available. CentOS Engineer then would go to CentOS Koji and build the CentOS package from that exploded source 2) How it was after Stream but Before the announcement: There is a public git tree on GitLab.com [4] RHEL Engineers commit changes to it. RHEL engineers build CentOS package in public Stream Koji _and_ RHEL package internally from the same git commit. CentOS package becomes public, RHEL package goes into RHEL repository. [4] https://gitlab.com/redhat/centos-stream/rpms/glibc As soon as RHEL package is released, the SRPM for a RHEL package becomes available. CentOS Engineer would take that SRPM, unpack it and upload the content to CentOS Git. But the CentOS package for that RHEL SRPM has already been built weeks ago. So now we have CentOS package, which is available for weeks in Koji, its sources available for the same two weeks on GitLab [4], with proper git history, MR history, and test history. And then a there is a second set of CentOS sources (exploded rpms, no history), which are not really CentOS sources anymore, because CentOS doesn't build anything from them. 3) So what happened? - CentOS Engineers will not be producing that git repo of exploded SRPMs anymore because there is no need for them in CentOS project. - Red Hat recommends to take RHEL sources from CentOS Stream repositories because that is the actual source from which RHEL packages are built by RHEL Engineers. Can you still get access to SRPMs and create exploded sources repo - Yes. But there is no practical reason for Red Hat or for CentOS Project to maintain such a service. There is no change in Fedora or with anything related to Fedora. -- Aleksandra Fedorova, member of Fedora Council RHEL/CentOS Strem CI Engineer bookwar on Matrix ___ 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
Re: What is Fedora?
I'm a Red Hat employed engineer, working on all Fedora, CentOS Stream and RHEL. This is what each means for me in particular (but should also be applicable in general) in practice: * RHEL - only when I'm bound by some legal requirement (embargo, etc.) I do work 'RHEL only' (not visible in CentOS stream). In practice, such work is expected to be seen in CentOS Stream once the legal barrier falls / expires. * CentOS Stream - all work (except abovementioned) for RHEL is done here. The code has been available here (for 2 years already for C9S): https://gitlab.com/redhat/centos-stream/ Are you missing anything? (codebase-wise) This means my work on RHEL is visible unlike ever before. Open to submissions via merge requests Also merge requests where I develop changes are open to examination during my development of them. (unlike anytime before) * Fedora - unlike RHEL or CentOS, this is the place where I can develop new features. I don't have this space downstream. So tuning packaging, trying out various enhancements, adopting big upstream changes, packing latest greatest upstream releases. All that will be branched to form a new RHEL one day. This is the only way for me to introduce big changes. As I see it, both RHEL and Fedora profit from that to maximum. And I don't expect this relationship to go away anytime soon. However I might have misunderstood the core of this discussion. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Thu, Jun 22, 2023 at 11:39 AM Miroslav Suchý wrote: > > Dne 22. 06. 23 v 10:44 Michael J Gruber napsal(a): > > In each case, the way it was done and communicated was literally begging > > for bad press. > > ... > > > > So, the signal is either "we don't care about our upstream" or "we do not > > understand upstream's importance and concerns". > > None of the last two. It is first one out of these three: wrongly > communicated and begging for bad press. > > I think that RH engineers are pretty bad in communicating things. Me included. > > -- > Miroslav Suchy, RHCA > Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys > ___ > 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 2216352] perl-libwww-perl-6.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216352 Michal Josef Spacek changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ASSIGNED|CLOSED Last Closed||2023-06-22 10:31:52 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216352 ___ 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: Rawhide update gating on openQA tests will be enabled Wednesday
On Mon, 2023-06-19 at 18:28 +0200, Adam Williamson wrote: > Hey folks! So, as per https://pagure.io/fesco/issue/3011 , we plan to > enable gating of Rawhide updates on openQA test results on Wednesday. This is now enabled! Please let me and/or releng know if it causes any terrible consequences, and in the worst case, we'll turn it off again. I did notice while doing final checks that we still have a bit of a result display inconsistency. If you check https://bodhi.fedoraproject.org/updates/FEDORA-2023-3c2931ff23 - the bad sqlite update - you will see that Bodhi/Greenwave still think several tests are "running". They are actually cancelled. This is because they're jobs that depend on other tests that failed; when that happens, openQA cancels the dependent jobs, but does not publish any event about it in its internal event messaging system. Our system for publishing Fedora messages and reporting results to resultsdb triggers off those internal events, so because we don't get an internal openQA "job_done" or "job_cancel" message, we never send any Fedora messages or file a failed/cancelled result to ResultsDB, so Greenwave and hence Bodhi don't know the job has been cancelled. They'll just think it's 'queued' forever. I'm working on a fix for this upstream now. The issue doesn't have any particularly terrible consequences - any time we land in this situation, we'll have the record that the *parent* job failed, so the update will be gated as it should be - but it does look a bit confusing in Bodhi. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
Towards enabling rpm sysusers integration
Hey all, Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's time to start looking towards enabling the sysusers integration: https://rpm-software-management.github.io/rpm/manual/users_and_groups.html We (as in rpm-team) are not pushing for doing all this in Fedora 39, this is more to start discussion and lay down the necessary steps. In the 4.19 builds so far, the sysusers integration has been entirely disabled because it needs more coordination than just drop it in. Much of it is between systemd and rpm, but any package with non-root ownerships will be affected in the end. At least the following, and not necessarily exactly in this order: 1. systemd has it's own user/group provides generator which directly conflicts (both on generated content and file level) with the new native generator in rpm, and the feature will not work with the provides generated by systemd. 2. systemd provides users and groups that are actually owned by the setup package. As rpm is now turning non-root file ownership into dependencies, systemd could end up pulled in where setup is needed (eg early install stage) which will not end up well. So systemd will need to stop providing users it does not actually own. 3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased out. As it'll be a long time before the sysusers feature is in all Fedora versions, it needs a longer term plan. One simple possibility is do what was done with all those ldconfig from %post back then: change the %sysusers_() macros to no-ops in rawhide to let rpm handle it, and only actually bother updating packages once all relevant versions have the sysusers feature. 4. The sysusers "hook" in rpm needs to be enabled (uncomment %__systemd_sysusers macro in rpm). It wont do anything at all before 1) and 3) are done though. 6. The user/group dependencies for non-root users need to be turned into hard requires (initially these are just recommends). I would be suprised if this doesn't cause some disruption somewhere, although the content that is not root:root owned is pretty scarce these days. 7. Packages creating or using non-root user/group need to be rebuilt. 7. One day a few years from now, replace https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ with "supply a sysusers file for your needs" :P In reality, it'll need adjusting long before that and for that, it'll need FPC recommendations and all. 8. Remove all user/group addition related macro and script fubar from specs for good. The first commit in rpm source tree is from 1995, it'd be a nice 30 year celebration... but I don't expect it to happen quite that soon. Maybe in 2035 new people will start look at old specs in horror, "What do you mean they had to deal with all this user/group stuff manually! For 30 years!" I've begun from 1) now: https://src.fedoraproject.org/rpms/systemd/pull-request/109 https://src.fedoraproject.org/rpms/rpm/pull-request/45 After those have been done, people can start experimenting with the feature. I don't remember seeing an actual Fedora Change for either file-trigger enablement or current %sysuser_* macros so I'm not sure it's needed here either? Comments, thoughts etc? - Panu - ___ 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: What's the error in this build?
On Thu, Jun 22, 2023 at 11:02:13AM +0200, Adam Williamson wrote: > On Thu, 2023-06-22 at 10:57 +0200, Miroslav Suchý wrote: > > Dne 22. 06. 23 v 10:40 Daniel P. Berrangé napsal(a): > > > On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 > > > > > > > > I don't see what the error is ... > > > Mock appears to have failed to install the builddeps, for unknown > > > reasons. I would just re-try the build in hope that it is a transient > > > infra problem ? If it isn't transient, I guess it'll require admin > > > attention ? Either way it doesn't look like a problem on your side. > > > > Hmm, it just happened to me too: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102444300 > > > > I would guess that dnf-3 was killed in the middle of the operation. It is > > different builder than Richard's. So it does > > not seems to be just builder issue. > > It's likely this that I just caught in openQA: > https://bugzilla.redhat.com/show_bug.cgi?id=2216688 > > a crash in sqlite. I've filed a request to untag it: > https://pagure.io/releng/issue/11497 > > if anyone's awake with the power to do that, please do so... Since it looks as if this got untagged about an hour ago I submitted a new build. Let's see how it goes: https://koji.fedoraproject.org/koji/taskinfo?taskID=102446485 Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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: What is Fedora?
Dne 22. 06. 23 v 10:44 Michael J Gruber napsal(a): In each case, the way it was done and communicated was literally begging for bad press. ... So, the signal is either "we don't care about our upstream" or "we do not understand upstream's importance and concerns". None of the last two. It is first one out of these three: wrongly communicated and begging for bad press. I think that RH engineers are pretty bad in communicating things. Me included. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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
go-sig status
Hi all, This mail is just a heads up on go-sig delicate current status. After a "non-responsive" process for one of the go-sig members[1], a lot of go-sig packages become orphans. This maintainer has been working for years creating hundreds of packages and updating them. The orphaning process caused that ~2100/~2300 go-sig packages to be affected directly or indirectly. The current number is 1633/2373 packages affected. The list of currently affected packages can easily be checked using package-dashboard[2] and clicking on the 'orphan' (little person) button at the top right. IIUC in little more than 4 weeks all those orphaned packages will be retired and that can cause massive impact. Indirectly affected packages include docker (moby-engine), containerd, rclone, restic or gopass to name a few. Some packages might be key for some people, some might just disappear without causing major noise. I adopted ~100 packages needed by packages I maintain and I'm in the process to update them. More hands will be needed to take the rest and/or review new deps required by the updates. And that's it. As this may create some bad press if some of those packages vanish, I just wanted to alert devel-list. Kind regards, Mikel [1] https://pagure.io/fesco/issue/2999 [2] https://packager-dashboard.fedoraproject.org/dashboard?groups=go-sig ___ 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
[rpms/perl-libwww-perl] PR #49: 6.71 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.71 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/49 ___ 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
Fedora-Rawhide testing blocked in Testing Farm (partially)
Hi, a few more issues appeared: 1. Testing PRs via Zuul is broken due to missing feature in dnf5 https://github.com/rpm-software-management/dnf5/issues/549 No ETA for fixing this one 2. Packit's sanity copr installation test fails due to to dnf5-plugins needed for copr plugin. ETA 30 min. Best regards, /M< On Wed, Jun 21, 2023 at 7:39 PM Miroslav Vadkerti wrote: > Both issues were hot patched, and testing against Rawhide is unblocked > again \o/ > > Thanks to all who helped! > > /M > > On Wed, Jun 21, 2023 at 2:51 PM Miroslav Vadkerti > wrote: > >> Hi, >> >> Fedora Rawhide testing blocked on dnf5 update, which broke Testing Farm. >> >> We are trying to hotpatch the problems to bring back testing against >> Rawhide. >> >> ETA 2 hours. >> >> For updates watch: >> https://status.testing-farm.io/issues/2023-06-21-rawhide-outage/ >> >> Best regards, >> /M >> >> -- >> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE >> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 >> Remote Czech Republic :: Red Hat Czech s.r.o >> >> >> > > -- > Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE > IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 > Remote Czech Republic :: Red Hat Czech s.r.o > > > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o ___ 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
[rpms/perl-libwww-perl] PR #49: 6.71 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.71 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/49 ___ 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: What is Fedora?
On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote: > In the specific case of RHEL srpms, it makes life harder for EPEL > packagers because you can't look at the source easily when they are > problems between RHEL and EPEL packages. It matches well with RH's > standard of shipping libraries without headers etc - it is easier for them > and limits the scope of support contracts but makes upstream's life > harder. EPEL packagers should have easy access to RHEL through the no-cost subscription program. Or, reasonably easy -- I'm aware that the developer portal hoops are more... hoopy... than would be idea. But once set up, it shouldn't be difficult. If you _are_ finding rough spots in that, I can raise the issues and see if we can make things beter. -- Matthew Miller Fedora Project Leader ___ 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: What's the error in this build?
On Thu, 2023-06-22 at 11:02 +0200, Adam Williamson wrote: > On Thu, 2023-06-22 at 10:57 +0200, Miroslav Suchý wrote: > > Dne 22. 06. 23 v 10:40 Daniel P. Berrangé napsal(a): > > > On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 > > > > > > > > I don't see what the error is ... > > > Mock appears to have failed to install the builddeps, for unknown > > > reasons. I would just re-try the build in hope that it is a transient > > > infra problem ? If it isn't transient, I guess it'll require admin > > > attention ? Either way it doesn't look like a problem on your side. > > > > Hmm, it just happened to me too: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102444300 > > > > I would guess that dnf-3 was killed in the middle of the operation. It is > > different builder than Richard's. So it does > > not seems to be just builder issue. > > It's likely this that I just caught in openQA: > https://bugzilla.redhat.com/show_bug.cgi?id=2216688 > > a crash in sqlite. I've filed a request to untag it: > https://pagure.io/releng/issue/11497 > > if anyone's awake with the power to do that, please do so... Note, if I'd actually remembered to turn on Rawhide gating yesterday liek I said I would, it would have prevented this reaching the buildroot and we'd have had a win right away. Sorry I forgot! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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: What's the error in this build?
On Thu, 2023-06-22 at 10:57 +0200, Miroslav Suchý wrote: > Dne 22. 06. 23 v 10:40 Daniel P. Berrangé napsal(a): > > On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 > > > > > > I don't see what the error is ... > > Mock appears to have failed to install the builddeps, for unknown > > reasons. I would just re-try the build in hope that it is a transient > > infra problem ? If it isn't transient, I guess it'll require admin > > attention ? Either way it doesn't look like a problem on your side. > > Hmm, it just happened to me too: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102444300 > > I would guess that dnf-3 was killed in the middle of the operation. It is > different builder than Richard's. So it does > not seems to be just builder issue. It's likely this that I just caught in openQA: https://bugzilla.redhat.com/show_bug.cgi?id=2216688 a crash in sqlite. I've filed a request to untag it: https://pagure.io/releng/issue/11497 if anyone's awake with the power to do that, please do so... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]
>> ELN is a build of (some) Fedora packages with EL-specific options, so >> it requires Fedora. > ELN can exist off an internal non fedora tree. Just depends who is > updating the tree. Sure, but... that's the _opposite_ of the direction things are going. Previously, what happened to make a major RHEL release was: 1. Some Fedora Linux Release -> an internal bootstrap 2. ... a year or so of secret work ... 3. RHEL Beta 4. RHEL Release 5. CentOS Linux rebuild 6. Internal RHEL build process, internal work on minor release 7. RHEL updates appear in publiuc 8. CentOS Linux rebuilds of those. There's no connection to Fedora beyond the intial fork, and a lot of work done inside Red Hat without any transparency. Now, CentOS Stream brings that to the surface: 1. Fedora Rawhide continually updated 2. ELN maintained in parallel, as part of Fedora 3. At some point, ELN branched to new CentOS Stream 4. ... a year or so of CentOS Stream development in public ... 5. RHEL Beta forked from that, released 6. Work on RHEL updates visible in CentOS Stream 7. Updates appear in CentOS Stream 8. Updates released to RHEL Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git history from Fedora, which is a big improvement in preserving all of the incredible, valuable work from Fedora contributors. All of this is the exact opposite of Red Hat preparing to make some new base for RHEL. Additionally, this model provides a clean path for Red-Hat-opinionated decisions to differ from those we make from Fedora. Take BTRFS as an example. Or, the increase in CPU baseline. Like this: Fedora Linux: Community Space - * Community engineering decisions * No special code privileges due to your employer * Community-run infrastructure with RH investment, significant resources from Amazon, contributions from other companies * Community quality engineering with RH investment * Community support * No cost CentOS Stream: Shared Space --- * Red Hat Engineering decisions with community input * Pull requests from the community, approval from Red Hat engineers * Red Hat-provided and maintained infrastructure * Red Hat quality engineering with partner and community involvement * Community support * no cost Red Hat Enterprise Linux: Product Space --- * Red Hat Engineering decisions with customer input * Red Hat engineers and only RH engineers do the work * Red Hat infrastructure * Red Hat quality engineering (mostly done in Stream, though) * Enterprise support * Subscription, including low- and no-cost options Previously, we had a whole convoluted thing which people tried to describe in terms of MC Escher paintings. This is far better, and Fedora is in a better place. In the earlier setup, CentOS _was_ sometimes positioned as a competitor (although generally, those of us working in the actual Fedora and CentOS communities didn't have any interest in playing that game.) -- Matthew Miller Fedora Project Leader ___ 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 2216352] perl-libwww-perl-6.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216352 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Michal Josef Spacek --- Changes: 6.71 2023-06-20 19:44:19Z - Use rather than require Module::Load (GH#435) (Olaf Alders) For rawhide only -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216352 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216352%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: What's the error in this build?
Dne 22. 06. 23 v 10:40 Daniel P. Berrangé napsal(a): On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 I don't see what the error is ... Mock appears to have failed to install the builddeps, for unknown reasons. I would just re-try the build in hope that it is a transient infra problem ? If it isn't transient, I guess it'll require admin attention ? Either way it doesn't look like a problem on your side. Hmm, it just happened to me too: https://koji.fedoraproject.org/koji/taskinfo?taskID=102444300 I would guess that dnf-3 was killed in the middle of the operation. It is different builder than Richard's. So it does not seems to be just builder issue. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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 2216582] perl-MCE-1.888 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216582 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-MCE-1.888-1.fc39 Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2023-06-22 08:45:05 --- Comment #2 from Fedora Update System --- FEDORA-2023-735793c3df 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=2216582 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216582%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
Re: What is Fedora?
> On 6/22/23 06:21, Gordon Messmer wrote: > > That's how I understand it well and I'm a bit confused what's the > "fuss" about. The git.centos.org mirrored sources that were used to build > CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, > the same is > true - the sources are still available, just at different location [0]. So > this > doesn't seem like RH is "locking things down", just getting rid of things > that are not needed anymore. > > Note that I'm in a no way endorsing the change, I'm just trying to understand > what's the big deal (if there's any). > > [0] https://gitlab.com/redhat/centos-stream/rpms > [1] https://vault.centos.org/centos/8-stream/ The big deal is that it sends wrong signals at the wrong time. Within the last few weeks, we had out of the blue (pun intended): - Lay-off of the Fedora Program Manager - Dropping LO packages and dependencies the hard way (orphan first, announce later when the rubbles are crumbling) - Retreating from GPL's source distribution requirement to the bare minimum (or less, I'm no lawyer) In each case, the way it was done and communicated was literally begging for bad press. In the specific case of RHEL srpms, it makes life harder for EPEL packagers because you can't look at the source easily when they are problems between RHEL and EPEL packages. It matches well with RH's standard of shipping libraries without headers etc - it is easier for them and limits the scope of support contracts but makes upstream's life harder. So, the signal is either "we don't care about our upstream" or "we do not understand upstream's importance and concerns". And that is why packagers may consider dropping EPEL branches and let RH pick from Fedora what they want - at the expense of having to support it themselves. That will reduce RHEL to a pure enterprise distribution without community. Is that what their customers want? Groundhog day. ___ 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 2216582] perl-MCE-1.888 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216582 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-735793c3df has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-735793c3df -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216582 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216582%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: What's the error in this build?
On Thu, Jun 22, 2023 at 09:07:34AM +0100, Richard W.M. Jones wrote: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 > > I don't see what the error is ... Mock appears to have failed to install the builddeps, for unknown reasons. I would just re-try the build in hope that it is a transient infra problem ? If it isn't transient, I guess it'll require admin attention ? Either way it doesn't look like a problem on your side. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Proposal: drop delta rpms (for real this time)
On Mon, Jun 12, 2023 at 09:46:26AM -0700, Kevin Fenzi wrote: > I don't think there's a formal change filed yet. > > Matthew: Did you want to do that? Or would you like me or someone else > to do so? I would love someone else to do so, but if no one else wants to, I can. :) -- Matthew Miller Fedora Project Leader ___ 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: What's the error in this build?
On 6/22/23 11:07, Richard W.M. Jones wrote:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065
I don't see what the error is ...
Rich.
Towards the end:
DEBUG util.py:539: Executing command: ['/usr/bin/systemd-nspawn', '-q',
'-M', '03701d048e03484c80696e05b2d9f2fe', '-D',
'/var/lib/mock/f39-build-43645279-5233438-bootstrap/root', '-a',
'--capability=cap_ipc_lock',
'--bind=/tmp/mock-resolv.0hjd84i1:/etc/resolv.conf', '--console=pipe',
'--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash',
'--setenv=HOME=/var/lib/mock/f39-build-43645279-5233438/root/installation-homedir',
'--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin',
'--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"',
'--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8',
'--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf-3',
'builddep', '--installroot',
'/var/lib/mock/f39-build-43645279-5233438/root/',
'--setopt=install_weak_deps=0', '--disableplugin=local',
'--disableplugin=spacewalk', '--disableplugin=versionlock',
'/var/lib/mock/f39-build-43645279-5233438/root//builddir/build/SRPMS/libnbd-1.17.1-2.fc39.src.rpm',
'--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOME':
'/var/lib/mock/f39-build-43645279-5233438/root/installation-homedir',
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin',
'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1':
' \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES':
'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 'SYSTEMD_SECCOMP': '0'} and
shell False
DEBUG util.py:442: No matches found for the following disable plugin
patterns: local, spacewalk, versionlock
DEBUG util.py:444: Package coreutils-9.3-1.fc39.x86_64 is already
installed.
DEBUG util.py:444: Package util-linux-2.39-4.fc39.x86_64 is already
installed.
DEBUG util.py:595: Child return code was: 255
...whereas on eg i686, it continues with:
DEBUG util.py:444: Package coreutils-9.3-1.fc39.i686 is already installed.
DEBUG util.py:444: Package util-linux-2.39-4.fc39.i686 is already
installed.
DEBUG util.py:442: warning: (null): notification message: recovered 669
frames from WAL file
/var/lib/mock/f39-build-43645278-5233438/root/var/lib/dnf/history.sqlite-wal
DEBUG util.py:444: Dependencies resolved.
[...]
DEBUG util.py:444: Complete!
DEBUG util.py:595: Child return code was: 0
So that's 'dnf builddep' failing but *why*...
(the "recovered 669 frams from WAL" message in the successful i686 build
doesn't seem entirely healthy either)
- Panu -
___
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: What is Fedora?
On 22/06/2023 10:11, Daniel P. Berrangé wrote: Nothing described in that blog post above changes this process, so what's written there doesn't have any direct impact on Fedora. Yet. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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: What is Fedora?
Dne 22. 06. 23 v 0:11 Philip Wyett napsal(a): One mage saying Download/Signup One image when you click on download at no cost and you need to login or create an account. Beauty of using clean VM's https://pasteboard.co/eCfDDb13IIOL.png https://pasteboard.co/AXwSb6XWmeTN.png So you create account and proceed. What is the problem? -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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: What is Fedora?
On Wed, Jun 21, 2023 at 04:26:35PM -0400, Gerald Henriksen wrote: > On Wed, 21 Jun 2023 21:06:40 +0100, you wrote: > > >Hi all, > > > >Obviously many will have seen: > > > >https://www.redhat.com/en/blog/furthering-evolution-centos-stream > > > >and see, where EL (contributors like you of fedora/EPEL) have been knocked > >down: > > > >https://bugzilla.redhat.com/show_bug.cgi?id=2215299 > > > >Let us face it our efforts with the Fedora project are not valued and it is > >a means nothing to the > >new corporate IBM/Red Hat enterprise systems that we have to struggle to get > >access to srpms, to > >make a community. What is community now to Red Hat? > > My interpretation of the blog post, combined with recent actions > towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as > the new "Fedora" for basing future versions of RHEL. IMHO this is a mis-reading of the above blog / general situation. The flow of development for future versions of RHEL is absolutely still originating in Fedora, where Rawhide feeds into ELN (Enterprise Linux Next), which then becomes the next major RHEL release. Fedora -> ELN -> RHEL-$NEXT Nothing described in that blog post above changes this process, so what's written there doesn't have any direct impact on Fedora. If you look at rawhide / eln branches in Fedora dist-git today you can see ongoing changes in many packages that will feed into RHEL-10. CentOS Stream is *not* the new Fedora. Fedora remains critical to future RHEL. CentOS Stream is the development path *within* a major RHEL release eg CentOS Stream 9 ---> | || V VV RHEL-9.1.0 RHEL-9.2.0 RHEL-9.x.0 | || | || V VV The main effect of the blog post I see is that the bug fixes / CVEs that go into RHEL-9.1.z, 9.2.z, 9.x.z streams are no longer going to be freely available - only the initial content of each poinmt release in available from CentOS Stream. This doesn't impact Fedora, but will certainly impact the various RHEL rebuilds whether community based (AlmaLinux, Rocky Linux), or fully commercial (Oracle OEL). Those distros can still provide the initial point releases, but will have to do all the work to figure out backports for bug fixes/CVEs/etc within the release. This is going to be a serious burden for those distros. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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
What's the error in this build?
https://koji.fedoraproject.org/koji/taskinfo?taskID=102443065 I don't see what the error is ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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: What is Fedora?
On 6/22/23 06:21, Gordon Messmer wrote: On 2023-06-21 13:06, Philip Wyett wrote: https://www.redhat.com/en/blog/furthering-evolution-centos-stream ... I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products? I don't think this is a major change from the status quo. In the past, Red Hat has published a subset of the git repositories used to create RHEL. They have published spec and patches used to create the current minor release of each major, but nothing from the EUS or SAP support periods. That is, they haven't published any updates to any branch other than the latest branch they publish. There is only one available branch at any time. Now that Stream is available, the same thing is (apparently) true. At least, as best as I understand their announcement. There will be just one available branch, and that branch will contain the spec and patches used to create the latest packages. That's how I understand it well and I'm a bit confused what's the "fuss" about. The git.centos.org mirrored sources that were used to build CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, the same is true - the sources are still available, just at different location [0]. So this doesn't seem like RH is "locking things down", just getting rid of things that are not needed anymore. Note that I'm in a no way endorsing the change, I'm just trying to understand what's the big deal (if there's any). [0] https://gitlab.com/redhat/centos-stream/rpms [1] https://vault.centos.org/centos/8-stream/ -- Frantisek Sumsal GPG key ID: 0xFB738CE27B634E4B ___ 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
