@dmnks pushed 3 commits.
eb16077ce74cad62c6017aedc7bbae14c154fd5c Replace MKTREE_NATIVE with
MKTREE_MODE in cmake
b2a80b40b15e30405c7d109109971b392972214e Hybrid mode
38f1e0927b27f5a082f60927c1d85b1dc93d8999 Dockerfile
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull
In any case, #2883 is now merged. We can always tweak this later, at least
before the first public release carrying this feature.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2754#discussioncomment-8452948
You are receiving this
Nah, I *was* running it on Ubuntu (by setting up a container manually) :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1941652244
You are receiving this because you are subscribed to this thread.
Message ID: _
OK, I was a bit vague above, so to clarify:
What I did was:
1. Ran an Ubuntu-based container (with `toolbox`)
2. Installed all the RPM deps in it
3. Built the latest RPM checkout in it
4. Created an image from it (with `podman commit`)
5. Ran the test-suite against *that* image (instead of the def
Yup, this is a known issue, see
https://github.com/rpm-software-management/rpm/issues/2355.
The thing is, even if this would be possible to work around, we don't want to
have any such filesystem-specific code in RPM.
Now, thinking about it more, this might in fact be something to handle in an
Right, that is a valid question, although I'm no expert on OverlayFS so can't
really answer that.
The only "explanation" (as to why EXDEV is issued on a `rename(2)` call) that
I've found is the following excerpt from a comment in the OverlayFS
[code](https://github.com/torvalds/linux/blob/v4.8
Looking at the OverlayFS
[docs](https://docs.kernel.org/filesystems/overlayfs.html#renaming-directories)
some more, specifically at the section covering `redirect_dir`, it mentions the
following (emphasis mine):
> return EXDEV error: this error is returned by rename(2) when trying to move a
>
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the atomi
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the atomi
Hmm, it seems like OverlayFS indeed does a full copy up (there's the `metacopy`
feature that only does that for the metadata).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456485
You are receiving this be
OK, having discussed this with the team, let's reopen #2355 and see what we can
do on that front. This issue certainly is something that comes up regularly so
we might as well bite the bullet now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/r
Reopened #2355.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#event-11800812040
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
As per discussion in #2905, reopening now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#issuecomment-1943636423
You are receiving this because you are subscribed to this thread.
Message ID: __
Oh, sure! This looks useful. Please go ahead and submit a PR, we'll take it
from there. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2855#issuecomment-1943638444
You are receiving this because you are subscribed to this threa
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
This is already fixed in the rpm-l10n repo, in the commit
https://github.com/rpm-software-management/rpm-l10n/commit/b4dc72f4b92489f77de9b0ae0bed754875d37ece,
we just need to update the `po` submodule in the main repo to pull that change.
> IMO It would be hoof to add excutinh that target at lea
Oh, and just to clarify, in the case of 4.19.1.1, we did *not* intend to update
the translations in that release at all, which is why this issue wasn't caught
yet.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-19542
Merged #2906 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2906#event-11874927721
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Closed #2890 as completed via #2906.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2890#event-11874927944
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
One thing to keep in mind here is that we'll be getting rid of a shared
BUILDROOT. I've always wondered what the purpose of that (or the shared
`%_topdir` workspace in general) was, but I can think of one use case:
You wish to deploy a common set of packages and/or configuration (a *suite*) to
Which makes me think - couldn't the shared BUILDROOT be useful for actually
building container images? I'm not sure about the advantages over just grabbing
pre-built RPMs to compose the final root filesystem tree, but it does seem like
you'd save a number of redundant steps if you were building
To summarize my above comments a bit, from a higher-level perspective:
In the context of the shared `%_topdir`, an RPM package doesn't necessarily
have to correspond to a single program or piece of software. It's a way to
distribute a "snapshot" or "sub-tree" of the root filesystem. In that cont
Thinking more about it, the shared BUILDROOT use case might actually be
impossible to achieve because of the fact that RPM checks for unpackaged files
in there when building a single package (see the recent discussions around
excludes).
--
Reply to this email directly or view it on GitHub:
htt
While at it, I realized the whole [Runtime
scriptlets](https://rpm-software-management.github.io/rpm/manual/spec.html#runtime-scriptlets)
section needs to be rewrtiten and updated so I'll do that as part of this
ticket.
--
Reply to this email directly or view it on GitHub:
https://github.com/r
@dmnks commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ", sp
Speaking of name bikeshedding,
> Other ponderings include the per-build directory macro name, should it be
> just %builddir without the underscore (instead of %pkgbuilddir)
This has gotten lost in the above chatter, but I think it's worth considering.
It's a macro name that we'll be living with
As for the paths, I think they're fine now, no need to mull over those more,
indeed :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1969297547
You are receiving this because you are subscribed to this thread.
M
Lastly, the `docs/manual/dynamic_specs.md` files needs updating as it mentions
the old SPECPARTS path.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1969341612
You are receiving this because you are subscribed to this
Closed #2655 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2655#event-11996919379
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Let's track this in the respective GH project that already exists for this one:
https://github.com/orgs/rpm-software-management/projects/16/views/1
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2655#issuecomment-1976277991
You are rec
Seems like the test-suite changes have accidentally spilled into the preceding
commit `Print informative messages to stderr, not stdout on --target build`
:smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1976941
@dmnks commented on this pull request.
> if (initialPackage) {
if (checkForRequiredForBuild(pkg->header)) {
goto exit;
}
- char *buildRoot = rpmGetPath(spec->buildRoot, NULL);
- free(spec->buildRoot);
- spec->buildRoot = buildRoot;
- rpm
Yet another practical example from Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2252661
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1346#issuecomment-1978531887
You are receiving this because you are subscribed to this thre
Now with the cmake options in place, this looks fine to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1978795518
You are receiving this because you are subscribed to this thread.
Message ID: ___
That said... This does make the cmake file a bit noisier. I wonder what the
actual use cases are for disabling these (versus just not installing the given
build dependency in the first place, assuming a clean build system or container
is set up for the build).
A quick googling also reveals:
ht
OK, the above cmake feature seems to only work with `find_packages()`, not
`pkg_check_modules()`...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1978815299
You are receiving this because you are subscribed to this thr
> The problem with not installing items is that one can't be certain if they
> are indeed not installed. They can be pulled in indirectly through some other
> dependency, or appear later on after a system update. That happens quietly,
> and will change the way rpm builds. The cmake option on the
One way, I think, is to introduce a special distro-wide obsoleter package.
Example from Fedora:
https://src.fedoraproject.org/rpms/fedora-obsolete-packages. This assumes that
the maintainers of the retired packages update the package manually, though.
--
Reply to this email directly or view it
Oh, just noticed the linked ticket above is actually from the
fedora-obsolete-packages repo :facepalm:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681230
You are receiving this because you are subscribe
> Lets have some package installed on a system, which is already removed from
> the repository. This package might work just fine as long as their
> dependencies are satisfied. But after the dependencies change, the package
> needs to be removed.
A package installed on the system has its depend
I think your question therefore belongs to the DNF layer. In fact,
`--allowerasing` might just be what you're after.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681697
You are receiving this because you
What rpm *could* help with is to e.g. optionally remove a package whose
dependencies can't be satisfied in a given transaction. Basically, an analogy
to `--allowerasing` in DNF. However, I'm not sure if that's really what rpm
wants to support...
--
Reply to this email directly or view it on Gi
This would probably also clash with DNF's own depsolving logic (libsolv).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681813
You are receiving this because you are subscribed to this thread.
Message ID:
Yeah, I'd think that by performing a system upgrade the user explicitly grants
the permission to the package manager (DNF) to remove any unsupported packages
that prevent a complete system upgrade.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/
Whether there's a reasonable replacement for the removed packages is another
thing, a "social" one I suppose. That is, ideally there always are such
replacements (Obsolete-ing the removed package) and if there aren't, that
should somehow perhaps be communicated in the Release notes or similar.
Looking at Fedora's system upgrade guide, there's this:
> If some of your packages have unsatisfied dependencies, the upgrade will
> refuse to continue until you run it again with an extra --allowerasing option.
That's basically what we've discussed so far, it's just not the default.
Letting th
Argh, I've got a little tangled up here. What was discussed here was *another*
(currently non-existing) option similar to `--allowerasing` but for packages
that have *no* obsoleting package in the repos... Nevermind my last comment
then.
--
Reply to this email directly or view it on GitHub:
ht
@dmnks commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ", sp
Merged #2914 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2914#event-12025012441
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Closed #2855 as completed via #2914.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2855#event-12025012740
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
Closed #2867 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2867#event-12040234782
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Let's just cover this as part of #2860, closing now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2867#issuecomment-1983234261
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2867 as not planned.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2867#event-12040276990
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Fixing up the closure reason (to "not planned").
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2867#issuecomment-1983239750
You are receiving this because you are subscribed to this thread.
Message ID:
Ostree does something similar, too, maybe we could take a look at that as well:
https://docs.fedoraproject.org/en-US/fedora-silverblue/tips-and-tricks/#_working_with_ostreerpm_ostree
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1178#
Awk is part of POSIX and thus should always be installed. Gawk is a GNU
implementation that's is typically installed by default on Linux but even
then, there should always be an "awk" symlink in $PATH.
This fixes the build on (non-Linux) systems that don't have Gawk.
Fixes: #2926
You can view,
> Plain awk is commonly available, but it's quite possible to have eg a minimal
> image where it's not installed. So I think we should check for it explicitly
> and fail if not found.
OK, I admit I was just being a bit lazy here :sweat_smile: The point of (cmake)
configuration is not to *assume
Thanks, I'll update the PR accordingly.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2960#issuecomment-1991244835
You are receiving this because you are subscribed to this thread.
Message ID: ___
OK, should be fixed now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2960#issuecomment-1991531934
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Yep, I was originally going with exactly that (even had the code locally) but
then I realized there was no point in not just using `find_program()` :smile:
The reason we have `findutil()` is so that we have a sanitized path selection
(i.e. not `$PATH`) for these utilities that go into `macros.in
And while at it, `find-debuginfo` should be handled the same way as `awk` here.
@pmatilai, I wonder what the rationale of commit
https://github.com/rpm-software-management/rpm/commit/5ac27313a5ecd601e01393cda10e6f16728a434a
was? Besides `macros.in`, we're only using it in `atlocal.in` but that d
Oh, now I realize commit
https://github.com/rpm-software-management/rpm/commit/5ac27313a5ecd601e01393cda10e6f16728a434a
was *before*
https://github.com/rpm-software-management/rpm/commit/bbb289e303d8c72b9e35410e593b8d92b006bec1
so I guess that's the explanation :smile:
I'll hack up a fixup co
Reopened #2926.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2926#event-12089522278
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Needs a re-fix, see #2960 for details.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2926#issuecomment-1991683268
You are receiving this because you are subscribed to this thread.
Message ID: __
Please see the commit messages for details.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2966
-- Commit Summary --
* Sanitize awk and find-debuginfo paths in macros
* Accept alternative awk implementations in cmake
--
The second commit (to add the other awks) may be a bit "controversial" in terms
of how useful it really is but... why not :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2966#issuecomment-1992154308
You are receiving this because
Closed #2830.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2830#event-12114599493
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
Closing for now, I'll open an actual PR when ready.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2830#issuecomment-1996896069
You are receiving this because you are subscribed to this thread.
Message ID: ___
While the "canonical" `_build` subdirectory in the source tree is
[ignored](https://github.com/rpm-software-management/rpm/blob/master/.dockerignore)
when copying the sources into the OCI image, there may be other directories
and/or files and some of them may cause issues when copying them (e.g.
The `ADD` command can copy archives (and unpacks them also) so we might as well
just do a `git archive` beforehand and copy that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2970#issuecomment-1997061467
You are receiving this becaus
This is entirely non-obvious as one would assume that any exported env vars are
inherited by the runroot() subprocesses. Yet they aren't because we
intentionally reset the environment in the bwrap containers with --clearenv
(see atlocal.in). It's a common use case, though, so deserves a proper
Merged #2991 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2991#event-12232880576
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@dmnks requested changes on this pull request.
> @@ -2,6 +2,41 @@
#
AT_BANNER([RPM macros])
+AT_SETUP([macro path])
+AT_KEYWORDS([macros])
+RPMDB_INIT
+
+# .rpmmacros exists
I'd suggest that we actually check that `~/.rpmmacros` really exists (or just
`touch` it like in the other tests bel
@dmnks commented on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacr
@dmnks commented on this pull request.
> +}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacroPath(const char *confdir)
+{
+const char *xdgconf = getenv("XDG_CONFIG_HOME");
+if (!(xdgconf &
@dmnks approved this pull request.
Looks good now! And thanks for the updated commit message (wrt the "rpm
--showrc" case) :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#pullrequestreview-1959771873
You are receiving thi
Oh, and please add a label for the category of this feature (for the future
auto-changelog).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#issuecomment-2019913634
You are receiving this because you are subscribed to this thread.
M
Ugh, right...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#issuecomment-2019920673
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing lis
Merged #2992 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#event-12247199537
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Closed #2153 as completed via #2992.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2153#event-12247199859
You are receiving this because you are subscribed to this thread.
Message ID:
___
R
Relevant piece of code:
https://github.com/rpm-software-management/rpm/blob/c4665da3b6f9adc1e689e77fdf83c91b264be40f/rpmio/macro.c#L722
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2020965004
You are receiving this
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: ___
What I mean is rpm's own test-suite:
https://github.com/rpm-software-management/rpm/blob/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d/tests/mktree.oci#L53
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2035694448
You are
Details in the commit messages (GH didn't populate the description
automatically for some reason).
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3018
-- Commit Summary --
* Rename script->args to script->prog
* Replace
As mentioned above, this is indeed expected behavior; when the trigger source
is part of the transaction, the trigger is also activated, and is fed *all* the
matching prefixes. It's analogous to *all* the packages shipping files in the
`/` prefix being part of the transaction.
That said, I can
Spring is here again and with it, a preview of what's coming in the next major
RPM update later this year, version 4.20, in the form of an ALPHA pre-release.
As per usual, a number of new features are in the works, most of which have
already landed in this pre-release and are ready for a test driv
Spring is here again and with it, a preview of what's coming in the next major
RPM update later this year, version 4.20, in the form of an ALPHA pre-release.
As per usual, a number of new features are in the works, most of which have
already landed in this pre-release and are ready for a test dr
After a quick chat on our team channel, this may benefit from packagers'
feedback. It's meant for them, after all. I'll ask for it, let's convert to a
draft meanwhile.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3018#issuecomment-207
@dmnks commented on this pull request.
> @@ -248,4 +248,29 @@ char *argvJoin(ARGV_const_t argv, const char *sep)
return dest;
}
-
+
+ARGV_t argvFromVaList(const char *fmt, va_list ap)
+{
+ARGV_t argv = argvNew();
Oh, fair points, thanks. Will update the PR later.
--
Reply to t
@dmnks commented on this pull request.
> @@ -32,7 +32,7 @@ directories, symlinks etc.
The file triggers are defined in spec files of packages. E.g. file trigger
executing `ldconfig` could be defined in glibc package.
-Similarly to regular triggers, file trigger scripts (except the
`%trans
Closed #3033 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3033#event-12576755985
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
This was fixed "recently" (in 2022) via #2176, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3033#issuecomment-2072485700
You are receiving this because you are subscribed to this thread.
Message ID: _
Note the patch was never backported to RHEL-8, hence CentOS 8 being affected
too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3033#issuecomment-2072488384
You are receiving this because you are subscribed to this thread.
Message ID
> I suppose a custom base image could be handy. It doesn't scale though, eg in
> case we'd want to build rpm-sequoia, popt and .. say, elfutils from sources
> to test a new feature before it's packaged in Fedora.
Imagine for a moment that the test-suite doesn't run in containers (e.g. it
still
Thanks for taking the bait, the purpose of the (rhetorical) question was to get
us closer to finding a solution :smile:
What changes with the new test-suite is that you would do those builds in a
container instead of your host, one that's preferably based on the test image.
Then, you would run
Put differently, the building workflow itself doesn't have to change, you only
do it in a container vs. natively. Of course, this enables us to have
declarative recipes for these builds (i.e. Dockerfiles) which is what I alluded
to above.
--
Reply to this email directly or view it on GitHub:
h
Thing is, you still need to manually bother with containers and images. What we
need here is an easy way to integrate this so you don't need to remember "oh, I
first need to run a container, then commit it, blah blah".
One way perhaps is to use Toolbx. We just need to integrate `make check` into
With the above said, I'm going to close this issue now. We also plan to improve
the documentation for triggers in general (via #2860) so that should help avoid
the confusion in the future.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issue
Closed #386 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/386#event-12610248521
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mai
101 - 200 of 1305 matches
Mail list logo
