Re: mutt no longer sending mail

[Ben Altman]

On Thu, Dec 14, 2017 at 2:36 AM, Ben Altman  wrote:
> I accidentally removed parts of my cygwin installation. I reinstalled
> it with mutt, sendmail and ssmtp. I ran ssmtp-config and set it up as
> before with some minor modifications afterwards to
> /etc/ssmtp/ssmtp.conf. I also compared it to another machine I have
> and the files were basically the same. Despite this, when I do a basic
> test that used to work, it now gives me an error:
> Error sending message, child exited 127 (Exec error.).
> Could not send the message.
>
> I do have another machine where it is working and an installation of
> babun on the same machine as the one where it is not working that does
> have mutt working but I would like to get it working with cygwin on
> the machine I messed up. I googled around without success and was
> wondering if anyone could make some suggestions that would help me in
> this situation?

I should also mention that the PC has Windows 7 and it is the 32 bit
version of cygwin.
Ben

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

mutt no longer sending mail

[Ben Altman]

I accidentally removed parts of my cygwin installation. I reinstalled
it with mutt, sendmail and ssmtp. I ran ssmtp-config and set it up as
before with some minor modifications afterwards to
/etc/ssmtp/ssmtp.conf. I also compared it to another machine I have
and the files were basically the same. Despite this, when I do a basic
test that used to work, it now gives me an error:
Error sending message, child exited 127 (Exec error.).
Could not send the message.

I do have another machine where it is working and an installation of
babun on the same machine as the one where it is not working that does
have mutt working but I would like to get it working with cygwin on
the machine I messed up. I googled around without success and was
wondering if anyone could make some suggestions that would help me in
this situation?

Thanks,
Ben

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

[PATCH] Implement sigtimedwait

[Mark Geisert]

Abstract out common code from sigwait/sigwaitinfo/sigtimedwait to implement the 
latter.
---
 winsup/cygwin/common.din   |  1 +
 winsup/cygwin/include/cygwin/version.h |  3 ++-
 winsup/cygwin/signal.cc| 32 ++--
 winsup/cygwin/thread.cc|  2 +-
 winsup/doc/posix.xml   |  2 +-
 5 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/common.din b/winsup/cygwin/common.din
index 14b9c2c18..91f2915bf 100644
--- a/winsup/cygwin/common.din
+++ b/winsup/cygwin/common.din
@@ -1326,6 +1326,7 @@ sigrelse SIGFE
 sigset SIGFE
 sigsetjmp NOSIGFE
 sigsuspend SIGFE
+sigtimedwait SIGFE
 sigwait SIGFE
 sigwaitinfo SIGFE
 sin NOSIGFE
diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index 0fee73c1d..aa7c14ec3 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -492,12 +492,13 @@ details. */
   321: Export wmempcpy.
   322: [w]scanf %m modifier.
   323: scanf %l[ conversion.
+  324: Export sigtimedwait.
 
   Note that we forgot to bump the api for ualarm, strtoll, strtoull,
   sigaltstack, sethostname. */
 
 #define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 323
+#define CYGWIN_VERSION_API_MINOR 324
 
 /* There is also a compatibity version number associated with the shared memory
regions.  It is incremented when incompatible changes are made to the shared
diff --git a/winsup/cygwin/signal.cc b/winsup/cygwin/signal.cc
index 69c5e2aad..0599d8a3e 100644
--- a/winsup/cygwin/signal.cc
+++ b/winsup/cygwin/signal.cc
@@ -575,6 +575,28 @@ siginterrupt (int sig, int flag)
   return res;
 }
 
+static int sigwait_common (const sigset_t *, siginfo_t *, PLARGE_INTEGER);
+
+extern "C" int
+sigtimedwait (const sigset_t *set, siginfo_t *info, const timespec *timeout)
+{
+  LARGE_INTEGER cwaittime;
+
+  if (timeout)
+{
+  if (timeout->tv_sec < 0
+   || timeout->tv_nsec < 0 || timeout->tv_nsec > 10LL)
+   {
+ set_errno (EINVAL);
+ return -1;
+   }
+  cwaittime.QuadPart = (LONGLONG) timeout->tv_sec * NSPERSEC
+  + ((LONGLONG) timeout->tv_nsec + 99LL) / 100LL;
+}
+
+  return sigwait_common (set, info, timeout ?  : cw_infinite);
+}
+
 extern "C" int
 sigwait (const sigset_t *set, int *sig_ptr)
 {
@@ -582,7 +604,7 @@ sigwait (const sigset_t *set, int *sig_ptr)
 
   do
 {
-  sig = sigwaitinfo (set, NULL);
+  sig = sigwait_common (set, NULL, cw_infinite);
 }
   while (sig == -1 && get_errno () == EINTR);
   if (sig > 0)
@@ -592,6 +614,12 @@ sigwait (const sigset_t *set, int *sig_ptr)
 
 extern "C" int
 sigwaitinfo (const sigset_t *set, siginfo_t *info)
+{
+  return sigwait_common (set, info, cw_infinite);
+}
+
+static int
+sigwait_common (const sigset_t *set, siginfo_t *info, PLARGE_INTEGER cwaittime)
 {
   int res = -1;
 
@@ -602,7 +630,7 @@ sigwaitinfo (const sigset_t *set, siginfo_t *info)
   set_signal_mask (_my_tls.sigwait_mask, *set);
   sig_dispatch_pending (true);
 
-  switch (cygwait (NULL, cw_infinite, cw_sig_eintr | cw_cancel | 
cw_cancel_self))
+  switch (cygwait (NULL, cwaittime, cw_sig_eintr | cw_cancel | 
cw_cancel_self))
{
case WAIT_SIGNALED:
  if (!sigismember (set, _my_tls.infodata.si_signo))
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index b9b2c7aaa..f3c709a15 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -708,7 +708,7 @@ pthread::cancel ()
 * sendto ()
 * sigpause ()
 * sigsuspend ()
-o sigtimedwait ()
+* sigtimedwait ()
 * sigwait ()
 * sigwaitinfo ()
 * sleep ()
diff --git a/winsup/doc/posix.xml b/winsup/doc/posix.xml
index ab574300f..2664159e1 100644
--- a/winsup/doc/posix.xml
+++ b/winsup/doc/posix.xml
@@ -888,6 +888,7 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008).
 sigset
 sigsetjmp
 sigsuspend
+sigtimedwait
 sigwait
 sigwaitinfo
 sin
@@ -1582,7 +1583,6 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008).
 pthread_mutex_consistent
 putmsg
 setnetent
-sigtimedwait
 timer_getoverrun
 ulimit
 waitid
-- 
2.15.1

Bug Vim/GVim Ruby support broken

[Ameya Vikram Singh]

The latest Vim/GVim package currently available on Cygwin Packages has
broken ruby support.

Here is the stackoverflow question about the same:
https://stackoverflow.com/questions/47356294/cygwin-installing-vim-with-ruby-support

and here is the short list of the status of ruby support on Vim.
vim-8.0.1157-1 - vim: Ruby support is working
vim-8.0.1216-1 - vim: Ruby support is currently broken
vim-8.0.1376-1 - vim: Ruby support is currently broken

Currently I am manually using the older version(8.0.1157-1).

-- 
Regards,
Ameya Vikram Singh

--
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: Need help with multibyte UTF-8 characters

[Brian Inglis]

On 2017-12-13 00:50, Thomas Wolff wrote:
> Am 13.12.2017 um 06:21 schrieb Brian Inglis:
>> On 2017-12-04 18:23, Thomas Taylor wrote:
>> Your Windows Regional settings and your mintty/Options/Text/Language and
>> Character Set should be set to match.
>> The profile commands below set Cygwin locale to your Windows Regional 
>> settings
>> and charset to UTF-8, or Unix locale to your system locale.
>> Otherwise your system or mintty is going to be doing conversions on each
>> character.
> I am not aware that mintty character display and Windows regional settings 
> would
> interfere in any way you indicated.
> Can you elaborate on this please?

Maybe I'm just too optimistic that software will DTRT to ensure that output is
faithfully passed thru, or converted for the next layer of software, if it has
different settings.
I set all of my locales the same so characters should pass thru transparently
and I can see output faithfully rendered, given adequate font configurations.

What happens when your system, terminal, and shell locales and charsets differ?
Either some component/-s has/have to do conversion to provide readable output,
which is my expectation given the requirement to specify locales and charsets,
or you could end up with garbled output if nothing is doing any conversion.
Does one override others to pass thru readable output, does conversion occur, or
do you just see junk in some or all cases when locales and charsets differ?

I am ignoring here the effect on text content, input and output formatting of
selecting languages, territories, and scripts.

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

[ANNOUNCEMENT] autoconf-archive 2017.09.28-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* autoconf-archive-2017.09.28-1

The GNU Autoconf Archive is a collection of more than 450 macros for GNU 
Autoconf that have been contributed as free software by friendly supporters 
of the cause from all over the Internet.

This is an update to the latest upstream release.

--
Yaakov

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

Re: setup's response to a "corrupt local copy"

[Hans-Bernhard Bröker]

Am 13.12.2017 um 14:28 schrieb Ken Brown:

When setup is preparing to download files and it finds a corrupt copy in 
the local cache, it issues a fatal error message telling the user to 
remove the corrupt file and retry.  Steven said that setup should 
silently delete the corrupt file, while I argued in favor of the current 
behavior, on the grounds that setup shouldn't be deleting user files if 
it doesn't know where they came from.


I agree with the latter approach, primarily because those files must 
have still been OK the last time setup was run successfully, or not have 
been there at all.  Otherwise this run of setup wouldn't be the one 
where this suddenly popped up, would it.  So the real question is: how 
could that status have changed from then to now?


First off, I hope we agree that files very rarely change their content 
just by lying around somewhere, particularly in a local cache folder 
structure like this, which will usually not be touched by anything other 
than setup itself.  So the odds should really be negligible that the 
files just corrupted themselves.  If those are sizable odds on a given 
machine, the ease of further cygwin installs done onto it are the least 
of your worries.


That leaves two primary possibilities how this change of state might 
have occurred:


1) File contents changed on purpose, probably by manual overwrite with 
locally built archives.


2) setup's idea of what a correct file is changed from one run of 
setup.exe to the next, mostly likely by loading a newer setup.ini


There is a middle ground: setup could query the user.  Additionally, as 
suggested by cyg Simple, there could be an option that directs setup to 
silently remove corrupt files.


I agree: this is essentially the same situation as a merge conflict in 
CVS/SVN/git: upstream (setup.ini) and local working copy (archive) are 
now in conflict, and you really _have_to_ ask the user about what to do 
about it.  The query should contain relevant details (CRC expected vs. 
observed, timestamps, whatever) to allow the user to make an informed 
decision, and it might better offer an extra wide selection of answers, 
such as Back to selection, Delete this, Delete all, Keep this, Keep all, 
and possibly even "Back up local file for later inspection".


A command line switch really won't do, because its setting would be 
decided either way too early or slightly too late for that decision to 
have any reliable relation to what the user needs to happen in the case 
at hand.  It would unavoidably trigger irate user feedback like


	"This switch solved some arcane problem I don't even remember any more, 
years ago, so I hardcoded it in the start script; and _now_ you tell me 
that's what killed my local, irreplacable cygwin packages?"


one way, or

	"If just some junk file needed to be deleted, why on earth does that 
mean I have to step through that entire, tedious setup and package 
selection _again_!!??!@"


the other.

--
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 00/14] Use libsolv, solve all our problems... (WIP)

[Ken Brown]

On 12/13/2017 1:05 PM, Achim Gratz wrote:

Ken Brown writes:

1. Uninstall A.
2. Don't uninstall B.

On the surface, it would seem that libsolv chose 2 by default, because
it returned an empty transaction list.  This was reflected in the log
and was also clear when I selected 'Back'.


I don't think there is a default in this case.  I also see in zypper
that the order of the proposed solutions (there can be way more than two
if the dependencies are more complicated) is not always the same, so
there is no preference implied by the order as well.


Maybe we have to deal with this situation ourselves.  Whenever a
problem involves a missing dependency, we could choose as default
solution the one that installs/keeps the dependent package, as is
currently done.


That solution unfortunately isn't always the one that causes the least
amount of transactions or even the least amount of breakage.


That may be true, but I still think it's a reasonable default.  The user 
doesn't have to accept it.  Also, it's consistent with what setup 
currently does, so it won't surprise anyone.


The attached patch attempts to implement my suggestion.

Ken

From 65cb5413e81794829cbddeebc6826d04115f2a49 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Wed, 13 Dec 2017 17:20:26 -0500
Subject: [PATCH] Implement a default solution for SOLVER_RULE_PKG_REQUIRES

If libsolv reports a SOLVER_RULE_PKG_REQUIRES problem, it means that
the user chose to uninstall or skip a required package.  Add an
appropriate transInstall transaction if necessary, to override this
choice.  The user will have to uncheck the "Accept default problem
solutions" box to insist on the original choice.
---
 libsolv.cc | 18 +++---
 libsolv.h  |  2 +-
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/libsolv.cc b/libsolv.cc
index 0fb39c7..9977926 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -868,7 +868,7 @@ SolverSolution::transactions() const
 
 // Construct a string reporting the problems and solutions
 std::string
-SolverSolution::report() const
+SolverSolution::report()
 {
   packagedb db;
   std::string r = "";
@@ -881,8 +881,20 @@ SolverSolution::report() const
   Id probr = solver_findproblemrule(solv, problem);
   Id dep, source, target;
   SolverRuleinfo type = solver_ruleinfo(solv, probr, , , 
);
-  if (source == db.basepkg.id)
-   r += "package " + std::string(pool_dep2str(pool.pool, dep)) + " is a 
Base package and is therefore required";
+  if (type == SOLVER_RULE_PKG_REQUIRES)
+   {
+ packagemeta *pkg = 
db.findBinary(PackageSpecification(pool_dep2str(pool.pool, dep)));
+ if (!pkg->desired && pkg->installed < pkg->default_version)
+   // User chose to uninstall or skip a required package.
+   trans.push_back(SolverTransaction(pkg->default_version,
+ SolverTransaction::transInstall));
+ if (source == db.basepkg.id)
+   r += "package " + std::string(pool_dep2str(pool.pool, dep))
+ + " is a Base package and is therefore required";
+ else
+   r += "package " + std::string(pool_dep2str(pool.pool, dep)) +
+ " is  required by " + std::string(pool_solvid2str(pool.pool, 
source));
+   }
   else
r += solver_problemruleinfo2str(solv, type, source, target, dep);
   r += "\n";
diff --git a/libsolv.h b/libsolv.h
index cddf76f..391a96d 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -253,7 +253,7 @@ class SolverSolution
 updateForce, // distupdate: downgrade if necessary to best version in repo
   };
   bool update(SolverTasks , updateMode update, bool use_test_packages, 
bool include_source);
-  std::string report() const;
+  std::string report();
 
   const SolverTransactionList () const;
 
-- 
2.15.1

Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Achim Gratz]

Ken Brown writes:
> 1. Uninstall A.
> 2. Don't uninstall B.
>
> On the surface, it would seem that libsolv chose 2 by default, because
> it returned an empty transaction list.  This was reflected in the log
> and was also clear when I selected 'Back'.

I don't think there is a default in this case.  I also see in zypper
that the order of the proposed solutions (there can be way more than two
if the dependencies are more complicated) is not always the same, so
there is no preference implied by the order as well.

> Maybe we have to deal with this situation ourselves.  Whenever a
> problem involves a missing dependency, we could choose as default
> solution the one that installs/keeps the dependent package, as is
> currently done.

That solution unfortunately isn't always the one that causes the least
amount of transactions or even the least amount of breakage.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)

[Ken Brown]

On 12/5/2017 9:32 AM, Jon Turney wrote:
It seems we're missing something to actually apply the default solution, 
so "accept default solutions" makes no changes, at the moment. (looks 
like we have to do this ourselves with solver_take_solution() ?)


I've just looked at this again, and I'm not sure what's happening.

Here's what I tried:  I had two installed packages A and B, where A 
requires B.  I tried to uninstall B and got the expected problem report 
telling me that A requires B.  The solutions presented were


1. Uninstall A.
2. Don't uninstall B.

On the surface, it would seem that libsolv chose 2 by default, because 
it returned an empty transaction list.  This was reflected in the log 
and was also clear when I selected 'Back'.


On the other hand, maybe libsolv's default was to do nothing, and it's 
just a coincidence that this coincided with solution 2.  This could have 
tricked me into thinking that libsolv chose a default solution.


Also, in the dependency problem report, we should identify which of the 
possible solutions is the default one, so it's clearer what "accept 
default solutions" is going to do.


Is there in fact a default solution?  I skimmed through problems.c in 
the libsolv sources, and I didn't see any mention of a default solution.


Maybe we have to deal with this situation ourselves.  Whenever a problem 
involves a missing dependency, we could choose as default solution the 
one that installs/keeps the dependent package, as is currently done.


Ken

Re: Need help with multibyte UTF-8 characters

[cyg Simple]

On 12/13/2017 2:50 AM, Thomas Wolff wrote:
> Hi Brian,
> 
> Am 13.12.2017 um 06:21 schrieb Brian Inglis:
>> On 2017-12-04 18:23, Thomas Taylor wrote:
>>> I want to use multibyte UTF-8 characters in 64-bit Cygwin under
>>> Windows 7.  The
>>> "vim" editor running in mintty displays the two-byte characters
>>> correctly, but
>>> not the three- (and I assume four-) byte characters, which instead
>>> display as
>>> rectangular filled-in blocks.  The "less" program doesn't even
>>> display two-byte
>>> characters correctly, but instead displays them as  to ,
>>> depending on
>>> the character in question, in reverse color in the terminal window. 
>>> The "cat"
>>> program is even worse, replacing every two-byte character with a
>>> character that
>>> looks like three horizontal bars stacked one above the other.  I've
>>> read the
>>> "Internationalization" page in the Cygwin online manual, but am still
>>> baffled.
>>> My LANG environment variable is set to "en_US.UTF-8".  Can anyone help?
>> Your Windows Regional settings and your mintty/Options/Text/Language and
>> Character Set should be set to match.
>> The profile commands below set Cygwin locale to your Windows Regional
>> settings
>> and charset to UTF-8, or Unix locale to your system locale.
>> Otherwise your system or mintty is going to be doing conversions on
>> each character.
> I am not aware that mintty character display and Windows regional
> settings would interfere in any way you indicated.
> Can you elaborate on this please?
> Thomas
> 
>> # Set user-defined locale
>> locale -fU > /dev/null 2>&1 \
>>  && LC_ALL=$(locale -fU) \
>>  || LC_ALL=$(locale |    \
>>  sed
>> '/^LANG=\|^LC_CTYPE=\|^LC_ALL=/{s///;h};$!d;x;s/"//g')
>>

I was having an issue with git changing the locale of the files from
ISO-8859-1 to UTF-8 because of this.  I modified my $HOME/.profile and
changed:

# Set user-defined locale
export LANG=$(locale -uU)

to:

# Set user-defined locale
export LANG=$(locale -u).ISO-8859-1

which sets all of the locale within Cygwin except for LC_ALL.

$ locale
LANG=en_US.ISO-8859-1
LC_CTYPE="en_US.ISO-8859-1"
LC_NUMERIC="en_US.ISO-8859-1"
LC_TIME="en_US.ISO-8859-1"
LC_COLLATE="en_US.ISO-8859-1"
LC_MONETARY="en_US.ISO-8859-1"
LC_MESSAGES="en_US.ISO-8859-1"
LC_ALL=
$

-- 
cyg Simple

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

Re: tensorflow

[Ray Donnelly]

On Dec 13, 2017 2:33 PM, "Eliot Moss"  wrote:

Has anyone successfully built tensorflow under Cygwin?
I ask before putting effort in on building it from source
since there is no pre-built Cygwin package.  I have an
MS Surface Book with an NVidia GEForce series GPU, which
I think should work to provide GPU support for tensorflow
as well.


Building tensorflow is an absolute nightmare. You probably need to first
build Bazel which is Google's own Java-based build system.


Sorry if this is a bit off-topic, but the tensorflow lists
mostly had to do with issue around multiple Cygwins installed
at the same time, etc.

Regards - Eliot Moss

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

tensorflow

[Eliot Moss]

Has anyone successfully built tensorflow under Cygwin?
I ask before putting effort in on building it from source
since there is no pre-built Cygwin package.  I have an
MS Surface Book with an NVidia GEForce series GPU, which
I think should work to provide GPU support for tensorflow
as well.

Sorry if this is a bit off-topic, but the tensorflow lists
mostly had to do with issue around multiple Cygwins installed
at the same time, etc.

Regards - Eliot Moss

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

setup's response to a "corrupt local copy"

[Ken Brown]

This is a followup to the discussion started here:

  https://cygwin.com/ml/cygwin/2017-12/msg00088.html

When setup is preparing to download files and it finds a corrupt copy in 
the local cache, it issues a fatal error message telling the user to 
remove the corrupt file and retry.  Steven said that setup should 
silently delete the corrupt file, while I argued in favor of the current 
behavior, on the grounds that setup shouldn't be deleting user files if 
it doesn't know where they came from.


There is a middle ground: setup could query the user.  Additionally, as 
suggested by cyg Simple, there could be an option that directs setup to 
silently remove corrupt files.


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: setup 2.883 release candidate - please test

[Ken Brown]

On 12/11/2017 1:46 PM, Jon Turney wrote:
>
> A new setup release candidate is available at:
>
>https://cygwin.com/setup/setup-2.883.x86.exe(32 bit version)
>https://cygwin.com/setup/setup-2.883.x86_64.exe (64 bit version)
>
> Please test and report problems to cygwin@cygwin.com. If no
> regressions
> are discovered in the next week or so, it will be promoted to release.
>
> This is not the place for setup feature requests.

This thread has veered off topic.  I'm going to start a new thread to 
discuss the issue that Steven raised.


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