This is a followup after
https://github.com/rpm-software-management/rpm/issues/664
Apparently, not all entry_points console_scripts have the pkg_resources import.
It seems to me that packages installed via pip from a wheel have this:
```
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import re
@pmatilai, @ffesti: can we get this merged?
--
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/951#issuecomment-559232386___
fixed in https://github.com/rpm-software-management/rpm/issues/664 ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I've been using the double-underscore names in [my
specfiles](https://gist.github.com/ascherer/474764be05e3d8031f0e1cf375b61b4c)
for years, and secondary versions like `%{__ln_s}` and `%{__mkdir_p}` always
came quite handy.
--
You are receiving this because you are subscribed to this thread.
Thanks, @encukou
If this PR looks good to you all, then let's merge and close it, and continue
discussion in issues on the convert-440 project. Miro has a couple open now.
If I get that code into a condition where we're happy with it, then I can add
unit tests and then work on integrating
> https://github.com/gordonmessmer/convert-440/blob/master/convert-pep440.py
Wow! That looks great!
I started writing something similar, but ran into a lack of tests – I can't
hold all the details in my head alone.
> For example, I don't know what you have in mind when you say "strictly
>
The existing ones are there because they were at one point or another used by
rpm itself, but got left behind when the usage went away.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I extrapolated incorrectly to 600 million because of an off-by-1024 error in my
calculations, not because of other architectures / releases. Those add a
factor of 20ish (for fedora).
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I think it makes sense for these kinds of macros to exist for dealing with
portability concerns. If, for example, you're like me and trying to build
packages that transparently build and run on Fedora and macOS, it's very handy
to have an "interface" that is more or less guaranteed to behave as
The way I see it, those double underscore macros are really intended for rpm's
own use and to allow overriding rpm behavior without having to recompile,
rather than convenience for spec.
I'll certainly listen to opposing arguments, but the recent trend has been to
eliminate these things
BSDs sed _requires_ an `extension` for the `-i` option, even an
empty (`-i `) extension to suppress creation of a backup
for in-place editing, while GNU seds `-i` defaults to no
backup without an express `suffix`. With `%{__sed_i}` it should be easier
to write portable specfiles for both
Hi Frank,
Thanks so much for trying to come up with actual numbers!
On Tue, 2019-11-26 at 13:07 -0800, Frank Ch. Eigler wrote:
> Argh, very sorry @espindola but I was 3 orders of magnitude too high
> with my extrapolated numbers. I hereby hand back my math card. The
> collision probability is
pmatilai commented on this pull request.
> if (fnamedPipe)
Fclose(fnamedPipe);
-if (pid)
- waitpid(pid, , 0);
+if (gpgPid)
+ waitpid(gpgPid, , 0);
Not a problem introduced in this patch so not something you need to address,
just noting: the exit section
pmatilai commented on this pull request.
> @@ -307,8 +337,8 @@ static int runGPG(sigTarget sigt, const char *sigfile)
Fclose(fnamedPipe);
fnamedPipe = NULL;
-(void) waitpid(pid, , 0);
-pid = 0;
+(void) waitpid(gpgPid, , 0);
Hmm, what if we get a SIGCHLD in the
Closed #950.
--
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/950#event-2835387089___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
Non-unique build-ids become file conflicts in rpm, and end up preventing
installations packages when the build-id links are in the main package, ie at
least Fedora + RHEL and derivates. That's why strong hashes in build-id
calculation are a must.
--
You are receiving this because you
pmatilai commented on this pull request.
> @@ -276,7 +296,17 @@ static int runGPG(sigTarget sigt, const char *sigfile)
rpmPopMacro(NULL, "__plaintext_filename");
rpmPopMacro(NULL, "__signature_filename");
-fnamedPipe = Fopen(namedPipeName, "w");
+while (1) {
Looping while
pmatilai commented on this pull request.
> @@ -276,7 +296,17 @@ static int runGPG(sigTarget sigt, const char *sigfile)
rpmPopMacro(NULL, "__plaintext_filename");
rpmPopMacro(NULL, "__signature_filename");
-fnamedPipe = Fopen(namedPipeName, "w");
+while (1) {
+errno =
pmatilai commented on this pull request.
> @@ -238,11 +239,25 @@ static rpmtd makeSigTag(Header sigh, int ishdr, uint8_t
> *pkt, size_t pktlen)
return sigtd;
}
+static pid_t gpgPid = 0;
Okay, thinking about it with hopefully somewhat fresher head, I suppose this
should be `volatile`
19 matches
Mail list logo
