date:20171220

On 2017-12-20 17:08, Vijaya Subramanian wrote:
> Thanks a lot. This worked but only with the new version of setup.exe that is 
> out
> right now.
> 
> 
> On Tuesday, December 19, 2017, 11:22:39 PM MST, Brian Inglis
>  wrote:
> 
> 
> On 2017-12-19 22:47, Vijaya Subramanian wrote:
>> On 2017-12-19 10:43, Vijaya Subramanian via cygwin wrote:
>>>On Tuesday, December 19, 2017, 11:36:08 AM MST, Brian Inglis wrote:
 I checked /var/log/setup-full.log and found the below instances where
 libz4-1 was mentioned
 package liblz4-devel comparing versions 131-1 and 131-1, result was 0
 package liblz4_1 comparing versions 131-1 and 131-1, result was 0
 package liblz4-devel comparing versions 1.7.5-1 and 131-1, result was -1
 package liblz4_1 comparing versions 1.7.5-1 and 131-1, result was -1
 2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting
 already-installed version .
 2017/12/02 14:06:47 Changing gid back to original
 So I am not sure why I get the following message when I run cmake:
 When I try to run cmake, I get the following error message:
 C:/cygwin64/bin/cmake.exe: error while loading shared libraries: ?:
 cannot open shared object file: No such file or directory
 or why cygcheck cmake says: cygcheck: track_down: could not find 
 cyglz4-1.dll
>>> Cygwin setup currently has problems upgrading when version numbers change
>>> formats and a solution is being addressed by the volunteer maintainers.
>>> You have to manually run Cygwin setup, find the liblz4 packages you have
>>> installed, and select the new version number to be installed 1.7.5-1.
>> Want to confirm setup-x86_64 -D liblz4-1 -q -g is what I input on the
>> command line to upgrade the package? Do I have to install cmake again?
> You can not use setup from the command line to upgrade to a different version
> format: Cygwin currently has no way to specify a package version on the 
> command
> line like apt ... pkg=ver. You will just get the same messages and problems as
> before.
> 
> You must download and run Setup interactively.
> On the Select Packages panel, change View to |Full| or |Up To Date|;
> in Search enter |liblz4|;
> on each package line under column New, click until the version to be installed
> reads 1.7.5-1;
> click the [Clear] button;
> change View to |Pending| to verify the version;
> then click [Next] to upgrade.

It worked when I did it with earlier setup on 2017-09-05.

-- 
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: [PATCH setup] Make sure that fatal error messages are visible

On 2017-12-20 10:09, Ken Brown wrote:
> On 12/20/2017 11:19 AM, Jon Turney wrote:
>> On 19/12/2017 00:53, Ken Brown wrote:
>>> The message box produced by TOPLEVEL_CATCH could be hidden by whatever
>>> window was previously being displayed, so that setup appeared to hang.
>>> Fix this by giving fatal error message boxes type MB_SETFOREGROUND.
>>
>> This is good as far as it goes, but is kind of working around the fact that
>> fatal() is being called with an NULL owner HWND.
>>
>> This is not idea because I guess it means that propsheet window is still
>> activate-able when this messagebox is displayed (MB_APPMODAL doesn't apply)?
> 
> It turns out that MB_SYSTEMMODAL did the job.  I tried MB_APPLMODAL and
> MB_TASKMODAL also, but both of those still allowed me to activate the 
> propsheet
> window.

Is it really a problem if users can look at other windows when there is an
error? It is often useful to be able to look at your inputs to see if they
played a role in causing the error, or it is some external issue.

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

Re: [PATCH] winsup/doc/etc.postinstall.cygwin-doc.sh fix shell variable typo

On 2017-12-20 16:10, Eric Blake wrote:
> On 12/20/2017 05:01 PM, Brian Inglis wrote:
>> ---
>>   winsup/doc/etc.postinstall.cygwin-doc.sh | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh
>> b/winsup/doc/etc.postinstall.cygwin-doc.sh
>> index 2873d9395..935bd94e1 100755
>> --- a/winsup/doc/etc.postinstall.cygwin-doc.sh
>> +++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
>> @@ -52,7 +52,7 @@ fi
>>   # create User Guide and API PDF and HTML shortcuts
>>   while read target name desc
>>   do
>> -    [ -r $t ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" -- 
>> $target
>> +    [ -r $target ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" --
>> $target
> 
> Wrong.  Needs to be [ -r "$target" ] to be properly quoted.

>From working with Windows paths, I feel I often overdo the quotes: originally
had both uses quoted, then seeing the diff, took them off again, pre-commit.
Those are base Cygwin paths - don't *need* quotes - unless you feel shell var
uses should be quoted just in case, or just in tests?

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

Re: [ANNOUNCEMENT] fdk-aac 0.1.5-2

2017-12-20 Thread Steven Penny


On Wed, 20 Dec 2017 18:56:12, Yaakov Selkowitz wrote:

What need do you specifically have for static libraries?


its not a need - its a preference - i prefer static builds - the count of
programs i regularly build is small, so the redundancy doesnt hurt my use case.
also if I am to share my builds with others it makes for a smoother process - as
you can end up with a single exe. notice carefully that many projects offer
static and shared builds, here is one example:

http://ffmpeg.zeranoe.com

if you choose to keep doing only shared builds it wont kill me, but it is an
annoyance because its that many more libraries i need to build, when I could
just download and link an already built static library - also notice carefully
that these type packages have some inconsistency - whereas the ones i listed
previously do not have static library - these here do:

1. mingw64-x86_64-curl
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libcurl.a

2. mingw64-x86_64-libgnurx
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgnurx.a
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libregex.a

3. mingw64-x86_64-openssl
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libcrypto.a
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libssl.a

4. mingw64-x86_64-win-iconv
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libiconv.a

5. mingw64-x86_64-zlib
- usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.a


--
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] fdk-aac 0.1.5-2

On 2017-12-20 17:58, Steven Penny wrote:
> On Tue, 19 Dec 2017 12:01:35, Yaakov Selkowitz wrote:
>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * mingw64-i686-fdk-aac-0.1.5-2
>> * mingw64-x86_64-fdk-aac-0.1.5-2
> 
> Can we get a static library along with the shared library in these type
> packages? This has been a growing issue (for me) as time has gone on:

What need do you specifically have for static libraries?

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else;manual install solved problem.

Thanks a lot. This worked but only with the new version of setup.exe that is 
out right now.
 

On Tuesday, December 19, 2017, 11:22:39 PM MST, Brian Inglis 
 wrote:  
 
 On 2017-12-19 22:47, Vijaya Subramanian wrote:
> On 2017-12-19 10:43, Vijaya Subramanian via cygwin wrote:
>>On Tuesday, December 19, 2017, 11:36:08 AM MST, Brian Inglis wrote:
>>> I checked /var/log/setup-full.log and found the below instances where
>>> libz4-1 was mentioned
>>> package liblz4-devel comparing versions 131-1 and 131-1, result was 0
>>> package liblz4_1 comparing versions 131-1 and 131-1, result was 0
>>> package liblz4-devel comparing versions 1.7.5-1 and 131-1, result was -1
>>> package liblz4_1 comparing versions 1.7.5-1 and 131-1, result was -1
>>> 2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting
>>> already-installed version .
>>> 2017/12/02 14:06:47 Changing gid back to original
>>> So I am not sure why I get the following message when I run cmake:
>>> When I try to run cmake, I get the following error message:
>>> C:/cygwin64/bin/cmake.exe: error while loading shared libraries: ?:
>>> cannot open shared object file: No such file or directory
>>> or why cygcheck cmake says: cygcheck: track_down: could not find 
>>> cyglz4-1.dll
>> Cygwin setup currently has problems upgrading when version numbers change
>> formats and a solution is being addressed by the volunteer maintainers.
>> You have to manually run Cygwin setup, find the liblz4 packages you have
>> installed, and select the new version number to be installed 1.7.5-1.
> Want to confirm setup-x86_64 -D liblz4-1 -q -g is what I input on the
> command line to upgrade the package? Do I have to install cmake again?
You can not use setup from the command line to upgrade to a different version
format: Cygwin currently has no way to specify a package version on the command
line like apt ... pkg=ver. You will just get the same messages and problems as
before.

You must download and run Setup interactively.
On the Select Packages panel, change View to |Full| or |Up To Date|;
in Search enter |liblz4|;
on each package line under column New, click until the version to be installed
reads 1.7.5-1;
click the [Clear] button;
change View to |Pending| to verify the version;
then click [Next] to upgrade.

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

  
--
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] fdk-aac 0.1.5-2

2017-12-20 Thread Steven Penny


On Tue, 19 Dec 2017 12:01:35, Yaakov Selkowitz wrote:

The following packages have been uploaded to the Cygwin distribution:

* libfdk-aac1-0.1.5-2
* libfdk-aac-devel-0.1.5-2
* mingw64-i686-fdk-aac-0.1.5-2
* mingw64-x86_64-fdk-aac-0.1.5-2


Can we get a static library along with the shared library in these type
packages? This has been a growing issue (for me) as time has gone on:

- http://github.com/cygwinports/mingw64-x86_64-fdk-aac/issues/1
- http://github.com/cygwinports/mingw64-x86_64-expat/issues/1
- http://github.com/cygwinports/mingw64-x86_64-lua/issues/1
- http://github.com/cygwinports/mingw64-x86_64-nghttp2/issues/1
- http://github.com/cygwinports/mingw64-x86_64-pcre/issues/1


--
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: Norton antivirus detects a threat in setup-x86_64.exe

2017-12-20 Thread Greg Taylor

On Wed, Dec 20, 2017 at 2:22 PM, Greg Taylor 
wrote:

> I downloaded the file setup-x86_64.exe again and now the scan reports no
> threats.
>
> Version 2.882 was all clear
> Version 2.883 downloaded at 12:30pm reported a threat
> Version 2.883 downloaded at 2:14pm PST was all clear
>

To clear up the issue (if there are any lingering doubts about the 12:30
file), the md5 sum of the files from 12:30 and 2:14 are identical.

--
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: Wrong file position after writing 65537 bytes to block device

2017-12-20 Thread Kaz Kylheku

On 18.12.2017 16:27, Steven Penny wrote:

On Mon, 18 Dec 2017 14:10:35, Corinna Vinschen wrote:

In general, the writes on disk devices is sector-oriented. Howewver,
in this case ftell should have returned 65536. The problem here is
that the newlib implmentation of ftell/ftello performs an fflush
when called on a write stream since about 2008 to adjust for appending
streams. Given your example (thanks for the testcase!) this seems
pretty wrong. Looking further it turns out that neither glibc nor BSD
actually calls fflush in this case. There's only a special case for
appending streams, but this calls lseek, not fflush.

Looks like a patch is required. Stay tuned.

is it though? he says "write 65536 + 1 bytes", but as far as i can
tell, you

cant do that. quoting myself:

Seeking, reading and writing must all be done in multiples of sector
size, in

my case 512 bytes

http://web.archive.org/web/stackoverflow.com/questions/37228874/how-to-fwrite-to-removable-volume

so it would make sense that the position becomes "65536 + 512"

You can do that on a "block" device. It's "raw" devices that have
transfer unit restrictions.

A block device creates an abstraction over a disk, dividing it into
blocks. Those blocks are not related to the underlying sector size;
they could be larger (e.g. 4096 byte block size, versus 512 byte
sectors) or even smaller (e.g. 4096 byte block size, versus 65536
byte flash erase block size).

Unix block devices let you read, write and seek using byte offsets
and sizes. The bytes which are affected by a write operation map
to one or more ranges in one or more blocks. All of the blocks have to
be read into memory (if they aren't already). The bytes are updated,
and then the blocks are marked dirty and written out (eventually).
More changes can take place before that happens.

So for instance if we have a block device (4096 bytes) over a flash
device with 64 kB erase blocks, we can write just one byte somewhere
in a block. When this change is flushed, the entire erase block has to
be erased and rewritten.

Because of the abstract nature of block devices, it's largely
pointless to use the "dd" utility; you can use "cp" to copy them.
"dd" is required when you need to control the exact size of the
read and write calls. Thus "cat /dev/zero > /dev/blockdevice"
has the same effect as "dd if=/dev/zero of=/dev/blockdevice".

--
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: mkshortcut fails when run from setup, postinstall/cygwin-doc.sh - not otherwise

On 2017-12-20 05:59, Enrique Perez-Terron wrote:
> Lately, whenever I run setup (x86), my /var/log/setup.log.full contains:
>  2017/12/20 03:07:44 running: C:\cygwin\bin\bash.exe --norc --noprofile
> "/etc/postinstall/cygwin-doc.sh"
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/User Guide (PDF).lnk" failed; does the target 
> directory
> exist?
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/User Guide (HTML).lnk" failed; does the target 
> directory
> exist?
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/API (PDF).lnk" failed; does the target directory 
> exist?
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/API (HTML).lnk" failed; does the target directory 
> exist?
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/Home Page.lnk" failed; does the target directory 
> exist?
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/FAQ.lnk" failed; does the target directory exist?
>  2017/12/20 03:07:45 abnormal exit: exit code=3
> Please notice the extra C:/ in front of the target link name.
> So I have added a line "set -x" at the top in  postinstall/cygwin-doc.sh, and
> the relevant section becomes
>  + read target name desc
>  + '[' -r ']'
>  + /bin/mkshortcut -A -P -n 'Cygwin/User Guide (PDF)' -d 'Cygwin User Guide 
> PDF'
> -- /usr/share/doc/cygwin-doc/cygwin-ug-net.pdf
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/User Guide (PDF).lnk" failed; does the target 
> directory
> exist?
>  + read target name desc
>  + '[' -r ']'
>  + /bin/mkshortcut -A -P -n 'Cygwin/User Guide (HTML)' -d 'Cygwin User Guide
> HTML' -- /usr/share/doc/cygwin-doc/html/cygwin-ug-net/index.html
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/User Guide (HTML).lnk" failed; does the target 
> directory
> exist?
>  + read target name desc
>  + '[' -r ']'
>  + /bin/mkshortcut -A -P -n 'Cygwin/API (PDF)' -d 'Cygwin API Reference PDF' 
> --
> /usr/share/doc/cygwin-doc/cygwin-api.pdf
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/API (PDF).lnk" failed; does the target directory 
> exist?
>  + read target name desc
>  + '[' -r ']'
>  + /bin/mkshortcut -A -P -n 'Cygwin/API (HTML)' -d 'Cygwin API Reference HTML'
> -- /usr/share/doc/cygwin-doc/html/cygwin-api/index.html
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/API (HTML).lnk" failed; does the target directory 
> exist?
>  + read target name desc
>  + read target name desc
>  + /bin/mkshortcut -A -P -n 'Cygwin/Home Page' -d 'Cygwin Home Page Link' -a
> https://cygwin.com/index.html -- /bin/cygstart
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/Home Page.lnk" failed; does the target directory 
> exist?
>  + read target name desc
>  + /bin/mkshortcut -A -P -n Cygwin/FAQ -d 'Cygwin Frequently Asked Questions
> Link' -a https://cygwin.com/faq.html -- /bin/cygstart
>  mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start
> Menu/Programs/C:/cygwin/FAQ.lnk" failed; does the target directory exist?
> (by the way -- this reveals another bug too: The script says "[ -r $t ] && 
> $mks
> ..." where I am sure it should be "[ -r $target ] && $mks ...")
> (and again btw, I am not sure bash should count "[ -r ]" as a true statement)
> The script issues mkshortcut commands with sane arguments, no extra "C:/" in 
> there.
> So I just tried to run the script from an elevated-privilege mintty shell:
>  $ CYGWINFORALL=-A /bin/bash /etc/postinstall/cygwin-doc.sh
> But then it does NOT fail, and the shortcuts do get installed -- they were not
> present before.

CYGWINFORALL=-A requires elevation or security changes to install for all users.
mkshortcut may be defaulting something incorrectly when -A -P is specified
without elevation?
Patch submitted for variable typo - thanks for catching and reporting.

-- 
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: [PATCH] winsup/doc/etc.postinstall.cygwin-doc.sh fix shell variable typo

2017-12-20 Thread Eric Blake


On 12/20/2017 05:01 PM, Brian Inglis wrote:

---
  winsup/doc/etc.postinstall.cygwin-doc.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh 
b/winsup/doc/etc.postinstall.cygwin-doc.sh
index 2873d9395..935bd94e1 100755
--- a/winsup/doc/etc.postinstall.cygwin-doc.sh
+++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
@@ -52,7 +52,7 @@ fi
  # create User Guide and API PDF and HTML shortcuts
  while read target name desc
  do
-   [ -r $t ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" -- 
$target
+   [ -r $target ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" -- 
$target


Wrong.  Needs to be [ -r "$target" ] to be properly quoted.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[PATCH] winsup/doc/etc.postinstall.cygwin-doc.sh fix shell variable typo

---
 winsup/doc/etc.postinstall.cygwin-doc.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh 
b/winsup/doc/etc.postinstall.cygwin-doc.sh
index 2873d9395..935bd94e1 100755
--- a/winsup/doc/etc.postinstall.cygwin-doc.sh
+++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
@@ -52,7 +52,7 @@ fi
 # create User Guide and API PDF and HTML shortcuts
 while read target name desc
 do
-   [ -r $t ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" -- 
$target
+   [ -r $target ] && $mks $CYGWINFORALL -P -n "Cygwin/$name" -d "$desc" -- 
$target
 done <

Re: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else


[Once again, please don't top-post on this list.]

On 12/20/2017 3:48 PM, Vijaya Subramanian wrote:
Is there any reason why Norton would have removed only one dll and left 
all the others alone?


I have no idea.  Do you know that none of the others are missing?  Does 
'cygcheck -c' show that all packages are OK other than liblz4_1?


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: Norton antivirus detects a threat in setup-x86_64.exe

2017-12-20 Thread Greg Taylor

I downloaded the file setup-x86_64.exe again and now the scan reports no
threats.

Version 2.882 was all clear
Version 2.883 downloaded at 12:30pm reported a threat
Version 2.883 downloaded at 2:14pm PST was all clear

I looked in the logs and there was a WS.Reputation.1 risk which is
essentially a crowd sourced threat level.

The following URL explains this type of warning:
https://community.norton.com/en/forums/clarification-wsreputation1-detection



On Wed, Dec 20, 2017 at 1:56 PM, Vijaya Subramanian via cygwin <
cygwin@cygwin.com> wrote:

> Just tell Norton you trust the application-it will say too few users but
> also give you the option to say you trust the app.
>
>
> On Wednesday, December 20, 2017, 2:44:33 PM MST, Sean Murphy <
> s.pat.mu...@gmail.com> wrote:
>
>  On Wed, Dec 20, 2017 at 3:38 PM, Greg Taylor 
> wrote:
> > On 12/20/17 @ 12;20pm PST I downloaded the most recent version of
> > setup-x86_64.exe which was flagged as a threat by Norton Antivirus.
>
> It means Norton's heuristics jump the gun about Cygwin's setup.  I
> encountered this quite a few times in the past before I stopped using
> Norton.
>
> You have to go into Norton's settings and whitelist it as a trusted
> application.
>
> --
> Problem reports:  http://cygwin.com/problems.html
> FAQ:  http://cygwin.com/faq/
> Documentation:http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

--
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: Norton antivirus detects a threat in setup-x86_64.exe

Just tell Norton you trust the application-it will say too few users but also 
give you the option to say you trust the app.

On Wednesday, December 20, 2017, 2:44:33 PM MST, Sean Murphy 
 wrote:  

 On Wed, Dec 20, 2017 at 3:38 PM, Greg Taylor  wrote:
> On 12/20/17 @ 12;20pm PST I downloaded the most recent version of
> setup-x86_64.exe which was flagged as a threat by Norton Antivirus.

It means Norton's heuristics jump the gun about Cygwin's setup.  I
encountered this quite a few times in the past before I stopped using
Norton.

You have to go into Norton's settings and whitelist it as a trusted application.

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

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

Re: Norton antivirus detects a threat in setup-x86_64.exe

2017-12-20 Thread Sean Murphy

On Wed, Dec 20, 2017 at 3:38 PM, Greg Taylor  wrote:
> On 12/20/17 @ 12;20pm PST I downloaded the most recent version of
> setup-x86_64.exe which was flagged as a threat by Norton Antivirus.

It means Norton's heuristics jump the gun about Cygwin's setup.  I
encountered this quite a few times in the past before I stopped using
Norton.

You have to go into Norton's settings and whitelist it as a trusted application.

--
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: Norton antivirus detects a threat in setup-x86_64.exe

2017-12-20 Thread Lee

On 12/20/17, Greg Taylor   wrote:
> On 12/20/17 @ 12;20pm PST I downloaded the most recent version of
> setup-x86_64.exe which was flagged as a threat by Norton Antivirus.

What does https://www.virustotal.com say about the file?  (I get 0/67
- all clean)

You can also download https://cygwin.com/setup-x86_64.exe.sig
& do  gpg --verify setup-x86_64.exe.sig
hopefully you get something along the lines of
gpg: Signature made Mon, Dec 11, 2017  1:36:32 PM EST
gpg:using DSA key 0xA9A262FF676041BA
gpg: Good signature from "Cygwin "

Lee

--
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: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else

Is there any reason why Norton would have removed only one dll and left all the 
others alone?
 

On Wednesday, December 20, 2017, 1:16:05 PM MST, Ken Brown 
 wrote:  
 
 [Please don't top-post on this list.]

On 12/20/2017 1:05 PM, Vijaya Subramanian via cygwin wrote:
> Hi,I found two instances of liblz4-1 (the old version 131) installed in the 
> following directory.windows 
> c:/cygwin65/usr/x86_64-w64-mingw32/sys-root/mingw/binDo you think that is 
> what is causing the problem?

No.

> When I update cygwin, I believe I updated all the recommended packages 
> including mingw.
> I believe I tried installing liblz4-1 using the method Brian mentioned 
> already and that it didn't work, I'll try again.

Do you have any anti-virus software running that might have removed 
cyglz4-1.dll?

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

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

Norton antivirus detects a threat in setup-x86_64.exe

2017-12-20 Thread Greg Taylor

On 12/20/17 @ 12;20pm PST I downloaded the most recent version of
setup-x86_64.exe which was flagged as a threat by Norton Antivirus.

--
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: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else


[Please don't top-post on this list.]

On 12/20/2017 1:05 PM, Vijaya Subramanian via cygwin wrote:

Hi,I found two instances of liblz4-1 (the old version 131) installed in the 
following directory.windows 
c:/cygwin65/usr/x86_64-w64-mingw32/sys-root/mingw/binDo you think that is what 
is causing the problem?


No.


When I update cygwin, I believe I updated all the recommended packages 
including mingw.
I believe I tried installing liblz4-1 using the method Brian mentioned already 
and that it didn't work, I'll try again.


Do you have any anti-virus software running that might have removed 
cyglz4-1.dll?


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: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else

Hi,I found two instances of liblz4-1 (the old version 131) installed in the 
following directory.windows 
c:/cygwin65/usr/x86_64-w64-mingw32/sys-root/mingw/binDo you think that is what 
is causing the problem?
When I update cygwin, I believe I updated all the recommended packages 
including mingw.
I believe I tried installing liblz4-1 using the method Brian mentioned already 
and that it didn't work, I'll try again.
ThanksVijaya
 

On Wednesday, December 20, 2017, 7:08:18 AM MST, Jon Turney 
 wrote: 
On 19/12/2017 18:35, Brian Inglis wrote:
> On 2017-12-19 10:43, Vijaya Subramanian via cygwin wrote:
>> I checked /var/log/setup-full.log and found the below instances where 
>> libz4-1 was mentioned
>> package liblz4-devel comparing versions 131-1 and 131-1, result was 0
>> package liblz4_1 comparing versions 131-1 and 131-1, result was 0
>> package liblz4-devel comparing versions 1.7.5-1 and 131-1, result was -1
>> package liblz4_1 comparing versions 1.7.5-1 and 131-1, result was -1
>> 2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting 
>> already-installed version .
>> 2017/12/02 14:06:47 Changing gid back to original
>> So I am not sure why I get the following message when I run cmake:
>> When I try to run cmake, I get the following error message:
>> C:/cygwin64/bin/cmake.exe: error while loading shared libraries: ?:
>> cannot open shared object file: No such file or directory
>> or why cygcheck cmake says: cygcheck: track_down: could not find cyglz4-1.dll
> 
> Cygwin setup currently has problems upgrading when version numbers change
> formats and a solution is being addressed by the volunteer maintainers.
> 
> You have to manually run Cygwin setup, find the liblz4 packages you have
> installed, and select the new version number to be installed 1.7.5-1.

Of itself, this is not an explanation for a missing cyglz4-1.dll, as it 
is contained in both versions of the package (even if the package 
version has changed, the soversion doesn't change) (compare the package 
contents seen at [1])

[1] https://cygwin.com/packages/x86_64/liblz4_1/

setup thinks liblz4_1 is already installed, so doesn't install it again.

 >> 2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting 
already-installed version .

This is weird, since it seems to indicate that PrereqChecker::isMet() 
noted it as needing to be installed, but that 
PrereqChecker::selectMissing() thinks it is already installed.

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

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

Re: [PATCH setup] Make sure that fatal error messages are visible


On 12/20/2017 11:19 AM, Jon Turney wrote:

On 19/12/2017 00:53, Ken Brown wrote:

The message box produced by TOPLEVEL_CATCH could be hidden by whatever
window was previously being displayed, so that setup appeared to hang.
Fix this by giving fatal error message boxes type MB_SETFOREGROUND.


This is good as far as it goes, but is kind of working around the fact 
that fatal() is being called with an NULL owner HWND.


This is not idea because I guess it means that propsheet window is still 
activate-able when this messagebox is displayed (MB_APPMODAL doesn't 
apply)?


It turns out that MB_SYSTEMMODAL did the job.  I tried MB_APPLMODAL and 
MB_TASKMODAL also, but both of those still allowed me to activate the 
propsheet window.


Revised patch attached.

Ken

From 1f99ac4cc6c2b6c0b39aa84d80985cb21438a242 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Mon, 18 Dec 2017 19:53:00 -0500
Subject: [PATCH setup v2 1/2] Make sure that fatal error messages are visible

The message box produced by TOPLEVEL_CATCH could be hidden by whatever
window was previously being displayed, so that setup appeared to hang.
Fix this by giving fatal error message boxes type MB_SYSTEMMODAL.

This also prevents the user from activating the property sheet
window while the fatal message box is being displayed.
---
 msg.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/msg.cc b/msg.cc
index 403e78a..92c9675 100644
--- a/msg.cc
+++ b/msg.cc
@@ -83,7 +83,7 @@ fatal (HWND owner, int id, ...)
 {
   va_list args;
   va_start (args, id);
-  mbox (owner, "fatal", 0, id, args);
+  mbox (owner, "fatal", MB_SYSTEMMODAL, id, args);
   Logger ().exit (1);
 }
 
-- 
2.15.1

[ANNOUNCEMENT] gobject-introspection 1.52.1-2

The following packages have been uploaded to the Cygwin distribution:

* gobject-introspection-1.52.1-2
* libgirepository1.0_1-1.52.1-2
* libgirepository1.0-devel-1.52.1-2
* libgirepository1.0-doc-1.52.1-2
* girepository-cairo1.0-1.52.1-2
* girepository-GIRepository2.0-1.52.1-2
* girepository-GLib2.0-1.52.1-2
* girepository-x11-1.52.1-2

The goal of the project is to describe GObject APIs and collect them in a 
uniform, machine readable format.

This release includes upstream fixes to allow correct operation when 
libtool is not in use (such as in a Meson build).

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

[ANNOUNCEMENT] appstream-glib 0.7.4-1

The following packages have been uploaded to the Cygwin distribution:

* appstream-glib-0.7.4-1
* appstream-builder-0.7.4-1
* libappstream-glib8-0.7.4-1
* libappstream-glib-devel-0.7.4-1
* libappstream-glib-doc-0.7.4-1
* libappstream-builder8-0.7.4-1
* libappstream-builder-devel-0.7.4-1
* girepository-AppStreamGlib1.0-0.7.4-1
* girepository-AppStreamBuilder1.0-0.7.4-1

This library provides GObjects and helper methods to make it easy to read 
and write AppStream metadata. It also provides a simple DOM implementation 
that makes it easy to edit nodes and convert to and from the standardized 
XML representation. It also supports reading of Debian-style DEP-11 
metadata.

This is an update to the latest upstream release.  The package layout has 
been changed somewhat in order to obsolete the appdata-tools package and 
safely install alongside the new appstream package.

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

appstream-glib 0.7.4-1

The following packages have been uploaded to the Cygwin distribution:

* appstream-glib-0.7.4-1
* appstream-builder-0.7.4-1
* libappstream-glib8-0.7.4-1
* libappstream-glib-devel-0.7.4-1
* libappstream-glib-doc-0.7.4-1
* libappstream-builder8-0.7.4-1
* libappstream-builder-devel-0.7.4-1
* girepository-AppStreamGlib1.0-0.7.4-1
* girepository-AppStreamBuilder1.0-0.7.4-1

This library provides GObjects and helper methods to make it easy to read 
and write AppStream metadata. It also provides a simple DOM implementation 
that makes it easy to edit nodes and convert to and from the standardized 
XML representation. It also supports reading of Debian-style DEP-11 
metadata.

This is an update to the latest upstream release.  The package layout has 
been changed somewhat in order to obsolete the appdata-tools package and 
safely install alongside the new appstream package.

--
Yaakov

[ANNOUNCEMENT] appstream 0.11.7-1

The following packages have been uploaded to the Cygwin distribution:

* appstream-0.11.7-1
* libappstream4-0.11.7-1
* libappstream-devel-0.11.7-1
* libappstream-doc-0.11.7-1
* girepository-AppStream1.0-0.11.7-1
* vala-appstream-0.11.7-1
* libAppStreamQt2-0.11.7-1
* libAppStreamQt-devel-0.11.7-1

AppStream is a cross-distribution effort for enhancing the way we interact 
with the software repositories provided by distributions by standardizing 
software component metadata.

This is the initial release for Cygwin, not to be confused with the 
existing appstream-glib package.

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

appstream 0.11.7-1

The following packages have been uploaded to the Cygwin distribution:

* appstream-0.11.7-1
* libappstream4-0.11.7-1
* libappstream-devel-0.11.7-1
* libappstream-doc-0.11.7-1
* girepository-AppStream1.0-0.11.7-1
* vala-appstream-0.11.7-1
* libAppStreamQt2-0.11.7-1
* libAppStreamQt-devel-0.11.7-1

AppStream is a cross-distribution effort for enhancing the way we interact 
with the software repositories provided by distributions by standardizing 
software component metadata.

This is the initial release for Cygwin, not to be confused with the 
existing appstream-glib package.

--
Yaakov

Re: [PATCH setup] Throw exceptions instead of exiting with error codes


On 12/20/2017 11:06 AM, Jon Turney wrote:

On 19/12/2017 17:20, Ken Brown wrote:

---
  Exception.h |  1 +
  PickView.cc | 11 +++
  choose.cc   |  7 +--
  3 files changed, 13 insertions(+), 6 deletions(-)


Yeah, silently dying seems like a bad idea.

Hmmm... does this not need a corresponding use of TOPLEVEL_CATCH to 
transform that exception into a fatal() ?


It's already caught by a TOPLEVEL_CATCH.

In any case, some commentary in the commit about how these exceptions 
are expected to be handled would good.


Revised patch attached.

Ken
From 7e41d3bcd3994394b775744b3c53b7a8f54b2282 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Tue, 19 Dec 2017 11:10:22 -0500
Subject: [PATCH setup v2] Throw exceptions instead of exiting with error codes

There were two places in PickView.cc and one in choose.cc where setup
would silently die with an error code.  Change this so that setup now
throws exceptions.  The exceptions are caught by
TOPLEVEL_CATCH("DialogProc") in PropertyPage::DialogProc().
---
 Exception.h |  1 +
 PickView.cc | 11 +++
 choose.cc   |  7 +--
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/Exception.h b/Exception.h
index 7b16612..15a145e 100644
--- a/Exception.h
+++ b/Exception.h
@@ -36,6 +36,7 @@ private:
 #define APPERR_CORRUPT_PACKAGE 1
 #define APPERR_IO_ERROR2
 #define APPERR_LOGIC_ERROR 3
+#define APPERR_WINDOW_ERROR4
 
 #define TOPLEVEL_CATCH(threadname)  \
   catch (Exception *e)  \
diff --git a/PickView.cc b/PickView.cc
index d24866c..2e1beda 100644
--- a/PickView.cc
+++ b/PickView.cc
@@ -27,6 +27,7 @@
 /* For 'source' */
 #include "state.h"
 #include "LogSingleton.h"
+#include "Exception.h"
 
 using namespace std;
 
@@ -539,8 +540,9 @@ PickView::init(views _mode)
 HDS_HORZ, 0, 0, 0, 0, GetHWND(),
 (HMENU) IDC_CHOOSE_LISTHEADER, hinstance,
 (LPVOID) NULL)) == NULL)
-// FIXME: throw an exception
-exit (10);
+throw new Exception (TOSTRING(__LINE__) " " __FILE__,
+"Unable to create list header window",
+APPERR_WINDOW_ERROR);
 
   // Retrieve the bounding rectangle of the parent window's
   // client area, and then request size and position values
@@ -550,8 +552,9 @@ PickView::init(views _mode)
   hdl.prc = 
   hdl.pwpos = 
   if (!SendMessage (listheader, HDM_LAYOUT, 0, (LPARAM) & hdl))
-// FIXME: throw an exception
-exit (11);
+throw new Exception (TOSTRING(__LINE__) " " __FILE__,
+"Unable to get size and position of rectangle",
+APPERR_WINDOW_ERROR);
 
   // Set the font of the listheader, but don't redraw, because its not shown
   // yet.This message does not return a value, so we are not checking it as we
diff --git a/choose.cc b/choose.cc
index c78f55d..32600c8 100644
--- a/choose.cc
+++ b/choose.cc
@@ -57,6 +57,8 @@
 
 #include "UserSettings.h"
 
+#include "Exception.h"
+
 #include "getopt++/BoolOption.h"
 static BoolOption UpgradeAlsoOption (false, 'g', "upgrade-also", "also upgrade 
installed packages");
 static BoolOption CleanOrphansOption (false, 'o', "delete-orphans", "remove 
orphaned packages");
@@ -143,8 +145,9 @@ ChooserPage::createListview ()
   chooser = new PickView (cat);
   RECT r = getDefaultListViewSize();
   if (!chooser->Create(this, WS_CHILD | WS_HSCROLL | WS_VSCROLL | 
WS_VISIBLE,))
-// TODO throw exception
-exit (11);
+throw new Exception (TOSTRING(__LINE__) " " __FILE__,
+"Unable to create chooser list window",
+APPERR_WINDOW_ERROR);
   chooser->init(PickView::views::Category);
   chooser->Show(SW_SHOW);
   chooser->setViewMode (!is_new_install || UpgradeAlsoOption || 
hasManualSelections ?
-- 
2.15.1

Re: [PATCH setup] Make sure that fatal error messages are visible


On 19/12/2017 00:53, Ken Brown wrote:

The message box produced by TOPLEVEL_CATCH could be hidden by whatever
window was previously being displayed, so that setup appeared to hang.
Fix this by giving fatal error message boxes type MB_SETFOREGROUND.


This is good as far as it goes, but is kind of working around the fact 
that fatal() is being called with an NULL owner HWND.


This is not idea because I guess it means that propsheet window is still 
activate-able when this messagebox is displayed (MB_APPMODAL doesn't apply)?



---
  msg.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/msg.cc b/msg.cc
index 403e78a..0ba4839 100644
--- a/msg.cc
+++ b/msg.cc
@@ -83,7 +83,7 @@ fatal (HWND owner, int id, ...)
  {
va_list args;
va_start (args, id);
-  mbox (owner, "fatal", 0, id, args);
+  mbox (owner, "fatal", MB_SETFOREGROUND, id, args);
Logger ().exit (1);
  }

Re: cygwin installation fails in Windows 10 when running with --quite-mode

2017-12-20 Thread n8tm via cygwin

Cygwin installer annoys virus checkers which never used to care.  White list 
setup.exe before casting blame



Sent via the Samsung Galaxy S8 Active, an AT 4G LTE smartphone
 Original message From: Arkady  Date: 
12/20/17  7:37 AM  (GMT-05:00) To: cygwin@cygwin.com Subject: Re: cygwin 
installation fails in Windows 10 when running with --quite-mode 
I have little doubt that here is a bug in the Cygwin installer. I
reproduce the problem
consistently. I use the following command 10 times
setup-x86.exe -q -s http://cygwin.mirror.constant.com
The setup fails one time of three in my Win10 64 bits setup.

On Wed, Dec 20, 2017 at 2:25 PM, Arkady  wrote:
> On Wed, Dec 20, 2017 at 12:27 PM, Achim Gratz  wrote:
>> Arkady writes:
>>> setup-x86_64.exe -q -p wget -v
>>>
>>> The installation fails with the last line "Changing gid to
>>> Administrators" and a small dialog box "setup-x86_64.exe" has stopped
>>> working A problem caused the program to stop working correctly..."
>>
>> That is usually caused by BLODA that recognizes an application that
>> tries to elevate itself while run from some script.  The solution may be
>> as simple as to remove the ADS annotation that says "this executable was
>> downloaded from the dangerous internet" or you may have to explicitly
>
> Thank you, Achim,
>
> I am running in the Administrator console - there is "Administrator:
> Command Prompt" at the top
> of the windows. I am pulling the file from Internet using a power shell 
> script.
> According to dir /R there is only one data stream for the file
>
>> except setup.exe someplace.  Other potential solutions are to start the
>> CMD or script with administrative privileges so setup doesn't need to
>> elevate itslef or use a program like runas that can start setup directly
>> with elevated privileges.  Which of these is most appropriate to your
>> environment is something you'll have to find out yourself.
>>
>>
>> Regards,
>> Achim.
>> --
>> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>>
>> SD adaptation for Waldorf microQ V2.22R2:
>> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>>
>> --
>> Problem reports:   http://cygwin.com/problems.html
>> FAQ:   http://cygwin.com/faq/
>> Documentation: http://cygwin.com/docs.html
>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>>

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


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

Re: [PATCH setup] Throw exceptions instead of exiting with error codes


On 19/12/2017 17:20, Ken Brown wrote:

---
  Exception.h |  1 +
  PickView.cc | 11 +++
  choose.cc   |  7 +--
  3 files changed, 13 insertions(+), 6 deletions(-)


Yeah, silently dying seems like a bad idea.

Hmmm... does this not need a corresponding use of TOPLEVEL_CATCH to 
transform that exception into a fatal() ?


Or does the default handling of the exception by the runtime report the 
error?


In any case, some commentary in the commit about how these exceptions 
are expected to be handled would good.

Re: mkshortcut fails when run from setup, postinstall/cygwin-doc.sh - not otherwise

2017-12-20 Thread Eric Blake


On 12/20/2017 06:59 AM, Enrique Perez-Terron wrote:

So I have added a line "set -x" at the top in postinstall/cygwin-doc.sh, 
and the relevant section becomes


  + read target name desc
  + '[' -r ']'





(by the way -- this reveals another bug too: The script says "[ -r $t ] 
&& $mks ..." where I am sure it should be "[ -r $target ] && $mks ...")


Or, rather,

[ -r "$target" ]

It is almost always a bug to use [ ] without quoting "$..." expansions, 
because if the expansion of $... is empty, it changes the number of 
arguments to [ and thus the test that [ performs.


If your script uses #!/bin/bash, then you can use bashisms like:

[[ -r $target ]]

which do the right thing ('[[' is part of the shell grammar, rather than 
treated like an executable; as such, you can safely omit quoting in that 
form; but '[[' is not yet POSIX and is not supported on dash).


(and again btw, I am not sure bash should count "[ -r ]" as a true 
statement)


I am.  POSIX requires that behavior.  Any time you have exactly one 
argument to '[', the result is true unless that argument was the empty 
string.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

--
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: cygwin installation fails in Windows 10 when running with --quite-mode


On 20/12/2017 12:43, Arkady wrote:

I can upload VirtualBox VM which demonstrates the problem - this is
14GB image for VirtualBox 5.1.30


Please don't.

In any case, you might wish to consult the license you have for Windows 
to see if you are permitted to do this...



On Wed, Dec 20, 2017 at 2:38 PM, Arkady  wrote:

Another clue - flags -d -n -N probably solve the problem or make the
problem very rare

On Wed, Dec 20, 2017 at 2:37 PM, Arkady  wrote:

I have little doubt that here is a bug in the Cygwin installer. I
reproduce the problem
consistently. I use the following command 10 times
setup-x86.exe -q -s http://cygwin.mirror.constant.com
The setup fails one time of three in my Win10 64 bits setup.


Wait what? are you using setup-x86.exe? or setup-x86_64.exe?

I have run this command many times, but I can't reproduce this problem.

Despite more than 10 emails from you on this subject, you still haven't 
mentioned what version of setup you are using.


You might like to try installing the cygwin upx and gdb packages, and 
then (assuming you are using setup 2.883):


upx -d setup-x86-64.exe
wget https://cygwin.com/setup/setup-2.883.x86_64.dbg
mv setup-2.883.x86_64.dbg setup.dbg

and then, in an elevated shell:

gdb --args setup-x86-64.exe -q -s http://cygwin.mirror.constant.com

at the '(gdb)' prompt

(gdb) r

when your error occurs:

(gdb) bt


--
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: cmake install; required cyglz4-1.dll not installed in /usr/bin or anywhere else


On 19/12/2017 18:35, Brian Inglis wrote:

On 2017-12-19 10:43, Vijaya Subramanian via cygwin wrote:

I checked /var/log/setup-full.log and found the below instances where libz4-1 
was mentioned
package liblz4-devel comparing versions 131-1 and 131-1, result was 0
package liblz4_1 comparing versions 131-1 and 131-1, result was 0
package liblz4-devel comparing versions 1.7.5-1 and 131-1, result was -1
package liblz4_1 comparing versions 1.7.5-1 and 131-1, result was -1
2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting 
already-installed version .
2017/12/02 14:06:47 Changing gid back to original
So I am not sure why I get the following message when I run cmake:
When I try to run cmake, I get the following error message:
C:/cygwin64/bin/cmake.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or directory
or why cygcheck cmake says: cygcheck: track_down: could not find cyglz4-1.dll


Cygwin setup currently has problems upgrading when version numbers change
formats and a solution is being addressed by the volunteer maintainers.

You have to manually run Cygwin setup, find the liblz4 packages you have
installed, and select the new version number to be installed 1.7.5-1.


Of itself, this is not an explanation for a missing cyglz4-1.dll, as it 
is contained in both versions of the package (even if the package 
version has changed, the soversion doesn't change) (compare the package 
contents seen at [1])


[1] https://cygwin.com/packages/x86_64/liblz4_1/

setup thinks liblz4_1 is already installed, so doesn't install it again.

>> 2017/12/02 14:06:47 Adding required dependency liblz4_1: Selecting 
already-installed version .


This is weird, since it seems to indicate that PrereqChecker::isMet() 
noted it as needing to be installed, but that 
PrereqChecker::selectMissing() thinks it is already installed.


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

mkshortcut fails when run from setup, postinstall/cygwin-doc.sh - not otherwise

2017-12-20 Thread Enrique Perez-Terron


Lately, whenever I run setup (x86), my /var/log/setup.log.full contains:

 2017/12/20 03:07:44 running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/cygwin-doc.sh"
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/User Guide (PDF).lnk" failed; does the target 
directory exist?
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/User Guide (HTML).lnk" failed; does the target 
directory exist?
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/API (PDF).lnk" failed; does the target directory 
exist?
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/API (HTML).lnk" failed; does the target 
directory exist?
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/Home Page.lnk" failed; does the target directory 
exist?
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/FAQ.lnk" failed; does the target directory 
exist?

 2017/12/20 03:07:45 abnormal exit: exit code=3

Please notice the extra C:/ in front of the target link name.

So I have added a line "set -x" at the top in  
postinstall/cygwin-doc.sh, and the relevant section becomes


 + read target name desc
 + '[' -r ']'
 + /bin/mkshortcut -A -P -n 'Cygwin/User Guide (PDF)' -d 'Cygwin User 
Guide PDF' -- /usr/share/doc/cygwin-doc/cygwin-ug-net.pdf
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/User Guide (PDF).lnk" failed; does the target 
directory exist?

 + read target name desc
 + '[' -r ']'
 + /bin/mkshortcut -A -P -n 'Cygwin/User Guide (HTML)' -d 'Cygwin User 
Guide HTML' -- /usr/share/doc/cygwin-doc/html/cygwin-ug-net/index.html
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/User Guide (HTML).lnk" failed; does the target 
directory exist?

 + read target name desc
 + '[' -r ']'
 + /bin/mkshortcut -A -P -n 'Cygwin/API (PDF)' -d 'Cygwin API Reference 
PDF' -- /usr/share/doc/cygwin-doc/cygwin-api.pdf
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/API (PDF).lnk" failed; does the target directory 
exist?

 + read target name desc
 + '[' -r ']'
 + /bin/mkshortcut -A -P -n 'Cygwin/API (HTML)' -d 'Cygwin API Reference 
HTML' -- /usr/share/doc/cygwin-doc/html/cygwin-api/index.html
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/API (HTML).lnk" failed; does the target 
directory exist?

 + read target name desc
 + read target name desc
 + /bin/mkshortcut -A -P -n 'Cygwin/Home Page' -d 'Cygwin Home Page 
Link' -a https://cygwin.com/index.html -- /bin/cygstart
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/Home Page.lnk" failed; does the target directory 
exist?

 + read target name desc
 + /bin/mkshortcut -A -P -n Cygwin/FAQ -d 'Cygwin Frequently Asked 
Questions Link' -a https://cygwin.com/faq.html -- /bin/cygstart
 mkshortcut: Saving "/cygdrive/c/ProgramData/Microsoft/Windows/Start 
Menu/Programs/C:/cygwin/FAQ.lnk" failed; does the target directory 
exist?



(by the way -- this reveals another bug too: The script says "[ -r $t ] 
&& $mks ..." where I am sure it should be "[ -r $target ] && $mks ...")
(and again btw, I am not sure bash should count "[ -r ]" as a true 
statement)




The script issues mkshortcut commands with sane arguments, no extra 
"C:/" in there.


So I just tried to run the script from an elevated-privilege mintty 
shell:


 $ CYGWINFORALL=-A /bin/bash /etc/postinstall/cygwin-doc.sh

But then it does NOT fail, and the shortcuts do get installed -- they 
were not present before.



I am still running the 32-bit cygwin, though on a 64-bit windows 10 Home 
edition, version 1709, OS build 16299.125.


Any ideas about what could be the problem?

-Enrique

--
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: cygwin installation fails in Windows 10 when running with --quite-mode

I can upload VirtualBox VM which demonstrates the problem - this is
14GB image for VirtualBox 5.1.30

On Wed, Dec 20, 2017 at 2:38 PM, Arkady  wrote:
> Another clue - flags -d -n -N probably solve the problem or make the
> problem very rare
>
> On Wed, Dec 20, 2017 at 2:37 PM, Arkady  wrote:
>> I have little doubt that here is a bug in the Cygwin installer. I
>> reproduce the problem
>> consistently. I use the following command 10 times
>> setup-x86.exe -q -s http://cygwin.mirror.constant.com
>> The setup fails one time of three in my Win10 64 bits setup.
>>
>> On Wed, Dec 20, 2017 at 2:25 PM, Arkady  wrote:
>>> On Wed, Dec 20, 2017 at 12:27 PM, Achim Gratz  wrote:
 Arkady writes:
> setup-x86_64.exe -q -p wget -v
>
> The installation fails with the last line "Changing gid to
> Administrators" and a small dialog box "setup-x86_64.exe" has stopped
> working A problem caused the program to stop working correctly..."

 That is usually caused by BLODA that recognizes an application that
 tries to elevate itself while run from some script.  The solution may be
 as simple as to remove the ADS annotation that says "this executable was
 downloaded from the dangerous internet" or you may have to explicitly
>>>
>>> Thank you, Achim,
>>>
>>> I am running in the Administrator console - there is "Administrator:
>>> Command Prompt" at the top
>>> of the windows. I am pulling the file from Internet using a power shell 
>>> script.
>>> According to dir /R there is only one data stream for the file
>>>
 except setup.exe someplace.  Other potential solutions are to start the
 CMD or script with administrative privileges so setup doesn't need to
 elevate itslef or use a program like runas that can start setup directly
 with elevated privileges.  Which of these is most appropriate to your
 environment is something you'll have to find out yourself.


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

 SD adaptation for Waldorf microQ V2.22R2:
 http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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


--
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: cygwin installation fails in Windows 10 when running with --quite-mode

Another clue - flags -d -n -N probably solve the problem or make the
problem very rare

On Wed, Dec 20, 2017 at 2:37 PM, Arkady  wrote:
> I have little doubt that here is a bug in the Cygwin installer. I
> reproduce the problem
> consistently. I use the following command 10 times
> setup-x86.exe -q -s http://cygwin.mirror.constant.com
> The setup fails one time of three in my Win10 64 bits setup.
>
> On Wed, Dec 20, 2017 at 2:25 PM, Arkady  wrote:
>> On Wed, Dec 20, 2017 at 12:27 PM, Achim Gratz  wrote:
>>> Arkady writes:
 setup-x86_64.exe -q -p wget -v

 The installation fails with the last line "Changing gid to
 Administrators" and a small dialog box "setup-x86_64.exe" has stopped
 working A problem caused the program to stop working correctly..."
>>>
>>> That is usually caused by BLODA that recognizes an application that
>>> tries to elevate itself while run from some script.  The solution may be
>>> as simple as to remove the ADS annotation that says "this executable was
>>> downloaded from the dangerous internet" or you may have to explicitly
>>
>> Thank you, Achim,
>>
>> I am running in the Administrator console - there is "Administrator:
>> Command Prompt" at the top
>> of the windows. I am pulling the file from Internet using a power shell 
>> script.
>> According to dir /R there is only one data stream for the file
>>
>>> except setup.exe someplace.  Other potential solutions are to start the
>>> CMD or script with administrative privileges so setup doesn't need to
>>> elevate itslef or use a program like runas that can start setup directly
>>> with elevated privileges.  Which of these is most appropriate to your
>>> environment is something you'll have to find out yourself.
>>>
>>>
>>> Regards,
>>> Achim.
>>> --
>>> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>>>
>>> SD adaptation for Waldorf microQ V2.22R2:
>>> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>>>
>>> --
>>> Problem reports:   http://cygwin.com/problems.html
>>> FAQ:   http://cygwin.com/faq/
>>> Documentation: http://cygwin.com/docs.html
>>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>>>

--
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: cygwin installation fails in Windows 10 when running with --quite-mode

I have little doubt that here is a bug in the Cygwin installer. I
reproduce the problem
consistently. I use the following command 10 times
setup-x86.exe -q -s http://cygwin.mirror.constant.com
The setup fails one time of three in my Win10 64 bits setup.

On Wed, Dec 20, 2017 at 2:25 PM, Arkady  wrote:
> On Wed, Dec 20, 2017 at 12:27 PM, Achim Gratz  wrote:
>> Arkady writes:
>>> setup-x86_64.exe -q -p wget -v
>>>
>>> The installation fails with the last line "Changing gid to
>>> Administrators" and a small dialog box "setup-x86_64.exe" has stopped
>>> working A problem caused the program to stop working correctly..."
>>
>> That is usually caused by BLODA that recognizes an application that
>> tries to elevate itself while run from some script.  The solution may be
>> as simple as to remove the ADS annotation that says "this executable was
>> downloaded from the dangerous internet" or you may have to explicitly
>
> Thank you, Achim,
>
> I am running in the Administrator console - there is "Administrator:
> Command Prompt" at the top
> of the windows. I am pulling the file from Internet using a power shell 
> script.
> According to dir /R there is only one data stream for the file
>
>> except setup.exe someplace.  Other potential solutions are to start the
>> CMD or script with administrative privileges so setup doesn't need to
>> elevate itslef or use a program like runas that can start setup directly
>> with elevated privileges.  Which of these is most appropriate to your
>> environment is something you'll have to find out yourself.
>>
>>
>> Regards,
>> Achim.
>> --
>> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>>
>> SD adaptation for Waldorf microQ V2.22R2:
>> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>>
>> --
>> Problem reports:   http://cygwin.com/problems.html
>> FAQ:   http://cygwin.com/faq/
>> Documentation: http://cygwin.com/docs.html
>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>>

--
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: cygwin installation fails in Windows 10 when running with --quite-mode