Re: Can't use install-path longer than 15 chars after 2.875 update

[Brian Inglis]

On 2016-08-31 13:28, Garber, Dave (GE Oil & Gas, Non-GE) wrote:

On Aug 31 18:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:

On Aug 31 20:22, Jacek Sowiński wrote:

After updating to setup-x86_64.exe version 2.875 I can't use
install paths longer than 15 chars and error is throwed:

The install directory must be absolute, with both a drive
letter and leading slash, like C:\Cygwin

So what was your actual install path? FYI, I just used
setup-2.875 to installed Cygwin into C:\cygwin-test-blubber-
test\test\test and it just worked.

I can confirm that C:\apps\Cygwin64 does NOT work but
C:\apps\Cygwin6 does.  I also get the error with
C:\cygwin-test-blubber-test\test\test.

On what OS?  You're not running it on XP by any chance?  Is that
on 32 or 64 bit? I could reproduce it on W7 32 bit for some reaosn,
while it works fine all the time on W10 64 bit.

Fails on Win7 64 bit also.


Sounds suspiciously close to _POSIX_NAME_MAX(==14) if backslash is
stripped and nul terminator is included in the count?
But can't find anything obvious grepping setup and newlib sources.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Different representations of time in ls -l and date(1)

[Erik Soderquist]

On Wed, Aug 31, 2016 at 4:17 PM, cyg Simple wrote:
>
> In other words, don't trust a default

Exactly!

-- Erik

--
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 2.6.0-1

[Brian Inglis]

On 2016-08-31 13:30, Achim Gratz wrote:

Brian Inglis writes:

On 2016-08-31 12:32, Kenneth Wolcott wrote:

On Wed, Aug 31, 2016 at 11:30 AM, Vince Rice  wrote:

As the 84 year old guy who helps my 70 year old dad …

H. Is one of you Benjamin Button? :)

That's what I thought when I first read this, but I re-read it a
couple of times, it makes sense :-)

In what bases/radixes does it make sense?

The senior of the guy who wrote the post has someone his senior looking
after his computers.  There, no need to change a radix or even use the
numbers.  :-)

Thanks, guess I was looking for the kicker; maybe getting too old to do
the parse without the extra delimiters ;^>
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: setup.exe (Release 2.875)

[Achim Gratz]

Emily Jackson writes:
> On 8/31/2016 10:43 AM, Corinna Vinschen wrote:
>> A new version of Setup, release 2.875, has been uploaded to
>> 
>>   https://cygwin.com/setup-x86.exe (32 bit version)
>>   https://cygwin.com/setup-x86_64.exe  (64 bit version)
>
> I have downloaded the 64 bit version twice, and I keep getting the old
> version (2.874)

The newer version has been retracted and 2.874 reinstated due to a
problem that needs investigation.


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: setup.exe (Release 2.875)

[Emily Jackson]

On 8/31/2016 10:43 AM, Corinna Vinschen wrote:
> A new version of Setup, release 2.875, has been uploaded to
> 
>   https://cygwin.com/setup-x86.exe (32 bit version)
>   https://cygwin.com/setup-x86_64.exe  (64 bit version)

I have downloaded the 64 bit version twice, and I keep getting the old
version (2.874)

Emily

--
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: pdftk cygwin 32-bit

[Marco Atzeri]

On 31/08/2016 22:19, Ivandro Sanches wrote:

I would like to install pdftk but it seems it is not present anymore
among the available packages from setup-x86.exe.

If possible, could you please give me some hint on how to install
pdftk on cygwin 32-bit?

Thanks a lot




pdftk has been removed as it depends on Java
and gcj is basically dead and never worked on 64bit
https://sourceware.org/ml/cygwin-apps/2016-07/msg00037.html

Two solutions:
1) take the old package from
http://www.fruitbat.org/Cygwin/

2) try qpdf
https://sourceware.org/ml/cygwin-announce/2016-07/msg1.html

that provide similar functionality

Regards
Marco




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

pdftk cygwin 32-bit

[Ivandro Sanches]

I would like to install pdftk but it seems it is not present anymore
among the available packages from setup-x86.exe.

If possible, could you please give me some hint on how to install
pdftk on cygwin 32-bit?

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

Re: Different representations of time in ls -l and date(1)

[cyg Simple]

On 8/31/2016 11:23 AM, Erik Soderquist wrote:
> On Wed, Aug 31, 2016 at 10:45 AM, Eric Blake wrote:
>> So, the answer to your question is determined by what your locale thinks
>> is the appropriate representation; and I have no control over whether
>> Windows' locale defaults will match glibc's locale defaults for en_US or
>> any other locale outside of C.
> 
> 
> It is because I have been burned on this (world wide customers) that I
> know explicitly specify the format I want to work with in my scripts
> and disregard whatever the local is.
> 

In other words, don't trust a default to provide the exact
representation needed for your process to work correctly.  You cannot
control what a default might return so be specific if you have a
specific format required.

-- 
cyg 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: Can't use install-path longer than 15 chars after 2.875 update

[Jacek Sowiński]

On Wed, 31 Aug 2016 20:38:39 +0200 Corinna Vinschen wrote:
> So what was your actual install path?

E:\PortableApps\CygwinPortable64

It works if I cut it to E:\PortableApps
It doesn't however if it is E:\PortableApps1

I'm on Windows 7 64bit and I've tried both versions of setup.exe (x86
and x86_64).

-- 
Jacek Sowiński

--
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 2.6.0-1

[Achim Gratz]

Brian Inglis writes:
> On 2016-08-31 12:32, Kenneth Wolcott wrote:
>> On Wed, Aug 31, 2016 at 11:30 AM, Vince Rice  
>> wrote:
 As the 84 year old guy who helps my 70 year old dad …
>>> H. Is one of you Benjamin Button? :)
>> That's what I thought when I first read this, but I re-read it a
>> couple of times, it makes sense :-)
>
> In what bases/radixes does it make sense?

The senior of the guy who wrote the post has someone his senior looking
after his computers.  There, no need to change a radix or even use the
numbers.  :-)


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

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 3:26 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 18:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> > > -Original Message-
> > > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com]
> On
> > > Behalf Of Corinna Vinschen
> > > Sent: Wednesday, August 31, 2016 2:39 PM
> > > To: cygwin@cygwin.com
> > > Subject: EXT: Re: Can't use install-path longer than 15 chars after
> > > 2.875 update
> > >
> > > On Aug 31 20:22, Jacek Sowiński wrote:
> > > > After updating to setup-x86_64.exe version 2.875 I can't use
> > > > install paths longer than 15 chars and error is throwed:
> > > >
> > > > > The install directory must be absolute, with both a drive letter
> > > > > and leading slash, like C:\Cygwin
> > >
> > > So what was your actual install path?
> > >
> > > FYI, I just used setup-2.875 to installed Cygwin into
> > > C:\cygwin-test-blubber- test\test\test and it just worked.
> >
> > I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6
> > does.  I also get the error with C:\cygwin-test-blubber-test\test\test.
> 
> On what OS?  You're not running it on XP by any chance?  Is that on
> 32 or 64 bit?
> 
> [...time passes...]
> 
> I could reproduce it on W7 32 bit for some reaosn, while it works fine all the
> time on W10 64 bit.
> 

Fails on Win7 64 bit also.

> FWIW, I reverted setup to version 2.874 for the time being.
> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Marco Atzeri]

On 31/08/2016 21:16, Brian Inglis wrote:

On 2016-08-31 12:32, Kenneth Wolcott wrote:

On Wed, Aug 31, 2016 at 11:30 AM, Vince Rice
 wrote:

As the 84 year old guy who helps my 70 year old dad …

H. Is one of you Benjamin Button? :)

That's what I thought when I first read this, but I re-read it a
couple of times, it makes sense :-)


In what bases/radixes does it make sense?


It is a third person...

As the 84 year old guy { who helps my 70 year old dad do Linux installs
and Cygwin fixes on systems } keeps telling me: you are never too old...


--
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: Can't use install-path longer than 15 chars after 2.875 update

[Corinna Vinschen]

On Aug 31 18:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:
> > -Original Message-
> > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> > Behalf Of Corinna Vinschen
> > Sent: Wednesday, August 31, 2016 2:39 PM
> > To: cygwin@cygwin.com
> > Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> > update
> > 
> > On Aug 31 20:22, Jacek Sowiński wrote:
> > > After updating to setup-x86_64.exe version 2.875 I can't use install
> > > paths longer than 15 chars and error is throwed:
> > >
> > > > The install directory must be absolute, with both a drive letter and
> > > > leading slash, like C:\Cygwin
> > 
> > So what was your actual install path?
> > 
> > FYI, I just used setup-2.875 to installed Cygwin into 
> > C:\cygwin-test-blubber-
> > test\test\test and it just worked.
> 
> I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6
> does.  I also get the error with C:\cygwin-test-blubber-test\test\test.

On what OS?  You're not running it on XP by any chance?  Is that on
32 or 64 bit?

[...time passes...]

I could reproduce it on W7 32 bit for some reaosn, while it works fine
all the time on W10 64 bit.

FWIW, I reverted setup to version 2.874 for the time being.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: per-version hints proposal

[Achim Gratz]

Jon Turney writes:
>> calm will be changed so that:
>>
>> * The requires: line written in setup.ini will contain the union of the
>> requires: from each pvr.hint
>>
>> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
>> taken from the pvr.hint for the curr version

I've not given this much more thought, but I think we should change the
setup.ini syntax to allow different values for _all_ keys in a package
for each version.  The ones that are not in a specific section
(i.e. where they are now, right after the package line) would just
provide a default that gets used when there is no version-specific value
provided in the corresponding section.  Calm could/should move such
key/value pairs to the default when they are identical among the
majority of versions, otherwise use those from the current version.


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

Re: [PATCH 1/4] dlopen: switch to new pathfinder class

[Corinna Vinschen]

Hi Michael,

On Aug 31 20:07, Michael Haubenwallner wrote:
> Instead of find_exec, without changing behaviour use new pathfinder
> class with new allocator_interface around tmp_pathbuf and new vstrlist
> class.
> * pathfinder.h (pathfinder): New file.
> * vstrlist.h (allocator_interface, allocated_type, vstrlist): New file.
> * dlfcn.cc (dlopen): Avoid redundant GetModuleHandleExW with RTLD_NOLOAD
> and RTLD_NODELETE.  Switch to new pathfinder class, using
> (tmp_pathbuf_allocator): New class.
> (get_full_path_of_dll): Drop.
> [...]

Just one nit here:

> +/* Dumb allocator using memory from tmp_pathbuf.w_get ().
> +
> +   Does not reuse free'd memory areas.  Instead, memory
> +   is released when the tmp_pathbuf goes out of scope.
> +
> +   ATTENTION: Requesting memory from an instance of tmp_pathbuf breaks
> +   when another instance on a newer stack frame has provided memory. */
> +class tmp_pathbuf_allocator
> +  : public allocator_interface

You didn't reply to
https://cygwin.com/ml/cygwin-developers/2016-08/msg00013.html
So, again, why didn't you simply integrate a tmp_pathbuf member into the
pathfinder class, rather than having to create some additional allocator
class?  I'm probably not the most diligent C++ hacker, but to me this
additional allocator is a bit confusing.

The rest of the patch looks good.  I'll look further into the patchset
later tomorrow.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Brian Inglis]

On 2016-08-31 12:32, Kenneth Wolcott wrote:

On Wed, Aug 31, 2016 at 11:30 AM, Vince Rice  wrote:

As the 84 year old guy who helps my 70 year old dad …

H. Is one of you Benjamin Button? :)

That's what I thought when I first read this, but I re-read it a
couple of times, it makes sense :-)


In what bases/radixes does it make sense?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Can't use install-path longer than 15 chars after 2.875 update

[Brian Inglis]

On 2016-08-31 12:59, Garber, Dave (GE Oil & Gas, Non-GE) wrote:

On Aug 31 20:22, Jacek Sowiński wrote:

After updating to setup-x86_64.exe version 2.875 I can't use
install paths longer than 15 chars and error is throwed:

The install directory must be absolute, with both a drive
letter and leading slash, like C:\Cygwin

So what was your actual install path? FYI, I just used setup-2.875
to installed Cygwin into C:\cygwin-test-blubber- test\test\test and
it just worked.

I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6
does.  I also get the error with
C:\cygwin-test-blubber-test\test\test.


No problems updating cygwin today with setup-x86_64.exe 2.875:
$ uname -srvmo
CYGWIN_NT-10.0 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin
$ head -n 2 /etc/setup/setup.rc
last-cache
C:/usr/local/cygwin64/var/cache/setup/packages
Brian@BWInglisD ~ 2013 $ tail -n 8 /etc/setup/setup.rc
last-mirror
ftp://ftp.muug.ca/mirror/cygwin/
net-method
Direct
last-action
Download,Install
chooser_window_settings
44,0,1,4294967295,4294967295,4294967295,4294967295,101,401,1090,1181
$
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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

Can't use install-path longer than 15 chars after 2.875 update

[Garber, Dave (GE Oil & Gas, Non-GE)]

> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: Wednesday, August 31, 2016 2:39 PM
> To: cygwin@cygwin.com
> Subject: EXT: Re: Can't use install-path longer than 15 chars after 2.875
> update
> 
> On Aug 31 20:22, Jacek Sowiński wrote:
> > After updating to setup-x86_64.exe version 2.875 I can't use install
> > paths longer than 15 chars and error is throwed:
> >
> > > The install directory must be absolute, with both a drive letter and
> > > leading slash, like C:\Cygwin
> 
> So what was your actual install path?
> 
> FYI, I just used setup-2.875 to installed Cygwin into C:\cygwin-test-blubber-
> test\test\test and it just worked.

I can confirm that C:\apps\Cygwin64 does NOT work but C:\apps\Cygwin6 does.  I 
also get the error with C:\cygwin-test-blubber-test\test\test.

> 
> 
> Corinna
> 
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat

Re: Can't use install-path longer than 15 chars after 2.875 update

[Corinna Vinschen]

On Aug 31 20:22, Jacek Sowiński wrote:
> After updating to setup-x86_64.exe version 2.875 I can't use install
> paths longer than 15 chars and error is throwed:
> 
> > The install directory must be absolute, with both a drive letter and
> > leading slash, like C:\Cygwin

So what was your actual install path?

FYI, I just used setup-2.875 to installed Cygwin into
C:\cygwin-test-blubber-test\test\test and it just worked.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Kenneth Wolcott]

On Wed, Aug 31, 2016 at 11:30 AM, Vince Rice  wrote:
>> As the 84 year old guy who helps my 70 year old dad …
>
> H. Is one of you Benjamin Button? :)

That's what I thought when I first read this, but I re-read it a
couple of times, it makes sense :-)

--
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 2.6.0-1

[Vince Rice]

> As the 84 year old guy who helps my 70 year old dad …

H. Is one of you Benjamin Button? :)


--
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

Can't use install-path longer than 15 chars after 2.875 update

[Jacek Sowiński]

After updating to setup-x86_64.exe version 2.875 I can't use install
paths longer than 15 chars and error is throwed:

> The install directory must be absolute, with both a drive letter and
> leading slash, like C:\Cygwin

Below are the contents of setup.log.full:

> 2016/08/31 19:09:26 Starting cygwin install, version 2.875
> 2016/08/31 19:09:26 User has NO backup/restore rights
> 2016/08/31 19:09:26 Current Directory: 
> E:\PortableApps\CygwinPortable64\packages
> 2016/08/31 19:09:26 Could not open Service control manager
> 2016/08/31 19:09:29 source: network install
> 2016/08/31 19:09:30 mbox note: The install directory must be absolute, with 
> both a drive letter and leading slash, like C:\Cygwin
> 2016/08/31 19:11:31 Ending cygwin install

I've double checked and this issue doesn't exist with 2.872. I don't
remember it also with 2.873 and 2.874 (I can't check those versions
right now, because after update I have only additional copy of 2.872).

I tried to attach cygcheck.out, but then my e-mails were rejected with
such message:

> 552 spam score exceeded threshold

-- 
Jacek Sowiński

--
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

[PATCH 4/4] dlopen: on unspecified lib dir search exe dir

[Michael Haubenwallner]

Applications installed to some prefix like /opt/application do expect
dlopen("libAPP.so") to load "/opt/application/bin/cygAPP.dll", which
is similar to "/opt/application/lib/libAPP.so" on Linux.

See also https://cygwin.com/ml/cygwin-developers/2016-08/msg00020.html

* dlfcn.cc (dlopen): For dlopen("N"), search directory where the
application executable is in.
---
 winsup/cygwin/dlfcn.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/winsup/cygwin/dlfcn.cc b/winsup/cygwin/dlfcn.cc
index f8b8743..974092e 100644
--- a/winsup/cygwin/dlfcn.cc
+++ b/winsup/cygwin/dlfcn.cc
@@ -232,6 +232,12 @@ dlopen (const char *name, int flags)
 not use the LD_LIBRARY_PATH environment variable. */
  finder.add_envsearchpath ("LD_LIBRARY_PATH");
 
+ /* Search the current executable's directory like
+the Windows loader does for linked dlls. */
+ int exedirlen = get_exedir (cpath, wpath);
+ if (exedirlen)
+   finder.add_searchdir (cpath, exedirlen);
+
  /* Finally we better have some fallback. */
  finder.add_searchdir ("/usr/bin", 8);
  finder.add_searchdir ("/usr/lib", 8);
-- 
2.7.3

[PATCH 2/4] dlopen (pathfinder): try each basename per dir

[Michael Haubenwallner]

Rather than searching all search dirs per one basename,
search for all basenames within per one search dir.

pathfinder.h (check_path_access): Interchange dir- and basename-loops.
---
 winsup/cygwin/pathfinder.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/winsup/cygwin/pathfinder.h b/winsup/cygwin/pathfinder.h
index bbba168..c306604 100644
--- a/winsup/cygwin/pathfinder.h
+++ b/winsup/cygwin/pathfinder.h
@@ -182,12 +182,12 @@ public:
 basenamelist::member const ** found_basename = NULL)
   {
 char const * critname = criterion.name ();
-for (basenamelist::iterator name = basenames_.begin ();
-name != basenames_.end ();
-++name)
-  for (searchdirlist::iterator dir(searchdirs_.begin ());
-  dir != searchdirs_.end ();
-  ++dir)
+for (searchdirlist::iterator dir(searchdirs_.begin ());
+dir != searchdirs_.end ();
+++dir)
+  for (basenamelist::iterator name = basenames_.begin ();
+  name != basenames_.end ();
+  ++name)
if (criterion.test (dir, name))
  {
debug_printf ("(%s), take %s%s", critname,
-- 
2.7.3

[PATCH 0/4] dlopen: improving the search algorithm

[Michael Haubenwallner]

Hi Corinna,

based on the discussion on -developers list [1][2], here's a reworked
set of patches for dlopen, split along these features and fixes.

[1] https://cygwin.com/ml/cygwin-developers/2016-06/msg0.html
[2] https://cygwin.com/ml/cygwin-developers/2016-08/msg0.html

*) Switch to pathfinder class for path search iteration, without any
deliberate change in behaviour, but with the pathfinder::criterion
interface to allow for more generic use eventually.

*) Fix search order to search all basenames per one directory
rather than searching all directories per one basename.

*) For dlopen ("/path/lib/libz.so"), search "/path/bin/" first when
the executable calling is located in "/path/bin/".  This is for [3].
[3] https://cygwin.com/ml/cygwin-developers/2016-08/msg00020.html

*) Consequently, dlopen ("libAPP.so") without an explicit path
should search the executable's directory first, like the Windows
loader does for linked dlls.

Topics dropped for now:

*) Extra GetModuleHandleEx is not that necessary to me, as it[4]
turns out that LoadLibrary detects a dll as already loaded even
if the underlying dll file has been replaced (renamed actually).
[4] https://cygwin.com/ml/cygwin-developers/2016-08/msg00023.html

*) Add PATH environment variable to list of searchdirs should not
be necessary to me when the executable dir is added.

Thank you!
/haubi/

Re: [ANNOUNCEMENT] openssl 1.0.2h-1

[Corinna Vinschen]

On Aug 31 11:42, Yaakov Selkowitz wrote:
> On 2016-08-31 06:10, Corinna Vinschen wrote:
> > We can't and we won't switch to OpenSSH 1.1.0 unless at least the first
> > problems are ironed out.  There were a lot of partially backward
> > incompatible changes, one of them results in OpenSSH not working with
> > OpenSSL 1.1.0 yet.
> > 
> > So, for the time being, we stay with 1.0.2.  It will be supported by
> > upstream for at least another two years, so there's no reason for hurry.
> 
> +1.  I suggest we wait until one or more of the major Linux distros has
> tackled this first so that patches for the API incompatibilities will
> already be available.

ACK.  Sounds good.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Stephen John Smoogen]

On 31 August 2016 at 12:28, Nirgendsdorf  wrote:
> On Wed, 31 Aug 2016 15:58:45 +0200, Corinna Vinschen wrote:
>
>> I uploaded a new Cygwin release 2.6.0-1.
>>
>> Please note that this release won't work on Windows XP and Windows
>> Server 2003 or 2003 R2.  At least Windows Vista or Windows Server 2008
>> are required.
>
>
> Well, there goes XP as another software project on which I depend withdraws
> support. It’s not that I can’t afford to "upgrade"-- I can get a
> reconditioned box with Windows 7 on it for around $200 or less. It's that I
> am too old and tired to install the applications and utilities I would want,
> find replacements for my old favorites that would not run on the new box,
> and then tweak everything the way I would want it to run. Worse yet, I would
> probably want to install Linux...and build it from scratch. Nope, far too
> old and tired for any of that, especially for learning my way around the new
> stuff.
>

As the 84 year old guy who helps my 70 year old dad do Linux installs
and Cygwin fixes on systems keeps telling me: you are never too old...
it just takes a bit longer to get the circuits going.


>> Thanks,
>> Corinna
>
> Thank you, Corinna, for helping to keep Cygwin going. I found it when it was
> ver. b17 because I was looking for a way to run Joseph Allen's editor (joe)
> on Windows and keep all the nice POSIX features. It's been quite a ride ever
> since. I'll probably be around for a little while yet, long as I can build
> stuff for the old Cygwin without too much trouble. Goodness help me, though,
> if I ever get to the point where I find myself sitting in a wheelchair,
> staring at a wall.
>
> Cheers,
>
> Jeff
>
>
> --
> 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
>



-- 
Stephen J Smoogen.

--
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] openssl 1.0.2h-1

[Yaakov Selkowitz]

On 2016-08-31 06:10, Corinna Vinschen wrote:

We can't and we won't switch to OpenSSH 1.1.0 unless at least the first
problems are ironed out.  There were a lot of partially backward
incompatible changes, one of them results in OpenSSH not working with
OpenSSL 1.1.0 yet.

So, for the time being, we stay with 1.0.2.  It will be supported by
upstream for at least another two years, so there's no reason for hurry.


+1.  I suggest we wait until one or more of the major Linux distros has 
tackled this first so that patches for the API incompatibilities will 
already be available.


--
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: [ANNOUNCEMENT] Updated: Cygwin 2.6.0-1

[Nirgendsdorf]

On Wed, 31 Aug 2016 15:58:45 +0200, Corinna Vinschen wrote:


I uploaded a new Cygwin release 2.6.0-1.

Please note that this release won't work on Windows XP and Windows
Server 2003 or 2003 R2.  At least Windows Vista or Windows Server 2008
are required.


Well, there goes XP as another software project on which I depend 
withdraws support. It’s not that I can’t afford to "upgrade"-- I can get 
a reconditioned box with Windows 7 on it for around $200 or less. It's 
that I am too old and tired to install the applications and utilities I 
would want, find replacements for my old favorites that would not run on 
the new box, and then tweak everything the way I would want it to run. 
Worse yet, I would probably want to install Linux...and build it from 
scratch. Nope, far too old and tired for any of that, especially for 
learning my way around the new stuff.



Thanks,
Corinna
Thank you, Corinna, for helping to keep Cygwin going. I found it when it 
was ver. b17 because I was looking for a way to run Joseph Allen's 
editor (joe) on Windows and keep all the nice POSIX features. It's been 
quite a ride ever since. I'll probably be around for a little while yet, 
long as I can build stuff for the old Cygwin without too much trouble. 
Goodness help me, though, if I ever get to the point where I find myself 
sitting in a wheelchair, staring at a wall.


Cheers,

Jeff

--
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: Different representations of time in ls -l and date(1)

[Corinna Vinschen]

On Aug 31 15:23, Schwarz, Konrad wrote:
> > -Original Message-
> > > > So my problem is that date(1) outputs AM/PM style dates, whereas ls
> > > > -
> > > l
> > > > uses 24 hour times.
> > > >
> > > > $ ls -l rtos_benchmark.lst
> > > > -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14
> > > > rtos_benchmark.lst*
> > > > $ date
> > > > Wed, Aug 31, 2016  1:39:35 PM
> > > > $ echo $LC_TIME
> > > >
> > > > $ echo $LANG
> > > > en_US.UTF-8
> > > >
> > > > Shouldn't they be using the same format?
> > >
> > > Further experimentation shows that they do indeed use the same format
> > > in the POSIX locale, (LANG=C), as required by that standard.
> > >
> > > However, I still think it is an ugly inconsistency for them to differ
> > > in the en_US.UTF-8 locale (which I assume is the default locale in
> > > Cygwin).
> > 
> > Still further investigation shows that on SUSE Linux, with
> > LANG=en_US.UTF-8, both of these utilities consistently, if counter-
> > intuitively, display 24 hour time.
> > 
> > So I think the problem lies in Cygwin's locale database.
> 
> [Cygwin's locale database is Windows' locale database]
> 
> On my Windows 7 machine, Control Panel, Region and Language, Formats shows
> Short time: h:mm tt
> Long time: h:mm:ss tt
> AM Symbol: AM
> PM Symbol: PM
> 
> This is the standard English (United States) setting.
> 24 hour format is represented in Windows by either H:mm or HH:mm.
> 
> Shouldn't ls -l therefore be using a 12 hour format?

Cygwin has a conversion routine, which converts the Windows date/time
input strings to POSIX-compatible strftime strings for digestion by
applicatrions calling nl_langinfo.

I just checked:

  Input:  "h:mm:ss tt"
  Output: "%l:%M:%S %p"

This looks pretty much like a 12hour AM?PM format to me.

If ls uses what Cygwin provides for the default time format, then it
does.  But note Eric's mail in this thread:
https://cygwin.com/ml/cygwin/2016-08/msg00630.html


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[ANNOUNCEMENT] Updated: setup.exe (Release 2.875)

[Corinna Vinschen]

A new version of Setup, release 2.875, has been uploaded to

  https://cygwin.com/setup-x86.exe (32 bit version)
  https://cygwin.com/setup-x86_64.exe  (64 bit version)

Changes compared to 2.874:

- Layout changes in the chooser window header

- Improved search field:  You can now type as fast as you can, the
  actual search is only performed after you stopped typing for about
  half a second.

- Fix setup reading all available setup.ini files in a directory.
  Only read the first found.

- Fix progress report bar during dependency check.

- Add a new view, showing all packages which have been picked for
  installation, not installed as dependencies.  This information may be
  used in future for other uses.

- Use a drop-down menu to select the views.


Please send bug reports, as usual, to the public mailing list cygwin AT
cygwin DOT com.


Have fun,
Corinna

--
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

Updated: setup.exe (Release 2.875)

[Corinna Vinschen]

A new version of Setup, release 2.875, has been uploaded to

  https://cygwin.com/setup-x86.exe (32 bit version)
  https://cygwin.com/setup-x86_64.exe  (64 bit version)

Changes compared to 2.874:

- Layout changes in the chooser window header

- Improved search field:  You can now type as fast as you can, the
  actual search is only performed after you stopped typing for about
  half a second.

- Fix setup reading all available setup.ini files in a directory.
  Only read the first found.

- Fix progress report bar during dependency check.

- Add a new view, showing all packages which have been picked for
  installation, not installed as dependencies.  This information may be
  used in future for other uses.

- Use a drop-down menu to select the views.


Please send bug reports, as usual, to the public mailing list cygwin AT
cygwin DOT com.


Have fun,
Corinna

Re: Different representations of time in ls -l and date(1)

[Erik Soderquist]

On Wed, Aug 31, 2016 at 10:45 AM, Eric Blake wrote:
> So, the answer to your question is determined by what your locale thinks
> is the appropriate representation; and I have no control over whether
> Windows' locale defaults will match glibc's locale defaults for en_US or
> any other locale outside of C.


It is because I have been burned on this (world wide customers) that I
know explicitly specify the format I want to work with in my scripts
and disregard whatever the local is.

-- Erik

--
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: Different representations of time in ls -l and date(1)

[Schwarz, Konrad]

> -Original Message-
> > > So my problem is that date(1) outputs AM/PM style dates, whereas ls
> > > -
> > l
> > > uses 24 hour times.
> > >
> > > $ ls -l rtos_benchmark.lst
> > > -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14
> > > rtos_benchmark.lst*
> > > $ date
> > > Wed, Aug 31, 2016  1:39:35 PM
> > > $ echo $LC_TIME
> > >
> > > $ echo $LANG
> > > en_US.UTF-8
> > >
> > > Shouldn't they be using the same format?
> >
> > Further experimentation shows that they do indeed use the same format
> > in the POSIX locale, (LANG=C), as required by that standard.
> >
> > However, I still think it is an ugly inconsistency for them to differ
> > in the en_US.UTF-8 locale (which I assume is the default locale in
> > Cygwin).
> 
> Still further investigation shows that on SUSE Linux, with
> LANG=en_US.UTF-8, both of these utilities consistently, if counter-
> intuitively, display 24 hour time.
> 
> So I think the problem lies in Cygwin's locale database.

[Cygwin's locale database is Windows' locale database]

On my Windows 7 machine, Control Panel, Region and Language, Formats shows
Short time: h:mm tt
Long time: h:mm:ss tt
AM Symbol: AM
PM Symbol: PM

This is the standard English (United States) setting.
24 hour format is represented in Windows by either H:mm or HH:mm.

Shouldn't ls -l therefore be using a 12 hour format?

--
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: Different representations of time in ls -l and date(1)

[Brian Inglis]

On 2016-08-31 07:04, Frank Farance wrote:

On 2016-08-31 08:09, Markus Hoenicka wrote:

At 2016-08-31 13:41, Schwarz, Konrad was heard to say:

Sorry for the previous incomplete mail.
So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
uses 24 hour times.
$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME
$ echo $LANG
en_US.UTF-8
Shouldn't they be using the same format?

date has a ton of options to format the output including the 12/24 h style, ,
see 'man date'.

You have misunderstood the question.
Question Intended: Why are they different?
Incorrectly Interpreted: There are lots of options for "ls" and "date".
I have everything in 24-hour format, yet my LC_TIME and LANG are the same as 
Konrad.
Furthermore, I'd say that the default output of "date" should look like the 
Linux one, which is the way it has looked on UNIX for about 40 years:
Linux: Wed Aug 31 08:56:10 EDT 2016
Cygwin: Wed, Aug 31, 2016 08:54:49
In other words, on Cygwin: get rid of the commas, put back the timezone.


POSIX specifies that locale settings are used by default in date and ls.
In the case of date, that appears to be Windows regional settings long date 
time, with
abbreviated words, as I have no idea where else it could be getting that custom 
format.
In ls, I appear to be getting the POSIX default.
POSIX also says that LC_ALL overrides LC_TIME overrides LANG, so if you have 
LC_ALL set,
you can only override it with LC_ALL e.g. "LC_ALL=C date" to get the default 
format.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Different representations of time in ls -l and date(1)

[Corinna Vinschen]

On Aug 31 09:36, Eric Blake wrote:
> On 08/31/2016 08:04 AM, Frank Farance wrote:
> > On 2016-08-31 08:09, Markus Hoenicka wrote:
> >> At 2016-08-31 13:41, Schwarz, Konrad was heard to say:
> >>> Sorry for the previous incomplete mail.
> >>>
> >>> So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
> >>> uses 24 hour times.
> >>>
> >>> $ ls -l rtos_benchmark.lst
> >>> -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
> >>> $ date
> >>> Wed, Aug 31, 2016  1:39:35 PM
> >>> $ echo $LC_TIME
> >>>
> >>> $ echo $LANG
> >>> en_US.UTF-8
> >>>
> >>> Shouldn't they be using the same format?
> 
> Not necessarily.  ls hardcodes its default representation for files
> younger than 6 months to:
> 
> "%b %e %H:%M"
> 
> while date hardcodes its default representation to:
> 
> nl_langinfo(_DATE_FMT)
> 
> > 
> > Furthermore, I'd say that the default output of "date" should look like
> > the Linux one, which is the way it has looked on UNIX for about 40 years:
> > 
> > Linux: Wed Aug 31 08:56:10 EDT 2016
> > Cygwin: Wed, Aug 31, 2016 08:54:49
> > 
> > In other words, on Cygwin: get rid of the commas, put back the timezone.
> 
> Sounds like the bug is in cygwin1.dll's nl_langinfo() function for
> returning a date format with spurious commas.

Windows LOCALE_SLONGDATE contains these commas in the en-US locale.

Outside of the "C"/"POSIX" locale the expectation of identical date/time
strings on different platforms is not feasible.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Different representations of time in ls -l and date(1)

[Eric Blake]

On 08/31/2016 09:36 AM, Eric Blake wrote:

> Not necessarily.  ls hardcodes its default representation for files
> younger than 6 months to:
> 
> "%b %e %H:%M"
> 
> while date hardcodes its default representation to:
> 
> nl_langinfo(_DATE_FMT)
> 

Except that I just tested, and nl_langinfo(_DATE_FMT) for both Cygwin
and Linux is

%a %b %e %H:%M:%S %Z %Y

so something else weird is going on.

Oh duh, it's locales!  nl_langinfo() is locale-specific, and you are
(probably) running in a default locale of en_US rather than the C locale.

$ date
Wed, Aug 31, 2016  9:39:55 AM
$ LC_ALL=C
Wed Aug 31 09:43:42 CDT 2016

So, the answer to your question is determined by what your locale thinks
is the appropriate representation; and I have no control over whether
Windows' locale defaults will match glibc's locale defaults for en_US or
any other locale outside of C.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Different representations of time in ls -l and date(1)

[Eric Blake]

On 08/31/2016 08:04 AM, Frank Farance wrote:
> On 2016-08-31 08:09, Markus Hoenicka wrote:
>> At 2016-08-31 13:41, Schwarz, Konrad was heard to say:
>>> Sorry for the previous incomplete mail.
>>>
>>> So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
>>> uses 24 hour times.
>>>
>>> $ ls -l rtos_benchmark.lst
>>> -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
>>> $ date
>>> Wed, Aug 31, 2016  1:39:35 PM
>>> $ echo $LC_TIME
>>>
>>> $ echo $LANG
>>> en_US.UTF-8
>>>
>>> Shouldn't they be using the same format?

Not necessarily.  ls hardcodes its default representation for files
younger than 6 months to:

"%b %e %H:%M"

while date hardcodes its default representation to:

nl_langinfo(_DATE_FMT)

> 
> Furthermore, I'd say that the default output of "date" should look like
> the Linux one, which is the way it has looked on UNIX for about 40 years:
> 
> Linux: Wed Aug 31 08:56:10 EDT 2016
> Cygwin: Wed, Aug 31, 2016 08:54:49
> 
> In other words, on Cygwin: get rid of the commas, put back the timezone.

Sounds like the bug is in cygwin1.dll's nl_langinfo() function for
returning a date format with spurious commas.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Different representations of time in ls -l and date(1)

[Corinna Vinschen]

On Aug 31 14:23, Schwarz, Konrad wrote:
> > -Original Message-
> > From: Schwarz, Konrad (CT RDA ITP SES-DE)
> > Sent: Wednesday, August 31, 2016 2:51 PM
> > To: 'cygwin@cygwin.com'
> > Subject: RE: Different representations of time in ls -l and date(1)
> > 
> > > -Original Message-
> > > From: Schwarz, Konrad (CT RDA ITP SES-DE)
> > > Sent: Wednesday, August 31, 2016 1:42 PM
> > > To: 'cygwin@cygwin.com'
> > > Subject: RE: Different representations of time in ls -l and date(1)
> > >
> > > Sorry for the previous incomplete mail.
> > >
> > > So my problem is that date(1) outputs AM/PM style dates, whereas ls -
> > l
> > > uses 24 hour times.
> > >
> > > $ ls -l rtos_benchmark.lst
> > > -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14
> > > rtos_benchmark.lst*
> > > $ date
> > > Wed, Aug 31, 2016  1:39:35 PM
> > > $ echo $LC_TIME
> > >
> > > $ echo $LANG
> > > en_US.UTF-8
> > >
> > > Shouldn't they be using the same format?
> > 
> > Further experimentation shows that they
> > do indeed use the same format in the POSIX locale, (LANG=C), as
> > required by that standard.
> > 
> > However, I still think it is an ugly inconsistency for them to differ
> > in the en_US.UTF-8 locale (which I assume is the default locale in
> > Cygwin).
> 
> Still further investigation shows that on SUSE Linux, with LANG=en_US.UTF-8,
> both of these utilities consistently, if counter-intuitively, display 24 hour 
> time.
> 
> So I think the problem lies in Cygwin's locale database.

If so, it would be Window's locale database.  Apart from information
not available on Windows (era and messages info) all other locale
info is fetched from Windows.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

RE: Different representations of time in ls -l and date(1)

[Schwarz, Konrad]

> -Original Message-
> From: Schwarz, Konrad (CT RDA ITP SES-DE)
> Sent: Wednesday, August 31, 2016 2:51 PM
> To: 'cygwin@cygwin.com'
> Subject: RE: Different representations of time in ls -l and date(1)
> 
> > -Original Message-
> > From: Schwarz, Konrad (CT RDA ITP SES-DE)
> > Sent: Wednesday, August 31, 2016 1:42 PM
> > To: 'cygwin@cygwin.com'
> > Subject: RE: Different representations of time in ls -l and date(1)
> >
> > Sorry for the previous incomplete mail.
> >
> > So my problem is that date(1) outputs AM/PM style dates, whereas ls -
> l
> > uses 24 hour times.
> >
> > $ ls -l rtos_benchmark.lst
> > -rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14
> > rtos_benchmark.lst*
> > $ date
> > Wed, Aug 31, 2016  1:39:35 PM
> > $ echo $LC_TIME
> >
> > $ echo $LANG
> > en_US.UTF-8
> >
> > Shouldn't they be using the same format?
> 
> Further experimentation shows that they
> do indeed use the same format in the POSIX locale, (LANG=C), as
> required by that standard.
> 
> However, I still think it is an ugly inconsistency for them to differ
> in the en_US.UTF-8 locale (which I assume is the default locale in
> Cygwin).

Still further investigation shows that on SUSE Linux, with LANG=en_US.UTF-8,
both of these utilities consistently, if counter-intuitively, display 24 hour 
time.

So I think the problem lies in Cygwin's locale database.

--
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: Cygwin 2.6.0-1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin release 2.6.0-1.

Please note that this release won't work on Windows XP and Windows
Server 2003 or 2003 R2.  At least Windows Vista or Windows Server 2008
are required.


What's new:
---

- Support for POSIX-1.2008 locale objects and per-thread locales.

  New API per POSIX-1.2008: newlocale, freelocale, duplocale, uselocale,
  nl_langinfo_l, isalnum_l, isalpha_l, isblank_l, iscntrl_l, isdigit_l,
  isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l, iswalnum_l,
  iswalpha_l, iswblank_l, iswcntrl_l, iswctype_l, iswdigit_l, iswgraph_l,
  iswlower_l, iswprint_l, iswpunct_l, iswspace_l, iswupper_l, iswxdigit_l,
  isxdigit_l, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l,
  wctrans_l, wctype_l, strcasecmp_l, strcoll_l, strerror_l, strfmon_l,
  strftime_l, strncasecmp_l, strxfrm_l, wcscasecmp_l, wcscoll_l,
  wcstrncasecmp_l, wcstrxfrm_l.

  New API, GNU extensions: isascii_l, toascii_l, strptime_l, strtod_l,
  strtof_l, strtol_l, strtold_l, strtoll_l, strtoul_l, strtoull_l, wcsftime_l,
  wcstod_l, wcstof_l, wcstol_l, wcstold_l, wcstoll_l, wcstoul_l, wcstoull_l.

- locale(1) now supports a -i/--input option to fetch the current input
  locale (this is basically equivalent to the current keyboard layout setting).

- New API: pthread_getname_np, pthread_setname_np.


What changed:
-

- Drop support for Windows XP and Windows Server 2003/2003 R2.

- Drop support for very old SUNWNFS filesystem.

- Further header file improvements in terms of feature test macros.

- Raise number of supported partitions per disk (for raw access) to 63.
  Addresses: https://cygwin.com/ml/cygwin/2016-06/msg00136.html

- Add a workaround for filesystems not supporting the FileAllInformation
  info class.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00350.html

- Support AzureAD accounts.

- "nobody" account support for WinFSP.


Bug Fixes
-

- Try to avoid spurious DENY ACEs when creating files in directories
  with non-POSIX-like (rather: Windows-like) permissions.
  Addresses: Report and reproducer on IRC.

- Make sure ldd(1) does not exit prematurely when enumerating DLLs.
  Addresses: https://cygwin.com/ml/cygwin/2016-05/msg00185.html

- Fix strace timer output in child process.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00067.html

- Change blkcnt_t to signed type per POSIX.

- Fix definition of SSIZE_MAX on 32-bit systems.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00179.html

- Fix transposing invalid chars in Windows filenames on relative paths.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00193.html

- Don't raise SIGTTIN from select(2)/poll(2).
  Addresses: https://cygwin.com/ml/cygwin-developers/2016-07/msg4.html

- Use correct FPU rounding mode in truncl.
  Addresses: https://rt.perl.org/Public/Bug/Display.html?id=128665

- Fix a regression in ioctl(fd, FIONREAD, ...) introduced in Cygwin 2.5.0.
  This only affects 64 bit Cygwin.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg1.html

- Handle "clear screen" escpae sequence in console window more reliable.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00310.html

- Allow kill(pid, ) on zombies to return successfully, rather than
  only kill(pid, 0), to align behaviour with POSIX requirements.
  Addresses: https://cygwin.com/ml/cygwin/2016-08/msg00188.html

- Fix off_t typedef on 64-bit.
  Addresses: https://sourceware.org/ml/newlib/2016/msg01028.html

- Fix weird problem running passwd on newer Windows versions.
  Addresses: https://cygwin.com/ml/cygwin/2016-08/msg00608.html


Thanks,
Corinna

-- 
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

Updated: Cygwin 2.6.0-1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin release 2.6.0-1.

Please note that this release won't work on Windows XP and Windows
Server 2003 or 2003 R2.  At least Windows Vista or Windows Server 2008
are required.


What's new:
---

- Support for POSIX-1.2008 locale objects and per-thread locales.

  New API per POSIX-1.2008: newlocale, freelocale, duplocale, uselocale,
  nl_langinfo_l, isalnum_l, isalpha_l, isblank_l, iscntrl_l, isdigit_l,
  isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l, iswalnum_l,
  iswalpha_l, iswblank_l, iswcntrl_l, iswctype_l, iswdigit_l, iswgraph_l,
  iswlower_l, iswprint_l, iswpunct_l, iswspace_l, iswupper_l, iswxdigit_l,
  isxdigit_l, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l,
  wctrans_l, wctype_l, strcasecmp_l, strcoll_l, strerror_l, strfmon_l,
  strftime_l, strncasecmp_l, strxfrm_l, wcscasecmp_l, wcscoll_l,
  wcstrncasecmp_l, wcstrxfrm_l.

  New API, GNU extensions: isascii_l, toascii_l, strptime_l, strtod_l,
  strtof_l, strtol_l, strtold_l, strtoll_l, strtoul_l, strtoull_l, wcsftime_l,
  wcstod_l, wcstof_l, wcstol_l, wcstold_l, wcstoll_l, wcstoul_l, wcstoull_l.

- locale(1) now supports a -i/--input option to fetch the current input
  locale (this is basically equivalent to the current keyboard layout setting).

- New API: pthread_getname_np, pthread_setname_np.


What changed:
-

- Drop support for Windows XP and Windows Server 2003/2003 R2.

- Drop support for very old SUNWNFS filesystem.

- Further header file improvements in terms of feature test macros.

- Raise number of supported partitions per disk (for raw access) to 63.
  Addresses: https://cygwin.com/ml/cygwin/2016-06/msg00136.html

- Add a workaround for filesystems not supporting the FileAllInformation
  info class.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00350.html

- Support AzureAD accounts.

- "nobody" account support for WinFSP.


Bug Fixes
-

- Try to avoid spurious DENY ACEs when creating files in directories
  with non-POSIX-like (rather: Windows-like) permissions.
  Addresses: Report and reproducer on IRC.

- Make sure ldd(1) does not exit prematurely when enumerating DLLs.
  Addresses: https://cygwin.com/ml/cygwin/2016-05/msg00185.html

- Fix strace timer output in child process.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00067.html

- Change blkcnt_t to signed type per POSIX.

- Fix definition of SSIZE_MAX on 32-bit systems.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00179.html

- Fix transposing invalid chars in Windows filenames on relative paths.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00193.html

- Don't raise SIGTTIN from select(2)/poll(2).
  Addresses: https://cygwin.com/ml/cygwin-developers/2016-07/msg4.html

- Use correct FPU rounding mode in truncl.
  Addresses: https://rt.perl.org/Public/Bug/Display.html?id=128665

- Fix a regression in ioctl(fd, FIONREAD, ...) introduced in Cygwin 2.5.0.
  This only affects 64 bit Cygwin.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg1.html

- Handle "clear screen" escpae sequence in console window more reliable.
  Addresses: https://cygwin.com/ml/cygwin/2016-07/msg00310.html

- Allow kill(pid, ) on zombies to return successfully, rather than
  only kill(pid, 0), to align behaviour with POSIX requirements.
  Addresses: https://cygwin.com/ml/cygwin/2016-08/msg00188.html

- Fix off_t typedef on 64-bit.
  Addresses: https://sourceware.org/ml/newlib/2016/msg01028.html

- Fix weird problem running passwd on newer Windows versions.
  Addresses: https://cygwin.com/ml/cygwin/2016-08/msg00608.html


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

Re: Different representations of time in ls -l and date(1)

[Frank Farance]

On 2016-08-31 08:09, Markus Hoenicka wrote:

At 2016-08-31 13:41, Schwarz, Konrad was heard to say:

Sorry for the previous incomplete mail.

So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
uses 24 hour times.

$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME

$ echo $LANG
en_US.UTF-8

Shouldn't they be using the same format?

--
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


date has a ton of options to format the output including the 12/24 h style, ,
see 'man date'.

regards,
Markus




Markus and Marco-

You have misunderstood the question.

Question Intended: Why are they different?
Incorrectly Interpreted: There are lots of options for "ls" and "date".

I have everything in 24-hour format, yet my LC_TIME and LANG are the same as 
Konrad.

Furthermore, I'd say that the default output of "date" should look like the 
Linux one, which is the way it has looked on UNIX for about 40 years:


Linux: Wed Aug 31 08:56:10 EDT 2016
Cygwin: Wed, Aug 31, 2016 08:54:49

In other words, on Cygwin: get rid of the commas, put back the timezone.

-FF

--
__
Frank Farance, Farance Inc.T: +1 212 486 4700   M: +1 917 751 2900
mailto:fr...@farance.com   http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: passwd unrecoverable error 1265

[Corinna Vinschen]

On Aug 31 14:12, Vlado wrote:
> On 31.8.2016 12:16, Corinna Vinschen wrote:
> > I found a workaround:  The Windows call for changing the password used
> > by the passwd tool is
> > 
> >   ret = NetUserChangePassowrd (server, username, old_pwd, new_pwd);
> > 
> > The server is usually the logon server, prepended by double backslash,
> > as in the variable $LOGONSERVER, and this is how passwd uses the function.
> > However, while this still works fine on W7 and 2008R2, it fails on the
> > newer systems with error 1265, ERROR_DOWNGRADE_DETECTED.
> > 
> > The workaround puzzles me slightly, but it seems to do the trick:
> > If I use the domain name (as in $USERDOMAIN) instead of the server
> > name when calling this function, it works as expected, also on W7
> > or 2008R2.
> 
> Thank You for very useful information.
> 
> I tried Your workaround and it works perfectly for me:
>   test@server ~
>   $ LOGONSERVER=server passwd
>   Old password:
>   New password:
>   Re-enter new password:
>   Password changed.
> 
>   test@server ~
>   $
> 
> (Old value in $LOGONSERVER was \\server)
> 
> My server is standalone Windows Server 2008R2 Enterprise, so Microsoft's
> error message is not quite correct.
> 
> (On Yours 2008R2 problem didn't occur - interesting.)

Yeah, I have no idea why :(


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Different representations of time in ls -l and date(1)

[Marco Atzeri]

On 31/08/2016 14:09, Markus Hoenicka wrote:

At 2016-08-31 13:41, Schwarz, Konrad was heard to say:

Sorry for the previous incomplete mail.

So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
uses 24 hour times.

$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME

$ echo $LANG
en_US.UTF-8

Shouldn't they be using the same format?





date has a ton of options to format the output including the 12/24 h
style, , see 'man date'.

regards,
Markus



same for ls.

Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: passwd unrecoverable error 1265

[Vlado]

On 31.8.2016 12:16, Corinna Vinschen wrote:

I found a workaround:  The Windows call for changing the password used
by the passwd tool is

  ret = NetUserChangePassowrd (server, username, old_pwd, new_pwd);

The server is usually the logon server, prepended by double backslash,
as in the variable $LOGONSERVER, and this is how passwd uses the function.
However, while this still works fine on W7 and 2008R2, it fails on the
newer systems with error 1265, ERROR_DOWNGRADE_DETECTED.

The workaround puzzles me slightly, but it seems to do the trick:
If I use the domain name (as in $USERDOMAIN) instead of the server
name when calling this function, it works as expected, also on W7
or 2008R2.


Thank You for very useful information.

I tried Your workaround and it works perfectly for me:
test@server ~
$ LOGONSERVER=server passwd
Old password:
New password:
Re-enter new password:
Password changed.

test@server ~
$

(Old value in $LOGONSERVER was \\server)

My server is standalone Windows Server 2008R2 Enterprise, so Microsoft's 
error message is not quite correct.


(On Yours 2008R2 problem didn't occur - interesting.)

Thank You.

Vlado

--
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: Different representations of time in ls -l and date(1)

[Markus Hoenicka]

At 2016-08-31 13:41, Schwarz, Konrad was heard to say:

Sorry for the previous incomplete mail.

So my problem is that date(1) outputs AM/PM style dates, whereas ls -l
uses 24 hour times.

$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 
rtos_benchmark.lst*

$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME

$ echo $LANG
en_US.UTF-8

Shouldn't they be using the same format?

--
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


date has a ton of options to format the output including the 12/24 h 
style, , see 'man date'.


regards,
Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
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: Different representations of time in ls -l and date(1)

[Schwarz, Konrad]

Sorry for the previous incomplete mail.

So my problem is that date(1) outputs AM/PM style dates, whereas ls -l uses 24 
hour times.

$ ls -l rtos_benchmark.lst
-rwxr-xr-x+ 1 mchn1350 Domain Users 263 Aug 31 13:14 rtos_benchmark.lst*
$ date
Wed, Aug 31, 2016  1:39:35 PM
$ echo $LC_TIME

$ echo $LANG
en_US.UTF-8

Shouldn't they be using the same format?

--
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] openssl 1.0.2h-1

[Corinna Vinschen]

On Aug 31 12:50, Gerrit Haase wrote:
> 2016-05-04 19:35 GMT+02:00 Yaakov Selkowitz:
> >
> > The following packages have been uploaded to the Cygwin distribution:
> >
> > * openssl-1.0.2h-1
> > * openssl-devel-1.0.2h-1
> > * openssl-perl-1.0.2h-1
> > * libopenssl100-1.0.2h-1
> > * mingw64-i686-openssl-1.0.2h-1
> > * mingw64-x86_64-openssl-1.0.2h-1
> >
> > ...
> 
> 
> Hello Yaakov,
> 
> 25-Aug-2016: OpenSSL 1.1.0 is now available

We can't and we won't switch to OpenSSH 1.1.0 unless at least the first
problems are ironed out.  There were a lot of partially backward
incompatible changes, one of them results in OpenSSH not working with
OpenSSL 1.1.0 yet.

So, for the time being, we stay with 1.0.2.  It will be supported by
upstream for at least another two years, so there's no reason for hurry.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] openssl 1.0.2h-1

[Gerrit Haase]

2016-05-04 19:35 GMT+02:00 Yaakov Selkowitz:
>
> The following packages have been uploaded to the Cygwin distribution:
>
> * openssl-1.0.2h-1
> * openssl-devel-1.0.2h-1
> * openssl-perl-1.0.2h-1
> * libopenssl100-1.0.2h-1
> * mingw64-i686-openssl-1.0.2h-1
> * mingw64-x86_64-openssl-1.0.2h-1
>
> ...


Hello Yaakov,

25-Aug-2016: OpenSSL 1.1.0 is now available

https://www.openssl.org/news/newslog.html


:-)
Gerrit

--
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 setup] Allow setup to parse more than 3 versions from the setup.ini file

[Jon Turney]

On 08/06/2015 14:43, Corinna Vinschen wrote:

On Jun  3 17:30, Jon TURNEY wrote:

Reminded by a recent request as to how to install xorg-server-1.17.1-2, which
has disappeared beyond setup's ken (in order to determine if there was a
regression in the curent version), this is a re-send of a patch I originally
submitted back in 2011 [1], which received an ambiguous response then.

[1] https://cygwin.com/ml/cygwin-apps/2011-04/msg00053.html

This recognizes any "[foo]" line as introducing the information for another
version, which doesn't have one of the trust levels [curr], [prev] or [test],
and so isn't automatically selected when setup is told to install all packages
at that trust level (by default, [curr]).

Setup already does all the neccessary sorting in version order etc. to use these
additional versions.

Since the value of  carries no meaning, it might make sense to update the
setup.ini specification to mandate the use of specific strings like "[also]" or
"[other]", or perhaps "[prev-1]", "[prev-2]", etc.

I have written a corresponding patch to genini.

I'm not sure what expiry policy is currently used by upset for old packages, but
presumably that would need to be made more sophisticated, along with the changes
needed to generate setup.ini entries for other versions.


Upset does not handle expiry of packages at all.  Versions are mentioned
in setup.hint as test, curr, prev, or exp (yes, really) and those are
handled, everything else throws an error message.  Package versions not
mentioned in setup.hint are simply ignored.


Yes, upset doesn't (didn't) explicitly handle expiry, but the fact that 
a package version is not mentioned in setup.ini causes it to be removed 
by stalepkgs, when that is next run.


After the corresponding change to setup.ini generation, it will list all 
versions, so none would ever be eligible for expiry under that policy.


Anyhow, improving that is close to the top of my hit-list for calm.


I'm not against adding some functionality along these lines (provided
you also fix upset), but I'm not so sure about the broad definition of
the version state pattern.  It feels as generating problems down the
road.  Think setup.hint.  Your patch would requite to recognize more or
less any string as version state:

  category: [...]
  requires: [...]
  sdesc: [...]
  ldesc: [...]
  prev: 1.2.3-1
  curr: 1.2.4-1
  test: 1.2.5-1
  blub: 1.2.6-1
  fwexf3efx24x: 1.2.7-1


I wasn't envisioning these labels appearing in setup.hint at all, since 
that only gives the information 'this version exists', which is already 
apparent from the existence of the package file.


(In fact, even 'prev' has no real meaning any more since the removal of 
the 'prev' stability selector in setup [1], apart from 'don't expire me')


Nevertheless, you are correct, so (by specification) let's restrict the 
label to 'ver'.


I should also have mentioned that existing versions of setup cannot 
parse setup.ini with these extra labels (reporting an error and asking 
'do you have the latest setup?'), so it would be nice to get this into 
setup sooner rather than later, if possible.


[1] 
https://sourceware.org/git/?p=cygwin-setup.git;a=commit;h=ec9c1d708418e05c4ba02b58a9869f1e232ad381

Re: passwd unrecoverable error 1265

[Corinna Vinschen]

On Aug 30 20:20, Vlado wrote:
> Hello.
> 
> I have few users with sshd-only access to server.  They use passwd when
> changing passwords.
> 
> passwd is not working anymore for regular user (remote connection with
> PuTTy):
> 
>  test@server ~
>  $ passwd
>  Old password:
>  New password:
>  Re-enter new password:
>  passwd: unrecoverable error 1265

That's a windows error code.  1265 means ERROR_DOWNGRADE_DETECTED, the
officiale error message being:

  The system cannot contact a domain controller to service the
  authentication request. Please try again later.

I can reproduce this problem, but not on all machines. It occurs on W10,
on 2012R2, on W8.1, but it does not occur on W7 or 2008R2.

I found a workaround:  The Windows call for changing the password used
by the passwd tool is

  ret = NetUserChangePassowrd (server, username, old_pwd, new_pwd);

The server is usually the logon server, prepended by double backslash,
as in the variable $LOGONSERVER, and this is how passwd uses the function.
However, while this still works fine on W7 and 2008R2, it fails on the
newer systems with error 1265, ERROR_DOWNGRADE_DETECTED.

The workaround puzzles me slightly, but it seems to do the trick:
If I use the domain name (as in $USERDOMAIN) instead of the server
name when calling this function, it works as expected, also on W7
or 2008R2.

I applied the workaround which will be in passwd of the soon to be
released Cygwin 2.6.0.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] strace: Don't print exception info for SetThreadName exception

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a157df316546ac77207b2a3c5eb08fa140643866

commit a157df316546ac77207b2a3c5eb08fa140643866
Author: Corinna Vinschen 
Date:   Wed Aug 31 12:15:29 2016 +0200

strace: Don't print exception info for SetThreadName exception

The new functionality to set the thread name for debugging purposes
creates exception debugging events.  These are printed out when running
strace.  Since these exceptions have nothing to do with real exceptions
but are, like breakpoint execptions, expected and non-fatal, don't print
exception info for them.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/utils/strace.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/winsup/utils/strace.cc b/winsup/utils/strace.cc
index b193cfe..5d4a23d 100644
--- a/winsup/utils/strace.cc
+++ b/winsup/utils/strace.cc
@@ -751,15 +751,19 @@ proc_child (unsigned mask, FILE *ofile, pid_t pid)
  break;
 
case EXCEPTION_DEBUG_EVENT:
- if (ev.u.Exception.ExceptionRecord.ExceptionCode
- != (DWORD) STATUS_BREAKPOINT)
+ switch (ev.u.Exception.ExceptionRecord.ExceptionCode)
{
+   case STATUS_BREAKPOINT:
+   case 0x406d1388:/* SetThreadName exception. */
+ break;
+   default:
  status = DBG_EXCEPTION_NOT_HANDLED;
  if (ev.u.Exception.dwFirstChance)
fprintf (ofile, "--- Process %lu, exception %08lx at %p\n",
 ev.dwProcessId,
 ev.u.Exception.ExceptionRecord.ExceptionCode,
 ev.u.Exception.ExceptionRecord.ExceptionAddress);
+ break;
}
  break;
}

[newlib-cygwin] Fix passwd getting error 1265 when running on newer Windows

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=472e5439e7c7c7ecb552149de494f91540b55f8b

commit 472e5439e7c7c7ecb552149de494f91540b55f8b
Author: Corinna Vinschen 
Date:   Wed Aug 31 12:08:34 2016 +0200

Fix passwd getting error 1265 when running on newer Windows

On Windows 8.1 and later, the NetUserChangePassword call apparently
doesn't accept the usual "\\server" string anymore, but requires to
use the "domain" instead, otherwise it emits en error code 1265,
ERROR_DOWNGRADE_DETECTED.  Since this is accepted by pre-8.1 as well,
use the domain indiscriminately when calling NetUserChangePassword
from passwd(1).

While at it, do some minor cleanup in passwd.c.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.6.0 |  3 ++
 winsup/utils/passwd.c   | 92 -
 2 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/winsup/cygwin/release/2.6.0 b/winsup/cygwin/release/2.6.0
index eb39f8f..ffa6c17 100644
--- a/winsup/cygwin/release/2.6.0
+++ b/winsup/cygwin/release/2.6.0
@@ -84,3 +84,6 @@ Bug Fixes
 
 - Fix off_t typedef on 64-bit.
   Addresses: https://sourceware.org/ml/newlib/2016/msg01028.html
+
+- Fix weird problem running passwd on newer Windows versions.
+  Addresses: https://cygwin.com/ml/cygwin/2016-08/msg00608.html
diff --git a/winsup/utils/passwd.c b/winsup/utils/passwd.c
index 9510be5..70778b8 100644
--- a/winsup/utils/passwd.c
+++ b/winsup/utils/passwd.c
@@ -113,57 +113,57 @@ EvalRet (int ret, const char *user)
 }
 
 PUSER_INFO_3
-GetPW (char *user, int print_win_name, LPWSTR *server)
+GetPW (char *user, int print_win_name, LPWSTR *server, LPWSTR domain)
 {
   char usr_buf[UNLEN + 1];
   WCHAR name[UNLEN + 1];
   DWORD ret;
   PUSER_INFO_3 ui;
   struct passwd *pw;
-  char *domain = (char *) alloca (INTERNET_MAX_HOST_NAME_LENGTH + 1);
+  char dom[INTERNET_MAX_HOST_NAME_LENGTH + 1];
 
   /* Get the Win32 username and a suitable server. */
-  if ((pw = getpwnam (user)))
+  pw = getpwnam (user);
+  if (!pw)
 {
-  cygwin_internal (CW_EXTRACT_DOMAIN_AND_USER, pw, domain, usr_buf);
-  if (strcasecmp (pw->pw_name, usr_buf))
-   {
- /* Hack to avoid problem with LookupAccountSid after impersonation */
- if (strcasecmp (usr_buf, "SYSTEM"))
-   {
- user = usr_buf;
- if (print_win_name)
-   printf ("Windows username : %s\n", user);
-   }
-   }
-  if (!*server)
-   {
- PDOMAIN_CONTROLLER_INFOW dci;
- char machine[INTERNET_MAX_HOST_NAME_LENGTH + 1];
- DWORD mlen = sizeof machine;
- WCHAR wdom[INTERNET_MAX_HOST_NAME_LENGTH + 1];
-
- /* If we can't fetch the local machine name, or if the machine name
-is not the same as the user's domain name, try to fetch the DC via
-DsGetDcName.  Otherwise, just stick to a NULL servername, since
-that's the same as using the local machine. */
- if (!GetComputerNameExA (ComputerNameNetBIOS, machine, )
- || strcasecmp (domain, machine) != 0)
-   {
- mbstowcs (wdom, domain, INTERNET_MAX_HOST_NAME_LENGTH + 1);
- if (!DsGetDcNameW (NULL, wdom, NULL, NULL, DS_IS_FLAT_NAME, ))
-   *server = dci->DomainControllerName;
-   }
-   }
+  EvalRet (NERR_UserNotFound, user);
+  return NULL;
+}
+
+  cygwin_internal (CW_EXTRACT_DOMAIN_AND_USER, pw, dom, usr_buf);
+  /* Hack to avoid problem with LookupAccountSid after impersonation
+ using the simple NtCreateToken method. */
+  if (strcasecmp (pw->pw_name, usr_buf) && strcasecmp (usr_buf, "SYSTEM"))
+{
+  user = usr_buf;
+  if (print_win_name)
+   printf ("Windows username : %s\n", user);
 }
   mbstowcs (name, user, UNLEN + 1);
+  mbstowcs (domain, dom, INTERNET_MAX_HOST_NAME_LENGTH + 1);
+  if (!*server)
+{
+  PDOMAIN_CONTROLLER_INFOW dci;
+  WCHAR machine[INTERNET_MAX_HOST_NAME_LENGTH + 1];
+  DWORD mlen = INTERNET_MAX_HOST_NAME_LENGTH + 1;
+
+  /* If the machine name is not the same as the user's domain name we're
+in a domain.  Fetch the DC via DsGetDcName.  Otherwise, just stick
+to a NULL servername, since that's the same as using the local
+machine. */
+  if ((!GetComputerNameExW (ComputerNameNetBIOS, machine, )
+  || wcscasecmp (domain, machine) != 0)
+ && !DsGetDcNameW (NULL, domain, NULL, NULL, DS_IS_FLAT_NAME, ))
+   *server = dci->DomainControllerName;
+}
+
   ret = NetUserGetInfo (*server, name, 3, (void *) );
   return EvalRet (ret, user) ? NULL : ui;
 }
 
 int
-ChangePW (const char *user, PCWSTR name, const char *oldpwd, const char *pwd,
- int justcheck, LPCWSTR server)
+ChangePW (const char *user, PCWSTR domain, PCWSTR name, const char *oldpwd,
+ const char *pwd, int justcheck, PCWSTR server)
 {

Re: update_etc_shells gone from cygport?

[Corinna Vinschen]

On Aug 30 11:44, Yaakov Selkowitz wrote:
> On 2016-08-30 11:15, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > > update_etc_shells /bin/tcsh /bin/csh
> > > > 
> > > > But I think we need to coordinate this with an updated base-cygwin.
> > > 
> > > base-cygwin?  Not base-files?
> > 
> > The file /etc/shells is currently installed by base-files from
> > /etc/defaults/etc/shells unless it had been altered.  So if you invent a
> > mechanism to alter the contents of the file, /etc/shells will cease to
> > be handled in pre-remove and post-install of base-files automatically,
> > I'd think.  We could then remove it of course.
> 
> Yes, /etc/shells would end up staying once altered by update_etc_shells, but
> I don't see an issue with that.

Ok, guys, give the word when you do this.

Yaakov, if you want to do it during my absence I announced on
cygwin-developers, feel free to rebuild the tcsh package.  I pick up the
new cygport file when I'm back.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature