build-extra installer doesn't work anymore

Question

build-extra installer doesn't work anymore

brice-gros opened this issue 4 years ago · 11 comments

build-extra installer git-sdk-1.0.7 doesn't work anymore due to the removal of the master branch from this repo.
The fix is already present in build_extra, only a corresponding release is missing

Answer 1 · 2020-10-23T22:14:49.000Z

Acknowledged. In the meantime, please use the work-around to clone https://github.com/git-for-windows/git-sdk-64 (or for 32-bit, https://github.com/git-for-windows/git-sdk-32) manually.

Answer 2 · 2020-10-24T01:05:54.000Z

There you go: https://github.com/git-for-windows/build-extra/releases/tag/git-sdk-1.0.8

Answer 3 · 2020-10-31T16:55:58.000Z

Hi @dscho

What's the 'right' way of installing this on top of an already installed previous version (If needed at all)?

I'm also having a separate issue with the package updates for mingw32, mingw64, and msys because of the retiral of some PGP keys due to the change of maintainer which I haven't managed to get past yet But not sure where it's best to discuss that.

Answer 4 · 2020-10-31T22:11:37.000Z

What's the 'right' way of installing this on top of an already installed previous version (If needed at all)?

I typically git -C /c/git-sdk-64 pull (using Git Bash, not Git SDK Bash), but that requires no Git SDK processes to be running. And it only includes the packages tracked in git-sdk-64.

You might be better off using pacman -Syu.

I'm also having a separate issue with the package updates for mingw32, mingw64, and msys because of the retiral of some PGP keys due to the change of maintainer which I haven't managed to get past yet But not sure where it's best to discuss that.

You will have to use pacman-key --recv-key <key> && pacman-key --lsign-key <key> to fix that.

Answer 5 · 2020-11-01T14:57:35.000Z

Thanks @dscho, Just clarifying a few points out of an abundance of caution... probably with more detail than needed but...

On 31/10/2020 22:11, Johannes Schindelin wrote: What's the 'right' way of installing this on top of an already installed previous version (If needed at all)? I typically git -C /c/git-sdk-64 pull (using Git Bash, not Git SDK Bash), but that requires no Git SDK processes to be running. And it only includes the packages tracked in git-sdk-64.

The fetch part downloaded ok, but the merge/checkout failed. It looks like I've been on a detached head for a long long time, and also that I left myself on a stashed head back at the end of May (on e27af39 2020-05-18 04:08:44) while attempting an earlier update of the sdk (the start of PGP sign fail). It feels like the right approach to resolve the final pull step may be `git reset --hard origin/main`, but I'm concerned about consequences. Would I be right that the sdk repo has no submodules and the 'pull' update is meant to be equivalent to the `pacman -Syu`? (I believe it is). i.e. git reset --hard origin/main # anything to be cleaned? The first commit I have locally in the SDK repo is from 2019-03-02 03:11:44 (c0c5cc6), which I think is when I got the current PC. The shall file lists: 8c1d0b1 c0c5cc6 My local sdk repo's objects file is now 5.8GB, 7 packs. My main concern would be affecting the usr/src/<sub-projects> directories. Plus I've got a clang32 and clang64 directory immediately at the 'root' level (e.g. C:\git-sdk-64\clang64), but I could delete and restart that, as long it it didn't have ripples...

You might be better off using pacman -Syu.

I had been using that for a long while, then hit the problem below, which I thought I'd tried all the suggestions from the up streams without luck. There are 3 keys currently "missing" (retired...)

I'm also having a separate issue with the package updates for mingw32, mingw64, and msys because of the retiral of some PGP keys due to the change of maintainer which I haven't managed to get past yet But not sure where it's best to discuss that. You will have to use pacman-key --recv-key <key> && pacman-key --lsign-key <key> to fix that.

Currently, for me, if get (if run in CMD window) 'pacman-key' is not recognized as an internal or external command, operable program or batch file. or Bash [Ahh that was the Mingw64 bash] $ pacman-key --recv-key 4A6129F4E4B84AE46ED7F635628F528CF3053E04 bash: pacman-key: command not found A quick web search suggests that I may need to update pacman itself first... But phili@Philip-Win10 MINGW64 /c/git-sdk-64 ((e27af39...)) $ pacman -Syy bash: pacman: command not found Hmm. getting myself lost here. So start a fresh `SDK-64:/` window Welcome to the Git for Windows SDK! The common tasks are automated via the `sdk` function; See `sdk help` for details. phili@Philip-Win10 MINGW64 / ((e27af39...)) $ pacman error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] n error: mingw64: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] That's naff! a bit catch 22. try: phili@Philip-Win10 MINGW64 / ((e27af39...)) $ pacman-key --recv-key 4A6129F4E4B84AE46ED7F635628F528CF3053E04 gpg: keyserver receive failed: General error ==> ERROR: Remote key not fetched correctly from keyserver. hmph. Still a bit stuck/unsure. Thought it worth at least posting 'what I've tried so far' just in case anyone can clarify what to do.

…

-- Philip

Answer 6 · 2020-11-01T15:24:35.000Z

On 01/11/2020 14:57, Philip Oakley wrote: Thanks @dscho, Just clarifying a few points out of an abundance of caution... probably with more detail than needed but... On 31/10/2020 22:11, Johannes Schindelin wrote: > > What's the 'right' way of installing this on top of an already > installed previous version (If needed at all)? > > I typically git -C /c/git-sdk-64 pull (using Git Bash, not Git SDK > Bash), but that requires no Git SDK processes to be running. And it > only includes the packages tracked in git-sdk-64. > The fetch part downloaded ok, but the merge/checkout failed. It looks like I've been on a detached head for a long long time, and also that I left myself on a stashed head back at the end of May (on e27af39 2020-05-18 04:08:44) while attempting an earlier update of the sdk (the start of PGP sign fail). It feels like the right approach to resolve the final pull step may be `git reset --hard origin/main`, but I'm concerned about consequences. Would I be right that the sdk repo has no submodules and the 'pull' update is meant to be equivalent to the `pacman -Syu`? (I believe it is). i.e. git reset --hard origin/main # anything to be cleaned? The first commit I have locally in the SDK repo is from 2019-03-02 03:11:44 (c0c5cc6), which I think is when I got the current PC. The shall file lists: 8c1d0b1 c0c5cc6 My local sdk repo's objects file is now 5.8GB, 7 packs. My main concern would be affecting the usr/src/<sub-projects> directories. Plus I've got a clang32 and clang64 directory immediately at the 'root' level (e.g. C:\git-sdk-64\clang64), but I could delete and restart that, as long it it didn't have ripples... > You might be better off using pacman -Syu. > I had been using that for a long while, then hit the problem below, which I thought I'd tried all the suggestions from the up streams without luck. There are 3 keys currently "missing" (retired...) > I'm also having a separate issue with the package updates for > mingw32, mingw64, and msys because of the retiral of some PGP keys > due to the change of maintainer which I haven't managed to get > past yet But not sure where it's best to discuss that. > > You will have to use pacman-key --recv-key <key> && pacman-key > --lsign-key <key> to fix that. > Currently, for me, if get (if run in CMD window) 'pacman-key' is not recognized as an internal or external command, operable program or batch file. or Bash [Ahh that was the Mingw64 bash] $ pacman-key --recv-key 4A6129F4E4B84AE46ED7F635628F528CF3053E04 bash: pacman-key: command not found A quick web search suggests that I may need to update pacman itself first... But ***@***.*** MINGW64 /c/git-sdk-64 ((e27af39...)) $ pacman -Syy bash: pacman: command not found Hmm. getting myself lost here. So start a fresh `SDK-64:/` window Welcome to the Git for Windows SDK! The common tasks are automated via the `sdk` function; See `sdk help` for details. ***@***.*** MINGW64 / ((e27af39...)) $ pacman error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] n error: mingw64: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] That's naff! a bit catch 22. try: ***@***.*** MINGW64 / ((e27af39...)) $ pacman-key --recv-key 4A6129F4E4B84AE46ED7F635628F528CF3053E04 gpg: keyserver receive failed: General error ==> ERROR: Remote key not fetched correctly from keyserver. hmph. Still a bit stuck/unsure. Thought it worth at least posting 'what I've tried so far' just in case anyone can clarify what to do. --

Having hit the worry merry-go-round (email above), the 'clean' man page helped with pointing to the regular .gitignore file checks, which then showed that the various concerned sub-directories were being ignored for changes and cleaning. I just realised I will need to exclude my clang32/64 sub-directories as they aren't in the .gitignore, so the exclude `-e 'clang*'` is I think needed for the `git clean` (I hope I get the quoting right, or maybe just have two `-e pattern`s). Then try the pacman update. Philip

Answer 7 · 2020-11-02T13:10:05.000Z

Well, it really is more of an "either/or". Either you go with git pull, or you do pacman. It does not really make sense to do both, except maybe for myself, to make sure that I catch bugs in the git-sdk-64 early.

Answer 8 · 2020-11-02T18:09:50.000Z

Either you go with git pull, or you do pacman

However, currently both are failing for me, so it's a bit catch 22 with rather too many XY problem issues to get past.

I.e.

If I try checking out origin/main I get various .exe/.dll "Unlink of file" fails.

$ git reset --hard origin/main
Unlink of file 'usr/bin/dirmngr.exe' failed. Should I try again? (y/n) n
error: unable to unlink old 'usr/bin/dirmngr.exe': Invalid argument
Unlink of file 'usr/bin/msys-2.0.dll' failed. Should I try again? (y/n) n
error: unable to unlink old 'usr/bin/msys-2.0.dll': Invalid argument
Unlink of file 'usr/bin/msys-gcrypt-20.dll' failed. Should I try again? (y/n) n
error: unable to unlink old 'usr/bin/msys-gcrypt-20.dll': Invalid argument

(I think the "Invalid argument" is just our -1 return code).

If I try the pacman updates I get the key failures.
If I try the sdk I get the same key failures

$ sdk cd  msys2-runtime
...
==> Making package: msys2-runtime 3.1.7-4 (Sat, Oct 31, 2020  1:30:59 PM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
:: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n]
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: mingw64: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
:: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n]
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: msys: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
...

So at the moment, I'm flailing around a bit trying to get to a firm state.

I was even wondering about having a Windows config variable to allow the above errors to be temporarily converted to warnings to make progress in a slightly different direction (a checkout that appears to have those listed files as being reverted..)

Answer 9 · 2020-11-03T23:31:36.000Z

$ git reset --hard origin/main
Unlink of file 'usr/bin/dirmngr.exe' failed. Should I try again? (y/n) n

That's because dirmngr is still running, I am certain. Once you stop it (e.g. via gpgconf --kill dirmngr) that'll no longer be an issue.

* If I try the pacman updates I get the key failures.

You might be able to fix them via gpg --recv-key <key> && gpg --lsign-key <key>, too.

In any case, if you haven't used your copy of the SDK for a while, it might be a good idea to just throw it away and start anew. It's not like you were in the middle of some work that mustn't be lost, right?

Answer 10 · 2020-11-03T23:47:08.000Z

I had decided that I was in the sand trap, so I've renamed the old SDK install, and started a new one which installed Ok and make install and sdk build git-and-installer all completed successfully.

The PGP key thing does get a lot of hits for folks having had problems with time limiting issues, but the new sdk has side stepped that,

I've still to fetch any work I had from my old sdk, and ensure my Github forks all match up, (there's plenty / too much of half complete stuff to just lose..;-)

Answer 11 · 2020-11-05T17:56:15.000Z

In case it helps anyone: While comparing my old and new installs, I did notice the SDK-64 .gitignore change for the pacman GNU Privacy Guard folder, which had been one of the areas mentioned in the MSYS2 News for fixing the missing signature.

The pacman updates appear to run fine now.