Re: [BUG] lftp 4.3.6
Achim Gratz NexGo.DE> writes: > The previous lftp version 4.3.3 on Cygwin also does not show the bug. I've > reported the bug to the lftp mailing list as well. I'm investigating further > with a local compile... I've compiled both the 4.3.3 and 4.3.6 version using the same settings, so they have the same libraries etc. -- 4.3.3 is still good and 4.3.6 has the bug. Let's see what upstream has to say about it, meanwhile I'd think that 4.3.6 should be pulled from distribution... Regards, Achim. -- 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
1.7.14-2: Suspected lock-up in texlive-collection-basic post inst all when also installing CygwinPorts
Hi I am a newbie to the Cygwin mailing lists and have read through in detail the process of reporting problems so hopefully I am submitting the following problem to the correct mailing list. There appears to be a problem when installing Cygwin and CygwinPorts. I followed the installation instructions at the following link, downloading the files to a local drive before attempting the installation: http://sourceware.org/cygwinports/ The MD5 checksums verified successfully, and all packages installed. However, when running the post install script for texlive-collection-basic, the installation process appeared to lock up: there was little CPU activity, and although the installer was left running for several hours (overnight), the texlive-collection-basic post install script did not finish. I cancelled the installation and ran /etc/postinstall/texlive-collection-basic.sh in a console window. It gave a repeating sequence of the following two errors: 1 [main] perl 4920 child_info_fork::abort: unable to remap Fcntl.dll to same address as parent (01FC) - try running rebaseall 1 [main] perl 5996 child_info_fork::abort: unable to remap MD5.dll to same address as parent (01FB) - try running rebaseall This was surprising, as rebaseall is the first thing run in post install (it is called from /etc/postinstall/autorebase.bat). So a rebaseall would have been run just a few moments before. I did a little investigation on the web, and discovered that rebaseall does not rebase perl modules: http://cygwin.com/ml/cygwin/2012-02/msg00701.html My solution was to force a rebase of the perl modules during the autorebase post install process, by adding the following line to the end of /etc/postinstall/autorebase.bat (in package _autorebase): if exist bin\perlrebase sh /bin/perlrebase This change ensures that perl modules are rebased before the texlive-collection-basic post install script runs. This fixed the problem: Cygwin and CygwinPorts install successfully. Cygwin and CygwinPorts were download on 1st May from a mirror (thus picking up packages added or updated as of 30th April). The problem was verified on two PCs, both running Windows XP Professional SP 3. The fix was verified on the same two PCs. .. Unfortunately I am not able to provide the output from the command cygcheck as it contains sensitive information. If you require any further information then please don't hesitate to contact me. Best Regards Chris Moran -- 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: [BUG] lftp 4.3.6
Achim Gratz NexGo.DE> writes: > I've compiled both the 4.3.3 and 4.3.6 version using the same settings, so > they > have the same libraries etc. -- 4.3.3 is still good and 4.3.6 has the bug. > Let's see what upstream has to say about it, meanwhile I'd think that 4.3.6 > should be pulled from distribution... Upstream has released 4.3.7 which fixes the bug. Yay! Regards, Achim. -- 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: Performance problems with emacs-X11 in current cygwin.
I just upgraded this morning and can confirm emacs is also very sluggish for me also. I'm running windows xp pro 2002 sp 3, if that is any help. Let me know if you need any more information and/or help testing, best regards, stephen -- 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
cygwin won't create .bashrc / .bash_profile after installing
cygwin version 2.761 have a problem when installing cygwin, I installed it with a clean when setup is complete, I run "cygwin.bat" but cygwin does not create the file. bashrc and. bash_profile. as are his or her home directory. not in C: \ cygwin \ Home \ profile but instead in C: \ Documents And Settings \ User I've re-install up to 3 times but do not also fix Can you help me? -- 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: cygwin won't create .bashrc / .bash_profile after installing
On 5/30/2012 1:25 PM, bowo keren wrote: cygwin version 2.761 that is the setup version and not the cygwin version "uname -a" or "cygcheck -c cygwin" will provide you the cygwin version have a problem when installing cygwin, I installed it with a clean when setup is complete, I run "cygwin.bat" but cygwin does not create the file. bashrc and. bash_profile. as are his or her home directory. not in C: \ cygwin \ Home \ profile but instead in C: \ Documents And Settings \ User I've re-install up to 3 times but do not also fix Can you help me? modify /etc/password and set the right home location for you / your user Regards Marco -- 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: Performance problems with emacs-X11 in current cygwin.
On 5/30/2012 6:51 AM, Stephen L wrote: I just upgraded this morning and can confirm emacs is also very sluggish for me also. I'm running windows xp pro 2002 sp 3, if that is any help. Let me know if you need any more information and/or help testing, Which packages got upgraded? You can check this by looking at /var/log/setup.log. Ken -- 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: 20120523: bug in fork/exec
On May 29 11:40, Corinna Vinschen wrote: > On May 25 15:10, Yaakov (Cygwin/X) wrote: > > On 2012-05-25 04:40, Corinna Vinschen wrote: > > >On May 25 03:26, Yaakov (Cygwin/X) wrote: > > >>With the 20120523 snapshot, if a process attempts to fork/exec > > > > > >Which snapshot shows this effect first? > > > > Ouch, it starts with 20120309. > > Thanks. That would mean a single change is the culprit, but I need > a way to reproduce the problem to be able to fix it (other than just > reverting the patch). > > > FWIW, here is the fork() code I discovered this with: > > > > http://git.gnome.org/browse/glib/tree/glib/gspawn.c?id=2.32.3 > > That's a bit heavy as far as testcases go. Thing is, I can't reproduce > it. If that's a generic problem, shouldn't this also occur when trying > to start a program from bash or tcsh? I deliberately removed a DLL from > my system, but there is no hang at all when trying to start an affected > application. > > Can you please provide a simple testcase? If you can reproduce it with > given binaries from the distro, I don't need source code, just the steps > and the names of the binaries to reproduce. Never mind. I found the problem and just checked in a patch. I'll create a new snapshot shortly. Please test. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Mintty Log Off problem (now 1.7.16s)
On May 29 12:41, Harry G McGavran Jr wrote: > > > On 05/29/12 12:31, Andy Koppe wrote: > > On 29 May 2012 17:17, Harry G McGavran Jr wrote: > >> > >> Ryan Johnson wrote: > >>> > >>> I routinely encounter mintty windows that don't close after > >>> I exit the login shell they run (even though they contain no > >>> visible child processes), but they can still be closed using > >>> the big red "X" in the corner... your problem sounds like > >>> something more sinister. > >>> > >>> Ryan > >>> > >> > >> There is never an "X" to deal with here. One never know there is > >> a problem until he does start->Log Off to log out of windows. > >> > >> I can normally close any/all mintty windows and then with various > >> process explorers try to find a mintty process and never find any. > >> Then when I log out of Windows, Windows claims it has to close > >> mintty.exe. This was fixed once in a snapshot of 1.7.10, but > >> has since returned with 1.7.15. In this incarnation it seems to > >> occur whenever I've run a Cygwin X app from a mintty window. > >> If I've signed on in Windows and never run a Cygwin X app it > >> generally doesn't happen, but I can't be sure it never happens. > >> Every time I've run a Cygwin X app though I can expect to see > >> it after closing (apparently normally) all mintty windows and > >> then log off of Windows. > > > > Do I understand you correctly that you no longer have any mintty > > windows open when this happens? That's puzzling indeed. Have you > > looked at ye olde Big List Of Dodgy Applications? > > > > http://cygwin.com/faq/faq.using.html#faq.using.bloda > > > > Andy > > Yes, your understanding is correct. My bloda spectrum hasn't > changed since 1.7.10 and is pretty well in hand. When the problem first > appeared in 1.7.10 and I posted about it, a few days later I got a > suggestion to try the latest 1.7.11s snapshot and see if that fixed it. > It did, I haven't had the problem since until 1.7.15 and 1.7.16s. > > This isn't a show stopper, especially since in this incantation it > doesn't happen all the time, however something isn't quite right... > Interesting the Cygwin X apps aggravate the problem. Can you try to find out which snapshot introduced the problem? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: procps and pgrep hang
On May 30 08:12, Tom Rodman wrote: > On Wed 5/23/12 17:53 +0200 Corinna wrote: > > On May 21 11:40, Tom Rodman wrote: > > > On Wed 5/16/12 22:04 EDT Christopher Faylor wrote: > > > > On Wed, May 16, 2012 at 08:46:09PM -0500, Tom Rodman wrote: > > > > > $ pgrep bash > > > --snip > > > > > $ procps -o pid,args > > > > > PID COMMAND > > > > > 4580 procps -o pid,args > > > > > --note: above command hangs, ended up killing it > > > > > > > > Try a snapshot. > > > > > > Thanks. It seems better, but still hangs, on this box (and 1 other). > > > > > > Examples ran tonight w/20120517 snapshot: > > > > > > http://pastebin.com/xQbtChsJ > > > > Looking into your strace I'm wondering if you really mean hanging in > > the sense of "hanging indefinitely until killed", > > That's what I mean - I have to kill it, it hangs forever. > > > or if you mean it > > hangs for about half a second. Since that's what the strace shows. > > For some of the information about a process under /proc, the requesting > > process has to open a pipe and then, by using a special signal, informs > > that process that it requests information which in turn is send over > > the pipe back to the requester. The timeout for each of the read > > operations on the pipe is restricted to 500ms to avoid indefinite > > hangs. > > > > Unfortunately I can't reproduce this effect, neither on XP nor on W7. > > > > Hmm, puzzeling. I'm wondering though, if this may be a result of using > > message type pipes. Nothing else comes to mind which has changed in > > this piece of code lately. For testing you could set the environment > > variable CYGWIN to "pipe_byte" and try again. > > On my laptop, only the pgrep bug shows up, here is the 'forever hang' > strace w/CYGWIN set to pipe_byte: A signal delivery hangs as if the receiver never reads its signal pipe. I still can't reproduce the problem, though. Can you try to find out which snapshot introduced the problem? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Mintty Log Off problem (now 1.7.16s)
On 30/05/2012 11:52 AM, Corinna Vinschen wrote: On May 29 12:41, Harry G McGavran Jr wrote: On 05/29/12 12:31, Andy Koppe wrote: On 29 May 2012 17:17, Harry G McGavran Jr wrote: Ryan Johnson wrote: I routinely encounter mintty windows that don't close after I exit the login shell they run (even though they contain no visible child processes), but they can still be closed using the big red "X" in the corner... your problem sounds like something more sinister. Ryan There is never an "X" to deal with here. One never know there is a problem until he does start->Log Off to log out of windows. I can normally close any/all mintty windows and then with various process explorers try to find a mintty process and never find any. Then when I log out of Windows, Windows claims it has to close mintty.exe. This was fixed once in a snapshot of 1.7.10, but has since returned with 1.7.15. In this incarnation it seems to occur whenever I've run a Cygwin X app from a mintty window. If I've signed on in Windows and never run a Cygwin X app it generally doesn't happen, but I can't be sure it never happens. Every time I've run a Cygwin X app though I can expect to see it after closing (apparently normally) all mintty windows and then log off of Windows. Do I understand you correctly that you no longer have any mintty windows open when this happens? That's puzzling indeed. Have you looked at ye olde Big List Of Dodgy Applications? http://cygwin.com/faq/faq.using.html#faq.using.bloda Andy Yes, your understanding is correct. My bloda spectrum hasn't changed since 1.7.10 and is pretty well in hand. When the problem first appeared in 1.7.10 and I posted about it, a few days later I got a suggestion to try the latest 1.7.11s snapshot and see if that fixed it. It did, I haven't had the problem since until 1.7.15 and 1.7.16s. This isn't a show stopper, especially since in this incantation it doesn't happen all the time, however something isn't quite right... Interesting the Cygwin X apps aggravate the problem. Can you try to find out which snapshot introduced the problem? Perhaps figuring out which snapshot between 1.7.10 and 1.7.11 fixed it would be faster? It sounds like he didn't go very long between 10 and [some] 11s. Not sure it would be as enlightening, though, especially if it's one of these cases where some undefined behavior just happens to do less-horrible things than usual for some reason... Ryan -- 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: [BUG] lftp 4.3.6
> Achim Gratz NexGo.DE> writes: > > I've compiled both the 4.3.3 and 4.3.6 version using the same settings, so > > they > > have the same libraries etc. -- 4.3.3 is still good and 4.3.6 has the bug. > > Let's see what upstream has to say about it, meanwhile I'd think that 4.3.6 > > should be pulled from distribution... > > Upstream has released 4.3.7 which fixes the bug. Yay! Thanks for chasing that down. I'll package and release 4.3.7 shortly. Andrew. -- 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: Mintty Log Off problem (now 1.7.16s)
On May 30 11:58, Ryan Johnson wrote: > On 30/05/2012 11:52 AM, Corinna Vinschen wrote: > >On May 29 12:41, Harry G McGavran Jr wrote: > >> > >>On 05/29/12 12:31, Andy Koppe wrote: > >>>On 29 May 2012 17:17, Harry G McGavran Jr wrote: > Ryan Johnson wrote: > >I routinely encounter mintty windows that don't close after > >I exit the login shell they run (even though they contain no > >visible child processes), but they can still be closed using > >the big red "X" in the corner... your problem sounds like > >something more sinister. > > > >Ryan > > > There is never an "X" to deal with here. One never know there is > a problem until he does start->Log Off to log out of windows. > > I can normally close any/all mintty windows and then with various > process explorers try to find a mintty process and never find any. > Then when I log out of Windows, Windows claims it has to close > mintty.exe. This was fixed once in a snapshot of 1.7.10, but > has since returned with 1.7.15. In this incarnation it seems to > occur whenever I've run a Cygwin X app from a mintty window. > If I've signed on in Windows and never run a Cygwin X app it > generally doesn't happen, but I can't be sure it never happens. > Every time I've run a Cygwin X app though I can expect to see > it after closing (apparently normally) all mintty windows and > then log off of Windows. > >>>Do I understand you correctly that you no longer have any mintty > >>>windows open when this happens? That's puzzling indeed. Have you > >>>looked at ye olde Big List Of Dodgy Applications? > >>> > >>>http://cygwin.com/faq/faq.using.html#faq.using.bloda > >>> > >>>Andy > >>Yes, your understanding is correct. My bloda spectrum hasn't > >>changed since 1.7.10 and is pretty well in hand. When the problem first > >>appeared in 1.7.10 and I posted about it, a few days later I got a > >>suggestion to try the latest 1.7.11s snapshot and see if that fixed it. > >> It did, I haven't had the problem since until 1.7.15 and 1.7.16s. > >> > >>This isn't a show stopper, especially since in this incantation it > >>doesn't happen all the time, however something isn't quite right... > >>Interesting the Cygwin X apps aggravate the problem. > >Can you try to find out which snapshot introduced the problem? > Perhaps figuring out which snapshot between 1.7.10 and 1.7.11 fixed > it would be faster? It sounds like he didn't go very long between 10 > and [some] 11s. Not sure it would be as enlightening, though, If the code in question has changed a lot, it's only marginally helpful to refer to a change in older code. OTOH, knowing both, which snapshot "fixed" it and which snapshot broke it again could be valuable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [BUG] lftp 4.3.6
Andrew Schulman writes: >> Upstream has released 4.3.7 which fixes the bug. Yay! > > Thanks for chasing that down. I'll package and release 4.3.7 shortly. > Andrew. Thank you. When you're at it, please remove the README~ from the patch file... :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
Bug? Mercurial permissions
Hi,
Mercurial seems to be setting permissions strangely, on files inside
subdirectories, when cloning a repository. Namely, on the Windows side,
the user SYSTEM user seems to be lacking any permissions.
This causes the files not being able to be backed up (by CrashPlan).
~$ mkdir test
~$ cd test
~/test$ mkdir foo
~/test$ touch bar.txt foo/baz.txt
~/test$ hg init
~/test$ hg add bar.txt foo/baz.txt
~/test$ hg commit -m "test"
~/test$ cd ..
~$ hg clone test test2
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
~$ cd test2
~/test2$ ls -l bar.txt foo/baz.txt
-rw---+ 1 tuomov None 0 2012-05-30 18:51 bar.txt
-rw--- 1 tuomov None 0 2012-05-30 18:51 foo/baz.txt
All looks good so far... but what's the difference with the + sign ?
Now let's look at Windows properties dialog for the permissions:
bar.txt:
SYSTEM: full control, etc.
tuomov: read, write
Administratoren: Full control
Everyone, None: Special permissions
("Administrators" is in German, because Lenovo recovery disks never gave
me the chance
to install English Windows, and I had to do some spurious stuff to make it
English.
The original install gave the chance.)
This looks ok so far, but let's look at the other file.
foo/baz.txt:
tuomov: read, write
Everyone, None: Special permissions
Oops, SYSTEM is missing.
What's going on here?
cygcheck.out
Description: Binary data
--
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: Mintty Log Off problem (now 1.7.16s)
Corinna wrote: >If the code in question has changed a lot, it's only marginally helpful >to refer to a change in older code. OTOH, knowing both, which snapshot >"fixed" it and which snapshot broke it again could be valuable. > > >Corinna This problem first appeared in 1.7.10. The snapshot I downloaded that fixed it was "cygwin-inst-20120415.tar.bz2" that I downloaded on April 17, 2012. The first go around of posts on this went without replies for quite some time after 1.7.10 came out. After one of my posts that questioned whether there were very many seeing this problem, someone posted that I should try the latest snapshot, so there is a chance the problem was fixed in a snapshot previously to the one I downloaded. The one I downloaded was current as of the day the post appeared suggesting a snapshot, so it could have been where the fix was. Nonetheless I responded to that post with a post saying that that snapshot fixed the problem. There were no further posts on the subject until now. Harry -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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: Bug? Mercurial permissions
On Wed, 30 May 2012 18:57:37 +0200, Tuomo Valkonen
wrote:
~/test2$ ls -l bar.txt foo/baz.txt
-rw---+ 1 tuomov None 0 2012-05-30 18:51 bar.txt
-rw--- 1 tuomov None 0 2012-05-30 18:51 foo/baz.txt
Actually -- didn't occur to me earlier to check it -- the permissions under
'test', that has not gone through Mercurial, are exactly the same. So why
is one directory level deeper losing all the SYSTEM permissions?
c:\cygwin\home\tuomov has
Full control for SYSTEM, tuomov, Administratoren. Not inherited.
c:\cygwin\home\tuomov\test has
Full control for tuomov ("This folder only"), and
SYSTEM, Administratoren ("This folder, subfolders
and files"),
CREATOR OWNER, CREATOR GROUP ("Subfolders and
files only"),
Read only for Everyone ("This folder, subfolders, and files"), and
None ("This folder only").
c:\cygwin\home\tuomov\test\foo has
Full control for tuomov, SYSTEM, Administratoren ("This folder only"),
and
CREATOR OWNER, CREATOR GROUP ("Subfolders and
files only"),
Read only for Everyone ("This folder, subfolders, and files"), and
None ("This folder only").
So somewhere the permissions inheritance bits are also altering.
--
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: Display a starting message
Merci beaucoup :) Bugzilla from m...@cs.umass.edu wrote: > > On 5/28/2012 2:26 PM, Shravan1804 wrote: >> >> Dear all, >> >> I would like my cygwin terminal to display a starting message everytime I >> start the program. For example something like "Hello Shravan, what do you >> want to do today?" or this type of pictures : > > Put something in your .bash_profile (or something like > that). Not a function of cygwin,specifically ... > > Eliot Moss > > -- > 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 > > > -- View this message in context: http://old.nabble.com/Display-a-starting-message-tp33921015p33933611.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Mintty Log Off problem (now 1.7.16s)
On 05/30/12 12:37, Andy Koppe wrote: > On 29 May 2012 19:41, Harry G McGavran Jr wrote: >> >> >> On 05/29/12 12:31, Andy Koppe wrote: >>> On 29 May 2012 17:17, Harry G McGavran Jr wrote: >>> Do I understand you correctly that you no longer have any mintty >>> windows open when this happens? That's puzzling indeed. Have you >>> looked at ye olde Big List Of Dodgy Applications? >>> >>> http://cygwin.com/faq/faq.using.html#faq.using.bloda >>> >>> Andy >> >> Yes, your understanding is correct. My bloda spectrum hasn't >> changed since 1.7.10 and is pretty well in hand. > > That doesn't exclude a BLODA problem. It's entirely possible that a > dodgy app gets away with whatever it's doing with one Cygwin version, > but fails with the next. > I can normally close any/all mintty windows and then with various process explorers try to find a mintty process and never find any. Then when I log out of Windows, Windows claims it has to close mintty.exe. > > Are you invoking mintty as administrator and looking at the process > lists without administrator rights? Otherwise this just defies > explanation, short of something messing with the Windows kernel, which > Cygwin (being a user-space DLL) doesn't do. > > Andy This is with Windows XP SP3. I am in the administrator group, but I don't invoke mintty as administrator, only as I normally run as me, but I am in the administrator group. It's not impossible that is bloda, but it is odd that it comes and goes with various cygwin releases then. It clearly started when I upgraded to 1.7.10, and clearly disappeared with the 1.7.11s snapshot and then clearly appeared again with 1.7.15. Harry -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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: Mintty Log Off problem (now 1.7.16s)
On May 30 11:37, Harry G McGavran Jr wrote: > Corinna wrote: > > > >If the code in question has changed a lot, it's only marginally helpful > >to refer to a change in older code. OTOH, knowing both, which snapshot > >"fixed" it and which snapshot broke it again could be valuable. > > > > > >Corinna > > This problem first appeared in 1.7.10. The snapshot I downloaded > that fixed it was "cygwin-inst-20120415.tar.bz2" that I downloaded > on April 17, 2012. The first go around of posts on this went > without replies for quite some time after 1.7.10 came out. > After one of my posts that questioned whether there were > very many seeing this problem, someone posted that I should > try the latest snapshot, so there is a chance the problem > was fixed in a snapshot previously to the one I downloaded. > The one I downloaded was current as of the day the post appeared > suggesting a snapshot, so it could have been where the fix was. > Nonetheless I responded to that post with a post saying that > that snapshot fixed the problem. There were no further > posts on the subject until now. That's why I'm asking. If you could try to find out which snapshot fixed it and which snapshot broke it again, it would help to find the cause. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [BUG] lftp 4.3.6
> Andrew Schulman writes: > >> Upstream has released 4.3.7 which fixes the bug. Yay! > > > > Thanks for chasing that down. I'll package and release 4.3.7 shortly. > > Andrew. > > Thank you. When you're at it, please remove the README~ from the patch > file... :-) OK, sorry. Most annoying emacs feature that yet I've never bothered to turn off. I always try to cut those out, but sometimes they slip through. -- 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: [BUG] lftp 4.3.6
Andrew Schulman writes: > OK, sorry. Most annoying emacs feature that yet I've never bothered to turn > off. I always try to cut those out, but sometimes they slip through. No need to be sorry, but maybe we could convince Yaakov not to package autosave files or at least give a warning about their presence? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Mintty Log Off problem (now 1.7.16s)
Corinna wrote: >That's why I'm asking. If you could try to find out which snapshot >fixed it and which snapshot broke it again, it would help to find the >cause. > > >Thanks, >Corinna This will take a little time since one has to log off to see the problem and I have no idea which 1.7.10s was the starting point. Unfortunately, the rest of this week, I won't have very much time to do many iterations. I'll see if I can find where it started and post back, but unless it's in the first few tries, it will likely be sometime next week before I have the answer... Harry On 05/29/12 10:17, Harry G McGavran Jr wrote: > > Ryan Johnson wrote: >> >> I routinely encounter mintty windows that don't close after >> I exit the login shell they run (even though they contain no >> visible child processes), but they can still be closed using >> the big red "X" in the corner... your problem sounds like >> something more sinister. >> >> Ryan >> > > There is never an "X" to deal with here. One never know there is > a problem until he does start->Log Off to log out of windows. > > I can normally close any/all mintty windows and then with various > process explorers try to find a mintty process and never find any. > Then when I log out of Windows, Windows claims it has to close > mintty.exe. This was fixed once in a snapshot of 1.7.10, but > has since returned with 1.7.15. In this incarnation it seems to > occur whenever I've run a Cygwin X app from a mintty window. > If I've signed on in Windows and never run a Cygwin X app it > generally doesn't happen, but I can't be sure it never happens. > Every time I've run a Cygwin X app though I can expect to see > it after closing (apparently normally) all mintty windows and > then log off of Windows. > > Harry > > > -- Harry G. McGavran, Jr. E-mail: w5...@w5pny.com -- 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: [BUG] lftp 4.3.6
On 2012-05-30 14:32, Achim Gratz wrote: Andrew Schulman writes: OK, sorry. Most annoying emacs feature that yet I've never bothered to turn off. I always try to cut those out, but sometimes they slip through. No need to be sorry, but maybe we could convince Yaakov not to package autosave files or at least give a warning about their presence? As in the attached? Yaakov 0001-pkg-exclude-text-editor-backup-files-in-CYGWIN-PATCH.patch Description: application/itunes-itlp -- 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
