Case `%triggerin -- %{name} < 1.0-2.new`:
RPM triggers `%triggerin -- %{name} < 1.0-2.new`. It is according to the
description in the documentation [1] (_The %triggerin script is also run when
your package_ (`baz-1.0-2.new`) _is installed or upgraded, should the target
package_
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/869
-- Commit Summary --
* Add the marker to the appropriate expression error messages
-- File Changes --
M rpmio/expression.c (15)
M tests/rpmmacro.at (2)
--
Commit message is corrected according to @pmatilai's comment.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
75ec68392ece1006f1543bd556f64199257b6b32 Add an error message when rpm fails
to open a pipe for shell expansion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/862/files
@pavlinamv pushed 1 commit.
e2677384cde95e69e14979ccac8936874c376652 Add an error message when rpm fails
to open a pipe for shell expansion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/862/files
Removed unnecessary "mb->error = 1;" line.
--
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/862#issuecomment-535370536___
Changed (added the command it's trying to execute and strerror(errno)).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
0226f7c190326c6ab1d7a82f4143fe7e7928192a Add an error message when rpm fails
to open a pipe for shell expansion
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/862/files
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/862
-- Commit Summary --
* Add an error message when rpm fails to open a pipe for shell expansion
-- File Changes --
M rpmio/macro.c (1)
-- Patch Links --
The PR looks good to 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/pull/853#issuecomment-534511744___
Rpm-maint mailing list
Pushed.
--
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/856#issuecomment-534511549___
Rpm-maint mailing list
@pavlinamv pushed 1 commit.
9ae7eb4858f381cad3925c96a0ec1b4d7d9f36cc Correct description of %verbose and
%getconfdir in the macro manual
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/856/files
Changed according to the comment.
--
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/856#issuecomment-534508114___
Rpm-maint
I looked into rpm/doc/manual/macros to check 0 and 1 added into the
builtinmacros[] in PR #853. Values added in PR #853 are correct, but
description of macros %verbose and %getconfdir in manual is confusing. So
that is why I created this PR.
You can view, comment on, or merge this pull
@pavlinamv pushed 1 commit.
e9d4397003b99f0636bbaabb6a9b151145680a1e Add 'string' into query format
extensions in man-pages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/837/files
Mentioning ":string" in that part of man page, will not cause any problems. But
if ":string" is not there, it looks like that it is not supported.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pavlinamv commented on this pull request.
> @@ -1349,6 +1386,13 @@ expandMacro(MacroBuf mb, const char *src, size_t slen)
doShellEscape(mb, s, (se - 1 - s));
s = se;
continue;
+ case '[': /* %[...] expression expans
Cool. It would be great to add a testcase.
--
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-533026052___
@mlschroe: Thank you. The PR looks good to me.
@pmatilai After the mentioned example there is a list of operators that can be
used in a condition after
```
%if
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Could you change file
```
rpm/doc/manual/spec
```
in section "Conditionals" the text after example:
```
%if 0%{?fedora} > 10 || 0%{?rhel} > 7
```
according of the PR?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
8e919739e766840626d17b0891bdc27ac6be776e Prevent dividing by 0 in the
expression evaluation
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/833/files
Thank you. It solves the 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/pull/838#issuecomment-532561398___
Rpm-maint
Yes, there is no need to use ":string". But it is supported.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think that adding ternary operator support to the expression parser is useful
and it will not cause problems in the parsing of the existing expressions.
There is one thing that can be improved -cases like:
```
--eval '%{expr: 1 ?}'
--eval '%{expr: 0 ? 3 : }'
```
returns an error, but
@mlschroe: I like this idea. I checked Fedora spec files and there was no
conflict with "%[... ]".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
3. agree with @pmatilai, changelog entries can be without comments.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/837
-- Commit Summary --
* Add string into query format extensions in man-pages
-- File Changes --
M doc/rpm.8 (3)
-- Patch Links --
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/833
-- Commit Summary --
* Do not allow to divide by 0 in the expression evaluation
-- File Changes --
M rpmio/expression.c (4)
M tests/rpmmacro.at (2)
-- Patch
The comments are incorporated in the new version.
Thank you for the review.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 2 commits.
db00406d78149cfaa0e78fea9426d5642bc6a95e Improve description of conditionals
in spec documentation
c150103aae26475d92ee26d6427a13f9f21890ad Add description of comments in spec
documentation
--
You are receiving this because you are subscribed to this thread
> The constructive solution to the problem would be supporting spec #-comments
> at arbitrary positions, just like the shell does.
Supporting spec #-comments at arbitrary positions can potentially cause some
problems. That is why I looked into spec files and search for occurrences of
#. There
>>Or just leave them as historical reference for future generations to gape
>> at...
> I like this option. :)
Changed. I leave the original names.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
8a1f9ec0f420ba4a5eec64db52c5d86ff6162c03 Correct and update Query formats
documentation
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/827/files
Corrected according to the review.
--
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/828#issuecomment-52945___
Rpm-maint
@pavlinamv pushed 1 commit.
218633033acea714edbbdb6b21a8dba8aa3d39e8 Disable marker on multiline
expression error messages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/828/files
Moreover to the described corrections (according to the review) I add an
example of example of a query expression.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pavlinamv pushed 1 commit.
209faf3a124341c3e26ba811759a09ec89490603 Correct and update Query formats
documentation
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/827/files
- Improve description of conditionals in spec documentation
- Add description of comments in spec documentation
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/830
-- Commit Summary --
* Improve description of conditionals
>From Fedora documentation [1]: "_To include comments in the spec file, use a #
>character at the start of the line._"
So the text "# with foo" in line
```%else # with foo```
is not a valid comment. If you need to use a comment near %else, you can write
e.g.:
```
%if %{with foo}
...
%else
#
I do not see any problem in the syntax that @pmatilai proposed in his previous
comment:
```%{()?:}```
There are two similar options that are closer to the currently proposed triple
condition operator syntax (#746):
```%{{}?:}```
```%{{}::}```
Using these syntax the example from the previous
Corrected
--
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/828#issuecomment-527410044___
Rpm-maint mailing list
@pavlinamv pushed 1 commit.
b2260fbae4087f55615219376906d066db7341ee Disable marker on multiline
expression error messages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/828/files
If the expression after %{expr: is mutiline like:
%{expr: 0 || 0 ||
0 || 0 |o| 0 ||
0 || 0 || 0 }
then it is better not to support marker pointing to the exact
place of the error.
You can view, comment on, or merge this pull request online at:
> Yeah, known. Missing/wrong arguments to built-in macros are wildly
> inconsistent in how they behave, some emit errors, some just fail silently
> etc.
Evidently better way is to emit an error.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
- in a majority of examples in manual the text after the --queryformat
argument is in double quotes - thus it does not look good to wrote
that A query format is passed to RPM after the --queryformat
argument, and normally should be enclosed in single quotes.
- in case of:
rpm -qa -i
I tested this PR on my laptop.
- The expansion of macro %{getmem:virt}" finishes with an error. It is because
getmem returns 0. This is caused by the fact that function getmem_virt returns
SIZE_MAX. After dividing by 1024^2 it is still to high to fit into return_type
of getmem (unsigned int).
> Please, how does it break the stack semantics?
I am asking because I think that it is easy to implement such a builtin macro.
E.g. popMacro() can be changed such that it returns 1 if an macro was deleted
and 0 if no macro was deleted. After that it will be easy to call popMacro() in
some
Please, how it breaks the stack semantics?
--
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/820#issuecomment-523881821___
A builtin macro
```%undefine macro_name```
removes the last defined _'macro_name'_ from defined macros. But it still
leaves all older definitions of the macro _'macro_name'_. So as @pmatilai wrote
in #115 - "macros stack so undefining doesn't guarantee said macro actually
goes away".
Thus I
> While we're thinking about extending the conditional macro syntax, here's
> another thing to consider:
> The current ? test is only for (non-)existence of macro, which is extremely
> limiting. We could easily make the spec %if expression parser available to
> macro engine, which would give a
It is definitely better.
I tried a multiline expression:
```
rpm --eval '%{expr: 0 || 0 ||
0 || 0 |o| 0}'
```
and **'^'** does not point to the expected position:
```
+error: syntax error while parsing ||: 0 || 0 ||
+ 0 || 0 |o| 0
+error:
> The error messages are simply the same as you get from spec %if conditionals,
> there are no messages added / changed in this PR. That's not to say the
> messages couldn't maybe be improved, but any change needs to account for the
> fact that they're shared between two quite different
The commit message is changed according to the review.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The alignment of the commit message is broken otherwise the patch looks perfect.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Functionality is OK, but error messages can be improved. I tried macros:
%{expr:0 || b} %{expr:4 &|| 0} %{expr:6 + 9 - o -=iu}
in a spec file and error messages were:
error: types must match
error: syntax error while parsing &&
error: types must match
--
You are receiving this because
The patch is correct. The only thing that I propose to change is to is to
refer to the particular commit behind the regression.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Another thing is that this syntax makes it impossible to have colons (':') in
> the output (eg '%{!?foo::}'), which is a limitation the original syntax
> doesn't have'. It obviously has it's own set of limitations and quirks...
Not impossible, but not straightforward. For ':' in the output
It corrects warnings [SC2166] spotted by covscan:
warning: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined. [SC2166]
warning: Prefer [ p ] || [ q ] as [ p -o q ] is not well defined. [SC2166]
Motivated by last the comment in #802. This should fix all [sc2166] warnings
spotted by covscan
Support for extra spaces is ripped out.
--
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#issuecomment-518617194___
Rpm-maint
> And how do you're supposed to know which spaces before and after the 0/1 are
> intentional or not? This must expand literally to either " 0 " or " 1".
According to the specification of triple operator - all spaces
- after '%{?!' or '%{?',
- before and after ':' that divides the operator and
-
>@pavlinamv So then, how does date in GNU Coreutils do it?
rpm task:
_input_: time in an arbitrary time zone, the time zone description
_result_: the corresponding time in UTC.
Command ```date``` _prints_ or _sets_ the system date and time. Neither
_printing_, nor _setting_ is so comp
>There is no reason to break support for this,
@Conan-Kudo, @ignatenkobrain:
The current situation is:
rpm accepts arbitrary text as a time zone description in extended date format.
If the time zone description is not "correct" rpm (silently) change it to UTC
instead of the given time zone
The commit message is changed.
--
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/802#issuecomment-515872259___
Rpm-maint mailing
…0590)
Thanks to Florian Festi for spotting this and proposing the solution.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/802
-- Commit Summary --
* Use [ ] and && to avoid sub processes in find-debuginfo.sh
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/792
-- Commit Summary --
* Test %dnl such that its contents influences its expansion
-- File Changes --
M tests/data/macros.testfile (6)
M tests/rpmmacro.at (15)
_The --set-utc (-Z) option causes patch to set a patched file’s modification
and access times to the timestamps given in context diff headers._
=>
behavior of diff file without date header
_patch normally refrains from setting a file’s timestamps if the file’s
original last-modified timestamp
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/790
-- Commit Summary --
* Add support for 'patch -Z'
-- File Changes --
M build/parsePrep.c (15)
-- Patch Links --
I am sorry, but I do not know any way how to do it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can use %{shrink:...} this way:
```%global godocs docs examples code-of-conduct.md %{shrink:\```
``` }README.md```
"godocs" will be defined:
```xdocs examples code-of-conduct.md README.md```
--
You are receiving this because you are subscribed to this thread.
Thank you very much. It was mistake.
Corrected in the new version.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #776.
--
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/776#event-2469575345___
Rpm-maint mailing list
Fixed in commit 7a227533d1342dccc5b3717554a35dbe2baa9832
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> The exact syntax is subject to endless bikeshedding of course, but one thing
> that strikes me as just wrong are the surrounding spaces everywhere. There
> are no "courtesy spaces" for readability anywhere in rpm macros, I dont think
> this should be any different.
Here are 2 relevant
It is good to have conditionally expanded macros documented in manual before
implementing the triple operator for conditional shortcut (#115). Especially
because I did not find any documentation describing %{?builtin_macro:value} or
the special case %{?load:value}. (See last comment in closed
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/786
-- Commit Summary --
* Describe conditionally expanded macros in manual
-- File Changes --
M doc/manual/macros (43)
-- Patch Links --
E.g. command
```[tester]$ rpm --eval "%{load:xxx}"```
before the patch returns
```error: failed to load macro file xxx[tester]$```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/784
-- Commit Summary --
* Print newline after "failed to load macro file" error is emitted
-- File Changes --
M rpmio/macro.c (2)
-- Patch Links --
In case of #776 the added rpmbuild error looks:
error: Can't read content of file:
/home/tester/reps/776/zdroj/776/tests/testing/build/BUILDROOT/h-1.0-1.x86_64/etc/foo/bar
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/783
Trailing '\' after multiline conditionals or %include will be trimmed.
After the patch lines like:
%if 1 && ( 2 || \
3 )
%endif
will be parsed correctly. The other lines stay unchanged.
A test is added.
You can view, comment on, or merge this pull request online at:
Thank you
--
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/775#issuecomment-506709813___
Rpm-maint mailing list
Please, should the second %if look like this (I added \ at the end of the first
line)?
%if 1 && ( 2 || \\
3 )
%endif
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pavlinamv commented on this pull request.
> @@ -178,13 +179,17 @@ static int dateToTimet(const char * datestr, time_t *
> secs, int * date_words)
if (*secs == -1) goto exit;
+if (tzname[1][0] == 0)
+ rpmlog(RPMLOG_WARNING, _("time zone in %%changelog not in tz da
pavlinamv commented on this pull request.
> @@ -44,7 +44,8 @@ static int dateToTimet(const char * datestr, time_t * secs,
> int * date_words)
struct tm time, ntime;
const char * const * idx;
char *p, *pe, *q, *date, *tz;
-char tz_name[10]; /* name of ti
pavlinamv commented on this pull request.
> @@ -178,13 +179,17 @@ static int dateToTimet(const char * datestr, time_t *
> secs, int * date_words)
if (*secs == -1) goto exit;
+if (tzname[1][0] == 0)
+ rpmlog(RPMLOG_WARNING, _("bogus TZ database name in %%chang
Warning instead of info is emitted (in the latest version).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Corrected in the latest version.
--
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/739#issuecomment-501619925___
Rpm-maint mailing
%{? { macro_name } : true : false }
%{? { macro_name } : true }
%{?! { macro_name } : false : true }
%{?! { macro_name } : false }
More detailed description of the notation:
* Between the first chars "%{?" resp. "%{!?" or "%{?! there can not be a
Panu's comments incorporated.
Moreover I think about the problem again. The current implementation does not
need further changes, but it needs to correct comments and add an info if the
description of time zone is not correct. o the first commit in the PR is
omitted and commit "Emit info if
pavlinamv commented on this pull request.
> @@ -30,10 +30,12 @@ static int sameDate(const struct tm *ot, const struct tm
> *nt)
ot->tm_wday == nt->tm_wday);
}
+#define TZ_MAX_LENGTH 80
Thank you. In the new version dynamic allocation is used.
--
You are receiving
Tests were added. Moreover they already help to show, that exit status 0 is
returned when changelog order fails. Thus I add an additional commit that
corrects this behaviour (regression).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
@pavlinamv pushed 2 commits.
1b44c113b06574e24ae5cd1e92aa2ae132975081 Return non-zero exit status if
changelog order fails
e4dc76e450dd0277fe5f15d4b74df3935dc2ae58 Test effects of time zone in chanelog
timestamp
--
You are receiving this because you are subscribed to this thread.
View
When building RPMs that have %changelog sections with changelog entries with
full timestamps, RPM did not take the time zone into account. Now the timezone
description is taken into account using function tzset(). It handles correctly
timezone descriptions like:
"Europe/London",
"GMT-5", or
Introduced in commit 1da9e83, spotted by covscan.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/737
-- Commit Summary --
* Fix bogus if-condition in find-debuginfo.sh (#735)
-- File Changes --
M
Corrected the commit message of the first commit.
--
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/710#issuecomment-495102226___
pavlinamv commented on this pull request.
> rl->lastConditional = lineType;
spec->readStack = rl;
spec->line[0] = '\0';
+} else if (lineType->id & (LINE_ELIF | LINE_ELIFARCH | LINE_ELIFOS)) {
It is changed in the new version.
--
You are receivi
Panu's comments are incorporated.
--
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/710#issuecomment-494773665___
Rpm-maint
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/710
-- Commit Summary --
* Use already detected line type to identify %if lines
* Consolidate %if condition parsing to one place
* Make "Bad %if condition" error message
Rebase + fixes are done.
--
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/649#issuecomment-493749504___
Rpm-maint mailing list
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/707
-- Commit Summary --
* Add documentation for %getncpus macro
-- File Changes --
M doc/manual/macros (1)
-- Patch Links --
Commit message is corrected.
--
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/649#issuecomment-492949023___
Rpm-maint mailing
1 - 100 of 176 matches
Mail list logo
