Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Brian Inglis]

On 2018-03-22 08:41, Ken Brown wrote:
> On 3/21/2018 8:35 PM, Brian Inglis wrote:
>> On 2018-03-21 12:14, Ken Brown wrote:
>>> On 3/20/2018 4:11 PM, Achim Gratz wrote:
 Ken Brown writes:
> I'll look into both of these issues, unless Jon beats me to it.

 Thanks.

> By the way, this only affects local installs.  For network installs,
> the hash gets checked at an earlier stage.

 That's correct.  I forgot to mention that, but all my installs are from
 a local mirror (necessary due to the way network access is restricted at
 my workplace)
>>>
>>> I haven't been able to come up with a safe way to recover from a checksum 
>>> error
>>> at this point, at least not without a lot of work.  I propose that we just 
>>> bail
>>> out with an appropriate error message in this situation.
>>>
>>> Patch attached.
>>
>> Skipping a single package install is likely to be /relatively/ safe, but if 
>> this
>> patch causes setup to exit sometime after upgrading a bunch of packages but
>> before upgrading another bunch of packages, it could leave Cygwin unusable,
>> especially if there are upgrade dependencies between the packages installed
>> prior and not installed after the problematic download.
>>
>> It would be better in such cases to check all the hashes before proceeding 
>> with
>> any of the installs
> 
> We already do that.  My patch deals with the situation where we find a corrupt
> file during this process.

Sorry, it sounded like the check was happening during the install action,
instead of before. The process has changed now the solver is being used.

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

texlive-collection-basic requires Perl to be removed

[Steven Penny]

This package contains this file:

   /etc/preremove/texlive-collection-basic.sh

which in turn calls:

   /usr/libexec/update_tlpdb

which is a Perl script. I understand that "texlive-collection-basic" requires
"perl_base", but if a user removed Perl first then uninstallation of texlive
would fail. Perhaps "update_tlpdb" could be rewritten as a shell script.


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

Issues with setting or not setting HOME environment variable

[David Karr]

I currently do not set the HOME environment variable.  I get the
impression you're not supposed to do that.  When I run a mintty shell,
it correctly puts me in "/home/", which is what I want.

I'm running into a problem with Eclipse egit, as I think it's looking
for the "HOME" environment variable to determine where the .gitconfig
file is. If it doesn't find "HOME" set, I have a feeling it's looking
for "HOMEDRIVE", which is set to something I can't easily control.

Is there some way I can set "HOME" to my Windows home location, but
still have Cygwin do the right thing and go to "/home/"?

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

Re: setup 2.891release candidate - please test

[Robert Cohen]

---
From: Jon Turney 
...

Thanks for testing.

Yes, as I wrote in [1], this isn't more a missing feature and/or missing 
dependency information, than a bug in setup.

[1] https://cygwin.com/ml/cygwin/2018-03/msg00108.html
---

Hi Jon,

 Thanks for clarifying that.  For now, would it make sense for me to manually 
run /etc/postinstall/fontconfig_dtd.sh, or /etc/postinstall/libxml2.sh, or both 
after setup is complete, or should I just ignore the error?


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

Re: setup -g ???

[Jon Turney]

On 14/03/2018 15:26, David Allsopp wrote:

[reformatted for top-posting]

Lee wrote:

-- Forwarded message --
From: Jon Turney
Date: Fri, 3 Nov 2017 15:26:27 +
Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor
To: The Cygwin Mailing List 

On 03/11/2017 14:45, Vadim Zeitlin wrote:

Our build has started on AppVeyor, a continuous integration provider,
started failing since a couple of days as a makefile command running a
Python script started failing with exit code 127 without any more
information. This is a strange situation as I can't reproduce the
problem locally, but something definitely seems to be wrong with this
package on the AppVeyor machine as Python just doesn't seem to be
executable, e.g. the output of these commands in our batch file

driving the build:

Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's
setup.

Due to setup terribleness, without this flag, it will install the
requested packages, and any missing dependencies of them, but not
upgrade any of the dependencies which are already installed to the
current (and perhaps needed) version...

See also [1].

[1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html


Should we still be using the -g (--upgrade-also) flag on setup?


I believe so (or at least hope so). I think it's the case that setup should now 
know to upgrade a dependency if you install a new package which requires a 
newer version of it, but I hope that's not become the same as setup effectively 
acting with --upgrade-also every time you run it (that would be a real 
nuisance, unless the entire Cygwin package universe is going to be recompiled 
on every new Cygwin release).


This is basically correct.

setup is now capable of being told about dependencies where upgrading an 
already installed package is required, but this information isn't 
currently collected


(For example, some packages now exist (e.g. vim [1]), which were built 
with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost certainly 
use ssp/fortify functions in the cygwin DLL, and so require a cygwin 
package >=2.10.0-1 (technically, the requirement is cygwin API >=0.320), 
but the dependency recorded is only on the cygwin package at any version)


That's something someone could usefully work on, if they were so inclined.

So, yes, if you are using --packages, you should continue to use -g 
(unless you know what you are doing and/or like to live dangerously)


[1] https://cygwin.com/ml/cygwin/2018-03/msg00176.html

--
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: Quotes around command-line argument that has unicode characters are not removed

[Dmitry Katsubo via cygwin]

On 2018-03-22 18:10, Kaz Kylheku wrote:
> That may be so, yet there may be an issue here for someone packaging
> Cygwin programs for use as native Windows applications.
> 
> That is to say, there could potentially be something here that the Cygnal
> project could address:
> 
> http://www.kylheku.com/cygnal/
> 
> Cygnal is an ultra-light fork of the Cygwin DLL that is intended for users,
> who run Cygwin programs out of the Windows environment directly, after 
> building them in Cygwin.

Thanks for the hint. I confirm that just substituting cygwin1.dll makes
the test working:

D:\cli> test "текст плюс.txt"
param 0 = test
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened

I was not able to find any relevant difference in dcrt0.cc, but perhaps the
difference is in initial setting of locale (Cygnal initialization).

-- 
With best regards,
Dmitry

--
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: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Jon Turney]

On 21/03/2018 18:14, Ken Brown wrote:

On 3/20/2018 4:11 PM, Achim Gratz wrote:

Ken Brown writes:

I'll look into both of these issues, unless Jon beats me to it.


Thanks.


By the way, this only affects local installs.  For network installs,
the hash gets checked at an earlier stage.


That's correct.  I forgot to mention that, but all my installs are from
a local mirror (necessary due to the way network access is restricted at
my workplace)


I haven't been able to come up with a safe way to recover from a 
checksum error at this point, at least not without a lot of work.  I 
propose that we just bail out with an appropriate error message in this 
situation.


Patch attached.


Thanks.

Yeah, this seems entirely reasonable.

Even the previous behaviour is wrong in unattended mode, i.e. 'setup -q 
-P foo -L' should definitely stop with an error if the package for foo 
is corrupt, rather than silently doing our best.

Re: Quotes around command-line argument that has unicode characters are not removed

[Dmitry Katsubo via cygwin]

On 2018-03-22 14:25, Andrey Repin wrote:
> Greetings, Mikhail Usenko!
> 
>> In bare cmd.exe native-msvcrt binary is working OK with quoted non-ascii
>> arguments, while cygwin-flavor binary is not. But I don't know exactly which
>> level here: cmd.exe or msvcrt.dll/cygwin1.dll is responsible for
>> such a behavior.

Thanks, Mikhail! I generally agree with you. If you follow the links I've
provided in my original mail, you can see that cmd.exe does not do any argument
splitting. I also see that from this method signature [1]:

build_argv (char *cmd, char **, int , int winshell)

which basically takes a string as input and returns an array of strings plus
number of arguments as output. So this is either done by msvcrt.dll or by
cygwin1.dll and they have different ways of doing that, which is OK provided
it is documented and done consistently. I refer back to dcrt0.cc where the
woodoo is done. In particular in line 165 [2] it checks that execution was
performed from bare Windows, and behaves differently.

On 2018-03-22 12:24, Andrey Repin wrote:
> Run it in bash. I'm pretty sure you will see your results more consistent.

When "test.exe" is run from bash, it behaves correctly because as you said
bash did the most of dirty work. I also tried to workaround like below,
but it does not work:

D:\cli> bash -c "./test 'текст плюс.txt'"
bash: ./test 'текст плюс.txt': No such file or directory

> Locale settings affecting Cygwin binary.
> 
> If you
> set LANG=ru_RU.CP866
> (f.e.)
> before invoking cygwin testcase in native CMD, you will likely see it
> working better.

Thanks for this advise, Andrey. I see that it reacts, but works worth :)
I think it advises to output characters in CP866, but console is UTF-8:

D:\cli> set LANG=ru_RU.CP866

D:\cli> test "текст плюс.txt"
param 0 = test
param 1 = ⥪▒▒ .txt
Failed to open '⥪▒▒ .txt': No such file or directory

But.. ta-da! I made it working like that:

D:\cli> set LANG=ru_RU.UTF-8

D:\cli> test "текст плюс.txt"
param 0 = test
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened

Hooray, it worked!

> Alternatively, you could try
> chcp 65001

That does not help:

D:\cli> chcp 65001
Active code page: 65001

D:\cli> test "текст плюс.txt"
param 0 = test
param 1 = "текст плюс.txt"
Failed to open '"текст плюс.txt"': No such file or directory

[1] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L297
[2] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L165

-- 
With best regards,
Dmitry

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

Re: setup-x86_64.exe v2.889 doesn't select additionally downloaded packages when installing from local directory

[Ken Brown]

On 3/7/2018 3:15 PM, Jon Turney wrote:
Yeah, this looks like an ordering problem between libxml2 and 
libfontconfig-common.



$ cat /etc/postinstall/fontconfig_dtd.sh
if [ -x /usr/bin/xmlcatalog ] ; then
    /usr/bin/xmlcatalog --noout --add "system" "fonts.dtd" 
/usr/share/xml/fontconfig/fonts.dtd /etc/xml/catalog

fi

$ cat /etc/postinstall/libxml2.sh
if test ! -f /etc/xml/catalog; then
    /bin/mkdir -p /etc/xml
    /usr/bin/xmlcatalog --noout --create /etc/xml/catalog
fi


Not sure how to fix this.

I think there's no actual dependency of libfontconfig-common on 
xmlcatalog, but we lack a triggering mechanism to say "run this script 
when this other package is installed"


/etc/postinstall/fontconfig_dtd.sh could check whether 
/etc/postinstall/libxml2.sh exists.  If so, it could run it and then add 
'.done' so it isn't run again.


Ken

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

Re: [PATCH setup] Link with -lws2_32 again

[Jon Turney]

On 20/03/2018 21:42, Yaakov Selkowitz wrote:

libgpg-error 1.28 includes new APIs which use socket functions, which
on Win32 are provided by WinSock2.

https://cygwin.com/ml/cygwin/2018-03/msg00306.html

Signed-off-by: Yaakov Selkowitz 



Thanks.  Applied.

Re: setup 2.891release candidate - please test

[Jon Turney]

On 18/03/2018 18:23, Houder wrote:



cd /var/log
file setup.log *log-*

[...]



grep '^M^M' setup.log-8.full

2018/03/18 14:06:50 Problem 1/1
nothing provides liblz4_1 needed by libarchive13-3.3.2-1
Solution 1/1 (default)
   - do not ask to install bsdtar-3.3.2-1

# apparently, problem reporting by libsolv causes an additional CR ... why?


Q:

Would it be possible to prevent the additional CR from showing up in the log
file? It is visible when the log file is examined by means of vi(m).


It looks like this is just a bug (we are logging the string after it's 
had the line terminators turned into CRLF for putting into a Windows 
text box, but the logging mechanism expects LF line terminators)


Thanks for testing, and thanks for pointing this out.


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

Re: setup 2.891release candidate - please test

[Jon Turney]

On 16/03/2018 21:52, Robert Cohen wrote:

-

Hi Jon,

  I tested setup-2.891.x86_64 with an install from local directory, and I got 
the same
result as setup-2.889-12-g1cf567.x86_64.exe, where it installed the additional 
packages
that I selected, but at the end it gave this message:

Package: _/libfontconfig-common
fontconfig_dtd.sh exit code 2

  Do you think this may be because I'm installing from an already-downloaded 
directory and
It may work ok if I repeat the download and install process using the new setup 
executable, or
would another solution be needed for this, as alluded to in your earlier reply 
to this same error
message?


Thanks for testing.

Yes, as I wrote in [1], this isn't more a missing feature and/or missing 
dependency information, than a bug in setup.


[1] https://cygwin.com/ml/cygwin/2018-03/msg00108.html

--
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: setup (2.891)

[Jon Turney]

A new version of Setup, release 2.891, 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.889:

- 'Use HTTP/FTP Proxy' connection type now uses the WinINet API

As a consequence, the '--user-agent' option now affects this connection 
type as well


- Remove the 'Direct(legacy)' connection type and associated cruft

There have been no reported problems with it's replacement, the 'Direct' 
connection type, since it's introduction in 2.878

(See https://cygwin.com/ml/cygwin-announce/2017-05/msg00053.html)

If this is the currently configured connection type, it will be silently 
migrated to 'Direct'


- Improve file:// URL handling

All well-formed file URLs should now work.  Malformed file URLs we 
previously accepted should also still work.


Thanks to SZAVAI Gyula for these changes.

- Various fixes for regressions in 'Install from Local Directory' mode
  Addresses: https://cygwin.com/ml/cygwin/2018-03/msg00027.html

Thanks to Ken Brown for these changes.

- Add support for setup-minimum-version: in setup.ini

- Preliminary support for 'provides:' and 'conflicts': in setup.ini

- Add a --version option


Please send bug reports, as usual, to the public mailing list cygwin AT 
cygwin DOT 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

Updated: setup (2.891)

[Jon Turney]

A new version of Setup, release 2.891, 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.889:

- 'Use HTTP/FTP Proxy' connection type now uses the WinINet API

As a consequence, the '--user-agent' option now affects this connection 
type as well


- Remove the 'Direct(legacy)' connection type and associated cruft

There have been no reported problems with it's replacement, the 'Direct' 
connection type, since it's introduction in 2.878

(See https://cygwin.com/ml/cygwin-announce/2017-05/msg00053.html)

If this is the currently configured connection type, it will be silently 
migrated to 'Direct'


- Improve file:// URL handling

All well-formed file URLs should now work.  Malformed file URLs we 
previously accepted should also still work.


Thanks to SZAVAI Gyula for these changes.

- Various fixes for regressions in 'Install from Local Directory' mode
  Addresses: https://cygwin.com/ml/cygwin/2018-03/msg00027.html

Thanks to Ken Brown for these changes.

- Add support for setup-minimum-version: in setup.ini

- Preliminary support for 'provides:' and 'conflicts': in setup.ini

- Add a --version option


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

[ANNOUNCEMENT] ghostscript 9.23-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* ghostscript-9.23-1
* libgs9-9.23-1
* libgs-devel-9.23-1

GNU Ghostscript is a PostScript interpreter capable of converting PS
files into a number of printer output formats.  Ghostscript can also
render PS files into a number of graphics file formats.

This is an update to the latest upstream release.

Ken Brown
Cygwin's Ghostscript maintainer

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

ghostscript 9.23-1

[Ken Brown]

The following packages have been uploaded to the Cygwin distribution:

* ghostscript-9.23-1
* libgs9-9.23-1
* libgs-devel-9.23-1

GNU Ghostscript is a PostScript interpreter capable of converting PS
files into a number of printer output formats.  Ghostscript can also
render PS files into a number of graphics file formats.

This is an update to the latest upstream release.

Ken Brown
Cygwin's Ghostscript maintainer

Re: Quotes around command-line argument that has unicode characters are not removed

[Dmitry Katsubo via cygwin]

On 2018-03-22 12:24, Andrey Repin wrote:
> 
> This is not cygwin, this is bare Windows.

This is executable linked against cygwin1.dll. I personally call such
binaries "Cygwin programs". However it is run from Windows.

> Parameter unquoting done by the shell.
> CMD does that differently from POSIX shells.

CMD does nothing when you execute a program from it. Command-line
is passed literally. I've download procmon.exe [1] and filtered by
process name "cmd.exe". When I run

D:\cli> test abc "текст\" плюс.txt"

(suppose that CMD will at least remove backslashes) I see the following
in the log:

test abc "текст\" плюс.txt"

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

-- 
With best regards,
Dmitry

--
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: Odd hang in python waiting for child; strace wakes hung process?

[Dan Kegel]

On Thu, Mar 22, 2018 at 9:59 AM, Corinna Vinschen
 wrote:
> I guess we can simply remove /dev/kmsg support completely and drop
> the mailslot code.  I'm pretty sure nobody would miss it.  Hardly
> anybody knows it exists...

I'd be happy to test (though building cygwin is not in the cards for
me for now).
But would it break this guy's use case (running syslog-ng on cygwin)?
http://kb.kaminskiengineering.com/node/382
https://web.archive.org/web/20110209222803/http://www.syslog.org/logged/running-syslog-ng-on-windows/
- Dan

--
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: Odd hang in python waiting for child; strace wakes hung process?

[Achim Gratz]

Dan Kegel writes:
> 1) kill -CONT the-pid doesn't do anything, nor does kill -9.  It's
> truly wedged.

No, you send CONT to all processes (like 'pkill -CONT .'), it seems that
this gets whatever was wedged enough of a kick to retry or time out and
then it (often, not always) it seems to start reaping processes again
and the  start to vanish.  You can tell you have one of these
when just doing a ps takes much longer than usual when it hits those
processes.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

Re: X Server 1.19.6-2 , xset does not add ghostscript fonts for xfig

[Achim Gratz]

Ken Brown writes:
> What a mess!

Indeed.

> There's a comment just yesterday at
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1551219#c8
>
> suggesting that there will be some Fedora changes in the urw font
> package coming this week.  So let's wait for the dust to settle, and
> then I hope we can just copy whatever solution Fedora comes up with.

That works for me.  :-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: Quotes around command-line argument that has unicode characters are not removed

[Kaz Kylheku]

On 2018-03-22 04:24, Andrey Repin wrote:

Greetings, Dmitry Katsubo!


Dear Cygwin community,



I observe the following on my Cygwin:


This is not cygwin, this is bare Windows.


That may be so, yet there may be an issue here for someone packaging
Cygwin programs for use as native Windows applications.

That is to say, there could potentially be something here that the 
Cygnal

project could address:

http://www.kylheku.com/cygnal/

Cygnal is an ultra-light fork of the Cygwin DLL that is intended for 
users like Dmitry Katsubo, who run Cygwin programs out of the Windows 
environment directly, after building them in Cygwin.





when I put quotes around file that has
non-ASCII symbols, these quotes are passed to argv of the process 
literally,
otherwise they are removed. I would expect that there is a 
consistency.


Parameter unquoting done by the shell.
CMD does that differently from POSIX shells.


As I seem to recall, CMD doesn't do anything, period! It passes the 
command line

as one big string. It has to since that's the OS mechanism.

The quoting conventions come from how various run-time libraries deal 
with that
string. An influential convention is that of the MS Visual C run-time 
library;
it behooves other run-times to be compatible with that for consistency 
with

programs whose main() was compiled with MSVC.


--
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: Odd hang in python waiting for child; strace wakes hung process?

[Corinna Vinschen]

On Mar 21 23:41, Brian Inglis wrote:
> On 2018-03-21 16:07, Dan Kegel wrote:
> > On Wed, Mar 21, 2018 at 11:54 AM, Achim Gratz  wrote:
> >> Well, with the sporadic hanging/defunct processes at work my routine is
> >> to send CONT to all Cygwin processes, then HUP/KILL to anything that's
> >> still not live or gone and then another round of CONT.  This works
> >> _most_ of the time, anything more stubborn I /bin/kill -f usually.
> > 
> > Since I wrote, both bots hung again.  This time I verified:
> > 0) both had the defunct git process as expected
> > 1) kill -CONT the-pid doesn't do anything, nor does kill -9.  It's truly 
> > wedged.
> > 2) the process stays in its spin hang until you ^C strace -p the-pid
> > 3) ^C-ing the strace causes the process to terminate (strace alone doesn't)
> > 4) taskkill /pid the-task /f also kills the process successfully.
> > 
> > So I could write a script that watched for defunct git processes
> > and taskkilled their parent.  Build jobs would fail, but at least
> > the bot would stay up.  Of course it would be much nicer if
> > the cygwin python process didn't get wedged.
> > 
> > Alternately, I suppose I could try running native python...
> > or cygwin's python3... but dangit, kill -9 should work.
> 
> Seems to be looping on access failure to a Windows mailslot; not sure what 
> this
> feature is normally used for: dmesg/syslog messages/AF_UNIX sockets?

/dev/kmsg is implemented using a mailslot under the hood.  This
feature is only used to log exceptions and for nothing else since
nobody ever found another reason to use it for.

It would be interesting to learn if the perl hangs have the same reason.

I guess we can simply remove /dev/kmsg support completely and drop
the mailslot code.  I'm pretty sure nobody would miss it.  Hardly
anybody knows it exists...


Corinna

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


signature.asc
Description: PGP signature

Re: de1 problem

[Andrey Repin]

Greetings, Raissa SHEMA!

>   3 [main] bash 1360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
> pointer.  Please report this problem to
> the public mailing list cygwin@cygwin.com
> Compilation stopped.

Please update your Cygwin, this issue was resolved over a decade ago.

For details, see 
http://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings


-- 
With best regards,
Andrey Repin
Thursday, March 22, 2018 19:43:44

Sorry for my terrible english...


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

Re: GitForWindows vs. Cygwin

[R0b0t1]

Hello list, I think there is information the OP can use, but no one
has apparently experienced it. Also, it's not likely he'd have gotten
good information from the other respective mailing lists, so I think
it is fine he asked here.

However, I am not very smart and my opinion does not matter, so I
apologize for the noise on the list.

On Tue, Mar 20, 2018 at 5:52 PM, KARL BOTTS  wrote:
>
> Can anyone enlighten me about the relationship of "Git for Windows" to
> Cygwin?
>
> I have no intention to use GFW myself: I use Cygwin git.  But now other people
> around here are discovering GitHub, MSysGit and or GitForWindows.  Pretty
> soon, we are going to wind up with multiple git flavors installed on the same
> host, which worries me.
>
> I know that MSysGit is basically a stale fork of Cygwin.  I tried it a long
> time ago (during a period when the git in Cygwin was not getting updated
> often), and it caused me trouble.  As I recall, the bash in it was only v3,
> and I was used to v4, and some of my scripts didn't run right, and MSysGit
> messed up my HOME dir.  Anyhow, I got rid of MSysGit.  And now that the git in
> Cygwin is keeping current, I am quite content.
>
> But now I hear of this GitForWindows thing.  Which seems to have replaced
> MSysGit, with a GUI thrown in.  But is it _still_ a stale fork of Cygwin, or a
> fork at all?  Is it descended from MSysGit?  I have been googling all over,
> but not finding good answers.
>
> I just want to watch out for the damn thing, and try to keep it away...
>

What you need to watch out for is having a cluttered PATH. If you
install, say, the WinAVR toolchain, it includes either an MSYS
distribution or select pieces of Cygwin (bundling MSYS[2] is more
popular, from memory). These old tools will cause problems if you try
to run autotools for a native project from within Cygwin. Other
distributions, like the Haskell Stack, have the same problem.

If you install MSYS2 and Cygwin and both are in your path but you keep
both up to date, you won't have this problem.

Cheers,
 R0b0t1

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

de1 problem

[Raissa SHEMA]

  3 [main] bash 1360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
Compilation stopped.

--
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: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Ken Brown]

On 3/21/2018 8:35 PM, Brian Inglis wrote:

On 2018-03-21 12:14, Ken Brown wrote:

On 3/20/2018 4:11 PM, Achim Gratz wrote:

Ken Brown writes:

I'll look into both of these issues, unless Jon beats me to it.


Thanks.


By the way, this only affects local installs.  For network installs,
the hash gets checked at an earlier stage.


That's correct.  I forgot to mention that, but all my installs are from
a local mirror (necessary due to the way network access is restricted at
my workplace)


I haven't been able to come up with a safe way to recover from a checksum error
at this point, at least not without a lot of work.  I propose that we just bail
out with an appropriate error message in this situation.

Patch attached.


Skipping a single package install is likely to be /relatively/ safe, but if this
patch causes setup to exit sometime after upgrading a bunch of packages but
before upgrading another bunch of packages, it could leave Cygwin unusable,
especially if there are upgrade dependencies between the packages installed
prior and not installed after the problematic download.

It would be better in such cases to check all the hashes before proceeding with
any of the installs


We already do that.  My patch deals with the situation where we find a 
corrupt file during this process.


Ken

Re: Quotes around command-line argument that has unicode characters are not removed

[Andrey Repin]

Greetings, Mikhail Usenko!

> In bare cmd.exe native-msvcrt binary is working OK with quoted non-ascii
> arguments, while cygwin-flavor binary is not. But I don't know exactly which
> level here: cmd.exe or msvcrt.dll/cygwin1.dll is responsible for
> such a behavior.

Locale settings affecting Cygwin binary.

If you
set LANG=ru_RU.CP866
(f.e.)
before invoking cygwin testcase in native CMD, you will likely see it
working better.
Alternatively, you could try
chcp 65001


-- 
With best regards,
Andrey Repin
Thursday, March 22, 2018 16:22:13

Sorry for my terrible english...


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

Re: Quotes around command-line argument that has unicode characters are not removed

[Mikhail Usenko via cygwin]

On Thu, 22 Mar 2018 01:15:00 +0100
Dmitry Katsubo via cygwin <...> wrote:

> Dear Cygwin community,
> 
> I observe the following on my Cygwin: when I put quotes around file that has
> non-ASCII symbols, these quotes are passed to argv of the process literally,
> otherwise they are removed. I would expect that there is a consistency.
> 
> I have written a small C program that displays arguments, and run it three
> times:
> 
> #1 For the file with space, taken into quotes ("the file.txt") -- OK
> #2 For the file with non-ASCII characters (Château.txt) -- OK
> #3 For the file with non-ASCII characters, taken into quotes ("Château.txt") 
> -- WRONG
> 
> d:\cli> uname -a
> CYGWIN_NT-6.1-WOW PC 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin
> 
> D:\cli> chcp
> Active code page: 866
> 
> D:\cli> dir
> ...cut...
> 2018-03-22  00:43 0 Château.txt
> 2018-03-22  00:01   393 test.c
> 2018-03-22  00:01   150,230 test.exe
> 2018-03-21  00:15   186 test.pl
> 2018-03-22  00:43 0 the file.txt
> 2018-03-22  00:4016 текст плюс.txt
>6 File(s)150,825 bytes
>2 Dir(s)  41,972,293,632 bytes free
> 
> D:\cli> test "the file.txt"
> param 0 = test
> param 1 = the file.txt
> File 'the file.txt' was opened
> 
> D:\cli> test Château.txt
> param 0 = test
> param 1 = Château.txt
> File 'Château.txt' was opened
> 
> D:\cli> test "Château.txt"
> param 0 = test
> param 1 = "Château.txt"
> Failed to open '"Château.txt"': No such file or directory
> 
> As one can see, the last run fails. I am a bit puzzled: how can I pass the 
> name
> of the file with space and Unicode symbols? I need to do it in uniform way, 
> as I
> am calling a Cygwin program from native Windows program, as in [1].
> 
> D:\cli> test "текст плюс.txt"
> param 0 = test
> param 1 = "текст плюс.txt"
> Failed to open '"текст плюс.txt"': No such file or directory
> 
> I have search a bit, but I couldn't find a direct answer. From post [1] and 
> [2]
> I see that compiler inserts the code to do some argument pre-processing like
> @pathnames [3], but what are exactly the rules? Is quote pre-processing done 
> in
> dcrt0.cc:177 [4]?
> 
> Any feedback is appreciated.
> 
> [1] https://sourceware.org/ml/cygwin/2016-05/msg00082.html
> [2] http://daviddeley.com/autohotkey/parameters/parameters.htm
> [3] https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-at
> [4] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L177
> 
> === test.c ===
> #include 
> #include 
> #include 
> 
> int main(int argc, char* argv[])
> {
>   for (int i = 0; i < argc; i++)
>   {
>   printf("param %d = %s\n", i, argv[i]);
>   }
>   FILE* f = fopen(argv[1], "r");
>   if (f != NULL)
>   {
>   printf("File '%s' was opened\n", argv[1]);
>   fclose(f);
>   } else {
>   printf("Failed to open '%s': %s\n", argv[1], strerror(errno));
>   }
>   return 0;
> }
> 
> -- 

Hello, Dmintry,
consider these test cases:

Native (msvcrt) binary:
---
$ x86_64-w64-mingw32-gcc test.c -o test-win.exe
$ ldd test-win.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fa0590)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL 
(0x7fa030e)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll 
(0x7fa028f)
msvcrt.dll => /cygdrive/c/Windows/system32/msvcrt.dll (0x7fa0322)
---

Cygwin-flavor binary:
-
$ gcc test.c -o test-cygwin.exe
$ ldd test-cygwin.exe
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7fa0590)
KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL 
(0x7fa030e)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll 
(0x7fa028f)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
-

Create a file with non-ascii chars in the name:
---
$ touch "текст плюс.txt"
---

Run both binaries in mintty with bash:
--
$ ./test-win "текст плюс.txt"
param 0 = D:\wroot\test.cygwin\Quotes around command-line argument that has 
unicode characters are not removed\test-win.exe
param 1 = ▒ .txt
File '▒ .txt' was opened
$ ./test-cygwin "текст плюс.txt"
param 0 = ./test-cygwin
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened
--

Run the binaries in cmd.exe with bash:
--
$ ./test-win "текст плюс.txt"
param 0 = D:\wroot\test.cygwin\Quotes around command-line argument that has 
unicode characters are not removed\test-win.exe
param 1 = ЄхъёЄ яы■ё.txt
File 'ЄхъёЄ яы■ё.txt' was opened
$ ./test-cygwin "текст плюс.txt"
param 0 = ./test-cygwin
param 1 = текст плюс.txt
File 'текст плюс.txt' was opened

Re: Quotes around command-line argument that has unicode characters are not removed

[Andrey Repin]

Greetings, Dmitry Katsubo!

> Dear Cygwin community,

> I observe the following on my Cygwin:

This is not cygwin, this is bare Windows.

> when I put quotes around file that has
> non-ASCII symbols, these quotes are passed to argv of the process literally,
> otherwise they are removed. I would expect that there is a consistency.

Parameter unquoting done by the shell.
CMD does that differently from POSIX shells.

> I have written a small C program that displays arguments, and run it three
> times:

Run it in bash. I'm pretty sure you will see your results more consistent.

> #1 For the file with space, taken into quotes ("the file.txt") -- OK
> #2 For the file with non-ASCII characters (Château.txt) -- OK
> #3 For the file with non-ASCII characters, taken into quotes ("Château.txt") 
> -- WRONG

> d:\cli> uname -a
> CYGWIN_NT-6.1-WOW PC 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin

> D:\cli> chcp
> Active code page: 866

> D:\cli> dir
> ...cut...
> 2018-03-22  00:43 0 Château.txt
> 2018-03-22  00:01   393 test.c
> 2018-03-22  00:01   150,230 test.exe
> 2018-03-21  00:15   186 test.pl
> 2018-03-22  00:43 0 the file.txt
> 2018-03-22  00:4016 текст плюс.txt
>6 File(s)150,825 bytes
>2 Dir(s)  41,972,293,632 bytes free

> D:\cli> test "the file.txt"
> param 0 = test
> param 1 = the file.txt
> File 'the file.txt' was opened

> D:\cli> test Château.txt
> param 0 = test
> param 1 = Château.txt
> File 'Château.txt' was opened

> D:\cli> test "Château.txt"
> param 0 = test
> param 1 = "Château.txt"
> Failed to open '"Château.txt"': No such file or directory

> As one can see, the last run fails. I am a bit puzzled: how can I pass the 
> name
> of the file with space and Unicode symbols? I need to do it in uniform way, 
> as I
> am calling a Cygwin program from native Windows program, as in [1].

> D:\cli> test "текст плюс.txt"
> param 0 = test
> param 1 = "текст плюс.txt"
> Failed to open '"текст плюс.txt"': No such file or directory

> I have search a bit, but I couldn't find a direct answer. From post [1] and 
> [2]
> I see that compiler inserts the code to do some argument pre-processing like
> @pathnames [3], but what are exactly the rules? Is quote pre-processing done 
> in
> dcrt0.cc:177 [4]?

> Any feedback is appreciated.

> [1] https://sourceware.org/ml/cygwin/2016-05/msg00082.html
> [2] http://daviddeley.com/autohotkey/parameters/parameters.htm
> [3] https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-at
> [4] https://github.com/openunix/cygwin/blob/master/winsup/cygwin/dcrt0.cc#L177

> === test.c ===
> #include 
> #include 
> #include 

> int main(int argc, char* argv[])
> {
> for (int i = 0; i < argc; i++)
> {
> printf("param %d = %s\n", i, argv[i]);
> }
> FILE* f = fopen(argv[1], "r");
> if (f != NULL)
> {
> printf("File '%s' was opened\n", argv[1]);
> fclose(f);
> } else {
> printf("Failed to open '%s': %s\n", argv[1], strerror(errno));
> }
> return 0;
> }



-- 
With best regards,
Andrey Repin
Thursday, March 22, 2018 14:21:25

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

Re: GitForWindows vs. Cygwin

[David Macek]

It doesn't use cygwin, therefore it's not related. Since this is a
cygwin mailing list, that means the first two replies were correct —
this isn't the place to discuss it.



When the vast majority of the code in the MSYS2 runtime is exactly
the same as the code in the Cygwin runtime, and Git for Windows uses
msys-2.0.dll in a number of places (which is essentially a renamed
copy of cygwin1.dll) the question was fair. Particularly given Cygwin
has its own git package, it's only natural to wonder how that differs
from Git for Windows, and how it differs from the probably lesser-
known msys2-git package (which is built in very nearly the same
configuration as the Cygwin git package, posix style).



Only GfW and Msys2 Git projects can answer how Cygwin components are used by
their projects. Most (all?) of Cygwin winsup and (all of?) newlib are available
under permissive BSD(-style) licences that allow all uses of the code.

It's possible that the developers of those GfW and Msys2 Git packages have moved
on from those projects and the current maintainers don't have the basis to 
answer.

One might expect some of those maintainers to be subscribed to this list and
able to answer, but they may not, and just check web archives, or they may
choose not to get into this discussion here, although they could perhaps suggest
a more appropriate forum, or take the discussion off-list.


I've been watching this thread closely, but I had decided not to post since it
seemed like this discussion is unwanted by a part of the community.

On the surface, this discussion is about Git, so the most on-topic place to 
discuss
is the Git public mailing list.  I personally don't think the Cygwin mailing 
list
is off-topic.  Because most(all?) Windows Git distros use Cygwin code, it might 
be
even more useful to ask here (though I assume Johannes subscribes to Git ML and
he would be able to answer all the intricacies pretty accurately).

So far, Tony Kelman's descriptions were pretty spot on (that's why I didn't 
respond
to his call for corrections -- I couldn't think of any).

--
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature