Re: [PATCH] Revert "Don't override a Keep selection"

[Ken Brown]

On 10/17/2017 3:31 PM, Ken Brown wrote:

On 10/17/2017 2:43 PM, Jon Turney wrote:

On 16/10/2017 20:13, Ken Brown wrote:

This reverts (the rest of) commit b43b697.  Part of that commit was
already reverted in commit ff0bb3d.  The rest is not needed either
since we no longer send the upgrade flag to the solver after the user
has made their selections.
---
  libsolv.cc | 14 +++---
  libsolv.h  |  1 -
  package_meta.h |  2 --
  3 files changed, 3 insertions(+), 14 deletions(-)


Hmm... not sure about this.

Say the initial upgrade solution had something like: package A 1.0 -> 
1.1, and A 1.1 has a dependency on package B 2.0, where currently B 
1.0 is installed (so B 1.0 -> 2.0)


If the user then changes B to 'keep' (at 1.0), we should report a 
conflict?


Good point.  I wasn't thinking about dependencies with version relations.


I just tested this scenario, and it turns out that putting a lock on B 
1.0 overrides the dependency of A 1.1 on B 2.0.  There's no problem 
reported.  On the other hand, if there's no lock, then the dependency 
overrides the Keep choice, again with no problem reported.


Back to the drawing board.

Ken

Re: Which is it -pc- or -unknown-

[Yaakov Selkowitz]

On 2017-10-18 18:26, Steven Penny wrote:
> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:
>> For a regex pattern you should include both.
>> I do not bore which one is built and distributed on my packages.
>>
>> E.G. on octave
>>
>> /usr/lib/octave/site/oct/i686-pc-cygwin
>> /usr/lib/octave/site/oct/x86_64-unknown-cygwin
> 
> This is certainly not right. I can understand that we will have some
> discrepancies across packages, but having a different vendor in the same
> package is unacceptable.

According to whom?  'pc' is the default vendor for i*86 for historical
reasons, but 'unknown' is the default for most other architectures.
There really isn't anything unusual here.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: Which is it -pc- or -unknown-

[Steven Penny]

On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote:

For a regex pattern you should include both.
I do not bore which one is built and distributed on my packages.

E.G. on octave

/usr/lib/octave/site/oct/i686-pc-cygwin
/usr/lib/octave/site/oct/x86_64-unknown-cygwin


This is certainly not right. I can understand that we will have some
discrepancies across packages, but having a different vendor in the same package
is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin
differ in more ways that one, which they dont. you let it slide, then people
start asking:

- where is x86_64-pc-cygwin?
- where is i686-unknown-cygwin?

which are both valid questions when a package maintainer does dumb stuff like
this. just realized that for octave package, that is you:

http://cygwin.com/cygwin-pkg-maint

point still stands


--
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: Which is it -pc- or -unknown-

[JonY]

On 10/18/2017 10:41 PM, Yaakov Selkowitz wrote:
> On 2017-10-18 14:10, cyg Simple wrote:
>> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>>> On 2017-10-18 09:05, cyg Simple wrote:
 Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
 filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>>
>>> That would be incorrect.  config.guess is fine as it is.
>>
>> So the corrective action is to distribute GCC and friends as
>> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
> 
> Incorrect.  GCC is also fine as is.
> 

I agree with Yaakov, why does it need to change?



signature.asc
Description: OpenPGP digital signature

Re: Which is it -pc- or -unknown-

[Yaakov Selkowitz]

On 2017-10-18 14:10, cyg Simple wrote:
> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>> On 2017-10-18 09:05, cyg Simple wrote:
>>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>
>> That would be incorrect.  config.guess is fine as it is.
> 
> So the corrective action is to distribute GCC and friends as
> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.

Incorrect.  GCC is also fine as is.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[David Rothenberger]

On 10/18/2017 11:20 AM, Achim Gratz wrote:

subversion-perl: A version control system (perl bindings)


I've uploaded new subversion packages.

--
David Rothenberger    daver...@acm.org

Re: Please update ssh key

[David Rothenberger]

On 10/18/2017 3:01 PM, David Rothenberger wrote:

Name: David Rothenberger
Package: subversion
 BEGIN SSH2 PUBLIC KEY 
ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC8/LZleM+Eev114finffzNL49HcFrvxhqHL8N1YVZ8Drb6VNFHC7HK/kvRqp3jiqeiHY62aytfZZwLEdLgmT5nkEdXRQ0AmrjTjFQHfojQZwWmTJEPJldk1c2vbKHLAxNth256xoR4SJDZuEPOq2+YMpFpJqR/rCbreDgSnQ9SJTjxxmWhDz++Hv90H00dRkgltO3BiQc8ys0BGnboZUFMI/Ajg11M92TnlaFQ0cOwy0nRmIAxMDQPKcsa/U+egZFrgMrLaFOFBIGoto2GRs6U6FtGL7UXg3lSGPlWQS/tWAMOkSy2hsanj0ynVbM/3OJvFpkF8dTCmb344bqaw7Lz
 END SSH2 PUBLIC KEY 



User error. This can be disregarded.

--
David Rothenberger    daver...@acm.org

Small is beautiful.

Please update ssh key

[David Rothenberger]

Name: David Rothenberger
Package: subversion
 BEGIN SSH2 PUBLIC KEY 
ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC8/LZleM+Eev114finffzNL49HcFrvxhqHL8N1YVZ8Drb6VNFHC7HK/kvRqp3jiqeiHY62aytfZZwLEdLgmT5nkEdXRQ0AmrjTjFQHfojQZwWmTJEPJldk1c2vbKHLAxNth256xoR4SJDZuEPOq2+YMpFpJqR/rCbreDgSnQ9SJTjxxmWhDz++Hv90H00dRkgltO3BiQc8ys0BGnboZUFMI/Ajg11M92TnlaFQ0cOwy0nRmIAxMDQPKcsa/U+egZFrgMrLaFOFBIGoto2GRs6U6FtGL7UXg3lSGPlWQS/tWAMOkSy2hsanj0ynVbM/3OJvFpkF8dTCmb344bqaw7Lz
 END SSH2 PUBLIC KEY 

Re: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[Ken Brown]

On 10/18/2017 2:20 PM, Achim Gratz wrote:


I've just uploaded the files for the update of Perl to version 5.26 to
sourceware.  Unfortunatley only a single other package has been staged
there (znc), so we need to wait for the rest of the maintainers to do
their uploads.

Please upload your packages to sourceware _without_ the !ready cookies
(i.e. don't use cygport upload) and instead place !perl cookies.  This
way the staged uploads can all be activated at the same time so that no
inconsistent intermediate state gets published.

Please post a not here on this list as well when your upload is staged.


My files are in place.

Ken

Re: Which is it -pc- or -unknown-

[Brian Inglis]

On 2017-10-18 13:10, cyg Simple wrote:
> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
>> On 2017-10-18 09:05, cyg Simple wrote:
>>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
>>
>> That would be incorrect.  config.guess is fine as it is.
>>
> 
> So the corrective action is to distribute GCC and friends as
> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.
> 
> MAINTAINERS: Please take note for your next releases.

Does this mean 64 bit binutils needs rebuilt with current config.guess to be
found by an updated gcc, or is there a different config option for that triplet?

-- 
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: Which is it -pc- or -unknown-

[cyg Simple]

On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote:
> On 2017-10-18 09:05, cyg Simple wrote:
>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
>> filter to echo ${UNAME_MACHINE}-unknown-cygwin?
> 
> That would be incorrect.  config.guess is fine as it is.
> 

So the corrective action is to distribute GCC and friends as
x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe.

MAINTAINERS: Please take note for your next releases.

-- 
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: [Attn. Maintainers] Perl 5.26.1 (release is imminent)

[Achim Gratz]

I've just uploaded the files for the update of Perl to version 5.26 to
sourceware.  Unfortunatley only a single other package has been staged
there (znc), so we need to wait for the rest of the maintainers to do
their uploads.

Please upload your packages to sourceware _without_ the !ready cookies
(i.e. don't use cygport upload) and instead place !perl cookies.  This
way the staged uploads can all be activated at the same time so that no
inconsistent intermediate state gets published.

Please post a not here on this list as well when your upload is staged.

Again the reminder that the following packages will have to be re-built
since they install perl modules:

biber:   BibTeX replacement for users of BibLaTeX (installed 
binaries and support files)
git-svn: Subversion compatibility support for Git version control 
system
git: Distributed version control system
grepmail:search mailboxes for mail matching an expression 
(installed binaries and support files)
irssi:   Modular text mode IRC client with Perl scripting
nginx-mod_http_perl: Web and mail proxy server (installed binaries and support 
files)
nginx-mod_http_perl: Web and mail proxy server
po4a:Tools for translating various file formats with gettext 
(installed binaries and support files)
pristine-tar:Regenerate pristine tarballs (installed binaries and 
support files)
sendxmpp:Commandline XMPP (jabber) utility (installed binaries and 
support files)
subversion-perl: A version control system (perl bindings)


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Which is it -pc- or -unknown-

[Yaakov Selkowitz]

On 2017-10-18 09:05, cyg Simple wrote:
> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
> filter to echo ${UNAME_MACHINE}-unknown-cygwin?

That would be incorrect.  config.guess is fine as it is.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: [setup topic/libsolv] Packages contained in multiple repositories

[Achim Gratz]

Ken Brown writes:
> In retrospect, I'm not sure this patch is right, but I'm sending it
> anyway for the sake of discussion.  My hesitation comes from the fact
> that libsolv might have a good reason for preferring the one it chose,
> e.g., if we've assigned priorities to the repos.  On the other hand,
> if we've gone to the trouble of assigning priorities, shouldn't
> packagemeta reflect our choice?

Extrapolating from my experience with zypper, libsolv should stick with
the repo the installed package comes from even if some other repo has a
newer version.  The whole purpose of the "dup" command in zypper is to
lift that restriction (compared to the normal "up") and consider the
highest version from any repo as the preferred package (unless more
specific dependencies would yield a lower version or repo priorities
override the default algorithm).

This is often used for example to update just a single application to
something different from the main distribution: chose an extra repo,
install just one of many applications from that repo and then keep
updating the system normally.  The updates will come from your install
repo and just that single application will be updated from the extra
repo instead.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

[PATCH setup] Fix spinning after replace-on-reboot failure or skipped

[Jon Turney]

If:
- extracting a file failed AND --no-replaceonreboot was used
- OR, writing the .new file for replacing on reboot failed
we don't advance to the next file in the archive, so we just sit there,
trying the same operation repeatedly.

Yes, this seems to mean that --no-replaceonreboot never worked usefully.

Also advance to next file in extract_other error case.

See https://cygwin.com/ml/cygwin/2017-10/msg00090.html

Signed-off-by: Jon Turney 
---
 install.cc | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/install.cc b/install.cc
index f8f0b59..a47edcd 100644
--- a/install.cc
+++ b/install.cc
@@ -498,6 +498,8 @@ Installer::installOne (packagemeta , const 
packageversion ,
   archive::extract_results extres;
   while ((extres = archive::extract_file (tarstream, prefixURL, 
prefixPath)) != archive::extract_ok)
 {
+  bool error_in_this_file = false;
+
   switch (extres)
 {
case archive::extract_inuse: // in use
@@ -602,13 +604,13 @@ Installer::installOne (packagemeta , const 
packageversion ,
 if (NoReplaceOnReboot)
   {
 ++errors;
-error_in_this_package = true;
+error_in_this_file = true;
 Log (LOG_PLAIN) << "Not replacing in-use file " << 
prefixURL
 << prefixPath << fn << endLog;
   }
 else
   {
-error_in_this_package = 
extract_replace_on_reboot(tarstream, prefixURL, prefixPath, fn);
+error_in_this_file = extract_replace_on_reboot(tarstream, 
prefixURL, prefixPath, fn);
   }
   }
   break;
@@ -633,8 +635,7 @@ Installer::installOne (packagemeta , const 
packageversion ,
   MB_OK | MB_ICONWARNING | MB_TASKMODAL);
   }
 
-// don't mark this package as successfully installed
-error_in_this_package = true;
+error_in_this_file = true;
   }
   break;
case archive::extract_ok:
@@ -642,6 +643,16 @@ Installer::installOne (packagemeta , const 
packageversion ,
 }
 
   // We're done with this file
+
+  // if an error occured ...
+  if (error_in_this_file)
+{
+  // skip to next file in archive
+  tarstream->skip_file();
+  // don't mark this package as successfully installed
+  error_in_this_package = true;
+}
+
   break;
 }
   progress (pkgfile->tell ());
-- 
2.14.2

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

[Ken Brown]

On 10/18/2017 11:28 AM, Ken Brown wrote:
Similar considerations apply to the other public member functions of 
SolvableVersion.  So my inclination is to go with something like my 
patch...


...with perhaps one tweak.  Maybe we should test 'id' rather than 
'pool', since id being 0 is what's used elsewhere to characterize the 
empty package.  And if id != 0 but pool == 0, there's a bug that we want 
to catch.


Revised patch attached.

Ken

From 948db09180765d89639b63e37a98d3806bf199d5 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Tue, 17 Oct 2017 08:12:48 -0400
Subject: [PATCH] Extend the SolvableVersion member functions to the empty
 package

Currently some of these functions cause crashes when the package is
empty because the libsolv function pool_id2solvable unconditionally
dereferences its first argument ('pool').
---
 libsolv.cc | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libsolv.cc b/libsolv.cc
index 78e73a8..289f19c 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -75,6 +75,8 @@ RelId2Operator(Id id)
 const std::string
 SolvableVersion::Name () const
 {
+  if (!id)
+return "";
   Solvable *solvable = pool_id2solvable(pool, id);
   return std::string(pool_id2str(pool, solvable->name));
 }
@@ -82,6 +84,8 @@ SolvableVersion::Name () const
 const std::string
 SolvableVersion::Canonical_version() const
 {
+  if (!id)
+return "";
   Solvable *solvable = pool_id2solvable(pool, id);
   return std::string(pool_id2str(pool, solvable->evr));
 }
@@ -89,6 +93,8 @@ SolvableVersion::Canonical_version() const
 package_type_t
 SolvableVersion::Type () const
 {
+  if (!id)
+return package_binary;
   Solvable *solvable = pool_id2solvable(pool, id);
   if (solvable->arch == ARCH_SRC)
 return package_source;
@@ -112,6 +118,9 @@ SolvableVersion::obsoletes() const
 const PackageDepends
 SolvableVersion::deplist(Id keyname) const
 {
+  static PackageDepends empty_package;
+  if (!id)
+return empty_package;
   Solvable *solvable = pool_id2solvable(pool, id);
 
   Queue q;
@@ -147,13 +156,14 @@ SolvableVersion::deplist(Id keyname) const
 }
 
   // otherwise, return an empty depends list
-  static PackageDepends empty_package;
   return empty_package;
 }
 
 const std::string
 SolvableVersion::SDesc () const
 {
+  if (!id)
+return "";
   Solvable *solvable = pool_id2solvable(pool, id);
   const char *sdesc = repo_lookup_str(solvable->repo, id, SOLVABLE_SUMMARY);
   return sdesc;
@@ -197,6 +207,8 @@ SolvableVersion::sourcePackage () const
 void
 SolvableVersion::fixup_spkg_id (SolvableVersion spkg_id) const
 {
+  if (!id)
+return;
   Solvable *solvable = pool_id2solvable(pool, id);
   Repodata *data = repo_last_repodata(solvable->repo);
   Id handle = id;
@@ -237,6 +249,8 @@ SolvableVersion::accessible () const
 package_stability_t
 SolvableVersion::Stability () const
 {
+  if (!id)
+return TRUST_UNKNOWN;
   Solvable *solvable = pool_id2solvable(pool, id);
   Id stability_attr = pool_str2id(pool, "solvable:stability", 1);
   return (package_stability_t)repo_lookup_num(solvable->repo, id, 
stability_attr, TRUST_UNKNOWN);
-- 
2.14.2

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

[Ken Brown]

On 10/17/2017 2:46 PM, Jon Turney wrote:

On 17/10/2017 13:44, Ken Brown wrote:

On 10/10/2017 7:18 AM, Ken Brown wrote:

On 9/29/2017 4:33 PM, Ken Brown wrote:

I'll resume my testing after I return.


I've just started testing (based on the current HEAD of 
topic/libsolv), and so far everything looks good.


I came across a situation where a SolvableVersion method was being 
called on a trivial object (with pool and id both 0).  This caused a 
crash when pool_id2solvable(pool, id) was called and pool was 
dereferenced.  There's probably a bug that led to this situation.  [It 
involved a local install in which a package was listed in two 
different setup.ini files, but the tarballs existed only in one.]  I 
plan to investigate this further.  But in any case, we shouldn't 
crash.  Patch attached.


I thought about putting this in, but decided against it as it would 
probably catch some mistakes I had made...


But yeah, for production use, I think not crashing is probably a good 
idea :).  Although I guess we might want asserts or something, if we 
think these cases shouldn't be happening.


Here's the situation where I got the crash: Package A is installed and 
requires B.  setup tries to install B, but the install fails for some 
reason.  During the postinstall phase, we're scanning the dependencies 
of A and we call checkForInstalled to see if B is installed.  This ends 
up calling PackageSpecification::satisfies(aPackage), with aPackage 
being the empty package (pool == NULL, id == 0) because B is not 
installed.  A call to aPackage.Name() then causes the crash.


I think this sequence of calls is reasonable.  Name() is part of the 
public interface to SolvableVersion, so we should be able to call Name() 
on any package without a crash or assertion violation.  In the case of 
the empty package, the empty string is a reasonable return value.


Similar considerations apply to the other public member functions of 
SolvableVersion.  So my inclination is to go with something like my 
patch rather than changing all callers.


Ken

Re: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Yaakov Selkowitz]

On 2017-10-18 09:11, Corinna Vinschen wrote:
> On Oct 18 07:52, Ken Brown wrote:
>> On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
>>> On Oct 17 18:36, Jeffrey Walton wrote:
 On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:
> Hi Everyone,
>
> I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> because of Newlib. Emacs is failing with:

 Forgive my ignorance... Should this question go to the Newlib folks?
>>>
>>> Good thinking, but in this case, no.  The problem (*iff* there is any)
>>> and the potential fix would only affect Cygwin headers.
>>
>> As I said in https://cygwin.com/ml/cygwin/2017-10/msg00144.html, this is
>> almost certainly the same gnulib issue that has already been fixed
>> (http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html). The OP
>> is probably building old emacs sources that hadn't incorporated the fix.
> 
> Yeah, I saw that, Ken, but thanks for pointing it out.  I was
> talking about this more in a theoretical way :)

I don't think there is anything more to do on our end wrt this gnulib issue.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



signature.asc
Description: OpenPGP digital signature

[newlib-cygwin] cygwin: belatedly bump DLL minor version

[Corinna Vinschen]

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

commit 3bdd4841034bb1264135e8bd94fc01f76ded39bb
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:40:56 2017 +0200

cygwin: belatedly bump DLL minor version

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/cygwin/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index e5c9e7f..7b95de3 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -11,7 +11,7 @@ details. */
changes to the DLL and is mainly informative in nature. */
 
 #define CYGWIN_VERSION_DLL_MAJOR 2009
-#define CYGWIN_VERSION_DLL_MINOR 0
+#define CYGWIN_VERSION_DLL_MINOR 1
 
 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are incompatible. */

[newlib-cygwin] cygwin: unlink: drop redundant check for netapp FS

[Corinna Vinschen]

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

commit 5224eb7517498318595fd7f9a67d9a1b50b66d25
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:13:48 2017 +0200

cygwin: unlink: drop redundant check for netapp FS

The try_to_bin function isn't called for netapp FSes anyway, so testing
for this FS type in the function is moot.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 63563ea..8ff50c8 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -374,7 +374,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
  names. */
   RtlAppendUnicodeToString (,
(pc.fs_flags () & FILE_UNICODE_ON_DISK
-&& !pc.fs_is_samba () && !pc.fs_is_netapp ())
+&& !pc.fs_is_samba ())
? L".\xdc63\xdc79\xdc67" : L".cyg");
   pfii = (PFILE_INTERNAL_INFORMATION) infobuf;
   /* Note: Modern Samba versions apparently don't like buffer sizes of more

[newlib-cygwin] cygwin: unlink: workaround NFS non-ability to move file in certain cases

[Corinna Vinschen]

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

commit 88cfcda06b1017b7a05cf7c6f7ebafba9fe6f9fa
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:27:17 2017 +0200

cygwin: unlink: workaround NFS non-ability to move file in certain cases

Under some not quite clear conditions, NFS fails to use its
unlink workaround to rename a file to ".nfsXYZ".  The problem has been
reproduced with the GAWK testext.awk testcase.  To workaround this in
Cygwin, we now call try_to_bin on NFS, too.  For some reason NFS doesn't
fail to rename the .cygXYZ file to .nfsXYZ after this Cygwin rename.
Fix comment in unlink_nt accordingly.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 51 +++
 1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 8124df9..caa3a77 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -501,8 +501,11 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
  Otherwise the below code closes the handle to allow replacing the file. */
   status = NtSetInformationFile (fh, , , sizeof disp,
 FileDispositionInformation);
-  if (status == STATUS_DIRECTORY_NOT_EMPTY)
+  switch (status)
 {
+case STATUS_SUCCESS:
+  break;
+case STATUS_DIRECTORY_NOT_EMPTY:
   /* Uh oh!  This was supposed to be avoided by the check_dir_not_empty
 test in unlink_nt, but given that the test isn't atomic, this *can*
 happen.  Try to move the dir back ASAP. */
@@ -522,6 +525,34 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
}
   debug_printf ("Renaming dir %S back to %S failed, status = %y",
, pc.get_nt_native_path (), status);
+  break;
+case STATUS_FILE_RENAMED:
+  /* On NFS, the subsequent request to set the delete disposition fails
+with STATUS_FILE_RENAMED.  We have to reopen the file, close the
+original handle, and set the delete disposition on the reopened
+handle to make sure setting delete disposition works. */
+  InitializeObjectAttributes (, _u_empty, 0, fh, NULL);
+  status = NtOpenFile (_fh, access, , ,
+  FILE_SHARE_VALID_FLAGS, flags);
+  if (!NT_SUCCESS (status))
+   debug_printf ("NtOpenFile (%S) for reopening in renamed case failed, "
+ "status = %y", pc.get_nt_native_path (), status);
+  else
+   {
+ NtClose (fh);
+ fh = tmp_fh;
+ status = NtSetInformationFile (fh, , , sizeof disp,
+FileDispositionInformation);
+ if (!NT_SUCCESS (status))
+   debug_printf ("Setting delete disposition %S (%S) in renamed "
+ "case failed, status = %y",
+ , pc.get_nt_native_path (), status);
+   }
+  break;
+default:
+  debug_printf ("Setting delete disposition on %S (%S) failed, status = 
%y",
+   , pc.get_nt_native_path (), status);
+  break;
 }
   /* In case of success, restore R/O attribute to accommodate hardlinks.
  That leaves potentially hardlinks around with the R/O bit suddenly
@@ -759,15 +790,19 @@ retry_open:
 {
   debug_printf ("Sharing violation when opening %S",
pc.get_nt_native_path ());
-  /* We never call try_to_bin on NFS and NetApp for the follwing reasons:
+  /* We never call try_to_bin on NetApp.  Netapp filesystems don't
+understand the "move and delete" method at all and have all kinds
+of weird effects.  Just setting the delete dispositon usually
+works fine, though.
 
 NFS implements its own mechanism to remove in-use files, which looks
-quite similar to what we do in try_to_bin for remote files.
-
-Netapp filesystems don't understand the "move and delete" method
-at all and have all kinds of weird effects.  Just setting the delete
-dispositon usually works fine, though. */
-  if (!pc.fs_is_nfs () && !pc.fs_is_netapp ())
+quite similar to what we do in try_to_bin for remote files.  However,
+apparently it doesn't work as desired in all cases.  This has been
+observed when running the gawk 4.1.62++ testcase "testext.awk" under
+Windows 10.  So for NFS we still call try_to_bin to rename the file,
+at least to make room for subsequent creation of a file with the
+same filename. */
+  if (!pc.fs_is_netapp ())
bin_stat = move_to_bin;
   /* If the file is not a directory, of if we didn't set the move_to_bin
 flag, just proceed with the FILE_SHARE_VALID_FLAGS set. */

[newlib-cygwin] cygwin: unlink: don't try "final trick" in try_to_bin on NFS

[Corinna Vinschen]

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

commit 5b7921523da00d81aaa0af829fbd8c5fe36e1e56
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:22:14 2017 +0200

cygwin: unlink: don't try "final trick" in try_to_bin on NFS

Doesn't work.  Just another STATUS_SHARING_VIOLATION.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 8ccc768..8124df9 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -532,8 +532,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   NtClose (fh);
   fh = NULL; /* So unlink_nt doesn't close the handle twice. */
   /* On success or when trying to unlink a directory we just return here.
- The below code only works for files. */
-  if (NT_SUCCESS (status) || pc.isdir ())
+ The below code only works for files.  It also fails on NFS. */
+  if (NT_SUCCESS (status) || pc.isdir () || pc.fs_is_nfs ())
 goto out;
   /* The final trick.  We create a temporary file with delete-on-close
  semantic and rename that file to the file just moved to the bin.

[newlib-cygwin] cygwin: unlink: fix "final trick" overwrite method on remote drives

[Corinna Vinschen]

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

commit e6c79e7a2ab7fe9e1d45c25526841e035ee67407
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:21:12 2017 +0200

cygwin: unlink: fix "final trick" overwrite method on remote drives

The "final trick" code in try_to_bin accidentally never worked on
remote drives because it relies on rootdir.  Which isn't set for
remote unlinks.  The code now creates a full path for remote files.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index e64b017..8ccc768 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -542,8 +542,22 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
  delete-on-close on the original file succeeds.  There are still
  cases in which this fails, for instance, when trying to delete a
  hardlink to a DLL used by the unlinking application itself. */
-  RtlAppendUnicodeToString (, L"X");
-  InitializeObjectAttributes (, , 0, rootdir, NULL);
+  if (pc.isremote ())
+{
+  /* In the remote case we need the full path, but recycler is only
+a relative path.  Convert to absolute path. */
+  RtlInitEmptyUnicodeString (, (PCWSTR) tp.w_get (),
+(NT_MAX_PATH - 1) * sizeof (WCHAR));
+  RtlCopyUnicodeString (, pc.get_nt_native_path ());
+  RtlSplitUnicodePath (, , NULL);
+  /* Reset max length, overwritten by RtlSplitUnicodePath. */
+  fname.MaximumLength = (NT_MAX_PATH - 1) * sizeof (WCHAR); /* reset */
+  RtlAppendUnicodeStringToString (, );
+}
+  else
+fname = recycler;
+  RtlAppendUnicodeToString (, L"X");
+  InitializeObjectAttributes (, , 0, rootdir, NULL);
   status = NtCreateFile (_fh, DELETE, , , NULL,
 FILE_ATTRIBUTE_NORMAL, 0, FILE_SUPERSEDE,
 FILE_NON_DIRECTORY_FILE | FILE_DELETE_ON_CLOSE,

[newlib-cygwin] cygwin: unlink: improve debug messages in try_to_bin

[Corinna Vinschen]

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

commit 3dda58f1573a7e216f4656a3248252aea4f30593
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:18:12 2017 +0200

cygwin: unlink: improve debug messages in try_to_bin

Signed-off-by: Corinna Vinschen 

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

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 96fb6f3..e64b017 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -520,6 +520,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
  bin_stat = dir_not_empty;
  goto out;
}
+  debug_printf ("Renaming dir %S back to %S failed, status = %y",
+   , pc.get_nt_native_path (), status);
 }
   /* In case of success, restore R/O attribute to accommodate hardlinks.
  That leaves potentially hardlinks around with the R/O bit suddenly
@@ -548,7 +550,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
 NULL, 0);
   if (!NT_SUCCESS (status))
 {
-  debug_printf ("Creating file for overwriting failed, status = %y",
+  debug_printf ("Creating file %S for overwriting %S (%S) failed, "
+   "status = %y", , , pc.get_nt_native_path (),
status);
   goto out;
 }
@@ -556,7 +559,8 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
 FileRenameInformation);
   NtClose (tmp_fh);
   if (!NT_SUCCESS (status))
-debug_printf ("Overwriting with another file failed, status = %y", status);
+debug_printf ("Overwriting %S (%S) with %S failed, status = %y",
+ , pc.get_nt_native_path (), , status);
 
 out:
   if (rootdir)

[newlib-cygwin] cygwin: unlink: Fix typos in comments

[Corinna Vinschen]

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

commit 7127e8ef3b6f9d76f57515ad4297709738d05a6b
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:12:42 2017 +0200

cygwin: unlink: Fix typos in comments

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 61872fe..63563ea 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -273,7 +273,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
  mixed case or in all upper case.  That's a problem when using
  casesensitivity.  If the file handle given to FileRenameInformation
  has been opened casesensitive, the call also handles the path to the
- target dir casesensitive.  Rather then trying to find the right name
+ target dir casesensitive.  Rather than trying to find the right name
  of the recycler, we just reopen the file to move with 
OBJ_CASE_INSENSITIVE,
  so the subsequent FileRenameInformation works caseinsensitive in terms of
  the recycler directory name, too. */
@@ -308,7 +308,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   /* Is fname really a subcomponent of the full path?  If not, there's
 a high probability we're acessing the file via a virtual drive
 created with "subst".  Check and accommodate it.  Note that we
-ony get here if the virtual drive is really pointing to a local
+only get here if the virtual drive is really pointing to a local
 drive.  Otherwise pc.isremote () returns "true". */
   if (!RtlEqualUnicodePathSuffix (pc.get_nt_native_path (), , TRUE))
{

[newlib-cygwin] cygwin: unlink: simplify rootdir handling

[Corinna Vinschen]

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

commit 9ac4c0325fba621cdb5bf503b2521b4edd35086f
Author: Corinna Vinschen 
Date:   Wed Oct 18 16:15:08 2017 +0200

cygwin: unlink: simplify rootdir handling

In try_to_bin, rootdir is NULL for remote drives anyway.  No extra
check required.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/syscalls.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 8ff50c8..96fb6f3 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -394,7 +394,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   /* Shoot. */
   pfri = (PFILE_RENAME_INFORMATION) infobuf;
   pfri->ReplaceIfExists = TRUE;
-  pfri->RootDirectory = pc.isremote () ? NULL : rootdir;
+  pfri->RootDirectory = rootdir;
   pfri->FileNameLength = recycler.Length;
   memcpy (pfri->FileName, recycler.Buffer, recycler.Length);
   frisiz = sizeof *pfri + pfri->FileNameLength - sizeof (WCHAR);

Re: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Ken Brown]

On 10/18/2017 10:11 AM, Corinna Vinschen wrote:

On Oct 18 07:52, Ken Brown wrote:

[CC-ing the OP in case he is not subscribed to the list.]

On 10/18/2017 6:13 AM, Corinna Vinschen wrote:

On Oct 17 18:36, Jeffrey Walton wrote:

On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:

Hi Everyone,

I'm trying to build Emacs on Cygwin. I use the platform as a test bed
because of Newlib. Emacs is failing with:


Forgive my ignorance... Should this question go to the Newlib folks?


Good thinking, but in this case, no.  The problem (*iff* there is any)
and the potential fix would only affect Cygwin headers.


As I said in https://cygwin.com/ml/cygwin/2017-10/msg00144.html, this is
almost certainly the same gnulib issue that has already been fixed
(http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html). The OP
is probably building old emacs sources that hadn't incorporated the fix.


Yeah, I saw that, Ken, but thanks for pointing it out.  I was
talking about this more in a theoretical way :)


Ah, OK.  My main reason for writing was to CC the OP, since his latest 
email suggested that he hadn't seen any of the replies.


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

[setup topic/libsolv] Packages contained in multiple repositories

[Ken Brown]

When a package (with specified version) is contained in multiple 
repositories, we register in packagemeta the last one we see.  But if 
libsolv decides that the package needs to be installed, its solution may 
arbitrarily specify one from a different repo.  This caused me some 
confusion when debugging an unrelated issue, and I created the attached 
patch to "fix" it.


In retrospect, I'm not sure this patch is right, but I'm sending it 
anyway for the sake of discussion.  My hesitation comes from the fact 
that libsolv might have a good reason for preferring the one it chose, 
e.g., if we've assigned priorities to the repos.  On the other hand, if 
we've gone to the trouble of assigning priorities, shouldn't packagemeta 
reflect our choice?


I'm of two minds here.

Ken
From 2c0c1edbecad7cdce69a02cef0506b93fe5d7981 Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Wed, 18 Oct 2017 09:24:48 -0400
Subject: [PATCH] Prefer the packageversion registered in packagemeta

When a packageversion that is contained in multiple repositories is
being installed, the solver has no way to know which one we prefer.
Change the solution, if necessary, to use the one we registered in
packagemeta when we parsed the setup.ini files.
---
 libsolv.cc | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/libsolv.cc b/libsolv.cc
index 3a244d4..3750867 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -21,6 +21,8 @@
 
 #include "LogSingleton.h"
 #include  
+#include 
+#include 
 
 // ---
 // Utility functions for mapping between Operators and Relation Ids
@@ -762,10 +764,21 @@ SolverSolution::update(SolverTasks , updateMode 
update, bool use_test_pack
 
   for (int i = 0; i < t->steps.count; i++)
 {
-  Id id = t->steps.elements[i];
   SolverTransaction::transType tt = type(t, i);
+  SolvableVersion sv = SolvableVersion(t->steps.elements[i], pool.pool);
+  // If we are installing a package that is contained in multiple
+  // repositories, we want to use the one registered in
+  // packagemeta.
+  if (tt == SolverTransaction::transInstall)
+   {
+ packagedb db;
+ packagemeta *pkg = db.findBinary(PackageSpecification(sv.Name()));
+ std::set ::iterator j = pkg->versions.find(sv);
+ assert (j != pkg->versions.end());
+ sv = *j;
+   }
   if (tt != SolverTransaction::transIgnore)
-trans.push_back(SolverTransaction(SolvableVersion(id, pool.pool), tt));
+trans.push_back(SolverTransaction(sv, tt));
 }
 
   // add install and remove tasks for anything marked as reinstall
-- 
2.14.2

Re: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Corinna Vinschen]

On Oct 18 07:52, Ken Brown wrote:
> [CC-ing the OP in case he is not subscribed to the list.]
> 
> On 10/18/2017 6:13 AM, Corinna Vinschen wrote:
> > On Oct 17 18:36, Jeffrey Walton wrote:
> > > On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  
> > > wrote:
> > > > Hi Everyone,
> > > > 
> > > > I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> > > > because of Newlib. Emacs is failing with:
> > > 
> > > Forgive my ignorance... Should this question go to the Newlib folks?
> > 
> > Good thinking, but in this case, no.  The problem (*iff* there is any)
> > and the potential fix would only affect Cygwin headers.
> 
> As I said in https://cygwin.com/ml/cygwin/2017-10/msg00144.html, this is
> almost certainly the same gnulib issue that has already been fixed
> (http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html). The OP
> is probably building old emacs sources that hadn't incorporated the fix.

Yeah, I saw that, Ken, but thanks for pointing it out.  I was
talking about this more in a theoretical way :)


Corinna

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


signature.asc
Description: PGP signature

Re: Which is it -pc- or -unknown-

[cyg Simple]

On 10/17/2017 3:16 PM, cyg Simple wrote:
> The config.guess file[1] is confused.
> 
> 840i*:CYGWIN*:*)
> 841   echo ${UNAME_MACHINE}-pc-cygwin
> 842   exit ;;
> -
> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
> 871   echo x86_64-unknown-cygwin
> 872   exit ;;
> 
> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my
> system gives x86_64-unknown-cygwin so specifying a fully qualified host
> doesn't find the executable file.  So which should it be?
> 
> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28
> 

Does anyone care if a patch to config.guess changes the i*:CYGWIN*:*
filter to echo ${UNAME_MACHINE}-unknown-cygwin?

-- 
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: Which is it -pc- or -unknown-

[Brian Inglis]

On 2017-10-18 00:45, Marco Atzeri wrote:
> On 18/10/2017 05:29, cyg Simple wrote:
>> On 10/17/2017 7:49 PM, Brian Inglis wrote:
>>> On 2017-10-17 13:16, cyg Simple wrote:
>> I'm only concerned with Cygwin at the moment.  As I understand it the we
>> should distribute x86[_64]-unknown-cygwin-*.exe and not as
>> x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
>> i*:CYGWIN*:* match.
> it is irrelevant as x86[_64]-unknown-cygwin-*.exe and
> x86[_64]-pc-cygwin-*.exe are equivalent.
> And usually it is not x86 but i686
>  $ arch
> i686
> For a regex pattern you should include both.
> I do not care which one is built and distributed on my packages.
> E.G. on octave
> /usr/lib/octave/site/oct/i686-pc-cygwin
> /usr/lib/octave/site/oct/x86_64-unknown-cygwin

Do gcc... and binutils have to match so the front end can find the build tools
or are there config options for binutils triplet or vendor?

-- 
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: ERROR: A specified logon session does not exist. It may already have been terminated

[Fournier, Danny G]

I did not add the password to the registry (not knowingly in any case). When we 
initially setup, we logged in by providing the password and used ssh-copy-id to 
setup the key.

-Original Message-
From: Gluszczak, Glenn [mailto:glenn.gluszc...@dell.com] 
Sent: October-17-17 5:11 PM
To: Fournier, Danny G
Subject: RE: ERROR: A specified logon session does not exist. It may already 
have been terminated

Good detective work.   I need to think about why key only authentication would 
cause an impact.

Did you add the password to the registry?
(Log in as the user and the run "passwd -R").

To get proper identity from a filesystem basis, a process still needs to log in.
SSH uses a behind the scene login if it finds the password.  If you log in 
directly, it doesn't need to access the registry one.

Glenn

-Original Message-
From: Fournier, Danny G [mailto:danny.fourn...@dfo-mpo.gc.ca]
Sent: Tuesday, October 17, 2017 3:32 PM
To: Gluszczak, Glenn; cygwin@cygwin.com
Subject: RE: ERROR: A specified logon session does not exist. It may already 
have been terminated

Here's what I just did:

1. created new local administrator account 2. ran mkpasswd -l > /etc/passwd 3. 
removed all instances of server name in /etc/passwd (ie. MYSERVERNAME+) 4. 
remotely connected successfully 5. successfully ran schtasks, it listed all 
jobs configured 

I just retried with the other user, where I connect specifying a shared key and 
got the error message.

For good measure, I changed the password on the problematic user, connected 
directly without the key and provided the password. I then ran schtasks and it 
ran fine. It listed all the jobs configured.

It would seem that our issue is related to connecting over SSH using a shared 
key.

-Original Message-
From: Gluszczak, Glenn [mailto:glenn.gluszc...@dell.com]
Sent: October-17-17 11:08 AM
To: Fournier, Danny G
Subject: RE: ERROR: A specified logon session does not exist. It may already 
have been terminated


Does ssh with Administrator and running schtasks fail as well?

--
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: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Ken Brown]

[CC-ing the OP in case he is not subscribed to the list.]

On 10/18/2017 6:13 AM, Corinna Vinschen wrote:

On Oct 17 18:36, Jeffrey Walton wrote:

On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:

Hi Everyone,

I'm trying to build Emacs on Cygwin. I use the platform as a test bed
because of Newlib. Emacs is failing with:


Forgive my ignorance... Should this question go to the Newlib folks?


Good thinking, but in this case, no.  The problem (*iff* there is any)
and the potential fix would only affect Cygwin headers.


As I said in https://cygwin.com/ml/cygwin/2017-10/msg00144.html, this is 
almost certainly the same gnulib issue that has already been fixed 
(http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html). 
The OP is probably building old emacs sources that hadn't incorporated 
the fix.


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: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Corinna Vinschen]

On Oct 17 18:36, Jeffrey Walton wrote:
> On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton  wrote:
> > Hi Everyone,
> >
> > I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> > because of Newlib. Emacs is failing with:
> 
> Forgive my ignorance... Should this question go to the Newlib folks?

Good thinking, but in this case, no.  The problem (*iff* there is any)
and the potential fix would only affect Cygwin headers.


Corinna

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


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

[JonY]

On 10/17/2017 11:47 AM, Steven Penny wrote:
> On Sun, 20 Aug 2017 14:16:07, JonY wrote:
>> The mingw-w64 cross compilers have been updated:
>>
>> * mingw64-i686-binutils-2.28.1.12c1f20d
>> * mingw64-i686-gcc-6.3.0-1
>> * mingw64-x86_64-binutils-2.28.1.12c1f20d
>> * mingw64-x86_64-gcc-6.3.0-1
> 
> http://cygwin.com/ml/cygwin/2017-08/msg00182.html
> 
> Can mingw64-{x86_64,i686}-gcc move to Current? These were released about 2
> months ago, and it seems the only issue was with binutils, which has
> already
> been fixed and moved to current. Please and thank you.
> 

Sure, I'll bump it soon, thanks for testing.




signature.asc
Description: OpenPGP digital signature

Re: Which is it -pc- or -unknown-

[Marco Atzeri]

On 18/10/2017 05:29, cyg Simple wrote:

On 10/17/2017 7:49 PM, Brian Inglis wrote:

On 2017-10-17 13:16, cyg Simple wrote:




I'm only concerned with Cygwin at the moment.  As I understand it the we
should distribute x86[_64]-unknown-cygwin-*.exe and not as
x86[_64]-pc-cygwin-*.exe  We also need to correct config.guess for the
i*:CYGWIN*:* match.



it is irrelevant as x86[_64]-unknown-cygwin-*.exe and
x86[_64]-pc-cygwin-*.exe are equivalent.

And usually it is not x86 but i686

 $ arch
i686

For a regex pattern you should include both.
I do not bore which one is built and distributed on my packages.

E.G. on octave

/usr/lib/octave/site/oct/i686-pc-cygwin
/usr/lib/octave/site/oct/x86_64-unknown-cygwin


Regards
Marco

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