@pmatilai funny thing is that somebody recently (yesterday) mentioned this bug
in the Russian Fedora telegram group and today you come up with the fix :)
Can we also backport this to 4.14?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Parsing a spec, even unsuccessfully, will affect the global macro
state in any number of ways that may affect the following operations
in unpredictable ways. Lacking any saner way to do this, reset the
entire global macro state after each spec parse in rpmspec and spec
query code (rpmbuild already
Oh, this would be so great.
--
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/1063#issuecomment-585008636___
Rpm-maint mailing list
Oh. There would be no way to buildrequire an extra. Is that what you mean?
That's a problem.
--
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/1061#issuecomment-584926788_
My old suggestion was `%bcond `, with numeric "default" (zero
for false).
Aside from "inheritance", it might be used instead of
`%bcond_with`/`%bcond_without`. (Whenever I try to choose one, I have to stop
and think which one will give me the right default. I don't think I'm alone in
that.)
``
This is a take on #949 as described in
https://github.com/rpm-software-management/rpm/pull/949#issuecomment-580354653
Original Patch is rebased to have access to the new rpmMacroIsDefined()
function.
Patches should probably be squashed before merging. Keeped them separate to
make review easier.
I'm not all that familiar with ndb internals: how is this different to the
regular --rebuilddb just skipping any headers it finds invalid? Or to turn the
question around: is there a reason why this could/should not be used on all
--rebuilddb operations (on ndb)?
--
You are receiving this beca
...and perhaps there should be that primitive to entirely suppress macro
expansion (as per the %{literal:...} suggestion in #1049, which simply expands
to its literal, unexpanded argument. But as literal is a macro type now, maybe
that should be called %{verbatim:...} instead. Dunno.
--
You ar
pmatilai commented on this pull request.
> @@ -72,6 +72,7 @@ to perform useful operations. The current list is
%define ... define a macro
%undefine ... undefine a macro
%global ... define a macro whose body is available in global context
+ %{body:...}
Some infrastructure issue is causing CI builds on rawhide failing
intermittently with "service temporary unavailable" -type errors which go away
by persistently resubmitting the builds, but this is not productive use of
anybody's time. So as of now, rawhide CI is disabled until further notice.
voxik commented on this pull request.
> @@ -72,6 +72,7 @@ to perform useful operations. The current list is
%define ... define a macro
%undefine ... undefine a macro
%global ... define a macro whose body is available in global context
+ %{body:...} lit
Some open questions:
- Should the argument be expanded first, like doFoo() does? Using the literal
value has its pros but I guess its cons too.
- Is raising an error on undefined macro a reasonable thing to do? If not, what
should it do on undefined macros?
I was also tempted to add %{opts:...}
Fixes: #582
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1064
-- Commit Summary --
* Implement %{body:...} built-in for retrieving the literal macro body
-- File Changes --
M doc/manual/macros (1)
M rpmio/macro.
Good question, which I think settles the name as well: the argument is a macro
name, so it's not the opposite of %{expand:...} at all but a specific thing
that in rpm terminology is known as the macro body, so why make this any more
complicated... lets just call it %{body:...} and be done with i
RFC only for now: if we do this then we'd really want to export options
natively to Lua too, and probably some other stuff too.
--
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/p
Merged #1053 into master.
--
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/1053#event-3025934733___
Rpm-maint mailing list
Rpm-mai
Accessing macro arguments via rpm.expand("%1") etc is tedious,
non-intuitive and subject to all sorts of expansion issues. Make
the argument macros available as a native Lua table (named "arg"
for consistency with -p scriptlet arguments) with their
literal values - the arguments are already m
Is the argument a macro name or some generic string? I.e. is it
`%{body:_builddir}` which should then return ` %{_topdir}/BUILD`? Or is it
`%{noexpand:%_builddir}` which then should only do one level of expansion? I
find the latter a bit weird.
--
You are receiving this because you are subscri
pmatilai commented on this pull request.
> @@ -514,6 +514,22 @@ static ARGV_t runCmd(const char *cmd,
return output;
}
+static ARGV_t runCall(const char *cmd,
+const char *buildRoot, const char *fn)
+{
+
+ARGV_t output = NULL;
+char *fullcmd = rstrscat(NULL, "
Updated to use rpmMacroIsParametric() as the API name, tweaks to commit
message(s).
--
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/1053#issuecomment-584549360_
@pmatilai pushed 2 commits.
c2177646458ef20c6d3cfeeddc0fa7ca34c0d50b Add APIs for testing whether a macro
is defined and whether its parametric
fc98504d59603014edffa53439b96c793ac11f29 Add support for macro-only dependency
generators
--
You are receiving this because you are subscribed to t
pmatilai commented on this pull request.
> @@ -1784,6 +1784,29 @@ rpmDefineMacro(rpmMacroContext mc, const char * macro,
> int level)
return rc;
}
+int rpmMacroIsDefined(rpmMacroContext mc, const char *n)
+{
+int defined = 0;
+if ((mc = rpmmctxAcquire(mc)) != NULL) {
+ if
mlschroe approved this pull request.
--
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/1053#pullrequestreview-356505622___
Rpm-
pmatilai commented on this pull request.
> @@ -1784,6 +1784,29 @@ rpmDefineMacro(rpmMacroContext mc, const char * macro,
> int level)
return rc;
}
+int rpmMacroIsDefined(rpmMacroContext mc, const char *n)
+{
+int defined = 0;
+if ((mc = rpmmctxAcquire(mc)) != NULL) {
+ if
mlschroe commented on this pull request.
> @@ -1784,6 +1784,29 @@ rpmDefineMacro(rpmMacroContext mc, const char * macro,
> int level)
return rc;
}
+int rpmMacroIsDefined(rpmMacroContext mc, const char *n)
+{
+int defined = 0;
+if ((mc = rpmmctxAcquire(mc)) != NULL) {
+ if
25 matches
Mail list logo
