Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add way to set macro for --nocheck in rpmbuild (#316)
we can use : rpmbuild --without check -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/316#issuecomment-1899391222 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] Make user/group lookup caching thread-safe (PR #2843)
@dmnks approved this pull request. Other than the commit note above, the patches look good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1830246698 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] Make user/group lookup caching thread-safe (PR #2843)
@dmnks commented on this pull request.
>
return 0;
}
const char * rpmugUname(uid_t uid)
{
-static uid_t lastUid = (uid_t) -1;
-static char * lastUname = NULL;
-
-if (uid == (uid_t) -1) {
- lastUid = (uid_t) -1;
Ah, this is not needed now that we have a `struct`, of course. Nevermind the
above :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#discussion_r1457778721
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] Make user/group lookup caching thread-safe (PR #2843)
It seems like the commit hash mentioned in the commit message isn't correct (it's the "Bump CI" commit which doesn't seem to have anything to do with this). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1898909235 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] Make user/group lookup caching thread-safe (PR #2843)
@dmnks commented on this pull request.
>
return 0;
}
const char * rpmugUname(uid_t uid)
{
-static uid_t lastUid = (uid_t) -1;
-static char * lastUname = NULL;
-
-if (uid == (uid_t) -1) {
- lastUid = (uid_t) -1;
I wonder if this line shouldn't be kept? `rpmugFree()` won't reset `lastUid` to
`-1` and it can be used before assignment.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1830213798
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] Don't brp-strip ruby, python, or javascript files (PR #2858)
There are often a large number of script source files. While the xargs will later discover that these files are simple text files, it makes a very large number of io calls to determine this. Since many people are using containerized builds, the expense of this IO ends up adding minutes to some build processes. Thank you You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2858 -- Commit Summary -- * Dont brp-strip ruby, python, or javascript files -- File Changes -- M scripts/brp-strip (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2858.patch https://github.com/rpm-software-management/rpm/pull/2858.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2858 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@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] Add "local_generator" (PR #2734)
OK, just to write down how the current system works: The `fileattrs/*.attr` are read in at the beginning with all other macro files. The macros in there can be over written by the spec file - or by `%load` ing the `.attr` file in the Sources. RPM goes through the list of file attrs (currently from globbing the `fileattr` directory) and stuffs the macros it can find into it's own data structure before evaluating them and running the dependency generators. The has the disadvantage that when e.g. a `_provides` script is declared in the installed `.attr` file it will be excuted unless the macro is `#undefined` in the spec file. That's kinda unfortunate but something packagers probably can deal with. This also means that if the same name is used in `%__packaged_file_attrs` the over written macro values will also overwrite the installed settings as the macros are in the same name space. So the old scripts would not be used - only the new ones executed twice. But we can simply filter out the duplicates. Having the file attribute twice doesn't ever make sense as there is only one setting for it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898627307 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] Update Docs for "Users and Groups" in the manual (Issue #2857)
Docs still assume that systemd_sysusers is to be used. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2857 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] Add "local_generator" (PR #2734)
@ffesti pushed 1 commit. 5059816af9185cc7c3f19ad729b4dc657f912cde Rename __local_file_attrs to __packaged_file_attrs -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734/files/cd4bd81ad1c446c119a27eec77b2828b5ea1624a..5059816af9185cc7c3f19ad729b4dc657f912cde 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] Add "local_generator" (PR #2734)
> I think the issues is reproducibility and correctness. If you fix the
> dependency generator in your package you don't want to old - possibly broken
> - deps still in your package, just because the old package is still on your
> build system.
That is actually good point.
So in the Ruby case, it would actually make sense to override the `rubygems`
macros, which would make sure the generator shipped with Ruby is the only one
used. IOW there would need to be:
~~~
%global __local_file_attrs rubygems
%global __rubygems_requires make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
%global __rubygems_provides make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
%global __rubygems_conflicts make -C
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
%global __rubygems_path ^%{gem_dir}/specifications/.*\.gemspec$
~~~
Actually, this leads me to another silly idea. Maybe the `rubygems.attr` could
be loaded instead of the overrides if it was crafted properly ...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898330857
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] Add "local_generator" (PR #2734)
I think the issues is reproducibility and correctness. If you fix the dependency generator in your package you don't want to old - possibly broken - deps still in your package, just because the old package is still on your build system. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898223470 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] Don't use _nl_msg_cat_cntr if __GLIC__ is not defined (PR #2856)
musl doesnt need to use libintl from GNU gettext because it has its own NLS implementation. Assuming _nl_msg_cat_cntr exists breaks the build against the musl system. ``` /usr/lib/gcc/x86_64-gentoo-linux-musl/13/../../../../x86_64-gentoo-linux-musl/bin/ld: ../lib/librpm.so.10.0.1: undefined reference to `_nl_msg_cat_cntr collect2: error: ld returned 1 exit status ``` You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2856 -- Commit Summary -- * Dont use _nl_msg_cat_cntr if __GLIC__ is not defined -- File Changes -- M lib/tagexts.c (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2856.patch https://github.com/rpm-software-management/rpm/pull/2856.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2856 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Improve build determinism (replace soft dependencies with strict ones) (Issue #2855)
This is a followup to https://github.com/rpm-software-management/rpm/pull/2852/ There is still a number of soft dependencies in https://github.com/rpm-software-management/rpm/blob/master/CMakeLists.txt: ``` find_package(BZip2) find_package(Iconv) ... pkg_check_modules(ZSTD IMPORTED_TARGET libzstd>=1.3.8) pkg_check_modules(LIBELF IMPORTED_TARGET libelf) pkg_check_modules(LIBDW IMPORTED_TARGET libdw) pkg_check_modules(LIBLZMA IMPORTED_TARGET liblzma>=5.2.0) ``` Then, the respective build options get enabled depending on whether or not these components were found on the build system. I believe it's better to make them strict (add REQUIRED parameter), and (optionally) wrap them in cmake options (like was just done for readline support), if there are situations where they should be disabled. I can write the patch, but wanted first to confirm what would be preferred. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2855 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] Add "local_generator" (PR #2734)
> I am thinking about actually shipping the dependency generator but also using > it in the package itself. This ^^ actually is my use case and here is how it looks in practice: https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_187-190 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_203-206 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_795-800 https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/ruby.spec#_1330-1335 Saying all these, it makes me realize that in theory, if the `rubygems-devel` package was installed during Ruby build, the generators could actually run twice. But they are executed for specific path based on specific macro: https://src.fedoraproject.org/rpms/ruby/blob/308b2c0ab2c6268847ed3bf2008e74bce334e810/f/rubygems.attr#_6 Not sure. In reality, having Ruby installed during build of Ruby is problematic for different reasons, so I don't have to be worried in this case. > For that you need to make sure that it is only run once during the build - > even if the package is actually installed in the system building the package. Do I? I don't think there is currently anything, which would prevent one generator running twice. E.g. if there are multiple `.attr` files pointing to the same script. Also the macros can be changed any time to point to the same script. And the generators can also be disabled by changing the macro. Actually, from this POV, my original PR making the `local_generator` special kind of helps to mitigate the concerns. The more flexibility will provide more opportunities for clashes. Nevertheless, let me be clear that I am not really arguing for or against of any of those variant. Both versions are acceptable. But it is good to understand all the corner cases -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898123753 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] RFE: add a cmake target for hands-free docs-server (Issue #2854)
For someone like me who's utterly unaware of the Ruby ecosystem, setting up the jekyll server for locally testing docs changes is a rather terrifying experience. We should have a cmake target that sets it up and runs it in a hands-free manner. Something along the lines of "make docs-server" that sets up a container to run "jekyll serve" in the docs directory, and emits an url you need to click. Considering how ubiquitous GH markdown is, there probably already is a docker image we could use for this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2854 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] Add "local_generator" (PR #2734)
Hmm, I guess we are taking about two different use cases. You are thinking about a dependency generator that is in the package only and not installed ever. For that you want a unique name that won't ever clash with installed file attributes. I am thinking about actually shipping the dependency generator but also using it in the package itself. For that you need to make sure that it is only run once during the build - even if the package is actually installed in the system building the package. The you'd want the names to be the same and RPM should overwrite the installed one with the one in the package. I guess we do want both use cases to work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898072680 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] Add "local_generator" (PR #2734)
On the second thought, maybe it really is the right way. I am coming from place where no "local" generator us was possible, so one was already great improvement. But maybe there are use cases for multiple generators? OTOH, one could call them via some helper script or by chaining them (in the worst case by executing `bash` or what not). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898067418 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -866,6 +866,7 @@ RPMTEST_CHECK([ RPMDB_INIT runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs local_generator' \ Maybe something like `totally_random_generator_name` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#discussion_r1457125066 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] Add "local_generator" (PR #2734)
> OK, just hard coding one file attribute doesn't seem like a good idea. I > added a macro that allows you to register an arbitrary number of local file > attributes and generators. Nice, now we can argue if the `__local_file_attrs` is the right name or rather e.g. `__package_local_file_attrs` 藍 Sorry, couldn't resist. Nevertheless, thx for contributing. I see your point. OTOH, if I read your commit correctly, my original proposal had the advantage, where one could count with convention over configuration. IOW with your changes one additional line is needed to make this work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#issuecomment-1898047160 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] Add "local_generator" (PR #2734)
@voxik commented on this pull request. > @@ -866,6 +866,7 @@ RPMTEST_CHECK([ RPMDB_INIT runroot rpmbuild -bb --quiet \ + --define '__local_file_attrs local_generator' \ While this is "just test case", maybe the `local_generator` could use different name, just to avoid the impression that the `local` is somehow mandatory in the latter -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2734#pullrequestreview-1829143312 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
