Bug 590766 – net-proxy/obfs4proxy-0.0.6 keyword request

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Marek Szuba 2016-08-08 13:34:14 UTC]

I would like to request a bunch of keywords for the only available ebuild of net-proxy/obfs4proxy. The idea is that it should ideally be keyworded for the same architectures as net-misc/tor.

Unfortunately it seems all of the first-order dependencies of obfs4proxy are currently only keyworded ~amd64, will create separate bugs for them shortly. As for higher-order dependencies... We shall see, I guess.

[Comment 1 Anthony Basile 2016-08-08 13:37:18 UTC]

(In reply to Marek Szuba from comment #0)
> 
> Unfortunately it seems all of the first-order dependencies of obfs4proxy are
> currently only keyworded ~amd64, will create separate bugs for them shortly.
> As for higher-order dependencies... We shall see, I guess.


You can list them all in this bug.  No need to create separate bugs for each dep.

[Comment 2 Marek Szuba 2016-08-08 13:50:54 UTC]

Target keywords: ~arm ~mips ~ppc ~ppc64 ~sparc ~x86 ~ppc-macos

[Comment 3 Markus Meier 2016-08-30 20:35:54 UTC]

~arm added

[Comment 4 Marek Szuba 2016-09-21 14:38:15 UTC]

~x86 added

[Comment 5 Jeroen Roovers (RETIRED) 2016-10-07 15:56:18 UTC]

(In reply to Anthony Basile from comment #1)
> You can list them all in this bug.  No need to create separate bugs for each
> dep.

Why did you do that? Now I need to visit seven bugs when a single one would have sufficed. It's an administrative nightmare in an administrative nightmare.

[Comment 6 Jeroen Roovers (RETIRED) 2016-10-07 16:00:27 UTC]

(In reply to Marek Szuba from comment #0)
> I would like to request a bunch of keywords for the only available ebuild of
> net-proxy/obfs4proxy. The idea is that it should ideally be keyworded for
> the same architectures as net-misc/tor.

Why would that be ideal? Does it help to have both usable on the same system? Please explain why one naturally leads to the other.

And another thing, this appears to hinge entirely on porting dev-lang/go to different architectures, so realistically only those architectures that dev-lang/go supports should be involved here: ARM and PPC64.

[Comment 7 Jeroen Roovers (RETIRED) 2016-10-07 16:12:48 UTC]

Currently the source code for 1.7.1 seems to say MIPS is also in but SPARC is out.

[Comment 8 Marek Szuba 2016-10-07 21:57:11 UTC]

(In reply to Jeroen Roovers from comment #6)

> Why would that be ideal? Does it help to have both usable on the same
> system? Please explain why one naturally leads to the other.
Because obfs4proxy is currently the only way of augmenting Tor with OBFS4, i.e. the most popular obfuscation protocol which still works. No obfs4proxy - no working Tor in a country which blocks it. Of course it isn't exactly likely one would turn up in such a country with a MIPS or SPARC box in tow, or at least not without some alternative device to use - but, you know, *ideally* obfs4proxy and tor should have identical keywords.

[Comment 9 Mart Raudsepp 2017-01-06 23:24:13 UTC]

There are no plans to introduce mips keywords to dev-lang/go right now. If you feel inclined net-misc/tor should have equal keywords, I'm happy to accommodate a net-misc/tor mips keyword removal request bug. Or ask again after we've miraculously found the time to bootstrap go for mips and keyword the basics of it.