Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin doesn't share what's in transaction (#386)
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/issues/386#issuecomment-2077445462 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
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 it so that you can run it from a Toolbx container directly. I've attempted this with (the now closed) #2830 but I'm planning on submitting a new version of that PR, so that could help. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077406653 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
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: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077338041 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
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 the test-suite manually from that container or commit the container as the "new" test image and run it with `make check` from the host as usual. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077334471 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
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 receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
> 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 uses fakechroot). How would you accomplish the above? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077164963 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)
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 const char pointers though to the c_str() items to avoid having to change everything at once. Popping macros is a bit clunky and repetitive, well clean it up later. findEntry() returns a pointer to the macro entry itself instead of pointer to pointer, which simplifies things a bit further. This is a wee bit slower than the raw C counterpart, but by no means tragically so and moving to native structures opens up other opportunities in turn, both optimization and feature wise. Further work will be easier now that the highly optimized but also tangled up data structure is (mostly) untangled. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3062 -- Commit Summary -- * Add copy control and in particular, destructor to the macro context * Convert macro table to STL containers + native strings -- File Changes -- M rpmio/macro.c (245) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3062.patch https://github.com/rpm-software-management/rpm/pull/3062.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3062 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Another bunch of misc C++ conversion/cleanups (PR #3060)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
