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

[Brian Inglis]

On 2017-10-17 21:29, cyg Simple wrote:
> On 10/17/2017 7:49 PM, Brian Inglis wrote:
>> On 2017-10-17 13:16, 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
>>
>> There are also similar confusions and differences between projects and 
>> distros
>> about use of x86_64 (or x86-64) and amd64. You may have come across others.
>>
> 
> 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 seems that i686-pc-... on lines 840... is common, probably for historical
reasons, and that may be okay for 32 bit builds but I don't know the Cygwin
history here, and x86_64-unknown-... should be selected for 64 bit builds in
lines 870...
Packages for current 32 and 64 bit binutils, cygwin32-..., and gcc... are
prefixed with or found under {i686,x86_64}-pc-cygwin, so you might have to
change the vendor field in config.guess, if you want to stay consistent.
Packages emacs, octave, and pkg-config are the only ones I can find using
x86_64-unknown-cygwin prefix on 64 bit, none with i686-unknown-cygwin on 32 bit.

-- 
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/17/2017 7:49 PM, Brian Inglis wrote:
> On 2017-10-17 13:16, 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
> 
> There are also similar confusions and differences between projects and distros
> about use of x86_64 (or x86-64) and amd64. You may have come across others.
> 

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.

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

[cyg Simple]

On 10/17/2017 7:39 PM, Brian Inglis wrote:
> On 2017-10-17 15:31, cyg Simple wrote:
>> On 10/17/2017 3:45 PM, Brian Inglis wrote:
>>> On 2017-10-17 13:16, cyg Simple wrote:
 The config.guess file[1] is confused.
 840i*:CYGWIN*:*)
 841echo ${UNAME_MACHINE}-pc-cygwin
 842exit ;;
 -
 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
 871echo x86_64-unknown-cygwin
 872exit ;;
 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
>>> That part of the triplet is defined as vendor, so it was probably initially
>>> Intel, then compatibles came out and that was genericized to PC, then 
>>> someone
>>> objected and discussed and came up with Unknown, rather than say Any or 
>>> None.
>>> It may reflect development ages of projects, autotools, defaults on 
>>> projects, or
>>> project politics.
>>> Some projects still use PC, which may be a project override, others use 
>>> Unknown,
>>> which should be the default in current releases of autotools.
>> So config.guess needs to change, correct?  I thought the I had
>> remembered the discussion that it should be -unknown- for Cygwin.  But
>> the GCC distribution is giving us -pc- instead which means the
>> maintainer specified the target as such.  That needs to change as well.
>> I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
>> it's coded.  Confusing!
> 
> You might want to diff the upstream config.{guess,sub} with those from
> /usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to
> see if they are just old, in case there are project customizations.
> You can then decide whether you want to look further at how much of the 
> project
> automake infrastructure you want to upgrade, or check if the project has 
> looked
> at, or is working on, doing that.
> If you do so, you could look at offering that back upstream.
> 

Brian, I quoted the git master of config.guess in my original mail.

My concern is that on my 64bit Cygwin version config.guess guesses the
build as x86_64-unknown-cygwin but x86_64-pc-cygwin-gcc.exe is
distributed.  Therefore there is a mismatch between what the maintainer
gives us from the GCC distribution and what the upstream config.guess
gives us.  This leads to not being able to find
x86_64-unknown-cygwin-gcc.exe.

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

tar checkpoint-action screen width padding

[Steven Penny]

You can run a command like this via mintty:

   $ tar -x -f php-7.1.10.tar.xz --checkpoint-action ttyout=%c
   2017-10-17 20:28:01: 0s, read: 81920 (80KiB, 5.1MiB/s)

and it updates the status on the same line. However if you run via Cygwin.bat,
it prints on multiple lines. If you break down "%c" via this page:

http://gnu.org/software/tar/manual/html_section/tar_26

You get this:

   %{%Y-%m-%d %H:%M:%S}t: %ds, %{read,wrote}T%*\r

after some troubleshooting this is the problem:

   %*

here is what that does:

   %{n}*
   Pad output with spaces to the nth column. If the {n} part is omitted, the
   current screen width is assumed.

So the issue is either that "%*" is printing 1 too many spaces, or that "\r" is
taking up a character when it should not be.


--
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-17 13:16, 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

There are also similar confusions and differences between projects and distros
about use of x86_64 (or x86-64) and amd64. You may have come across others.

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

[Brian Inglis]

On 2017-10-17 15:31, cyg Simple wrote:
> On 10/17/2017 3:45 PM, Brian Inglis wrote:
>> On 2017-10-17 13:16, 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
>> That part of the triplet is defined as vendor, so it was probably initially
>> Intel, then compatibles came out and that was genericized to PC, then someone
>> objected and discussed and came up with Unknown, rather than say Any or None.
>> It may reflect development ages of projects, autotools, defaults on 
>> projects, or
>> project politics.
>> Some projects still use PC, which may be a project override, others use 
>> Unknown,
>> which should be the default in current releases of autotools.
> So config.guess needs to change, correct?  I thought the I had
> remembered the discussion that it should be -unknown- for Cygwin.  But
> the GCC distribution is giving us -pc- instead which means the
> maintainer specified the target as such.  That needs to change as well.
> I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
> it's coded.  Confusing!

You might want to diff the upstream config.{guess,sub} with those from
/usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to
see if they are just old, in case there are project customizations.
You can then decide whether you want to look further at how much of the project
automake infrastructure you want to upgrade, or check if the project has looked
at, or is working on, doing that.
If you do so, you could look at offering that back upstream.

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

[Jeffrey Walton]

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?

Jeff

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

Re: No error messages printed out within Windows Command Prompt when shared libraries are not found

[Steven Penny]

On Tue, 17 Oct 2017 21:41:05, Luca wrote:

If I run the program within the Windows Command Prompt, I do not get any er=
ror messages (the program simply does not do anything).


Yeah, you do:

---
foo.exe - System Error
---
The program can't start because libfoo.dll is missing from your computer. Try
reinstalling the program to fix this problem.
---
OK
---

http://lut.im/qFIrHFkG6Y/LjKasGBjWeIeqOgY.png


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

No error messages printed out within Windows Command Prompt when shared libraries are not found

[Luca]

On Linux, if I run a program compiled with 'gcc' without the proper shared 
libraries in path I get the following error message:

> error while loading shared libraries: libxxx.so: cannot open shared object 
> file: No such file or directory

This is expected.

The same happens when running a program compiled with Cygwin on Windows, either 
using 'gcc' or 'x86_64-w64-mingw32-gcc', but only if I run the program within 
the Cygwin Terminal.

If I run the program within the Windows Command Prompt, I do not get any error 
messages (the program simply does not do anything).

Below are the instructions to reproduce the issue.


File 'foo.h':

#ifndef foo_h__
#define foo_h__
extern void foo(void);
#endif  // foo_h__


File 'foo.c':

#include 
void foo(void)
{
puts("Hello, I'm a shared library");
}


File 'main.c':

#include 
#include "foo.h"
int main(void)
{
puts("This is a shared library test...");
foo();
return 0;
}


Build object file 'foo.o':
x86_64-w64-mingw32-gcc -c foo.c

Build shared library 'libfoo.dll':
x86_64-w64-mingw32-gcc -shared -o libfoo.dll foo.o

Build executable 'foo.exe':
x86_64-w64-mingw32-gcc -o foo.exe main.c libfoo.dll

Rename shared library 'libfoo.dll':
mv libfoo.dll liberror.dll

If you run 'foo.exe' within the Cygwin Terminal you get the error message, if 
you run it within the Windows Command Prompt you do not get any messages 
printed out.
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Dear Applicant

[Mr , Paul Steward]

Dear Applicant,

We wish to inform you that your resume has been reviewed by the appropriate 
department throughly and you have been shortlisted for the position of an 
Administrative Assistant. You have been selected for an interview with us

You are to create or use an existing gmail account (hangout) to proceed with 
the job and to know more about the company, locations, positions, pay scale and 
duties.

You are to set up a screen name with Google Hangout messenger and add up the 
company's head of operation ID to your contact list, ID Google Hang Out ID ( 
paulsteward...@gmail.com ) and instant message him for an online 
interview/briefing exercise. You are to be available on Google Hangout for the 
interview (ASAP), Your swift and timely response matters to this position as 
well as the job interview. I wish you all the very best of luck in the 
interview. Please feel free to email Paul Steward for more details.


Time: Asap
Pay: $30 - $35 hourly
Position: Administrative Assistant
Venue: Google HangOut (Gmail IM)
Best regard,
Human Resources Department.

--
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/17/2017 3:45 PM, Brian Inglis wrote:
> On 2017-10-17 13:16, 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
> 
> That part of the triplet is defined as vendor, so it was probably initially
> Intel, then compatibles came out and that was genericized to PC, then someone
> objected and discussed and came up with Unknown, rather than say Any or None.
> It may reflect development ages of projects, autotools, defaults on projects, 
> or
> project politics.
> Some projects still use PC, which may be a project override, others use 
> Unknown,
> which should be the default in current releases of autotools.
> 

So config.guess needs to change, correct?  I thought the I had
remembered the discussion that it should be -unknown- for Cygwin.  But
the GCC distribution is giving us -pc- instead which means the
maintainer specified the target as such.  That needs to change as well.

I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way
it's coded.  Confusing!

-- 
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-17 13:16, 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

That part of the triplet is defined as vendor, so it was probably initially
Intel, then compatibles came out and that was genericized to PC, then someone
objected and discussed and came up with Unknown, rather than say Any or None.
It may reflect development ages of projects, autotools, defaults on projects, or
project politics.
Some projects still use PC, which may be a project override, others use Unknown,
which should be the default in current releases of autotools.

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

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: [PATCH] Revert "Don't override a Keep selection"

[Ken Brown]

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.


Does keeping this cause a problem?


No, but it's not actually effective at the moment, because after commit 
ff0bb3d, package_meta::default_version isn't being set.  Maybe it should 
be set to reflect the initial upgrade solution.  I'll play with this 
some more.


I guess we are generating a huge number of these tasks into the solver 
because "Keep" is kind of overloaded between "Don't care (but it just 
happens that I know that there's nothing to do)" and "Lock"?


Yeah, this needs further thought.

Ken

Which is it -pc- or -unknown-

[cyg Simple]

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

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

[Jon Turney]

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.

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

[Jon Turney]

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?

Does keeping this cause a problem?

I guess we are generating a huge number of these tasks into the solver 
because "Keep" is kind of overloaded between "Don't care (but it just 
happens that I know that there's nothing to do)" and "Lock"?

Re: Cygwin Help needed

[Marco Atzeri]

On 17/10/2017 17:21, Mike Adkins wrote:

It will not let me chown cyg_server /home


you should not do it.



From: Mike Adkins 
Sent: Tuesday, October 17, 2017 11:18 AM

To: cygwin cygwin.com
Subject: RE: Cygwin Help needed

  


Any help?


There was already an answer
https://cygwin.com/ml/cygwin/2017-10/msg00145.html

asking for more details mentioning the  guidelines for reporting 
problems at  https://cygwin.com/problems.html.

In particular, please attach output of
cygcheck -svr.

If you are not subscribed to the mail list
I assume you have not received that reply.

Regards
MArco


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

RE: Cygwin Help needed

[Mike Adkins]

It will not let me chown cyg_server /home

 

From: Mike Adkins [mailto:bmike.adk...@gmail.com] 
Sent: Tuesday, October 17, 2017 11:18 AM
To: cygwin@cygwin.com
Subject: RE: Cygwin Help needed

 

Any help?

 

From: Mike Adkins [mailto:bmike.adk...@gmail.com] 
Sent: Monday, October 16, 2017 10:17 AM
To: cygwin@cygwin.com  
Subject: Cygwin Help needed

 

 

After I installed Cygwin syslog-ng, Cygwin ssh isn't working correctly..  

I am unable to change ownership or permissions..  /home is owned by
Administrator, not Cyg_server..  /dev is showing up in the folder list and
had been hidden.. and ssh keys are not working..  only with password.

 

Can you help?

 

Mike

 


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

[Mike Adkins]

Any help?

 

From: Mike Adkins [mailto:bmike.adk...@gmail.com] 
Sent: Monday, October 16, 2017 10:17 AM
To: cygwin@cygwin.com
Subject: Cygwin Help needed

 

 

After I installed Cygwin syslog-ng, Cygwin ssh isn't working correctly..  

I am unable to change ownership or permissions..  /home is owned by
Administrator, not Cyg_server..  /dev is showing up in the folder list and
had been hidden.. and ssh keys are not working..  only with password.

 

Can you help?

 

Mike

 


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


Ken
From f3b3c60ed473a1ef4e5b1ae5fcd1bfc46a6210fb Mon Sep 17 00:00:00 2001
From: Ken Brown 
Date: Tue, 17 Oct 2017 08:12:48 -0400
Subject: [PATCH] Avoid dereferencing NULL pointers

The libsolv function pool_id2solvable unconditionally dereferences its
first argument ('pool').  Callers must check that this argument is
non-NULL to avoid crashes.
---
 libsolv.cc | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libsolv.cc b/libsolv.cc
index 78e73a8..3a244d4 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -75,6 +75,8 @@ RelId2Operator(Id id)
 const std::string
 SolvableVersion::Name () const
 {
+  if (!pool)
+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 (!pool)
+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 (!pool)
+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 (!pool)
+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 (!pool)
+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 (!pool)
+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 (!pool)
+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: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

[Steven Penny]

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.


--
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 Git cant' Sync File Based repository

[Corinna Vinschen]

Please don't top-post.

On Oct 16 13:35, Gary Furash wrote:
> On Mon, Oct 16, 2017 at 1:09 PM, Gary Furash  wrote:
> 
> > From windows GIT
> >
> > [gffurash ~] $ git --version
> > git version 2.14.2.windows.3
> > [gffurash ~] $ which git
> > /mingw64/bin/git
> > [gffurash ~] $
> >
> > From Cygwin GIT
> >
> > [gffurash ~] $ git --version
> > git version 2.14.2
> > [gffurash ~] $ which git
> > /usr/bin/git
> > [gffurash ~] $
> >
> >
> > in each case they're referring to a different root: the former
> > C:\Progra~1\Git and the latter C:\Cygwin64
> >
> I think the issue IMHO is that when you use a *file* based repository git
> stores the file path in a certain way, and Cygwin64's git gets confused.

No, that's not Cygwin git's fault.  The problem is that you're using
Windows paths which only work in Git for Windows:

> [gffurash ~/Documents/Projects/wo219161] $ git remote -v
> origin  file://v:/GitSrcCtrl/wo219161 (fetch)
> origin  file://v:/GitSrcCtrl/wo219161 (push)

Change this to:

  $ git remote set-url origin file:///cygdrive/v/GitSrcCtrl/wo219161

or better, because this continues to work even after changing the
cygdrive path prefix:

  $ git remote set-url origin file:///proc/cygdrive/v/GitSrcCtrl/wo219161

POSIX-like paths should work in both git versions.


Corinna

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


signature.asc
Description: PGP signature