This is intended to be used for non-mock builds. It simplifies patches
maintenance when preparing old rhel specs from Fedora system, so it does not
need to be backported to rhel8 or previous. It is meant to be used for rebasing
or testing in ``fedpkg local`` or ``fedpkg install`` modes, where
this allows creating git-based build patches applied, even on rhel7 or rhel8,
where %autosetup is not used.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2961#issuecomment-1991193975
You are receiving this because you are subscribed to
I have used (or misused) _fixperms macro to provide special actions for
creating build repository as git repository, without the need to modify
original source spec file. Something I have prepared at
https://github.com/pemensik/rpm-gitprep. I would like to have a way more clean
to it.
--
Allow custom action done after %_fixperms is done. Creates %_setup_post macro,
which will be expanded after %setup. Consequently also always done in autosetup.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2961
-- Commit
Ah, then yes, that would be what I were looking for. But because quite
unintuitive name I have never tried to use it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643683
You are receiving this because
seems ``rpmbuild -bl`` would be ideal for me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643342
You are receiving this because you are subscribed to this thread.
Message ID:
I want to check unit tests are passing in my builds. Also I want to check
%files are found and packaged, but most of time I will delete built rpms
without installing them. Afaik *fedpkg* does not allow to use rpmbuild -bi
alternative, but has -bb via local build :)
--
Reply to this email
Tags on mentioned commit say:
Follows: rpm-4.17.0-alpha
Precedes: rpm-4.19.0-alpha
Just tried it on rpm-build-4.16.1.3-29.el9.s390x, where --noclean is not
necessary. This is not about deleting buildroot *before* the build, but *after
successful* build.
--
Reply to this email directly or view
In fact, I might want to delete built rpms instead. Usually I do not need them
anyway, because I do local builds usually just o test something with built
version. I need builddir, but not locally generated rpms. But that would be
other topic.
--
Reply to this email directly or view it on
**Is your feature request related to a problem? Please describe.**
Before commit b34333fa021c0ee7215714eeef96d1a2843ea08e, rpmbuild has by default
kept built artifacts. I had often used it to run upstream test suite of bind
package, which needs first setup made by root. Therefore it could not be
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,
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:
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
> @pemensik You can use `%patch -P 123`
I can, but it does not work well with `%autosetup -N -S git`, which is my
point. I want to apply one patch like `%apply_patch`, with support for %__scm
macro. But simple and short way. My patch allows to override ``%patch -p1 -P
0001`` with custom macro,
Cool, thank you very much. I hoped it would be possible without modified RPM
itself. Anyway, thanks for finishing it!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Unfortunately I found out it is not useable as it is. My use case worked on
small test example. I did expect however numbers of patches in lua corresponds
to numbers used in spec files. I recently found they are unrelated. I think it
would require modification of packages table in lua, so used
Hi. This is my test approach to allow redefinition of patch application in old
plain spec files. All references with
```
%patch1 -p1
%patch2 -p1
```
etc. cannot be redefined. There is quite nice %apply_patch macro and
%autopatch, which allows applying all patches in automated way.
Moves single %patchX from RPM code to macros. This can be then
redefined.
Similar to apply_patch, but allows all custom flags that can be passed
to %__patch utility. Forwards also name and number of a patch.
Rename to __apply_patchx_{common,plain,uncompress}
Use single macro in two variants,
It should help to spec files with large number of patches of different age and
maybe format. If few patches has to be applied in different order or
conditionally, %autopatch cannot be used. With this extension, some parts can
be applied later. Some packages require some action between patches,
Limits allow to apply only range of patches with given parameters.
Useful if something needs to be done between patch sets. Allows applying
of patches with different -pX parameter in one spec file.
You can view, comment on, or merge this pull request online at:
20 matches
Mail list logo
