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-managem
@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
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 ve
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://gith
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
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.
%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 t
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.pat
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:
%{?w
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 "%
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.c
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/94e8cd6058cba07b5
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 --ev
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
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
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
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
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 t
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 (becaus
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/i
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 preva
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
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
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.
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:
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
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&
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.
> @@ -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.
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)
+
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 v
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)
+
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/
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.o
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
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 %
> 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 sev
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
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
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-
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.o
> 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
> %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 whe
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-461790
>...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
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
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__
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
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\
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
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
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___
> 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
Rpm-maint@lists.r
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
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 ma
> 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 ma
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 opt
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-s
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__
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
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 --
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_
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 gi
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-l
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
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 --
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)
-- F
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
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
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___
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.
Re
> 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
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 (R
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___
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 cr
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
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 t
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
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
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__
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/rp
- 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
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 expect
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 &&
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
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
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-managemen
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
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 m
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
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 a
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___
R
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-debuginf
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
"NZ
@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
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 i
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
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
%{? { 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 spac
1 - 100 of 190 matches
Mail list logo