Fedora 39 compose report: 20231103.n.0 changes
OLD: Fedora-39-20231102.n.0 NEW: Fedora-39-20231103.n.0 = SUMMARY = Added images:3 Dropped images: 5 Added packages: 0 Dropped packages:0 Upgraded packages: 2 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 447.51 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 506.88 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-39-20231103.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-39-20231103.n.0.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-39-20231103.n.0.iso = DROPPED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-39-20231102.n.0.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-39-20231102.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-39-20231102.n.0.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-39-20231102.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-39-20231102.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: firefox-119.0-2.fc39 Old package: firefox-118.0.1-7.fc39 Summary: Mozilla Firefox Web browser RPMs: firefox firefox-langpacks firefox-wayland firefox-x11 Size: 433.90 MiB Size change: 3.27 MiB Changelog: * Tue Oct 10 2023 Martin Stransky - 118.0.2-1 - Updated to 118.0.2 * Tue Oct 24 2023 Martin Stransky - 119.0-1 - Updated to 119.0 * Fri Oct 27 2023 Martin Stransky - 119.0-2 - Added fix for mzbz#1861615 Package: nss-3.94.0-2.fc39 Old package: nss-3.93.0-1.fc39 Summary: Network Security Services RPMs: nspr nspr-devel nss nss-devel nss-pkcs11-devel nss-softokn nss-softokn-devel nss-softokn-freebl nss-softokn-freebl-devel nss-sysinit nss-tools nss-util nss-util-devel Size: 13.61 MiB Size change: -2.77 MiB Changelog: * Wed Oct 04 2023 Frantisek Krenzelok - 3.94.0-1 - Update NSS to 3.94.0 * Thu Oct 26 2023 Bob Relyea - 3.94.0-2 - binary compatibility issue with HACL ECC 256 patch. = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Summary/Minutes from today's FESCo Meeting (2023-11-02)
= #fedora-meeting-2: FESCO (2023-11-02) = Meeting started by tstellar at 17:00:45 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2023-11-02/fesco.2023-11-02-17.00.log.html . Meeting summary --- * init process (tstellar, 17:01:06) * #3089 retiring redhat-lsb in Fedora (tstellar, 17:09:08) * LINK: https://github.com/search?q=lsb_release+NOT+language%3AMarkdown&type=code has over 200k results for the record (dcavalca, 17:22:54) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=2055953 (carlwgeorge, 17:33:24) * Next week's chair (tstellar, 17:48:14) * ACTION: Son_Goku will chair next meeting (tstellar, 17:48:36) * Open Floor (tstellar, 17:48:50) * ACTION: Son_Goku will file a ticket so we can continue to discuss a new meeting time. (tstellar, 17:56:00) Meeting ended at 18:00:45 UTC. Action Items * Son_Goku will chair next meeting * Son_Goku will file a ticket so we can continue to discuss a new meeting time. Action Items, by person --- * Son_Goku * Son_Goku will chair next meeting * Son_Goku will file a ticket so we can continue to discuss a new meeting time. * **UNASSIGNED** * (none) People Present (lines said) --- * tstellar (42) * Son_Goku (36) * carlwgeorge (27) * dcantrell (22) * decathorpe (18) * zodbot (15) * michel-slm (12) * nirik (9) * dcavalca (4) * zbyszek (0) * sgallagh (0) * mhroncok (0) * mhayden (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * King_InuYasha (0) * Sir_Gallantmon (0) * Eighth_Doctor (0) ___ 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: Heads up: libunibreak 5.1 update coming to rawhide
On 02-11-2023 11:19, Fabio Valentini wrote: I have an update for libunibreak ready and plan to release that for rawhide in a week (or slightly later). The new version bumps libunibreak from so.3 to so.5. I also intend to drop building for i686. Note: Dropping builds for i686 is technically only allowed to happen without bureaucracy if * and only if* the package is already a leaf package on i686. Dropping i686 builds while package still depend on them is a breaking change that needs to be coordinated better than via side note in an soname bump notification. Duly noted. However, I don't think "side note in an soname bump notification" applies here. There are three dependent packages. One of which is mine. The other two need to be rebuilt and coordinated anyway. And I didn't just "note" dropping i686, I also submitted PRs to that extend and provided a side tag (as mentioned below). Of the three packages, two have already been rebuilt. Should the third not follow suit, I can revert dropping i686 for libunibreak, keeping it for the packages that have already been rebuilt. So, there will still be a win of two leaf packages having dropped i686. The following packages depend on libunibreak: $ fedrq wr -s libunibreak-devel coolreader-3.2.59-6.fc39.src fbreader-0.99.4-12.fc39.src naev-0.10.2-3.fc39.src I will take care of coolreader. I have tested fbreader and naev in Copr [1] and they build fine. I've created f40-build-side-76870 for rebuilding against the updated libunibreak and dropping support for i686. -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: f39 local kernel builds don't install
or quicker: https://bugzilla.redhat.com/show_bug.cgi?id=2239008 ___ 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 local kernel builds don't install
> Just had upstream dev move to f39 and I tried it myself. > .. > grub2-mkrelpath: error: failed to get canonical path of > `/boot/vmlinuz-6.6.0+'. > dirname: missing operand > Try 'dirname --help' for more information. > > this appears to be because I now have /boot/bzImage-6.6.0+ instead of > /boot/vmlinuz-6.6.0+, but I don't see anything upstream that changed, > so I assume it's systemd kernel-install that broke? maybe this: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/K3KP3NXCAW5JC6MDQFHNSBS7XNAEZZEW/ ___ 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 local kernel builds don't install
Just had upstream dev move to f39 and I tried it myself. Building an installing a kernel from Linus now fails make -C /home/airlied/devel/kernel/build \ -f /home/airlied/devel/kernel/linux/Makefile install make[1]: Entering directory '/home/airlied/devel/kernel/build' make --no-print-directory -C /home/airlied/devel/kernel/build \ -f /home/airlied/devel/kernel/linux/Makefile install # INSTALL /boot unset sub_make_done; /home/airlied/devel/kernel/linux/scripts/install.sh grub2-mkrelpath: error: failed to get canonical path of `/boot/vmlinuz-6.6.0+'. dirname: missing operand Try 'dirname --help' for more information. this appears to be because I now have /boot/bzImage-6.6.0+ instead of /boot/vmlinuz-6.6.0+, but I don't see anything upstream that changed, so I assume it's systemd kernel-install that broke? Dave. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Linux 39 Final is GO
The Fedora Linux 39 Final RC 1.5 compose is GO and will be shipped live on Tuesday, November 7th 2023. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2023-11-02/f39-final-go_no_go-meeting.2023-11-02-17.04.html [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-11-02/f39-final-go_no_go-meeting.2023-11-02-17.04.log.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney ___ 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
Re: DNF5: Checking signatures of packages installed out of a repository?
On Thu, Nov 2, 2023 at 1:33 PM Brian C. Lane wrote: > > I think we should: > > * Switch the default local gpg check to true > - this removes surprise when you learn you've been installing > unchecked software for ... years? If they want it, it can be set > back to false by the user. > > * Don't apply the local flag to rpms downloaded from a url by dnf. >Treat them as if they came from a repo. > - users (or me) don't know all the internal paths inside dnf, the > expectation is that a url isn't a local file. This seems like a reasonable default. Does it also make sense to add some CLI UI niceties that: * Let's the user know this check may be skipped with "--nogpgcheck" with a brief explanation of the risk * Allow the user to continue the transaction with only the specific package not being checked, default no -- Jonathan Steffan ___ 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: DNF5: Checking signatures of packages installed out of a repository?
On Tue, Oct 31, 2023 at 04:23:41PM +0100, Petr Pisar wrote: > The nonchecking behavior probably exists to make installing local packages > easy. If DNF5 would insist on checking the signatures, Fedora users would have > to pass --no-gpgchecks option to their "dnf5" commands to override the new > default, or start signing their packages. As always security is not easy. > > Because this an old behavior and some users probably depend on it, enabling > the verification for all cases looks like an abrupt change. > > I would would like to hear your opinion: Should DNF5 start verifying all > packages? Should DNF5 keep ignoring signatures for out-of-repository packages? > Or should rather narrow the verification skip to packages from a local file > system? Any other options? dnf should verify all packages unless the user turns this off. I may have known checks were skipped for local files at one point, but reading this today I was surprised by it. Especially in today's world where instruction tell you to download the rpm and install it manually I think it is important to default to being as safe as possible by default. I think we should: * Switch the default local gpg check to true - this removes surprise when you learn you've been installing unchecked software for ... years? If they want it, it can be set back to false by the user. * Don't apply the local flag to rpms downloaded from a url by dnf. Treat them as if they came from a repo. - users (or me) don't know all the internal paths inside dnf, the expectation is that a url isn't a local file. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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
F40 Change Proposal: Tuned Replaces Power-profiles-daemon (Self-Contained)
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. Wiki: https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon = Tuned Replaces Power-profiles-daemon = == Summary == Tuned and power-profiles-daemon provide a similar function to set and tune the power status of a system. However, the power-profiles-daemon provides limited profiles to configure the power status of a system. In the meantime, tuned provides many power profiles for different kinds of use cases and technologies. Both of them have similar features, if they can be integrated into one, it allows the fedora user to have more options for power settings of their system and benefits the users. In this proposal, we would like to replace power-profiles-daemon with tuned. As far as we know, tuned already provides power profiles for different use cases and power-profiles-daemon provides the basic power profile configuration, such platform_profiles, Intel p-state and AMD p-state. We expected that the user can set those profile, tuned provided through gnome-control-panel. To minimize the information to the user, the power panel would provide a simple and advanced mode to show the power profiles. If the users want to finetune the system, they can switch to the advanced mode themselves. The impact scope will be on the tuned and the power panel since tuned should provide the basic power setting and API as power-profiles-daemon and the power panel should be able to show the power profiles that tuned provides. == Owner == * Name: [[User:smallorange| Kate Hsuan]] * Email: == Detailed Description == This work would like to replace power-profiles-daemon with tuned. Since tuned already provides a wide range of power profiles for different purposes, this allows the user to have more options for configuring the system power profile. As far as we know, tuned provide many kinds of advanced and basic profile for different purposes. Power-profiles-daemon provides the basic power profiles and the profiles can be set to the system through platform_profiles, Intel p-state and AMD p-state. That is simple and clever. However, if the users want to ask for an advanced profile, they need to install another power utility, such as tuned to finetune their system. If the power-profiles-daemon can be replaced with tuned. The users would have a wide range of profiles to finetune the system. If the tuned would be the major power profile management tool, the major impact scope will be on gnome-control-center power panel and tuned itself. Tuned should also provide the new Dbus API to provide the access point to applications. The other is the gnome-control-center power panel. An "Advanced profile" dialog should be made to show advanced profiles to the user. Moreover, the server users need to get used to another command to switch the profiles. The work expects the tuned replaces the power-profiles-daemons to offer a wide range of power profiles to the fedora users. To integrate them, gnome-control-center power panel needs to add an Advanced profile dialog to use those advanced features. Tuned also needs to integrate the original API to ensure compatibility with legacy applications and provide the basic configuration if the user would stay in basic profiles. == Feedback == '''From fedora-devel''' https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B3UJKFOCRAY3BEEPTHVPW4RY5GFBZWHU/#B3UJKFOCRAY3BEEPTHVPW4RY5GFBZWHU 1. The dependency concern. Since tuned is written by Python, that causes a dependency impact on Fedora installation. 2. The power-profiles-daemon API should be ported to tuned to provide the function to the application that uses power-profiles-daemon API, such as gnome-shell and gnome-control-center. '''From the hardware vendor''' Moreover, we discuss it with vendors through the mail. 1. Since tuned covers several kinds of system tuning schemes that allow the vendor to implement their power profile for different devices or workloads. For power-profile-daemon, it only has three profiles to set and every detail setting should be done through the firmware level. If tuned can replace power-profiles-daemon, they can imagine they can develop the profile in a much more flexible manner. == Benefit to Fedora == 1. Benefits the user. The user would have more options to tune their system. 2. Benefits the maintainer. Integrate similar software into one software to reduce the maintenance effort. == Scope == * Proposal owners: * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == Both th
F40 Change Proposal: Ruby 3.3 (System-Wide)
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. Wiki: https://fedoraproject.org/wiki/Changes/Ruby_3.3 = Ruby 3.3 = == Summary == Ruby 3.3 is the latest stable version of Ruby. Many new features and improvements are included for the increasingly diverse and expanding demands for Ruby. With this major update from Ruby 3.2 in Fedora 39 to Ruby 3.3 in Fedora 40, Fedora becomes the superior Ruby development platform. == Owner == * Name: [[User:vondruch| Vít Ondruch]] * Email: vondr...@redhat.com * Name: [[User:mtasaka| Mamoru Tasaka]] * Email: mtas...@fedoraproject.org == Detailed Description == Ruby 3.3 is upstream's new major release of Ruby. Ruby 3.3 adds a new pure-Ruby JIT compiler named RJIT, uses Lrama as a parser generator, and many performance improvements especially YJIT. === RJIT === * Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT. ** RJIT supports only x86_64 architecture on Unix platforms. ** Unlike MJIT, it doesn’t require a C compiler at runtime. * RJIT exists only for experimental purposes. ** You should keep using YJIT in production. === Use Lrama instead of Bison === * Replace Bison with Lrama LALR parser generator === YJIT === * Major performance improvements over 3.2 ** Support for splat and rest arguments has been improved. ** Registers are allocated for stack operations of the virtual machine. ** More calls with optional arguments are compiled. ** Exception handlers are also compiled. ** Instance variables no longer exit to the interpreter with megamorphic Object Shapes. ** Unsupported call types no longer exit to the interpreter. ** `Integer#!=`, `String#!=`, `Kernel#block_given?`, `Kernel#is_a?`, `Kernel#instance_of?`, `Module#===` are specially optimized. ** Now more than 3x faster than the interpreter on optcarrot! * Metadata for compiled code uses a lot less memory. * Generate more compact code on ARM64 * Option to start YJIT in paused mode and then later enable it manually ** `--yjit-pause` and `RubyVM::YJIT.resume` ** This can be used to enable YJIT only once your application is done booting * `ratio_in_yjit` stat produced by `--yjit-stats` is now available in release builds, a special stats or dev build is no longer required. * Exit tracing option now supports sampling ** `--trace-exits-sample-rate=N` * More thorough testing and multiple bug fixes === Other notable changes since 3.2 === * Performance improvements ** `defined?(@ivar)` is optimized with Object Shapes. * IRB has received several enhancements, including but not limited to: ** Advanced `irb:rdbg` integration that provides an equivalent debugging experience to `pry-byebug`. ** Pager support for commands like `ls` and `show_cmds`. ** More accurate and helpful information provided by the `ls` and `show_source` commands. * ext/readline is retired ** Replaced by `reline` that is pure Ruby implementation compatible with `ext/readline` API. * RubyGems and Bundler warn if users require gem that is scheduled to become the bundled gems in the future version of Ruby. == Feedback == == Benefit to Fedora == With a latest release, Ruby language is supporting the newest language features, which enables even faster and easier development of Ruby applications. == Scope == * Proposal owners: ** Finish packaging of Ruby 3.3. Current changes available in PR https://src.fedoraproject.org/rpms/ruby/pull-request/159 ** Rebuilding of Ruby packages providing native extensions (i.e. packages which depends on libruby). * Other developers: ** Rebuild of packages with binary extensions (i.e. packages which depends on libruby) will be handled automatically, but some packages might need fixes/updates to support Ruby 3.3 properly. * Release engineering: [https://pagure.io/releng/issue/11753 #11753] < ** The packages are going to be rebuild in side-tag, but that does not need releng involvement nowadays. * 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 == * User specific Ruby binary extensions need to be rebuild. * Ruby packages/application dependencies might need to be adjusted if newly bundled gems are used. == How To Test == * No special hardware is needed. * To test, install Ruby 3.3. The test builds are published in PR or on Ruby-SIG ML * Try to locally rebuild your packages using Ruby 3.3. * Use the packages with your applications previously written in Ruby. * If something doesn't work as it should, let us know. == User Experience == The Ruby programs/scripts should behave as they were used to. == Dependencies == $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq | wc -l 134 == C
Schedule for Thursday's FESCo Meeting (2023-11-02)
Following is the list of topics that will be discussed in the FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2023-11-02 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: KDE Plasma 6 https://pagure.io/fesco/issue/3086 APPROVED (+6, 0, 0) Updates policy exception request for Macaulay2 stack in Fedora 39 https://pagure.io/fesco/issue/3088 APPROVED (+7, 0, 0) = Followups = = New business = #3089 retiring redhat-lsb in Fedora https://pagure.io/fesco/issue/3089 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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: DNF5: Checking signatures of packages installed out of a repository?
On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote: > > On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote: > > > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote: > > > > > > > > FWIW, from what I can recall, yum used to check all packages, but this > > > > resulted in tons of people complaining because they did not want it to > > > > check their local packages. So, a localpkg_gpgcheck option was added and > > > > set to false. dnf4 still has this option. > > > > > > I wasn't aware of that change in behavior. I can't find that option > > > documented in the man page for dnf or any other readily available docs > > > about dnf in my installation, or present in my dnf.conf file. I don't > > > > Odd. It's in the dnf.conf man page here in rawhide: > > > > "localpkg_gpgcheck > > boolean > > > > Whether to perform a GPG signature check on local > > packages (packages in a > > file, not in a repository). The default is False. This > > option is subject to > > the active RPM security policy (see gpgcheck for more > > details). > > " > > > > Looks like it was added to yum 13 years ago: > > https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115 > > This is pretty badly documented. I'm pretty sure that most people will > not guess that any URL qualifies as "in a file". > > The approach to security nowadays is much stricter than 13 years ago… > I think we should revisit this decision. > > > > remember anybody ever complaining, certainly not "tons of people". > > > > This was 13-14 years ago. > > > > > Using local RPMs is a pretty rare thing. I can't imagine too many > > > people complaining about this. It was never much of a burden, and to > > > the extent that it was, it was a burden that was a worthwhile tradeoff > > > for increased security. > > > > I'm just relaying the history here... > > > > > It's also not clear when this option would take effect. Would it take > > > effect if I did `dnf install /path/to/local/file` or just when I did > > > > no, because that looks up that file in your repos and downloads the repo > > version of the package. > > > > > `dnf localinstall /path/to/local/file`? What if I did `dnf > > My vote would be: > 'dnf install /path/to/file' default to warn-but-allow (*) I don't think any "warn-but-allow" option is sufficient. The warning comes too late if the transaction is allowed to proceed. By the time the user can react, the installation scripts could have already corrupted the system due to installing a malicious or corrupted package, and possibly in a way that prevents them from reacting at all to the warning. > 'dnf install https://some.url/' default to an enforcing check > > For files outside of a repo, the current set of keys registered > with rpm should be used. A valid-signature-with-unknown-key must be > rejected when the check is enforcing. > > If such fine-grained policy is not possible, then I think > defaulting to requiring explicit --nogpgcheck would be better > than status quo. > > (*) I think that 99% of the time when you're doing a local install > like that, the package was built by the user and it's convenient > to skip the check. I don't know how common it is for people to create their own RPMs, but that's necessarily going to be some subset of all Fedora users. I suspect there are many more users who install RPMs downloaded directly from others where these checks matter more (GPU drivers, Steam repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made from Amazon's DEB using alien, Google Chrome initial installation RPM that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who never build their own RPMs. However, even for those who build their own RPMs, skipping this check is only going to be convenient for those who don't sign their own RPMs... which is a good practice and very easy to do. After all, these signatures don't just protect by authenticating the source of the package, but they also verify the package integrity to protect against file corruption. Whatever inconvenience there is for users who build their own RPMs to add an explicit --nogpgcheck to a command-line, I think that's negligible compared to the benefit to everybody to verify by default. Perhaps the minor inconvenience will encourage those holdouts to adopt a better security posture and start signing the RPMs they build themselves? > > 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
Re: DNF5: Checking signatures of packages installed out of a repository?
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi wrote:
>
> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi wrote:
> > >
> > > FWIW, from what I can recall, yum used to check all packages, but this
> > > resulted in tons of people complaining because they did not want it to
> > > check their local packages. So, a localpkg_gpgcheck option was added and
> > > set to false. dnf4 still has this option.
> >
> > I wasn't aware of that change in behavior. I can't find that option
> > documented in the man page for dnf or any other readily available docs
> > about dnf in my installation, or present in my dnf.conf file. I don't
>
> Odd. It's in the dnf.conf man page here in rawhide:
>
> "localpkg_gpgcheck
> boolean
>
> Whether to perform a GPG signature check on local packages
> (packages in a
> file, not in a repository). The default is False. This option
> is subject to
> the active RPM security policy (see gpgcheck for more details).
> "
You're right. I didn't see it before. I guess I wasn't looking in the
right place. After finding it, though, I will say, the options,
localpkg_gpgcheck, repo_gpgcheck, and gpgcheck, are all still a bit
confusing to me, as currently worded. In addition to revisiting the
defaults, I think there's room for improvement in these docs to make
them more approachable to end users of DNF.
>
> Looks like it was added to yum 13 years ago:
> https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115
>
> > remember anybody ever complaining, certainly not "tons of people".
>
> This was 13-14 years ago.
>
> > Using local RPMs is a pretty rare thing. I can't imagine too many
> > people complaining about this. It was never much of a burden, and to
> > the extent that it was, it was a burden that was a worthwhile tradeoff
> > for increased security.
>
> I'm just relaying the history here...
Understood. Thanks.
>
> > It's also not clear when this option would take effect. Would it take
> > effect if I did `dnf install /path/to/local/file` or just when I did
>
> no, because that looks up that file in your repos and downloads the repo
> version of the package.
That's not what I've seen. I've used this to explicitly install the
Google Chrome RPM before from a local path... before the Chrome repo
was set up, and it did not re-download the RPM from any repo. `dnf
install ./google-chrome-stable.rpm`. I remember this because it was
surprising to me that I didn't need to specify 'localinstall', that
regular 'install' just worked. Ever since, I've assumed that
'localinstall' was just an alias for 'install' and didn't behave any
differently. Perhaps that assumption is wrong, but that appeared to be
the behavior I observed at the time.
>
> > `dnf localinstall /path/to/local/file`? What if I did `dnf
>
> yes.
>
> > localinstall remotepath:/to/remote/file`? All of these work, as it
> > seems "localinstall" and "install" both just work if given a URL,
> > local or remote.
>
> remote path just downloads the file and installs it, so it's the same as
> the last case.
>
> > This option seems poorly rolled out, unclear in function, and overall
> > bad for security.
>
> Well, nothing was rolled out, it's been that way for 13 years.
The way I was using the term "poorly rolled out", I just mean that it
seems the way it was implemented or deployed ("rolled out") was less
than ideal, regardless of when that occurred. Sorry if this wasn't
clear. It's possible we use these terms differently.
> Should it be revisited? Sure, and thats what this thread is for?
+1, and for what it's worth, my intent isn't to complain about
previous decisions, but to offer a critical perspective that can be
used constructively to inform future changes.
> >
> > >
> > > It's also worth noting that if you pass yum/dnf/dnf5 urls for the
> > > package(s) you want to install, it's not using a repo at all, it's
> > > downloading those packages and treating them as local packages.
> >
> > Is this meant to imply that it doesn't do checks by default whenever
> > you pass a URL?! That's even worse! From this user's perspective, a
> > URL pointing to a package in a repo, is just a more fully-qualified
> > way of specifying the shorthand package name. It seems very odd if
>
> But dnf has no way to know https://foo.bar/packagename is in a repo.
> If it is, you should enable the repo and install it with 'dnf install
> packagename'.
That's not clear, because some package managers actually do work this
way, and use the package name to construct a URL from a configured
repo base. Maven2 repository layouts, for example, work by taking an
package artifact specification and using that to construct a
fully-qualified URL for an artifact on a base URL, so the package
artifact spec really is just shorthand for a fully-qualified URL in a
repo. This is also the way a human finds a package manually from the
Fedora 39 compose report: 20231102.n.0 changes
OLD: Fedora-39-20231101.n.0 NEW: Fedora-39-20231102.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-39-20231102.n.0.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-39-20231102.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-39-20231101.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Does a change approved for f39 need reapproval for f40?
On Tue, 31 Oct 2023 at 14:26, Aoife Moloney wrote: > Hi Jonathan, > > Sorry this (among other things Im sure) fell through the cracks while we > were without a Fedora Program Manager :( > Yep, completely understandable. It wouldn't have been a problem if I had started the work sooner! > I will re-announce this on discourse as this is how the process for a > change targeting F40 goes, and open a new ticket to FESCo after about a > week or so, and thank you for cleaning up the wiki, it makes it much easier > to see the discussion surrounding the change from its initial proposal for > F39 by separating it out in the Current Status section. I'll remove the > discussion links, tracker bug and fesco ticket for the F40 section and > re-add with F40 links. > Great, thanks. > > > Kindest regards, > Aoife > > On Mon, Oct 30, 2023 at 3:16 PM Neal Gompa wrote: > >> On Mon, Oct 30, 2023 at 10:55 AM Jonathan Wakely >> wrote: >> > >> > On Mon, 30 Oct 2023 at 14:24, Ian McInerney via devel >> > wrote: >> > > >> > > >> > > >> > > On Mon, Oct 30, 2023 at 2:06 PM Jonathan Wakely >> wrote: >> > >> >> > >> Well it looks like I took too long to do the deferral to F40, and so >> > >> FESCO dropped the change: >> > >> https://pagure.io/fesco/issue/3059#comment-875144 >> > >> >> > >> So now do I need to re-submit as a fresh change for F40? >> > > >> > > >> > > My reading of the email replies to the FESCO minutes when they >> announced this ( >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E3M624WQFJV4L5NCJBA3UC746Z7BWNO5/#TMIPXR25CJR72BUMXHKTVICUKVUU5REM) >> is that they want an entirely new change proposal for it... since they >> apparently didn't think anyone was working on it and that it was completely >> abandoned even though you had emailed that you were working on it. >> > >> > Drat. I finally have some time to pick up the work on it (having >> > inherited the change from trodgers after he left) and now I can't do >> > it! That's kinda annoying, as I had mailed the list about it. I >> > probably should have updated the change to make myself the owner. >> > >> > Fingers crossed I'll still be able to make time for it after it gets >> > re-approved. I'll submit a new change. >> >> If it's substantially the same, just update the wiki page and ask >> Aoife to create the FESCo ticket so we can approve it again. >> >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> >> > > -- > > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > > ___ > 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
Fedora rawhide compose report: 20231102.n.0 changes
OLD: Fedora-Rawhide-20231101.n.0 NEW: Fedora-Rawhide-20231102.n.0 = SUMMARY = Added images:2 Dropped images: 2 Added packages: 4 Dropped packages:2 Upgraded packages: 112 Downgraded packages: 0 Size of added packages: 456.27 KiB Size of dropped packages:126.86 KiB Size of upgraded packages: 5.73 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 272.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231102.n.0.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20231102.n.0.iso = DROPPED IMAGES = Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20231101.n.0.x86_64.vagrant-virtualbox.box Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20231101.n.0.x86_64.vagrant-libvirt.box = ADDED PACKAGES = Package: python-extractcode-7z-21.5.31-1.fc40 Summary: ScanCode Toolkit plugin to use pre-installed 7zip executables RPMs:python3-extractcode-7z Size:17.29 KiB Package: python-extractcode-libarchive-21.5.31-1.fc40 Summary: ScanCode Toolkit plugin to use pre-installed libarchive library RPMs:python3-extractcode-libarchive Size:18.48 KiB Package: python-plugincode-32.0.0-1.fc40 Summary: Plugable functionality with plugins used by ScanCode toolkit RPMs:python-plugincode-doc python3-plugincode Size:133.89 KiB Package: python-spdx-tools-0.7.1-1.fc40 Summary: Python library to parse, validate and create SPDX documents RPMs:python3-spdx-tools Size:286.60 KiB = DROPPED PACKAGES = Package: perl-Math-BigRat-0.2624-500.fc39 Summary: Arbitrary big rational numbers RPMs:perl-Math-BigRat perl-Math-BigRat-tests Size:82.80 KiB Package: rust-json_to_table-0.5.0-2.fc39 Summary: Library for pretty print JSON as a table RPMs:rust-json_to_table+color-devel rust-json_to_table+default-devel rust-json_to_table-devel Size:44.06 KiB = UPGRADED PACKAGES = Package: R-4.3.2-2.fc40 Old package: R-4.3.2-1.fc40 Summary: A language for data analysis and graphics RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath libRmath-devel libRmath-static Size: 319.80 MiB Size change: 10.49 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 4.3.2-2 - Revert adding flexiblas to LAPACK_LIBS as per discussion with Tomas Kalibera Package: R-cli-3.6.1-1.fc40 Old package: R-cli-3.6.0-3.fc39 Summary: Helpers for Developing Command Line Interfaces RPMs: R-cli Size: 5.54 MiB Size change: 99.79 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 3.6.1-1 - Update to 3.6.1 Package: R-digest-0.6.33-1.fc40 Old package: R-digest-0.6.31-2.fc39 Summary: Create Cryptographic Hash Digest of R Objects RPMs: R-digest R-digest-devel Size: 1.16 MiB Size change: 39.81 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 0.6.33-1 - Update to 0.6.33 Package: R-evaluate-0.22-1.fc40 Old package: R-evaluate-0.15-4.fc39 Summary: Parsing and Evaluation Tools that Provide More Details than the Default RPMs: R-evaluate Size: 106.42 KiB Size change: 3.11 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 0.22-1 - Update to 0.22 Package: R-jsonlite-1.8.7-1.fc40 Old package: R-jsonlite-1.8.5-3.fc39 Summary: A Simple and Robust JSON Parser and Generator for R RPMs: R-jsonlite Size: 2.54 MiB Size change: -2.85 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 1.8.7-1 - Update to 1.8.7 Package: R-pkgload-1.3.3-1.fc40 Old package: R-pkgload-1.3.0-4.fc39 Summary: Simulate Package Installation and Attach RPMs: R-pkgload Size: 214.85 KiB Size change: 2.79 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 1.3.3-1 - Update to 1.3.3 Package: R-processx-3.8.2-1.fc40 Old package: R-processx-3.8.1-3.fc39 Summary: Execute and Control System Processes RPMs: R-processx Size: 1.47 MiB Size change: -5.62 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 3.8.2-1 - Update to 3.8.2 Package: R-testthat-3.2.0-1.fc40 Old package: R-testthat-3.1.7-3.fc39 Summary: Unit Testing for R RPMs: R-testthat Size: 6.86 MiB Size change: 357.99 KiB Changelog: * Wed Nov 01 2023 I??aki ??car - 3.2.0-1 - Update to 3.2.0 Package: R-waldo-0.5.1-9.fc40 Old package: R-waldo-0.5.1-6.fc40 Summary: Find Differences Between R Objects RPMs: R-waldo Size: 120.58 KiB Size change: 965 B Changelog: * Wed Nov 01 2023 I??aki ??car - 0.5.1-7 - Fix wrong BuildRequires * Wed Nov 01 2023 I??aki ??car - 0.5.1-8 - bootstrap [skip changelog] * Wed Nov 01 2023 I??aki ??car - 0.5.1-9 - Revert "bootstrap [skip changelog]" Packa
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2023-11-03 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10568/ ___ 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
F40 Change Proposal: DNFConditionalFilelists (System-Wide)
= DNF: Do not download filelists by default = 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. Wiki: https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists == Summary == Change the DNF behavior to not download filelists by default. These metadata, which describe all the files contained within each package, are unnecessary in the majority of use cases. Additionally, these metadata files can be large in size, leading to a significant slowdown in the user experience. == Owner == * Name: [[User:jkolarik| Jan Kolarik]] * Email: jkola...@redhat.com == Detailed Description == Until now, filelists were always downloaded together with other metadata. This was hardcoded and unable to change from the outside of DNF. With these changes, we are proposing to not download the filelists metadata by default. This default behavior can be modified through the new DNF configuration option. Additionally, specific commands can override this behavior and request loading the filelists metadata at runtime using the existing demands object in DNF. Note that after this change, users can still use DNF without filelists metadata when querying file provides located in `/usr/bin`, `/usr/sbin` or `/etc` directories. == Feedback == == Benefit to Fedora == As DNF is integral to various infrastructure tasks like package building and installation, testing environment creation, and server integration tests, this change significantly reduces processing time and resource usage for these processes. This change reduces the RAM requirements of the DNF process, addressing existing issues when running the Fedora system on low-memory machines such as the Raspberry Pi (see f.e. [https://bugzilla.redhat.com/show_bug.cgi?id=1907030 Bug 1907030]). Also, omitting the filelists metadata download overall decreases the costs of a Fedora mirror server operation. == Scope == * Proposal owners: ** libdnf *** Modify the `Repo` object to enable conditional filelists metadata download *** Introduce a new main configuration option to set the default behavior ** dnf *** Enable configuration of filelists download from commandline, DNF commands and DNF plugins *** Implement filename pattern argument detection heuristics * Other developers: ** Dependencies using the existing DNF C interface may need to adapt if they expect the filelists metadata to be available and explicitly request loading filelists using the existing API due to this change: *** PackageKit *** microdnf *** API users * Release engineering: N/A * Policies and guidelines: ** Package maintainers must follow Fedora's packaging guidelines, particularly concerning file dependency specifications (see [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies here]) * Trademark approval: N/A * Alignment with Community Initiatives: N/A (no currently active initiatives) == Upgrade/compatibility impact == In general, applying these changes should not affect any existing user workflows and no additional manual changes are required. However, the absence of filelists might create an issue with packages that are not correctly packaged or originate from third-party repositories. In the current Fedora release repository, there are only a few such packages, see the [https://bugzilla.redhat.com/show_bug.cgi?id=2180842#c8 comment] in [https://bugzilla.redhat.com/show_bug.cgi?id=2180842 Bug 2180842]. == How To Test == When using DNF commands without a filename pattern passed as the argument, filelists metadata should not be downloaded from the remote repositories and should not be needed for the command execution. This can be tested with the following steps: * Clean the local metadata cache (`dnf clean metadata`) * Run a DNF command not involving the filename spec (e.g. `dnf repoquery rpm`) * Verify that no `*-filelists.*` metadata files were downloaded inside the cache subdirectories (by default under the `/var/cache/dnf` for root) * Check the command works as expected The same should also apply to RPM package arguments (files ending with `.rpm` extension). When using DNF commands with a filename pattern passed as the argument, filelists metadata should be downloaded from the remote repositores as before. == User Experience == Large filelists could be over 200MB in size. It could take 1-2 minutes to download which is greatly slowing down the user experience. For many operations the filelists metadata are not needed, so downloading them is wasting the resources. Without filelists being downloaded, DNF performance will be improved significantly, mainly regarding the network, CPU and disk space resources. Metadata download size will be reduced by about 60%. The improvement includes deployments of customer built RPMS to containers that have no need for filelists
F40 Change Proposal: Build Fedora with DNF5 (Self-Contained)
Wiki Link: https://fedoraproject.org/wiki/Changes/BuildWithDNF5 = Build Fedora with DNF 5 = == Summary == We are proposing to change the Mock configuration in Mock (mock-core-configs), Koji, and Copr to use DNF 5 as Mock's package manager instead of DNF 4. DNF 5 would be used by Mock to install build dependencies into chroots for package builds. This change is related to the build infrastructure and is distinct from changing the default package manager in Fedora. == Owner == * Name: [[User:egoode| Evan Goode]] * Email: ego...@redhat.com * Name: [[User:praiskup| Pavel Raiskup]] * Email: prais...@redhat.com == Detailed Description == DNF 5 is a new package manager intended to replace DNF: https://dnf5.readthedocs.io/en/latest/about.html. It offers significant performance improvements over DNF while achieving lower memory usage and disk footprint. The switch to DNF 5 was originally planned for Fedora 39, but it's been postponed to (likely) Fedora 41: https://pagure.io/fesco/issue/3039. In the meantime, we would like to start building Fedora with DNF 5. The set of package management features that Mock needs for setting up buildroots is small compared to the full capabilities of DNF, so it's a good place to start deploying DNF 5. We will be able to test the stability of DNF 5 at a large scale and gather data about its performance. The Mock developers have been working alongside the DNF 5 developers for a while to ensure Mock can use DNF 5, per this tracking issue: https://github.com/rpm-software-management/mock/issues/894. The two remaining items on that issue are "optional" items that are not blocking this proposed change. == Feedback == == Benefit to Fedora == With the switch to DNF 5 as the default package manager on the horizon, the build infrastructure offers an opportunity to subject a crucial subset of DNF 5's features to heavy testing. This change will let us verify that every build dependency in the distribution is installable by DNF 5. In addition, we expect a substantial performance improvement for package builds that spend a significant portion of their time installing build dependencies. Larger, compilation-heavy packages likely won't see much improvement; the difference will be most apparent when building many smaller packages. Switching the build system over to DNF 5 will let us measure the performance improvement over DNF across a wide variety of install transactions. == Scope == * Proposal owners: The work to support DNF 5 in Mock is done already. This change should be as simple as setting the Mock option `config_opts['package_manager'] = 'dnf5'` in Mock, Koji, and Copr for F40+ builds (Koji config option exists from the `yum -> dnf4` era). The `dnf5` doesn't necessarily have to be installed on building hosts - in such a case, Mock will automatically use `/bin/dnf-3` (DNF4) from the host to install DNF5 into the bootstrap chroot, to further use *that* DNF5 for build chroot installation. * Other developers: * Release engineering: https://pagure.io/releng/issue/11737 * 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 == There are no special steps needed to test the change after it happens (updated `mock-core-configs` package is installed on your host), just enjoy the installation speedup. There's a way to test this on Fedora 37+ or EPEL8+ host (builder) in advance. Considering you want to build SRCRPM like `mock -r fedora-40-x86_64 your.src.rpm`, you can do this instead: 1. `mock -r fedora-40-x86_64 --scrub=all` (mandatory step to cleanup DNF4 from all caches) 2. `mock -r fedora-40-x86_64 --config-opts=package_manager=dnf5 your.src.rpm` (DNF5 is installed and cached in bootstrap) 3. `mock -r fedora-40-x86_64 --scrub=all` (to invalidate caches again) == User Experience == This change will mostly be invisible to users. The builds, namely the buildroot preparation, will be much faster. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the F40 Mock configuration in Koji and Copr back to using `dnf` (5-minute work). * Contingency deadline: F40 Beta freeze * Blocks release? Yes == Documentation == == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney ___ 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 __
Re: DNF5: Checking signatures of packages installed out of a repository?
On 11/1/23 17:09, Christopher wrote: On Wed, Nov 1, 2023 at 5:53 AM Paul Howarth wrote: Maybe not using dnf, but you can check it using rpm directly: $ wget mypackage.rpm $ rpm --checksig mypackage.rpm Yeah, that's why DNF is more convenient for this... the whole point of using DNF to install a local file is for consistency of using the same command as for repo packages, not manually altering the RPM database outside of YUM/DNF (that results in a warning), and the expectation of FWIW, dnf doesn't issue any silly warnings about rpm changing its own database, that was a yum thing. - 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: Heads up: libunibreak 5.1 update coming to rawhide
On Thu, Nov 2, 2023, 01:31 Sandro wrote: > I have an update for libunibreak ready and plan to release that for > rawhide in a week (or slightly later). > > The new version bumps libunibreak from so.3 to so.5. > > I also intend to drop building for i686. > Note: Dropping builds for i686 is technically only allowed to happen without bureaucracy if * and only if* the package is already a leaf package on i686. Dropping i686 builds while package still depend on them is a breaking change that needs to be coordinated better than via side note in an soname bump notification. Fabio > The following packages depend on libunibreak: > > $ fedrq wr -s libunibreak-devel > coolreader-3.2.59-6.fc39.src > fbreader-0.99.4-12.fc39.src > naev-0.10.2-3.fc39.src > > I will take care of coolreader. I have tested fbreader and naev in Copr > [1] and they build fine. I've created f40-build-side-76870 for > rebuilding against the updated libunibreak and dropping support for i686. > > Please rebuild fbreader and naev (PRs submitted and maintainers in Cc) > in the side tag to ensure a smooth update. If you prefer, you can also > grant me commit rights and I will take care of rebuilding myself. > > [1] https://copr.fedorainfracloud.org/coprs/gui1ty/libunibreak/builds/ > > Cheers, > -- > Sandro > FAS: gui1ty > IRC: Penguinpee > Elsewhere: [Pp]enguinpee > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: DNF5: Checking signatures of packages installed out of a repository?
V Tue, Oct 31, 2023 at 04:49:30PM -0700, Kevin Fenzi napsal(a): > FWIW, from what I can recall, yum used to check all packages, but this > resulted in tons of people complaining because they did not want it to > check their local packages. So, a localpkg_gpgcheck option was added and > set to false. dnf4 still has this option. > Thanks for bringing this option I did not know about. DNF5 supports it and it also defaults to false. -- Petr 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
