Re: gem remap problem
Am 12.04.2012 11:02 schrieb Neusbeer: Since a few weeks when I try to install a gem I get a remap error. I tried rebasing with ash /bin/rebaseall -v but nothing works :( http://cygwin.com/ml/cygwin/2012-02/msg00701.html -- Michael -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1
Am 27.03.2012 10:36 schrieb Corinna Vinschen: Needless to say that the ultimately most efficient way would be to find a method to avoid rebase problems after fork at all. The last attempt at it looked promising at first, but then again... http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073 You'd think all the statements about interoperability after the EU anti-trust cases would apply to Cygwin as well. If SUA can, Cygwin should as well: Microsoft shall ensure that third-party software products can interoperate with Microsoft’s Relevant Software Products using the same Interoperability Information on an equal footing as other Microsoft Software Products. (“Interoperability Commitment”). http://www.microsoft.com/Presspass/press/2009/dec09/12-16Statement.mspx Conveniently, nothing except a press contact is given on that page. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git svn got error int the latest versoin of cygwin
Am 18.03.2012 19:07 schrieb Anand Arumugam: $ash $/bin/rebaseall -v after installing cygwin and whenever I have this problem. Sometimes it gets fixed but sometimes, I have to restart the laptop. I downgrade cygwin1.dll to 1.7.10 and the problem is still there. Try 'perlrebase' in addition as well. You might have a custom perl module not installed by cygwin setup, which rebaseall alone won't catch. -- Michael Lutz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: more address space needed ... is already occupied problems (with snapshot of 2012-02-20)
Am 24.02.2012 03:25 schrieb marco atzeri: the cygwin's ruby package etc.so should be included in the rebaseall list by default. I never said my script would specifically fix this problem. I only said that, just like for perl, it is very easy to install additional binary ruby modules NOT covered by cygwin's package database. As long as perlrebase is needed (and it definitely is on my computer), there's also the need for an equivalent rubyrebase. Michael -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: more address space needed ... is already occupied problems (with snapshot of 2012-02-20)
Am 23.02.2012 09:30 schrieb Corinna Vinschen:
If you ran rebaseall, then ruby's shared libs should have been rebased
as well.
This is not necessarily true if you've got gems (just like perl CPAN
modules) not packaged by cygwin installed.
For that I've hacked a rubyrebase script from the cygwin supplied
perlrebase script. I've attached it here, maybe it can be useful for other
people as well.
Feel free to use it for whatever you want, public domain, CC-0, whatever.
Michael
#!/bin/sh
# The default ruby modules are properly rebased, a rebase clash is very
unlikely.
# However with more and more ruby gems being added over time,
# *** fatal error - unable to remap some.dll to same address as parent
# will become more likely, and those new DLLs are not rebased by a normal
rebaseall.
# rubyrebase starts afresh all ruby DLLs from a pretty low base upwards.
suff=$1
baseaddr=$2
# use a rather low base and go upwards, might clash with some Win7 system dlls
baseaddr=${baseaddr:=0x5700}
ruby=/usr/local/bin/ruby$suff.exe
if [ ! -f $ruby ]; then
ruby=/usr/bin/ruby$suff.exe
if [ ! -f $ruby ]; then
echo $ruby and /usr/local/bin/ruby.exe not found
echo usage: rubyrebase [1.8 [baseaddr]]
exit
fi
fi
dll=$(ldd $ruby | $ruby -anle 'print $F[2] if /cygruby/')
if [ ! -e /usr/bin/rebase.exe ]; then
echo /usr/bin/rebase.exe not found. Install the rebase package
exit
fi
archdir=$($ruby -rrbconfig -e 'puts RbConfig::CONFIG[archdir]')
sitedir=$($ruby -rrbconfig -e 'puts RbConfig::CONFIG[sitearchdir]')
vendordir=$($ruby -rrbconfig -e 'puts RbConfig::CONFIG[vendorarchdir]')
ext=$($ruby -rrbconfig -e 'puts RbConfig::CONFIG[DLEXT]')
# write to a local .lst to be able to re-order dlls locally
echo $ruby rebase$suff.lst
echo $dll rebase$suff.lst
/usr/bin/find $archdir -name \*.$ext rebase$suff.lst
/usr/bin/find $sitedir -name \*.$ext rebase$suff.lst
/usr/bin/find $vendordir -name \*.$ext rebase$suff.lst
# rubygems might not be installed, in this case ruby errors and the error
message is not likely to be a valid directory :)
for i in $($ruby -rrubygems -e 'Gem.path.each {|f| puts f}'); do if [ -d $i ];
then /usr/bin/find $i -name \*.$ext rebase$suff.lst; fi done
/usr/bin/cat rebase$suff.lst | /usr/bin/xargs chmod ug+w
[ -e /usr/bin/peflags.exe ] /usr/bin/peflags -t $ruby
/usr/bin/rebase -v -b $baseaddr -T rebase$suff.lst
[ -e /usr/bin/peflags.exe ] /usr/bin/grep .so rebase$suff.lst |
/usr/bin/peflags -d0 -T - /dev/null
/usr/bin/cat rebase$suff.lst | /usr/bin/xargs chmod g-w
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fork failures in git rebase
Am 07.12.2011 19:16 schrieb Eric Blake: On 12/07/2011 11:12 AM, Rafael Kitover wrote: I was doing a git rebase origin/master today on a repo, and I saw alot of this: 7 [main] sh 6120 C:\cygwin\bin\sh.exe: *** fatal error - couldn't allocate heap, Win32 error 487, base 0xAD, top 0xB4, Have you run 'rebaseall' yet? Also, does it work any better with the snapshot? If rebaseall alone doesn't help, maybe also try disabling Address Space Layout Randomization (ASLR) by executing 'peflagsall -d 0 -s dll'. After that I've encountered these kinds of errors a lot less on my Win7 x64 cygwin install. Michael -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Installation problems with home path and sshd
Am 27.11.2011 11:37 schrieb gabier: cygrunsrv: Error starting a service: StartService: Win32 error 1069: (Following sentence translated from French) The failure to open a session has prevented the start of the service. Open the properties of the service and enable Allow service to interact with desktop (or something like that). If that option is already enabled I don't have any more ideas either. Michael -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Divergent file system contents, Cygwin versus Windows 7
Am 26.06.2011 17:14 schrieb Andrew Hancock: Thanks for any comments or suggestions for courses of action. I'm beginning to wonder if a fundamental incompatibility with Windows 7 (64-bit, in case it matters) could prevent the use of Cygwin on my machine. Mega- :( It works as designed (TM). That's the Vista file virtualization in action, which is supposed to increase application compatibility in conjunction with UAC. Section File Virtualization from http://msdn.microsoft.com/en-us/library/bb756960.aspx has more on it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
Am 22.01.2011 03:01 schrieb David Antliff: I do want to have CRLF endings in my files, because merge tools like kdiff3 (on Windows) require CRLF files. We could live without kdiff3, however changing this setting down the track is a harder problem to solve than using 'set -o igncr'. All sorts of strange problems occur if people stop using autocrlf=true. We have a very large number of repositories and clones, making a global change difficult, but perhaps not impossible. Well, if you use both software that requires CRLF (though kdiff3 in my experience doesn't) and software that requires LF (bash) on the same files, there isn't much git can do to solve that conflict. If it's a different set of files though (i.e. LF for .sh files, CRLF for source code or whatever), you might benefit from switching to the newer core.eol mechanism, which allows to override the line endings for individual files through .gitattributes. Refer to http://www.kernel.org/pub/software/scm/git/docs/git-config.html http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html Michael Lutz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Invoking GUI programs over SSH
Am 21.01.2011 13:06 schrieb David Antliff: I suppose it's a bug with git then, since it produces CRLF files on check-out (even if they were checked in as LF), [...] Seems more like a documentation misunderstanding to me: | core.autocrlf | | Setting this variable to true is almost the same as setting the text | attribute to auto on all files except that text files are not | guaranteed to be normalized: files that contain CRLF in the repository | will not be touched. Use this setting if you want to have CRLF line | endings in your working directory even though the repository does not | have normalized line endings. This variable can be set to input, in | which case no output conversion is performed. http://www.kernel.org/pub/software/scm/git/docs/git-config.html Don't set core.autocrlf to true if you don't want to have CRLFs in your files. Use input if you just want to avoid accidentally commit CRLFs. Michael Lutz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with gitk after cygwin update
Hello, thanks for looking into this. Am 20.09.2010 10:55 schrieb Corinna Vinschen: I can't reproduce the stack dumps, but I can reproduce the premature exit of the parent shell. This is a problem I'm still mulling over: http://cygwin.com/ml/cygwin/2010-09/msg00237.html I don't always get the stack dump either and I couldn't figure out a pattern for when it happens, so I'm not surprised. I can always open up a second xterm so this bug isn't that critical. There is another problem with git that I occasionally saw with older cygwin version as well, but feels to have become much more common lately. It happens when using git gui, which incidentally is a tk wish app as well. It's harder to reproduce, but the recipe below should do the trick. As a preparation in some temp dir: $ git init . $ echo -e a\nb file.txt $ git add file.txt $ git commit -m Commit $ echo -e a\na\nc\nd file.txt Now start citool: $ git gui citool The big pane on the right has some red and green line, click on one of these lines with a right click and select Stage this line. If you're lucky, this will hang git gui because it seems to wait for the output of a git command it spawned. The git command is hanging in process startup though, the stack trace below made with Process Explorer of the hanging command looks like it is waiting on some mutex. If it actually works the first try, click on the file icon in the lower left pane to unstage the line again and repeat until the hang occurs. It happens quite often that it hangs the first time for me, but sometimes it only hangs after several minutes of work done with git gui. Michael Lutz --- snip 1 --- Stack trace with Process Monitor Command C:\cygwin\lib\git-core\git-rev-parse.exe --verify HEAD ntoskrnl.exe!SeAccessCheckWithHint+0xb4a ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!PsIsSystemProcess+0x94 ntoskrnl.exe!KeStackAttachProcess+0x11c1 ntoskrnl.exe!ObReferenceObjectByPointerWithTag+0x233 ntoskrnl.exe!PsLookupProcessThreadByCid+0x56f ntoskrnl.exe!KeTestAlertThread+0xa79 ntoskrnl.exe!KeTestAlertThread+0x9fb ntdll.dll!RtlUserThreadStart -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problems with gitk after cygwin update
Hello, I just updated my Cygwin installation with the newest packages, especially cygwin base from 1.7.5 to 1.7.7 and git from 1.7.1 to 1.7.2.3. I'm now having problems when I launch gitk in the background from a xterm, i.e. gitk . First of all, if I press any key after I switch back to the xterm, it just closes. On the prompt logout is visible for just a moment before it closes. Secondly, I got the following error log when clicking around in gitk to view some commits. I never had such problems before I updated. Michael Lutz --- snip 1 $ cygcheck -c cygwin git gitk Cygwin Package Information Package VersionStatus cygwin 1.7.7-1OK git 1.7.2.3-1 OK gitk 1.7.2.3-1 OK Windows 7 Pro x64 with all updates. --- snip 2 0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty1 Stack trace: Frame Function Args 002838C8 6102749B (002838C8, , , ) 00283BB8 6102749B (61177B80, 8000, , 61179977) 00284BE8 61004AFB (611A1670, , 6123AAC4, 0001) End of stack trace 0 [main] git 6884 C:\cygwin\bin\git.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty1 Stack trace: Frame Function Args 002838C8 6102749B (002838C8, , , ) 00283BB8 6102749B (61177B80, 8000, , 61179977) 00284BE8 61004AFB (611A1670, , 6123AAC4, 0001) End of stack trace while executing close $gdtf (procedure gettreediffline line 36) invoked from within gettreediffline file10200d8 b5628c26f463d437e916ef31e0e97fa7629ead2a (eval body line 1) invoked from within eval $script (procedure dorunq line 11) invoked from within dorunq (after script) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: X server fails to start
Am 17.12.2009 14:48 schrieb Csaba Raduly: X used to work for quite a while but now it doesn't. The X icon appears and disappears. It seems to have developed a fixation with another window manager, according to the log. Not even a reboot helps. I have the same problem after upgrading to 1.7.1. Commenting the checkX call in startxwin.bat out and replacing it with 'sleep 5' makes it work for me. Michael Lutz -- PGP encrypted mails preferred. 4096/1024-bit DH/DSS key, ID 0x31DEFEF1, created 2001-03-02 FP: 5305 7CF5 09E9 EFF6 E12F D3D2 CD12 A090 31DE FEF1 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
