I kinda suspected that anyway. Thanks for confirming.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3357#discussioncomment-10841231
You are receiving this because you are subscribed to this thread.
Message ID:
__
Hello. Consider this Python code:
```pycon
>>> import rpm
>>> rpm.expandMacro('%{lua:print(a)}')
'nil'
>>> rpm.expandMacro('%{lua:a = 1}')
''
>>> rpm.expandMacro('%{lua:print(a)}')
'1'
```
Between individual `rpm.expandMacro` calls, the Lua state is preserved. `a` is
a global variable and it is
@hroncok commented on this pull request.
> +
+ spawn({command} [, {actions}])
+
+Spawn, aka execute, an external program. (rpm >= 4.20)
+
+`{command}` is a table consisting of the command and its arguments.
+An optional second table can be used to pass various actions related
+to the command
@hroncok commented on this pull request.
> +
+ spawn({command} [, {actions}])
+
+Spawn, aka execute, an external program. (rpm >= 4.20)
+
+`{command}` is a table consisting of the command and its arguments.
+An optional second table can be used to pass various actions related
+to the command
@hroncok commented on this pull request.
> + execute({table} [, stdout [, stderr]])
+
+Execute an external command (rpm >= 4.20)
+This is an alternative form of rpm.execute() that takes the command and any
+arguments as a single Lua table.
+
+Standard output and/or error can be optionally re
@hroncok commented on this pull request.
> + execute({table} [, stdout [, stderr]])
+
+Execute an external command (rpm >= 4.20)
+This is an alternative form of rpm.execute() that takes the command and any
+arguments as a single Lua table.
+
+Standard output and/or error can be optionally re
@hroncok commented on this pull request.
> + execute({table} [, stdout [, stderr]])
+
+Execute an external command (rpm >= 4.20)
+This is an alternative form of rpm.execute() that takes the command and any
+arguments as a single Lua table.
+
+Standard output and/or error can be optionally re
Thank you!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3190#issuecomment-2225295400
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
That's what I had in mind. Buildsystem does not exist and buildsystem is
incompletely defined are two distinct errors in my head.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3190#issuecomment-2213782740
You are receiving this becaus
```
(gdb) bt
#0 0x77d6c4d4 in __printf_buffer () from /lib64/libc.so.6
#1 0x77d92a73 in __vsnprintf_internal () from /lib64/libc.so.6
#2 0x77f1a255 in vsnprintf (__s=0x0, __n=0, __fmt=,
__ap=0x7f7ff4a0) at /usr/include/bits/stdio2.h:100
#3 rvasprintf (strp=strp@entr
**Describe the bug**
This works as expected:
```
$ rpm --define 'aaa %aaa' --eval '%aaa'
error: Too many levels of recursion in macro expansion. It is likely caused by
recursive macro declaration.
```
This crashes:
```
$ rpm --define 'aaa %[%aaa]' --eval '%aaa'
Segmentation fault (core dumped)
Alternatively, we can keep it, but say `(removed in rpm >= 4.20, do not use)`
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3193
-- Commit Summary --
* Undocument %patch1
-- File Changes --
M docs/manual/spec.md (4)
If you are interested, here is my first draft implementation of this:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-9941757
You are r
`%conf` is an optional section. Hence, I believe mandating the presence of
`%buildsystem_name_conf` for a declarative buildsystem is suboptimal.
I was able to "solve" this by:
```
%buildsystem_name_conf() %nil
```
However, that seems rather boilerplate-like.
Is there a reason to force the pres
**Describe the bug**
https://github.com/rpm-software-management/rpm/blob/775acf13850373c16d4b0d02a1970339c381f19b/build/parseSpec.c#L965-L971
Currently, all of `%buildsystem_name_conf`, `%buildsystem_name_build`, and
`%buildsystem_name_install` need to be defined for the buildsystem to function.
If they can affect the build, they can do it even in -ba.
If rpm wants to guarantee its own operations, it should provide an API for the
caller to handle %generate_buildrequires installations (e.g. via file sockets
or pipes or whatever).
--
Reply to this email directly or view it on GitHub:
htt
Mock guarantees the "production readiness" and "reproducibility" of the result.
Running the final -ba without noprep would gain no benefit to mock.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136608224
You are rec
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L744
https://github.com/rpm-software-management/mock/blob/3560d386d32e0d96e50f1495a0ee66c0e9d3fe55/mock/py/mockbuild/backend.py#L43
https://github.com/rpm-software-management
>From @pmatilai at #3121:
> I can see why mock would use such a thing, but I'm not really comfortable
> with that (or the option itself) because it seems that mock is now driving
> the build and not rpmbuild. And this means any changes to rpmbuild are even
> more difficult than they are otherwi
> You need [Mock
> v5.3+](https://rpm-software-management.github.io/mock/Release-Notes-5.3) that
> has this optimization.
Even before that, `--noprep` was used for the last rpmbuild round, so I assume
even older mock would be impacted.
> (not yet build in Rawhide, or already untagged, not su
**Describe the bug**
RPM 4.20 breaks all Fedora packages with %generate_buildrequires (when built in
mock, koji, etc.).
The error looks like this:
```
Executing(%generate_buildrequires): /bin/sh -e /var/tmp/rpm-tmp.nQJoQh
+ umask 022
+ cd /builddir/build/BUILD/python-cffi-1.16.0-build
+ cd cffi
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:
Thank you!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3059#issuecomment-2074482274
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
R
Saner handling of multiple identical options would be nice, but even without
that, the described behavior is wrong. Agreed?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2072404151
You are receiving this because you
**Describe the bug**
Consider this situation:
Macros:
```
%macro_leaking(E:) %{nil}
%macro_infected(E:) echo -- "%{-E:-E was provided: %{-E*}}%{!-E:there was no
-E}"
```
Notice both macros take an `-E` option with a value. The exact name of that
option is not limited to `E`.
And run:
```
%ma
I wonder if the License of the generated debugsource package should be derived
from the SourceLicense tag or not. Do we assume the debugsource package
contains sources, hence it is covered by SourceLicense, or do we assume it only
contains sources of stuff that has been built, and hence should n
That's currently possible and can lead to various subtle runtime failures
instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035405478
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks.
I noticed the `BuildOption(prep)` documentation was not updated in that PR.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034393793
You are receiving this because you are subscribed to this thread.
Message
https://github.com/rpm-software-management/rpm/issues/2998
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8919866
You are receiving this because you are subscribed to this thread.
Message ID:
__
See
https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8915180
It would make sense to make `-C` the default option for `BuildOption(prep)`, so
packages utilizing the Declarative builds feature don't have to pass custom
`-n` to it. (Using custom `-n` is also used a
Should I open an issue for -C to be the default for BuildOption(prep)?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8916583
You are receiving this because you are subscribed to this thread.
Message ID:
_
As long as it won't tell me `Unknown option l in buildsystem_pyproject_install`
but let me pass any option further down via `%**`, good (even better, so I
won't have to duplicate the option list).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/r
Hello. I've just located
https://github.com/rpm-software-management/rpm/issues/1087 in
https://fedoraproject.org/wiki/Changes/RPM-4.20 and I've read
https://rpm-software-management.github.io/rpm/manual/buildsystem.html
I am trying to understand how to use this, so let's dive in.
Suppose I curr
It's not possible to keep them anyway. That's the problem.we want to solve:
remove them when it's no longer possible to keep them.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682257
You are receiving thi
I've said it before and I will repeated it here. Dnf should gain an option to
allow erasing packages iff they are no longer available in the repos. Dnf
system upgarde should default to this option (at least for Fedora-provided
repos).
That way, we can stop manually tracking each retired package
@hroncok commented on this pull request.
> @@ -91,5 +91,16 @@ macros which is nicer in other situations, e.g.:
Always test for the `with`-condition, not the `without`-counterpart!
+## Overrinding Defaults
+
+For distributions it can be useful to overwrite the build conditionals on a
global
Could you please add an example to the docs?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1929392923
You are receiving this because you are subscribed to this thread.
Message ID: __
I suppose you care because of RHEL 9. If that's the case, I suggest you open a
RHEL 9 Jira.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1883#issuecomment-1795002390
You are receiving this because you are subscribed to this thread.
> That said, a generator not using the filename passed to it via %1 sounds
> suspicious in itself.
It's generating a provide based on the package name.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2501#discussioncomment-6384533
No idea?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2501#discussioncomment-6371154
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailin
Is a huge mess. In Fedora, we want to transition into using that, but so far it
has not been a priority :(
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-1594742567
You are receiving this because you are subscribed to t
Could you please add this to 4.19 as well?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1587265425
You are receiving this because you are subscribed to this thread.
Message ID: __
@hroncok commented on this pull request.
> @@ -132,6 +132,8 @@
%_keyringpath %{_dbpath}/pubkeys/
+%specpartsdir %{_builddir}/%{buildsubdir}-SPECPARTS
Is buildsubdir always defined?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/r
In our testing Copr for Python 3.12, the `r"Multiple top-level packages
discovered in a flat-layout: \[.*'SPECPARTS'"` regex was found in:
- python-uc-micro-py
- python-linkify-it-py
- python-nose2
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manageme
> An easy solution would be letting a package override the path. That allows
> the handful of special cases to handle it on spec level while leaving it loud
> and clear for the others...
What would b the advice for packages affected by the setuptools package
discovery issue? Putting `%global sp
Fixes https://github.com/rpm-software-management/rpm/issues/2532
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2533
-- Commit Summary --
* Rename SPECPARTS to .SPECPARTS to make it less disruptive
-- File Changes --
That depends on what files are built from what source. If anything in the main
package is actually built from lib or rpmio dirs, the License would be
`GPL-2.0-or-later AND (GPL-2.0-or-later OR LGPL-2.1-or-later)`, based on the
"no effective analysis" rule, wouldn't it? (Silly, isn't it?)
--
Re
Another Fedora package is known to be impacted. python-quantities:
https://bugzilla.redhat.com/show_bug.cgi?id=2213013
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2532#issuecomment-1579523314
You are receiving this because you are s
The `SPECPARTS` directory is leaking into setuptools package discovery. When
upstream Python projects choose to use automatic Python package discovery by
setuptools, `SPECPARTS` is considered a Python package (because empty
directories actually *are* Python packages) and when not explicitly excl
https://github.com/rpm-software-management/rpm/pull/2256 ? Did you mean
https://github.com/rpm-software-management/rpm/pull/2526 ?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1567005064
You are receiving this becau
Works:
```
sh-5.2# rpm --eval '%rpmversion'
4.18.90
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2525#issuecomment-1566935070
You are receiving this because you are subscribed to this thread.
Message ID: _
A number of % signs to escape a literal % sign in the file list. RPM 4.17 and
4.18 needed 8 of them, 4.19 is sane and only needs 2.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523#issuecomment-1566870904
You are receiving this beca
Would it be possible to expose a macro with the version of RPM, itself? So I
could do `%if v"0%{?rpm_version}" >= v"4.19" ...`.
Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2523
You are receiving this because you are subscri
Hello.
We have a workaround in our Fedora package:
https://src.fedoraproject.org/rpms/python-rpm-generators/blob/b1fa63bf02b03b2120d32eb91ca2911d4ec77beb/f/pythonname.attr#_6
While debugging a related issue on CentOS Stream 9, I figured out that the
warning is no longer present since Fedora 35.
%bcond_set_libmpeg does not carry enough meaning. The other two proposals do
and I don't have a preference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1464010710
You are receiving this because you are subscribed to
I am confused by the nomenclature here. As a spec author, when I write:
```
%bcond tests 1
```
I expect the tests will run.
Now the distro maintainer (or anybody who can define macros, really) can define
a macro:
```
%bcond_default_tests 0
```
What happens to my package? Does it no longer run
> Should errors encountered during fallback version lookup be a fatal error? It
> sounds like the answer is yes, so I'll make those changes shortly.
Note that even if the generator exists with non-zero, the build does not fail.
https://github.com/rpm-software-management/rpm/issues/1183
--
Repl
I just want to mention that:
- calling `rpm` from within a generator has always been considered a bad thing
to do
- `rpm -q --whatprovides` may return multiple things -- it might be safer to
`rpm -qf` the actual .so file
--
Reply to this email directly or view it on GitHub:
https://github.co
Note that if this is ready
https://github.com/rpm-software-management/rpm/issues/2345 -- the rpm shim
should be able to copy/link the _rpm extension module from the python3-rpm RPM
package to virtual environments using different (well, probably just newer)
Python versions.
--
Reply to this em
See also https://pypi.org/project/rpm-py-installer/
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2361#discussioncomment-4736849
You are receiving this because you are subscribed to this thread.
Message ID:
_
Thank you!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2358#issuecomment-1398310035
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
R
This is a followup from https://bugzilla.redhat.com/show_bug.cgi?id=2160716
It appears that when `%{undefined ...}` or `%{defined ...}` is used in an
expression in a macro definition, it breaks parsing of options.
See e.g.
```
$ rpm --define '%xxx(r) %[ %{undefined yyy} ? "" : "" ]%{-r:the -r
Hello. I often written macros defined like this:
```rpm
%py_shebang_fix %{expand:\\\
if [ -z "%{?py_shebang_flags}" ]; then
shebang_flags="-k"
else
shebang_flags="-ka%{py_shebang_flags}"
fi
%{__python} -B %{_rpmconfigdir}/redhat/pathfix.py -pni %{__python}
$shebang_flags}
```
I'v
Thanks. See also
https://pagure.io/packaging-committee/c/26174464286d7e44c4f5a23f71d487fd9fd4d3f9
for Fedora guidelines.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2340#discussioncomment-4631748
You are receiving this because
At https://rpm-software-management.github.io/rpm/manual/macros.html both
variants are used:
> %{?!macro_name:value}
> %{!?with_python3:1}
Which syntax is the "proper" one? Or are both of them fully OK?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwar
> Enterprise distros of course do what they see fit.
https://bugzilla.redhat.com/2129060
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2042#issuecomment-1254936077
You are receiving this because you are subscribed to this thread.
Mes
I like your questions but I don't have the answer. Would exposing Lua string
methods on RPM macros make sense? E.g.:
```
%{version:gsub ~} -> as if rpm.expand("%version"):gsub(rpm.expand("~"), "") is
called from Lua
%{version:gsub %{thingy} -} -> as if
rpm.expand("%version"):gsub(rpm.expand("%{
@hroncok pushed 1 commit.
e168ef0e325097ac41d8069960a5fc07bfd28eea Introduce convenient %gsub macro to
wrap Lua's string.gsub()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1764/files/9d2d9cfb564580
See also https://github.com/rpm-software-management/rpm/pull/1764
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1219#issuecomment-906332380__
Related to https://github.com/rpm-software-management/rpm/issues/1219
Related to https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/101
Would you accept (something like) this? It is much easier than calling Lua
directly from the spec.
You can view, comment on, or merge this pull re
However, not sure how to load macros from a file and dump them without
affecting the actual macros.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1758#issuecomment-901036
> I'd imagine a parametric generator in Lua would work nicely for this thinking
That was my plan when pitching for this functionality.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managemen
I wonder whether "calling rpm from rpm" is considered OK nowadays.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1758#issuecomment-900999827___
The semantics of escaping stuff in %files is not very clear. See also this
thread: http://lists.rpm.org/pipermail/rpm-list/2021-June/002048.html
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software
Consider this spec file:
```
Name: reproducer
Version:0
Release:0
Summary:...
License:MIT
BuildArch: noarch
%description
...
%prep
%install
touch '%{buildroot}/file[with spaces]'
%files
"/file[with spaces]"
```
RPM 4.16 and 4.17 will fail to buil
> No further comments in two weeks, I guess we're sufficiently done here...
Well, it was 1 day since you posted the recent update, not 2 weeks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
```
%autopatch-- applies all patches defined in the spec file, in
the definition order
%autopatch -m 100 -- applies all patches numbered 100 or higher, in the
definition order
%autopatch -M 99 -- applies all patches numbered 99 or lower, in the
definition order
%
So, no ranges after all?
I think the documentation would benefit form some examples. I'll write some
down.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1697#issuecommen
Fedora rawhide does not use the removed files via the rpm package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-849506440___
Sorry, I've meant that ranges/slices include start but not the end. I.e. `1:3`
is 1, 2. Unlike `%autopatch -m 1 -M 3` which is 1, 2, 3.
> Hmm, but then we can nowadays have macros opt out of option processing.
Yes, but that way, no backports would be possible.
--
You are receiving this becau
Note that Python ranges don't include the ending number. If you use them please
keep the semantics to avoid confusion for Pythonistas.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managemen
I wonder if `-5` would not be recognized as an option
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-833454305
I've grepped the source three for `autopatch` and there seem to be no
documentation for the options anywhere, except the inline comment. Would you
please guide me in documenting this change?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
This allows to apply one single patch.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1673
-- Commit Summary --
* Add the -n option for %autopatch
-- File Changes --
M macros.in (14)
-- Patch Links --
https://github
https://github.com/rpm-software-management/rpm/pull/1673
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668#issuecomment-832554477_
I am just trying to make my life easier here, nothing more. Removals have
negative impact on others :(
I'll open a PR with just `%autopatch -n`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software
What about this: I'll finally shut up about `%apply_patch` if you'll take a
backport of `%autopatch -n` for RPM 4.16.x and we document it as a replacement
for the removal. That way, we can update our Python spec files on Fedora 33 and
further and hopefully also in CentOS Stream 9. (I'd also glad
@hroncok pushed 1 commit.
ae82e016c8ea67048ebc6db4922768eabed10a0f Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/d3bde71ecdd083f19ede619
@hroncok pushed 1 commit.
d3bde71ecdd083f19ede6199d2e7ec1a25707eb5 Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/31a317c32b0e7b74a54b16f
@hroncok pushed 1 commit.
31a317c32b0e7b74a54b16ffe35540623db2a5cc Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/08a1d90e15e724d671847b3
@hroncok pushed 1 commit.
08a1d90e15e724d671847b3b661aa62311a38d1b Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/948cbc19808693de3231a40
@hroncok pushed 1 commit.
948cbc19808693de3231a4083445d2642811cc1e Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/75c9985ecc2a13e8a62cd27
@hroncok pushed 1 commit.
75c9985ecc2a13e8a62cd27cf9d2826e282762d2 Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/65be867de4dd62f5215f12d
@hroncok pushed 1 commit.
65be867de4dd62f5215f12ddd5eda5809a6e57cb Add deprecated %apply_patch, provide
an alternative
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1668/files/3935ad6c6c0309ce3295a42
This is how I'd deal with the removal of %apply_patch.
I opened it as draft, because I have not tested the implementation yet, it also
needs tests and documentation. But before I dive into that, I'd like to
know if this is acceptable.
You can view, comment on, or merge this pull request online a
@torsava Could you please reopen this to
https://github.com/rpm-software-management/python-rpm-packaging ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1546#issuecomment
Thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-821376174___
Rpm-maint mailing list
Rpm-maint@lists.
I guess we are. I want to get the README adapted there but that is not a
blocker for removal from here.
However, let's document the transition in the changelog?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
Ideas for progress:
- [ ] Open a [ticket at Fedora Packaging
Committee](https://pagure.io/packaging-committee/issues) or better send a PR to
[File and Directory
Ownership](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership)
([source](https://pagure.io/pac
> This could be seen as a feature: Allowing %check to examine the generated
> packages
Even better if %check can assert certain attributes (e.g. provides/requires)
etc. are present :+1:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
1 - 100 of 389 matches
Mail list logo
