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_EN
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 &&
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
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
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:
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
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:
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
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___
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
> 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
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.
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:
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
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
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
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
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:
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 --
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
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:
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:
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
> 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
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
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
> 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
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
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:
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
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:
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\
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
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:
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
>...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 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:
> %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
> 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
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
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___
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
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:
> 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
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
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
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
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:
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->
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
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->
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.
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:
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
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
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:
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:
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
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
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
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:
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
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
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
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
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
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
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:
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:
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
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 --
%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
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
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:
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
@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/d4f90c9625fc7f5694bd57802e1e52
101 - 176 of 176 matches
Mail list logo
