Re: [Rpm-maint] [rpm-software-management/rpm] RFE: %{_system_bindir} and such macro (#721)
It actually cites the source: https://github.com/rpm-software-management/rpm/blob/6714ec7068a0343dcb4aaaeb4fe49940c129292f/macros.in#L960 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1811979900 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] RFE: %{_system_bindir} and such macro (#721)
And yeah, the point of those macros is NOT to make it easier to type. They're
there for flexibility.
Those of us who lived through the rise of the multilib will remember fixing a
thousand specs wrt /usr/lib -> %{_libdir} to accommodate for that. And /usr/doc
-> /usr/share/doc change before that. It's not likely that something like
/usr/bin gets moved to some different location now, but they still serve the
flexibility purpose in allowing for entirely different repackaging with a few
simple defines - like Flatpak, SCL and so on.
But, that "few simple defines" doesn't hold in practise because these macros
are ambiguous: do they refer to the system or the package being built?
Traditionally these are the same thing, but it falls apart with Flatpak, SCL
and so on, and changing the prefix can and probably does break all manner of
other helpers which just slavishly use the macros as alleged system level
paths. And hence we have this ticket.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1811991213
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] RFE: extract changelog to file, include as %doc automatically and put stub in actual binary and source RPMs. (#305)
Technically, I think we have sufficient APIs nowadays that we could actually pull file contents such as a changelog from the payload on non-installed packages. There's some extra cost of course, but just how performance critical is looking at changelogs? Not very I think. The "problem" is that the changelog is not stored in the form you see with -q --changelog, but three arrays which can be accessed programmatically, such as to pull the last three items, or the unfortunate --changes which shows finegrained timestamps. Of course the content could be parsed back into that form using the same code that puts it into the header, we'd just need to move part of the parsing code to librpm side. But whether that's worth all the extra complexity? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/305#issuecomment-1812019304 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] RFE: extract changelog to file, include as %doc automatically and put stub in actual binary and source RPMs. (#305)
The same tag-query-from-payload thing could be beneficial to various other cases too, such as RPMTAG_SPEC which could be placed in the payload rather than the header if we could do this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/305#issuecomment-1812147033 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] OpenPGP: How to get `can_sign` info? (Issue #2515)
Closed #2515 as completed via 01fb42d42ca710bf24e3af841d43b4e3d60b3aef. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2515#event-10967022569 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] Extend %changelog to accept filename. (#393)
I see %changelog -f as something that would create more issues than it solves, but like said above, we too would very much like to see better integration with external changelogs. Let's continue the external changelog discussion in a dedicated topic: https://github.com/rpm-software-management/rpm/discussions/2768 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/393#issuecomment-1812406092 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] Extend %changelog to accept filename. (#393)
Closed #393 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/393#event-10966512266 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] rpmdb - flag about the package installation reason (#622)
@dmnks converted this issue into discussion #2767. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/622#event-10965344679 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] rpmvercmp() compares as equal versions that are not the same (#925)
@dmnks converted this issue into discussion #2765. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/925#event-10965331958 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] RFE: %{_system_bindir} and such macro (#721)
@dmnks converted this issue into discussion #2766. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/721#event-10965341585 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] RFE OptionalBuildRequires (#577)
As stated above we'd rather not have weak/optional BuildDependencies. Having predictable builds is a value on it's own. Closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/577#issuecomment-1812150848 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] RFE OptionalBuildRequires (#577)
Closed #577 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/577#event-10965418970 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] RFE: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
This can probably be done as a plugin nowadays. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1812090168 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] RFE: set builsubdir to the *first* extracted archive not the last one (#551)
With the latest changes to the `%setup` macro this may now be easier and should be looked at again. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/551#issuecomment-1812148572 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] rpmbuild should present machine parseable failure reports (Issue #2769)
On talk about AI by Tomáš Tomeček I have realized rpm building process it quite terrible at providing machine processable results for failed builds. I think it should be reported in machine parseable format, JSON for example. When the build has failed on BuildRequires: installation, it should even know exact list of packages missing to be working. But the list is just written into the output in unstructured way. I think optional status file should be provided, with mentioning in which section the failure happened and optional parameters, if it cat gather them. I think those section failures should be reported separately: - BuildRequires: missing (with list of packages) - source files missing (with list of files) - patch files missing (with list of files) - patch apply failed (with list of patches) - ``%prep`` fail in general - ``%build`` fail - ``%check`` fail - ``%install`` fail - unpackaged files found (with list of files) Those information could be the presented by build service to the user, ideally with possibility to read only failing section output if I wish. If the tool has structured information, it should export it in structured way for machine processing. Such structured information could be used for statistics or faster fixing. In some cases it would allow even *automated* fixes of failing spec file. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2769 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] [RFE] rpmbuild should present machine parseable failure reports (Issue #2769)
I think rpmbuild should return different return code at least for different sections, in which the failure occurred. But ideally also with lists of relevant object types it knows. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2769#issuecomment-1812880637 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] [RFE] rpmbuild should present machine parseable failure reports (Issue #2769)
At least it would be possible to say in which file to search for the error. Not something the end user has to find himself. Example: https://koji.fedoraproject.org/koji/taskinfo?taskID=105833248 But in general, I do not think the result should be pure boolean. More likely something like enum, with 0 used for success, positive numbers for issue type specification. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2769#issuecomment-1812887021 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] [RFE] rpmbuild should present machine parseable failure reports (Issue #2769)
I fully support Petr's idea here. It would be amazing to use that data further in the workflow and display that information nicely in koji, Copr, GitHub, Gitlab... We could even think about automated retries for certain types of errors (flakes, network problems) or even fix a spec file if a BR is missing? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2769#issuecomment-1812929861 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] External changelog integration (Discussion #2768)
I don't know what you mean by that. %prep, %build, %install etc are shell scripts, %files and %changelogs are static data that rpm parses. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2768#discussioncomment-7584794 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] External changelog integration (Discussion #2768)
Can the `%changelog` section being made similar to others, such as `%prep`, `%build`, etc? Thinking of this, can `%files` section be more similar to those as well 樂 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2768#discussioncomment-7580530 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] External changelog integration (Discussion #2768)
Pretty much all distros have at least the option of pulling the spec changelog from an external source - namely the package SCM (dist-git in the Fedora world). There have been various suggestions to make rpm better integrate with this, such as - https://github.com/rpm-software-management/rpm/issues/393 - https://github.com/rpm-software-management/rpm/pull/69 ...and I think a whole other bunch in RH bugzilla and other ticket systems over time, yet here we still are, none of them have been implemented/applied, because the designs just haven't seemed right. If you have an external process to do 'git log > changes; rpmbuild --changelog=changes foo.spec' then that same process can could just as easily append the changes to the spec itself. Plus it's a step you need to remember to do manually unless you have extra tooling around rpmbuild. Adding -f support to %changelog to allow for an external changelog forces silly '%changelog -f somefile' boilerplate in each and every spec, and worse, introduces a whole new world of spec parse failures because the externally generated file is not there. To come up with a solution that satisfies most if not everybody, we need to be aware of what people are currently doing. I don't know what exactly other distros do (just append to the spec or something fancier? please fill us in), in Fedora there's [rpmautospec](https://pagure.io/fedora-infra/rpmautospec) to fill this role and (optionally) generate a release automatically too. I haven't used it beyond curiosity testing a bit. There are interesting ideas in there, but then it also requires running some external wrapper tooling to make it actually work. And at that point we're back to: if external tooling is required, then what do we need rpm changes for? This is already possible, in numerous different ways. But surely, there *must* be something we can do in this area. Thoughts and ideas, even wacky ones, welcome. It's better to hash out the ideas as a central discussion that speculate independent RFE tickets. We'll file ticket(s) if/when some conclusions are reached. I've been recently working on https://github.com/rpm-software-management/rpm/issues/1087, and one thing that will give us is a way to automatically populate spec sections with macros. This should make it possible to invoke something like `%([ -d .git ] && git log --pretty="* %ad %an <%ae>%n- %s%n")` (real-worl will want more complicated "filter" there now doubt) to autofill %changelog from inside rpmbuild itself with no need for external commands and zero changes to the spec itself. Except to trim out the %changelog section entirely. Whether this kinda of thing is useful to anybody at this point is another question. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2768 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
