I need to build the mozilla source in my Windows 7 machine. I used the following command line code to pull the source using mercurial
hg clone http://hg.mozilla.org/mozilla-central/ D:\FFsrc\src20
but the process always stop in the middle, with the following error.
requesting all changes adding
changesets transaction abort! rollback
completed abort: premature EOF reading
chunk <got 6 bytes, expected 776>
Try successive clone -r, it looks like your connection is flaky which stops the clone process in the middle.
HI Tonfa, Krtek
the issue was actually on the network, which stopped the clone process. I have now downloaded the bundle and grabbed the source by unbundling it.
https://developer.mozilla.org/en/Mozilla_Source_Code_%2528Mercurial%2529%23
Thanks!!!
I had that error and found it was caused by using the old 1.2 hg client.
Upgraded to 2.4.2 and it worked fine since then.
So try to update to the latest hg version.
Related
I'm following chapter 13.3 of "Haskell Programming from First Principles"
and working on stack build but fail with below error message as below. I'm doing on my MBP terminal with current Stack version: 1.3.2 installed, . Any solution for a way out? (I'm currently working with very slow wifi environment. I'm not sure whether stack build fails because of bad connectivity.)
$ stack build
Updating package index Hackage (mirrored at
https://github.com/commercialhaskell/all-cabal-hashes.git) ...
Long Pause Here... almost 10 minutes.
Running /usr/bin/git clone https://github.com/commercialhaskell/all-cabal-hashes.git all-cabal-hashes/ -b display in directory /Users/Sleepyleo/.stack/indices/Hackage/git-update/ exited with ExitFailure 128
Cloning into 'all-cabal-hashes'...
error: RPC failed; curl 56 SSLRead() return error -9806
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Error code -9806 is a Mac OS X error code for a generic SSL connection failure. Others have reported this as a problem with older versions of git connecting to certain sites with incompatible SSL configurations. See this StackOverflow question, for example. However, it's also been reported as a result of a connection being interrupted on a flaky Internet connection (e.g., this github issue).
Unfortunately, since you are seeing this after a 10 minute timeout, it's likely your Internet connection rather than an SSL compatibility problem.
You might want to try running:
/usr/bin/git clone https://github.com/commercialhaskell/all-cabal-hashes.git
all-cabal-hashes/ -b display
manually in a directory somewhere. It's about a 200 megabyte download. This will show you if it's making any progress and how fast the download is running.
After about 6+ days and numerous rounds of spin-up/destroy I have FINALLY gotten my Digital Ocean droplet server up and running (ie I can view a live page of content at my ip).
At this point I am trying to install Git, and have installed/removed it 3 times so far as I keep getting 'close' to completion but then run into some error I can't find an answer for. I'm hoping someone can help me figure out what my latest problem is so I can move forward with the actual development of my site rathe than spending over a week on the server build.
I have attempted to install version 2.6.2 of git on my server and have had to compile from source (something I am no where near familiar with). I 'thought' I had it correct this time, but received the following error when I attempted to set my git user name:
gitconfig --global user.name "MyUserName" (<--- last command I made)
bash: gitconfig: command not found (<-- error i received)
I thought it was an issue with being in the wrong directory to run the command, so i ran which git and received the following output:
/usr/local/git/bin/git
This seems to be a binary (?) file and none of the directories listed in that path allow me to use gitconfig command either.
Any ideas what I have done wrong? Do I need to remove (again!) and re-compile. I don't desire to be a server admin, but really had thought (hoped?) spinning my own LEMP server on CentOS 7 would be simple - doing so on CentOS 6.* was.
Thanks for your help/advice.
gitconfig isn't a command.
You'd do:
git config --global user.name "MyUserName"
Also you're really better off installing git via yum, rather than compiling from source unless there's a good reason to compile it yourself.
(Edit - updated answer with tested solution on Centos 7).
I am trying to Install Cygwin 64 bit on a Windows 2012R2 (64 bit).
Downloading and initial setup went through but when it reached man-db (/etc/postinstall/man-db) the setup hangs
and remains so forever. I waited more than 1.5 Hours but still no progress.
I checked log file in /var/log/setup.log which has following contents.
Updating index cache for path `/usr/share/man/man1'. Wait...
Processing manual pages under /usr/share/man...
/usr/bin/mandb: warning: /usr/share/man/man1/col.1.gz: whatis parse for col(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/imv.1 is a dangling symlink
/usr/bin/mandb: iconv_open ("UTF-8//IGNORE", "utf8"): Invalid argument
/usr/bin/mandb: warning: /usr/share/man/man1/mc.1.gz: whatis parse for mc(1) failed
I am not sure if I should cancel and start again. Will this setup come out of this stage with at least some error?
Did anyone install 64 bit Cygwin and got this error ?
Please help
Happens to me often. I was setting up 8 servers this week and it happened to 3 of them. Waited many hours and it is still would not finish. Sometimes the re-installation works, some it does not. So I have resorted to kill the mandb.exe process and that allows the installer to finish normally. So far I have found no side effects of doing so.
After waiting for more than 3 hours, I decided to cancel the setup. Then I tried a reinstall, following the steps exactly as in the first install. I did not add or remove any packages. The already selected packages in the first attempt were recognized as installed. This time, the setup stopped at the above step (man-db) briefly and then completed the installation. No errors. So, re-installation solved my problem.
Late to the party, but —
When mandb.exe hung, I killed its parent bash.exe via Task Manager and the installation completed.
I then killed mandb.exe in Task Manager, since it was still running.
I then opened a Cygwin shell and ran mandb -cds. -c recreates the index, -d prints messages (so you can actually tell it's doing something constructive!) and -s suppresses checking for orphaned formatted manual pages ("stray cats").
As I write this, mandb is still chugging along, three or four hours later, with plenty yet to go.
So I'll remember to file a bug report later :) , I did notice one oddity during the mandb run:
mandb: /usr/share/man/man3/jN.3 is self referencing
mandb: warning: /usr/share/man/man3/jnf.3.gz: bad symlink or ROFF `.so' request
I've been struggling with the same problem today until I realised that moving the main Cygwin setup window revealed a popup complaining about "can't open (null) for reading: no such file"
This happens multiple times in a (re)install
when trying to install cygwin, I keep getting this error message:
the entry point
rl_filename_rewrite_hook could not be
located in the dynamic link library
cygreadline7.dll
Has anyone seen this before ?
Thanks
I had the same error with cygwin1.dll. I checked in c:\cygwin\bin and noticed there were two files, cygwin1.dll and cygwin1.dll.new (possibly from a failed or aborted setup run?). The ".new" version was in fact newer (and slightly larger) than the existing cygwin1.dll, so I replaced cygwin1.dll with cygwin1.dll.new, and ran setup again. It completed with no errors.
First idea is to try reinstalling libreadline7 (or similarly named package) using the cygwin installer. Use the search field to enter readline to make it easier to find the right package.
Another option is that in the cygwin installer, change form Curr to Prev in order to switch to the previous-stable release. This means lots and lots of downloading and reinstalling. I anctually did manage to provoke my error into becoming a libreadline7 error, and switching to Prev at least got rid of the error messages. (Yay! Now bash, ssh server and git is working again! Back to work here then...)
Please check your path in WINDOWS (advanced system properties) environment. I found that C:\WinAVR\bin was coming before my cygwin path, so I moved that to the end, fixed my issue.
If you have multiple CYGWIN1.DLL files in your system, it definitely causes headaches if you're not careful.
I recently updated to CC.NET 1.5 and I'm now getting some strange exceptions.
On one project I get: -
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: Can't create a character converter from native encoding to 'UTF-8'
This happens when CC is checking a subversion repository for any mods. If I run the actual command line CC says is failing it works and returns an empty XML (there are no mods).
Some other projects also fail to check mods with another "Source control operation failed" exception but no further info. Again the command is an "svn log" which when run from command line works ok.
I'm using subversion 1.4.5 client side and my source repository exists on a separate box than my build server.
Anyone got any ideas?
Have u try to update Svn client ? I doubt it is so simple, but let's check !
Try a svn cleanup
What is your svn config in ccnet ?
What is the build revision of ccnet you are using ? You should try the latest 1.5.x nigthly build, which is very stable for me.
http://ccnetlive.thoughtworks.com/CCNet-builds/1.5.0/
did you try to change the startup parameters of CCService?
Namely, set the "Allow service to interact with desktop" check box on Log On tab.
Also, you may try to use other account than "Local System".
I am not sure, but seems it may fix the issue, since it may be "Local System" account specific issue effect.