Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 558830

Summary: dev-libs/pth-2.0.7-r3 doesn't compile with UClibC
Product: Gentoo Linux Reporter: gentoo
Component: Current packagesAssignee: 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

Description gentoo 2015-08-26 13:18:54 UTC
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
Comment 1 gentoo 2015-08-26 13:35:45 UTC
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
Comment 2 Anthony Basile gentoo-dev 2015-08-26 16:14:53 UTC
(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.
Comment 3 Alon Bar-Lev gentoo-dev 2015-08-29 18:46:03 UTC
> 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.
Comment 4 Anthony Basile gentoo-dev 2015-08-29 19:21:27 UTC
(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?
Comment 5 Alon Bar-Lev gentoo-dev 2015-08-29 19:31:32 UTC
(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.