Inserting an empty line between } and %bbb also works around it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> addDep(>provides, ei->soname, NULL, ei->marker);
+ if (multiarch_deps)
+ addDep(>provides, ei->soname, NULL, ei->archmarker);
+ }
Oh and ditto here too, shouldn't the non-archmarker addDep() be behind an else?
pmatilai commented on this pull request.
> @@ -146,6 +244,8 @@ static void processVerDef(Elf_Scn *scn, GElf_Shdr *shdr,
> elfInfo *ei)
continue;
} else if (soname && !soname_only && !skipPrivate(s)) {
addDep(>provides, soname, s,
AIUI this *is* RPATH, and we don't want that. Not by default anyway, but as an
optional, opt-in feature I suppose it wouldn't hurt anybody.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #227.
--
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/227#event-1492159676___
Rpm-maint mailing list
I really can't see this happening in rpm as long as C.UTF-8 is not in glibc
upstream. I am closing this for now. Still, this is eligible to reopening as
soon as there are news on the glibc side of things.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Closed #361 via 449ed5d9d772d588566748c26ead8c8fbaae71e1.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #190.
--
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/190#event-1492074446___
Rpm-maint mailing list
I would've thought closure of #25 and #96 made it fairly clear that it's the
functionality that is not wanted. The problem here isn't so much with the
implementation but the fact that we *don't want to* enable arbitrary embedded
language support in specs and macros. Lua is *the* embedded
Well you at least understand why the Fread() return code was originally
changed, so that read(2) could be replaced with Fread() with little risk of
error.
You might as well rename Fread() to Read() etc and remove the extraneous nmemb
argument if you prefer read/write to fread/fwrite. At least
Thanks for the patch but no thanks.
I pushed commit c7a8104df7b0e77459efb32d1d6a926fb59dbf03 to just loosely
document the existing behavior, changing it is just a whole lotta hassle and
pain for little gain (we have negative return values etc that are much more
like read()/write() than the
macros.foo
```
%xxx defined
%aaa %{?xxx:\
aaa\
}
%bbb %{?xxx:\
bbb\
}
```
```
⋊> ~ rpm --macros macros.foo --eval "%aaa" --eval "%bbb"
13:08:23
aaa
More generally still: There is no reason (that I know of) that
Fread/Fwrite/Fseek cannot be simply deprecated and replaced with
fread/fwrite/Fseek everywhere now that *BSD (and OS X) have equivalent
libio-like functionality.
The only lossage would be integrated debugging and statistics which
Merged #399.
--
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/399#event-1491825991___
Rpm-maint mailing list
It's indeed a bit late to be fixing code that was deprecated ten years ago and
since then actually removed, but whatever, I've no reason not to include it
either. Thanks for the patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Old adage: When the doco disagrees with the the code, they are both wrong.
You can swipe the minor changes to Fread/Fwrite from RPM5 CVS to "fix" posix
stdio behavior any time you wish.
Much better than adding an assert, or documenting a flaw.
--
You are receiving this because you are
Ehm, this looks very wrong to me:
`Requires: (foo < 1 with foo > 1)`
Requires a package that does provide a version of foo smaller than 1 and at the
same time a version of foo that is bigger than 1. That is not the same as
`Requires: foo != 1`. `Requires: ( foo < 1 or foo > 1)` is.
Also I
%end is a spec directive, the macro engine knows absolutely nothing about it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'd rather just fix the documentation to match behavior instead of introducing
arbitrary assert()'s in the code. Something like
```
- * fread(3) clone.
+ * fread(3) clone, but return number of bytes instead of items.
```
...and ditto for Fwrite(). Of course there's the option of actually making
19 matches
Mail list logo
