Re: Running setup-x86_64.exe without admin privileges
Am 24.09.2013 23:49, schrieb Buchbinder, Barry (NIH/NIAID) [E]: Trying to compress it with upx failed with an error message: upx: setup-x86-64.exe: CantPackException: can't pack new-exe UPX can't compress PE+ (64bit) executables. 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: fixing BLODA-caused fork failures
Am 03.10.2013 22:55, schrieb Adam Kellas: My company uses Cygwin and we experience fairly frequent fork failures, believed to be BLODA-related. I say "believed to be" because in this corporate environment, like many, we cannot uninstall the virus scanner even long enough to see what happens without it. In my experience the culprit is most often the "real-time" or "behavioral" component of the anti virus program. Uninstalling the virus program is a bad idea and it will certainly draw the ire of corporate IT, but you may persuade them to exclude the whole Cygwin installation tree from these two functions. In any case I'd try to get a test machine from IT and try if that helps. > So we need Cygwin and we're stuck with Forefront, putting us > between a rock and a hard place. AFAIK Forefront uses the same engine on the client as MSE. MSE has not been a problem w.r.t. Cygwin for me, so either the rules used by Forefront have been sharpened or the fork problems may not be related to it after all. Do you use other programs that are based on Cygwin, like NoMachine NX or other (perhaps in-house) programs that insist on putting their DLL at fixed address spaces? 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: checking in >= 256k file fatally corrupts rcs file
Ryan Johnson writes: > So in other words, a misguided performance optimization [1] that > almost certainly has little measurable impact on performance [2] has > introduced a silent data corruption bug (or tickled a latent one > somewhere else). Lovely. It is not the performance optimization that isn't working, but the code path through plain stdio while doing a diff that was probably never exercised (the tests all pass on Cygwin). Try RCS_MEM_LIMIT=0 to force stdio. The error does not occur on Linux and it doesn't seem to be known to the devs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Automated Installation Problem - Dependencies not installed?
Josef Kemetmüller student.tuwien.ac.at> writes: > The obvious fix is to install these using the "-P" option, but shouldn't there be an easier way to install > dependent packages using automated installation? That has been fixed in version 2.830 of setup.exe. 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: Automated Installation Problem - Dependencies not installed?
Josef Kemetmüller writes: > Where can I find this version? At the moment in sourceware CVS, but cgf said he planned to roll a new version. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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
gcc4-core packaging bug
The package gcc4-core provides a compatibility symlink for programs that expect the old gcc naming scheme (like Perl). The link however is just "gcc4", while Devel::CheckLib for instance looks for "gcc4.exe". 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: gcc4-core packaging bug
Andrey Repin writes: >> The package gcc4-core provides a compatibility symlink for programs that >> expect the old gcc naming scheme (like Perl). The link however is just >> "gcc4", while Devel::CheckLib for instance looks for "gcc4.exe". > > Report that to the maintainer of Devel::CheckLib > It SHOULD NOT check for .exe suffix under cygwin. Yes it should, since it does not need to know about the .exe magic Cygwin performs. Besides, it gets that information from %Config, which in turn comes from Cygwin's own Perl. Once the compatibility link is named gcc-4.exe, the .exe magic ensures that both checking for an executable named gcc-4 and gcc-4.exe will succeed, so that's the right thing to do and not patching whatever number of Perl modules and/or other build scripts. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: rename (util-linux 2.21.2)
Mariusz WODZICKI writes: > I frequently use ``rename''. Today I discovered that the most current > version has a changed syntax: Exactly why do you think it changed syntax? Looking at some old and new Linux manpages and the Git repository, it appears that the only thing that changed was the monikers for the parameters plus added documentation for the switches (that had been existing before already: expression <=> from replacement <=> to file<=> file http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=03b3d715ded40c44c074300b704be430aafbc1ae Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: gcc4-core packaging bug
Yaakov (Cygwin/X) writes: > Actually, the RIGHT thing to do is to have Perl (updated to 5.14.4 > and) built without the CC=gcc-4 hack. Oh, absolutely. But until we have that, if anyone runs into troubles that some program which hasn't been rebuilt since the gcc update is unable to find a C compiler, add the .exe suffix to the compatibility link. I've only mentioned it here because I recently got a new machine at work and wondered why I couldn't build some Perl modules anymore until I remembered that I had re-linked the compilers on the old one. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: setup.ini dependency graph?
Charles Wilson writes: > On 11/4/2013 11:00 AM, Christopher Faylor wrote: >> On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote: >>> I've got a few cleanups, and then I'll share the result. It's already >>> helped me generate a few re-packaging requests I plan to post over on >>> cygwin-apps... >> >> Is this packagable? It sounds pretty interesting. > > Probably. I could put it in cygutils, or standalone (like the new > cygcheck-leaves package is a standalone utility). Interesting, indeed. I've been working on another script that creates install directories for offline installation (using multiple package repositories and a config file to control package selection) that I hope to get polished for public release. It doesn't explicitly produce a dependency graph (I do have some optional debug output that could be used for this), but it wouldn't be difficult to bolt on (I already have a hash for the forward dependencies). >> Would it be crazy to generate this and make it available on the cygwin >> web site? Or would the dependency graph generation overload >> sourceware.org? > > The basic processing to generate a .dot file is pretty simple really; > just string comparisons and hash manipulations. But as Ryan already > pointed out, generating the actual graph in whatever format, is > probably compute intensive. It might be easier to keep things a bit more simple: the most common question is to get the direct dependencies of a package and the direct dependents (who is requiring this package). This graph is almost trivial and could be followed interactively up or down the dependency chain with little effort. It wouldn't look as pretty as a full dependency graph on an 8k display, but it'd be very useful. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Seeking a suggestion for unattended mass install procedure
Lavrentiev, Anton (NIH/NLM/NCBI) [C] writes: > As far as they can tell, there is no such an installation option that > tells to install "everything from the download directory". What they > do is that they run setup.exe to manually check everything from the available > packages that they want to have installed on a PC, then they follow the option > to download any left-over package dependencies, from which step setup.exe > takes > control and downloads / installs the selections. There is an option for setup.exe to install a complete category. To make use of that you need to write a new setup.ini so that the packages you've selected are members of that particular group. > Now, they want to replay the setup unattended with using only those downloaded > packages again, on any other new PC, without going through the selection > process > again, so basically to install everything that setup.exe has already > _downloaded_ to a certain directory when run manually (where all the > dependencies have already been satisfied, so the set is self-sufficient). They may say that they want this, but believe me that they actually don't. There's always some machines that will need a different selection of packages, if not initially then somewhere down the road. > How / Whether can they do such an install? If you really want to clone an existing installation, then copy over /etc/setup/installed.db into the new installation root and do a reinstall (there's no command line option for that). Alternatively, set all the versions in installed.db to zero and then let setup.exe do an "update", which is the default. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Seeking a suggestion for unattended mass install procedure
Lavrentiev, Anton (NIH/NLM/NCBI) [C] writes: >> I have an install script for Cygwin. It's not offline > > Thanks for the suggestion. My Systems team need to install from scratch > on bare boxes, from only an image DVD (which contained all the requisites of > the future machine, including CYGWIN's setup and the downloaded directory, > as I previously described). > > From the replies I've got so far, I beginning to think it's close to > impossible > without having to list (all) the packages... No. I have scripts to prove otherwise, but they are not yet ready for public consumption. If you need it right now, then you'll have to look elsewhere, otherwise if you are interested in betatesting, drop me a mail. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Seeking a suggestion for unattended mass install procedure
Lavrentiev, Anton (NIH/NLM/NCBI) [C] writes: >> Alternatively, you can grab the sources for setup and add an option > to do what you want the way you want it. > > Well, that's a trivial option with open source, of course. But also > it means to maintain a branch of our own setup.exe, which is the > least favorable of all. I've been down that path earlier than you and have managed to upstream most of my patches. I still carry a local branch for a few things, though. http://repo.or.cz/w/cygwin-setup.git The CVS version is mirrored on branch origin. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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: vi stealing SYSTEM-owned permissions and ownership
D. Boland writes: > I think I have new information on the stealing of ownership. Below test has > been > performed on the Apache folder, placed in the Windows Program Files folder by > the > Apache msi installer: > > "/cygdrive/c/Program Files (x86)/Apache Group/Apache2/" > > But if I perform the same test in my Cygwin home directory, vi behaves > beautifully. > > So, I was thinking this difference must be related to the Windows ACL > assigments on > the "Program Files" folder. If you are operating as a normal user on this folder, you aren't actually editing the files you think you see there, the whole contents is virtualized by UAC and redirected to your own personal copy on edit. If you want to keep your sanity, do not place anything that you intend to edit / change as a normal user into system directories on Win7 (that includes Cygwin itself). http://msdn.microsoft.com/en-us/library/bb756960.aspx Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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
[ANNOUNCEMENT] Update: upx-3.91 (test)
UPX has been updated to version 3.91 for both x86 and x86_64 architectures. This version includes experimental support for Win32/PE+ 64bit binaries. Additionally, this build uses LZMA SDK version 9.22, which is marked beta since 2011. For this reason, the release is currently marked test/experimental and has to be selected manually in setup.exe. Please test with your applications and report the results to the Cygwin mailing list to help gain the confidence to eventually make this release current. Thank you. 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: Problem with latest setup-x86.exe
Christopher Faylor writes: > I appreciate your looking at the source code but given what you changed, > I don't understand how what you did would fix that. If your changes > were really necessary then something would have to be seriously wrong > with mscvrt handling of argv strings. That points to a problem on > your system, not in the code. This is not the bug you are looking for... The changes from Harry effectively shut out the code path that triggers the bug by introducing another one. The bug is in a nutshell, that "\\?\conout$" isn't a valid UNC path and with the override of fopen as per the latest changes by Corinna creating an ofstream tries to use that to get the console output handle. I'm not sure how to fix this, it seems odd that there'd be no UNC variant of conout$, but my search has turned up empty. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: emacs-w32 24.3-7 aborts frequently using TRAMP
Ken Brown writes: > Can you do some experimentation to try to narrow this down? For example: > > * Is it related to Tramp or not? I don't think so, I get those crashes without Tramp in the picture and sometimes with an Emacs that simply has a single file open and then left alone. FWIW, besides crahses (which never happen when I'm using Emacs, so I'm thinking they might relate to the screen saver kicking in when Emacs is trying to do something), I do get some error messages from timer code that complains about not getting the expected vectorp once in a while and I've never seen these anywhere else but on Windows. > * Does the abort still occur if you start emacs with "emacs -Q"? I've tried numerous times, but none of these has crashed yet. Then again, the parallel "normal" Emacs session didn't crash either. > * Is the problem specific to emacs-w32 or does it happen with > emacs-nox and emacs-X11 also? Didn't test that. On the last crash I forgot that I had another Emacs running and attached to the wrong PID... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Problem with latest setup-x86.exe
Harry G McGavran Jr writes: > int main(int argc, char **argv, char **envp) The entry point in setup.exe is WinMain, which has a different signature and entry point. The use of __argv ties into the actual RTC entry point of WinMainCRTStartup and gets populated on startup. If indeed on one of your machines the behaviour is different than on others, you might pick up a different RTC. Try to find out from where this CRT, more specifically msvcrt.dll, is coming. These days you can expect a dozen of these in several places on your system and with the wrong path settings you might pick up a rogue one. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: Problem with latest setup-x86.exe
Corinna Vinschen writes: > I just explained that in a reply an the cygwin-apps list: > http://cygwin.com/ml/cygwin-apps/2013-11/msg00075.html > > I applied a patch to setup which should fix the issue. The patch WJFFM. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: I'm trying to get ProFTPD installed, and I can't seem to pull down the package from the Cygwin repositories
marco atzeri writes: > Ok, you forgot to highlight that, and it was not my first thought. > This is clearly a weakness of the current setup implementation. > > As basic install > > setup-x86.exe -P proftpd -q > > should install the package you are looking for, without the need > of additional software. > It works for me, just tested. > > I suggest to contact the chocolatey/cyg-get team > to check any problem on their side I've had a look at what cyg-get is and how it (likely) works. The problem with cyg-get is not that it doesn't use setup.exe, it is that it has no way of listing the available packages. That's even mentioned as a bug somewhere. So, to answer the original question, you'd first have to find out which package (if any) provides proftpd (using the Cygwin package search, URL below) and then give the package name thus obtained to cyg-get, which will call setup.exe to install it. http://cygwin.com/packages/ http://cygwin.com/cgi-bin2/package-grep.cgi?grep=proftpd&arch=x86 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: [ANNOUNCEMENT] Updated: rpm-4.11-1 (x86/x86_64)
Christopher Faylor cygwin.com> writes: > I have made a new version of rpm available for installation. rpm is the > Linux package management system used by Fedora, SuSE and others. There is a packaging or upload error with these: -rw-r--r-- 1 user users 1084632 29. Nov 16:19 rpm-4.11.1-1.tar.xz -rw-r--r-- 1 user users 1109872 29. Nov 16:19 rpm-4.11.1-1.tar.xzp The setup.ini file has picked up 4.11.1-1.xzp as the version of the package and the ".xzp" file is selected as the corresponding archive, the previous version is not listed at all. 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: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Andrew Schulman writes: > A new version of lftp, 4.4.11-1, is available in the Cygwin distribution. > The is the first release of lftp for x86_64. This version seems to have serious problems with the mirror command. Instead of transferring just the changed files, it seems to always want to transfer _everything_. I haven't yet looked into why this might happen, at the moment I've reverted to the previous version. 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: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Achim Gratz NexGo.DE> writes: > This version seems to have serious problems with the mirror command. > Instead of transferring just the changed files, it seems to always want to > transfer _everything_. I haven't yet looked into why this might happen, at > the moment I've reverted to the previous version. The last version to work correctly is 4.4.9, I don't see anything obvious in the ChangeLog that would explain why this happens. 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: emacs won't run
Andrea Venturoli netfence.it> writes: > Of course, emacs is a shell script. Of course it should be a symlink, pointing to emacs-X11 on a standard installation. Did you read /usr/share/doc/emacs/README.Cygwin? Is the DISPLAY environment variable set correctly? Does Emacs "run" when you start it as "emacs-X11 -Q"? 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: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Andrew Schulman writes: > OK. Meanwhile version 4.4.13 is out. Have you tried it to see if the > problem is fixed there? If not, I could put it out in test for you to try. Yes, I've tried all versions between and including 4.4.8 and 4.4.13 (I was hoping that it was fixed already). The last one to work is 4.4.9, but I haven't found any time to investigate further (and probably won't have for another few days). Since that failure is so glaringly obvious and no other reports in that direction have been made on the lftp mailing list, I'd venture the guess that it either somehow only happens on Cygwin or has something to do with the fact that I need to pull the files through a proxy server. It would be helpful to know if you can reproduce (just repeating a mirror operation on a freshly mirrored directory for instance) to narrow down the possibilities. 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: [ANNOUNCEMENT] Updated, new for 64-bit: lftp 4.4.11-1
Ken Brown writes: > On 12/6/2013 6:26 AM, Achim Gratz wrote: >> venture the guess that it either somehow only happens on Cygwin or has >> something to do with the fact that I need to pull the files through a proxy >> server. It would be helpful to know if you can reproduce (just repeating a >> mirror operation on a freshly mirrored directory for instance) to narrow >> down the possibilities. > > It works fine for me. I can re-produce it on my home computer, so no proxy involved. Here's a pared down version of what I'm doing: --8<---cut here---start->8--- set xfer:clobber set http:cache off set mirror:parallel-directories on mirror -e --parallel=10 -c --delete-first --depth-first --use-cache \ --script=cygwin.lftp \ http://mirrors.kernel.org/sourceware/cygwin/ \ /mnt/mirror/cygwin \ & --8<---cut here---end--->8--- The real mirror script sanitizes the cygwin.lftp script and the sources it for the actual mirroring. The problem is that from version 4.4.10 on the cygwin.lftp will include _all_ files encountered by mirror, not just the newer and missing ones. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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, new for 64-bit: lftp 4.4.11-1
Achim Gratz writes: > The real mirror script sanitizes the cygwin.lftp script and the sources > it for the actual mirroring. The problem is that from version 4.4.10 on > the cygwin.lftp will include _all_ files encountered by mirror, not just > the newer and missing ones. I've spent some time with this over the weekend. The conditions to re-produce the bug are slightly more involved, you need to mirror from more than one server to trigger the bug (as the original script does). --8<---cut here---start->8--- set xfer:clobber set http:cache off set mirror:parallel-directories on mirror -e --parallel=10 -c --delete-first --depth-first --use-cache \ --script=cygport.lftp \ http://ftp.gwdg.de/pub/linux/sources.redhat.com/cygwinports/x86/release/perl-Socket/ \ /home/cygwin/mirrortest/ & mirror -e --parallel=10 -c --delete-first --depth-first --use-cache \ --script=cygwin.lftp \ http://mirrors.kernel.org/sourceware/cygwin/x86/release/ucl/ \ /home/cygwin/mirrortest/ & wait all --8<---cut here---end--->8--- After a few false starts (due to an unrelated bug fixed in 147f4b1de6 that hides the target bug) I've bisected it down to f2f2bb91e4, which is unfortunately too large a change for me to make out what happens. I can't reproduce this on Linux. The lftp mailing list is seemingly down, so I've sent the bug report directly to the maintainer in the hope for a fix. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: gcc-4.8.2-2 (x86)
JonY <10walls gmail.com> writes: > 4.8.2-2 is a rebuilt of -1 with an additional --libexecdir=/usr/lib, > this should fix reports of spawn failures when called with /bon/gcc. This update breaks libquadmath0 because the library hasn't been uploaded correctly. 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: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
JonY writes: >> This update breaks libquadmath0 because the library hasn't been uploaded >> correctly. > > > OK, I see something called libquadmath0gcc-ada, my cygport file is broken. Thanks for looking into it. Meanwhile, the earlier libquadmath0 release works, but if someone is doing a fresh install, then any programs needing this library would require a manual install via "tar -C / -xf /..."since setup currently only sees the borked package in the wrong directory. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
Corinna Vinschen writes: > Does it make sense to remove the libquadmath0gcc-ada package entirely > for now? Yes, the whole libquadmath0gcc-ada directory including the files in it. Then setup.ini should have the 4.8.2-1 package version of libquadmath as current until it gets replaced with the -2 or -3 version. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)
JonY writes: > I just reuploaded -2 and deleted the stray libquadmath0gcc-ada. Both new > and existing users should not notice any big difference other than an > update. Thank you, it all works correctly now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: 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: Fwd: emacs-X11 memory problem after Windows update
Ken Brown writes: >> ***MEMORY-ERROR***: emacs[2924]: GSlice: failed to allocate 2040 bytes >> (alignment: 2048): Cannot allocate memory I'm seeing the same thing on Win7/64 Pro, both for 64bit and 32bit Cygwin. Since I don't normally use the X11 Emacs, unfortunately I don't know which update was introducing this, it used to worked OK a few weeks ago. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Fwd: emacs-X11 memory problem after Windows update
Ken Brown writes: > And do you also use Windows Defender? MSE (which I believe is just the "consumer" name for the same software). > If this isn't BLODA, I'm completely stumped. So far I've not had persistent problems with MSE (doesn't mean anything really… I know). Only when an application is newly installed you can get some more interference, but that usually goes away after the application has been run the first few times (or after running a full scan, which is awfully slow). The crash in 64bit is not very reproducible and I haven't been able to get it segfault in gdb, so there _is_ some racing involved I guess. On 32bit however it reproduces under gdb sometimes, but not always: --8<---cut here---start->8--- Reading symbols from /usr/bin/emacs-X11...Reading symbols from /usr/lib/debug/usr/bin/emacs-X11.exe.dbg...done. done. (gdb) run Starting program: /usr/bin/emacs-X11 [New Thread 6260.0x1c74] [New Thread 6260.0x2348] [New Thread 6260.0x20fc] [New Thread 6260.0x1ccc] [New Thread 6260.0x20d8] [New Thread 6260.0x1f9c] [New Thread 6260.0x2380] Program received signal SIGSEGV, Segmentation fault. _malloc_internal_nolock (size=, size@entry=4) at /usr/src/debug/emacs-24.3-2/src/gmalloc.c:744 744 next->next->prev = next->prev; (gdb) thr aplly all bt No symbol "aplly" in current context. (gdb) thr app all bt Thread 7 (Thread 6260.0x2380): #0 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #2 0x76c7149d in WaitForSingleObjectEx () from /cygdrive/c/windows/syswow64/KERNELBASE.dll #3 0x048c in ?? () #4 0x in ?? () Thread 6 (Thread 6260.0x1f9c): #0 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #2 0x76c7149d in WaitForSingleObjectEx () from /cygdrive/c/windows/syswow64/KERNELBASE.dll #3 0x0344 in ?? () #4 0x in ?? () Thread 5 (Thread 6260.0x20d8): #0 0x77ccf959 in ntdll!ZwRemoveIoCompletion () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77ccf959 in ntdll!ZwRemoveIoCompletion () from /cygdrive/c/windows/system32/ntdll.dll #2 0x71da635c in ?? () from /cygdrive/c/windows/SysWOW64/mswsock.dll #3 0x61005c5f in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=, func=0x0, arg=0x159d1a0, buf=0x3b9cdc4) at /usr/src/debug/cygwin-1.7.27-2/winsup/cygwin/cygtls.cc:100 #4 0x03b9cdc4 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 4 (Thread 6260.0x1ccc): #0 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77ccf8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/system32/ntdll.dll #2 0x76c7149d in WaitForSingleObjectEx () from /cygdrive/c/windows/syswow64/KERNELBASE.dll #3 0x02e0 in ?? () #4 0x in ?? () Thread 3 (Thread 6260.0x20fc): #0 0x77cd015d in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77cd015d in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/system32/ntdll.dll #2 0x77d02f91 in ntdll!RtlMoveMemory () from /cygdrive/c/windows/system32/ntdll.dll #3 0x0001 in ?? () #4 0x0001 in ?? () #5 0x in ?? () Thread 2 (Thread 6260.0x2348): #0 0x77ccf905 in ntdll!ZwReadFile () from /cygdrive/c/windows/system32/ntdll.dll #1 0x77ccf905 in ntdll!ZwReadFile () from /cygdrive/c/windows/system32/ntdll.dll #2 0x76c6dd54 in ReadFile () from /cygdrive/c/windows/syswow64/KERNELBASE.dll #3 0x0090 in ?? () #4 0x772f3ec7 in ReadFile () from /cygdrive/c/windows/syswow64/kernel32.dll #5 0x0090 in ?? () #6 0x610db6e8 in wait_sig () at /usr/src/debug/cygwin-1.7.27-2/winsup/cygwin/sigproc.cc:1214 #7 0x in ?? () Thread 1 (Thread 6260.0x1c74): #0 _malloc_internal_nolock (size=, size@entry=4) at /usr/src/debug/emacs-24.3-2/src/gmalloc.c:744 #1 0x00597478 in _realloc_internal_nolock (ptr=ptr@entry=0x88d98f80, size=size@entry=4) at /usr/src/debug/emacs-24.3-2/src/gmalloc.c:1432 #2 0x00597601 in _realloc_internal (ptr=0x88d98f80, size=4) at /usr/src/debug/emacs-24.3-2/src/gmalloc.c:1452 #3 0x61082cdd in realloc (p=0x88d98f80, size=4) at /usr/src/debug/cygwin-1.7.27-2/winsup/cygwin/malloc_wrapper.cc:73 #4 0x88d98f80 in ?? () #5 0x014e9c88 in _fraghead () #6 0x88d63b80 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) print next $1 = (struct list *) 0x88d886f0 (gdb) print next->prev $2 = (struct list *) 0x14e9c88 <_fraghead+40> --8<---cut here---end--->8--- IIRC I've had crashes like these (where GSlice complains about alignment) before on Linux when there was a mismatch between glib and some other library. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46
Re: [ANNOUNCEMENT] Updated: gcc-4.7.3-1
Am 17.12.2013 18:04, schrieb marco atzeri: in your ~/bin or /usr/local/bin ln -s /usr/bin/gcc gcc4 Actually, you will need to ln -s /usr/bin/gcc gcc-4.exe ln -s /usr/bin/g++ g++-4.exe or some build system checks using EXEEXT will produce quite unexpected results. (I have personally never needed gcc4, i.e. without the hyphen). -- Achim. (on the road :-) -- 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, new for 64-bit: lftp 4.4.11-1
Achim Gratz writes: > The lftp mailing list is seemingly down, so I've sent the bug report > directly to the maintainer in the hope for a fix. This bug has been fixed in release 4.4.14 of lftp. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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, new for 64-bit: lftp 4.4.11-1
Andrew Schulman writes: > Good. I'll get a new release out. The new package is good, albeit I haven't seen the announcement yet. Thank you. 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: Base 64-bit Cygwin now requires Perl?
Andrew Schulman writes: > lftp also has this problem. It comes with a few sample scripts, two of which > are in Perl. I include the sample scripts because why not, but cygport is now > quite diligent about finding this sort of thing, with the result that its > automatically-generated setup.hint now says that lftp depends on Perl. Which > is > annoying. The easiest solution (now that the package build is done by cygport and the upload done by yourself) is to split these into a sub-package. The main package stops being dependent on Perl and anybody else can get the scripts if they want to. 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: AdminCygwin Release
Tom Schutter writes: > 1) Modify cygwin_setup_config.bat to match your site requirements. > 2) Copy cygwin_setup.bat and cygwin_setup_config.bat to a target host. > 3) Run cygwin_setup.bat on the target host. > 4) Repeat 2 and 3 on your other hosts. I've been doing something very similar for a while now, with a few modifications that mainly have to do with the fact that I can't expect all hosts to have internet access and the requirement that an install, update or re-install must be possible by executing a single executable or script. At the moment I'm working from a full internal mirror, but the plan is to eventually download just those files that I will need to install directly from an external mirror. The required packages and the package repos are listed in a setup.conf file. This file has the information in which order the package sources should be considered when multiple repos offer the same package and finally the packages to install. You can also select test or prev versions on a per package basis or ignore named packages from a certain package source. You just need to list the top-level packages (or entire categories if wanted), dependencies are automatically pulled in. Packages can be grouped into new categories, one of which will later be used as the target for setup.exe to install (instead of listing the individual packages). From this I create a new setup.ini from the contents of all package repos with just those packages that I need. Lastly, all packages referenced by that setup.ini plus the install scripts are copied to a software repository that all clients on the network can access (it is also possible to put the whole thing on a USB stick or DVD). As in your scheme, since the actual install is done by setup.exe, the resulting installation is indistinguishable from a "normal" Cygwin and users familiar with setup.exe can modify package selections if they want to as they are used to. I consider this important and all the other methods, some of which have been discussed in this thread, either don't offer this possibility or require extra effort to maintain it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Reduce noise in dependency declaration during uninstall in setup.exe
Warren Young writes: > I've run into this after installing everything yesterday for my "size > of Cygwin" research project. Now I'm trying to remove most of that > piece by piece, but I keep getting tangled in dependency webs. In that case (and unrelated to the problem you noted with setup.exe) you might just look up which packages were installed since you've started that experiment (ls -lrt /etc/setup) and uninstall all of those past that date threshold. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: octave: cannot open shared object file: No such file or directory
Paul writes: > However, I recently started to get the following message when sending > expressions to octave: > >/usr/bin/octave-3.6.2.exe: error while loading shared libraries: ?: >cannot open shared object file: No such file or directory I'm almost certain that Octave can't find its lapack libraries. The standard profile scripts add this to the very end of the path and depending on what is in your windows path you may hide them. There are also two environment variables (sorry, can't check right now) that need to be set for lapack to be happy and you may not source the /etc/profile.d script that sets them depending on how you start bash. 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: setup.exe different packages
BGINFO4X writes: > I did it, and the results are diferent. Because you made it so. > I attach on the email both setup results: with commandline and with GUI. So you managed to trick setup into not installing some Base packages in the GUI. If you wouldn't have done that, you'd have installed the exact same packages in both cases (I've checked). > What I'm doing is trying to install ONLY bash, not the Base category, > so I think that you are wrong. You always have to have Base installed (which already includes bash). If you really want to create your own installer you'd first need to understand what setup.exe is doing and why. 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: Win32::Eventlog: Not found after upgrade
t-systems.com> writes: > Reinstalling perl/libwin32 didn't help. It would help, provided you actually installed the correct package perl-libwin32 at the current version 0.28-3. If you see something installed in vendor_perl/5.10, then it comes from an earlier version of that package. 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: setup.exe different packages
BGINFO4X kztsoftware.com> writes: > On my humble opinion, If I check ONLY bash with GUI, and I use the > command-line "setup-x86.exe -g -o --no-desktop --no-shortcuts > --no-startmenu --local-install %CYGWINALOCALPACKAGES% --quiet-mode > --root %CYGWINADMINDIR% --packages bash" both results should be the > same. They are, if you don't fiddle with a checkbox that you shouldn't be able to toggle in the first place. In other words it's a bug in the GUI that you are able to bypass the install of some Base packages. 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: setup.exe different packages
Chris J. Breisch breisch.org> writes: > No, I don't agree with that statement. I'd be more inclined to believe > that it's a bug in the command-line interface that doesn't allow you to > do what the GUI does. You can disagree all you want, the source of setup makes it pretty clear that all packages in category Base must always be installed, regardless of any other choices the user made. And that's in fact what the GUI does too (it goes through exactly the same code path), only that you're later able to deselect the "binary" package without setup checking for whether you do this on a Base package (note you can't uninstall or skip a Base package, so that you can defeat this via other means is the bug I was talking about). 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: [ANNOUNCEMENT] Updated: Cygwin 1.7.28-2
Luke Kendall cisra.canon.com.au> writes: > The 64 bit Cygwin distribution now has $num_pk_64 packages, compared > with $num_pk_32 in the 32 bit version. There are 3109 packages in x86 and 2833 in x86_64, for a total of 2491 common packages (present in both architectures) and 960 unique ones. 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: g77 on cygwin64
Scott T. Marshall writes: > The strange thing is that gfortran does compile the > code, but once compiled, the executables have strange behavior mainly > involving problems reading in data files. To me this rather indicates a bug in the code, probably involving bad assumptions about what can be be done to files and in which order. For starters you might check if the files are opened in binary mode. > So it is not clear to me > exactly what needs to be updated in the code. Big can of worms. I've seen old Fortran code break on seemingly unrelated things like a C library security update, not to say what happened when I first tried to run it on an Alpha. You might try if the program works correctly if compiled unoptimized. Another option is to purposefully use a compiler that does things in a very different way and see where it complains and/or breaks (I've been keeping f2c for that). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: get rid of getpwent?
Corinna Vinschen writes: > Caching is wonderful for the usual requests for single entries from the > DB, and for this we have already two caches, the LSA cache and Cygwin's > own cache. But caching doesn't help at all when enumerating. Would it be possible to only look (for user name completion purposes) at the current user plus whatever is in %SystemDrive%\Users plus whatever is found in /etc/passwd? That way no beans are spilled about domain users that couldn't be gleaned from the local file system and in almost all cases that's the list one would want to complete from anyway. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: 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: get rid of getpwent?
Corinna Vinschen writes: > Oh, hmm. Well, it might be possible, but somehow I'm not excited by the > idea. While it looks like getpwent is mostly used for this purpose, you > don't really know it. I think I'll try to implement it fully and then > let the admin decide what to allow. Configurable would be OK of course. I'm not sure when I'll get around to testing the new snapshot, but I can certainly try how long it takes when I do "~" in the shell. IIRC, mkpasswd took several minutes to pull down the domain accounts (I've then deleted all but the handful that was used for network shares). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: $PATH contains dot but unclear where it comes from
Cliff Hones writes: > So there is no dot at the end of PATH as seen in cmd - and (I assume, > since this was also discussed) no duplicated semicolons or trailing > semicolon at the end of the cmd PATH. But the very first PATH printed > by bash does contain a trailing dot. I assume this is before bash has > sourced any startup scripts - so where does it come from? This is actually from the first non-empty, non-comment line in /etc/profile, where the (converted) windows path is prepended with "/usr/local/bin:/usr/bin:". This suggests that the PATH as seen by bash starts life with that dot appended, but of course it would be more conclusive if the OP had shown the complete output (and maybe truncated the windows PATH variable for the experiment). Looking at the visible PATH it is quite likely that this variable is rather long and the rest of the environment may be quite large also. There are interesting problems when one or both of these get over a certain size – like for example Git, which is using environment variables quite extensively, stopping to work correctly without giving any useful error messages. It probably isn't the problem in this case, but the spaces and parens in the windows path also can become a problem when scripts aren't super careful with their quoting. 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: Maintainer for git?
Adam Dinwoodie writes: > I've tried this. I have `git cvsimport` seemingly working on the > current Git 1.7.9 build, while my build reports the following SHA1 > error: > > > $ CVSROOT=:pserver:anon...@cygwin.com:/cvs/src git cvsimport -C cygwin -r cvs > -k cygwin > Initialized empty Git repository in /home/Adam/vcs/cygwin/.git/ > fatal: refs/remotes/cvs/master: not a valid SHA1 > fatal: master: not a valid SHA1 > fatal: You are on a branch yet to be born > checkout failed: 32768 > I don't think that this error you see is related, but you absolutely need cvsps version 2 for cvsimport to work correctly (or at all). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > This is a pretty intrusive change, in need of some serious testing, so > I'd like to ask for volunteers. The latest 2014-02-13 snapshot from > http://cygwin.com/snapshots/ contains the changes, including the latest > bugfix. I've tested the 2014-02-19 snapshot at work. Two problems: 1. Running "id" takes 13 seconds to fetch my 440 group memberships (possibly there are some users that would be in ~10x as many groups). Caching doesn't seem to be effective for this since the next several invocations of "id" take the same time. During most of that time you actually can't ^C the process, lsass is growing a few dozen threads and seems to be talking to the DC. Falling back to use just the /etc files makes this work really fast (much faster than without the snapshot). 2. I use a few volumes on NetApp filers that have security set up so that you can't change attributes. That means POSIX permissions are always listed as "". I uausally mount these noacl, but when I access them via their UNC path (for instance when Windows runs a script from a CWD on that volume, then Perl reports false for file test operators (-x, -w) other than existence. Backing out the snapshot reverts to the previous behaviour of these test operators correctly determining that my effective rights (via normal and extended security attributes tied to a group memberships) are sufficient. The shell (bash, tcsh) test operators work correctly, but I don't know what Perl is doing differently. This is independent of whether I use just the /etc files or full AD lookup (switched via /etc/nsswitch.conf) and currently a showstopper for me. I've booby-trapped a few checks to always return true and the actual creation of directories and files then succeeds (as it has always done), but I can't just pull out every one of these from all scripts. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Testers needed: New passwd/group handling in Cygwin
Andrey Repin writes: > That seems like a bug elsewhere. Being able to change permissions shouldn't > restrict you from requesting them. There is no bug, not in Cygwin nor anywhere else. The standard file attributes are all cleared and since I can't set any of them (a policy which gets inherited) that stays for all files and directories that are created. Before you ask, I can't change any of that. > You can change that with cygdrive prefix options. That'd be a possible workaround, thanks. > Adjust your fstab line for it to include noacl, and operations on UNC paths > should run better, according to your setup. I'd rather want to know why the snapshot triggers such a change in behaviour and why the notion of the shells and Perl don't match. 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > The stuff in the `id' application is not cached at all. Caching is > inherited from the parent process, but the parent never asked for all > your groups so it hasn't cached this information. Every invocation of > id has to request the group info anew. OK, then I was misunderstanding what caching meant. I was operating under the assumption that there'd be something like a session cache that serves all Cygwin processes in the same process tree. > Do you have a very slow connection to your DC by any chance? I admit > that I never tested with 440 groups, only with about 30 or so, but 13 > seconds sounds *very* lame. That's around 33 lookups per second; not great, but also not bad (I'm far from the only user of that DC obviously). I'll have to check what our web application server is doing (albeit it uses a connection pool to amortize the connection overhead), but I don't think it'll do much more than about 200 peak. The answers can be insanely large depending on what and how you ask, too. In any case, based on the fact that I'm certainly not in as many groups as some other folks, I don't think I can drop file-based operation at the moment (which I really hoped I could). > OTOH, this isn't *quite* unexpected. Right now, the LDAP connection to > the DC is opened and closed for every single account request. I wasn't > sure yet if the ldap connection should be opened only once per process > and then stay open for the rest of the process lifetime. This sounds so > much like wasting sockets... See above, there's a timeout on each pooled connection, again I'll have to ask how long it is (I think somewhere in the single digits seconds range, we don't want to tie up the DC for too long). > The fact that the shells are doing it right seems to indicate that this > isn't a generic problem. I can't debug this, though. Can you see if > you can figure out what's going on under the hood? Does strace show > anything of interest? Can we perhaps set up some joint debugging via > private mail during the next couple of days? I can't dig further into this for the next two weeks. I need to get some work done, so I have rolled the snapshot back for now. I'll get back to you when this is out of the way, thanks for the offer. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: Testers needed: New passwd/group handling in Cygwin
> Sorry, I don't grok this. What has a web application server to do with > asking a DC for user info? We have one of these that does a lot of DC lookups because it authenticates all users. It's also in a much faster network, so I can check there what the lookup rate could be reasonably expected to be. > Erm... how often are you calling id, usually? I'm currently doing this in the login process to figure out whether the prompt should show "root" powers. I'll have to figure out something else to do instead. > Also, we're in the early > stages of testing this change. The idea is not that you just switch, > the idea is that we *test* this and I get enough feedback to be able to > ease the biggest pains. Understood. Until now I had to generate passwd and group files and I was hoping that the need for doing that would go away (I'd also need to talk to our AD folks so they start populating the correct fields). > Other than that, I just had an in-shower inspiration how to speed up > `id' specificially. The getgroups(2) call is in the center of this and > I could probably speed up the stuiff a lot by opening the LDAP > connection in getgroups only once. Thursday? :-) > Also, more radically, if we drop the functionality to define another > group name for a group, we could drop the requirement to open an LDAP > connection to fetch group information to the DC entirely(*). This would > only affect domain groups, local groups could still have different > names. But I'm already wondering for a couple of days if having a > Cygwin group name different from the Windows group name is really > necessary at all. I added this years ago for fun, but there's no > serious reason I can think of which would require to keep up with this. > > (*) Assuming the group info is cached in the local LSA, which is > pretty likely for the groups of the current user. That would also work for me (I don't think I've ever used that feature consciously). > Sigh. Testing in this tempo will take ages. Sorry, but that's not my decision to make in this case. I'll see if I can sneak in something until the end of the week. 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > I just created 400 groups in AD, and added myself as member. An `id' on > a 32 bit Windows 7 domain member machine in my tiny network consisting > only of a handful of Windows VMs and with me as the only real user takes > about 3.6 secs with the latest code from CVS, using a non-optimzed > Cygwin DLL. OK, so you do less than 200 lu/s even in that favorable case. Our DC is hit by some four figure number of clients I suppose. I've asked my colleague to check the lookup rate on our test web server and he also gets around 30 lu/s with caching disabled, just like I did via Cygwin. So the network speed isn't the limiting factor. > With this patch applied, the aforementioned `id' now takes about 1.9 > secs, in an otherwise identical scenario. Sounds interesting. > With this patch applied as well, `id' now takes constantly 0.4 secs. Gets even better… :-) > Note that this speedup is only possible when fetching lots of group > account information. For user accounts we still need the info from AD, > but apart from the getpwent functionality, which can be restricted via > the db_enum setting in /etc/nsswitch.conf, there's not very often a good > reason to fetch information for hundreds of user accounts. > > Anyway, if I send you the link to two DLLs with these patches, would you > mind to test their speed in your environment? Bring it on. I'd need 32bit DLL since I have to keep the 64bit Cygwin running on my machine. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: setup.exe bad signatures?
Michael Ryan writes: > I'm trying to verify the signatures on the latest setup.exe files and I'm > finding that they don't match: > > $ gpg --verify setup-x86.exe.sig > gpg: Signature made Fri 13 Dec 2013 17:24:37 GMT using DSA key ID 676041BA > gpg: BAD signature from "Cygwin " > $ gpg --verify setup-x86_64.exe.sig > gpg: Signature made Fri 13 Dec 2013 17:38:14 GMT using DSA key ID 676041BA > gpg: BAD signature from "Cygwin " > $ md5sum setup-x86* > 93ee19b4143133ec0d9462a27e5c92cb setup-x86_64.exe > 2f2d2a21916b164c9f844810ada0f5f5 setup-x86_64.exe.sig > 9b3e9b26fa040763f2673cc3dc0cf229 setup-x86.exe > 3afb815ce823e601f999de777ea72885 setup-x86.exe.sig > > Am I doing something wrong, or...? Probably not, those signatures are still referring to the previous setup.exe files if you believe the date. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: [...] > With this patch applied, the aforementioned `id' now takes about 1.9 > secs, in an otherwise identical scenario. [...] > With this patch applied as well, `id' now takes constantly 0.4 secs. > > Note that this speedup is only possible when fetching lots of group > account information. For user accounts we still need the info from AD, > but apart from the getpwent functionality, which can be restricted via > the db_enum setting in /etc/nsswitch.conf, there's not very often a good > reason to fetch information for hundreds of user accounts. > > Anyway, if I send you the link to two DLLs with these patches, would you > mind to test their speed in your environment? Thanks. I'm basically seeing the same with your DLL snapshots, plus the login times (each with an invocation of "id") are following suit. It also seems that our DC is a bit less loaded today. Here are the results of doing this: foreach p ( `seq 1 10` ) time id >/dev/null end "stock" 0.561u 0.514s 0:08.93 11.9% 0+0k 0+0io 7690pf+0w 0.499u 0.499s 0:09.04 10.8% 0+0k 0+0io 7717pf+0w 0.592u 0.686s 0:09.03 14.0% 0+0k 0+0io 7690pf+0w 0.639u 0.576s 0:09.18 13.0% 0+0k 0+0io 7698pf+0w 0.608u 0.390s 0:09.11 10.8% 0+0k 0+0io 7691pf+0w 0.577u 0.514s 0:09.03 11.9% 0+0k 0+0io 7048pf+0w 0.499u 0.468s 0:08.91 10.6% 0+0k 0+0io 7724pf+0w 0.498u 0.561s 0:08.84 11.8% 0+0k 0+0io 7744pf+0w 0.561u 0.405s 0:08.73 10.9% 0+0k 0+0io 6664pf+0w 0.452u 0.545s 0:08.96 11.0% 0+0k 0+0io 6968pf+0w "getgroups" 0.249u 0.202s 0:03.33 13.2% 0+0k 0+0io 3506pf+0w 0.234u 0.296s 0:03.33 15.6% 0+0k 0+0io 3489pf+0w 0.171u 0.296s 0:03.26 14.1% 0+0k 0+0io 3493pf+0w 0.171u 0.265s 0:03.25 13.2% 0+0k 0+0io 3486pf+0w 0.156u 0.358s 0:03.33 15.0% 0+0k 0+0io 3486pf+0w 0.171u 0.265s 0:03.29 13.0% 0+0k 0+0io 3487pf+0w 0.311u 0.373s 0:03.46 19.6% 0+0k 0+0io 3506pf+0w 0.171u 0.217s 0:03.27 11.6% 0+0k 0+0io 3488pf+0w 0.234u 0.202s 0:03.36 12.7% 0+0k 0+0io 3491pf+0w 0.218u 0.202s 0:03.42 11.9% 0+0k 0+0io 3487pf+0w "noldap" 0.249u 0.202s 0:03.33 13.2% 0+0k 0+0io 3506pf+0w 0.234u 0.296s 0:03.33 15.6% 0+0k 0+0io 3489pf+0w 0.171u 0.296s 0:03.26 14.1% 0+0k 0+0io 3493pf+0w 0.171u 0.265s 0:03.25 13.2% 0+0k 0+0io 3486pf+0w 0.156u 0.358s 0:03.33 15.0% 0+0k 0+0io 3486pf+0w 0.171u 0.265s 0:03.29 13.0% 0+0k 0+0io 3487pf+0w 0.311u 0.373s 0:03.46 19.6% 0+0k 0+0io 3506pf+0w 0.171u 0.217s 0:03.27 11.6% 0+0k 0+0io 3488pf+0w 0.234u 0.202s 0:03.36 12.7% 0+0k 0+0io 3491pf+0w 0.218u 0.202s 0:03.42 11.9% 0+0k 0+0io 3487pf+0w Best 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: Testers needed: New passwd/group handling in Cygwin
Achim Gratz writes: > "noldap" Sorry, copied the "getgroups" data again, this is the data for "noldap" of course: 0.171u 0.015s 0:01.03 17.4% 0+0k 0+0io 3298pf+0w 0.093u 0.140s 0:00.97 23.7% 0+0k 0+0io 3292pf+0w 0.046u 0.093s 0:00.97 13.4% 0+0k 0+0io 3285pf+0w 0.062u 0.140s 0:00.97 20.6% 0+0k 0+0io 3283pf+0w 0.031u 0.124s 0:00.97 15.4% 0+0k 0+0io 3285pf+0w 0.093u 0.077s 0:00.99 16.1% 0+0k 0+0io 3291pf+0w 0.093u 0.077s 0:00.96 16.6% 0+0k 0+0io 3298pf+0w 0.015u 0.077s 0:00.97 8.2% 0+0k 0+0io 3291pf+0w 0.093u 0.108s 0:00.99 19.1% 0+0k 0+0io 3300pf+0w 0.062u 0.109s 0:00.97 16.4% 0+0k 0+0io 3294pf+0w 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > 1 second? That sounds still a bit slow. Considering that I'm now > member of 414 groups, and you are member of 440 groups, the extra number > of groups cannot account for that. > > This sounds surprisingly as if the > names of some of your groups are not cached on your machine. Or > something. Or is this a rather slow machine?!? It's not a slow machine by any means, but it certainly gets its fair share of security policies, so it may have something to do with that. I don't know. > Still, it seems like the right thing to do to drop the group name > configuration stuff entirely. Yes (unless you'd want to make it configurable like the getpwent stuff). 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > 1 second? That sounds still a bit slow. It appears that that there are multiple DC involved, either via delegation or redirection (as I've managed to get some partial group resolutions where groups from a particular domain were absent). So all this slowness probably has to do with roundtrip times. Based on that hypothesis I've done the same test again via DSL/VPN and got this: 1:49 stock-cvs 1:15 getgroups 0:13 noldap The times don't change all that much whether I've clogged the DSL connection or not, so the size of the response doesn't seem to be a major factor here. > Still, it seems like the right thing to do to drop the group name > configuration stuff entirely. Indeed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > It allows you to do the following in /etc/nsswitch.conf: > > db_cache: no Using the 15:31 snapshot DLL again via VPN, id dumps core after about 2:30 minutes. > No caching of passwd and group data at all > > db_cache: yes Startup of a shell in mintty takes about 20 seconds, each id around 10...13s. > Caching of passwd and group data, no initial caching of the user's > supplementary groups from the user token. > > db_cache: full Startup in around 10seconds, each id takes a third of a second. > This is the default now. A good choice, I'd say. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > How? Details? Stackdump? It works for me(TM). The timing only shows > that it's not the right thing for you, or that in the long run the > non-caching option should just go away. For the time being, though, I > need *details*. Sorry, that's the best I can do at the moment. > Hang on. Are you telling me this snapshot takes longer than the > snapshot from yesterday? And you're telling me that normal caching, as > was the default all the time, is slower in startup than with the > additional caching of groups at startup? Is your startup procedure > calling `id' twice by any chance? I've been using the network via VPN, and measured the numbers with the previous DLL(s) before testing the snapshot, results are in a different reply. > The problem with your numbers is that I have nothing really to compare > it with. It would be helpful to know what you're doing, the essential > parts of your startup for instance. I'm on my way to catch a plane, sorry this will be in about a week. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > The fact that the shells are doing it right seems to indicate that this > isn't a generic problem. I can't debug this, though. Can you see if > you can figure out what's going on under the hood? Does strace show > anything of interest? Can we perhaps set up some joint debugging via > private mail during the next couple of days? Perl goes through stat64 that seems to explicitly check the ACL while sh uses a different codepath. I don't see anything obviously wrong with either trace. If I set up cygdrive to use the noacl option the problem goes away, apparently because the ACL check never takes place within stat64. 869 2501512 [main] perl 2604 stat64: entering 814 2502326 [main] perl 2604 normalize_posix_path: src x86 802 2503128 [main] perl 2604 cwdstuff::get: posix /cygdrive/x/install 1195 2504323 [main] perl 2604 cwdstuff::get: (/cygdrive/x/install) = cwdstuff::get (0x8008, 32768, 1, 0), errno 0 810 2505133 [main] perl 2604 normalize_posix_path: /cygdrive/x/install/x86 = normalize_posix_path (x86) 1195 2506328 [main] perl 2604 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/x/install/x86) 810 2507138 [main] perl 2604 mount_info::cygdrive_win32_path: src '/cygdrive/x/install/x86', dst 'X:\install\x86' 837 2507975 [main] perl 2604 set_flags: flags: binary (0x2) 810 2508785 [main] perl 2604 mount_info::conv_to_win32_path: src_path /cygdrive/x/install/x86, dst X:\install\x86, flags 0x4022, rc 0 3329 2512114 [main] perl 2604 symlink_info::check: 0x0 = NtCreateFile (\??\X:\install\x86) 2816 2514930 [main] perl 2604 symlink_info::check: not a symlink 845 2515775 [main] perl 2604 symlink_info::check: 0 = symlink.check(X:\install\x86, 0x289888) (0x404022) 839 2516614 [main] perl 2604 path_conv::check: this->path(X:\install\x86), has_acls(1) 828 2517442 [main] perl 2604 build_fh_pc: fh 0x612DD5A0, dev 00C3 816 2518258 [main] perl 2604 stat_worker: (\??\X:\install\x86, 0x800390D0, 0x612DD5A0), file_attributes 16 1603 2519861 [main] perl 2604 cygpsid::debug_print: get_sids_info: owner SID = S-1-5-21-2052111302-842925246-682003330-75441 818 2520679 [main] perl 2604 cygpsid::debug_print: get_sids_info: group SID = S-1-5-21-2052111302-842925246-682003330-513 818 2521497 [main] perl 2604 get_info_from_sd: ACL 0x4000, uid 75441, gid 10513 875 2522372 [main] perl 2604 fhandler_base::fstat_helper: 0 = fstat (\??\X:\install\x86, 0x800390D0) st_size=0, st_mode=0x4000, st_ino=-197262732544 4575109st_atim=531DE525.1B5BB150 st_ctim=530C5D84.1F71B690 st_mtim=52D570D0.251FE418 st_birthtim=51EFE5A9.12BDBAC0 1424 1978515 [main] sh 4736 normalize_posix_path: src x86 882 1979397 [main] sh 4736 cwdstuff::get: posix /cygdrive/x/install 918 1980315 [main] sh 4736 cwdstuff::get: (/cygdrive/x/install) = cwdstuff::get (0x2008, 32768, 1, 0), errno 0 1647 1981962 [main] sh 4736 normalize_posix_path: /cygdrive/x/install/x86 = normalize_posix_path (x86) 1218 1983180 [main] sh 4736 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/x/install/x86) 932 1984112 [main] sh 4736 mount_info::cygdrive_win32_path: src '/cygdrive/x/install/x86', dst 'X:\install\x86' 2389 1986501 [main] sh 4736 set_flags: flags: binary (0x2) 1221 1987722 [main] sh 4736 mount_info::conv_to_win32_path: src_path /cygdrive/x/install/x86, dst X:\install\x86, flags 0x4022, rc 0 4069 1991791 [main] sh 4736 symlink_info::check: 0x0 = NtCreateFile (\??\X:\install\x86) 2709 1994500 [main] sh 4736 symlink_info::check: not a symlink 985 1995485 [main] sh 4736 symlink_info::check: 0 = symlink.check(X:\install\x86, 0x289408) (0x404022) 946 1996431 [main] sh 4736 path_conv::check: this->path(X:\install\x86), has_acls(1) 947 1997378 [main] sh 4736 build_fh_pc: fh 0x612DD8D8, dev 00C3 1935 1999313 [main] sh 4736 check_file_access: flags 0x2, ret 0 971 2000284 [main] sh 4736 fhandler_base::fhaccess: returning 0 1526 2001810 [main] sh 4736 euidaccess: returning 0 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: >> (\??\X:\install\x86, 0x800390D0) st_size=0, st_mode=0x4000, >> st_ino=-197262732544 > ^^ > This is the important snippet, but I don't see how this could have been > different before my patches. The mode is S_IFDIR and 000 permissions. I've run the same on Cygwin64 (where I don't use the snapshot yet) and it does indeed produce the same line. It still correctly determines that I do have permission to change into (and write in) the directory, but I don't know how. > That usually means: > > - The owner of the file, here S-1-5-21-2052111302-842925246-682003330-75441, > has no ACCESS_ALLOWED_ACE in the ACL, or the owner has no FILE_READ_DATA, > FILE_WRITE_DATA, and FILE_EXECUTE permissions on the file. > > - The group of the file, here S-1-5-21-2052111302-842925246-682003330-513 > (Domain Users, apparently) has no ACCESS_ALLOWED_ACE in the ACL, or > the owner has no FILE_READ_DATA, FILE_WRITE_DATA, and FILE_EXECUTE > permissions on the file. > > - The Everyone group S-1-1-0 has no ACCESS_ALLOWED_ACE in the ACL, or > the owner has no FILE_READ_DATA, FILE_WRITE_DATA, and FILE_EXECUTE > permissions on the file. > > This stuff is entirely independent of the new passwd/group code, unless > the owner and group are Samba Unix Users/Groups (S-1-22-[...]), in which > case I made some changes in this area on 2014-02-27. The owner is me and the primary group is indeed Domain Users. As I said, the whole share (a NetApp filer) is set up to not forbid access to anyone except via extended security settings that enable access for a certain AD group (and administrative access for another). These settings are forced upon all new files via inheritance, plus if I managed to change this (there was such a loophole once, but it likely has been closed) there'd be a script to periodically remove all extra permissions. The owner and groups are not Samba Unix as far as I can tell. > The uid and gid values point to the fact that you're still using a > passwd and group file. How are your /etc/nsswitch.conf settings and > does switching to db-only make a difference? The same test without an /etc/passwd file produces a different uid (the original one in /etc/passwd was actually 85441 and I just changed it to see where it came from), I haven't yet checked if the nsswitch.conf settings make a difference. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen writes: > In that case the stat call is very likely unrelated. There must be some > other call involved in perl. IIRC, the next call is the write that prints "no" or "yes"... there may have been something like "stat_helper" inbetween only on Cygwin64, but I'll have to check again tomorrow. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Testers needed: New passwd/group handling in Cygwin
Achim Gratz nexgo.de> writes: > IIRC, the next call is the write that prints "no" or "yes"... there may > have been something like "stat_helper" inbetween only on Cygwin64, but > I'll have to check again tomorrow. It's a call to stat_worker with the UNC file path and the stat_worker handle, both times returning zero. There is only one interesting difference between the release and the snapshot DLL, they are reporting the atime to be different: st_atim=531DE525.1B5BB150 (release) st_atim=531DF887.5D9B9F8 (snapshot) Whatever differences there are probably inside stat_worker, but I don't really know. I've just found out that cygcheck cuts off the group listing after exactly 16kiB. Maybe there are some other places where it's now possible to overrun some buffer (pwdgrp::fetch_account_from_windows has got all of them according top the trace) or maybe some other limit for the number of groups? The group that grants access is number 293 in the list as returned by id... I've also found that two trusted domains aren't returning an entry for cyg_ldap::fetch_posix_offset_for_domain from the DC I'm assigned to, so that probably explains the long startup times I've been seeing with earlier snapshots. Maybe of interest: 987 1803457 [main] perl 6856 alloc_sd: uid 1124017, gid 10513, attribute 0x2190 860 1804317 [main] perl 6856 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-2052111302-842925246-682003330-75441 (+) 877 1805194 [main] perl 6856 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-2052111302-842925246-682003330-513 (+) 827 1806021 [main] perl 6856 alloc_sd: ACL-Size: 124 934 1806955 [main] perl 6856 alloc_sd: Created SD-Size: 200 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > > st_atim=531DE525.1B5BB150 (release) > > st_atim=531DF887.5D9B9F8 (snapshot) > > Access time. On Windows it even changes when requesting certain > kinds of metadata :-P It's been consistent over many days of testing and the only difference between release and snapshot, so I thought I'd mention it. > But the question is, does perl actually use that list? The strace > snippets don't show anything here. If it doesn't use the access(2) > call, it would have to load the full ACL of the file and match that > against your token group list. This requires calls to getgroups (which > would create the litany of group SIDs from fetch_account_from_windows) > and acl. It's pretty unlikely that perl would do this manually. Not that I can see, it simply seems to call stat64, which it did before. I don't think it drops any groups, either. And again, just mounting cygdrive with "noacl" gets rid of the problem entirely. > You're still using a group file? I think yes, I hadn't moved it away (but no passwd file). > Anyway, I need the full straces. It's pretty hard to say anything, let > alone isolate at least the most probable cause without them. Can you > please run the simple examples under the 2014-03-09 snapshot and send > URLs to the snapshots? I've just updated to the latest snapshot w/o AD integration for testing, will revert to the other one for more testing. Not sure if I can fit that in today, will send the links via PM when I have the traces uploaded. 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: New snapshots are from the 1.7.29 branch. That means...
Christopher Faylor cygwin.com> writes: > The snapshots page is incorrectly listing every snapshot as coming from > the branch. Sigh. I'll fix this. The 2013-03-09 snapshot also doesn't appear to have the AD integration code. 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > You don't have to move them away. Just set nsswitch.conf. Did that and using the snapshot DLL from 2014-03-05 on top of a full snapshot install from 2014-03-10. The ACL is this: # file: x86 # owner: gratz # group: Domain Users user::--- group::--- group:admin-cygwinupload:rwx group:user-cygwinupload:rwx mask:rwx other:--- default:user::--- default:group::--- default:group:admin-cygwinupload:rwx default:group:user-cygwinupload:rwx default:mask:rwx default:other:--- With the original passwd and group file in place and nsswitch.conf set to either "files" or "files db" the test fails. With just "files" getfacl doesn't show the group ACL at all, while with "files db" I see the ACL for both the admin and the user group (both are not in the group file). Setting to just "db" the ACL is shown as before and the test from Perl now succeeds! In fact any combination that includes "files" fails. So, after some head scratching I changed the uid and gid in the passwd and group files to match the new mapping scheme and lo and behold the test is now working. The getfacl command starts to show the group ACL when I add them to the group file (with the correct gid mapping), but the test still fails with "files" only. With the correct group entries and "files db", the test also works. So, Perl somehow uses the gid/uid mapping and relies on those to be working, while bash uses a code path that doesn't and probably just uses the uid/gid directly. I guess I could make the "files" only case work by adding some more groups (no time for checking what that might be at the moment), again changing the mapping (will mkpasswd do this at some point?). Do you still need traces or does get you a test case that works in your environment? 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: New snapshots are from the 1.7.29 branch. That means...
Christopher Faylor cygwin.com> writes: > You're responding to a heads up which was intended to *inform* you of > this fact. > > The snapshot does not have Corinna's new code. How is that unclear? The original message was posted when a 2014-03-10 snapshot (with AD integration) already existed and was replaced with one that doesn't. The website shows only that snapshot as being from the release branch. The 2013-03-09 snapshot was never explicitly mentioned in the original posting and is not shown on the webpage as being from the release branch (which it apparently is). More clear now? 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > > With the original passwd and group file in place and nsswitch.conf set to > > either "files" or "files db" the test fails. With just "files" getfacl > > doesn't show the group ACL at all, > > How does it look with any non-AD integrated Cygwin? ... doesn't show the group ACL until I add them to the group file. That part is consistent with the AD enabled snapshot. Actually... if I create a group file with those two groups added, the access again doesn't get granted. Which finally reveals that I also need to have the administrators group present in that file (which mkpasswd had been doing) -- then it works. I can even leave out the two ACL groups again and it still works. > Hmm. So you're saying that the groups in question are not in > /etc/groups, but it works with the non-AD Cygwin but not with the > AD-Cygwin? Exactly. But as revealed above, what was really missing is the Administrators group. Somehow, when "files" is in effect, that mapping doesn't seem to exist unless it is explicitly listed in the file. It does get auto-created when I use _only_ the "db". I hope that somehow makes sense... > > So, Perl somehow uses the gid/uid mapping and relies on those to be working, No, it seems to balk on not being able to map the Administrator group (which is my egid). 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: Testers needed: New passwd/group handling in Cygwin
Achim Gratz NexGo.DE> writes: > Exactly. But as revealed above, what was really missing is the > Administrators group. Somehow, when "files" is in effect, that mapping > doesn't seem to exist unless it is explicitly listed in the file. It does > get auto-created when I use _only_ the "db". I hope that somehow makes sense... I guess it does: the mapping that gets created from AD is sometimes 1049120 instead of 544. That depends on the settings in nsswitch.conf and whether an /etc/group file exists at all or contains an entry for Administrators. I guess that once this behaviour is stable (and maps to 544 in every case) the problem that Perl is having also goes away. 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: File permissions when using ACLs
Charles Plager writes: > * Anybody else experience files that lose all permissions? Any > suggestions on resetting the file (short of reformatting the drive)? Ahem. Yes, that has happened once to me. I don't know how the IT guys fixed it exactly, but they eventually deleted that file without formatting the disk or rebooting the server. The process starts with (recursively) taking ownership of said file or directory and then re-enabling the right to delete, IIRC. I've been using "noacl" mount option for that particular server ever since (also because it is slow enough as is and gets slower still when using ACL). > * Any other hints/insights that might be useful here? Not really, except that concurrent access to other files in the same directory seemed to be involved. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Cygwin64 ignoring /etc/passwd shell field?
Corinna Vinschen writes: > Thanks for finding this one! Unfortunately David has left us, > apparently. Isn't it that a bit too short a time to come to this conclusion? > Is anybody willing to take over maintainership of the base-files > package? Seeing that I have additional patches that David didn't apply to the test version, I could do that. But let's confirm first that he's not just having a vacation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > Ok, so, here's the question. Is your primaryGroupID in AD 544? If not, > you will have to explain to me how this happens. I have found no other > way to reproduce this. My primary group ID in AD is 513 (Domain Users), just as shown by id, I am not member of the Administrators group and I only have effective group membership when running from an elevated prompt (which I'm allowed to get to via another group membership and a group policy that's totally unrelated to the well-known Administrators group). I have no idea what happens either, none of the traces even contain a check for Administrators group or a recognizable ID. All I know is that when the mapping for Administrators group is not 544, then the test fails. Anyway, I've run out of time for the moment, I'll try to set up a clean test environment later. This whole business of various settings in nsswitch.conf and entries in passwd/group is creating a combinatorial explosion that I'm not sure how to manage yet. Then, I'll have to sanitize the traces, which will require a script if it's more than two or three. 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: Cygwin64 ignoring /etc/passwd shell field?
Chris J. Breisch writes: >> Chris, Achim, please figure out who's going to maintain the package. >> If you like, you can even do this together. >> > I'm willing to defer to Achim, since he already has some patches, but > I'm flexible. So let me try to roll a test package this weekend. I will not try to move out PATH setting from /etc/profile as requested by Andrey (I'm not sure that would even work, per the comments in the file). I can add /etc/shells to base-files if Chuck can synchronize a re-packaged inetutils without it. I'll have a look into the postinstall issues that Corinna mentioned. Other than that, is there something else not yet mentioned in this thread that needs to be taken care of? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: Latest snapshot will become Cygwin 1.7.29
Christopher Faylor cygwin.com> writes: > Unless there is an identified regression, the latest snapshot > is very close to becoming Cygwin version 1.7.29. The 32bit version (2014-03-29 21:21:42 UTC x86) seems to have at least the portion of the AD code active that relates to the numerical GID bumping (this only happens when the nsswitch.conf file exists, which I thought should not have any effect without AD integration): groups=1049089(passwd/group_GID_clash(1049089/10513)) I've removed the nsswitch.conf file that I had installed for the AD testing and this issue goes away (I haven't tried to change the settings in the file, they were "files db", sorry). There is no such problem with the 64bit version, with or without having an nsswitch.conf file present. 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
[ANNOUNCEMENT] Update: upx-3.91
Achim Gratz writes: > UPX has been updated to version 3.91 for both x86 and x86_64 > architectures. This version includes experimental support for Win32/PE+ > 64bit binaries. Additionally, this build uses LZMA SDK version 9.22, > which is marked beta since 2011. > > For this reason, the release is currently marked test/experimental and > has to be selected manually in setup.exe. Please test with your > applications and report the results to the Cygwin mailing list to help > gain the confidence to eventually make this release current. Thank you. This package has been promoted from test to current. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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
[ANNOUNCEMENT] Updated: gmp-6.0.0a
GNU Multiple Precision Arithmetic Library = GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no practical limit to the precision except the ones implied by the available memory in the machine GMP runs on. GMP has a rich set of functions, and the functions have a regular interface. Version 6.0.0a is an upstream release fully binary and ABI compatible with the 5.x version and including all bugfixes up to version 5.1.3, which was the latest release in the 5.x line. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
[ANNOUNCEMENT] Updated: mpclib-1.0.2
MPC Multiprecision Library == The GNU MPC library is a C library for multiple-precision complex floating-point computations with exact rounding (also called correct rounding). It is based on the GMP and MPFR multiple-precision libraries. Version 1.0.2 is an upstream bugfix release. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Possibly wrong address passed to callq asm instruction within MPIR test binaries
Jean-Pierre Flori writes: > The problem we recently encountered was the following: > in gmp-impl.h, mpn_store (which can be either a macro or a function if > efficient assembly is available, and so is always a function on x86_64) > was not marked __declspec(dllexport/dllimport). I can confirm that GMP has the same problem when I patch out these attributes (which I wanted to do because these cause lots of spurious warnings during compilation). This works fine on 32bit, but produces segmentation faults in some (not all) 64bit test binaries. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
[ANNOUNCEMENT] Updated: base-files 4.2-1
Base-files is a set of system configuration and setup files. Maintenance has been taken over from David Sastre Medina. Thanks to David for his work since the 3.0 release. Please report any problems or suggestions on the main Cygwin mailing list. Changes from the last release version: 4.2-1 * remove permission/ACL settings and corresponding files. see cygwin.com/ml/cygwin-apps/2014-03/msg00011.html 4.1-3 (unreleased) * Eliminate Windows PATH from default PATH if CYGWIN_NOWINPATH is set. Record the Windows PATH in ORIGINAL_PATH unless that variable is already set. * Better guard for non-existent /etc/skel. * Improve profile_d function. cygwin.com/ml/cygwin/2012-08/msg00488.html * Add /etc/shells. cygwin.com/ml/cygwin/2014-03/msg00039.html * Use full path for tools and avoid DOS file warning when creating service files. cygwin.com/ml/cygwin/2013-07/msg00114.html 4.1-2 (test release) * Enforce a secure ACL in /home /tmp /usr/tmp /var/log /var/run using new files /etc/profile.d/1777fix.* written by Corinna Vinschen. See cygwin.com/ml/cygwin/2012-03/msg00103.html * Setting CYG_SYS_BASHRC in bash.bashrc has no effect because it is run in a subshell environment. Reported by Christian Franke. See cygwin.com/ml/cygwin/2012-02/msg00832.html Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Compiling Heimdal
Henry S. Thompson writes: > Maybe same question -- acronym failure: BR ? Build Requirement. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: [PATCH] base-files-4.2-1: Change prompt if running with admin rights
Christian Franke writes: > Attached is an updated version of: > https://sourceware.org/ml/cygwin/2012-02/msg00806.html I'll put this on hold until the AD integration has landed in Cygwin (which will require some larger changes anyway). Generally I'd prefer to move such things that depend on personal preferences like setting up prompts into profile.d where they are easier to change and maintain independently from core system functionality. Using the registry to check for administrative privileges is clever, however I'm wondering why we shouldn't simply check via id (that's what I'm doing personally at the moment). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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: Compiling Heimdal
Corinna Vinschen cygwin.com> writes: > I'm wondering, though, couldn't the cygport script contain something > like this to give warning that the so-and-so devel packages are required > before building? Does cygport support this already, perhaps, and I just > missed it? Yes it can check for prerequisites and either warn or throw an error, but you have to put that test into the cygport file by hand. 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: Compiling Heimdal
Corinna Vinschen cygwin.com> writes: > Skimming the cygport manual, I just can't find the keyword to specify > the build reqs. That would be the "Checks" section, note that you need to check for the presence of specific headers, libs, programs or package configs (as well as language / interpreter specific modules) and not Cygwin packages as they might not be present during bootstrapping. Nothing prevents you from pointing to the Cygwin package in the error message or running cygcheck to specifically test for installed packages, though. 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: [PATCH] base-files-4.2-1: Change prompt if running with admin rights
Corinna Vinschen writes: > But even without /etc/group, the administrator's group will have the > gid 544. I think such a test should be sufficient? That's what I've been using for quite some time and I guess that's the right thing to check for. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Compiling Heimdal
Ken Brown writes: > Actually I think what you're looking for is "DEPEND" > (/usr/share/doc/cygport/manual.html#robo821). I've stopped using this one since it doesn't tell you which of the potentially many dependencies failed and it just stops the compilation cold. The individual check_* functions aren't any more complicated to use and you can be a bit more lenient with certain errors if you want. That said, if its simply a single dependency or two it msy not matter much. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: 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: Still testing needed: New passwd/group AD/SAM integration
Corinna Vinschen writes: > * cygserver now provides system-wide passwd/group entry caching. > > All processes started *after* cygserver will try to fetch passwd > and group entries from cygserver. While this is probably a bit > slow at the start, the longer cygserver runs, the more information > is present and later started processes will get the information > with all due speed. Does this mean there is no caching without cygserver running? > * Support for Cygwin user names different from the Windows username. This one always seemed a bit odd to me. The only use I could think up is if your Windows username contains non-ASCII or spaces and you'd want to avoid dealing with that within Cygwin. > * db_separator in /etc/nsswitch.conf I can't see a pressing need for configurable separators here. Domain users are probably already accustomed to seeing Domain\User, so that'd be a natural default unless somebody had a pretty good reason for something different. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Fatal error from Cygwin emacs-w32 every day or so
Ken Brown writes: > You might have to run emacs under gdb and put a breakpoint at > emacs_abort in order to get a useful backtrace. But I'm not sure it's > worth putting a lot of effort into debugging emacs-24.3 at this point, > because emacs-24.4 is already in its pretest phase. I'm traveling > right now, but when I return in about a week I'll build the current > pretest version for you to try. I see these crashes on a regular basis (the few times I've managed to attach gdb to this Emacs instance I've not got any useful backtraces except that it was always crashing in a timer triggered function). I'm waiting for 24.4 myself to see if this resolves itself. In the meantime I'm just running Emacs from a Cygwin32 instance, that never crashes for me. > One other question: Can you find a way to reproduce the problem, or > does it just seem to happen randomly? If I had a reproducer, you'd have it by now. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: Fatal error from Cygwin emacs-w32 every day or so
KARR, DAVID writes: > I just saw it die, and this is the bt I get: Try "thread apply all bt". Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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: Trouble with running cygwin dll on Vortex86MX+ CPU
Peter A. Castro fruitbat.org> writes: > I've just built a newer version of upx (and ucl, etc) and now I will start > archiving setup, x86 & x86_64, (again). Need to update my webpage > automation to generate an access list, but atleast I'm grabbing and > archiving them (again). Not that I want to discourage you from building those yourself, but I should perhaps mention that these packages are current for both Cygwin32 and Cygwin64. 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: Trouble with running cygwin dll on Vortex86MX+ CPU
Peter A. Castro writes: > Ah. You are making the assumption I'm running my little project > (Cygwin Time Machine) on Windows? No. This is run on a Linux server > I use (heresy, I know :-), mostly using automated scripts and cron > jobs. I just wanted to avoid folks asking for those "new" versions on Cygwin when they are already here. I certainly didn't want to suggest you do or should run your server on Windows. :-) > When I tried this years ago, it didn't compile and I didn't have time to > persue it. But the recent versions of upx (and ucl) both compile & run > just fine. Yes, it just builds out-of-the-box now. All software should do that! Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: 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: Wow, just hit RCS bug
tedno...@bellsouth.net writes: > Just for the record, the suggested env var fix > > RCS_MEM_LIMIT=0 > > to "force stdio" does not work for me, but the That was never suggested as a fix, but to show that the problem occurs with files much less than 256kiB size when forcing the code path through stdio (which is what the "0" setting does). The RCS test suite passes on Cygwin since it never actively tests this code path. http://thread.gmane.org/gmane.os.cygwin/142346 > RCS_MEM_LIMIT=10240 > > to allow 10megs of diffs does.. Which will fail once you happen upon a diff that gets that large. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: problem reproducing perl-Error build
Eric Blake redhat.com> writes: > cygwin warning: > MS-DOS style path detected: \Users\Administrator > Preferred POSIX equivalent is: /cygdrive/c/Users/Administrator > CYGWIN environment variable option "nodosfilewarning" turns off this > warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > Created MYMETA.yml and MYMETA.json > Creating new 'Build' script for 'Error' version '0.17019' > Module::Build version 0.39 required--this is only version 0.38 at Build > line 41. > *** ERROR: Module::Build build failed > > This raises several questions: > > 1. What is going wrong in cygport and/or perl's Module::Build that is > triggering the nodosfile warning? You need a newer Module::Build (I'm currently at 0.4205). If you build this version of Error you'll also find that it fails the test suite... > 2. How did someone else (Yaakov?) build the 64-bit package? Why is it > not reproducible using self-hosted stock cygwin? The dependencies don't care about versions unfortunately. > 3. Any chance the perl Module::Build shipped in cygwin perl can be > bumped to a newer version? ==8<= _ml="PAR::Dist" inform " Build of perl-Module-Build requires" inform " $_ml" for _m in $_ml; do check_perl_module $_m || warning " Perl module $_m is missing from build environment." done if ! check_perl_module $_ml; then error " At least one required perl module is missing." fi NAME="perl-Module-Build" VERSION="0.4205" RELEASE="1" CPAN_AUTHOR="LEONT" DESCRIPTION="Perl distribution Module-Build, providing Perl modules: Module::Build Module::Build::Base Module::Build::Compat Module::Build::Config Module::Build::Cookbook Module::Build::Dumper Module::Build::ModuleInfo Module::Build::Notes Module::Build::PPMMaker Module::Build::Platform::Default Module::Build::Platform::MacOS Module::Build::Platform::Unix Module::Build::Platform::VMS Module::Build::Platform::VOS Module::Build::Platform::Windows Module::Build::Platform::aix Module::Build::Platform::cygwin Module::Build::Platform::darwin Module::Build::Platform::os2 Module::Build::PodParser Module::Build::Version Module::Build::YAML inc::latest inc::latest::private. Build and install Perl modules." DIFF_EXCLUDES="MYMETA.*" inherit perl ==>8= 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: Wow, just hit RCS bug (attn: Dr Volker Zell)
Warren Young etr-usa.com> writes: > It's not a bug, it's a buffer size choice made with the rcs 5.8 release, > which affects Cygwin for reasons unknown. It is a bug in the "stdio" code path, independently of buffer size. That bug doesn't trigger on GNU/Linux, btw. > I built 5.9.2 under Cygwin with default build options, and it > successfully runs a test script that fails under the current Cygwin rcs, > which was posted by Don Hatch when this problem came up here 6 months > ago: http://cygwin.com/ml/cygwin/2013-10/msg00086.html Make sure you test the stdio code path, if they changed the sematics of RCS_MEM_LIMIT again, then you may need a different demonstrator to switch to stdio from the usual mmap code path. 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: Wow, just hit RCS bug (attn: Dr Volker Zell)
Achim Gratz NexGo.DE> writes: > Make sure you test the stdio code path, if they changed the sematics of > RCS_MEM_LIMIT again, then you may need a different demonstrator to switch to > stdio from the usual mmap code path. For grins I just built RCS 5.9.2, fixed a bug in the btdt program so it wouldn't infloop and ran the test suite. It still passes with all code paths. The demonstrator from Don Hatch still fails if I force the stdio code path, as it did with the 5.8.x versions. So the only way to have RCS not mangle those files still is to make sure it never falls back to RM_STDIO. 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: problem reproducing perl-Error build
Eric Blake writes: >> You need a newer Module::Build (I'm currently at 0.4205). If you build this >> version of Error you'll also find that it fails the test suite... > > Which version of Error - reproducing the 0.17019 shipped in 64-bit > cygwin, or the latest 0.17022 available upstream? The 0.17019 version as shipped with Cygwin64 fails the test suite (but otherwise works fine for me); I didn't look why exactly it does this. The current version 0.17022 passes all tests once you've installed a new enough Module::Build. I recommend you use App::cpanminus to bootstrap the build dependencies. > I guess I should come out and state this: > > I have no vested interest in maintaining the perl-Error package. It is > my only 'inherit perl' package, and I originally packaged as a > pre-requisite of being able to package git; but now that someone else is > planning on adopting git (although the progress on that front has been > glacially slow), I'm more than willing to put perl-Error up for adoption > for anyone else to manage, that is more likely to know how to resolve > the issues that I ran into. Is this something you'd like to adopt? If Reini can be persuaded to unbundle perl_vendor into it's constituent distributions, then yes. Otherwise I'd have to maintain another build environment just for this and change many things in my build process; I simply don't have the time to do this at the moment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: How LANG environment variable is set?
Larry Hall (Cygwin cygwin.com> writes: > Good catch. Yes, the latest version of base_files makes this change to > the profile_d() function. Looks like the easiest interim solution is to > downgrade to base_files-4.1-2. The easiest interim solution is probably to unset LC_ALL or revert to _LC_SAVE_ if set in lang.sh -- I'll have to think about this some more, but that's probably the solution I'll use for the bugfix release as well (I should manage to get it out over the weekend). See http://cygwin.com/ml/cygwin/2012-08/msg00489.html and the discussion leading up to it. This just goes to show that nobody tested the test version that was out there for almost two years. 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: GIT
Corinna Vinschen writes: >> > > >Yeah, I'm not exactly looking forward to it since I'm very familiar >> > > >with CVS or SVN, but have nothing but trouble with git. But since >> > > >everybody else is so very happy with git, I guess I'll have to adapt. >> > > >Teeth-gnashingly. > > Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/ My recommendation for newcomers to Git would be to take any not-too-large Git repository(*) and work out a few dozen ways of breaking it; then freshly clone it to start over once you've thoroughly messed it up. Once you've done that a few times and maybe know how to recover from a few less catastrophic sins (like resetting to where you didn't want to be and then finding out where the former branch head was), you should have a good base for deciding what kind of workflow works for you and Git alike. The thing that Git gets right is that it's incredibly cheap to make yet another clone or branch for when you want to try something even remotely risky. (*) http://repo.or.cz/r/cygwin-setup.git perhaps? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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
