DrOli commented 8 years ago

Have tried many times with many permutations to install Msys2 on WinXP64 (all SP's) using msys2-x86_64-20160205.exe. It almost never even gets to the first step of update-core due to "GPGME" etc errors.

1) on the rare occasions that it has, any variation of pacman -Su, Syuu etc fails with "GPGME error" "invalid crypto" etc. (see attached jpg). Apparently MSys2's databases become "corrupt" and after that it will not work. One attempt at a solution is to delete the Sync Dir. This allows a pacman Su etc to work once in the sense that it recreates the Sync dir, but again with "corrupt" db's.

There is no possibility of downloading anything even with Sync deleted, since it must first create Sync for the download, and immediately creates corrupt db's, preventing any further communication with the server.

2) On some occasions, not idea why, it completely "looses bash", and will not accept any bash commands at all (e.g. pacman).

3) Have tried various other "fixes" seen on the web (autorebase) etc., no joy.

... couldn't find an WinXP64 specific solutions on the MSys forum

No idea how to proceed, but would desperately wish to have a working WinXP64 install.

PS. Have tried several times to attach a jpg of a screen print example of the GPGME etc errors, but the blog keeps responding with "Something went really wrong, and we can't process that file". Trying again doesn't help

Alexpux commented 8 years ago

Well we not support Win XP 64. Never try it and never test on it.

DrOli commented 8 years ago

That's weird, according to Ray Donnelly, an MSys2 developer:

  "We target Windows XP SP3 as a minimum and support both 32bit and 64bit Windows"

as seen here (http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other).

I actually did some checking before my tests to make sure WinXP was supported, and apparently it is. Also, on the net, various people discuss using MSys2/WinXP.

So, is Ray Donnelly wrong, or ???

If so, the MSys2 installer should have enough sense to check for Win Ver, and NOT install on incompatible Windows.

Please advise.

Alexpux commented 8 years ago

Well installer is not working on Win XP at all. Need use tarballs to extract base MSYS2. We support Win XP 32-bit. 64-bit Win XP is very rare case and I have not installed it anywhere. If you want support for 64-bit Win XP please dig into problems and provide solution for it. MSYS2 is free time project so if you want if anything will be fixed soon - spend some time yourself

DrOli commented 8 years ago

OK, so:

0) I am not sure if it's some "language thing", but I don't understand some of the words you are using. I have no idea what "turbans" are in this context.

1) As the developers state that WinXP is "targeted", it should be supported. In the alternative, make it clear on your dload/install pages that your product does not work with WinXP so people don't waste their time with ... and it may help if all the staff at MSys2 "has the same story", rather than the conflicting story unfolding here.

2) As WinXP is an important platform, we definitely would wish for it to be supported.

3) As for us to the "dig into problems and provide solution for it". We have spent many man hours trying to get it to work, so far all that time is a waste. The problems with MSys2 seem to "deep in its bowels", and we have no access to, control over, or knowledge of why it throws GPGME errors, and why it insists on corrupting its own databases, which are managed with proprietary and inaccessible machinery in MSys2.

I should say that also, while it may not be intended, your responses seem to come across a bit confrontational and unhelpful. At the very least, you might provide information on how one would even approach a "solution" to the stated errors. Perhaps Ray Donnelly or somebody might be asked to respond.

DavidEGrayson commented 8 years ago

@DrOli: For what it's worth, there is more information about GPGME errors here: https://github.com/Alexpux/MSYS2-packages/issues/393

Alexpux commented 8 years ago

@DrOli, sorry some words are wrongly written by autocompletition here. turbans - tarballs

DrOli commented 8 years ago

Based on DavidEGrayson's suggestion, I performed all that I could from that link, with the errors as described below:

completely removed MSys2

Follow instructions from https://github.com/Alexpux/MSYS2-packages/issues/393

no MacType anywhere

no gnupg anywhere

had cygwin/cygwin terminal installed, so just in case, uninstalled that (not a simple process)

... from BLODA, I have no software installed that is on their "conflict" list

rebooted

clean install MSys2, following the EXACT instructions from (https://msys2.github.io/)

gpgme errors all over the place, so, (David's suggested link)

1) Try re-installing gpgme libgpgme, gnupg and pacman packages (you can temporarily disable signature checking in /etc/pacman.conf) ... no joy.

2) Try removing /etc/pacman.d/gnupg, then pacman-key --init, pacman-key --populate msys2, pacman-key --refresh-keys.

... the first two steps appeared to go OK, but he last step produced and ERROR, as per:

$ pacman-key --refresh-keys gpg: refreshing 8 keys from hkp://pool.sks-keyservers.net gpg: requesting key 3E058AFD from hkp server pool.sks-keyservers.net gpg: requesting key CA25678A from hkp server pool.sks-keyservers.net gpg: requesting key AEEA755C from hkp server pool.sks-keyservers.net gpg: requesting key 3E0D0813 from hkp server pool.sks-keyservers.net gpg: requesting key 3E652008 from hkp server pool.sks-keyservers.net gpg: requesting key A47D45A1 from hkp server pool.sks-keyservers.net gpg: requesting key 2C51581E from hkp server pool.sks-keyservers.net gpg: requesting key 4CA56930 from hkp server pool.sks-keyservers.net gpgkeys: key 6EB171030F67EB34A071054739D5AE203E058AFD not found on keyserver gpg: DBG: armor-keys-failed (KEY 0x6EB171030F67EB34A071054739D5AE203E058AFD BEGIN ) ->0 gpg: DBG: armor-keys-failed (KEY 0x6EB171030F67EB34A071054739D5AE203E058AFD FAILED 6 ) ->6 gpg: key CA25678A: "Alexey Pavlov (Alexpux) alexey.pawlow@gmail.com" 4 new signatures gpg: key AEEA755C: "Martell Malone (martell) martellmalone@gmail.com" 3 new signatures gpg: key 3E0D0813: "Ray Donnelly (MSYS2 Developer - master key) mingw.android@gmail.com" 2 new signatures gpg: key 3E652008: "Ignacio Casal Quinteiro icquinteiro@gmail.com" 2 new signatures gpg: key A47D45A1: "Alexey Pavlov (Alexpux) alexpux@gmail.com" 1 new signature gpg: key 2C51581E: "Martell Malone (MSYS2 Developer) martellmalone@gmail.com" not changed gpg: key 4CA56930: "Ray Donnelly (MSYS2 Developer) mingw.android@gmail.com" 2 new signatures gpg: Total number processed: 7 gpg: unchanged: 1 gpg: new signatures: 14 gpg: keyserver communications error: key not found gpg: keyserver communications error: bad public key gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 4 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 4 signed: 3 trust: 0-, 0q, 0n, 4m, 0f, 0u gpg: depth: 2 valid: 3 signed: 0 trust: 3-, 0q, 0n, 0m, 0f, 0u gpg: keyserver refresh failed: bad public key ==> ERROR:

... this probably will make the rest of tests meaningless, but continue with rest of

3) Maybe autorebase.bat is sometimes needed even for 64-bit MSYS2.

... restarted Msys2, update-core --> gpgme error as usual

4) Try debugging for GPGME by export GPGME_DEBUG=9 before running pacman ...something... 2> ~/gpgmelog and looking at the logfile ~/gpgmelog

... try pacman -Syuu 2> ~/gpgmelog and looking at the logfile ~/gpgmelog

... the log file contains:

error: GPGME error: Invalid crypto engine error: GPGME error: Invalid crypto engine error: GPGME error: Invalid crypto engine error: GPGME error: Invalid crypto engine error: failed to update mingw32 (invalid or corrupted database (PGP signature)) error: GPGME error: Invalid crypto engine error: failed to update mingw64 (invalid or corrupted database (PGP signature)) error: GPGME error: Invalid crypto engine error: failed to update msys (invalid or corrupted database (PGP signature)) error: failed to synchronize any databases error: failed to init transaction (invalid or corrupted database (PGP signature))

... OK, so what do I do now?

mingwandroid commented 8 years ago

There are no staff at MSYS2 nor is there anything proprietary. It is entirely open source and done in our spare time.

For supported operating systems, we do our best to not break support for what we claim to support, and certainly used to support when those things were written, which is 32 bit XP SP3. Windows XP 64 is a very unusual beast indeed and since none of us have it installed we can't make any guarantees that it runs on that operating system.

The best we can do is to update our documentation to say that XP 64 bit is probably not supported and for 64 bit, Vista or above is required. You might want to try Cygwin 64 bit to see if that works, but even if it does it just means that theoretically we could support XP 64, but we still face the two issues, lack of time and lack of software.

Alternatively, perhaps someone on the #msys2 channel on the oftc irc network also runs XP 64 and might be able to offer some assistance? It's unlikely but may be worth a shot.

DrOli commented 8 years ago

Dear MR Donnelly

Thank you for the clarification, though I am not sure if it gets us to the next step. However, a couple of items before "the next step", which I leave for last.

1) I am not sure why you have taken issue with the word "staff", a standard dictionary definition includes "The personnel who carry out a specific enterprise", and so my usage is perfectly accurate. Nevertheless, I am happy to change to the word to "team" or any other reasonable choice you may suggest ... but I wonder if this is the sort of thing our time should be spent on.

2) "Proprietary": The GPGME errors are accompanied by expressions like "invalid or corrupted database". We tried to assess the db's in our efforts to determine the "corruption", but could not find any db machinery in our possession that could open those files. It is in this sense that I used the word proprietary, since the MSys2 db's did not seem accessible by any standard db mechanism at our end. Again, I am happy to change the semantics.

3) WinXP 64: Would you agree that your comment on StackOverflow:

"We target Windows XP SP3 as a minimum and support both 32bit and 64bit Windows"

is reasonably interpreted as including WinXP64? And as such, would invite investment into the process on that expectation. Apparently, based on what you say now, that should have been appended with something like "except WinXP64" ... though now after considerable investment by us.

4) As indicated in my previous submissions, we had CygWin64 already installed and working. We un-installed it based on the possibility of a conflict, as implied by link #393

5) I don't know what "#msys2 channel on the oftc irc network" is, but I'll look into it.

Be that as it may, I wonder if our time would be better spent on actually getting this thing to work. Thus far, we have invested in excess of 70 man-hours testing a vast number of permutations and variations, and with little help from your team. There are a quite a number of places where your team invites/encourages the public to test/report etc etc. Well, we've been doing just that.

... and in our case, it is not simply "in our spare time", it is also on "company time", and so that means REAL cash has been spent (based on the expectation that WinXP64 was supported, as per your earlier statements).

We are not sure why your team cannot explain or otherwise assist with tracking down why this thing is throwing GPGME/corrupt database errors, or why it can't get the public key right, etc, etc as per our reports. As it's your code, one would imagine you might know where and why in the code these error's are thrown ... at least to the point to allow some testing, even just to get to the "boundaries".

Your response follows exactly one of those detailed detailed/test reports I submitted, with logs, error messages, etc. We are not sure why your team could not respond to that in any specific way.

Clearly, we are prepared to invest time in this process, but we are "math geeks" (not "IT geeks"), so a little help pointing us in the right direction would be appreciated ... we are happy to give you our time, but "throw us a bone" now and then :-)

... in the alternative, if you are now simply "throwing us to the dogs", and after those invitations/encouragements to invest time/resources, I think MSys2's reputation/credibility will, quite correctly, take a hit.

Cheers

DrO

PS. I am a little surprised that you would be willing to support Vista64 and not XP64, when Vista is commonly accepted as one of the greatest software abominations in recorded history. Indeed, as XP64 is really just a variation of Server03, would you need to update your "support commitment statement" to only non-server Windows variants?

And, while no offence is intended, and while I appreciate the issue of "scarce resources/time", it seems somewhat odd to hear that your team can't get their hands on a copy of WinXP64. Even just amongst us "math geeks", we have access to/saved all software going back to DOS, win3, Win95, etc. So we would have imagined that IT types would have even greater access to such things ... In any case, we have WinXP64, so we could/would/like to get it going, but some "directions" are needed, to do what you would accomplish at your end if you had installed WinXP64.

DrOli commented 8 years ago

BTW, an experiment we would have performed earlier, had there not been the discouragement on the MSyse pages to MSys2-32bit, is that of installing msys2-i686-20160205.exe on WInXP64.

FYI, it actually does NOT have any of the 64bit's GPGME errors. Unfortunately, it has other, apparently terminal, problems. For example, trying to close the shell, say after running update-core (which works with the 32bit MSys2), one gets various errors, such as there being multiple bash.exe's in TaskManager, and the inability to close the shell (at least not without "end Task" in TaskManager).

Following that it may be possible to launch the shell or not, with errors like "usr/bin/mintty: could not detach from caller", but typically if a second launch succeeds, that's about it. No more shell launching after that, with the same mintty issue.

So, 64 bit can't communicate with the server, but the shell works. 32 bit, can communicate with the server, but the shell crashes ... all on the same WinXP64 box.

... this seems to suggests that a working 64bit should be possible, if it could just have the same coms reliability as the 32bit.

DrOli commented 8 years ago

... oops, I clicked the Comment button accidentally before finishing the last Comment.

Not sure why, but the 64bit batch files are via CMD.exe, while the 32bit batch files are executed directly. If the 32bit batch files are launched via CMD, then the mintty problem is alleviated to some extent.

That is, it may be possible (need more testing) to have a working MSys2 on WinXP64 with the 32bit version of MSys, though clear getting the 64bit to work is desired.

mingwandroid commented 8 years ago

libalpm is a part of pacman. That is the library that you need to read the databases of MSYS2 (and ArchLinux), the source can be found here: https://projects.archlinux.org/pacman.git/

We're not throwing anyone to any dogs or anything of the sort, I don't have XP 64, have no way of getting it, no interest in getting it and no time or space to install it anyway. I don't collect old operating systems.

XP 64 is IMHO a complete oddity in the MS OS ecosystem and all variants of XP are end-of-lifed anyway. You are using an Operating System that doesn't receive security updates anymore and quite soon Cygwin will stop supporting it. When that happens, MSYS2 will also drop all XP support.

If you want to learn how to investigate it for yourself I'm happy to help you out with that though. The IRC channel is the best place.

GranoblasticMan commented 8 years ago

Even in its heyday, XP64 was not fully supported by the vast majority of software (or hardware, for that matter). It was not widely-used or installed (in fact, I don't think I ever saw it included with consumer PC purchases; only the 32-bit version was). Part of the reason is due to an incomplete implementation of WoW64, which was more robust starting with Vista. See: https://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition#Software_compatibility http://betanews.com/2010/07/09/after-five-years-64-bit-editions-of-windows-make-up-nearly-half-of-install-base/ (less than 1% of XP machines were 64-bit at the time of this 2010 article)

DrOli commented 8 years ago

Many thanks for all the thoughts, though there continues to be digressions away from the issue at hand. I don't really see that it is a good use of your or our time to go off on those digressions

As a matter of courtesy, I provide some limited response to the digression by Mr Donnelly and GranoblasticMan, though I don't think I will do too much of that in the future.

As these digressions dilute the important issue of getting MSys2 to work, I have separated my response into two parts. This part/Comment is just for the digressions. I will submit a separate and independent Comment focusing on the technical matters, and moving forward.

CAVEAT: the digressions made previously require something of tome to respond to properly. I simply don't have the time or budget for that. So I touch on a few salient points, purely as illustrative examples.

1) Pooh-poohing XP64 is all well good, though some of the remarks made don't stand tests/results we have performed/obtained from actually doing our own test, rather than relying on third party opinions.

2) 64bit Windows variants are designed to run 32bit apps, so even if you (now) don't support XP64, the XP32 variant should work on 64, but it does not (though we have figured out a way to make it work, sort of, on XP64 ... more on this in my "Part 2/next Comment").

3) The continued insistence on not installing XP64 seems miss-placed at MSys2, since, as per my earlier submissions, we have it, and we are willing to do the work without MSys2 needing to install it ... so long as we get a little help along the way.

In any case, the original point was (several comments ago), if you don't want do XP64, don't, that's your right, no need to make excuses for us ... and which you have stated in your follow-up Comment since.

4) The "end of life" issues may drive MSys2 to whatever decision MSys2 believes best at your end.

Having said so, approximately 30% or the planet (as of this month) is running XP. I am willing to bet it would be bigger were it not for MS's business model, and quite frankly some chicanery.

Bizarrely, the XP installed base grew faster than the 8.1 installed base in the last couple of months.

The links GranoblasticMan's Comment are 404's. Though it is easy enough for us to obtain installed based stats.

From where we sit, we think XP user's wont "go gently into the good night", see also below.

5) There are quite a few misdirections implied by some of the remarks. For example, GranoblasticMan remarks such as "XP64 was not fully supported by the vast majority of software (or hardware, for that matter)" seems to be misplaced.

We have found good support for both software and hardware, indeed better compared to WIn7 (see below)

Moreover, those sorts of problems exist, and often worse, for other OS's. Just as one of many examples I could provide, Adapatec refuses to make a proper scsi driver for Win7/64 (still). As all of our machines are scsi based, it means, amongst other things, we lose half the scsi channels if we boot into Win7, and with that lose access to any and all hard drives on those channels. I could go on for sometime on these sorts of things ...

We don't have any such problems on XP64.

... as noted, all these digressions are well a good, but they are not all that helpful to the current matter, and, quite frankly, not entirely a reliable basis for pooh-poohing XP/XP64.

I won't even begin commenting on Vista (a word that should not be used in polite company :-), which, and oddly in our mind, is supported by MSys2. Indeed, if GranoblasticMan's implied logic of relying on installed base as criteria for "support" is extrapolated, then Vista should be dropped from support also.

As for the more recent versions of Windows, starting with 7, they have incorporated a colossal number of ridiculous and preposterous "features" that make the cost of ownership and just the cost of doing otherwise simple tasks required on a daily/routine basis, unbelievably difficult/expensive, due MS's choices.

... you may wish to pooh-pooh XP, but things are much worse, from our perspective, in each every WIn ver since.

We are "OCP math geeks". It is not only good business, but also we are "hard-wired" to test carefully and thoroughly. We make our decisions following considerable assessments. If we have taken a decision to go down a particular path, perhaps you can give us the benefit of doubt that it is for good reasons, even if you are not aware of those reasons.

... so while we respect the choices MSys2 makes, it would be nice if MSys2 respected the choices we make for ourselves.

I am obliged to remind ourselves that we got here in the first place since MSys2 had made clear representation that WinXP 32 and 64 were "targeted" by MSys2. I appreciate that now MSys2 has decided not to support XP64, and that's MSys2's right ... but then, really, are all these digressions necessary. All these hand-waving arguments of "this that and the other thing" about XP64 are not worthy of your or our time, and some of it comes across as a smoke screen.

So, gentlemen, while I appreciate your digressions and views, I think I will now and moving forward restrict my attention to the technical issues.

Finally, Mr Donnelly, thank you for kind offer, we will do our best to make good use of it.

... Please see some WinXP64 test results in my next Comment.

DrOli commented 8 years ago

Some WinXP64 MSys2 test results:

A) First, we have updated our MSys2 testing strategy: it is now a parallel test, one for MSys2/64, and one for MSys2/32.

B) The results in this Comment relate to some findings with MSys2/32 on WinXP64.

1) First, the good news, we can get MSys2/32 to work, sort of, on WinXP64. It does not work reliably "out of the box", but with a couple of simple adjustments, it can be made to work quasi-reliably, though still with some "concerns", some of which are detailed below.

2) Out of the box, MSys2/32 cannot be used reliably on WinXP64 for a number of reasons. On the first launch of an MSys2 shell, there are at least two problems:

(i) running update-core appears to complete (to that point it asks for itself to be closed), but then the "shell"/MSys2 "freezes" or "is not responding", requiring end process in TaskMan to close.

(ii) Thereafter, it is not possible to run the MSys2 Shell (directly), since any attempt to launch fails with a dialogue box stating to the effect "mintty could not detach from caller".

... this may be related to another mintty "issue" discussed below.

... our "guess" is that after the very first shell was launched, MSys2 may have connected to mintty through services.exe, or bash.exe, or ??, but when the shell is closed, somehow services.exe is not told to drop mintty, etc ... or something to that effect.

... also, depending on the exact sequence of the install (and making the adjustments in 3) below), under some conditions, every time a shell is launched, yet another entry for bash.exe appears in TaskMan (so if you launched/close the shell 3 times, there will be three bash.exe in TaskMan).

3) On a hunch, we decided to create short-cuts to msys2_shell.bat via cmd.exe, rather than simply attempting to run D:\Apps\msys32\msys2_shell.bat directly. The idea being that WinXP64's cmd might help intercede with "detaching's" etc. That is, the short-cut now has

C:\WINDOWS\system32\cmd.exe /A /Q /K D:\Apps\msys32\msys2_shell.bat

we also tested exactly the same thing with a 64 bit cmd.exe, but that discussion is omitted for now.

... this WORKS, sort of. The "mintty detach" issue does not seem to come up to prevent launching a shell. A Shell is launched, and can be used, sort of, for many, but not all, things.

Some of the issues under these conditions include:

a)$ update-core bash: update-core: command not found

... no idea why, or how to fix (keeping in mind that update-core appeared to work on the very first launch of the shell, but then "froze" the shell after it appeared to complete the update, and explicitly asked for itself to be closed).

b)$ pacman -Syuu :: Synchronizing package databases... mingw32 265.8 KiB 255K/s 00:01 [#####################] 100% mingw32.sig 96.0 B 0.00B/s 00:00 [#####################] 100% mingw64 265.2 KiB 796K/s 00:00 [#####################] 100% mingw64.sig 96.0 B 0.00B/s 00:00 [#####################] 100% msys 136.0 KiB 387K/s 00:00 [#####################] 100% msys.sig 96.0 B 0.00B/s 00:00 [#####################] 100% :: Starting full system upgrade... resolving dependencies... looking for conflicting packages...

Packages (5) filesystem-2016.04-1 gzip-1.7-1 msys2-launcher-git-0.3.28.860c495-1 msys2-runtime-2.5.0.17073.1439def-1 msys2-runtime-devel-2.5.0.17073.1439def-1

Total Download Size: 5.74 MiB Total Installed Size: 28.23 MiB Net Upgrade Size: 0.33 MiB

:: Proceed with installation? [Y/n] y :: Retrieving packages ... filesystem-2016.04-... 31.1 KiB 1941K/s 00:00 [#####################] 100% msys2-runtime-2.5.0... 2.2 MiB 753K/s 00:03 [#####################] 100% gzip-1.7-1-i686 92.4 KiB 863K/s 00:00 [#####################] 100% msys2-launcher-git-... 25.0 KiB 2.03M/s 00:00 [#####################] 100% msys2-runtime-devel... 3.4 MiB 843K/s 00:04 [#####################] 100% (5/5) checking keys in keyring [#####################] 100% (5/5) checking package integrity [#####################] 100% (5/5) loading package files [#####################] 100% (5/5) checking for file conflicts [#####################] 100% (5/5) checking available disk space [#####################] 100% warning: could not get file information for mingw32.exe warning: could not get file information for mingw32.ini warning: could not get file information for mingw64.exe warning: could not get file information for mingw64.ini warning: could not get file information for msys2.exe warning: could not get file information for msys2.ini :: Processing package changes... (1/5) upgrading filesystem [#####################] 100% error: cannot remove /usr/bin/msys-2.0.dll (Permission denied) (2/5) upgrading msys2-runtime [#####################] 100% warning: warning given when extracting /usr/bin/msys-2.0.dll (Could not unlink) (3/5) upgrading gzip [#####################] 100% (4/5) upgrading msys2-launcher-git [#####################] 100% (5/5) upgrading msys2-runtime-devel [#####################] 100%

... we could not asses the importance of the "warnings" following the line "(5/5)".

... The Warning and Error following the line :: Processing package changes...

(i) It is not clear why MSys2 has "Permission denied" for removing msys-2.0.dll. Since there are detach issues with mintty, it is possible that some other process has locked/use of the dir, since it "failed to detach" earlier.

c) So, performed a complete uninstall/reinstall, just in case.

All of the same issues arose, had to use cmd.exe etc to get to a working Shell etc. Then, after all the initial steps, and getting to running pacman -Syuu on this occasion produced:

Administrator@art-64 MSYS ~ $ pacman -Syuu :: Synchronizing package databases... mingw32 is up to date mingw64 is up to date msys is up to date :: Starting full system upgrade... resolving dependencies... looking for conflicting packages...

Packages (25) coreutils-8.25-1 crypt-1.3-1 curl-7.47.1-2 file-5.25-1 filesystem-2016.04-1 gcc-libs-5.3.0-3 gettext-0.19.7-3 gmp-6.1.0-2 gnupg-1.4.20-1 grep-2.22-3 gzip-1.7-1 heimdal-libs-1.5.3-9 libasprintf-0.19.7-3 libcrypt-1.3-1 libcurl-7.47.1-2 libexpat-2.1.1-1 libgettextpo-0.19.7-3 libintl-0.19.7-3 libopenssl-1.0.2.g-1 mintty-1~2.2.3-1 mpfr-3.1.4-1 msys2-launcher-git-0.3.28.860c495-1 ncurses-6.0.20160220-1 openssl-1.0.2.g-1 rebase-4.4.2-1

Total Download Size: 12.01 MiB Total Installed Size: 68.02 MiB Net Upgrade Size: 2.10 MiB

:: Proceed with installation? [Y/n] y :: Retrieving packages ... gmp-6.1.0-2-i686 353.9 KiB 975K/s 00:00 [#####################] 100% gcc-libs-5.3.0-3-i686 840.2 KiB 977K/s 00:01 [#####################] 100% libintl-0.19.7-3-i686 25.9 KiB 2.30M/s 00:00 [#####################] 100% coreutils-8.25-1-i686 2.2 MiB 944K/s 00:02 [#####################] 100% libcrypt-1.3-1-i686 12.3 KiB 1756K/s 00:00 [#####################] 100% crypt-1.3-1-i686 12.5 KiB 2.43M/s 00:00 [#####################] 100% libopenssl-1.0.2.g-... 809.0 KiB 925K/s 00:01 [#####################] 100% ncurses-6.0.2016022... 1140.6 KiB 946K/s 00:01 [#####################] 100% heimdal-libs-1.5.3-... 621.5 KiB 901K/s 00:01 [#####################] 100% openssl-1.0.2.g-1-i686 1325.9 KiB 911K/s 00:01 [#####################] 100% gzip-1.7-1-i686 92.4 KiB 962K/s 00:00 [#####################] 100% libexpat-2.1.1-1-i686 57.2 KiB 2.15M/s 00:00 [#####################] 100% libcurl-7.47.1-2-i686 193.7 KiB 940K/s 00:00 [#####################] 100% curl-7.47.1-2-i686 594.6 KiB 921K/s 00:01 [#####################] 100% file-5.25-1-i686 399.3 KiB 976K/s 00:00 [#####################] 100% filesystem-2016.04-... 31.1 KiB 2.02M/s 00:00 [#####################] 100% libgettextpo-0.19.7... 114.1 KiB 943K/s 00:00 [#####################] 100% libasprintf-0.19.7-... 11.5 KiB 2.82M/s 00:00 [#####################] 100% gettext-0.19.7-3-i686 1529.0 KiB 931K/s 00:02 [#####################] 100% gnupg-1.4.20-1-i686 1013.8 KiB 947K/s 00:01 [#####################] 100% grep-2.22-3-i686 228.9 KiB 809K/s 00:00 [#####################] 100% mintty-1~2.2.3-1-i686 144.6 KiB 861K/s 00:00 [#####################] 100% mpfr-3.1.4-1-i686 239.7 KiB 936K/s 00:00 [#####################] 100% msys2-launcher-git-... 25.0 KiB 2.03M/s 00:00 [#####################] 100% rebase-4.4.2-1-i686 242.2 KiB 859K/s 00:00 [#####################] 100% upgrading rebase [#####################] 100%

... we have no idea why the second clean install's first use of -Syuu produces a different log/process compared to the earlier install, and why there are so many more items.

... the warnings and errors are interesting. Amongst other things, note that pacman could not update mintty (c.f. the earlier install where the Errors did not include mintty). We are guessing that since we did not reboot the machine between re-install of MSys2, services.exe kept a connection to mintty, and so the second reinstall was already starting "wrong footed" wrt mintty.

... no idea what all the "insecure memory" business is.

Nevertheless, it is possible to use MSys2/32 on WinXP64, save for the issues mentioned. It is possible that we will find additional issues with additional test.

In the mean time, we have successfully used (the adjusted) MSys2/32 to install the usual compiler toolchain, GTK3, Glade, etc.

We have at this point, only limited test for running/using the MSys2/32 installed toolchain etc, since there is another MingW-64 installation (not MSys2) on the same machine, and various env vars will need to be reset to point to the MSys2 dir's, which we cannot do for a little while yet for reasons beyond this discussion. Still, and though it's early days, at least it appears that the c and Fortran compilers are working.

Moving forward: Any suggestion for tests/fixes for

(i) the "cannot detach mintty" errors

(ii) that on the very first launch of the shell, it "freezes" after update-core, requiring TaskMan intervention

would be appreciated.

Cheers

DrO

mati865 commented 8 years ago

About update-core it's pretty normal that shell will freeze after using it. There should be warning saying you have to force close shell (just click on X in the corner and confirm warning about running processes). Also update-core is removed after updating pacman since pacman -Syuu has taken it's job.

DrOli commented 8 years ago

(A) Many thanks for that, its good know that

1) ... and YES, it would be very helpful if ONE of the lines at the end of the update-core process EXPLICITLY stated that you may not be able Close the shell by normal means, and that TaskMan may be required, and also TaskMan for bash.exe, etc.

2) Though, it does not seem to address the mintty detach issue with WinXP64/MSys2-32

(B) Now, for some good news, in addition to MSys2-32 working from above, we now have MSys2-64 working on WinXP64, sort of.

1) The solution, such as it is, requires editing etc/pacman pacman.conf. The edit is:

SigLevel = Never # DrO, use this for GPGME Error/curropt database etc

SigLevel = Required DatabaseOptional # DrO, turned off to obviate GPGME etc errors

... CRUCIALLY, we had performed a similar test previously based on link relating to GPGME errors, but there the instructions were simply to comment out/turn-off the SigLevel.

In fact, that is not enough, one MUST explicitly set SigLever = Never.

Following that, no more GPGME errors, and update-core/pacman -Syuu etc work as expected, though complaining about the "security".

If after update/-Syuu, the SigLevel is returned to "normal/original", then the GPGME/corrupt database errors return.

For the time being, we are leaving SigLevel = Never.

So, now the questions are:

a) How safe/advisable is it to run MSys2 with SigLevel = Never????

b) How to fix this, so that it works with the normal SigLevel?

2) The Shells are launched via short-cuts using the "cmd" approach, as discussed in the parallel test to get MSys2-32 to work on WinXP64. However, the default WinXP64 environment has the same cmd.exe in both System32 and SysWow, and they are both 32-bit.

We found that with MSys2-64, we had better results using a 64-bit version of cmd.exe. In our case, it is part of the AMD service pack. Presumably, other chip vendors may supply such as well.

Cheers

DrO

mati865 commented 8 years ago

To my last comment: After you updating msys using update-core there is warning and you should be able to see it (tested on win 7 64 and 10 64).

DrOli commented 8 years ago

There is no explicit message inside the Shell stating that extra ordinary effort will be required. Though there are quire a few messages about "use Close"/"red [x]" etc. So adding one more line should not be too difficult.

Yes, on Win7 there is dialogue that pops ups, with a "close anyway". On WinXP64, there is dialogue that indicates "some things are still running", but that's about it. Thereafter, the user is on their own to discover that they must enter TaskMan and start whittling the appropriate frozen bits. Not sure if this happens on XP32, as have not tested there.

In any case, I wonder if anyone has any thoughts on the deeper issues from above. For example, on WinXP64, amongst other things, we must run with

SigLevel = Never

... otherwise the shell just spews GPGME/currupt database errors, and nothing can be installed.

So,

1) how advisable/safe is it run with "Never" ?

2) how to fix the system so that the normal SigLevel settings don't cause those errors?

Many thanks

lberteau commented 8 years ago

Thank you for the SigLevel = Never tip !

lazka commented 4 years ago

WinXP support is long gone, so closing.

msys2 / MSYS2-packages

No way, no how on WinXP64 #532

SigLevel = Required DatabaseOptional # DrO, turned off to obviate GPGME etc errors