Re: [Rpm-maint] [rpm-software-management/rpm] Drop erroneous BYPRODUCTS uses from the cmake files (PR #2900)
Merged #2900 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2900#event-11784582614 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] Run build scriptlets with closed stdin to enforce unattended builds (PR #2898)
Merged #2898 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2898#event-11784579272 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] Remove cycles from CMake dependency graph (PR #2820)
Solved a bit differently by just dropping the bogus BYPRODUCTS directives: #2900 Thanks for reporting, and the patch even if it didn't get used as-is! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1940624460 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] Remove cycles from CMake dependency graph (PR #2820)
Closed #2820. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2820#event-11784571037 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] Drop erroneous BYPRODUCTS uses from the cmake files (PR #2900)
BYPRODUCTS is only relevant for Ninja generator which we officially dont even support, but on which these usages cause Ninja to error out with phony target names itself as an input messages. I dont remember why exactly I put these BYPRODUCTS in there, but I know it was NOT to support Ninja explicitly. Probably it seemed somehow relevant to this cmake newbie and since it didnt harm anything ... on the make generator. Taking them out makes Ninja happy except for the test-suite. The make generator is still the only officially supported one though. Reported-by: Timothy Brackett brackett...@gmail.com You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2900 -- Commit Summary -- * Drop erroneous BYPRODUCTS uses from the cmake files -- File Changes -- M CMakeLists.txt (1) M tools/CMakeLists.txt (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2900.patch https://github.com/rpm-software-management/rpm/pull/2900.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2900 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] 4.19.1.1: `update-po` target fails (Issue #2899)
Looks like po/POTFILES.in is not up-to-date and translators as well are not aware that some updates needs to be added ```console [tkloczko@pers-jacek x86_64-redhat-linux-gnu]$ make update-pot -C po make: Entering directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu/po' cd /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu && make -f CMakeFiles/Makefile2 po/CMakeFiles/update-pot.dir/rule make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu' /usr/bin/cmake -S/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1 -B/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu/CMakeFiles 1 make -f CMakeFiles/Makefile2 po/CMakeFiles/update-pot.dir/all make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu' make -f po/CMakeFiles/update-pot.dir/build.make po/CMakeFiles/update-pot.dir/depend make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu' cd /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1 /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/po /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu/po /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu/po/CMakeFiles/update-pot.dir/DependInfo.cmake "--color=" make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu' make -f po/CMakeFiles/update-pot.dir/build.make po/CMakeFiles/update-pot.dir/build make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/x86_64-redhat-linux-gnu' [100%] Updating translation source cd /home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1 && /usr/bin/xgettext --package-name=rpm --package-version=4.19.1.1 --output=/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/po/rpm.pot --language=C --no-location --keyword=_ --keyword=N_ --files-from=/home/tkloczko/rpmbuild/BUILD/rpm-4.19.1.1/po/POTFILES.in /usr/bin/xgettext: error while opening "cliutils.c" for reading: No such file or directory make[3]: *** [po/CMakeFiles/update-pot.dir/build.make:74: po/CMakeFiles/update-pot] Error 1 ``` IMO It would be hoof to add excutinh that target at least in dist tar ball process formation and/or in CI. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2899 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] Document rpm design philosophy in the manual (Issue #2897)
I wonder if there are other packages like the Microsoft case where they require an explicit acceptance of a EULA in order to install the package. Rather than their current solution of requiring an environment variable to be set, or prompting on the terminal, perhaps we can recommend something like this? > If your package requires some sort of confirmation before installation (for > example, the user must accept a EULA before installing the package), then the > package can have a `%preinstall` script which looks for a file with specific > content. For example, the package can look for `/etc/$VENDOR/EULA.txt` with > the content `yes`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897#issuecomment-1938768873 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] Compiling RPM Version 4.8 on Centos 7 (Discussion #2895)
You compile it the same as any autotools software: grab the release tarball (not git branch), ./configure and so on. The rpm version being several years older than the distro you'd be compiling it on could cause issues with library and compiler compatibility and such. Any breakage you get to keep to yourself, that version is over a decade out of support. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2895#discussioncomment-8440151 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
There hasn't been much direct activity here recently, but doesn't mean no work has been going on. I'm planning to produce an updated version of the draft in the coming weeks, but the main point is going to be: The overriding priority for V6 is the obsolence of V4 crypto. We need a replacement format now, not in five or ten years time. And to make this happen *now*, V6 packages will need to be significantly compatible with existing rpm versions to allow existing infrastructure to handle them. This will mean backpedalling a bit on some things - such as zeroing the lead which would achieve *absolutely nothing* except cause an unnecessary incompatibility. This isn't any big revelation actually, it's just going back to where it started after getting just a little bit carried away for a while: the package level fundamentals are already implemented in rpm >= 4.14, v6 is really more about defaults and dusting dark corners than anything else. The time for more forward-looking changes is after we have v6 out and deployed. Then we can start planning for v7 in the next 5-10 years scale. The 20+ years since v4 was much, much too long. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8439989 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
FWIW, this is now (briefly) documented in https://rpm-software-management.github.io/rpm/manual/format_header.html#immutable-regions -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8439422 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] Run build scriptlets with closed stdin to enforce unattended builds (PR #2898)
I only remember a couple of tickets where the issue was rpmbuild being interactive, eg #978. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2898#issuecomment-1938331913 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] Document rpm design philosophy in the manual (Issue #2897)
I agree, may be just a few sentences per item or may be even only one and the link to the rest of the manual for details. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897#issuecomment-1938330342 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] Document rpm design philosophy in the manual (Issue #2897)
Yup, there's a lot of related detail which deserves to be documented, but this must not become a 1000 page packaging guide. My primary goal here is a TLDR version of the higher level principles behind rpm operation, such as pristine sources and unattended operation, that you can point the uninitiated to without totally overwhelming them with the details. The finer details can and should be expanded on in other sections. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897#issuecomment-1938303087 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] Run build scriptlets with closed stdin to enforce unattended builds (PR #2898)
I would have sworn we actually did prevent that. I remember people being unhappy about it. I remember this being added before. But may be my mind is playing tricks on me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2898#issuecomment-1938295405 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] Is it possible for an RPM package to have no version? (Discussion #2896)
> Was it ever possible, at any point in the history of RPM, for a RPM package > to be created without a version or a release? No. Absolutely not. A package with empty or missing name, version, release, arch, os, license or summary tags is simply invalid, and rpm could and should (but apparently doesn't) refuse to install it at all. That package was either created by a modified rpmbuild (or perhaps more likely), custom-written 3rd party tool. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2896#discussioncomment-8438953 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] Run build scriptlets with closed stdin to enforce unattended builds (PR #2898)
Even max-rpm philosophy section points out that rpm builds are unattended, but then we do nothing at all to prevent it? I first though maybe this regressed when we switched the build scripts to use rpmfcExec() a few years ago, but there wasnt anything before that either. Weird. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2898 -- Commit Summary -- * Run build scriptlets with closed stdin to enforce unattended builds -- File Changes -- M build/rpmfc.c (11) A tests/data/SPECS/interact.spec (12) M tests/rpmbuild.at (12) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2898.patch https://github.com/rpm-software-management/rpm/pull/2898.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2898 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] Document rpm design philosophy in the manual (Issue #2897)
List of things to talk about: - Upstream tarball + patches to see what are the packager's changes - SRPM has all needed to rebuild the package on its "home" distributing - assuming the distribution ships all (devel and tooling) packages - nosource as an exception - Optimized for updates - especially quick security updates - Package name as a line of updates instead of one time packaging (obsoletes as name change or split/merge) - Unattended updates - Handle full life cycle of all owned files - but ignore all other files - Scriptlets are supported but should be used very sparingly. - Most things can be done with file trigger only - E.g. register stuff in centralized catalogs, update caches - Do all that can be done during build! Compiling and copying unowned files around is frowned upon! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897#issuecomment-1938266942 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] Document rpm design philosophy in the manual (Issue #2897)
Max-rpm has a section on [philosophy](https://ftp.osuosl.org/pub/rpm/max-rpm/ch-rpm-philosophy.html) but it's a source one doesn't really want to link to because it's *s* outdated now. We should have a section explaining the fundamental design principles of rpm in our reference manual, many/most people probably don't even realize rpm *has* a philosophy. This came up indirectly when somebody asked about interactivity in rpm (install) scriptlets. Somehow one of the most important aspects of rpm - the fact that by design all operations are unattended - doesn't seem to be mentioned *anywhere at all*. This is just tribal knowledge, those in the tribe just know, and those outside it, like the average 3rd party commercial vendor who wants to present an EULA for their software at install time... and we can' even point them to any canonical source of information as to why that's a total no-no. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2897 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
