| Summary: | dev-libs/pth-2.0.7-r3 doesn't compile with UClibC | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | gentoo |
| Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | alonbl, embedded, vapier |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=525136 https://bugs.gentoo.org/show_bug.cgi?id=552936 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | /var/tmp/portage/dev-libs/pth-2.0.7-r3/temp/build.log | ||
Workaround for those trying to install gnupg. This works by allowing newer versions of gnupg to be merged. Need at least >=2.1 to use npth which does not have this glibc problem. /etc/portage/package.accept_keywords app-crypt/gnupg (In reply to gentoo from comment #1) > Workaround for those trying to install gnupg. This works by allowing newer > versions of gnupg to be merged. Need at least >=2.1 to use npth which does > not have this glibc problem. > > /etc/portage/package.accept_keywords > app-crypt/gnupg pth, where the p stands for portable, is anything but portable. it dives into the libc's implementation details which you should never do. as a result it has some ad-hoc #ifdefs to try to guess your libc and use the appropriate hack. I hit this with musl (bug #525136) and had a fix there but abandoned it as a bad approach. I think the workaround should be the effective "fix". Bug 552936 is tracking the stabilization of gnupg-2.1. Let's stabilize it and be done with pth. > Bug 552936 is tracking the stabilization of gnupg-2.1. Let's stabilize it
> and be done with pth.
we do not wait for stable to resolve bugs, reporter is free to use gnupg-2.1 for his target if he wishes so.
resolved in gnupg-2.1.
(In reply to Alon Bar-Lev from comment #3) > > Bug 552936 is tracking the stabilization of gnupg-2.1. Let's stabilize it > > and be done with pth. > > we do not wait for stable to resolve bugs, reporter is free to use gnupg-2.1 > for his target if he wishes so. this makes me smile. feel free to (In reply to Alon Bar-Lev from comment #3) > > Bug 552936 is tracking the stabilization of gnupg-2.1. Let's stabilize it > > and be done with pth. > > we do not wait for stable to resolve bugs, reporter is free to use gnupg-2.1 > for his target if he wishes so. > > resolved in gnupg-2.1. I have no idea what you're talking about. Let me repeat my point: pth is required for <gnupg-2.1 which is not stable. Also pth is a terrible mess to port. The reporter is quite rightly complaining that a stable version doesn't work with uclibc or musl. I'm suggesting that we don't waste our effort on fixing something that is poorly coded and going away anyhow, and that we put our efforts into stabilizing gnupg-2.1. How does your statement follow? (In reply to Anthony Basile from comment #4) > I'm suggesting that we don't waste our > effort on fixing something that is poorly coded and going away anyhow, and > that we put our efforts into stabilizing gnupg-2.1. How does your statement > follow? we will not waste any resources, these special configurations (uclibc or any) can use non stable packages until such time reaches and these are stable. pth will not be fixed, while solution will be provided by gnupg-2.1 and its dependencies. efforts to stablize gnupg-2.1 is ongoing regardless. if it makes it any better, please modify the subject to "<gnupg-2.1 and dependencies cannot use uclibc" side note: even if >=gnupg-2.1 will have issues with uclibc, upstream is the proper place to discuss this. to avoid more discussion modifying the status to upstream, to make it clear - we do not modify packages. |
Created attachment 410350 [details] /var/tmp/portage/dev-libs/pth-2.0.7-r3/temp/build.log dev-libs/pth-2.0.7-r3 doesn't compile with UClibC