I am trying to rebuild the 64-bit version of git-1.9.0-2.src.tar.gz downloaded from https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources/ . I've installed MSYS2 and mingw64 and opened the mingw64 mintty with mingw64_shell.bat, and unpacked the tarball into its own directory. Trying to build the package results in the following output (a lot of config output redacted):
$ makepkg -C
==> Making package: git 1.9.0-2 (17 Mar 2014 23:25:17)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found git-1.9.0.tar.gz
-> Found git-manpages-1.9.0.tar.gz
-> Found 1.7.9-cygwin.patch
-> Found git-1.9.0-manifest-msys2.patch
-> Found git-1.8.4-msys2.patch
==> Validating source files with md5sums...
...
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
==> ERROR: A failure occurred in build().
Aborting...
Are there other variables necessary for makepkg or in the environment?
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the correction, it has now indeed built using msys2_shell.bat. I had deluded myself into thinking that I was about to build a native version that would link directly to MS dll's without the MSYS dll's interfering, and had therefore started the mingw64 shell.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.. the official Windows Git, despite being called msysGit is actually (a really old and bad version of) MSYS with a native build of Git, so that we build ours as an MSYS2 program is probably more surprising to most. The benefits of it being MSYS2 are that symlinks work to a better degree and Perl works with less problems too (msysGit's Perl is very old). We could provide a native version of Git easily enough but the MSYS2 one works very well so there's not much point in adding to the confusion. Some have reported it as being slower, but I've always found it plenty fast.
I should also mention that even if you are building native packages ( i.e. from https://github.com/Alexpux/MINGW-packages ) you should still use msys2_shell.bat, and run makepkg-mingw instead of makepkg, and that will add /mingw32/bin and /mingw64/bin to the front of PATH when it builds the 32bit and 64bit packages respectively.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the considered reply. To me, git is way too important a product, a concept even, to not put as much effort as possible into making it run as well/natively as possible on the Windows platform. (I am thinking of those that want to use git, and have no interest in knowing the internals of how it has been adapted to the Windows platform.) As you point out, msysgit (mis-named) did this for 32-bit, and I am very interested in the grown-up 64-bit equivalent of that product, and would be interested if you have any tips in this direction.
I mirror a lot of repositories, and I have noticed in my daily work that this version (the MSYS2 x86_64 one in discussion here) clearly falls over in pulling some repository updates, where msysgit just breezes through. At the moment, I'm running this version first, then getting msysgit to clean up the errors. I have already shut the console window for this evening, so I don't have a sample repository+object to note here, but I can post an example if there is interest. At this point, I was just trying to get set up to see if I could debug it myself.
Thank you also for the tips regarding Alexey's packages. I was indeed going to try to build some of them, and certainly wouldn't have known to run makepkg-mingw under msys2 instead of makepkg under mingw64. Is this written up somewhere?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MSYS2 Git has been misbehaving for me and another project member for a few days. If you do have time to look into this we'd really appreciate it. Alexey isn't have any problems for some reason.
I updated the README.md of both MSYS2-packages and MINGW-packages with the makepkg details, and, like you, had to resort to msysGit again (for the first time in about 8 months).
I am not really sure that users of MSYS2/Pacman need a deep understanding of the nature of each package. I'd like it to reach a point where it's simple to use - with a graphical package manager, Octopi being the frontrunner - so that people without any technical interest whatsoever can use it and benefit from not having to:
Hunt around for software.
Click through inconsistent and occasionally malware ridden installers.
Chose where to install things.
or deal with the Windows Registry
.. ever again :-)
Anyway, back to Git.. When it works correctly, MSYS2 Git integrated just fine with everything I introduced it to (SourceTree, TortoiseGit etc) and allowed a greater variety of symlink options than msysGit did (admittedly I don't keep up with what's new in msysGit).
If you were to make a PKGBUILD for native Git then I expect we'd be happy to merge that. Whether we'd make a prebuilt package for it is another matter. I'm not sure there's much benefit, but benchmarks results and parity of features could convince me otherwise (it's Alexey's call at the end of the day).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just so we're on the same page, are you getting the same error as I am when running git? Just this evening, on doing a 'git fetch --prune' 24 hours after the previous execution, I got this error:
remote: Counting objects: 930, done.
remote: Compressing objects: 100% (112/112), done.
Receiving objects: 27%remote: Total 499 (delta 386), reused 499 (delta 386)
Receiving objects: 100% (499/499), 145.56 KiB | 5.00 KiB/s, done.
fatal: bad object cee0c2750bb5f1b38f15ef961517e03c2e39c9ec
error: git://git.kernel.org/pub/scm/git/git.git did not send all necessary objects
Last edit: Peter Klavins 2014-03-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Disclaimer: What I'm about to share may be completely unrelated to your question. However, the output I saw today was strikingly similar to your above output.
Using "git version 1.8.4.msysgit.0" on Win7x64 SP1, I observed the same output ("bad object", "did not send all necessary objects") due to a MAX_PATH issue with my PWD.
If you're still running into the same issue performing a git fetch, you may wish to try changing to a working directory with fewer characters.
I am trying to rebuild the 64-bit version of git-1.9.0-2.src.tar.gz downloaded from https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources/ . I've installed MSYS2 and mingw64 and opened the mingw64 mintty with mingw64_shell.bat, and unpacked the tarball into its own directory. Trying to build the package results in the following output (a lot of config output redacted):
$ makepkg -C
==> Making package: git 1.9.0-2 (17 Mar 2014 23:25:17)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found git-1.9.0.tar.gz
-> Found git-manpages-1.9.0.tar.gz
-> Found 1.7.9-cygwin.patch
-> Found git-1.9.0-manifest-msys2.patch
-> Found git-1.8.4-msys2.patch
==> Validating source files with md5sums...
...
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
==> ERROR: A failure occurred in build().
Aborting...
Are there other variables necessary for makepkg or in the environment?
Peter
Our git is a msys2 program so use msys2_shell.bat to launch the bash prompt. This will cause msys2 compilers and other build tools to be used.
Thanks for the correction, it has now indeed built using msys2_shell.bat. I had deluded myself into thinking that I was about to build a native version that would link directly to MS dll's without the MSYS dll's interfering, and had therefore started the mingw64 shell.
Well, it's not that delusional ..
.. the official Windows Git, despite being called msysGit is actually (a really old and bad version of) MSYS with a native build of Git, so that we build ours as an MSYS2 program is probably more surprising to most. The benefits of it being MSYS2 are that symlinks work to a better degree and Perl works with less problems too (msysGit's Perl is very old). We could provide a native version of Git easily enough but the MSYS2 one works very well so there's not much point in adding to the confusion. Some have reported it as being slower, but I've always found it plenty fast.
I should also mention that even if you are building native packages ( i.e. from https://github.com/Alexpux/MINGW-packages ) you should still use msys2_shell.bat, and run makepkg-mingw instead of makepkg, and that will add /mingw32/bin and /mingw64/bin to the front of PATH when it builds the 32bit and 64bit packages respectively.
Thanks for the considered reply. To me, git is way too important a product, a concept even, to not put as much effort as possible into making it run as well/natively as possible on the Windows platform. (I am thinking of those that want to use git, and have no interest in knowing the internals of how it has been adapted to the Windows platform.) As you point out, msysgit (mis-named) did this for 32-bit, and I am very interested in the grown-up 64-bit equivalent of that product, and would be interested if you have any tips in this direction.
I mirror a lot of repositories, and I have noticed in my daily work that this version (the MSYS2 x86_64 one in discussion here) clearly falls over in pulling some repository updates, where msysgit just breezes through. At the moment, I'm running this version first, then getting msysgit to clean up the errors. I have already shut the console window for this evening, so I don't have a sample repository+object to note here, but I can post an example if there is interest. At this point, I was just trying to get set up to see if I could debug it myself.
Thank you also for the tips regarding Alexey's packages. I was indeed going to try to build some of them, and certainly wouldn't have known to run makepkg-mingw under msys2 instead of makepkg under mingw64. Is this written up somewhere?
MSYS2 Git has been misbehaving for me and another project member for a few days. If you do have time to look into this we'd really appreciate it. Alexey isn't have any problems for some reason.
I updated the README.md of both MSYS2-packages and MINGW-packages with the makepkg details, and, like you, had to resort to msysGit again (for the first time in about 8 months).
I am not really sure that users of MSYS2/Pacman need a deep understanding of the nature of each package. I'd like it to reach a point where it's simple to use - with a graphical package manager, Octopi being the frontrunner - so that people without any technical interest whatsoever can use it and benefit from not having to:
Hunt around for software.
Click through inconsistent and occasionally malware ridden installers.
Chose where to install things.
or deal with the Windows Registry
.. ever again :-)
Anyway, back to Git.. When it works correctly, MSYS2 Git integrated just fine with everything I introduced it to (SourceTree, TortoiseGit etc) and allowed a greater variety of symlink options than msysGit did (admittedly I don't keep up with what's new in msysGit).
If you were to make a PKGBUILD for native Git then I expect we'd be happy to merge that. Whether we'd make a prebuilt package for it is another matter. I'm not sure there's much benefit, but benchmarks results and parity of features could convince me otherwise (it's Alexey's call at the end of the day).
Just so we're on the same page, are you getting the same error as I am when running git? Just this evening, on doing a 'git fetch --prune' 24 hours after the previous execution, I got this error:
remote: Counting objects: 930, done.
remote: Compressing objects: 100% (112/112), done.
Receiving objects: 27%remote: Total 499 (delta 386), reused 499 (delta 386)
Receiving objects: 100% (499/499), 145.56 KiB | 5.00 KiB/s, done.
fatal: bad object cee0c2750bb5f1b38f15ef961517e03c2e39c9ec
error: git://git.kernel.org/pub/scm/git/git.git did not send all necessary objects
Last edit: Peter Klavins 2014-03-19
Peter,
Disclaimer: What I'm about to share may be completely unrelated to your question. However, the output I saw today was strikingly similar to your above output.
Using "git version 1.8.4.msysgit.0" on Win7x64 SP1, I observed the same output ("bad object", "did not send all necessary objects") due to a MAX_PATH issue with my PWD.
If you're still running into the same issue performing a
git fetch, you may wish to try changing to a working directory with fewer characters.More info here: https://stackoverflow.com/q/7866387/3376504
Hi Peter,
A bit of thread re-animating here. I don't have any problems with MSYS2 git anymore (the git.git clones just fine).
Did you look into a native x86_64 Git yet?
Hi Ray,
I'm nearly finished the native build
Benn working on it for the last few days
On Mon, Jul 21, 2014 at 12:45 PM, Ray Donnelly mingwandroid@users.sf.net
wrote: