Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1553 mingw-get.exe: execl: libexec/mingw-get/lastrites.exe: No su

closed-fixed
2011-06-07
2011-05-30
Earnie Boyd
No

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.

Discussion

1 2 > >> (Page 1 of 2)
  • Keith Marshall
    Keith Marshall
    2011-05-30

    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?

     
  • Keith Marshall
    Keith Marshall
    2011-05-31

    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).

     
  • 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).

     
  • Keith Marshall
    Keith Marshall
    2011-05-31

    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.

     
  • Earnie Boyd
    Earnie Boyd
    2011-05-31

    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?

     
  • Keith Marshall
    Keith Marshall
    2011-05-31

    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.

     
  • Keith Marshall
    Keith Marshall
    2011-05-31

    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.

     
  • Earnie Boyd
    Earnie Boyd
    2011-06-01

    • status: open --> closed-fixed
     
  • Earnie Boyd
    Earnie Boyd
    2011-06-01

    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.

     
  • Keith Marshall
    Keith Marshall
    2011-06-01

    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.

     
1 2 > >> (Page 1 of 2)