1.7.32: bind-utils-x86_64 commands can't redirect output on Win8.1 64bit
Windows 8.1 64bit setup.exe 2.850 bind-utils 9.9.6-2 9.9.5-3 Run this: dig www.google.com | cat Expected: the output of dig But was: empty and the same empty result for: * dig www.google.com > test.txt ; cat test.txt * a=$(dig www.google.com) ; echo $a Other commands in bind-utils (nslookup, host) have the same empty result, while their 32bit version works just fine (on Windows 8.1 64bit). Other 64bit package works fine, for example openssl, curl, etc. So I think probably there is a bug in bind-utils. Thanks henix -- 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] TEST RELEASE: Cygwin 1.7.33-0.2
On Oct 26 03:38, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > > For your convenience I wrote new documentation. Since this is a TEST > > prerelease, the new documentation is not part of the official docs yet. > > Rather have a look at > > > https://cygwin.com/preliminary-ntsec.html > > The "asks for a group with gidNumbe attribute" lost an "r" somewhere out > there. Fixed, thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpO8Q6qWhcKQ.pgp Description: PGP signature
Re: [ANNOUNCEMENT] New package: windows-default-manifest-6.4-1
On Oct 25 17:33, Andrew Schulman wrote: > > This package contains nothing but a default application compatibility > > manifest, which gets linked in by GCC by default, and which is supposed > > to claim compatibility with the latest Windows versions available at the > > time. > > > > Adding such a manifest got necessary due to a change in Windows 8.1. On > > earlier OS versions, applications without manifest were treated as > > compatible with the current OS. Starting with Windows 8.1, an > > executable without manifest is treated as being compatible only with the > > oldest supported OS version of the OS compatibility layer. > > > > That means, all applications without manifest are running in a Window > > Vista compatibility layer on Windows 8.1. This affects all Cygwin > > executables to date. By adding the default manifest to newly built > > packages, we're slowly getting to run our executables with full OS > > compatibility. > > I'm sorry, can you please remind me: Is there anything I have to do to > include the new manifest? Or is it enough just to rebuild the executable > once this package is installed? Just rebuilding is sufficient. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0WvH1xyXgY.pgp Description: PGP signature
Re: FW: bind-utils stdout pipe broken Cygwin x86_64 1.7.32+
On 2014-10-24 09:41, Jon Retting wrote: Sorry to report, but it would seem the new Cygwin versions break "bind-utils 9.9.5-3 -- 9.9.6-2" ability to stdout stdin. Tested on: CYGWIN_NT-6.1 1.7.32 - 1.7.33(0.278/5/3) 2014-10-22 10:37 x86_64 Cygwin (w2k8r2) CYGWIN_NT-6.3 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin (2012r2) I just can´t seem to do anything with host or dig´s output. Thanks for reporting. This doesn't happen on my Win7 system, but I was able to reproduce it on 2012R2. The bug is actually elsewhere, and we are attempting to track it down. Yaakov -- 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: Threads
On 10/24/2014 9:52 AM, Corinna Vinschen wrote: On Oct 24 14:54, Corinna Vinschen wrote: On Oct 24 12:05, Jon TURNEY wrote: On 23/10/2014 16:37, Corinna Vinschen wrote: On Oct 23 08:04, Ken Brown wrote: Yes, flags register corruption is exactly what Eli suggested in the other bug report I cited. The aforementioned patch was supposed to fix this problem and it is definitely in the current 1.7.32 release... I didn't mean to suggest otherwise, just that perhaps a similar problem exists now. So I made the attached test case to explore that. Maybe I've made an obvious mistake with it, but on the face of it, it seems to demonstrate something... jon@tambora / $ gcc signal-stress.c -Wall -O0 -g jon@tambora / $ ./a failed: 2144210386 isn't equal to 2144210386, apparently So it checks i and j for equality, fails, and then comes up with "42 isn't equal to 42"? This is weird... Note there is some odd load dependency. For me, it works fine when it's the only thing running, but when I start up something CPU intensive, it often fails... That's... interesting. I wonder if that only occurs in multi-core or multi-CPU environments. The fact that i and j are not the same when testing, but then are the same when printf is called looks like a out-of-order execution problem. Is it possible that we have to add CPU memory barriers to the sigdelayed function to avoid stuff like this? I discussed this with my college Kai Tietz (many thanks to him from here), and we came up with a problem in sigdelayed in the 64 bit case: pushf is called *after* aligning the stack with andq. This alignment potentially changes the CPU flag values so the restored flags are potentially not the flags when entering sigdelayed. I just applied a patch and created new snapshots on https://cygwin.com/snapshots/ I couldn't reprocude the problem locally, so I'd be grateful if you could test if that fixes the problem in your testcase, Jon. I tried Jon's testcase. With cygwin-1.7.33-0.1, it failed within a few minutes. With cygwin-1.7.33-0.2, I ran it for over an hour with no problem, with the system heavily loaded. So it looks good so far. Ken, can you check if this snapshot helps emacs along, too? The people who have been reporting frequent crashes are aware of the fix. Now I just have to wait and hope I don't hear from them for a few days. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Threads
Ken Brown wrote: The people who have been reporting frequent crashes are aware of the fix. Now I just have to wait and hope I don't hear from them for a few days. Just for the record... Both with the snapshot and test releases, the issues in building Emacs I had after the migration from Xp+Cygwin32 to W7+Cygwin64 are gone. Now it seems I can build/bootstrap Emacs trunk always at the first attempt, before I had to try at least 10-15 times... I hope that the Ken's "hunt" is over... :) Many thanks to Ken (and _Mum_, obviously...), Angelo. -- 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] TEST RELEASE: Cygwin 1.7.33-0.2
Corinna Vinschen wrote: For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html It seem s that many links in that page don't work: they gives "404 Page not found". For example: 'mount' in "...is controlled by the mount option..." 'the section called “Mapping Windows accounts to POSIX' 'https://cygwin.com/ntsec.html#ntsec-files' and so on.. Ciao, Angelo. -- 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] TEST RELEASE: Cygwin 1.7.33-0.2
Greetings, Angelo Graziosi! > Corinna Vinschen wrote: >> For your convenience I wrote new documentation. Since this is a TEST >> prerelease, the new documentation is not part of the official docs yet. >> Rather have a look at >> >> https://cygwin.com/preliminary-ntsec.html > It seem s that many links in that page don't work: they gives "404 Page > not found". > For example: > 'mount' in "...is controlled by the mount option..." > 'the section called �Mapping Windows accounts to POSIX' > 'https://cygwin.com/ntsec.html#ntsec-files' > and so on.. When the page is moved up to it's place, the links will be proper. https://cygwin.com/preliminary-ntsec.html#ntsec-files P.S. I would appreciate, if you teach your mail cleint to insert proper threading headers to the list replies. -- WBR, Andrey Repin (anrdae...@yandex.ru) 26.10.2014, <22:46> Sorry for my terrible english... -- 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: cygclang.dll breaks terminal output when used in Python bindings
> I was able to fix the problem by installing the libncurses-devel package and > recompiling LLVM/Clang. Should libncurses-devel be a dependency of libclang > or is there another way to fix this problem? I must have been confused about which version I was compiling when I wrote this. libncurses doesn't seem to make a difference. I was able to solve the problem using --enable-terminfo=no for the configure script or -DLLVM_ENABLE_TERMINFO=OFF with cmake which I tested on three different computers. Now the question is: should that option be set when compiling libclang for distribution with Cygwin? -- 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] TEST RELEASE: Cygwin 1.7.33-0.2
Il 26/10/2014 20:47, Andrey Repin ha scritto: P.S. I would appreciate, if you teach your mail cleint to insert proper threading headers to the list replies. I would appreciate, if you avoid to send me your replays. I read the list even if I haven't subscribed it... You should avoid also to put yourself in each thread.. -- 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: Threads
On 10/26/2014 9:20 AM, Angelo Graziosi wrote: Ken Brown wrote: The people who have been reporting frequent crashes are aware of the fix. Now I just have to wait and hope I don't hear from them for a few days. Just for the record... Both with the snapshot and test releases, the issues in building Emacs I had after the migration from Xp+Cygwin32 to W7+Cygwin64 are gone. Now it seems I can build/bootstrap Emacs trunk always at the first attempt, before I had to try at least 10-15 times... That's very good news! I hope that the Ken's "hunt" is over... :) Me too. It will be a big relief. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On 24/10/14 21:37, Corinna Vinschen wrote: > On Oct 24 17:35, Luke Kendall wrote: >> On 24/10/14 02:43, Corinna Vinschen wrote: >>> On Oct 22 20:57, Tom Schutter wrote: On Wed 2014-10-22 11:23, Corinna Vinschen wrote: > For your convenience I wrote new documentation. Since this is a TEST [snip] > > > 'Logon SIDs: The own[huh? owner's? user's?] LogonSid is converted' > > The logon SID of the current session. I rephrased this now to: > > "Logon SIDs: The LogonSid of the current user's session is converted ..." > That's clear. >> 'if the AD administrators chose an unreasonable[unreasonably] small' >> >> 'which keeps an analogue value of the trustPosixOffset' >> --> >> 'which keeps an analog of the trustPosixOffset' > > British vs. American English... Sure, and I thought you'd prefer the American, but I'm happy to see British spelling. But the main point was to drop the word "value". "A is an analog of B", not an analog /value/ of B. > > >> 'how do we uniquely differ[distinguish] between them by name?' >> >> 'very costly (read: slow) sea[r]ch operations' >> >> (By the way, if you want to belong to multiple groups, is the only way to do >> this via an /etc/group file? > > You mean via the gr_mem field? That's not evaluated anymore. Group > membership is stored in SAM or AD. No, I was just wondering: does AD allow you to be in multiple groups? It must, I suppose. (It was an idle question, not really on the subject of the documentation.) > > >> Also, it occurs to me that another way to >> store the unix home dir, etc., would be a 'partial passwd' file that omitted >> the fields for the parts supplied easily by AD (SID, GID)? That's just an >> idle thought.) > > But that means you have to read the files again. Thre's not much of an > advantage to having full passwd and group files then for the user, nor > for Cygwin itself. Plus, you have to implement two different reading > algos per file type. True. Forget it, dumb idea. > >> 'Cygwin process tree, which[ever?] first process' > > Hmm. Sounds bad, right? Um, awkward and not quite clear, yes. > What I'm trying to say is, if the first > process of a process tree found cygserver isn't started, it will not try > to ask cygserver again, and it will propagate the lack of cygserver to > the child processes, so they will neither try to contact cygserver. If > you have a catchy way to phrase this in less words, I'd be quite happy. > > Btw. > > In the document I'm talking of the "first process of a Cygwin process > tree" throughout. Is it clear at all what that means? I think your description is reasonably clear. > For a Cygwin > Terminal session that would be the mintty process. If you have this: > > Cygwin process 1 starts Cygwin process 2 > Cygwin process 2 starts CMD.EXE > CMD.EXE starts Cygwin process 3 > Cygwin process 3 starts Cygwin process 4 > > Then you have two Cygwin process trees with Cygwin process 1 and > Cygwin process 3 being the "first processes in a Cygwin process tree". > > Is there a better way to phrase this in English? Would it make more > sense to use "parent" or "grandparent" for the first process? Or > any other expression? Hmm. Well, you open the section by saying: "The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child processes." What about if you said: "The information fetched (from file or from the Windows account database), is cached by the first process in the process tree. This cached information is inherited by every child process." A little later you say: "If cygserver is running it will provide passwd and group entry caching for all processes in a Cygwin process tree, which first process has been started after cygserver." Maybe: "If cygserver is running, it will provide passwd and group entry caching for all processes in every Cygwin process tree started after cygserver." But what I hadn't realised until I read your reply, above, was that if you're not running cygserver, that if a Cygwin process is started from a Windows command in a Cygwin process tree, that new Cygwin process is the root of a new Cygwin process tree. I wonder if the opening sentence should therefore say something like: "The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child /Cygwin/ processes. (A Cygwin process invoked from a Windows command, such as CMD.exe, will start a fresh process tree unless /cygserver/ is running.)" BTW, you could say "root of the process tree", but "root" tends to get confused with (superuser) root quite easily, so care would be needed. I think "first process" is pretty clear. >> 'If both[,] files and db are specified' > > There is a comma already. Or am I looking into the wrong line? Sorry, I was too terse: the comma should be removed: "If both files and db are specified..." > >
Re: [REQUEST] Please upgrade irssi (0.8.17)
I use irssi and consider it a really good IRC client. An update would be nice when the maintainer has the interest and the time. Keith On Sat, Oct 25, 2014 at 11:59 PM, Alive wrote: > On 10/26/2014 2:23 AM, Marco Atzeri wrote: >> On 10/25/2014 8:35 PM, Alive wrote: >>> Does anyone use irssi on cygwin? >>> >>> It seems that irssi package is never upgraded. >>> >>> Latest version is 0.8.17. It released on Oct 11 and still no package >>> upgrade after two weeks (skipping 0.8.16 which is missed a long way ago). >>> >>> I don't expect irssi package maintainers to abandon their duty and be >>> irresponsible after volunteering themselves as package maintainers. >> >> cool down, please. "irresponsible" is a strong comment. >> >> irssi was not upgraded upstream for years so probably >> it is not on top of Kostya's list, assuming he has >> spare time to dedicate and he is still around. >> >> Regards >> Marco > > Apologize for my rudeness. > > My point here is for Cygwin packages to catch up with upstream releases, > if possible make it as fast as how Archlinux adopts a new upstream > release, so that Cygwin users will benefit from developments done by > upstream. > > I think it's a good idea to keep Cygwin packages in sync with upstream > release. > > To achieve it, package maintainers should have a way to know as soon as > a new upstream release is available, such as subscribing to the upstream > mailing list for a new package release announcement. > > By doing this, they can make a test package as soon as a new upstream > release is available and release the package after test package has been > free of serious bug. > > > -- > 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 > -- 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] TEST RELEASE: Cygwin 1.7.33-0.1
Corinna Vinschen wrote:
On Oct 25 13:10, Corinna Vinschen wrote:
On Oct 24 23:17, Denis Excoffier wrote:
2014-10-24 22:16, Christian Franke wrote:
Another possible solution:
Check for e.g. CYGWIN_DLLPATH environment variable before calling
SetDllDirectory().
If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
else if set to ".", do nothing.
else call SetDllDirectory(CYGWIN_DLLPATH);
The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the
Makefile will
do the job.
Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a
real search path in CYGWIN_DLLPATH.
Also perhaps you can use yet another subitem in the CYGWIN environment variable?
If AddDllDirectory works without much hassle, which I have to test first,
why introduce CYGWIN_DLLPATH or another CYGWIN item?
LD_LIBRARY_PATH would be the one we want then, wouldn't it?
One really big problem with AddDllDirectory is this: While you can add
multiple directories to the search path, the order in which these
directories are added does not specify a search order. In fact, the
order in which the paths are searched is unspecified per MSDN.
In Denis example that means, if we add /usr/bin and /my/dir/bin to the
DLL search path, Denis case works or it doesn't, and we never know when
it will work and when it won't, and we have no way to influence this.
Oh boy.
Apart from SetDllDirectory and AddDllDirectory, what about this very
simple solution in Cygwin:
- Don't call SetDllDirectory at all, thus "." is kept in the search
path.
- In execve, when creating the Windows environment for the child process,
check if $PATH is empty. If so, set $PATH to /bin for the child.
Or, check if /bin is in $PATH, if not, add it.
That would catch both problems, backward compatibility with Denis
scenario, as well as the PATH setting in postfix.
OK for me. For postfix, the '$PATH is empty' check would be sufficient.
Christian
--
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
