Taking weak dependencies into account during ordering has caused a noticeable
wave of dependency loop caused install failure bug reports at least in Fedora.
This is counter-productive: weak dependencies are commonly used to introduce
more exotic / heavier dependencies to packages without causing
While investigating #2519 I realized that we're running the entire test-suite
as root. That's not how rpmbuild is intended to be used, and masks various
permission issues real-world users have, such as that #2519 which is not
reproducable in the test-suite because of this.
Adding a user to the
Yup, good point. I think we should actually make the `rpmtests` script (which
runs in the podman container) run as a regular user there. The individual tests
aren't supposed to write to the root filesystem anyway (which we prevent by
making it read-only) so being root shouldn't be necessary eith
Bonus point - `runroot` will finally live up to its name :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024750126
You are receiving this because you are subscribed to this thread.
Message ID: ___
Sounds like a plan :+1:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024754579
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-main
@keszybz commented on this pull request.
Looks nice.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built r
Details in the commit messages, but in short: packages can leave unremovable
files in their build directory, run %_fixperms before and after to ensure
sufficient permissions to remove %builddir.
%clean is redundant since 9d35c8df497534e1fbd806a4dc78802bcf35d7cb, drop
default %clean sections and
FWIW, I revived my rpm-snapshot repository where you can get Fedora compatible
builds from rpm git:
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ so if folks want
to try this out before the soon-to-be-released 4.20 alpha, there goes.
--
Reply to this email directly or view it
I certainly remember seeing that code, but never quite got what it actually
refers to. I doubt anybody knows of it, really.
It'd be a lot more useful if it permitted multiline macros. People seem to be
widely abusing %{expand:...} (probably without fully realizing the
consequences) to get the m
Looks fine to me, thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2993#issuecomment-2025086199
You are receiving this because you are subscribed to this thread.
Message ID: ___
Merged #2993 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2993#event-12280849094
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
This is part of https://fedoraproject.org/wiki/Changes/RPMCoW
The majority of changes are in two new programs:
### rpm2extents
Modeled as a 'stream processor'. It reads a regular .rpm file on stdin,
and produces a modified .rpm file on stdout. The lead, signature and headers
are preserved 1:1
Particular use case: I'd like to be able to query a spec file for the list of
its patches. Currently (on Fedora 39's 4.19.1) this is only possible using
`rpmspec --shell` but it requires parsing the output:
```
❯ echo '%patches' | rpmspec --shell ./*.spec
RPM version 4.19.1.1 macro shell
> %patc
This would be tremendously useful, especially for me trying to dig through
really complex packages... Some of them are just not able to be intuited by
reading, and being able to probe them like this would be really useful!
--
Reply to this email directly or view it on GitHub:
https://github.com
> As such, moving to C++ now will probably make it harder to move to Rust later.
Well, maybe. My original comment here remember was about how we very
intentionally moved rpm-ostree to "C compiling as C++" explicitly to bridge
with cxx.rs. This...kind of worked in some ways, and definitely didn
15 matches
Mail list logo
