[Rpm-maint] [rpm-software-management/rpm] Extend %changelog to support full timestamps (#903) (#93)
The newly accepted date format is Mon Jan 6 09:02:22 CEST 2016 (like output of "date" command). Original format "Mon Jun 6 2016" is still supported. Resolves: http://www.rpm.org/ticket/903 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/93 -- Commit Summary -- * Extend %changelog to support full timestamps (#903) -- File Changes -- M build/parseChangelog.c (93) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/93.patch https://github.com/rpm-software-management/rpm/pull/93.diff -- 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/93 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Extend %changelog to support full timestamps (#903) (#93)
@pavlinamv pushed 1 commit. c95c6ff fixed "CEST 2016" in extended format decoded as part of author name -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/93/files/d4f90c9625fc7f5694bd57802e1e529cbc00d7ff..c95c6ff86df0e14bd85d0d746dd148e2457a52b2 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API documentation generation broken with doxygen > 1.8.7 (#131)
The problem is because: > In version 1.8.8 a change has taken place about handling files > with unknown / unsupported extension. Till that version they were seen as > C-like files. In version 1.8.8 and up they are skipped, but it is possible > to use your own extension and map it to a supported version. Thus files doc/librpm/Doxyheader doc/hacking/Doxyheader are skipped and that is why "Modules" are missing. To solve the problem: Add to both files "Doxyheader" an extension. According to the extension, change files "hacking.doxy.in" and "librpm.doxy.in" as it is in change.diff (for extension "xxx"). Another option is to configure "hacking.doxy.in" and "librpm.doxy.in" to process files without extension (no_extension). Doxygen would start to go through all files without extension - README, INSTALL, ... as C files, which could lead to undesired results. Therefore I prefer the first option. [change.txt](https://github.com/rpm-software-management/rpm/files/753006/change.txt) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/131#issuecomment-277520879___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix unclear %dev error message (#155)
Mistakes in %dev as "%dev(c,b,0) /dev/lirc" will give unclear errors like: Missing devmajor in %dev b Make a copy of the all the arguments in brackets to make the error clear: Missing devmajor in %dev(c,b,0) You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/155 -- Commit Summary -- * Fix unclear %dev error message -- File Changes -- M build/files.c (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/155.patch https://github.com/rpm-software-management/rpm/pull/155.diff -- 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/155 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: option for initial-only content in files (#152)
I try to sum up what I think that should be done with this issue. Name is unresolved. I chose "mutable" as an interim one. %mutable will be defined for REG files and LINKs. Behavior : - if a file/link is the same as in new package (it has the same contents, gid, uid and mode)/(is the same), then touch it (set time stamp for REG files). - if a file/link is the same as in old package (it has the same contents, gid, uid and mode)/(is the same), then upgrade it as "normal" file/link - else do nothing (It means, that for config files/links rpm will behave similarly as %config(noreplace), but without creation backup files and warnings. The only difference is that this behavior takes files with the same contents but different uid or gid or mode as different. For %config(noreplace) such files are similar. ) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/152#issuecomment-293501438___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: option for initial-only content in files (#152)
In my opinion update policy is a good term and good way of thinking about it. As I see the actual RFE needs two policies. (I think that two update policies are better that one with and without a parameter) %updatepolicy(mutable) - install and update until it is modified, after that do not care. Only if the file does not exist, install it again. %updatepolicy(installonly) - only if the file does not exist, install it, else do not care. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/152#issuecomment-293818931___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add %mutable and %noupdate update policies (#152) (#200)
%mutable - is defined for files and links. It means update until modified. In more details: - if a file/link is the same as in new package then touch it, - if a file/link is the same as in old package then upgrade it as "normal" file/link, - else do nothing. %noupdate - is defined for all file types used internally by rpm. It is for cases, where packager wants just the initial content, never to be touched by rpm again. In more details: - if the file does not exist, then create it, - if the file exists, then do nothing. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/200 -- Commit Summary -- * Add %mutable and %noupdate update policies (#152) -- File Changes -- M build/files.c (4) M lib/rpmfi.c (136) M lib/rpmfi_internal.h (25) M lib/rpmfiles.h (2) M lib/transaction.c (15) A tests/data/SPECS/updpolicy.spec (38) M tests/rpmi.at (254) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/200.patch https://github.com/rpm-software-management/rpm/pull/200.diff -- 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/200 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove unnecessary memset (#201)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/201 -- Commit Summary -- * Remove unnecessary memset -- File Changes -- M lib/rpmfi.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/201.patch https://github.com/rpm-software-management/rpm/pull/201.diff -- 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/201 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
The separator character should be chosen such that it will not cause problems
with old macros:
%{?condition:true}
or
%{!?condition:false}
If we define, that:
separator operator is the first '!' after ':', which is not nested in {}
or in ()
it will change interpretation of macros like:
%{?write_errors: You did not respond! It is a mistake.}
--
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#issuecomment-297976142___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
I do not see any possibility how to define sensible syntax of the triple
operator, without possible causing problems for macros %{?condition:true} and
%{!?condition:false}. Thus I think that adding this macro without additional
changes is not a good idea.
The syntax of the macro should start "%{?condition:" or "%{!?condition:"
But then there is a problem with next separator operator:
E.g if we define syntax
%{?condition:true!false},
where separator operator is the first '!' after ':', which is not nested in
{} or in ()
it will change interpretation of macros like
%{?write_errors: You did not respond! It is a mistake.}
which will change from its original meaning
if "write_errors" is defined, then write "You did not respond! It is a
mistake."
to
if "write_errors" is defined, then write "You did not respond" else write "
It is a mistake."
If we change separator operator from "!" to another character it will not help
us a lot. The mentioned type of mistake will still occur. The only characters
which are different from rpm point of view are "{", "}", "(", ")". To use some
of them is not a good choice too. The triple operator will look very weird and
probably another type of problems occur.
Similarly for a separator operator defined as a sequence of chars.
--
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#issuecomment-299160206___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
Thinking about it some more... Syntax:
%{?condition:{true}!{false}}
%{!?condition:{false}!{true}}
is OK. So if it is acceptable, I will make a patch for it.
--
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#issuecomment-303770661___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make macro %{error:...} cause an actual failure (94e8cd6)
If you want an error message without an actual failure, you can use %{warn:...}
instead of %{error:...}.
--
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/commit/94e8cd6058cba07b5b97785d2cc91566ec267eaf#commitcomment-23793570___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't expand %{verbose:...} argument on false condition (0032ee8)
The patch does not extend the syntax, it corrects the existing implementation
of {verbose:...} and {!verbose:...}.
The example in commit message shows that prior to this patch the syntax already
included {!verbose:...}.
An example of the corrected error in case of {verbose:...}:
$ rpm --eval '%{!verbose:%{echo:is not verbose}}' \
--eval '%{verbose:%{echo:is verbose}}'
Before this patch, it returned:
is not verbose
is verbose
--
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/commit/0032ee8c23bd93a24388b07aafd2dbd32772b328#commitcomment-25121796___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Human readable size in --queryformat (#375)
Closed #375. -- 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/375#event-1500803808___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Python tests are running even python support is disabled (#264)
Closed #264. -- 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/264#event-1537525682___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] macros: closing macro on newline breaks expansion of all later macros (#401)
Closed #401. -- 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/401#event-1542923473___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
rpm behaves correctly. rpm takes into account only the last option '-a number' in the command. So %autosetup -c -T -a 0 -a 1 executes only: /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz because -T disables implicit unpacking of Source0, -a 0 is skipped because it is not the last -a option, -a 1 enables unpacking of Source1 %autosetup -c -a 0 -a 1 executes: /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-data-0.2.tar.gz /usr/bin/gzip -dc /home/brain/Projects/fedora/rpms/nipy-data/nipy-templates-0.2.tar.gz because Source0 is implicitly unpacked. -a 0 is skipped because it is not the last -a option, -a 1 enables unpacking of Source1 For more details see link: https://rikers.org/rpmbook/node70.html#SECTION03541400 -- 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/462#issuecomment-414998372___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
Implicitly (without any option) source0 is unpacked. The -T option disables %setup's normal unpacking of the archive file specified on the source0 line. You can "re-enable"unpacking of the source0 using -a 0 or -b 0. -- 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/462#issuecomment-415008961___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %setup -T -a 0 -a 1 doesn't extract %{S:0} (#462)
Om my VM %autosetup -c -T -a 0 -a 1 .. unpacks only S1 (-a 1 is the last -a option) %autosetup -c -a 0 -a 1 .. unpacks S0 and S1 (because S0 is special and -T is not here, -a 1 is the last -a option), %autosetup -c -a1 -a 2 ... unpacks S0 and S2 (because S0 is special and -T is not here, -a 2 is the last -a option), %autosetup -c -a 0 -a 1 -a 2 -a 3 ... unpacks S0 and S3 (because S0 is special and -T is not here, -a 3 is the last -a option). Please can you give me a reproducer such that %autosetup -a 1 -a 2 unpacks S1 and S2 (with this exact numbers)? -- 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/462#issuecomment-415033354___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: useful lua errors (#545)
Agree. The error message does not help a lot. Some additional info containing whole %anotherluamacro can improve the situation. -- 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/545#issuecomment-424981239___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --setcaps sets empty security.capability when there is no caps (#585)
It is a very good point.
Empty capabilities ('') and no capabilities are different. Because (from
SETCAP(8) man page):
"setting an empty capability set is not the same as removing it. An empty set
can be used to guarantee a file is not executed with privilege inspite of the
fact that the prevailing ambient+inheritable sets would otherwise bestow
capabilities on executed binaries"
If %|FILECAPS? is false for a given package then --setcaps should set no caps.
This is a bug in the current --setcap implementation and it must be corrected.
If %|FILECAPS? is true for a given package then %{FILECAPS} contains textual
representation of file capabilities. In such a case files with no capabilities
and files with empty capabilities satisfies %{FILECAPS}=''. So from the value
%{FILECAPS}='' it is not clear whether a file has no or empty capabilities. I
checked several packages (iputils, gnome-keyring, httpd, mtr). After package
installation the files with %{FILECAPS}='' usually have no capabilities. But
because
1) empty capabilities are more strict then no capabilities and
2) %{FILECAPS} can be used as a querytag to print out capabilities of a file
I think the correct solution is: if %{FILECAPS} = '' then capabilities should
be set empty. In case of no capabilities %{FILECAPS} must contain a different
value. And with respect to this correct --setcups.
There is another problem:
rpm -V does not differ between no capabilities and empty capabilities now. E.g.
if a file /usr/bin/mc has empty or no capabilities rpm -V verifies both as
correct. It should be 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/issues/585#issuecomment-435394654___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --setcaps sets empty security.capability when there is no caps (#585)
The previous comment is not correct.
If %|FILECAPS? is true and file has empty capabilities, then %{FILECAPS}='='.
It is different from no capabilities. Thus the patch from Markus Linnala
https://github.com/rpm-software-management/rpm/pull/586
works correctly.
There is still a problem that rpm -V does not differ between no capabilities
and empty capabilities.
--
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/585#issuecomment-435800881___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
Notation
%{?{condition}:true:false}
%{!?{condition}:false:true}
looks promising for me.
1) It is because it causes no problems in old macros.
2) It looks quite naturaly, the only difference from the most expected notation
are curly baces around the condition. (They are added to reach 1).
Similar notations that can be chosen instead:
%{?{condition}:true!false}
%{?{condition}?true!false}
%{?{condition}?true:false}
..
More detailed description of the notation:
- Between the first chars "%{?" resp. "%{!?" or "%{?!" there can not be a
space.
- On the other hand arround {condition} and :, there can but not need to be a
space.
- In {condition}, there can be a space before or after condition.
It should be highly recommended to use %{true} and %{false} instead of true or
false.
It can not cause problems in the existing macros because:
If curly brackets around condition occure in the existing spec file, the
current implementation resolves
%{?{condition} } to "" (all cases without the space between '?' and '{'
are resolved to "")
and
%{? {condition} } resolves to "%".
E.g. %{!?{-n}:%{1}}%{?{-n}:%{-n*}} expands in all cases to "".
It means that the spec behaves differently than the author expected.
If the implementation will be done wisely it can change the expansion to more
natural case:
%{!?{-n}:%{1}}%{?{-n}:%{-n*}} -> expand to %{1} or %{-n*} according to "-n".
The only different unexpected beaviour for the current spec files can arise in
a case like: %{!?{condition}:sth1:sth2}. In such a case the current
implementation expands it to "" and the new behaviour will expand it to sth1 or
sth2. Thus it can potentially change behavior from the current one to different
unexpected behavior. But such case is highly unlikely and the original behavior
is already different from the expected one (as explained above). So it changes
one unexpected behavior to some different one.
--
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#issuecomment-445264535___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
You are correct %{?:condition:true:false} and %{?!:condition:false:true} also
should not conflict with the current macro usage. I am OK with this notation
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/issues/115#issuecomment-445346490___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
This pull request contains 6 patches: - patches 1, 2, 3: contain refactoring of the existing without any functional change. It is a preparation for the patch 5. - patch 4: improves "Bad %if condition" error message - patch 5: adds support of %elif operators (%elif, %elifarch, %elifos) - patch 6: adds tests for %elif operators If it will be requested, I can add patch 7 that restricts usage of %elif, %elifarch and %elifos such that: In scope of %if you can use only %elif, in scope of %ifos you can use only %elifos and similarly for %ifarch. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/613 -- Commit Summary -- * Refactor variable "match" to have clear meaning * Move checking whether %if condition will be resolved to the right place * Refactor expression expansion evaluation in parseSpec * Make "Bad %elif condition" error message more informative * Support %elif operators (#311) * Add tests for %elif, %elifos, %elifarch -- File Changes -- M build/parseSpec.c (85) M build/rpmbuild_internal.h (2) M build/spec.c (2) A tests/data/SPECS/iftest.spec (116) M tests/rpmmacro.at (104) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/613.patch https://github.com/rpm-software-management/rpm/pull/613.diff -- 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/613 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
pavlinamv commented on this pull request.
> @@ -421,8 +422,8 @@ int readLine(rpmSpec spec, int strip)
match = parseExpressionBoolean(s);
if (match < 0) {
rpmlog(RPMLOG_ERR,
- _("%s:%d: bad %%if condition\n"),
- ofi->fileName, ofi->lineNum);
+ _("%s:%d: bad %%if condition\n expanded line:
%s"),
+ ofi->fileName, ofi->lineNum, z);
Yes, there is a mistake in the commit message, it should talk about %if, not
about %elif. In the newer version of the PR I will correct this patch to have
common style and its commit message.
--
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/613#discussion_r246014711___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
pavlinamv commented on this pull request.
> lbuf = spec->lbuf;
SKIPSPACE(lbuf);
if (lbuf[0] == '#')
isComment = 1;
- /* Don't expand macros (eg. %define) in false branch of %if clause */
-if (!spec->readStack->reading)
+/* Don't expand macros after %elif (resp. %elifarch, %elifos) in false
branch */
+if (ISMACROWITHARG(lbuf, "%elif")) {
+ if (!spec->readStack->readable)
The need to test for `ISMACROWITHARG(lbuf, "%elif")` in that place is caused by
the current implementation of the parser and not by tracking by "reading" and
"readable".
Parsing of a line in spec file consists of these for us important actions (in
this order):
1) storing the line from file into buffer
(function `copyNextLineFromOFI`)
2) deciding whether the line should be expanded
(beginning of function `expandMacrosInSpecBuf`)
3) if it should be expanded then expansion of the line
(second part of function `expandMacrosInSpecBuf`)
4) checking if the line starts with a rpm conditional and according of it
doing appropriate actions
(second part of function `readLine`)
Before adding `%elif`, the decision 2) whether the line should be expanded
depends only on previous lines of the spec file. But after adding `%elif` it
depends on the new line stored in the buffer, too. Because if the line starts
with `%elif` then `if !readable` line must not be expanded, otherwise it must
be expanded.
If there should be a variable that is used for deciding whether the new line
should be expanded or not, then the variable must be set after 1). So it can be
set
a) in the second part of function `copyNextLineFromOFI` before calling
`expandMacrosInSpecBuf`, or
b) in the first part of `expandMacrosInSpecBuf`.
In the current patch the test is done in position b) and instead of setting a
variable and then deciding according to it, the test is straightforwardly used.
Thus I do not see any improvement in changing tracking variables to allow
decision 2).
To be precise I should add into `expandMacrosInSpecBuf` tests for
`ISMACROWITHARG(s, "%elifarch")` and `ISMACROWITHARG(s, "%elifos")` too. And to
be extremely precise with solve all corner cases I should add `ISMACRO(s,
"%endif")` and `ISMACRO(s, "%else")` too. Because they all can change the
potential to expand in that line. ( But usually only after `%elif` is expected
to be a macro).
--
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/613#discussion_r246021478___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
If this comment is about patch "Move checking whether %if condition will be resolved to the right place" then the reply is: I will improve the commit message. It should not speak about the "right place". But it is not just refactoring because of `%elif`. The current place is not optimal because: In function `readLine()`, all of conditionals (`%else`, `%endif`, `%ifarch`, `%ifnarch`, ...) except for `%if` are parsed in one place. But `%if` is parsed in two different places (there is `ISMACROWITHARG(s, "%if")` twice). I think that it is better to consolidate these two `ISMACROWITHARG(s, "%if")` into one place. And after that optimize it to be coded similarly as `%ifarch`, `%ifos`, ... -- 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/613#issuecomment-452327087___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
pavlinamv commented on this pull request.
> @@ -360,7 +364,10 @@ do { \
int readLine(rpmSpec spec, int strip)
{
char *s;
-int match;
+char *z;
+int match = 0;
+int isIf = 0;
+int isElif = 0;
Yes a line can be `%if` line, `%elif` line or "another" line.
Yes, in some earlier version were only two variables: `isElif` + `match`. The
meaning of variable `match` was quite unclear.
` 0 %if or %else line + condition after %if is not satisfied`
` 1 %if or %else line + condition after %if is satisfied`
`-1 ... %if or %else line + condition after %if is bad, or `
` .. not %if or %elif line`
`match` was used for both: deciding whether line is `%if` line and deciding,
whether the condition after `%if` (resp. `%ifos`, ...) is satisfied.
That is why I made the first patch of this PR. In the patch I refactored
`match` into two variables: `match` + `isIf` to have clean meaning and usage.
Variables `isIf` and `isElif` can be consolidated into one. I will change it.
--
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/613#discussion_r246402912___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
pavlinamv commented on this pull request.
> spec->readStack = rl;
spec->line[0] = '\0';
+} else if (isElif) {
+ spec->readStack->reading = match && spec->readStack->readable;
+ if (spec->readStack->reading)
+ spec->readStack->readable = 0;
+ spec->line[0] = '\0';
+ match = -1;
Thank you for the comment.
> For example, isn't elifEnabled practically the same thing as checking
> whether ->next non-NULL?
No. Because `elifEnabled = 1` if some `%if` condition starts and does not reach
`%else` or `%endif`. `->next` is non-NULL if some `%if` starts and does not
reach `%endif`. And from all other `->` variables you can not decide whether in
the current `%if` `%else` was reached or not. Yes the meaning and name of the
variable can be different, but there must be some variable containing this
information.
> Also makes me wonder if it'd fit in more naturally if you just treated
> %elif as a new %if inside an %else, which is what it ultimately is.
> %elif is just syntactic sugar after all.
This alternative approach does not optimize variables, or complexity of the
program:
Programming `%elif` like a "special `%else` `%if` " will lead into:
- `->elifEnabled` must stay in the code with this approach too. (Of course no
metter how it is implemented, there is need for testing whether all %elif's are
on their propper places).
- even if in this approach `->reading` can be omitted, there must be some new
variable counting how nested the `%elif` is. It is because after `%else` resp.
`%endif`, function `readLine`, must close the main `%if`, and all other
"auxiliary %else %if's" that emulate `%elifs`.
Thus it will result into code that is not better than the current one.
Current approach corresponds to defining %elif straightforwardly according to
its syntax and the alternative approach corresponds to defining %elif using %if
inside an %else. Both are correct definitions, but for me the current looks
more readable and natural.
--
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/613#discussion_r246720538___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Implement %elif (issue #311) (#618)
This is a new version of #613. All suggestions that are in #613 are included or in the discussion is described why they are not included. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/618 -- Commit Summary -- * Refactor variable "match" to have clear meaning * Consolidate %if condition parsing to one place * Refactor expression expansion evaluation in parseSpec * Make "Bad %if condition" error message more informative * Supported operators: %elif, %elifarch, %elifos. * Add tests for %elif, %elifos, %elifarch -- File Changes -- M build/parseSpec.c (81) M build/rpmbuild_internal.h (11) M build/spec.c (2) A tests/data/SPECS/iftest.spec (116) M tests/rpmmacro.at (103) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/618.patch https://github.com/rpm-software-management/rpm/pull/618.diff -- 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/618 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
pavlinamv commented on this pull request.
> spec->readStack = rl;
spec->line[0] = '\0';
+} else if (isElif) {
+ spec->readStack->reading = match && spec->readStack->readable;
+ if (spec->readStack->reading)
+ spec->readStack->readable = 0;
+ spec->line[0] = '\0';
+ match = -1;
> I wasn't asking for detailed explanation against my remarks, just pointing
> (partial) overlap and throwing possible ideas to explore.
I think that if you had a concrete remark and I am not planning to involve it
in next version of PR, then it is fair to explain why. And usually it is better
to explain it precisely.
> Like said: knowing what's involved and the surrounding code, rethink from
> scratch and see what comes up, you can almost always do better the second or
> even third time around.
I rethink this code many times and for me it results in the refactorization
patches before the "elif" patch.
> You mentioned corner cases that this doesn't take into account - take them
> into account from the beginning the in the next round.
Yes I mentioned those corner cases. Of course I planned to solve them - but in
following PR. There is no gain from solving it in this PR.
> I'm absolutely positive that if-elif-else-endif branching can be expressed
> and tracked in a more coherent manner than we have here. As discussed in
> private this ugly code to begin with, take the opportunity to improve the
> foundation instead of duct-taping over it. Sometimes there's no choice but to
> duct-tape due to time or API constraints but neither is an issue here.
If you have some concrete issues or improvements of the PR, please send me
them. But I am happy with this code.
--
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/613#discussion_r247311274___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make list of dependencies in test/README consistent (#619)
The other entries in the list of dependencies are names of provides. But gpg2 is name of executable and the command is not in package gpg2 or in a package with gpg2 in provides. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/619 -- Commit Summary -- * Make list of dependencies in test/README consistent -- File Changes -- M tests/README (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/619.patch https://github.com/rpm-software-management/rpm/pull/619.diff -- 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/619 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
Closed #613. -- 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/613#event-2070220111___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
Corrected version is in PR #618. -- 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/613#issuecomment-453772152___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
Before this commit, rpm handles text after %else or %endif
nonconsistently and does not give any feedback:
- a text after %else was expanded according to evaluation
of the previous %if.
- a text after %endif was expanded according to evaluation
of the previous %else, resp. %if if there was no %else.
So in the current spec files there exist lines like:
%else %if 0%{?centos}
%else !use_embedded
%endif # with_perf
(comments must have '#' at the start of the line to behave as defined)
So to be consistent and clear, this warning is added. It looks
for example:
warning: line 93, no text in allowed after %else
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/625
-- Commit Summary --
* Warn if a text is after %else or %endif
-- File Changes --
M build/parseSpec.c (24)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/625.patch
https://github.com/rpm-software-management/rpm/pull/625.diff
--
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/625
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
> the two cases only differ by the actual token, you should handle them
> by the same code and without unnecessary + 5 "magic" calculations.
Will be improved in the next version.
> auxBuf is not used to modify the contents so it should be const
Will be changed in the next version.
> Having several places parse the same tokens is generally an indication
> of something being wrong or at least sub-optimal, why can't this be
> handled where %else and %endif are otherwise parsed? (I'd think macro
> expansion shouldn't matter for this)
It is because logically it should be done before the macro expansion.
In majority of cases macro expansion shouldn't matter. But there are corner
cases like:
%else %{?iii:this}
%else %define name value
such that the macro expansion matter for them. I prefer to solve all possible
cases to handle the warnings where %else and %endif are otherwise parsed.
Moreover in the future there may be another cases, where macro expansion should
matter in more cases e.g. %elif.
> "Not allowed" as an expression doesn't work this kind of context: it's
> not question whether you have a permission to place text someplace or
> not, it's simply a syntax error.
I will change the error message in next version.
> Text following %endif is obviously a syntax error, but in case of %else
> I think it'd be more useful to simply treat any following text as a part
> of the else-branch. Ie, make "%else %if 0%{?centos}" kind of thing
> actually work.
There are 4 types of texts after %else that I saw:
a) %else # 0%{?with_systemd}
b) %else %if %{with_prerelease}
c) %else if 0%{?rhel} >= 6
d) %else !use_embedded
Treating a text after %else as a part of the else-branch will improve a) and
b), but it will not solve case c) and especially d). That is why I would prefer
the warning in both cases.
--
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/625#issuecomment-460289113___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
The pull request is reopened (PR #618 will be closed). -- 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/613#issuecomment-460559995___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
Reopened #613. -- 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/613#event-2117852085___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement %elif (issue #311) (#618)
The pull request is closed (returned to #613). -- 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/618#issuecomment-460560615___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement %elif (issue #311) (#618)
Closed #618. -- 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/618#event-2117856891___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
> Well, c) and d) would depend on context, but most likely they'd end up in
> syntax error, which is ok.
Yes, but not in all cases.
> OTOH the closest relative to spec %if's would be the C pre-processor which
> simply warns: warning: extra tokens at end of #else directive
>So perhaps that is the best option here afterall.
OK I think so.
>Looking at the macro expansion behavior, the current behavior is certainly
>very broken. Consider the following:
>%if %{val}
>%{echo:yeah}
>%else %{echo:moo}
>%{echo:nay}
>%endif
>"moo" gets echoed iff %{val} evaluates to true, which is just crazy. At this
>point I do have to agree with you that %else needs to be parsed before
>deciding whether to expand a line or not, and ditto %endif.
As it is described in the commit message of the PR:
* a text after %else is expanded according to evaluation of the previous %if.
* a text after %endif is expanded according to evaluation of the previous
%else, resp. %if if there was no %else.
This was my original reason for creating the patch.
> And if we're adding a warning for text after %else, then perhaps neither of
> these lines should ever be expanded.
I looked to the code and as usually it is more complicated. There are two
versions of the "line" in spec file. One before the macro expansion and the
second is after the expansion. So
1) if a line (before expansion) is:
%else %define name value
then it is incorrect before the expansion and it looks correctly after the
expansion. Thus a check of a text after %else must be done before the expansion.
2) on the other hand a macro (e.g. "%debug_package" from macros.in) can be
expanded to a text containing more lines including some %if + %else lines.
-> I) Thus we can not decide what is the current type of the line before
expansion. The final decision must be done after expansion. In the readLine
function where it is done now.
-> II) a second check of a text after %else must be done after expansion (if
a warning was written in the first check, then this check should not write any
warning). This should be improved in the next PR.
-> III) There is a large area for errors when expanding %if's from a file.
Lets start with an example:
Add into a macro file:
```
%mem1 \
%if 1 \
%global blabla1 \
%else \
%global blabla2 \
%endif\
%{nil}
```
try:
```
rpm --eval '%blabla1' --eval '%blabla2' --eval '%mem1' --eval '%blabla1' --eval
'%blabla2'
```
the result is:
```
%blabla1
%blabla2
%if 1
%else
%endif
```
So in expansion of %if - %else - %endif from macro files there is a bug. Macros
are expanded no matter whether %if/%else holds or not. Thus they are defined
and undefined no matter whether %if/%else holds or not. This is another and
bigger problem that should be solved. But it is not part of the problem that
this PR solve.
--
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/625#issuecomment-461151723___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
> %if-%else-%endif is a spec-only construct, there's no support for them in the > actual macro engine. Macro files are purely declarative and doesn't support > any sort of conditionals. You can of course define a macro that contains and > %if-%else-%endif but that will only work as expected when expanded in a spec. Please where is it documented? I am asking because there are macro files, that contain %if. For example: /usr/lib/rpm/macros.d/macros /usr/lib/rpm/macros.d/macros.lua /usr/lib/rpm/macros.d/macros.cmake /usr/lib/rpm/macros.d/macros.selinux-policy > I'm thinking the only sane interpretation would be that only the opening %if > can appear from a macro expanded on that line. Please can you explain why? In this case there is still a problem with detecting %else and %endif lines too? What %if's that are expanded from an already expanded macro? >So maybe it's just me, but this completely failed to drive the point across. >"expanded according to evaluation" basically reads to me that "expansion >depends on the evaluation" which makes me think "so, it's an %if, what do you >expect?" Adding something like "contrary to expectations" would help make it >more obvious what the problem is. >Which is just to say that concrete tends to work better than abstract in >commit messages and the like. Maybe something to the tune of "contrary to >expectations, the entire %else line is considered to be a part of the >preceeding %if block", and with a concrete example of what actually happens. I will improve the commit message. -- 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/625#issuecomment-461789707___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
In the previous comment should be /usr/local/lib/rpm/macros instead of: /usr/lib/rpm/macros.d/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/625#issuecomment-461790435___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
>...because obviously, you cannot detect the %else before expanding a line that >should not be expanded. Does that make it clearer? Yes, the idea is clear now and I agree with this limitation. It evidently does not worth the effort to solve all %if/%else/%endif corner cases. I read comments in PR:#613 and apply them on this patch, so here is a new 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/625#issuecomment-464060933___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add descrption of conditionals into the spec documentation (#633)
Document briefly conditionals and the fact that they work correctly in spec files only. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/633 -- Commit Summary -- * Add descrption of conditionals into the spec documentation -- File Changes -- M doc/manual/spec (20) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/633.patch https://github.com/rpm-software-management/rpm/pull/633.diff -- 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/633 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
I am waiting with a new version of this PR for finishing of PR #625. -- 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/613#issuecomment-465034301___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFE] Add limits to autopatch macro (#626)
I like this idea. Maybe I would recommend to change the names of parameters: -l -u from upper and lower bounds, or -m -M as minimum and Maximum. Otherwise it looks OK for 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/626#issuecomment-465138491___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove %ifarch-%endif from %debug_package macro (#635)
In PR #625 Comment 6 Panu wrote:
*"%if-%else-%endif is a spec-only construct, there's no support for them in the
actual macro engine. Macro files are purely declarative and doesn't support any
sort of conditionals."*
In maco file macros.in there is macro
```
%debug_package \
%ifnarch noarch\
%global __debug_package 1\
%_debuginfo_template\
%{?_debugsource_packages:%_debugsource_template}\
%endif\
%{nil}
```
that contains %ifnarch and thus it should be corrected.
Currently after expanding of macro %debug_package (e.g. in some spec file)
global definition
```
%global __debug_package 1\
```
is expanded in all cases.
--
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/635___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
Yesterday's comments are incorporated in the last 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/625#issuecomment-467435989___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
The patches are 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/625#issuecomment-467456685___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if a text is after %else or %endif (#625)
The the patch and commit message is changed + the last patch added. -- 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/625#issuecomment-467837401___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove %ifarch-%endif from %debug_package macro (#635)
> Err, what? You trimmed out the relevant part of that quote:
>>You can of course define a macro that contains and %if-%else-%endif but
>> that will only work as expected when expanded in a spec.
The problem is more complicated. Macro written in a macro file that contains
%if-%else-%endif + %global inside will not work correctly even if it is
expanded in spec file. For example use rpm sources and add into macro.in file :
```
%mymacro0 \
%if 0 \
%global bbb0 ccc0 \
%endif \
%{nil}
%mymacro1 \
%if 1 \
%global bbb1 ccc1 \
%endif \
%{nil}
```
then add into "tests/data/SPECS/replacetest.spec"
after the "%install" line two echos:
```
echo %mymacro0
echo %mymacro1
```
and change the line:
```
echo "%{filedata}" > $RPM_BUILD_ROOT/opt/foo
```
to the line:
```
echo "%bbb0 --- %bbb1 --- %name --- %ohouhiuiu" > $RPM_BUILD_ROOT/opt/foo
```
run "make check". Then you can see that
```
%bbb0 --- %bbb1 --- %name --- %ohouhiuiu
```
was expanded into
```
ccc0 --- ccc1 --- replacetest --- %ohouhiuiu
```
you can check it in tests/rpmtests.dir/232/rpmtests.log.
--
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/635#issuecomment-468262215___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove %ifarch-%endif from %debug_package macro (#635)
Reopened #635. -- 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/635#event-2170961834___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] implement %elif (#613)
Thank you for pointing out that this should be rebased. I have a slightly different plan. #625 already contains a non-trivial refactorization, that is useful for %elif. My next step will be to create an additional PR that will contain a correction of a current minor %else parsing problem + as a side effect a part of code that will be usefull for %elif too. After that I will rebase this PR. -- 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/613#issuecomment-469185640___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Test a macro from a macro file that contains %ifxxx - %endif (#640)
The underlying problem tested in the patch:
If a macro is in a macro file and at the same time it contains
%ifxxx - %endif (%ifxxx here denotes one of %if, %ifarch, %ifnarch,
%ifos, %ifnos) then during the rpm expansion of the macro the lines
inside %ifxxx - %endif are expanded in all cases (no matter whether
the condition after %ifxxx is satisfied or not).
Thus e.g. if the following definition is in a macro file:
%mymacro \
%if 0 \
%global bbb ccc \
%endif \
%{nil}
and a spec file contains line:
%mymacro
then during the expansion of %mymacro macro %bbb is globally
defined even if the condition after %if is not true.
It is not a problem in evaluation of the %if condition. It is caused
by the fact that the whole %mymacro is expanded in several recursive
steps and in meantime there is no check whether some of its lines start
by %ifxxx.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/640
-- Commit Summary --
* Test a macro from a macro file that contains %ifxxx - %endif
-- File Changes --
M tests/Makefile.am (2)
A tests/data/SPECS/iftest.spec (20)
A tests/data/macros.iftest (13)
M tests/rpmmacro.at (19)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/640.patch
https://github.com/rpm-software-management/rpm/pull/640.diff
--
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/640
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Test a macro from a macro file that contains %ifxxx - %endif (#640)
> the macros can be defined in the spec directly Yes, it is a good observation. The spec file is changed to the proposed one. >Then there's the issue of what it actually tries to test and what it expects - >this is not really an expected failure but expected behavior, very similarly >to how macros expanding in comments is. Normally you hardly notice it, but if >there's a %define/%global in there... > In these cases, the %if-%endif are processed as expected, but since the > expansion (including the %global) occurs first, what the spec parser actually > sees is just an empty %if-%endif. I think that the current behaviour is not expected by users. E.g. C don't evaluate #ifdef/#ifndef this way. Thus I let the test be "expected failure". -- 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/640#issuecomment-471953146___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Correct rpm -ql exit value when optional -p is omitted (RhBug:1680610) (#641)
Additionally if a package query with the argument was successful, there is no need to rpm query of the argument. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/641 -- Commit Summary -- * Correct rpm -ql exit value when optional -p is omitted (RhBug:1680610) -- File Changes -- M lib/query.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/641.patch https://github.com/rpm-software-management/rpm/pull/641.diff -- 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/641 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Correct rpm -ql exit value when optional -p is omitted (RhBug:1680610) (#641)
An additional commit is added for correcting -ql output for multiple rpm files if -p is omitted. (Thus the PR does not exactly correspond to its name). -- 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/641#issuecomment-472358348___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Test a macro from a macro file that contains %ifxxx - %endif (#640)
The "expected failure" is removed and 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/640#issuecomment-472375847___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Correct rpm -ql exit value when optional -p is omitted (RhBug:1680610) (#641)
I (hopefully) incorporated all comments from Florian and Panu. The line with a manual calculation is not a part of the 2 patches now. Thus I added the third patch to change it (on 2 places in the query file - to be consistent). If you think that the last commit should not be used, I am fine with it. -- 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/641#issuecomment-472892380___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add flag to use strip -g instead of full strip on DSOs (RhBug:1663264) (#643)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/643 -- Commit Summary -- * Add flag to use strip -g instead of full strip on DSOs (RhBug:1663264) -- File Changes -- M scripts/find-debuginfo.sh (20) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/643.patch https://github.com/rpm-software-management/rpm/pull/643.diff -- 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/643 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add flag to use strip -g instead of full strip on DSOs (RhBug:1663264) (#643)
Thank you for the review. The commit message is extended. -- 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/643#issuecomment-473912473___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add flag to use strip -g instead of full strip on DSOs (RhBug:1663264) (#643)
Thank you very much for the review. According of the review I added changes on two places: - in documentation + explicitly say "ONLY on DSOs" to make clear how it differs from -g. (as Mark wrote) + add a sentence that options -g and --g-libs are mutually exclusive - add an error if the user gives both -g and -g-libs. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/643#issuecomment-474319489___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add flag to use strip -g instead of full strip on DSOs (RhBug:1663264) (#643)
Sorry, I did a wrong alignment in the previous comment. Corrected: Thank you very much for the review. According of the review I added changes in two places: - in documentation: explicitly say "ONLY on DSOs" to make clear how it differs from -g. (as Mark wrote) and add that options -g and --g-libs are mutually exclusive) - add an error if the user gives both -g and -g-libs. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/643#issuecomment-474341794___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove full paths from expected results of --addsign test (#647)
The full paths should be removed from the expected results of the test. If the way that is used in the patch is not the one you prefer, feel free to correct it differently. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/647 -- Commit Summary -- * Remove full paths from expected results of --addsign test -- File Changes -- M tests/rpmsigdig.at (16) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/647.patch https://github.com/rpm-software-management/rpm/pull/647.diff -- 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/647 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/649 -- Commit Summary -- * Enable rpmParseLineType_e to store default value * Enable to use rpmParseLineType_e in spec.c * Warn if %else is after %else -- File Changes -- M build/parseSpec.c (21) M build/rpmbuild_internal.h (13) M build/spec.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/649.patch https://github.com/rpm-software-management/rpm/pull/649.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Sort list of hard linked files in find-debuginfo.sh (RhBug:1421272) (#658)
It helps to make build results reproducible. Based on Mark Wielaard's idea. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/658 -- Commit Summary -- * Sort list of hard linked files in find-debuginfo.sh (RhBug:1421272) -- File Changes -- M scripts/find-debuginfo.sh (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/658.patch https://github.com/rpm-software-management/rpm/pull/658.diff -- 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/658 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix segfault on fingerprinting symlink round (RhBug:1660232) (#651)
Lgtm -- 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/651#issuecomment-480871462___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix segfault on fingerprinting symlink round (RhBug:1660232) (#651)
Merged #651 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/651#event-2262490113___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
Please, do you have any idea what name can be used instead of implementedTypes? -- 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-481998368___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
All your comments are incorporated in the new version. First two commits are now in a single commit.The second now add a general type of an error for inappropriate ordering of conditionals + change of implementedTypes name. -- 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-482099096___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
> Hmm, why not? Having that LINE_DEFAULT kind of thing to represent all the > normal lines seemed useful. Perhaps you misunderstood what I meant by the > earlier comments? Please in which comment you spoke about LINE_DEFAULT? The implemented algorithm (added in #625) works differently and adding LINE_DEFAULT will lead to many subsequent changes with almost no gain. Moreover it can make the situation more complicated. Now if a line is "default", no branchType entry for the line is found. If there will be "LINE_DEFAULT" what value should "text" in branchType table contain? -- 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-482779241___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Use --dpbath only with full path (RhBug:1696408) (#677)
Before the patch rpm treats the relative path as a full path. The new behavior is similar to the "--root" option. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/677 -- Commit Summary -- * Use --dpbath only with full path (RhBug:1696408) -- File Changes -- M lib/poptALL.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/677.patch https://github.com/rpm-software-management/rpm/pull/677.diff -- 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/677 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
Your comments are incorporated 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: https://github.com/rpm-software-management/rpm/pull/649#issuecomment-486536987___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for special system-level %include path (#685)
Please can you add a test case that ends successfully? Note that: After this commit there will be two types of %include - basic "%include file" and - require/provides from system-level dir "%include ", If there will be a need for another special type of %include in future, it will be hard to create another type of notation. -- 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/685#issuecomment-487477114___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for %patchlist and %sourcelist spec sections (#679)
Can something similar be used for directories? E.g. %patchdir path/mydir will create in ASCIIbetical order for each file in "path/mydir" %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/679#issuecomment-487544674___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Try to continue despite missing %include files on forced spec parse (#684)
Please, where is described, that forced spec parse already allow sources and patches to be missing? Why to continue despite missing %include files and not despite missing %load files? (even if "more often than not, the %include'd file is actually a source of that package".) > It's just about trying to continue despite missing ones (and in this case the > result will be unreliable, but with a warning) Otherwise I think the changed behaviour in case "rpmspec -q" is good. It enables to get the data that are requested, but it still wrote the warning that informs is sources are missing. Moreover the output is usually so small so the warning can not be missed easily. But in cases where the output is larger e.g. "rpmspec -P" this change does not look unambiguously positive to me. It is because the output is "unreliable" and the warning can be missed. -- 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/684#issuecomment-487892591___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make check-buildroot check the build files in parallel (#687)
Maybe you can mention RhBug:1704354 in the commit message. -- 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/687#issuecomment-488628322___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix memory reading in the expansion of an unfinished macro "{%!" (#694)
Problem was in reading of the memory right after the end of the
allocated area. (Similar problem as in
commit 54f24ec5486bdacde9419466a2c27defaddf508e).
This is a good opportunity to reflector the corresponding code
(setting variables according to the number of exclamation marks and
interrogation marks after % an before the macro).
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/694
-- Commit Summary --
* Fix memory reading in the expansion of an unfinished macro "{%!"
-- File Changes --
M rpmio/macro.c (38)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/694.patch
https://github.com/rpm-software-management/rpm/pull/694.diff
--
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/694
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix memory reading in the expansion of an unfinished macro "{%!" (#694)
Thank you for the review. The commit message is changed according to your comments. -- 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/694#issuecomment-490864474___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove nonexistent macro "Q" from the table of builtin macros (#697)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/697 -- Commit Summary -- * Remove nonexistent macro "Q" from the table of builtin macros -- File Changes -- M rpmio/macro.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/697.patch https://github.com/rpm-software-management/rpm/pull/697.diff -- 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/697 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Correct an emitted error for built-in macro %load (#702)
- If rpm tries to load a file and is unsuccessful then emit an error in all cases - The error should end by a new line You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/702 -- Commit Summary -- * Correct an emitted error for built-in macro %load -- File Changes -- M rpmio/macro.c (5) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/702.patch https://github.com/rpm-software-management/rpm/pull/702.diff -- 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/702 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Correct an emitted error for built-in macro %load (#702)
Please where is this usage of %{?load:...} described (not counting macro.c)?
I see %{?load:...} in spec files ruby.spec or vagrant.spec where it is used for
another purpose: to be able to build SRPM on older Fedora, where the older RPM
has not %load defined. And it looks that the packager expects that with the new
version of RPM (with %load defined) it works similarly as %{load:...}.
--
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/702#issuecomment-491258089___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
pavlinamv commented on this pull request.
> @@ -462,6 +430,16 @@ int readLine(rpmSpec spec, int strip)
lineType = parseLineType(s);
if (!lineType)
goto after_classification;
+
+/* for a conditional check its ordering */
+if (lineType->isConditional &&
+ (spec->readStack->lastConditional->id & lineType->wrongPrecursors)) {
+ rpmlog(RPMLOG_ERR,_("%s:%d: Got %%%s %s\n"),
Removed 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:
https://github.com/rpm-software-management/rpm/pull/649#discussion_r283789969___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
pavlinamv commented on this pull request.
> +size_t textLen;
+const char *text;
+int withArgs;
+int isConditional;
+int wrongPrecursors;
+const char *info_text;
+} * parsedSpecLine;
+
+static struct parsedSpecLine_s const lineTypes[] = {
+{ LINE_ENDIF, LEN_AND_STR("%endif") , 0, 1, LINE_ENDIF, "with no
%%if"},
+{ LINE_ELSE, LEN_AND_STR("%else") , 0, 1, LINE_ENDIF | LINE_ELSE,
"after %%else" },
+{ LINE_IF, LEN_AND_STR("%if") , 1, 1, 0, "after %%if"},
+{ LINE_IFARCH, LEN_AND_STR("%ifarch") , 1, 1, 0, "after %%ifarch"},
+{ LINE_IFNARCH,LEN_AND_STR("%ifnarch"), 1, 1, 0, "after %%ifnarch"},
+{ LINE_IFOS, LEN_AND_STR("%ifos") , 1, 1, 0, "after %%ifos"},
+{ LINE_IFNOS, LEN_AND_STR("%ifnos") , 1, 1, 0, "after %%ifnos"},
>The %ifs should not have any info text because there are no such error cases,
>and the texts should be marked for translation.
>Programmatically constructed messages tend to be a problem for translators,
>might better to have the whole string in one piece, ie "%s with no %s" and "%s
>after %s" to allow translators to at least reorder the words.
Changed in the new version
> Also, isn't this now missing the else-with-no-if case, or am I just
> misreading it?
No in this case it wrote e.g.
/data/SPECS/attrtest.spec:1: %%endif with no %%if
/data/SPECS/configtest.spec:1: %%else with no %%if
> Hmm, "with no" could just as well be changed into "before", which makes the
> messages more in line with each other: this is just about the order of
> things, so things are either before or after its proper place.
This message appears e.g. in case that in spec file is only one conditional:
%endif. So in this case there is no %if after the %endif, thus changing "with
no" into "before" good idea.
--
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#discussion_r283789959___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
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 list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add documentation for %getncpus macro (#707)
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 -- https://github.com/rpm-software-management/rpm/pull/707.patch https://github.com/rpm-software-management/rpm/pull/707.diff -- 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/707 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warn if %else is after %else (#649)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Implement %elif (#710)
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 more general and informative * Supported operators: %elif, %elifarch, %elifos. * Add tests for %elif, %elifos, %elifarch -- File Changes -- M build/parseSpec.c (46) M build/rpmbuild_internal.h (7) M build/spec.c (1) M tests/Makefile.am (1) A tests/data/SPECS/eliftest.spec (116) M tests/rpmmacro.at (105) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/710.patch https://github.com/rpm-software-management/rpm/pull/710.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement %elif (#710)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement %elif (#710)
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 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#discussion_r286490094___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement %elif (#710)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix bogus if-condition in find-debuginfo.sh (#735) (#737)
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 scripts/find-debuginfo.sh (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/737.patch https://github.com/rpm-software-management/rpm/pull/737.diff -- 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/737 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)
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 "NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" but it is not able to work with time zone descriptions that do not contain all information regarding the DST like e.g. "NZST". You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/739 -- Commit Summary -- * Include time zone in changelog time calculation (RhBug:1715412) * Enable using longer time zones names/abbreviations in changelogs -- File Changes -- M build/parseChangelog.c (22) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/739.patch https://github.com/rpm-software-management/rpm/pull/739.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)
@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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/739/files/6a0e067a67cb13e69a3c7b465325e678f74068b0..e4dc76e450dd0277fe5f15d4b74df3935dc2ae58 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)
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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/739#issuecomment-499212394___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)
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 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#discussion_r291067663___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Take changelog timezone in account (RhBug 1715412) (#739)
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 the TZ database name in changelog is not correct" is added. -- 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-500183451___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Support triple operator for conditional shortcut (#115) (#746)
%{? { 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 space.
* On the other hand around {condition} and :, there can but not need to be a
space.
* In {condition}, there can be a space before or after macro_name.
So e.g. the following conditions are similar (from rpm point of view):
%{?{macro}:true:false}
%{? { macro } : true : false }
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/746
-- Commit Summary --
* Make chkexist variable in macro.c more general
* Create a separate variable for storing parts of a macro
* Support triple operator for conditional shortcut
-- File Changes --
M rpmio/macro.c (187)
M tests/rpmmacro.at (30)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/746.patch
https://github.com/rpm-software-management/rpm/pull/746.diff
--
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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
