Don't you need to do some escaping in case the prefix includes a '%' or '_'
character?
--
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/07129b641b733ab30995c93e2b08d0673b9
You may want to rename `skipdata` to `ii_skipdata` so that it fits in better
with the other elements.
--
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/971#issuecomment-56212
mlschroe approved this pull request.
--
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/971#pullrequestreview-327548592___
Rpm-m
Oooh, did you notice the #if 0 code in ndb/glue.c? I once started the same
thing (but used DBC_KEY_SEARCH to select it), but didn't finish the
implementation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
mlschroe approved this pull request.
--
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/969#pullrequestreview-327452563___
Rpm-m
Oh yes, the documentation...
Anyway, calling `gcry_check_version(NULL)` results in just another call to
libgcrypt's global_init() function, so doing it doesn't hurt and brings it in
line with the documentation.
--
You are receiving this because you are subscribed to this thread.
Reply to this
What libgcrypt version are you using?
The gcrypt code seems to indicate that GCRYCTL_SET_THREAD_CBS is nowadays a
dummy call that just calls gcrypt's global_init() function. So does
```
gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
```
also work for you?
--
You are receiving this because
Wouldn't `%expand` work here? (Note that `suffix` is already used in rpm...)
```
%{expand:%%global something%{suff} value}
```
--
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/iss
"Also only return an allocated dbi if everything fails." sounds not quite right
;)
--
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/943#issuecomment-555999855___
Doing it in the child (i.e. before the execve call) should not block. It just
does the same open that gpg does later on.
--
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/938
Regarding opening the pipe for reading: oh yeah, that's right. You can't do it
before the fork. But it should work if you do it after the fork.
It would be much saner if the gpg call would just read from stdin, i.e. if we
use a normal pipe instead of that named pipe. But it's a bit late to chang
(A different fix that might also work (untested) would be to simply open the
named pipe for reading before doing the exec call. You can even do that before
the fork(). The opened file descriptor will not be used by gpg, but that
shouldn't hurt.)
--
You are receiving this because you are subsc
A SIGCHLD can happen all the time for whatever reason, you need at least to
check if the process still exists and retry the Fopen if it does and the error
is EINTR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
Yes, we have `%_binarychangelogtrim`. The syntax is:
```
%_binarychangelogtrim maxnum,cuttime,minnum
```
It is only applied to binary packages, i.e. the source rpm still has the
complete changelog.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
(openSUSE is not slow to adopt new major versions. rpm-4.15 was released
2019-09-26, it is in the Factory staging project since 2019-10-02.)
--
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-man
I wouldn't worry too much about that wrap around: if you add a new rpm header
every tenth of a second, you'll need 13 years for the hdrid to wrap.
--
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-softwa
The rebuilddb case is handled by stat()ing the database. A rebuilt database
will have a different inode number.
(You probably already know this, but sqlite will guarantee increasing numbers
when you use the AUTOINCREMENT keyword.)
--
You are receiving this because you are subscribed to this th
Just FYI, recycling previously used header ids will break libsolv's
`repo_add_rpmdb()` function, which uses the packages from an old solv file if
the header id matches.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
You see this with ndb but not lmdb because ndb fsyncs the main database after
each operation. So after a system crash you'll have a correct main database but
outdated indices. With lmdb there's no fsync at all, so you get a outdated main
database with matching indices.
Ndb's behavior is *way* b
NDB supports detection of outdated indices since the beginning, but currently
rpm doesn't make use of that option.
So no, it's not yet fixed. (But it's not hard to do so, unlike with bdb)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
Note that from a high level perspective, rpm does not need transactions. It
only has to database operations "insert header into database" and "remove
header from database" and only does one operation at a time.
It should be up to the database to keep the index table in sync. Now, rpm's
index ta
mlschroe approved this pull request.
--
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/910#pullrequestreview-304543216___
Rpm-m
Note that some error paths don't work correctly when building without omp.
Those are the ones that use `#pragma omp cancel parallel`, where the `goto
exit;` statements were deleted.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on G
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/909
-- Commit Summary --
* Use xdb's pagesize instead of sysconf(_SC_PAGE_SIZE)
* Multiple fixes in rpmxdb.c for the ndb database backend
-- File Changes --
M lib/back
I recommend my little benchmark tool ;-)
--
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/5bf88af9cc71413b89f1b3df87688d0ec16d21f4#commitcomment-35562392___
You need to create an additional index on hnum, otherwise deleting is really
really slow.
--
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/5bf88af9cc71413b89f1b3df87688d0e
mlschroe approved this pull request.
--
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/904#pullrequestreview-303183322___
Rpm-m
@Conan-Kudo What does "It's been interesting..." mean? Did they run into some
problems?
--
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/899#issuecomment-543125140__
mlschroe approved this pull request.
--
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/903#pullrequestreview-303175649___
Rpm-m
On Wed, Oct 16, 2019 at 06:12:45PM +0300, Panu Matilainen wrote:
> Can you share this benchmark tool?
Sure. It's just 400 lines so I've attached it to this mail.
It uses some internal rpm API functions mainly to be able to
enable/disable fsync.
Cheers,
Michael.
--
Mich
peration), all implementations
take very long. The question is how much this is drowned out by the
time spent in unpacking/erasing all the files on disk.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16
(See also issue #561 )
--
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/896#issuecomment-542611714___
Rpm-maint mailing list
Rpm
I wouldn't dismiss poor ndb that easily. It has not many LoC and fits rpm's
needs perfectly. The packages database is similar to what rpm-3 had in the past
(but written with fault tolerance in mind), and the indexes are just mmaped
hash tables.
--
You are receiving this because you are subscri
It just needs to be removed, the MAP_SHARED was the next argument of the mmap
call. Force-pushed 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/895#issuecomme
@mlschroe pushed 1 commit.
b475725264bbe776c9384a22b7c5438dfe8da33f Refactor mmap/munmap/mremap handling
in ndb
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/895/files/e716bd973be5ed76c179077f94f629d
Closed #896.
--
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/896#event-2710646748___
Rpm-maint mailing list
Rpm-maint@lists.rpm
No, that's correct. The `-` character compares the same as the `.` character,
and 5 is greater than 1.
The `rpmvercmp` function only compares the version or the release parts. You
need to split the input into epoch/version/release and then do individual
rpmvercmp calls.
--
You are receiving
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/895
-- Commit Summary --
* Implement fsync disabling for the ndb backend
* Delete all the IDXDB_FILESUPPORT code in the ndb backend
* Do not always fsync the database dire
(That's also what `Makefile.am` in the `lib` directory does)
--
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/888#issuecomment-539432333
I used the following patch to fix the build:
```
--- ./build/Makefile.am.orig2019-10-02 13:12:00.031823903 +
+++ ./build/Makefile.am 2019-10-02 13:13:09.743668564 +
@@ -10,6 +10,9 @@ AM_CPPFLAGS += @WITH_NSS_INCLUDE@
AM_CPPFLAGS += @WITH_MAGIC_INCLUDE@
AM_CPPFLAGS += @WITH_POPT_INCLUD
The `ALLOW_EMPTY` logic seems to be broken:
- it is set if `_empty_manifest_terminate_build` is set, i.e. it's FORBID_EMPTY
- it uses RPMLOG_ERR if the flag is set
- it sets nlines to -1 if there are no lines and the flag is *not* set
--
You are receiving this because you are subscribed to this
(FYI: SUSE has a patch that makes rpm look in the chroot's /etc/passwd and
/etc/group file as there is no way to flush glibc's caches.)
--
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-manageme
Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/879#issuecomment-538968550___
Rpm-maint mailing list
Rpm-maint@lists.rp
This pops up from time to time as a bug report. The message rpm prints for too
low disk space/too few inodes is a bit confusing:
```
foo.noarch needs 377MB on the /usr/src filesystem
```
But the disk has more than 377 MB free space.
What's meant is that it needs 377 MB *more* disk space. Could yo
I don't think deltarpm would be able to make use of this global source file
hash.
--
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/861#issuecomment-535419462__
There's also the well-known `rpm -q --pkgid XXX` query option ;)
--
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/863#issuecomment-53547
The open build service project uses the pkgid (aka hdr+payload md5) as package
identifier.
--
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/863#issuecomment-534997823_
My only concern is that the password/group lookups in rpmug.c need to be done
in the chroot, but you probably already checked that.
--
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/r
Ok, it does use the file sizes. No 64bit support for files at the moment,
though.
--
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/864#issuecomment-534993086_
I don't think deltarpm uses size information from the header.
So you want to only put the 64bit versions in the header and add a macro check
so that it puts in both the 32bit and the 64bit versions for people that need
compatibility?
--
You are receiving this because you are subscribed to this
It's also weird that the algorithm is different to the one used in matchchar().
But changing this is probably way to dangerous.
--
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/p
If the reconstructed rpm is getting installed right away we can also use add an
option that tells rpm that the payload is uncompressed. Regarding the magic, we
already have to cpio magic to identify uncompressed payload.
I've also considered adding something like this. deltarpm would also need t
That's the third loop of that form in the code...
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/858
-- Commit Summary --
* Make copyNextLineFromOFI() aware of the new %[] syntax
-- File Changes --
M build/parseSpec.c
Here's another solution:
```
%global godocs docs examples code-of-conduct.md %dnl\
README.md
```
This uses the new %dnl macro to eat away the newline generated by the trailing
`\`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Git
(I've got no plans for another commit currently.)
--
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/855#issuecomment-534516042___
R
With the referenced pull request you can use && and || for alternate/default:
`%foo && %bar` is `%bar` if `%foo` is true, otherwise `0`
`%foo || %bar` is `%foo` if `%foo` is true, otherwise `%bar`
I think people are somewhat more used to this than the degenerate `?` and `?!`
forms that aren't us
This commits change the handling of the logical operators. It allows to use
strings as condition and also changes || and && to return the last
evaluated term like in perl/python/ruby.
Fixes #852
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-m
No objections from my side. Note that `%{echo:%nil}` would still work. I guess
you tested `gn` instead of `g` on purpose?
You may also want to add a test in doFoo so that this also gets checked after
expansion. Or maybe only check this in doFoo?
--
You are receiving this because you are subscr
(We can also go the perl/python/... way and change the || operator so that it
no longer returns a bool, but the first true term. I.e. `"%foo" || "bar"`.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
Closed #834.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/834#event-2654226267___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Here are some points to discuss:
1) The ternary op currently uses the same logic as rpmExprBool to evaluate if
the condition is true or not. But the other logical operators (!, &&, ||) only
work with integers. We should make this consistent, either by changing ternary
to only accept integers or
Also reduce the number of alloc/free calls by adding ValueSetXXX()
variants that change a value.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/851
-- Commit Summary --
* Free memory leak in unary op handling
-- File Chang
Fine with me ;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/779#issuecomment-534052426___
Rpm-maint mailing list
Rpm-maint@
Changed and force-pushed. I also tweaked the code so that a negative number is
allowed to make `%[ 3 + %[ 4 - 5]]` work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846
Ah, I get what you mean. I think we should print a bare word error if the
expanded string does not start with a digit. This makes it similar to what
`%{expr:...}` and `%if` does:
```
$ ./rpm --define "aaa a" --define "bbb 123b" --eval '%{expr: %aaa }'
error: bare words are no longer supported, pl
Sorry for the multiple force pushes, I had a little fight with git.
I now use "macro expansion did not return a number" as error 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-manage
@mlschroe pushed 1 commit.
52bd4a99ca452a974b248cf9291454e992e263b3 Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846/files/b0023896a47039a7d
I switched the helper function to camelCase and moved the digit check into a
separate function to make the code easier to read.
--
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/p
@mlschroe pushed 2 commits.
713d13cb402a76f58be3513fdd8e197754390265 Add support for primary expansion to
the expression parser
11e11cf1fc187efc50e4cdff1036355032f97be3 Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this thr
Panu, this is still open. Any insight on this issue?
--
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/791#issuecomment-533179508
I also noticed it, but didn't want to check if it's still true ;)
I removed that sentence.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846#issuecomment-533113309___
The duplicate error is because rpmExprStr/rpmExprBool ignore the return value
of the
`rdToken()` call. That should also be fixed.
It's not really about TOK_TERNARY_ALT, you'll get the same error with `%{expr:4
* +}`
If the different error message bothers you, just delete the TOK_EOF case so
th
I now also documented the difference to `%{expr:}`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846#issuecomment-533100283___
@mlschroe pushed 2 commits.
c2469258af1915aeef5b44a6c1444a7a938d99d0 Add support for primary expansion to
the expression parser
d77df7f2275027228f15b674bbab59d9496adb61 Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this thr
I fixed the comment plus added some basic documentation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846#issuecomment-533091735__
@mlschroe pushed 2 commits.
02819e9b723f29329acaed20051f5a0cee10121a Add support for primary expansion to
the expression parser
3288db0c688e89131833258d9cac028fabf1e89e Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this thr
I think we just need a
```
exprErr(state, _("syntax error in expression"), state->p);
```
in doPrimary()'s default case to fix missing error for `%{expr:0 < 1 ? 4+ : 0}`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
The false branch does get parsed, this needs to be fixed as well.
--
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/847#issuecomment-533062908_
Yes, I just ran out of time yesterday but wanted to show your guys the current
state.
I've added some test cases, next comes the documentation.
--
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
good catch, thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/847#issuecomment-533060875___
Rpm-maint mailing list
Rpm-main
@mlschroe pushed 1 commit.
630966ce35c39ac5a8c2a2583099a4165ac15c6f Implement short-circuit for logical
and ternary operators
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/846/files/b956786e490c221b6
This adds %[ expr ] as a new means to do expression expansion in rpm. Unlike
%{expr:} the expression is expanded in the parser, so we are safe against
expansion results messing up the syntax and also can to short-circuiting.
You can view, comment on, or merge this pull request online at:
https
mlschroe commented on this pull request.
> + result = v1->data.i != 0;
+ break;
+ case VALUE_TYPE_STRING:
+ result = v1->data.s[0] != '\0';
+ break;
+ default:
+ goto err;
+}
+valueFree(v1);
+if (rdToken(state))
+ goto err;
+v1 = doTerna
I added the ternary operator to the list of supported operators.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/838#issuecomment-532641740__
No, don't drop it. It's still useful if you need to do expansion before calling
the expression parser.
I.e. you have either 'expand first, then don't expand in the expression parser'
or 'expand in the expression parser':
```
%define test 1 + 2
%{expr:%test}
# the next line expands twice!
%{expand
mlschroe commented on this pull request.
> @@ -438,6 +438,10 @@ static Value doMultiplyDivide(ParseState state)
if (valueIsInteger(v1)) {
int i1 = v1->data.i, i2 = v2->data.i;
+ if ((i2 == 0) && (TOK_DIVIDE)) {
Is `(TOK_DIVIDE)` supposed to be `(op == TOK_DIVIDE)`?
--
You a
The %if lines in the specfile are expanded before the expressions
get evaluated, so the re-expansion of strings is surprising.
It's also not done for integers, which makes it inconsistent.
The original expression parser seems to have been written
without taking the upfront expansion into account,
@mlschroe pushed 1 commit.
cd764dbd89f56c7714d94d601c70453d1191ac2d Remove TOK_IDENTIFIER support from
expression parsing
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/840/files/08e34e0929d7278c3b7e6
Right, I'll add a different error message for bare strings.
--
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/840#issuecomment-532607547___
(Sorry for the bad copy&paste with `&state`. Seems I patched it correctly when
I did the change in the fedora chroot I use for testing but then messed it up
when re-doing it in the git tree.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vi
Oh, Panu already decided to go with it. Sorry for the noise ;)
I'll change the message and also do a rebase to fix the conflict.
--
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/
("Lots" meaning 26 spec files in Factory, which actually isn't that much. If
Panu decides to drop support for bare strings I'm also fine with that ;) )
--
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
So I grepped through the SUSE specs, and it seems we're stuck with bare
literals. Lots of specs using
things like `%if %llvm == yes` or `%if %{_lib} == lib64` or `%_arch == s390x`.
So I'll redo this pull request so that it keeps that functionality.
--
You are receiving this because you are subs
I was about to write that this still works, but it really depends on to what
`%var` expands. It'll most likely be an error and you need to write `%if "%var"
!= "string"`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
Ok, I'll create a pull request tomorrow. Is it ok to add a `flags` argument to
rpmExprBool()/rpmExprStr() or is the API fixed and we need new functions? I'm
asking because they are in rpm-4.15.x and you probably don't want to cherry
pick this into 4.15?
The flags would be `RPMEXPR_EXPAND_STRING
The problem is that many people do not know that `%var != string` is not valid
syntax. Even Panu used `a!=b` in the test suite. I prefer ripping out the code
because the currently only `[a-zA-Z][a-zA-Z0-9]*` is supported (it's supposed
to match an identifier, but note the missing `_`) and thus i
I've opened another pull request that fixes the error printing as this is
unrelated to the ternary operator.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/838#issuecommen
Expressions like '5 +' did not print an error message before.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/841
-- Commit Summary --
* Print an error for expressions with missing operands
-- File Changes --
M rpmio/e
Identifier expansion got broken in 2000 when getMacroBody() was
removed from the API (commit ad99fcba52fcc5e8ab636d2f1760c945cdfbf19).
Nobody seemed to have noticied, so it's safe to say that there is
no one that used it the intented way.
With the bad commit there is an unintended use for it: it
I modeled the code after the other operators. Things like `--eval '%{expr: 4
+}'` have the same problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/838#issuecomment-53
501 - 600 of 919 matches
Mail list logo
