| View previous topic :: View next topic |
| Author |
Message |
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
 Posted: Sat Dec 30, 2017 10:33 am Post subject: HTTPS and winetricks downloads [Solved with ssl USE enable] |
 |
|
Hi, trying to get some things straight about the Wine packages, as well as my local chroot that I use to house everything windows related.
1) I noticed that for some reason (even after updating winetricks just now) that the messages I'm getting that are several include errors in sha256sum not matching
2) Another thing that then follows, which I believe is related to that the winetricks packages (DLLs, etc.) won't download and install which is very frustrating
3) A final thing worth mentioning with winetricks is that it complains a lot about the packaging for wine on my system being outdated (at 2.0, or something like that)...here
| Code: | jonwine@Machine_West /opt $ wine --version
wine-2.0-rc5
|
A little background about my system, is that I recently installed wine into a 32-bit chroot environment since my laptop is running a pure 64-bit/no-multilib profile on it. Wine works great and I use it semi-often for various things. It really only seems to work based on local installs, and hence I think this is an issue with some of the packages in that environment, like openssl which is missing.
Could that possibly be 1 reason why winetricks would not work?
Also, when I try using wget with https:// address lookup the output I get is, | Code: | | HTTPS support not compiled in. |
Of course I am able to use https from within the system (outside of the chroot). Does anyone know what exactly is going on here?
Last edited by LIsLinuxIsSogood on Sun Dec 31, 2017 5:07 am; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sat Dec 30, 2017 5:53 pm Post subject: |
|
|
In the chroot environment, what is the output of emerge --pretend --verbose net-misc/wget dev-libs/openssl app-emulation/winetricks? As I understand it, winetricks downloads packages from various sources, then checks the download against a manually maintained list of acceptable digests. This is its equivalent of the Portage ebuild manifests.
Beyond that, it would be helpful to have the exact error output for each of the problems you want to investigate. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Sun Dec 31, 2017 2:53 am Post subject: |
|
|
| Thanks Hu, will do and get back soon about it, this is great troubleshooting idea from within the chroot - thanks. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Sun Dec 31, 2017 5:03 am Post subject: |
|
|
| Code: | Machine_West / # emerge --pretend --verbose net-misc/wget dev-libs/openssl app-emulation/winetricks
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] dev-libs/openssl-1.0.2n::gentoo [1.0.2m::gentoo] USE="asm sslv3 tls-heartbeat zlib -bindist -gmp -kerberos -rfc3779 -sctp -sslv2 -static-libs {-test} -vanilla" CPU_FLAGS_X86="-sse2" 5,262 KiB
[ebuild R ] net-misc/wget-1.19.1-r2::gentoo USE="ipv6 nls pcre zlib -debug -gnutls -idn -libressl -ntlm -ssl -static {-test} -uuid" 2,063 KiB
[ebuild U *] app-emulation/winetricks-99999999::gentoo [20170823::gentoo] USE="gtk -kde -rar*" 0 KiB
Total: 3 packages (2 upgrades, 1 reinstall), Size of downloads: 7,324 KiB
|
So what do you think do I need to go through with these updates? there's some further output about the Masked packages for winetricks, but do I need to include that?
I get the error message each time that I start winetricks, which looks like this...
| Code: | jonwine@Machine_West ~ $ WINEPREFIX="/home/jonwine/wine_testi" /opt/winetricks ------------------------------------------------------
Your version of wine 2.0 is no longer supported upstream. You should upgrade to 2.x
------------------------------------------------------
Using winetricks 20171222-next - sha256sum: 01ebb56d22f54467343700eedfe283d82a47e67bbb6c2d68b7da743f41bb78a3 with wine-2.0-rc5 and WINEARCH=win32
------------------------------------------------------
Github down? version '' doesn't appear to be a valid version
------------------------------------------------------
------------------------------------------------------
You are running winetricks-20171222-next, latest upstream is winetricks-!
------------------------------------------------------
------------------------------------------------------
You should update using your distribution's package manager, --self-update, or manually.
------------------------------------------------------
No protocol specified
|
Breaking it down, it looks like the sha256sum that is created is the central aspect (or one of them) would you agree? Because the upgrade to 2.x doesn't seem to be the cause, but the connection to github is central to what it needs as winetricks is like you said a way of accessing the information from there. What do you think might help solve this?
Is it just adding ssl to wget? Let me start with that first...
[Moderator edit: added [code] tags to preserve output layout. -Hu] |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Sun Dec 31, 2017 5:06 am Post subject: |
|
|
That was it.
Marking as solved, thanks! |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sun Dec 31, 2017 5:27 am Post subject: |
|
|
| If winetricks is broken when wget has no TLS support, then the winetricks ebuild should RDEPEND on net-misc/wget[ssl] to enforce that you not install an unusable wget. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Sun Dec 31, 2017 6:02 am Post subject: |
|
|
| This is true. But maybe the reason that it went overlooked as that most installations of wget will already have it set from whatever standard profile is in use? In my case the chroot kinda changed it all up in terms of the use flags maybe. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Dec 31, 2017 2:48 pm Post subject: |
|
|
| Neverheless, a bug should be filed. Whether anything actually gets done about it is another story. |
|
| Back to top |
|
|
LIsLinuxIsSogood
Veteran
Joined: 13 Feb 2016
Posts: 1179
|
| Posted: Fri Jan 19, 2018 4:52 am Post subject: |
|
|
Hey just checking, if this is a report I could still be filing for winetricks to be set for RDEPEND on wget (ssl)
In terms of what I can do before filing the bug, I am going to have a look at the ebuild to see what else is in there, IDK!
If filing a bug seems like a good idea, could someone please help me to make sure I am not submitting it without having done some more debugging of the issue with no ssl use flag for wget, and hopefully the debugging is pretty straightforward, for something like this. So then I'd like to try to have more definitive or comprehensive info to attach to the bug report. Would it be best to maybe replicate the situation I was dealing with in order to provide a thorough bug report? |
|
| Back to top |
|
|
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 264
|
| Posted: Sat Apr 20, 2019 1:31 pm Post subject: |
|
|
| I just ran into this same error with firefox-bin-66-0-3. Adding USE=ssl to wget solved it. This seems like the kind of thing that portage could detect automatically by parsing the fetch address, so that ebuild writers wouldn't have to remember to require wget[ssl] somewhere in their ebuild. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sat Apr 20, 2019 4:28 pm Post subject: |
|
|
Portage permits users to choose some other transport command. That command can even be something exotic, like ssh central-file-server wget fetch-arguments, with the expectation that once wget on that server has completed the download, then the file will be visible "locally" via an NFS mount of the file server. I agree that it would be nice if the package manager refused to let you do things that are guaranteed to fail, but there are practical limits to how much environment checking you can do. I expect that wget without SSL support is nearly useless these days, so it's not unreasonable to assume that anyone who disables SSL support on it is doing something very special and has made appropriate arrangements.
It is not actually correct to require wget[ssl], for two reasons. First, if the user provides the file separately, through NFS, sneakernet, etc., then wget will never be called. Second, even if the user expects the ebuild to download the file, the user may not be using wget to do it, so requiring the user to install an SSL-enabled wget that will not be used is wrong. |
|
| Back to top |
|
|
mattst88
Developer
Joined: 28 Oct 2004
Posts: 422
|
|
| Back to top |
|
|
|
Other Things Gentoo
