Re: [ANNOUNCEMENT] Updated: OpenSSH-7.4p1-1
Hi, On Tue, Dec 20, 2016 at 9:44 PM, Corinna Vinschen wrote: > I've just updated the Cygwin version of OpenSSH to 7.4p1-1. > > This is primarily an upstream bugfix release. > > Below's the original release message. [...] > * ssh(1): Add a proxy multiplexing mode to ssh(1) inspired by the >version in PuTTY by Simon Tatham. This allows a multiplexing >client to communicate with the master process using a subset of >the SSH packet and channels protocol over a Unix-domain socket, >with the main process acting as a proxy that translates channel >IDs, etc. This allows multiplexing mode to run on systems that >lack file- descriptor passing (used by current multiplexing >code) and potentially, in conjunction with Unix-domain socket >forwarding, with the client and multiplexing master process on >different machines. Multiplexing proxy mode may be invoked using >"ssh -O proxy ..." Looks like this could be used for connection multiplexing on Cygwin. Since it doesn't seem to be documented I am not sure how one can test it, but ... with Host * ControlMaster auto ControlPath ~/.ssh/master-%r@%h:%p latte ~ > ssh i10z.com mux_client_request_session: read from master failed: Connection reset by peer Failed to connect to new control master --> Fails as expected, lets retry. latte ~ > ssh i10z.com mux_client_request_session: read from master failed: Connection reset by peer ControlSocket /home/ismail/.ssh/master-ism...@i10z.com:22 already exists, disabling multiplexing Welcome to Ubuntu 16.10 (GNU/Linux 4.8.0-30-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support:https://ubuntu.com/advantage Last login: Tue Dec 20 23:42:56 2016 from 2a02:810d:8ac0:a3c:de8:1380:f2c2:bc79 --> Started a new session and created the master too. latte ~ > ssh -O proxy i10z.com Welcome to Ubuntu 16.10 (GNU/Linux 4.8.0-30-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support:https://ubuntu.com/advantage Last login: Tue Dec 20 23:43:02 2016 from 2a02:810d:8ac0:a3c:de8:1380:f2c2:bc79 --> Started a new session. latte ~ > ssh -O proxy i10z.com Last login: Tue Dec 20 23:43:06 2016 from 2a02:810d:8ac0:a3c:de8:1380:f2c2:bc79 --> Voila, it used the existing connection! And after that it indeed seems to be using the old connection as long as you specify -O proxy option. Something to play with I guess. Regards, ismail -- 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 setup.exe not code-signed?
Hello, On Thu, Dec 15, 2016 at 2:58 AM, Kal Sze wrote: > Hello, > > It looks like the new setup-x86_64.exe is not code-signed? Is that on > purpose? IIRC, the previous versions were code-signed. Do we now only > rely on the .sig signature file to verify it? It was never code signed and the reasons for this has been discussed before. You can search the list for the reasons. Regards, ismail -- 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: nm for .exe extensions?
Hi, On Tue, Jun 7, 2016 at 7:12 PM, Corinna Vinschen wrote: > On Jun 7 08:43, Bill Smith wrote: >> Warren Young-2 wrote >> > On May 24, 2016, at 6:43 AM, Benjamin Cao < >> >> > becao@ >> >> > > wrote: >> >> >> >> The executable, when run with nm in Cygwin, results in a "no symbols" >> >> result, whereas it generates a symbol table in unix. >> > >> > That’s not what I see here. Given hello.c containing a “Hello, world!” >> > program: >> > >> > $ make hello >> > cc hello.c -o hello >> > $ nm hello.exe | wc -l >> > 389 >> > >> > If I strip the exe, I get “No symbols,” as expected. There’s no reason a >> > finished executable should have much in the way of exported symbols >> > without debug info, since it is self-contained. You would only expect to >> > get useful output from nm on a stripped binary if it’s an object file or a >> > DLL. >> >> Hi, I'm picking this issue up from my colleague, Ben Cao. We're using >> Visual Studio C++ to compile the executables/objects. Is the issue that >> Visual Studio places the information in the .pdb file? That's why nm >> doesn't display any info on an *.exe ? > > PDB is an undocumented and potentially patent-encumbered format, that's > why the binutils tools can't read or write it. This will hopefully be no longer true in the future: https://github.com/Microsoft/microsoft-pdb ismail -- 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: Deterministic builds
Hi,
On Wed, May 4, 2016 at 4:38 PM, Ken Brown wrote:
> Is it possible to build an executable on Cygwin so that subsequent builds
> (with no change in source) produce identical results? Currently, the
> timestamp embedded in executables prevents this. (I don't know if that's
> the only obstacle.)
>
> For example:
>
> $ cat hello.c
> #include
> int
> main ()
> {
> printf("Hello, world!\n");
> return 0;
> }
>
> $ gcc hello.c -o hello1
>
> $ gcc hello.c -o hello2
>
> $ objdump -p hello1.exe | grep Time/Date
> Time/Date Wed May 4 09:20:24 2016
>
> $ objdump -p hello2.exe | grep Time/Date
> Time/Date Wed May 4 09:20:29 2016
You can easily disable this feature:
latte ~ > gcc -Wl,--no-insert-timestamp hello.c
latte ~ > objdump -p a.exe | grep Time/Date
Time/Date Thu Jan 1 03:31:53 1970
latte ~ > gcc -Wl,--no-insert-timestamp hello.c
latte ~ > objdump -p a.exe | grep Time/Date
Time/Date Thu Jan 1 03:31:53 1970
--
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: mutt-1.6.1-1
On Mon, May 2, 2016 at 11:03 AM, Marco Atzeri wrote: > New version 1.6.1-1 of > > mutt > > is available in the Cygwin distribution: > > CYGWIN CHANGES > Replaced ncurse with slang binding. > As requested on ML > https://cygwin.com/ml/cygwin/2016-04/msg00103.html Thanks a lot! -- 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
[Attn. tmux maintainer] tmux 2.2 is out
And packs a lot of nice changes including 24bit color support: https://raw.githubusercontent.com/tmux/tmux/master/CHANGES -- 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: mutt-1.6.0-1
On Wed, Apr 6, 2016 at 3:15 PM, Ismail Donmez wrote:
> Hi,
>
> On Wed, Apr 6, 2016 at 1:42 PM, Marco Atzeri wrote:
>> On 06/04/2016 11:32, Ismail Donmez wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri
>>> wrote:
>>>>
>>>> A counter example:
>>>>
>>>> http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html
>>>>
>>>> try and let me know
>>>
>>>
>>> I am not using a mutt colorscheme but a mintty one which mutt fails to
>>> render. I will, however, try the change but a quote from the page
>>>
>>> "The solution is to replace a lot of the very specific color
>>> specifications of the colorscheme by the value default. "
>>>
>>> This proves the point that mutt is unable to use 256-color specifications.
>>>
>>> Thanks,
>>> Ismail
>>
>>
>> ncurse can handle 256 color.
>> I doubt that mutt is different from other programs.
>>
>>
>> which TERM variable are you using ?
>>
>> $ TERM="xterm"
>> $ tput colors
>> 8
>>
>> $ TERM="xterm-256color"
>> $ tput colors
>> 256
>
> My TERM is also xterm-256color but however that won't matter because
> looking at mutt-1.6.0/color.c
>
> I see:
>
> #ifdef USE_SLANG_CURSES
> static char *get_color_name (char *dest, size_t destlen, int val)
> {
> static const char * const missing[3] = {"brown", "lightgray", "default"};
> int i;
> [...]
> #endif
>
> and similar functions. So looks like "some" color functionality
> depends on slang.
So, can we enable slang dependency now?
Thanks,
Ismail
--
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: mutt-1.6.0-1
Hi,
On Wed, Apr 6, 2016 at 1:42 PM, Marco Atzeri wrote:
> On 06/04/2016 11:32, Ismail Donmez wrote:
>>
>> Hi,
>>
>> On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri
>> wrote:
>>>
>>> A counter example:
>>>
>>> http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html
>>>
>>> try and let me know
>>
>>
>> I am not using a mutt colorscheme but a mintty one which mutt fails to
>> render. I will, however, try the change but a quote from the page
>>
>> "The solution is to replace a lot of the very specific color
>> specifications of the colorscheme by the value default. "
>>
>> This proves the point that mutt is unable to use 256-color specifications.
>>
>> Thanks,
>> Ismail
>
>
> ncurse can handle 256 color.
> I doubt that mutt is different from other programs.
>
>
> which TERM variable are you using ?
>
> $ TERM="xterm"
> $ tput colors
> 8
>
> $ TERM="xterm-256color"
> $ tput colors
> 256
My TERM is also xterm-256color but however that won't matter because
looking at mutt-1.6.0/color.c
I see:
#ifdef USE_SLANG_CURSES
static char *get_color_name (char *dest, size_t destlen, int val)
{
static const char * const missing[3] = {"brown", "lightgray", "default"};
int i;
[...]
#endif
and similar functions. So looks like "some" color functionality
depends on slang.
Regards,
ismail
--
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: mutt-1.6.0-1
Hi, On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri wrote: > A counter example: > http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html > > try and let me know I am not using a mutt colorscheme but a mintty one which mutt fails to render. I will, however, try the change but a quote from the page "The solution is to replace a lot of the very specific color specifications of the colorscheme by the value default. " This proves the point that mutt is unable to use 256-color specifications. Thanks, Ismail -- 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: mutt-1.6.0-1
On Wed, Apr 6, 2016 at 11:59 AM, Marco Atzeri wrote: > > > On 05/04/2016 18:35, Ismail Donmez wrote: >> >> Hi, >> >> On Tue, Apr 5, 2016 at 6:03 PM, Marco Atzeri >> wrote: >>> >>> New versions 1.6.0-1 of >>> >>>mutt >>> >>> is available in the Cygwin distribution: >>> >>> CHANGES >>> Last upstream release. First 1.6.x >> >> >> Thanks for the update! Could you maybe build it with slang? That way >> mutt can support 256 colors. >> >> Regards, >> ismail >> >> -- > > > I don't find anything in the mutt documentation that says > that 256 color requires slang. > Have you some reference ? Yes, https://superuser.com/questions/695867/not-able-to-use-solarized-in-mutt I have the same problem and compiling mutt against slang fixes the issue. Thanks. -- 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: mutt-1.6.0-1
Hi, On Tue, Apr 5, 2016 at 6:03 PM, Marco Atzeri wrote: > New versions 1.6.0-1 of > > mutt > > is available in the Cygwin distribution: > > CHANGES > Last upstream release. First 1.6.x Thanks for the update! Could you maybe build it with slang? That way mutt can support 256 colors. Regards, ismail -- 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 2.5.0-0.11
Hi, On Tue, Apr 5, 2016 at 12:29 AM, Yaakov Selkowitz wrote: > Hi Cygwin friends and users, > > > Corinna just released a new Cygwin TEST version 2.5.0-0.11. > > If things are not going very wrong, this is basically what you'll > get as 2.5.0-1 release (really, we mean it this time). Please, please test > and report regressions. This results in a very interesting regression for me. Running zsh in login mode with zsh --login fails and turns out that it hangs at /etc/zprofile line 56 which basically says: USER="$(/usr/bin/id -un)" I tried running the same command under zsh (without login mode) and fair enough it works fine, so I went ahead and commented that line and it now hangs at line 145: HOSTNAME="$(/usr/bin/hostname)" and well it seems that running any subcommand inside a zsh script seems to hang. I confirmed this with a script of mine which hung at a "cat" command. Reverting back to cygwin1-20160330.dll did fix the issue for me. This is on Win7 x64. Thanks, ismail -- 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: clang copy of limits.h misses NAME_MAX
Hi,
On Thu, Mar 17, 2016 at 3:11 PM, Hans-Bernhard Bröker
wrote:
> Hello there,
>
> clang has its own copy of some system headers. One of those lacks an entry
> that breaks compilation of any program trying to work with directories the
> POSIX way:
>
> $ cat tdirent.c
> #include
>
> void foo(void)
> {
> return;
> }
>
> $ clang -c tdirent.c
> In file included from tdirent.c:1:
> In file included from /usr/include/dirent.h:6:
> /usr/include/sys/dirent.h:31:15: error: use of undeclared identifier
> 'NAME_MAX'
> char d_name[NAME_MAX + 1];
> ^
> 1 error generated.
>
> The same file compiles just fine with GCC. The problem turns out to be that
> NAME_MAX is defined in as seen by GCC, but not in the same header
> read by clang. The culprit is this file:
>
> $ cygcheck -f /usr/lib/clang/3.7.1/include/limits.h
> libclang3.7-3.7.1-1
clangs limits.h has:
#if __STDC_HOSTED__ && __has_include_next()
#include_next
#endif
So it does depend on system's own limits.h which should have this
definition. And cygwin's /usr/include/limits.h does have NAME_MAX
defined but show its being hidden. Checking the preprocessed source
file might help to see why.
ismail
--
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: clang copy of limits.h misses NAME_MAX
On Thu, Mar 17, 2016 at 3:35 PM, Marco Atzeri wrote: > it seems to prefer gcc headers > > # 1 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 1 3 4 > # 37 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 3 4 > # 1 "/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/limits.h" 1 3 4 > # 38 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 2 3 4 > # 17 "/usr/include/sys/dirent.h" 2 3 4 I am looking at clang 3.7 headers on Linux so this might be not 100% same on Cygwin but, clang's limits.h has this on top: /* The system's limits.h may, in turn, try to #include_next GCC's limits.h. Avert this #include_next madness. */ #if defined __GNUC__ && !defined _GCC_LIMITS_H_ #define _GCC_LIMITS_H_ #endif which should prevent including gcc's own limits.h but looks like it doesn't. ismail -- 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
[attention p7zip maintainer] p7zip 15.14 is out
This version syncs code with 7zip 15.14 and adds the fix for CVE-2015-1038. Regards, ismail -- 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: [Attn] git maintainer: Remote Code Execution for git < 2.7.1
Hi, On Wed, Mar 16, 2016 at 12:50 PM, Adam Dinwoodie wrote: > On Wed, Mar 16, 2016 at 07:43:54AM +0200, Ismail Donmez wrote: >> Please see http://www.openwall.com/lists/oss-security/2016/03/15/5 . >> Would be nice to update to just released 2.7.3 version. > > Ack, thanks for the heads up. I've been holding off on making a release > while investigating some test failures, but I'll try to make a new build > available either today or tomorrow. Now git 2.7.4 is released with more security fixes: https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.7.4.txt :( ismail -- 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
[Attn] git maintainer: Remote Code Execution for git < 2.7.1
Hi, Please see http://www.openwall.com/lists/oss-security/2016/03/15/5 . Would be nice to update to just released 2.7.3 version. Regards, ismail -- 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: openssl-1.0.2g-3
Hi, On Tue, Mar 8, 2016 at 2:46 PM, Corinna Vinschen wrote: > Hi folks, > > > I've updated the version of OpenSSL to 1.0.2g-3. > > This version enables the IDEA and RC5 crypto ciphers. The IDEA patent > expired in 2012 (and should have been added long ago), the RC5 patent > expired in November 2015. Do we really need those? OpenSSL is already full of bugs and enabling these obscure ciphers might open new can of bugs. Regards, ismail -- 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: gmane?
On Mon, Feb 29, 2016 at 8:54 PM, Ismail Donmez wrote: > Hi, > > On Mon, Feb 29, 2016 at 8:52 PM, Thufir Hawat wrote: >> is the gmane NNTP gateway working for this list? It seems empty... > > Looks fine from here: http://news.gmane.org/gmane.os.cygwin Oh you said NNTP, never mind. > ismail -- 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: gmane?
Hi, On Mon, Feb 29, 2016 at 8:52 PM, Thufir Hawat wrote: > is the gmane NNTP gateway working for this list? It seems empty... Looks fine from here: http://news.gmane.org/gmane.os.cygwin ismail -- 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] llvm 3.7.1-1
On Mon, Feb 22, 2016 at 11:32 AM, Tony Kelman wrote: > Yaakov Selkowitz cygwin.com> writes: > >> This is an update to the latest upstream release. This release switches >> to the CMake build, which results in many small shared libraries instead >> of the single monolothic one from previous releases. Clang is also built >> as a separate source package as a result. > > You're not supposed to use BUILD_SHARED_LIBS with LLVM's cmake build. > They have a dedicated flag LLVM_BUILD_LLVM_DYLIB for this. LLVM_BUILD_LLVM_DYLIB is introduced with llvm 3.8 (upcoming) and have its own set of problems, see https://llvm.org/bugs/show_bug.cgi?id=22952 . Using BUILD_SHARED_LIBS is a better idea for now. ismail -- 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] Assorted MinGW-w64 toolchain libraries and tools
On Sun, Feb 14, 2016 at 11:43 PM, Yaakov Selkowitz wrote: > On 2016-02-10 18:58, Yaakov Selkowitz wrote: >>> >>> (Also a newer clang+llvm would be useful, they've made a lot of >>> improvements since 3.5.) >> >> >> LLVM/Clang version bumps are time-consuming to get right. I actually >> looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll >> have to see what the story is with 3.7. > > > FWIW, I have 3.7.1 ready pending a stable gcc 5.3.0 release. 3.8.0 will be out in two weeks, might be a good idea to wait for that. Thanks, ismail -- 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 new acl code and cdrtools
Hi Peter, On Tue, Feb 9, 2016 at 10:56 AM, Peter Rosin wrote: > My take on the situation was that you could disable SUN ACLs by telling > configure that cdrtools should not use aclfromtext(), and that the code > that backs this was already in place. I.e. that you could get a working > build recipe w/o any hacking/patching of cdrtools at all. > > I might be misunderstanding something though, but if it works and if > it is considered more of an hack than introducing a cygwin version > check inside the cdrtools package, then that's not my headache. > > Just trying to help... If my reply came out as rude, I am sincerely sorry. As you said yes this would be a way to fix the situation for Cygwin, but I would be more happy with a pre-processor macro which we can use for this. Anyhow. Thanks, ismail -- 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 new acl code and cdrtools
On Tue, Feb 9, 2016 at 10:46 AM, Warren Young wrote: > On Feb 9, 2016, at 12:56 AM, Ismail Donmez wrote: >> >> On Tue, Feb 9, 2016 at 6:14 AM, Warren Young wrote: >>> On Feb 8, 2016, at 9:59 AM, Ismail Donmez wrote: >>>> >>>> Thats a hack :) >>> >>> Peter’s proposal is as far from a hack as it gets. >> >> What Peter suggests is telling autoconf to assume aclfromtext() does >> not exist on the system which is a hack and I already have a hack I >> could use. > > No. Once again, he’s suggesting that you write a *test* that checks whether > aclfromtext() exists here. Hypothesis -> test -> decision is science, not > assumption or hackery. The check would succeed for all versions of Cygwin, the hack part is telling configure to not check for it and assume "no". ismail -- 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 new acl code and cdrtools
Hi, On Tue, Feb 9, 2016 at 6:14 AM, Warren Young wrote: > On Feb 8, 2016, at 9:59 AM, Ismail Donmez wrote: >> >> On Mon, Feb 8, 2016 at 6:29 PM, Peter Rosin wrote: >>> On 2016-02-08 14:31, Ismail Donmez wrote: >>>> This is a generic code so I don't want to add a cygwin specific >>>> dependency there. Is there a preprocessor definition for cygwin >>>> version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ >>> >>> Pardon me for butting in, but isn't adding a Cygwin version check >>> about as non-generic as it gets? >>> >>> Wouldn't something like this work: >>> >>> .../configure ac_cv_func_aclfromtext=no >> >> Thats a hack :) > > I don’t know if that smiley means you’re joking or if you’re just trying to > soften a negative judgement, but Peter’s proposal is as far from a hack as it > gets. What Peter suggests is telling autoconf to assume aclfromtext() does not exist on the system which is a hack and I already have a hack I could use. > He is proposing that you write an autoconf test that determines if the > platform has this new ACL behavior. Then in your C code: > >#include >#if HAVE_FUNC_ACLFROMTEXT ># include >#endif I could check for __cygwin__ instead of that which would do the same thing. Anyhow the discussion diverged a lot, and for now I'll be using my simple hack of disabling HAVE_SUN_ACL manually. ismail -- 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 new acl code and cdrtools
On Mon, Feb 8, 2016 at 6:29 PM, Peter Rosin wrote: > On 2016-02-08 14:31, Ismail Donmez wrote: >> This is a generic code so I don't want to add a cygwin specific >> dependency there. Is there a preprocessor definition for cygwin >> version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ > > Pardon me for butting in, but isn't adding a Cygwin version check > about as non-generic as it gets? > > Wouldn't something like this work: > > .../configure ac_cv_func_aclfromtext=no Thats a hack :) -- 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 new acl code and cdrtools
On Mon, Feb 8, 2016 at 4:36 PM, Corinna Vinschen wrote: > On Feb 8 16:13, Ismail Donmez wrote: >> On Mon, Feb 8, 2016 at 4:10 PM, Corinna Vinschen >> wrote: >> > On Feb 8 15:31, Ismail Donmez wrote: >> >> On Mon, Feb 8, 2016 at 3:18 PM, Corinna Vinschen >> >> wrote: >> >> > On Feb 8 12:01, Ismail Donmez wrote: >> >> >> Hi, >> >> >> >> >> >> cdrtools has some code to detect Solaris style ACLs: >> >> >> >> >> >> #if defined(HAVE_ACL) && defined(HAVE_FACL) && \ >> >> >> defined(HAVE_ACLFROMTEXT) && defined(HAVE_ACLTOTEXT) >> >> >> # define HAVE_SUN_ACL1 /* Sun UFS ACL's present */ >> >> >> #endif >> >> >> >> >> >> Since cygwin still seems to be defining aclfromtext() and acltotext() >> >> >> functions (which are not defined in POSIX) cdrtools thinks this a >> >> >> Solaris-style system and get up getting a compile error later on. >> >> > >> >> > Probably due to including sys/acl.h. Does swtiching to cygwin/acl.h >> >> > help? Or changing the above check to prefer POSIX ACLs over Solaris >> >> > ACLs? >> >> >> >> This is a generic code so I don't want to add a cygwin specific >> >> dependency there. Is there a preprocessor definition for cygwin >> >> version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ >> > >> > If you include cygwin/version.h you could use the version definitions. >> > >> > Alternatively we could allow to use the Solaris ACL functions even if >> > only including sys/acl.h, given some macro: >> > >> > sys/acl.h: >> > >> > #ifdef __USE_OLD_SOLARIS_ACL_FUNCTIONS >> > # include >> > #else >> > [...POSIX definitions...] >> > #endif >> > >> > Would that help? >> >> That should help, I cook a patch and send to cdrecord maintainer. > > Wait, that's a bit premature. I'm not even sure yet if the macro name > is ok. I thought the macro already exissts sorry. But, again I would prefer a __cygwin_version__ macro anyway. Thanks, ismail -- 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 new acl code and cdrtools
On Mon, Feb 8, 2016 at 4:10 PM, Corinna Vinschen wrote: > On Feb 8 15:31, Ismail Donmez wrote: >> On Mon, Feb 8, 2016 at 3:18 PM, Corinna Vinschen >> wrote: >> > On Feb 8 12:01, Ismail Donmez wrote: >> >> Hi, >> >> >> >> cdrtools has some code to detect Solaris style ACLs: >> >> >> >> #if defined(HAVE_ACL) && defined(HAVE_FACL) && \ >> >> defined(HAVE_ACLFROMTEXT) && defined(HAVE_ACLTOTEXT) >> >> # define HAVE_SUN_ACL1 /* Sun UFS ACL's present */ >> >> #endif >> >> >> >> Since cygwin still seems to be defining aclfromtext() and acltotext() >> >> functions (which are not defined in POSIX) cdrtools thinks this a >> >> Solaris-style system and get up getting a compile error later on. >> > >> > Probably due to including sys/acl.h. Does swtiching to cygwin/acl.h >> > help? Or changing the above check to prefer POSIX ACLs over Solaris >> > ACLs? >> >> This is a generic code so I don't want to add a cygwin specific >> dependency there. Is there a preprocessor definition for cygwin >> version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ > > If you include cygwin/version.h you could use the version definitions. > > Alternatively we could allow to use the Solaris ACL functions even if > only including sys/acl.h, given some macro: > > sys/acl.h: > > #ifdef __USE_OLD_SOLARIS_ACL_FUNCTIONS > # include > #else > [...POSIX definitions...] > #endif > > Would that help? That should help, I cook a patch and send to cdrecord maintainer. Thanks a lot. ismail -- 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 new acl code and cdrtools
On Mon, Feb 8, 2016 at 3:18 PM, Corinna Vinschen wrote: > On Feb 8 12:01, Ismail Donmez wrote: >> Hi, >> >> cdrtools has some code to detect Solaris style ACLs: >> >> #if defined(HAVE_ACL) && defined(HAVE_FACL) && \ >> defined(HAVE_ACLFROMTEXT) && defined(HAVE_ACLTOTEXT) >> # define HAVE_SUN_ACL1 /* Sun UFS ACL's present */ >> #endif >> >> Since cygwin still seems to be defining aclfromtext() and acltotext() >> functions (which are not defined in POSIX) cdrtools thinks this a >> Solaris-style system and get up getting a compile error later on. > > Probably due to including sys/acl.h. Does swtiching to cygwin/acl.h > help? Or changing the above check to prefer POSIX ACLs over Solaris > ACLs? This is a generic code so I don't want to add a cygwin specific dependency there. Is there a preprocessor definition for cygwin version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ > >> Since we are switching to POSIX ACLs it would be nice to remove >> Solaris-only ACL functions. > > We can't do that for backward compatibility. The Solaris function > have to stay available, not the least for Cygwin's getfacl/setfacl > which still use them. I see, thanks. ismail -- 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 with new acl code and cdrtools
Hi, cdrtools has some code to detect Solaris style ACLs: #if defined(HAVE_ACL) && defined(HAVE_FACL) && \ defined(HAVE_ACLFROMTEXT) && defined(HAVE_ACLTOTEXT) # define HAVE_SUN_ACL1 /* Sun UFS ACL's present */ #endif Since cygwin still seems to be defining aclfromtext() and acltotext() functions (which are not defined in POSIX) cdrtools thinks this a Solaris-style system and get up getting a compile error later on. Since we are switching to POSIX ACLs it would be nice to remove Solaris-only ACL functions. Thanks, ismail -- 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: Weird behavior of crypt
Hi, On Fri, Jan 29, 2016 at 1:39 PM, Marco Atzeri wrote: > The passwords created by crypt(3) are 56 bit DES encrypted and are > 100% identical to those created by the Linux crypt(). crypt(3) on Linux support SHA-256 & SHA-512, $6$ prefix means SHA-512 is requested. Regards, ismail -- 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] curl 7.47.0-2
On Fri, Jan 29, 2016 at 5:32 AM, Yaakov Selkowitz wrote: > The following packages have been uploaded to the Cygwin distribution: > > * curl-7.47.0-2 > * libcurl4-7.47.0-2 > * libcurl-devel-7.47.0-2 > * libcurl-doc-7.47.0-2 > > curl is a command line tool and library for transferring files > with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, > TELNET, DICT, and FILE. curl supports SSL certificates, HTTP POST, HTTP > PUT, FTP uploading, HTTP form based upload, proxies, cookies, > user+password authentication (Basic, Digest, NTLM, Negotiate...), file > transfer resume, proxy tunneling and a busload of other useful tricks. > > This release enables HTTP/2 support, and therefore adds a dependency > on libnghttp2. That was fast, thank you! ismail -- 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] curl 7.47.0-1
Hi, On Thu, Jan 28, 2016 at 4:50 AM, Yaakov Selkowitz wrote: > The following packages have been uploaded to the Cygwin distribution: > > * curl-7.47.0-1 > * libcurl4-7.47.0-1 > * libcurl-devel-7.47.0-1 > * libcurl-doc-7.47.0-1 Would it be possible to enable HTTP2 support (via nghttp2) for a future release? Regards, ismail -- 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: short C code that uses AVX and fails under Cygwin
Hi,
On Thu, Jan 14, 2016 at 10:20 PM, Ilya Razenshteyn wrote:
> Hi all,
>
> the below C code fails under Cygwin. More specifically, the environment is:
> Windows 8.1, Cygwin 2.3.1, GCC 4.9.3, CPU 'Intel(R) Core(TM) i7-4510U CPU @
> 2.00GHz', compilation options are '-O0 -mavx'. Is it indeed a bug in Cygwin
> or I don't understand something?
>
> Cheers,
> Ilya
>
> #include "immintrin.h"
>
> __m256 routine(void) {
> __m256 aux;
> return aux;
> }
>
> int main(void) {
> void *buf = malloc(1);
> __m256 res = routine();
> return 0;
> }
I believe this is due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 ,
https://stackoverflow.com/questions/5983389/how-to-align-stack-at-32-byte-boundary-in-gcc
has an ugly workaround which might work for you.
Regards,
ismail
--
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 Cygwin 2.4.0-0.18 release
On Wed, Jan 13, 2016 at 12:45 PM, Corinna Vinschen wrote: > On Jan 13 09:59, Ismail Donmez wrote: >> Hi, >> >> On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen >> wrote: >> > I tried to workaround this problem by "upgrading" the DLL load >> > mechanism to use the facilities available since Vista. In theory >> > this should work fine for you. I uploaded a new developer snapshot >> > to https://cygwin.com/snapshots/ Please give it a try. >> >> Sadly still getting the same error. > > That doesn't make sense. The new code has a fallback which is identical > to the code in -0.17. No offence, but are you *sure* you're using the > snapshot DLL? Uname on 64 bit should print: > > $ uname -srvm > $ CYGWIN_NT-6.1 2.4.0(0.293/5/3) 2016-01-12 14:54 x86_64 Sorry for that, indeed somehow it overwrite the cygwin1.dll I guess because I ran setup.exe first and it re-installed -0.18 and then I manually overwrited cygwin1.dll but somehow failed. Anyhow it works now, thanks! Regards, ismail -- 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 Cygwin 2.4.0-0.18 release
Hi, On Tue, Jan 12, 2016 at 5:05 PM, Corinna Vinschen wrote: > I tried to workaround this problem by "upgrading" the DLL load > mechanism to use the facilities available since Vista. In theory > this should work fine for you. I uploaded a new developer snapshot > to https://cygwin.com/snapshots/ Please give it a try. Sadly still getting the same error. ismail -- 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 Cygwin 2.4.0-0.18 release
On Tue, Jan 12, 2016 at 11:50 AM, Corinna Vinschen wrote: > On Jan 12 11:45, Ismail Donmez wrote: >> Hi, >> >> On Tue, Jan 12, 2016 at 11:28 AM, Corinna Vinschen >> wrote: >> > Hi Ismail, >> > >> > On Jan 12 10:23, Ismail Donmez wrote: >> >> Hi, >> >> >> >> -0.17 was fine but this release breaks sshd, sshd.log says: >> >> >> >> 1 [main] sshd 2828 C:\cygwin64\usr\sbin\sshd.exe: *** fatal error - unable >> >> to load C:\Windows\system32\ws2_32.dll, Win32 error 1001 >> > >> > What OS? 32 bit, 32 bit under WOW64 or 64 bit? How do you start sshd? >> >> Sorry for the brevity of my bug report. This is on Windows 7 SP1 >> 64-bit with cygwin 64bit. >> >> > I'm asking because >> > >> > a) What I did was to revert a piece of code to the same state as in 2.2.1. >> >Does the "prev" version 2.2.1 work for you? >> >> I am always running cygwin snapshots on this machine and yesterday >> -0.17 was working fine. Now I rolled backed to 2.2.1-1 and it works >> fine. Went a little bit further and cygwin1-20160109.dll works fine >> where-as cygwin1-20160111.dll shows the problem. > > Still, does 2.2.1 work for you, too? Quoting my email "Now I rolled backed to 2.2.1-1 and it works fine." ismail -- 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 Cygwin 2.4.0-0.18 release
Hi, On Tue, Jan 12, 2016 at 11:28 AM, Corinna Vinschen wrote: > Hi Ismail, > > On Jan 12 10:23, Ismail Donmez wrote: >> Hi, >> >> -0.17 was fine but this release breaks sshd, sshd.log says: >> >> 1 [main] sshd 2828 C:\cygwin64\usr\sbin\sshd.exe: *** fatal error - unable >> to load C:\Windows\system32\ws2_32.dll, Win32 error 1001 > > What OS? 32 bit, 32 bit under WOW64 or 64 bit? How do you start sshd? Sorry for the brevity of my bug report. This is on Windows 7 SP1 64-bit with cygwin 64bit. > I'm asking because > > a) What I did was to revert a piece of code to the same state as in 2.2.1. >Does the "prev" version 2.2.1 work for you? I am always running cygwin snapshots on this machine and yesterday -0.17 was working fine. Now I rolled backed to 2.2.1-1 and it works fine. Went a little bit further and cygwin1-20160109.dll works fine where-as cygwin1-20160111.dll shows the problem. > b) It works fine for me starting sshd as a service under 2.4.0-0.18 on >64 bit Windows 10. Logging in works fine as well, as admin user as well >as normal user. Its running as a service, set up by ssh-host-config. No manual configuration on my side. > If push comes to shove I revert the reversion of the patch again, but > I do hope it turns out some local problem. Error 1001 is weird, it > means "Recursion too deep; the stack overflowed.". In an OS function? > Just because the path is given as full path? > > > Thanks, > Corinna > > > Sidenote: Here's an example where supporting XP hurts, btw. The code > in question could be much simplified if we only had to support Vista > and later. > > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem with Cygwin 2.4.0-0.18 release
Hi, -0.17 was fine but this release breaks sshd, sshd.log says: 1 [main] sshd 2828 C:\cygwin64\usr\sbin\sshd.exe: *** fatal error - unable to load C:\Windows\system32\ws2_32.dll, Win32 error 1001 Thanks, ismail -- 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: cmp (or echo) bug?
Hi, David Balažic gmail.com> writes: > In Cygwin terminal (bash) I typed: > > cmp <(echo echo1) <(echo echo2) I suspect its a bash bug since it works fine with zsh (tested 64bit only).
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
Corinna Vinschen cygwin.com> writes: > > Hi Cygwin friends and users, > > I released TEST version 2.4.0-0.11 of Cygwin. > > So 0.10 was *not* the last test release... > > Anyway, compared to 0.10 there's only a single change: > > - Fix a potential crash reading invalid passwd and group entries from > /etc/passwd and /etc/group. > Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html Works beautifully on Win 10 x64 10586.29. Regards, ismail -- 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: zsh-5.1.1-1
Hi, Peter A. Castro fruitbat.org> writes: > > An updated version of zsh (zsh-5.1.1-1) has been released and should be > at a mirror near you real soon. This is an upstream release. Thank you! -- 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: Processes randomly get stuck
Corinna Vinschen writes: > > On Aug 21 08:49, Ismail Donmez wrote: > > Hi, > > > > Corinna Vinschen: > > > > > > This might explain some behaviour I am seeing because tmux is reading > > that > > > > file every 20 seconds or something like that. > > > > > > Oops. > > > > Well its even worse than that, its reading /proc/≤pid>/cmdline twice every > > *second* , for now I'll disable this insane behaviour and see if things > > improve. > > What on earth is it expecting? The idea is it updates the window title as needed, so you can zsh on tmux and the title is "zsh" and then you fire up vim and the title changes to "vim" etc. Apparently this is less of a problem on Linux because I never even noticed it was doing this. ismail
Re: Processes randomly get stuck
Hi, Corinna Vinschen: > > This might explain some behaviour I am seeing because tmux is reading that > > file every 20 seconds or something like that. > > Oops. Well its even worse than that, its reading /proc//cmdline twice every *second* , for now I'll disable this insane behaviour and see if things improve. -- 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: Processes randomly get stuck
Hi, Corinna Vinschen writes: > > On Jul 26 12:56, Ismail Donmez wrote: > > Hi, > > > > $ uname -a > > CYGWIN_NT-10.0 ux31a 2.2.0(0.289/5/3) 2015-07-23 20:41 x86_64 Cygwin > > > > For the last week or so ssh/zsh processes are randomly gets into defunct > > state, that is > > > > $ cat /proc/7232/cmdline > > > > $ cat /proc/7232/status > > Name: zsh > > State: S (sleeping) > > Tgid: 7232 > > Pid:7232 > > PPid: 5172 > > Uid:197609 197609 197609 197609 > > Gid:197609 197609 197609 197609 > > VmSize: 7556 kB > > VmLck: 0 kB > > VmRSS: 10860 kB > > VmData: 2140 kB > > VmStk: 0 kB > > VmExe: 0 kB > > VmLib: 4644 kB > > SigPnd: > > SigBlk: > > SigIgn: > > > > Same happens with ssh, and after some time like 5 minutes or so it goes > > back to the normal state. I wonder if anyone has been experiencing > > something similar? > > There's no change in 2.2.0 which might explain this, but still, did > you try to downgrade to 2.1.0? I tried to see the patterns of this problem before replying again. Because the bug randomly appears I can't conclude if 2.1.0 was any better (though I couldn't reproduce the problem with it.) I have an idea why this might be happening and want to ask what happens each time one does read /proc//cmdline, does the function _pinfo::commune_request called everytime, or just once? This might explain some behaviour I am seeing because tmux is reading that file every 20 seconds or something like that. Thanks! ismail -- 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: w32api-{headers,runtime}-4.0.4-1(x86/x86_64)
Hi, JonY writes: > Note: 4.0.3 was never released due to a bug in headers installation > routine. As of writing, SF developer service has yet to fully recover, > so there won't be any v4.0.4 tarballs on SF yet. Since SF seems to be back up, can you please upload the tarballs there too? Thanks. -- 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
Processes randomly get stuck
Hi, $ uname -a CYGWIN_NT-10.0 ux31a 2.2.0(0.289/5/3) 2015-07-23 20:41 x86_64 Cygwin For the last week or so ssh/zsh processes are randomly gets into defunct state, that is $ cat /proc/7232/cmdline $ cat /proc/7232/status Name: zsh State: S (sleeping) Tgid: 7232 Pid:7232 PPid: 5172 Uid:197609 197609 197609 197609 Gid:197609 197609 197609 197609 VmSize: 7556 kB VmLck: 0 kB VmRSS: 10860 kB VmData: 2140 kB VmStk: 0 kB VmExe: 0 kB VmLib: 4644 kB SigPnd: SigBlk: SigIgn: Same happens with ssh, and after some time like 5 minutes or so it goes back to the normal state. I wonder if anyone has been experiencing something similar? -- 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] Update: mintty 2.1.1
Hi, Houder writes: > > > Hi, > > > > Thomas Wolf writes: > > > >> > >> mintty 2.1.1 has a bunch of requested tweaks and fixes which Iâm > >> releasing before some restructuring around character attributes... > > > > This seems to stackdump on startup for me on Win7 x64. > > Confirmed. Both Win7 x86 and Win7 x64. It started working again for me after a restart, weird.
Re: [ANNOUNCEMENT] Update: mintty 2.1.1
Ismail Donmez writes: > This seems to stackdump on startup for me on Win7 x64. Already did a full > rebase but didn't help. Dump looks like: Sorry for the noise, this seems to be a local problem. -- 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] Update: mintty 2.1.1
Hi, Thomas Wolf writes: > > mintty 2.1.1 has a bunch of requested tweaks and fixes which I’m > releasing before some restructuring around character attributes... This seems to stackdump on startup for me on Win7 x64. Already did a full rebase but didn't help. Dump looks like: Exception: STATUS_ACCESS_VIOLATION at rip=7FEFB973430 rax=07FEFB973430 rbx=0022C5D0 rcx=0010016E rdx=0022C4B0 rsi=00010042A900 rdi=0022C5CC r8 =0022C458 r9 =0010016E r10= r11=0287 r12=0318 r13=03F0 r14=000600041F90 r15=031A rbp=0022C550 rsp=0022C488 program=C:\cygwin64\bin\mintty.exe, pid 2808, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 022C550 7FEFB973430 (022C550, 000, 0010042A900, 000) 022C550 0010040FAEA (022C550, 0010042A900, 3F0, 0060008D4F0) 022C550 0010041B3EA (000, 001, 030, FF0700010302FF00) 022CBC0 00180048410 (000, 000, 000, 000) 000 001800460DC (000, 000779E20C5, 000, 02D) 000 00180046174 (000, 000, 000, 000) 000 00100419EF1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 000) 000 000778559CD (000, 000, 000, 000) 000 00077A8B981 (000, 000, 000, 000) End of stack trace
RE: From Microsoft: Windows 10 Console and Cygwin
Rich Eizenhoefer wrote > I've created a backlog item for this request so we can track the ask. It's > possible, but would probably need to pick your brain in-depth more about > the ask in the future. In the meantime, is it okay if I attach a copy of > this email thread to the internal tracking item in our database? If not, > I'll just keep the summary that I've already added. I wonder if there is any news on this? Since Windows 10 RTM is approaching it would be nice to have some update about this. -- View this message in context: http://cygwin.1069669.n5.nabble.com/From-Microsoft-Windows-10-Console-and-Cygwin-tp117937p118602.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > On Apr 17 09:30, Corinna Vinschen wrote: > I think I found the culprit. I'll uploade a -0.7 test release in > the next hour or so. So far all my tests work, thanks a bunch! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117666.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [TESTERS needed] New POSIX permission handling
Corinna Vinschen-2 wrote > On Apr 16 09:09, Ismail Donmez wrote: >> Hi, >> >> [...] >> So I am trying to configure and install mutt, and the first error I see >> is >> at the end of configure: >> >> configure: creating ./config.status >> chmod: changing permissions of './config.status': Permission denied >> configure: error: write failure creating ./config.status >> >> Well, looks like its right: >> >> [~/src/mutt]> chmod +x config.status >> chmod: changing permissions of ‘config.status’: Permission denied >> >> [~/src/mutt]> uname -a >> CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin >> >> [~/src/mutt]> getfacl . >> # file: . >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> default:user::rwx >> default:group::r-x >> default:group:SYSTEM:rwx >> default:group:Administrators:rwx >> default:mask:r-x >> default:other:r-x >> >> [~/src/mutt]> getfacl config.status >> # file: config.status >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> >> Any ideas? :) > > Not yet. Can you add the output of icacls for both? For easier > copy/pasting, just pipe the icacls output through `cat' for the time > being. [~/src/mutt]> icacls config.status config.status NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files [~/src/mutt]> icacls . . NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117627.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > On Apr 16 03:20, Ismail Donmez wrote: >> Corinna Vinschen-2 wrote >> > I just applied a patch which is supposed to handle this owner==group >> > scenario better. >> > >> > In short, Cygwin will try to handle POSIX user and group permissions >> > separately, even if owner == group. This is basically a fake as far >> > as the actual permissions of the account are concerned, but it allows >> > applications still to chmod to different user and group perms. It >> > just *looks* different in the end. >> > >> > The only restriction of this is that the POSIX user permissions are >> > always changed so that the user perms are >= the group perms in this >> > situation. So this: >> > >> > chmod 460 foo >> > >> > will be internally twisted into >> > >> > chmod 660 foo >> > >> > >> > I uploaded new developer snapshots to https://cygwin.com/snapshots/ >> > and I'm just uploading a 2.0.0-0.5 test release with this change. >> >> I tested the new test release (rm -rfd the cygwin installation and >> re-installed from scratch just to be sure), my original testcase with >> quilt >> and mutt works, BUT now when I run make install inside mutt source it >> complains that /usr/bin/install cannot change permissions on the >> destination >> executables. > > Hmm, ok. Off the top of my head I don't understand this. > >> can post an easily reproducable error. Because running the same command >> myself gives no error whatsoever. I'll try to come up with a better >> report. > > That would be nice. A good start would be to know what permission mask > install is trying to set the destination to. Maybe that sheds some light. So I am trying to configure and install mutt, and the first error I see is at the end of configure: configure: creating ./config.status chmod: changing permissions of './config.status': Permission denied configure: error: write failure creating ./config.status Well, looks like its right: [~/src/mutt]> chmod +x config.status chmod: changing permissions of ‘config.status’: Permission denied [~/src/mutt]> uname -a CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin [~/src/mutt]> getfacl . # file: . # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:r-x default:other:r-x [~/src/mutt]> getfacl config.status # file: config.status # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x Any ideas? :) Thank you. -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117621.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [TESTERS needed] New POSIX permission handling
Hi, Corinna Vinschen-2 wrote > Hi Ismail, > > On Apr 12 16:25, Corinna Vinschen wrote: >> On Apr 12 06:21, İsmail Dönmez wrote: >> > Corinna Vinschen-2 wrote >> > > On Apr 11 10:11, donmez wrote: >> > >> Corinna Vinschen-2 wrote >> > >> > I just applied a patch I'm working on for quite some time now. As >> I >> > >> > outlined before on this list, the POSIX permission handling has >> aged >> > >> > considerably and, for historical reasons, did things differently >> > >> > dependent on the calling function. I took the time to reimplement >> the >> > >> > core functionality to handle all ACLs as strictly following POSIX >> ACL >> > >> > rules as possible. >> > >> >> > >> I tested the updated package and at least quilt and mutt seems to >> broken >> > >> by >> > >> the permission changes: >> > >> [...] >> > > No offense, but this is not overly helpful. The problem is to learn >> > > *why* this happens and how to fix it. For that I'd need to know what >> > > your permissions on /tmp look like (ls -l, getfacl, icacls). >> Creating >> > > files in my /tmp (having an old-style ACL) with the following >> > > permissions works as desired for me: >> > >> > Hopefully this will shed some more light: >> >> It does, thank you. The problem is the dreaded "owner == group" problem >> introduced with these weird Microsoft accounts. I completely forgot >> about this while implementing the new code. It's pretty tricky to get >> the Windows ACL right for this. Additionally the ACLs already created >> by setup are... borderline correct only. Back to the drawing board... > > I just applied a patch which is supposed to handle this owner==group > scenario better. > > In short, Cygwin will try to handle POSIX user and group permissions > separately, even if owner == group. This is basically a fake as far > as the actual permissions of the account are concerned, but it allows > applications still to chmod to different user and group perms. It > just *looks* different in the end. > > The only restriction of this is that the POSIX user permissions are > always changed so that the user perms are >= the group perms in this > situation. So this: > > chmod 460 foo > > will be internally twisted into > > chmod 660 foo > > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > and I'm just uploading a 2.0.0-0.5 test release with this change. I tested the new test release (rm -rfd the cygwin installation and re-installed from scratch just to be sure), my original testcase with quilt and mutt works, BUT now when I run make install inside mutt source it complains that /usr/bin/install cannot change permissions on the destination executables. Now this is a pretty vague error report but it might take some time before I can post an easily reproducable error. Because running the same command myself gives no error whatsoever. I'll try to come up with a better report. Thanks a lot! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117615.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
