Many things need to be known before the build can be started. Make
declaring these sections or directives an error when encountered parsing
the generated Spec parts.
Resolves: #2693
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-manageme
interesting hack. Would be nice if rpm could do that natively indeed. Would
help a lot to build git head of software based on the spec file of a stable
version. Might actually be doable by breaking the loop in
`processBinaryFiles()` into a two stage process.
--
Reply to this email directly or
I wonder if you need to store the repo file. Just having a name is not of much
use. Especially for yum/dnf where the name is in the local file and can be
changed at will. You will also need to store $release (you obviously already
have $arch) to be able to interpret the links in there.
--
Repl
Originally arches were split, but Liora Milbaum proposed that a single file
would be better as it would guaranteed consistency.
As Liora has background in both Red Hat In-Vehicle Operating System [1] and
Bootc [2] who are both potential candidates for usage of the lock files and
especially [1]
I just want to point out that structure might be vie reversa. Instead
```
- arch: aarch64
repos:
repoid:
packages:
```
To use
packages:
wget:
repoid:
baseos
arch:
x86_64
s390
```
Then I discovered one problem when o
I agree with @ppisar and @pmatilai above, this proposal seems to be sitting one
"floor" above us. We don't deal with repositories or the distribution of
packages in general.
That said, of course, if anything comes out of this discussion that impacts RPM
itself, we're happy to help. Also, like P
> You mean 'rpm --verify'? What errors?
No,
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1952432415
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2828 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#event-11849567215
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Merged #2916 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2916#event-11848850444
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Details in the commits, but basically add a new test group for package format
matters + a test for v4 package format utilizing rpmdump.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2916
-- Commit Summary --
* Split our r
Merged #2915 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2915#event-11848573139
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Yeah this doesn't seem particularly relevant to rpm itself. But if people want
to use this as a depsolver agnostic place to discuss it, you're welcome to do
so.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncommen
We have the list of tests in cmake, we can just as well generate the master
rpmtests.at file from there.
As the order of tests now depends on the list in tests/CMakeLists.txt, update
it to match the former order in rpmtests.at. As arbitrary as that order is,
people seem to get attached to certa
Reading all the fuss with repoid, are you sure you are targeting the right
project (rpm)? `rpm` tool has no notion of repositories. It only works with
locally accessible RPM packages. Even specifying remote RPM packages with an
URL and letting `rpm` tool to download them is, although implemente
Something that occurred to me just now - why does the lockfile contain multiple
architectures? Isn't a purpose of a more-or-less generic lockfile to address a
single use case? IOW the way I'm now looking at the format it looks like
whatever is consuming the lockfile is supposed to prefetch data
@pmatilai requested changes on this pull request.
These are all optional dependencies and must remain that way, some of these
dependencies aren't available outside Linux at all. Without the corresponding
cmake options this is a no-go.
--
Reply to this email directly or view it on GitHub:
htt
Merged #2913 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#event-11847031818
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@mlschroe approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#pullrequestreview-1887945667
You are receiving this because you are subscribed to this thread.
Message ID:
18 matches
Mail list logo
