The new wget2 in F40 no longer is able to download from FTP sites, whereas wget in F39 is able to. This loss of functionality might break some scripts and applications that depend on wget. For example, a number of weather apps grab METAR data from the US National Weather Service, and there is an FTP site for apps to get that data. To get the weather dockapp I use <https://www.dockapps.net/temperatureapp> working in F40 I had to download the wget package for F39 and extract its wget executable, which I put in /usr/local/bin as wget1 (so as not to conflict with the wget from the wget2-wget package), then I recompiled the dockapp to use wget1 instead of wget. Until wget2 supports FTP I'd like to see F40 include the old wget as an option. Reproducible: Always Steps to Reproduce: 1. Try to download a METAR weather data file from the US National Weather Service using wget (or wget2): wget ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDTW.TXT Actual Results: The file fails to download: $ wget ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDTW.TXT Failed to parse URI 'ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDTW.TXT' Nothing to do - goodbye Expected Results: The file should be downloaded: $ wget1 ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDTW.TXT --2024-05-15 13:23:43-- ftp://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDTW.TXT => 'KDTW.TXT' Resolving tgftp.nws.noaa.gov (tgftp.nws.noaa.gov)... 140.90.101.79 Connecting to tgftp.nws.noaa.gov (tgftp.nws.noaa.gov)|140.90.101.79|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /data/observations/metar/decoded ... done. ==> SIZE KDTW.TXT ... 445 ==> PASV ... done. ==> RETR KDTW.TXT ... done. Length: 445 (unauthoritative) KDTW.TXT 100%[===================>] 445 --.-KB/s in 0s 2024-05-15 13:23:44 (913 KB/s) - 'KDTW.TXT' saved [445] I also noticed that wget2 does not support plain HTTP by default—you have to supply the --https-enforce=soft option. So while there's a workaround, I imagine again that some scripts and applications that use wget will need to be updated to use that command-line option. I don't know how you'd get wget2 and the old wget to co-exist in the same system without some renaming (as I did with "wget1"), so perhaps the old wget could be made available in the F40 repos as "wget-legacy", which cannot be installed if wget2 is installed. I don't know how viable that solution would be.
Second that! I use wget to download recordings from my DVR system. Not only does it support FTP, it also has the best support for globbing. That makes it possible to define "wget --no-passive-ftp "ftp://<DVR_FTPUSER>:<DVR_FTPPASS>@<DVR_HOSTNAME>:/My%20Video/${1// /%20}", as a function, where the function argument $1 can be something like "myshow/*20240531*.ts" and wget finds that file. Not even good old curl supports that. Please bring wget 1 back!
Well, I think, wget2 sucks in terms of backward compatibility and also capability. But there seems to be no intention to provide wget1 alongside, according to this statement: https://bugzilla.redhat.com/show_bug.cgi?id=2283867 Going back to this actual report: FTP support is *not* even planned for wget2!
(In reply to samoht0 from comment #2) > Well, I think, wget2 sucks in terms of backward compatibility and also > capability. But there seems to be no intention to provide wget1 alongside, > according to this statement: > https://bugzilla.redhat.com/show_bug.cgi?id=2283867 > > Going back to this actual report: FTP support is *not* even planned for > wget2! FTP support has been discussed upstream: https://gitlab.com/gnuwget/wget2/-/issues/3 The only blocker is that nobody has contributed support for FTP to wget2 thus far.
Neal, you can't be serious. That thread was started eight years ago! Even the maintainers say wget2 is not ready for prime time and that it was never meant to be a drop in replacement for wget.
Came here to say that, among the other stuff, this bug breaks builds on crosstool-ng https://crosstool-ng.github.io/ because wget2 have different command line parameters and, most of all, does not support ftp. Moreover, many packages depends on wget2-wget, so it there is no easy way to work around this bug. People are installing wget1 from Cedora 39 or building it from sources and put in their $PATH... Please revert this and bring back wget1, maybe as alternative, maybe as a side package
I came up with another workaround on my F40 system that works so far: uninstall wget2 and wget2-wget, install the latest wget from F39, then exclude wget from dnf updates. This involved more hoops to jump through; see the details in this Fedora Forums thread: https://forums.fedoraforum.org/showthread.php?332571-F40-wget2-breaks-wget-compatibility&p=1884011#post1884011 I can't imagine most users would be willing to go through all that---they're more likely to just jump ship to another distro. Do we really want Fedora to be known as the distro where wget doesn't work? As mentioned in that thread, the best solution for F40 is to make the old wget the standard package, with wget2 as an optional package for those who want to try it out. I think people using wget are "old-school" and likely aren't even using whatever new features wget2 has, so the impact of this solution should be minimal. My guess is far more users are affected by the loss of FTP functionality. The thread on wget2's github about restoring FTP support hasn't had a comment in 2 years. I think the proposed solution for Fedora should be used until someone upstream fixes the problem. I know that backing out a packaging decision like this seems like a defeat, but practicality and meeting users' needs should be more important. It's not too late to do this.
Yep, I hit it today in f41: $ wget ftp://ftp.porcupine.org/mirrors/postfix-release/official/postfix-3.9.1.tar.gz Failed to parse URI 'ftp://ftp.porcupine.org/mirrors/postfix-release/official/postfix-3.9.1.tar.gz' Nothing to do - goodbye So apparently it isn't drop-in wget replacement.
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.