Description of problem: I'm using (or attempting to) fedup to upgrade from F19 to F20. I did this on my home machine with no problems, but here at work, I access tings thru a proxy. The environment variables are nicely defined and 'yum' can fetch packages OK, but 'fedup' appears to zone out. Version-Release number of selected component (if applicable): fedup.noarch 0.8.0-3.fc19 How reproducible: Always, but only on proxy walled machines. Steps to Reproduce: 1. # fedup --network 20 I have entered this exact command on non proxy machines and it works fine. I have the following proxy environment variables set: http_proxy= ftp_proxy= https_proxy= 'yum' can access repositories just fine. Actual results: # fedup --network 20 --debug --verbose usage: fedup <SOURCE> [options] fedup: error: argument --network: invalid VERSION value: '20' Expected results: Nice updates, but at least not 'invalid version number' Additional info: On another machine (no proxy here): # fedup --network 20 setting up repos... default-installrepo/metalink | 18 kB 00:00 default-installrepo | 3.6 kB 00:00 default-installrepo/group_gz | 210 kB 00:00 (just the beginning of the messages. I already had this machine at Fedora 20, so there was no need to continue. I assume that this is proper. Version on second machine: fedup.noarch 0.8.0-3.fc20
fedup inherits its proxy config from yum (which just lets libcurl do the work), so there's no obvious reason they should work differently. Also, the error message you mention usually happens well before any attempt to access the network. So I'm not sure this has anything to do with proxies? Could you attach /var/log/fedup.log from the proxied system? Also, what happens if you run "rpm -V python-libs fedup"? Any output there would indicate that something is wrong with the files on your system.
I did the following: [root@twatson2012 log]# rpm -V python-libs fedup [root@twatson2012 log]# fedup --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --network: invalid VERSION value: '20' [root@twatson2012 log]# cat /var/log/fedup.log cat: /var/log/fedup.log: No such file or directory Looks like no log was created by the fedup action. I have gotten other instances of fedup to create logs. In this case, I removed the older ones and ran the fedup command as shown above. Somehow it is aborting pretty early in the process (my guess).
More information: If you have the file 'debian_version' in the /etc directory, it causes this failure. I had it there for some testing, thus the failure. You might want to check this at some time! The error message is VERY unclear! >>>>> [tsw@twatson2012 etc]$ fedup --network 20 you must be root to run this program. [tsw@twatson2012 etc]$ su Password: [root@twatson2012 etc]# mv debian_ver.not debian_version [root@twatson2012 etc]# exit exit [tsw@twatson2012 etc]$ fedup --network 20 usage: fedup <SOURCE> [options] fedup: error: argument --network: invalid VERSION value: '20' <<<<<
Ah! I think /etc/debian_version confused python's "platform" module such that it: a) thinks you're running something other than Fedora, and b) gives a "version" that isn't a number. What happens if you replace /etc/debian_version and run this? python -c 'from platform import *; print linux_distribution()' without /etc/debian_version you would get something like: ('Fedora', '19', 'Schr\xc3\xb6dinger\xe2\x80\x99s Cat') What do you get if /etc/debian_version is there? And can you attach (or just paste the contents of) /etc/debian_version? I should be able to fix that error message pretty easily.
The file /etc/debian_version has a single line, something like: >>>>> 6.0.7 <<<<< This is what it had when it errored out on me. It seems that you look for files with 'version' in the name and expect things. The contents of 'debian_version' seem to trip up the code and make it get all flustered. I removed the file on the machine here (with proxy, which I thought was the problem), and the 'fedup' from 19 to 20 worked just fine. Of course I needed to add 'selinux=0' to the line in the grub configuration, but that is another matter. On a Debian (yuck, but I have to deal with it) I get: tsw@machine:~$ python -c 'from platform import *; print linux_distribution()' ('debian', '6.0.7', '') On my just (yesterday) updated Fedora machine: [tsw@twatson2012 Jan27]$ python -c 'from platform import *; print linux_distribution()' ('Fedora', '20', 'Heisenbug') If I put back in the debian_release file: [tsw@twatson2012 Jan27]$ cat /etc/fedora-release Fedora release 20 (Heisenbug) [tsw@twatson2012 Jan27]$ cat /etc/debian_version 6.0.7 [tsw@twatson2012 Jan27]$ python -c 'from platform import *; print linux_distribution()' ('debian', '6.0.7', '') So, it seems that the 'linux_distrubution' routine prefers debian releases and quits there. Bummer, it should be the other way around. Hope this helps.
fedup-0.8.0-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedup-0.8.0-4.fc19
fedup-0.8.0-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.8.0-4.fc20
Package fedup-0.8.0-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedup-0.8.0-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3270/fedup-0.8.0-4.fc20 then log in and leave karma (feedback).
fedup-0.8.0-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
fedup-0.8.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.8.1-1.fc20
fedup-0.8.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.