Yup, that'd make it much easier to understand what it's complaining about.
--
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/846#issuecomment-533990668
Merged #849 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/849#event-2653482879___
Rpm-maint mailing list
Rpm-maint
It belongs to all maintained stable series, but whether that includes 4.15.0 is
a slightly different question.
--
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/849#issuecomm
Closed #807 via #849.
--
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/807#event-2653482909___
Rpm-maint mailing list
Rpm-maint@
pmatilai approved this pull request.
Works for me.
Need for this is a good point, especially so with --with/without macros. I'm a
bit reluctant to add *all* (for example --buildpolicy which to my knowledge
nobody ever used, perhaps original developers not counting, and --scm which
affects pat
Oh and thanks for the patch!
--
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/848#issuecomment-533994392___
Rpm-maint mailing list
Merged #848 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/848#event-2653503853___
Rpm-maint mailing list
Rpm-maint
…dor>"
The politically correct version would be changing these all to .in files
with autoconf substituting the correct value during the build process
but that is such a PITA for what is at best a neglible benefit in this case,
it's just not worth it.
Fixes #779
You can view, comment on, or merge
Hmm, we could probably quite easily support per-generator customizable
character blacklist. That could be used to catch whitespace if/when it doesn't
make sense for eg pkgconfig.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitH
Changed and force-pushed. I also tweaked the code so that a negative number is
allowed to make `%[ 3 + %[ 4 - 5]]` work.
--
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/846
Awesome, 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/pull/846#issuecomment-534030947___
Rpm-maint mailing list
Rpm-maint@l
Merged #846 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/846#event-2653832413___
Rpm-maint mailing list
Rpm-maint
This whole thing is a seriously powerful and cool thing. Million thanks for all
the work, @mlschroe !
--
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/846#issuecomment-53403
Closed #115.
--
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/115#event-2653856761___
Rpm-maint mailing list
Rpm-maint@lists.rpm
So thanks to @mlschroe , we now have much more than originally bargained for.
See
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/macros#L238
for docs and
https://github.com/rpm-software-management/rpm/blob/796104e68a0a4b2e60f8e9b47293055a3159a8eb/tests/rpmmacro.at#L248
+
Superceded by @mlschroe 's work to add ternary operator to expression parsing
and wiring all that into the macro engine, closing.
Thanks @pavlinamv for your initiative on this though, I do think it was vital
for getting the ball rolling on the whole thing!
--
You are receiving this because you
Closed #746.
--
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/746#event-2653949216___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
Simple(r) fix proposal in PR #850
--
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/779#issuecomment-534046307___
Rpm-maint mail
Fine with me ;)
--
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/779#issuecomment-534052426___
Rpm-maint mailing list
Rpm-maint@
Also reduce the number of alloc/free calls by adding ValueSetXXX()
variants that change a value.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/851
-- Commit Summary --
* Free memory leak in unary op handling
-- File Chang
pmatilai approved this pull request.
Indeed, thanks for spotting & patching!
--
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/851#pullrequestreview-291709857__
Merged #850 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/850#event-2654091223___
Rpm-maint mailing list
Rpm-maint
Closed #779 via #850.
--
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/779#event-2654091227___
Rpm-maint mailing list
Rpm-maint@
Considering ack'ed as per
https://github.com/rpm-software-management/rpm/issues/779#issuecomment-534052426
--
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/850#issuecomment-
Merged #851 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/851#event-2654092110___
Rpm-maint mailing list
Rpm-maint
Upstream rpm doesn't *have* any info files, so I cannot comment on contents of
those.
Other than that, I guess we'll just have to agree to disagree, I don't know how
to make it any more obvious in the manual, in the structure that rpm manual
uses.
--
You are receiving this because you are s
Closed #662.
--
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/662#event-2654125188___
Rpm-maint mailing list
Rpm-maint@lists.rpm
> Imagine if ewt back in the day had declared that RPM would only ever accept
> the 34-or-so groups of the time.
I'm not talking about *hardcoding* a set of groups, but rather an externally
maintained set of allowed values.
> I am not sure what you mean by "typoed junk".
Having seen a few GUI
Closed #689.
--
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/689#event-2654158132___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Since there hasn't been any new developments or issues surrounding this,
closing.
Opening up the buildtime headers under construction to spec inspection is a
Pandora's box I have no wish to open at this time.
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
Here are some points to discuss:
1) The ternary op currently uses the same logic as rpmExprBool to evaluate if
the condition is true or not. But the other logical operators (!, &&, ||) only
work with integers. We should make this consistent, either by changing ternary
to only accept integers or
Closed #834.
--
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/834#event-2654226267___
Rpm-maint mailing list
Rpm-maint@lists.rpm
(We can also go the perl/python/... way and change the || operator so that it
no longer returns a bool, but the first true term. I.e. `"%foo" || "bar"`.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
Built-in macros either take arguments via %{foo:...} or don't, raise
errors on unexpected and missing arguments.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/853
-- Commit Summary --
* Codify built-in macro argument accep
Note that while for most built-ins such as %{getenv:...} a non-empty argument
is clearly required, but there are some cases where an empty argument could be
allowed, such as an empty %{echo:} which this turns into an error. I could be
convinced to add a third form where the argument is optional.
No objections from my side. Note that `%{echo:%nil}` would still work. I guess
you tested `gn` instead of `g` on purpose?
You may also want to add a test in doFoo so that this also gets checked after
expansion. Or maybe only check this in doFoo?
--
You are receiving this because you are subscr
This makes a couple of related changes to '%autosetup -S git' to make
debugging using the rpm build dir as a git worktree significantly
easier:
- creates a branch named "rpmbuild" at the initial commit, switches to
it, and sets the branch's upstream to master so that in the work tree
things lik
Yup, the thing with g vs gn is that g reflects whether ':' is there or not, and
gn reflects whether there's something after it: macros that do not accept
arguments must not have g, and macros that do need to have both (but non-zero
gn implies non-NULL g).
And yeah, ```%{echo:%{nil}}``` would wo
38 matches
Mail list logo
