on Thu, 27 Jun 2013, at 23:42, Alan W. Irwin thusly quipped: > I am getting absolutely nowhere.
Nonsense, you've now found the "next bug" that will be stopping cygwin from working in wine until it's fixed. I thought that was the point of the exercise? :) > A script run by setup.exe in the latter part of the install steps > appears to hang now with or without updating cygwin1.dll to the > fork-fixed version. I got this result for two versions of > wine which I have heavily tested in other ways, wine-1.5.19, and > a wine-git version near wine-1.6.0-rc1. > > Here are the last few messages before the hang: > > Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz > AddAccessAllowedAce(, group) failed: 1337 Installing file > cygfile:///usr/share/man/man1/xzgrep.1.gz AddAccessAllowedAce(, > group) failed: 1337 Installing file > cygfile:///usr/share/man/man1/xzless.1.gz AddAccessAllowedAce(, > group) failed: 1337 Installing file > cygfile:///usr/share/man/man1/xzmore.1.gz AddAccessAllowedAce(, > group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 > Extracting from > file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.k > ernel. > org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.b > z2 Installing file cygfile:///usr/bin/cygz.dll > AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, > group) Interesting but probably not the problem. > failed: 1337 Visited: 51 nodes out of 2986 while creating > dependency order. Dependency order of packages: base-cygwin sed > gzip libpcre0 gettext grep libmpfr4 gawk tzcode libgmp3 libattr1 > libncurses10 texinfo _update-info-dir libreadline7 terminfo > libstdc++6 libncursesw10 libiconv2 libintl8 bash coreutils cygwin > libgcc1 dash rebase _autorebase alternatives findutils base-files > libbz2_1 bzip2 libpopt0 cygutils diffutils dos2unix editrights > zlib0 file groff ipc-utils less liblzma5 login xz man mintty run > tar vim-minimal which running: > Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile > "/etc/postinstall/000-cygwin-post-install.sh" > > There is no obvious chance that I can see before that hang where I can > overwrite cygwin1.dll with the corrected version. See my previous post for a detailed, step-by-step explanation of how to run setup.exe without installing the cygwin package. Then you won't need to race the installer---just drop your binaries in before you run setup.exe. > However, if I exit > the hang, overwrite cygwin1.dll, and run the above script > by hand it still hung (no cpu activity and no change in the > cygwin tree that changes its total size as measured to > the nearest byte with "du -s --bytes cygwin") for ~20 minutes > before I gave up. A new behavior! This was the second best outcome you could have possibly hoped for. > By the way, after exiting after the first hang, if I simply > overwrite cygwin1.dll with the corrected version, then > run setup.exe the install stage errors out immediately with > the message "Can't open package database for writing. File exists." If it happens right away that's a message from setup.exe, not cygwin1.dll. If you deleted cygwin1.dll or put the old one back, you would almost certainly get the same result. cygwin's /etc/setup contains the database in question. > Instead, at that time I got the exact error > message when running the above script concerning an unhandled page > fault that others have described at > http://bugs.winehq.org/show_bug.cgi?id=24018 and which the > fork-fixed cygwin1.dll is supposed to fix. So presumably Cygwin's > bash.exe or some application executed by the above script has > changed in the last month to cause the different wine symptoms. Or > I am inadvertently doing something different than I did a month > ago. The old behavior was caused by a bug, clearly. That bug has been around for ages or so people are reporting. Perhaps, that bug is now fixed, or at least changed (like a maggot into a housefly). Either way, yes, wine folks now have a "new" problem to look at. But this does not imply a new bug was introduced into the wine code-base, DUCY? The Occam's Razor explanation is that, now that it no longer crashes due to the old bug, wine gets a little bit further down the "correct" code path, before crashing in some new way -- one that you are possibly the first person -- but also very probably not the last -- ever to observe, but which was nevertheless "there all along" in the wine (or cygwin) codebase, waiting to be discovered after this one got fixed. > So unless someone can suggest a method to get around the "Can't open > package database for writing. File exists." message, and assuming > that method doesn't subsequently run into the script hang (which is a > big if), then I think it is time for someone with a lot more wine and > cygwin expertise than me to take over here to attempt to try and > figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll > overwriting the buggy version. Sorry, I assumed you were a wine hacker in my previous post. Unless you're willing to tackle some potentially very steep learning curves, your best bet is to post your experiences to wine's bugzilla, if you haven't done so yet, and let the wine developers take it from there. You may or may not reach the promised-land anytime soon. If I had to, I'd guess that once one fixes this new-but-maybe-old bug, another new-but-maybe-old bug is exposed, and once one fixes that, another, and so on, for "a while yet" before cygwin works "like a champ" in wine... the good news is, both projects are open source, so anybody sufficiently determined and "-fu"-ly equipped can fix those bugs without poring over tons of disassembled binary code and trace-logs. -gmt -- 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
