You are not logged in.
Trying to install WINE.
Seemed simple enough:
sudo pacman -S wine
It ended abruptly with an "FTP response timeout". I don't know why, as there are several mirrors available.
anyway I decided to try again, but oh no:
error: failed to commit transaction (wrong or NULL argument passed)
Now I'm at a standstill as both Google and the wiki has given up on me.
Please advice.
Edit:
Never mind for now, I think I figured it out.
Apparently klid.dk is somewhat unstable.
Edit:
Nope. Thought I had it working, but now is give the same error when trying to install.
Tried different mirrors without luck. They all seem to work as intended, but then again, it don't seem to be a mirror problem at this point.
Possible solution: Make sure to change mirror, do pacman -Sc or simply remove .part files from /var/cache/pacman/pkg/
Last edited by zacariaz (2012-01-23 08:03:57)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
I gather from a bug report that "wpa_supplicant-0.7.3-4-x86_64.pkg.tar.gz.part" in cache is the problem.
Is it safe just to delete it?
edit:
I don't have it after all.
Last edited by zacariaz (2012-01-18 13:08:57)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Ok so I tried pacman -Sc and tried downloading again, but as before it halt after downloading wine-1.3.37-1.1-x86_64 and after a while outputs:
error: failed retrieving file 'wine-1.3.37-1.1-x86_64.pkg.tar.xz' from mirrors.kernel.org : FTP response timeout
If the process on screen is anything to go by, it did in fact download it.
warning: failed to retrieve some files from multilib
error: failed to commit transaction (download library error)
Error occurred, no packages were upgraded.
Next step for me, unless someone jumps in, can only be to clear the cache entirely and try again.
Of course I could also rename the 'wine-1.3.37-1.1-x86_64.pkg.tar.xz.part' I now have in cache, (remove .part) but I'd rather not make such leaps of faith.
Please advice.
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
I just tested the downloaded file up against another one, downloaded by other means, and they are identical.
So what is it? hash error? some odd signature flaw?
I'm certainly too noob to figure this one out.
I'm gonna take my chances and remove the .part problem. Hopefully it won't screw anything up.
Last edited by zacariaz (2012-01-18 13:20:54)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
I was getting the same timeouts from kernel.org when issuing -Syyu, uncommented them and added more local http repos which seems to have solved my problem.
Anyone who knows what's going on is more than welcome to educate me,
thanks.
Last edited by Earnestly (2012-01-18 13:23:41)
Offline
Well that worked apparently, but still... It's a rather big problem.
I'd very much like to know how to act when such things happen. Should I file a bug report or something?
I was getting the same issues from kernel.org when issuing -Syyu, uncommented them and added more local http repos which seems to have solved my problem.
I tried several different mirrors.
Last edited by zacariaz (2012-01-18 13:24:02)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Just had the exact same problem with wine_gecko, also from kernel.org
Trying another mirror now to made sure it isn't kernel.org that is the problem.
Edit:
Success!
Seems kernel.org is the problem after all.
But who to report it to?
Last edited by zacariaz (2012-01-18 13:34:06)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Just had the exact same problem with wine_gecko, also from kernel.org
Trying another mirror now to made sure it isn't kernel.org that is the problem.
Edit:
Success!
Seems kernel.org is the problem after all.But who to report it to?
What is your mirror to solve this issue? I've tried several and all of them has ftp timeouts.
Thanks
Offline
My current mirror is some German one, first on the list, but it is a very odd problem.
What I did was (And I do not guarantee that this is safe, I'm simply not experienced enough):
pacman -Sc
To remove unused packages from cache.
rm /var/cache/pacman/pkg/*.part
Just to make sure be sure.
Edit your mirrors list to include only one mirror. Simply out comment all (remember the one that may be left from the installation at the very top) and pick one at random.
pacman -Syy
To force update.
That seemingly did the trick for me, though I can not say exactly why, or if it will work for you.
Hope it works.
Best regards.
Last edited by zacariaz (2012-01-19 14:25:01)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
zacarias solved my problem. Thanks !!!
Offline
Hurray, I'm contributing. Must mean I'm smart.
Anyway, I'm very pleased that I could help.
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Hi all,
I am having the same problem while trying to install linux-3.2.1-1-i686. I have tried the aforementioned fixes of zacariaz, but it still does not seem to work.
$ sudo pacman -Su
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (1): linux-3.2.1-1
Total Download Size: 39.98 MiB
Total Installed Size: 58.55 MiB
Net Upgrade Size: 0.98 MiB
Proceed with installation? [Y/n] y
:: Retrieving packages from core...
linux-3.2.1-1-i686 40.0 MiB 78.9K/s 08:39 [##########################################] 100%
error: failed retrieving file 'linux-3.2.1-1-i686.pkg.tar.xz' from ftp.iinet.net.au : FTP response timeout
warning: failed to retrieve some files from core
error: failed to commit transaction (download library error)
Errors occurred, no packages were upgraded.
And trying immediately afterward:
$ sudo pacman -Su
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (1): linux-3.2.1-1
Total Installed Size: 58.55 MiB
Net Upgrade Size: 0.98 MiB
Proceed with installation? [Y/n] y
(1/1) checking package integrity [##########################################] 100%
error: failed to commit transaction (wrong or NULL argument passed)
Errors occurred, no packages were upgraded.
Any help would be appreciated.
Offline
Sweet. This confirms what I suspected. Broken FTP servers are timing out on connection close and leaving you with a full .part file.
Simple solution: stop using broken servers. Use HTTP servers.
Offline
If it's the same problem that I've experienced a number of times now, it's safe to go to /var/cache/pacman/pkg and find (in your case)
linux-3.2.1-1-i686.pkg.tar.xz.part
Then simply remove .part and install again.
I suppose this is not a recommended approach, but as it is checking package integrity, I should think it won't break anything.
This is a rather big problem and I don't presume to understand anything about it. I do hope it will be fixed soon.
Best regards
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
I don't really call this thread solved... if anyone's interested, I've posted a patch to the pacman-dev ML and rolled up packages with the patch applied:
If you are using FTP mirrors and seeing timeouts as shown by ianhoolihan in post #12, with the ensuing "wrong or NULL argument passed", please try to reproduce using this package. I'm unable to test this myself as the bug does not affect me, but I'm rather interested in solving it.
Offline
If it's the same problem that I've experienced a number of times now, it's safe to go to /var/cache/pacman/pkg and find (in your case)
linux-3.2.1-1-i686.pkg.tar.xz.part
Then simply remove .part and install again.
I tried this multiple times, and it did not work.
Simple solution: stop using broken servers. Use HTTP servers.
I tried this, and the first time it did not work either. However, I tried again (after deleting the .part file), and this time it miraculously worked. I've no rhyme or reason for why. Actually, on second thought, maybe it did work first time. Oh, the joys of a fickle memory.
If you are using FTP mirrors and seeing timeouts as shown by ianhoolihan in post #12, with the ensuing "wrong or NULL argument passed", please try to reproduce using this package.
Next time I have the problem, I'll try --- if I know how to apply the patch by then.
Ianhoolihan.
Offline
have you made sure that there are no .part files left?
ls /var/cache/pacman/pkg/*.part
I will not pretend know what I'm talking about, but I've read that this can course problems.
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Yes... the symptom is the leftover .part file. The problem is that FTP control connection is closing during the data transfer, and when pacman tries to close the connection after the download, the 'BYE' command times out. This is detected as an error, and the download fails when it really didn't. Because the transfer "didn't finish", we don't rename the temporary file back to the package name. The root cause of the "wrong or NULL argument passed" error is elsewhere, but it needs to be fixed in the downloader.
Next time I have the problem, I'll try --- if I know how to apply the patch by then.
What? There's no need to apply the patch -- the links I provided are already built with it.
Offline
have you made sure that there are no .part files left?
Yes, I did. I tried pacman -Sc and manually deleting the .part files. It didn't work until I changed to http.
Yes... the symptom is the leftover .part file. The problem is that FTP control connection is closing during the data transfer, and when pacman tries to close the connection after the download, the 'BYE' command times out. This is detected as an error, and the download fails when it really didn't. Because the transfer "didn't finish", we don't rename the temporary file back to the package name. The root cause of the "wrong or NULL argument passed" error is elsewhere, but it needs to be fixed in the downloader.
Next time I have the problem, I'll try --- if I know how to apply the patch by then.
What? There's no need to apply the patch -- the links I provided are already built with it.
What you're saying makes sense. As for the patch, I only clicked on the "patch" link, and not the "i686", so missed it
Ianhoolihan
Offline
Offline