[Rpm-maint] [rpm-software-management/rpm] Not all console_scripts entry points need pkg_resources from setuptools (#954)
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
import sys
from pytest import main
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(main())
```
While packages installed via python setup.py install have:
```
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'pytest==...','console_scripts','pytest'
__requires__ = 'pytest==...'
import re
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('pytest==...', 'console_scripts', 'pytest')()
)
```
We could do it the proper way:
- when console_scripts entrypoints are found, grep them for pkg_resources
import and only require setuptools if it is in there
Or the heuristic way:
- when dist-info, don't add setuptools, when egg-info, do add it
The second way is certainly easier and faster, however I am not yet sure
whether the situation is that simple
cc @encukou @ignatenkobrain @Conan-Kudo @gordonmessmer
--
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/954___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix compatible-release, versions with dot-star, semantically versioned deps, and python version (#951)
@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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Generate dependency on setuptools if entrypoints are used (#555)
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: https://github.com/rpm-software-management/rpm/issues/555#issuecomment-559232079___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support sed 'in-place' replacement on BSD. (#953)
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.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/953#issuecomment-559204888___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix compatible-release, versions with dot-star, semantically versioned deps, and python version (#951)
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 it back into pythondistdeps. -- 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-559129250___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix compatible-release, versions with dot-star, semantically versioned deps, and python version (#951)
> 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 > standard-based implementation" Well, figure out how to map PEP 440 & 508 to RPM versioning/requires properly :) (For the record, the PEPs are relevant because they are linked from https://www.pypa.io/en/latest/specifications/ – on its own, an Active/Informational PEP is not an agreed-to standard.) For example, we're currently ignoring pre-releases. That's probably OK, but it should be a conscious/documented decision. -- 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-559120414___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support sed 'in-place' replacement on BSD. (#953)
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: https://github.com/rpm-software-management/rpm/pull/953#issuecomment-559113592___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Please support smaller build-ids (#950)
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: https://github.com/rpm-software-management/rpm/issues/950#issuecomment-559105713___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support sed 'in-place' replacement on BSD. (#953)
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 expected. Should they be prefixed with two underscores? Maybe not, but we've been using this convention for so long now... We also do this already for `%__mkdir_p` with `mkinstalldirs` wrapper. I see no reason we can't do the same for things like `sed`... -- 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/953#issuecomment-559105165___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support sed 'in-place' replacement on BSD. (#953)
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 rather than add more. The reason is that we've seen too many of these things become liabilities one way or the other, such as presenting questions and decisions to us that have nothing to do with rpm. And as long as rpm itself doesn't need sed -i for anything, it's not our business to know about sed -i portability or lack of thereof. -- 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/953#issuecomment-559103549___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Support sed 'in-place' replacement on BSD. (#953)
BSD's 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 sed's `-i` defaults to 'no
backup' without an express `suffix`. With `%{__sed_i}` it should be easier
to write portable specfiles for both GNU/Linux and BSD based systems. The
latter should simply redefine
```
%__sed_i /bin/sed -i ""
```
in a local macro file or
```
%global __sed_i /bin/sed -i ""
```
in a specfile.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/953
-- Commit Summary --
* Support sed 'in-place' replacement on BSD.
-- File Changes --
M macros.in (1)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/953.patch
https://github.com/rpm-software-management/rpm/pull/953.diff
--
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/953
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Please support smaller build-ids (#950)
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 more in the 10e-6 range. This seems mood since the issue is already closed and lld will probably switch to a 128 or 160 bit build-id anyway. But I am still interested in the actual numbers and I am now also a little confused. When you say you were off by 3 orders of magnitude to you mean that for one architecture (x86_64) and one release (fedora 30) you estimate that there are ~600.000 build-ids (instead of ~600.000.000) because that is the number of executable artifacts? Or that you extrapolated it (which number?) wrongly when looking at the number of arches (i386 and x86_64 can be installed concurrently) and actual distros (3 normally) that overlap in maintenance? Or asked differently, which number of build-ids are you expecting to come to a collision probability of 10e-6 when the build-id is just 64bits? Thanks, Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
pmatilai commented on this pull request. > if (fnamedPipe) Fclose(fnamedPipe); -if (pid) - waitpid(pid, &status, 0); +if (gpgPid) + waitpid(gpgPid, &status, 0); Not a problem introduced in this patch so not something you need to address, just noting: the exit section duplicates much of what is being done just above it. The whole point of having exit/error labels to jump to is to avoid just 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/rpm/pull/938#pullrequestreview-32363___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
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, &status, 0); -pid = 0; +(void) waitpid(gpgPid, &status, 0); Hmm, what if we get a SIGCHLD in the meanwhile? That'd set gpgPid to 0, which would turn the above into waitpid(0, ...) which doesn't seem 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/938#pullrequestreview-323627595___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Please support smaller build-ids (#950)
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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Please support smaller build-ids (#950)
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 commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/950#issuecomment-559058807___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
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 fnamedPipe remains NULL might be a more natural check here,
eternal loops always make me a bit fidgety.
--
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#pullrequestreview-323611419___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
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 = 0;
+fnamedPipe = Fopen(namedPipeName, "w");
+if (errno != EINTR)
Never trust errno alone, it can get set as a side-effect even on success
(generally speaking). You'll want to move the "Fopen failed" check from below
here, and only look at errno if the open failed.
--
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#pullrequestreview-323608669___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
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` in addition to being static. As SIGCHLD is the only registered signal for that it can't be called multiple times so atomicity issues shouldn't come to play. And now my head hurts :smile: -- 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#pullrequestreview-323605958___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
