Menu
▾
▴
[MinGW-notify] [ mingw-Bugs-3309438 ] mingw-get.exe: execl: libexec/mingw-get/lastrites.exe: No su
|
From: SF/projects/mingw n. l. <min...@li...> - 2011-06-03 16:12:24
|
Bugs item #3309438, was opened at 2011-05-30 20:39 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3309438&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW Installer Group: None >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Earnie Boyd (earnie) Assigned to: Keith Marshall (keithmarshall) Summary: mingw-get.exe: execl: libexec/mingw-get/lastrites.exe: No su Initial Comment: Summary: mingw-get.exe: execl: libexec/mingw-get/lastrites.exe: No such file or directory Executing mingw-get upgrade mingw-get more than once will cause this error. Listing /libexec/mingw-get doesn't display a lastrites.exe either, it should have been created with an unzipped download of the previous alpha version. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2011-06-03 16:12 Message: It's actually not fixed properly; all I did was kludge around the issue by rebuilding with a less inclusive set of tracing options enabled. While this gets around the immediate problem, I should be able to build with all tracing options selectable. I've located the problem area in the code, and have a tentative solution. Reopening to remind me that I need to finalise and commit that, before the next release. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-06-01 13:26 Message: I hadn't given it a lot of thought, but yes, a `mingw-get clean' operation to delete cached package files is something I would have gotten to eventually. For reference, apt-get, (on which mingw-get is loosely modelled), provides `apt-get clean' and `apt-get autoclean', (neither of which accepts any package selection arguments); `clean' removes all cached package files, while `autoclean' removes only obsolete packages, (i.e. those which are no longer referenced in the catalogue). Of course, we don't have to slavishly clone apt-get; we already deviate in respect of the upgrade operation: (`apt-get upgrade' does not accept package specific arguments, but rather applies to all packages which are installed). I kind of prefer the package specific method used by mingw-get, both in the upgrade case and in the case of an eventual clean (or clean-cache) operation. However, I guess discussion of this will be more appropriate on mingw-dvlpr, rather on this ticket, where it somewhat off-topic. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-06-01 12:24 Message: Yea, well, no, I had not removed the cached copy. Any plans to a -ignore-cache switch, meaning to download a fresh copy? One of these might work: mingw-get upgrade --ignore-cache mingw-get mingw-get upgrade --force-download mingw-get mingw-get upgrade --redownload mingw-get Or perhaps a clean-cache action: mingw-get clean-cache mingw-get; # specifies to remove the cached copies of mingw-get. mingw-get clean-cache; #specifies to remove all files in the cache. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-05-31 15:08 Message: As an additional test, I just forcibly removed lastrites.exe, and the two 0.3 tarballs from the package cache: $ rm /mingw/libexec/mingw-get/lastrites.exe $ rm /mingw/var/cache/mingw-get/packages/mingw-get-0.3* $ ls /mingw/libexec/mingw-get/ gui.exe mingw-get-0.dll $ ls /mingw/var/cache/mingw-get/packages/mingw-get-0.3* ls: /mingw/var/cache/mingw-get/packages/mingw-get-0.3*: No such file or directory $ mingw-get upgrade mingw-get http://prdownloads.sourceforge.net/mingw/mingw-get-0.3-mingw32-alpha-1-bin.tar.gz?download 219.19 kB / 219.19 kB |================================================| 100% http://prdownloads.sourceforge.net/mingw/mingw-get-0.3-mingw32-alpha-1-lic.tar.gz?download 12.07 kB / 12.07 kB |================================================| 100% upgrade: mingw-get-0.3-mingw32-alpha-1-bin.tar.gz removing release mingw-get-0.3-mingw32-alpha-1-bin.tar.gz installing mingw-get-0.3-mingw32-alpha-1-bin.tar.gz upgrade: mingw-get-0.3-mingw32-alpha-1-lic.tar.gz removing release mingw-get-0.3-mingw32-alpha-1-lic.tar.gz installing mingw-get-0.3-mingw32-alpha-1-lic.tar.gz $ ls /mingw/libexec/mingw-get/ gui.exe lastrites.exe mingw-get-0.dll $ ls /mingw/var/cache/mingw-get/packages/mingw-get-0.3* /mingw/var/cache/mingw-get/packages/mingw-get-0.3-mingw32-alpha-1-bin.tar.gz /mingw/var/cache/mingw-get/packages/mingw-get-0.3-mingw32-alpha-1-lic.tar.gz Notice that running `mingw-get upgrade mingw-get' has brought them back. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-05-31 14:55 Message: No. mingw-get has no concept of files being up to date. If it says it's installing any particular tarball, then all files present in that tarball will be extracted, overwriting any previous file of the same name. I've tried this myself, several times. I've rolled back to 0.2-alpha-3 -- didn't have alpha-4 in my local package cache -- and run `mingw-get upgrade mingw-get' a number of times. Every time, /mingw/var/libexec/mingw-get has had the three files: gui.exe lastrites.exe mingw-get-0.dll as it should. I simply cannot reproduce this issue. Are you sure you removed the bad tarball from /mingw/var/cache/mingw-get/packages? If you didn't, mingw-get will just keep unpacking that, without bothering to download the correct one. The mingw-get-0.dll in the bad tarball correctly performs the remove operation, but it declines to save the replacement files during the subsequent install operation. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2011-05-31 14:01 Message: To answer the FIXME question, yes I see those. Overlaying the contents from the recent tar.gz file causes the issue to go away. However, if I overlay with the 0.2-alpha-4.zip file the problem returns with an upgrade of mingw-get. Listing the contents of /libexec/mingw-get after the first upgrade shows the lastrites.exe file present and missing after the second pass. Hmm... testing again the 0.3-alpha-1.tar.gz file, the second upgrade test of mingw-get causes the removal of lastrites.exe. So it appears to think that lastrites.exe is up-to-date and doesn't reinstall it after removing it? ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-05-31 11:47 Message: Hmm. We obviously can't take responsibility for anti-virus software which trashes downloads, but perhaps mingw-get could perform some form of integrity check, before blindly deploying. As a first step, I guess reading the tarfile headers, and verifying their checksums, all the way through to the end-of-data header, would yield some degree of confidence. It wouldn't verify data integrity -- the checksums are computed on the headers only, IIRC -- but short of us maintaining a separate catalogue of MD5 or SHA1 hashes, or some such, for every package -- a burden which I am reluctant to take on -- it would at least confirm that the chain of headers is complete and intact. ---------------------------------------------------------------------- Comment By: Chris Sutcliffe (ir0nh34d) Date: 2011-05-31 10:57 Message: I ran in to this issue when my anti-virus software partially blocked the download of 0.3-alpha1. It resulted in a corrupt tar file but I suspect wget returned OK, as a result mingw-get removed the previous version and attempted to install 0.3-alpha1, which failed due to the incomplete tarball. I got around it by adding an exception for the SourceForge download servers in the WebFilter as well as adding an exception for both mingw-get.exe and \MinGW\libexec\mingw-get. I am in the process of reporting the false positive to the vendor (G-Data). ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-05-31 09:50 Message: I've just had an opportunity to try this myself, on a real msw system; following my repost of the binary tarballs, I cannot reproduce this. I'm leaving open for now, because there is an underlying fault in that the install operation isn't respecting the -trace option, and is defaulting to dry-run mode when that is enabled at build-time. I've simply rebuilt without support for -trace on the install operation, for the reposted 0.3-alpha-1 release; (only download tracing -- -trace=0x0100 -- is currently enabled). ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2011-05-30 21:51 Message: Is this upgrading to 0.3-alpha-1? Did you see a raft of FIXMEs on the second run, indicating that files were not being extracted? I just posted a rebuild of the -bin components. Please download a fresh copy of the tarball or zipfile, and extract over the top of your failing installation, remove the broken tarball from <MINGW-GET-ROOT>/var/cache/mingw-get/packages, and try again. Does that work any better? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3309438&group_id=2435 |