Background: Yesterday I bumped the revision of helixplayer-bin from 0.3.0.71 to 0.3.0.124. Both of these releases of helixplayer require a click through in order to download (i.e. fetch restriction). However, today, the Alpha version of helixplayer was released, this version doesn't require a click through in order to download. However, this version is 0.3.0.123 which is older than the one with fetch restrictions. So, how do I communicate to people merging this package, that what they probably want is 0.3.0.123, even though there is a newer package. Options: - Just remove the ebuilds with fetch restrictions. - Make the 0.3.0.123 stable right now (probably the wrong route) - Make the ones with fetch restrictions -x86, so that the user has to force it. This is the one I'm leaning towards, because this way, enterprising users have the ebuild to use the fetch restricted helixplayer, but most users just get the alpha version 0.3.0.123 and don't have to worry about fetch restrictions. Another question: Also, I am behind a proxy (which I'm sure many people are). The download for helixplayer is at a https link only (https://helixcommunity.org/download.php/410/hxplay-0.3.0.123-linux-2.2-libc6-gcc32-i586.tar.bz2). I can't get wget to proxy https through our proxy (I have to use firefox to download the file to distfiles). I read something that said wget 1.9 doesn't work properly with https proxying? 1.9 is the stable version in portage. I guess it will be okay once the helixplayer download propogates to the mirrors, but it still doesn't seem like the ideal situation. Any guidance for either issue? P.S. Also, for those of you following helixplayer/realplayer stuff, there is also a source download (also not fetch restricted) on the alpha download page: https://helixcommunity.org/project/showfiles.php?group_id=154 It's ugly though because they use their own weird build system. Anybody else want to take a crack at getting it working? I'm not sure I'll have the time anytime soon. -- Joel Martin -- kanaka