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
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:
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`
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:
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
Have local recipes from building from those upstream sources, install in
suitable prefix with LD_LIBRARY_PATH. In a word, painfully? :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077175576
You are
> 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
Is there anything I need to do to initiate a backport to 4.19.x?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2076977118
You are receiving this because you are subscribed to this thread.
Message ID:
Use an STL map for the macro entry table, this matches exactly the behavior we
manually did with the C array.
The variable length array at end of macro entry structs is not really C++, use
native strings for the storage. Its slower, but not tragically so. For
now, keep name, opts and body as
Merged #3060 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3060#event-12605908368
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
10 matches
Mail list logo
