Re: What happened to the dnf makecache timer with dnf5?

On 2024-10-21 12:54 AM, Petr Pisar wrote: The service uses --timer option. You cannot have one without the other. The man page describes three behavioral differences when the "--timer" option is used, and it seems to me that the systemd units should be able to provide two of them (or a reaso

Re: What happened to the dnf makecache timer with dnf5?

I've opened https://bugzilla.redhat.com/show_bug.cgi?id=2319828 and https://src.fedoraproject.org/rpms/dnf5/pull-request/86 for further discussion of a temporary fix.  I'll follow up with a PR on the dnf5 project shortly. -- ___ devel mailing list --

Re: What happened to the dnf makecache timer with dnf5?

On 2024-10-18 1:32 AM, Petr Pisar wrote: V Thu, Oct 17, 2024 at 10:05:49AM -0700, Gordon Messmer napsal(a): dnf < 5 includes /usr/lib/systemd/system/dnf-makecache.service and ".timer" to ensure that metadata is usually already cached when users run dnf. I don't see any ma

What happened to the dnf makecache timer with dnf5?

dnf < 5 includes /usr/lib/systemd/system/dnf-makecache.service and ".timer" to ensure that metadata is usually already cached when users run dnf. I don't see any makecache service or timer in any of the dnf5 packages on Fedora 41.  Is that intentional, or is it a regression?  I can't tell, be

Re: dnf5 can't remove some qemu packages on rawhide

On 2024-08-06 8:17 AM, Petr Pisar wrote: I reported it upstrean . Thank you all very much! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-

dnf5 can't remove some qemu packages on rawhide

root@localhost:~# dnf install kiwi-cli ... root@localhost:~# dnf5 remove kiwi-cli Failed to resolve the transaction: Problem: The operation would result in removing the following protected packages: grub2-efi-ia32, grub2-efi-x64 root@localhost:~# rpm -q dnf5 rpm dnf5-5.2.5.0-2.fc41.x86_64 rpm-

Re: Following up on: Three steps we could take to make supply chain attacks a bit harder

On 2024-07-31 9:40 AM, Michael Catanzaro wrote: On Wed, Jul 31 2024 at 09:23:12 AM -07:00:00, Kevin Fenzi wrote: Some possible ones I'll toss out there: avahi-daemon cups rsyslog dovecot cockpit Maybe gnome-remote-desktop? Those all sound good to me.  I'll work on opening some more PRs t

Re: Following up on: Three steps we could take to make supply chain attacks a bit harder

tl;dr: Quick update, and one question: Are there other packages that should be monitored? On 2024-06-24 9:03 PM, Gordon Messmer wrote: (As a topic for later: the tirpc library exports functions with the same name as functions that appear in libc, so the behavior of erroring on duplicate

sudo broken in rawhide rpm-sti-test -- blocking openssh security patches

OpenSSH has been FTBFS in Rawhide for a while, and I've tracked that to a recent change intended to make tests execute faster.  I've opened a PR to fix that, and that PR fixes the problem it targeted, but there is another unrelated problem. OpenSSH's rpm-sti-test fails, and it looks like somet

Re: Following up on: Three steps we could take to make supply chain attacks a bit harder

On 2024-06-26 5:42 PM, Gordon Messmer wrote: On 2024-06-25 10:37 AM, Kevin Fenzi wrote: I wonder if this wouldn't fit in as a CI test? Do you mean https://docs.fedoraproject.org/en-US/ci/generic_tests/ ? Maybe it would?  If I misunderstand this, please correct me: Because Fedora use

Re: Following up on: Three steps we could take to make supply chain attacks a bit harder

On 2024-06-25 10:37 AM, Kevin Fenzi wrote: I wonder if this wouldn't fit in as a CI test? Do you mean https://docs.fedoraproject.org/en-US/ci/generic_tests/ ? Maybe it would?  If I misunderstand this, please correct me: Because Fedora uses "-z,relro" and "-z,now" in %build_ldflags, all bina

Re: Following up on: Three steps we could take to make supply chain attacks a bit harder

On 2024-06-24 10:34 PM, Alexander Bokovoy wrote: On Пан, 24 чэр 2024, Gordon Messmer wrote: (As a topic for later: the tirpc library exports functions with the same name as functions that appear in libc, so the behavior of erroring on duplicate symbols needs to be rationalized.  Maybe an

Following up on: Three steps we could take to make supply chain attacks a bit harder

Now that I've packaged the GEF gdb extension (package "gdb-gef" in Rawhide) which provides the "got-audit" command, I wanted to ask again whether there's interest in monitoring critical packages for signs of GOT tampering. The "got-audit" gdb command examines a running process to print a list

Re: Review swaps anyone?

On 2024-06-18 12:56 PM, Peter Lemenkov wrote: Is anyone willing to swap reviews? I haven't conducted any reviews yet, but this is probably a good chance to learn. I can swap for a review of https://bugzilla.redhat.com/show_bug.cgi?id=2276821 -- ___

Review request: gdb-gef

https://bugzilla.redhat.com/show_bug.cgi?id=2276821 GEF is a Python GDB extension that I'd like to use to add tests to monitor and detect GOT poisoning attacks, such as the one used in the liblzma attack.  For example, this proof-of-concept test for openssh: https://src.fedoraproject.org/rpms

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-04-04 06:10, Zbigniew Jędrzejewski-Szmek wrote: +1. I put the tool on my TODO list of things to look into. When you get that time, I've also opened the following PR that includes a proof-of-concept test https://src.fedoraproject.org/rpms/openssh/pull-request/73 It's sloppy at the m

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On 2024-04-03 14:27, Kevin Kofler via devel wrote: I am not sure I buy this argument. By the same argument, we should also not call the OS "Fedora Linux" because it implies there is also a "Fedora BSD" or "Fedora Hurd" or even "Fedora Windows" 😉 or something. Personally, I think the reason we

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On 2024-04-03 11:35, Andreas Tunek wrote: From Red Hat's POV it is not Fedora Gnome Workstation (https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/). I think this gets to the heart of the issue.  If we set aside subjective arguments about which desktop

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-04-01 23:59, Gordon Messmer wrote: On 2024-03-30 13:18, Gordon Messmer wrote: The write up describing the back door indicates that the malicious xz library "changes the value of rsa_public_decr...@plt to point to its own code."  So the back door has pointed one of the sy

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-03-30 11:52, Dmitry Belyavskiy wrote: We have an upstream-adjusted version of this patch, see https://bugzilla.mindrot.org/show_bug.cgi?id=2641 I'm OK to bring the updated version of this script to Fedora as soon as it is finalized. I proposed https://src.fedoraproject.org/rpms/open

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-04-02 03:42, Lennart Poettering wrote: Also, I don't think we should get hung up too much on the libsystemd thing. I know people like to hit on systemd, I know, and one of the problems that results from having just a torrent of undeserved criticism is that it naturally predisposes the

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-03-30 09:12, Neal Gompa wrote: Note that dlopen() doesn't fix the problem of the giant libsystemd in the first place. It just obfuscates the true dependency graph of libsystemd. This isn't my area of expertise, but I am curious: Why doesn't dlopen() solve the problem?  As best I under

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-04-01 23:59, Gordon Messmer wrote: Now gdb can print the GOT with the paths providing the memory section containing a function.  For example, on a Debian 12 system with liblzma 5.6: Purely as trivia, and as I haven't seen it discussed elsewhere, the malware steals a differen

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-03-30 13:18, Gordon Messmer wrote: The write up describing the back door indicates that the malicious xz library "changes the value of rsa_public_decr...@plt to point to its own code."  So the back door has pointed one of the symbols that should point to a page

Re: Three steps we could take to make supply chain attacks a bit harder

On 2024-03-30 02:37, Richard W.M. Jones wrote: (3) We should have a "security path", like "critical path". sshd is linked to a lot of libraries: I really don't want to start a systemd thread, but... the xz, lz4, and zstd libraries are pulled in by libsystemd, merely so that sshd can call "s

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

On 2023-06-25 14:29, Dominik 'Rathann' Mierzejewski wrote: The FOSS licenses give you the right to share the SRPMS, sans the Red Hat trademarks. The GPL, specifically, might guarantee that right, but not all of the distribution is under the terms of the GPL.  I don't have a license count for

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

On 2023-06-24 06:53, Chris Adams wrote: Once upon a time, Neal Gompa said: I will also point out that CentOS Stream is perfectly suitable for production use Is it? At one point, there were considerable gaps in security updates; CentOS delayed security updates for 6-8 weeks, twice a year, e

Re: What is Fedora?

On 2023-06-21 13:26, Gerald Henriksen wrote: 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. I think that's ... kind of true, in a good way. I don't know

Re: What is Fedora?

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

Re: Fedora 38 Workstation boot time and memory improvements

On 2023-04-14 01:28, Michael J Gruber wrote: Interesting. Can you pin down from you analysis where the difference comes from, especially in user-space? I'm asking for a friend 😄 The boot time improvements came from removing iscsi from the critical path.  There's no longer a dependency on net

Fedora 38 Workstation boot time and memory improvements

I didn't mention this in time to even discuss whether it'd make a good addition to the release notes, but I think users will be happy to see that Fedora 38 Workstation boots faster and uses less baseline memory (measured from a session logged in to GNOME with only a terminal application running

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-25 21:52, Gordon Messmer wrote: But, with regard to the bug: offhand, if this is a bug, it seems like a bug in the koji CI scripts and not in rpminspect, doesn't it? Where would I find the definition of the "fedora-ci.koji-build.rpminspect.static-analysis" stage fo

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-22 02:47, Petr Pisar wrote: V Mon, Feb 20, 2023 at 11:48:26AM -0800, Gordon Messmer napsal(a): First, the bug.  From these results, it looks like rpminspect is only comparing the primary package to the old build.  I do see a result for the package "nghttp2", but I do

Re: Proposal: drop delta rpms (for real this time)

On 2023-02-21 12:48, Matthew Miller wrote: I was asked to weigh in onhttps://pagure.io/releng/issue/7215 as a priority. Last time we talked about this we didn't really get anywhere... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX

Re: Proposal: drop delta rpms (for real this time)

On 2023-02-24 07:42, Robert Marcano via devel wrote: Does DNF on RHEL for example do something different when --security is involved? Because the RHEL documentation talks about it as a feature to use. Is a lack of metadata for previous updates the problem or the implementation? I don't have

Re: Proposal: drop delta rpms (for real this time)

On 2023-02-23 10:05, Gordon Messmer wrote: Contrary-wise: Because Fedora updates only contains the latest built, once a build marked as a security fix is obsoleted by another build, there is no longer any indication that a security issue existed in any version, at which point "dnf u

Re: Proposal: drop delta rpms (for real this time)

On 2023-02-22 10:48, Kevin Fenzi wrote: On Wed, Feb 22, 2023 at 05:38:23AM +0100, Kevin Kofler via devel wrote: I remember that in ancient times (pre Core-Extras Merge), some Fedora repository (IIRC, the old Fedora Extras) used to ship not only the latest build for each package, but the TWO lat

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

I wanted to sum up my understanding of the thread so far, and changes I intend to work on: The current implementation generates a version if the library's full name ends with ".so." followed by numbers separated by dots. After discussion, it seems like a more logical approach is to ensure that

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-22 19:17, Kevin Kofler via devel wrote: I see the value of the proposal, but I am worried that it may run into issues with upstream packages using very weird library version numbers, so I am not yet convinced that it is really a good idea.I In case it helps: I started with the filel

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-21 20:19, Kevin Kofler via devel wrote: It is generally unsafe to assume the version number to be in any specific format. I'm not sure if that means that you are opposed to the proposal, or to the idea of truncating the version numbers, or something else entirely.  :) you can a

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-21 08:57, Gordon Messmer wrote: If it were an addition, we have the option of making the system more compatible with existing packages than the current proposal by using a rich dependency. ...I forgot to mention: I also wonder what adding a new dependency would do to the memory

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 11:48, Gordon Messmer wrote: Looking at this result, I think I see one bug and one RFE. Should I report those in bugzilla, and if so, against what component? I want to add: If someone points me toward the right repo, I can work on both of those

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 10:01, Richard W.M. Jones wrote: Does it have to be something which looks so much like it might be a version number? For example it could be helpful for debugging if the generated requires was something like: Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1 or: Requires

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 12:57, Ben Beasley wrote: This is one of the C libraries, which have a more conventional integer ABI version. For the C++ libraries, have a look at the grpc-cpp subpackage. You will find libraries like: libgrpc++.so.1.48()(64bit) I see.  That also looks like it's compatible wi

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 11:32, Ben Beasley wrote: The grpc C++ libraries have CMake SOVERSION e.g. “1.48” for the 1.48.x minor release. There is no attempt at ABI compatibility across minor releases, and the entire string “1.48” is effectively a major version for ABI purposes. The “patch” relases of grp

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

As there is some discussion of whether the ELF dependency generator should use the full version string presented by the library file name's suffix, or should assume a SemVer-style major.minor and truncate the requirement to the first two dot-separated numbers, questions about rpminspect come to

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 02:06, Petr Pisar wrote: I applaud the struggle for ensuring compatibility. However, I worry that it will make downgrading RPM packages less feasible. Imagine a user who updates a system, finds a regression in a library, attempts to downgrade the library and it will result into down

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 10:01, Richard W.M. Jones wrote: Does it have to be something which looks so much like it might be a version number? For example it could be helpful for debugging if the generated requires was something like: Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1 You mean the

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 02:16, Daniel P. Berrangé wrote: You mention 'libtool' multiple times through this thread. libtool defines specific semantics for 3 digits in the version number. Not all shared libraries are built with libtool, and even those which did use libtool didn't neccesarily apply libtool's

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-20 03:08, Florian Weimer wrote: * Gordon Messmer: As you noted at the end of your message, that would involve querying the rpm DB from the ELF dependency generator, which the rpm maintainers want to avoid. Not really. We could dump an extract of the RPM database to a text file at

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-19 12:30, Stephen Smoogen wrote: > - You mention "over the course of two releases" but don't mention what >    is done in each one? I don't know the specifics of how package builds are ordered in a mass rebuild, so I tend to think the safest rollout is a slow

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-19 05:15, Björn Persson wrote: Gordon Messmer wrote: If a maintainer enabled the _elf_require_fallback_versions macro before a mass rebuild where the _elf_provide_fallback_versions macro had been enabled globally, then the resulting package would have versioned dependencies, and the

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-19 04:19, Reindl Harald (privat) wrote: Am 19.02.23 um 00:26 schrieb Gordon Messmer: *: I have to guess that this mariadb-libs package "Provides: libmysqlclient.so.18()(64bit)"... please tell me if you mean something else. is explained the point is "mari

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 15:53, Fabio Valentini wrote: I see a big hole in that problem (assuming that I understand Things correctly): What happens to packages where this .so.x.y.z pattern does not match their actual version? In this implementation, there is no relationship between the version of the s

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 14:23, Reindl Harald (privat) wrote: Am 18.02.23 um 22:58 schrieb Gordon Messmer: On  2023-02-18 03:59, Reindl Harald (privat) wrote: sounds horrible because Obsoletes/Provides in noarch-packages won't be longer enough to override useless dependencies Can you provi

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 03:59, Reindl Harald (privat) wrote: Am 18.02.23 um 06:08 schrieb Gordon Messmer: The point where compatibility becomes an issue is the use of old packages or third-party packages that don't Provide versioned virtual packages to fulfill the requirements of Fedora pac

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 12:19, Björn Persson wrote: Gordon Messmer wrote: In order to enable the requires feature on a single package (without a mass rebuild in between), the maintainer would need to ensure that all of the package's dependencies had been build after the provides feature was enabled

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 10:33, Kevin Fenzi wrote: - What Fedora release(es) are you targeting here? I'd appreciate guidance from more senior project members on that point. - You mention "over the course of two releases" but don't mention what is done in each one? I don't know the specifics of ho

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 04:40, Björn Persson wrote: The Detailed Description describes the problem thoroughly, but fails to describe the solution. Thanks. I'll make sure that it does before formally proposing it, assuming that we proceed to that point. Unanswered questions include: · What exactly

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-18 08:23, John Reiser wrote: About once per year I find it necessary or convenient to use /usr/bin/alien (provided by Fedora package alien-8.95-18.fc36.noarch, for instance) to import one or more Debian .deb package into Fedora as .rpm. I don't see how this could work with the propose

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

On 2023-02-17 20:14, John Reiser wrote: On 2023-02-18 @ 03:03 UTC, Gordon Messmer wrote: use libtool-style versions collected from library filenames to provide versioned library requirements How does this affect the output from  "readelf --symbols --version-info foo.o" whic

Feedback wanted for a proposed improvement to RPM's ELF dependency generator

Following a recent thread discussing a reproducible failure caused by mismatched library interfaces, I proposed a change to the RPM ELF dependency generator.  After discussion in the PR, I've provided an implementation suggested by keszybz@ which would use libtool-style versions collected from

Re: libvirt uninstallable (was: Re: Improving Fedora boot time when libvirt is installed)

On 2023-02-06 07:27, Richard W.M. Jones wrote: Why was this line added? + Requires: (fedora-release > 38-0.23 if fedora-release) I suppose it's related to this change in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/096fc7da49de5655db7aad17057e32191f2afe59?branch=rawhide

Re: Will dnf5 be ready by F39?

On 2023-02-02 09:33, Michael Catanzaro wrote: Red Hat is currently planning to port everything we care about that uses PackageKit to use dnfdaemon's D-Bus API. Currently that's gnome-software, gnome-shell, and gnome-initial-setup. (I think that's all we have in Fedora Workstation that depends o

Re: Will dnf5 be ready by F39?

On 2023-02-02 08:16, Miroslav Suchý wrote: Dne 02. 02. 23 v 5:41 Gordon Messmer napsal(a): Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currentl

Re: Will dnf5 be ready by F39?

On 2023-02-02 01:49, Neal Gompa wrote: Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API? https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5 Well, having it supported in PackageKit is certainly part of the plan once i

Will dnf5 be ready by F39?

On 2023-02-01 13:38, Zbigniew Jędrzejewski-Szmek wrote: #2870 Change proposal: Replace DNF with DNF5 https://pagure.io/fesco/issue/2870 APPROVED (+6,0,-0) (Fixed the link above) The change proposal calls for dnf5 to be ready by the time that F39 is branched, on Aug 8 of this year. Right no

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

On 2023-01-29 00:00, Zbigniew Jędrzejewski-Szmek wrote: The version doesn't have to be major.minor.micro, though.  The dependency generator only needs to get the version of the package that provides the .so, and use that version.  As long as changes within a so version are always backward compati

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

On 2023-01-28 15:23, Fabio Valentini wrote: If I understand things correctly, this is not entirely true. RPM generates a dependency for the soname / soversion, and some projects include not only X, but all of X.Y.Z in that, which RPM will happily generate Provides / Requires for $ ls -l /lib64

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote: ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the version of the package that provides libfoo.so.2 in the build root, which is an idea that's growing on me. This is indeed a shortcoming in the rpm symbol dependency g

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

On 2023-01-28 10:22, Gordon Messmer wrote: In order for rpm to do this, you'd probably have to throw out the current implementation of dependency resolution that provides "libfoo.so.2()(64bit)" and instead provide a dependency like "(foo-libs >= 2.4 with foo-libs

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

On 2023-01-28 00:14, Bruno Wolff III wrote: If there is a problem with not uodating dependencies when you do an install or an update on selected packages, the packages dependencies are not properly defined. By definition, yes.  But rpm auto-detects dependencies, and rpm doesn't do symbol-lev

Proposal: dnf should offer to update all of the dependencies of any package installed or updated

I recently helped another user repair their Fedora workation, after an update broke gnome-shell. In their case, I believe that the problem occurred because they had the nodejs:14 module enabled, which contained an outdated libnghttp2 [1], but in principle, the problem can affect any system tha

Re: [Test-Announce] Heads up: testing requested for significant PackageKit update

ensure all the previously- encountered problems were solved, but of course it's *possible* they missed something, or there are some other problems that folks weren't aware of. Yes, except "a few folks" is really just Gordon Messmer. Thanks Gordon. Time will tell if that

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-22 14:35, Gordon Messmer wrote: What do I misunderstand about systemd presets? ... actually, the systemd presets look like they *don't* need to be adjusted. I reverted the change I thought the presets needed, removed the packages, reinstalled, and iscsi-starter ended up en

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-22 10:14, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jan 19, 2023 at 01:48:16PM -0800, Gordon Messmer wrote: On 2023-01-19 00:55, Lennart Poettering wrote: hat you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 00:55, Lennart Poettering wrote: hat you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. If I'm not mistaken, this approach would also probably need approval by FESCo, since it'd involve reverting the "def

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 09:48, Daniel P. Berrangé wrote: The idea is that an application will put a dep on the specific libvirt-daemon-driver-XXX that its functionality requires. If Boxes requires storage APIs, then add a Requires: libvirt-daemon-driver-storage-core, along with any of the storage backends

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 09:07, Daniel P. Berrange wrote: berrange commented on the pull-request: `Permit an installation of only core storage drivers.` that you are following: `` THis isn't really required. If someone wants to have a fully minimal install of QEMU/KVM, then install 'libvirt-daemon-driver-

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 09:07, Daniel P. Berrange wrote: berrange commented on the pull-request: `Permit an installation of only core storage drivers.` that you are following: `` THis isn't really required. If someone wants to have a fully minimal install of QEMU/KVM, then install 'libvirt-daemon-driver-

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 08:57, Lennart Poettering wrote: On Do, 19.01.23 08:53, Gordon Messmer (gordon.mess...@gmail.com) wrote: Something like that was suggested last year, and Colin Walters objected, for what that's worth. have a link? Last year's thread is here: https://lists.fedorap

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 00:55, Lennart Poettering wrote: What you could do is split up the problem: have iscsi-starter.service or so, that is separate from the iscsi.service main service. The former's job would be to scan if iscsi volumes are configured. If it finds configured ones, it would then issue "s

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-19 01:25, Daniel P. Berrangé wrote: The libvirt packaging is already modular. The 'libvirt-daemon-driver-storage' package is intended to bring in/all/ storage backends libvirt supports. To avoid that, it is possible to depend on 'libvirt-daemon-drive-storage-core' instead which pulls

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-18 11:20, Michael Catanzaro wrote: Several people suggested using a weak dependency (Suggests:) on the iscsi driver, but I don't think that would solve the problem for most users because weak dependencies are installed by default and nothing really communicates to users that unless the

Re: Improving Fedora boot time when libvirt is installed

On 2023-01-18 11:20, Michael Catanzaro wrote: No, Suggests basically does nothing. See this table here: https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/ Recommends and Supplements are real dependencies that are installed automatically but which you can opt out of.

Improving Fedora boot time when libvirt is installed

(apologies for the long-ish message, but I'd like to save people the trouble of re-reading a year-old very long email thread) Early last year there was a thread on this list (Re: "Is NetworkManager-wait-online.service necessary by default?") in which maintainers discussed the issue of boot tim

Re: valgrind on Fedora

On 2023-01-16 05:24, Kalev Lember wrote: On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones wrote: Also make use of suppressions: https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind Also, to add to this, glib2 has a suppressions file you can use to cut down on the false positiv

Re: valgrind on Fedora

On 2023-01-16 01:38, Tom Hughes wrote: I suspect this is a result of libraries being opened and closed dynamically... Try using --keep-debuginfo=yes to make valgrind cache debuginfo for libraries that have been closed. Yes, that was it.  I did not know this about valgrind.  Thank you! I'll r

Re: valgrind on Fedora

On 2023-01-16 00:31, Tom Hughes via devel wrote: On 16/01/2023 08:12, Florian Festi wrote: Have you installed the debuginfo packages for the packages involved? See man debuginfo-install Making sure debuginfod fetching works should also do it as valgrind has support for that. I've tried this

valgrind on Fedora

I'm working on reducing memory use in packagekitd, and so far progress has been very good.  I've opened 4 memory-related PRs against PackageKit and libdnf this week, and locally I've reduced memory use at idle by almost 90% (I can reliably cause stock packagekitd to use ~ 700MB of RAM in a coup

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-30 06:41, Eike Rathke wrote: Maybe I misunderstood. So you're agreeing that once Thunderbird does not support the N-1 ESR anymore then rebasing to N is wanted on release branches? Yes.  In really explicit detail, see the message I sent at 2022-11-27, 23:42 (Pacific). _

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-28 08:51, Adam Williamson wrote: I'm not sure I agree with this, because practically speaking, there's very little "oversight" of anything in Fedora. Is that a disagreement, though?  When I say that packages are allowed to update without oversight, what I mean is that while the pol

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-28 07:36, Eike Rathke wrote: I would much prefer to see Thunderbird updated early in Rawhide and releases that are not yet final, but to remain on the older stable version for as long as possible on any Fedora release that had included it. That'd be a problem though because ~every T

Re: Should the policy documents better reflect real package maintenance practice?

As a practical example, if Fedora prefers stability for application packages over early updates, I'd like to use Thunderbird as an example because the upstream vendor supports two releases concurrently for a predictable period of ~ 12 weeks. In practice, maintaining that package might look lik

Re: Should the policy documents better reflect real package maintenance practice?

I'd like to suggest specific updates (I'd feel more like I was contributing to a productive conversation and less like I'm merely complaining), but I'm a little unclear FESCo's point of view. I'll do my best. Given the discussion so far, I feel like Fedora effectively allows at least leaf nod

Re: "rescue" boot entry files are not updated on OS upgrades

If I'm not mistaken, this issue hasn't been resolved... Since the rescue kernel depends to some extent on the kernel modules in the root volume, would the right solution be: - in preuninstall, determine whether the rescue kernel matches the version being removed, and if so, remove it, and then:

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-24 13:26, Stephen Smoogen wrote: It has to do with differing opinions on that and in the first part of the sentence. There is A) Updates should aim to fix bugs, AND not introduce features. B) Updates should aim to fix bugs, and not introduce features. ... Whenever I have talked to F

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-24 09:28, Adam Williamson wrote: The update policy is very keen on discouraging *compatibility-breaking* updates. That's true, it does explicitly discourage compatibility breaking updates.  But it also says "Updates should aim to fix bugs, and not introduce features," and if that'

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-24 05:50, Tomáš Popela wrote: Although not explicitly stated there, Firefox is mentioned as a first example in https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#examples. Also nearly all Firefox and Thunderbird updates there are the security ones there really isn't another

Re: Should the policy documents better reflect real package maintenance practice?

On 2022-11-24 03:13, Michael J Gruber wrote: I guess there's (at least) two ways to understand "stable": - things don't break - things don't change True, but the policy document is explicit about which meaning is intended, reading, "Updates should aim to fix bugs, and not introduce features

  1   2   >