date:20200423

On Fri, 2020-04-10 at 14:52 +0200, Marco Atzeri via Cygwin-apps wrote:
> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
> > On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
> > > Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > I would suggest the following:
> > 
> > * python2-2.7.z continues to provide all '2' symlinks.
> > 
> > * python38 be updated to 3.8.2, and 3.8 be designated the next default
> > 'python3' version (with the '3' symlinks continued to be kept
> > separate), and adjust python-wheel.cygclass accordingly.
> > 
> > * Similarly, a separate package (in Fedora it's called 'python-
> > unversioned-command') provide unversioned symlinks, pointing to 2.7 for
> > now (for compatibility).
> > 
> > * Anything currently dependent on 'python' or 'python2' should either
> > be dropped if no longer needed, switched to 3 is possible, otherwise
> > rebuilt.
> > 
> > * Drop 2.7 from the "default" version set in python-wheel.cygclass, and
> > only build those modules that are actually needed by other things by
> > specifying "all".
> > 
> > * Once that's done, look at what's still depending on /usr/bin/python
> > ('python-unversioned-command'), and based on that decide when that can
> > be changed to point to python3.
> 
> first steps done:
> - updated 3.8 to 3.8.2
> - updated 3.7 to 3.7.7
> - updated also their python doc
> - upload of all of them is in progress

Didn't think of it earlier, but how about updating python3 (the major-
version symlinks) to 3.8 as a test: release now?  That should help
maintainers start the move without breaking the world for everybody
else.  Posted this to a branch to help:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python3.git;a=commitdiff;h=772172be59111366ece38aebb1ea876322bfdd2f

> next steps:
> - I assume we can drop 3.5

Your call, it's still supported upstream for almost 5 more months.  I
wouldn't build anything python35-* except for
setuptools/pip/wheel/virtualenv.

> - for the time being no need to update 2.7 and 3.6
>(we are just one version behind)

There's now a 2.7.18, we should probably pick that up, as it has the
final upstream fixes.  After that, it's time to start moving to 3.8 en
masse.

> - verify which python packages we need to build/rebuild
> 
> currently we have
> 
> 119 *python27*

These are fine as is, but they also don't need to be rebuilt or updated
any more.

> 114 *python36*
> 115 *python37*
> 10  *python38*

We don't need to _obsolete or remove python3[67]-* packages, we just
need to track how many don't have python38-* equivalents yet. 
Obviously that's still the vast majority, since 3.8 just got updated to
a stable version.

Jon Turney, if a python-foo source package was previously building e.g.
python27-foo, python36-foo, and python37-foo, and now starts building
only python37-foo and python38-foo, is calm going to complain?

> and ~ 225 other *python* packages (plus 10 for python35)

There are a lot of _obsolete python-*, python2-*, and python3-*
"packages" which we don't need to count.  How many of those names are
NOT _obsolete?

> - verify the fedora python-unversioned-command

This is the last step.

--
Yaakov

Re: Problems with ssh when I log into my PC using my corporate domain while working from home


On 4/23/2020 12:30 PM, Marco Atzeri via Cygwin wrote:



Am 23.04.2020 um 21:19 schrieb Marco Atzeri:

Am 23.04.2020 um 17:25 schrieb Mark Hansen:

On 4/23/2020 5:51 AM, Marco Atzeri via Cygwin wrote:

Am 23.04.2020 um 13:54 schrieb Mark Hansen:

On 4/21/2020 2:52 PM, Mark Hansen wrote:

On 4/21/2020 8:33 AM, Mark Hansen wrote:
I have a Windows 10 laptop, on which I installed Cygwin. I always 
log into the machine using
my corporate domain account. When I log into the machine from my 
office, everything Cygwin

works fine.

When I log into my laptop from home (which I'm working from home 
for a while now, due to
COVID-19), I still log in using my corporate domain account, but 
Cygwin acts differently.


Here is my user id (from the id command) when I log in from the 
office:


uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.





check the differences in outputs for

  "mkpasswd -c" and "id"

in the two cases.





I have the differences for 'id' in the two cases. However, I currently 
don't have access to
my office during the 'stay at home' order we're having to honor these 
days.


I don't understand the difference in the 'id' output, but they are 
different. I showed
the first little bit of each in my first message. Does this help? 
Should I attach the

complete output of the two runs here?



I would look at any differences in the 4th and 5th field of
  "mkpasswd -c" output



5th (SID) and 6th (Home)



Here is my mkpasswd -c output while the machine is at home (I can't run it at 
the office,
as I'm not allowed to go there at this time):

Mark.Hansen:*:1293438:1049089:U-MAN\Mark.Hansen,S-1-5-21-602162358-1060284298-725345543-244862:/cygdrive/c/Users/mark.hansen:/bin/zsh

Note that my domain is "MAN" not "U-MAN" - I don't know if that is significant.
This does show my home directory as /cygdrive/c/Users/mark.hansen, which is 
correct.



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

Re: dash vs. bash inconsistency

2020-04-23 Thread Mark Geisert


Sasha Slijepcevic via Cygwin wrote:

On 3/28/2020, Thomas Wolff wrote:


Am 28.03.2020 um 02:09 schrieb Sasha Slijepcevic via Cygwin:

I am using Cygwin 3.1.4-1, bash 4.4.12-3 and dash 0.5.9.1-1.

I have a setup.exe in the root of my Cygwin installation, C:\cygwin64, for 
example.
If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from bash.

C:\>set PATH=C:\cygwin64;C:\cygwin64\bin

C:\>bash
$ echo $PATH
/:/usr/bin
$ setup-x86_64.exe  --version
Cygwin setup 2.903

However, in dash:
C:\>dash
$ echo $PATH
/:/usr/bin
$ setup-x86-64.exe --version
dash: 2: setup-x86-64.exe: not found

Am I misusing Cygwin trying to run executables from the top of the 
installation? Is it expected to all shells would behave the
same?


You mis-typed the name of the executable when trying dash.

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

Re: ssh-pageant

2020-04-23 Thread Andrey Repin

Greetings, Chris Rodgers!

> Thanks for the detailed reply. Interesting!

>> It's not that simple. You can't blindly restart agent every time you wish
>> without notifying other programs, `--reuse` is a very bad idea and there's
>> no easy way to set/change an environment variable globally for an entire
>> user session.

> May I ask, why do you say "--reuse" is a very bad idea? I'd be 
> interested to know in general, not just when considering this change.

With --reuse you're using predictable name, and not checking its permissions.
You can never know if that socket was actually created by you or left there by
accident. If you noticed, I trash both socket and agent configuration before
activating the agent anew. That gives me a little more control on what's going
on in the system.


-- 
With best regards,
Andrey Repin
Thursday, April 23, 2020 23:46:25

Sorry for my terrible english...

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

Re: ssh-pageant

2020-04-23 Thread Bill Stewart

On Thu, Apr 23, 2020 at 1:00 PM Thomas Wolff wrote:

> The Cygwin package manager (setup) in the description of the ssh-pageant
> package:
> "SSH agent for Cygwin/MSYS that links to PuTTY's Pageant"

The language is a bit imprecise, I suppose. Pageant is related to but
!= PuTTY - you don't have to use PuTTY to use Pageant (you may just
prefer to use Pageant instead of ssh-agent or whatever and not use
PuTTY).

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

Re: ssh-pageant


Dear Andrew,

Thanks for the detailed reply. Interesting!


It's not that simple. You can't blindly restart agent every time you wish
without notifying other programs, `--reuse` is a very bad idea and there's
no easy way to set/change an environment variable globally for an entire
user session.


May I ask, why do you say "--reuse" is a very bad idea? I'd be 
interested to know in general, not just when considering this change.


Best wishes,

Chris.

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

Re: ssh-pageant

2020-04-23 Thread Andrey Repin

Greetings, Chris Rodgers!

> I find the ssh-pageant package helpful to enable cygwin ssh to interact
> seamlessly with PuTTY's Pageant SSH agent. One small issue is that after 
> installing, one has to add the lines:

>> |# ssh-pageant eval $(/usr/bin/ssh-pageant -r -a 
>> "/tmp/.ssh-pageant-$USERNAME")|
> (see https://github.com/cuviper/ssh-pageant) 
> to .bashrc for each user.

> Would it be acceptable to update the ssh-pageant package to add a file 
> /etc/profile.d/ssh-pageant.sh that does this automatically?

It's not that simple. You can't blindly restart agent every time you wish
without notifying other programs, `--reuse` is a very bad idea and there's
no easy way to set/change an environment variable globally for an entire
user session.

> Or is there another preferred way to do this, e.g. a postinstall script?

> I'd be happy to draft a script file for review.

Just create a script for yourself and amend your own .bashrc accordingly.

I do it this way:

1. Add

- 8< - 8< - 8< - 8< -
# Import ssh-pageant settings
test -f "$HOME/.ssh/agent" && . "$HOME/.ssh/agent"
- >8 - >8 - >8 - >8 -

near the end of .bashrc

2. Create a script `$HOME/profile.d/ssh-pageant.sh`

- 8< - 8< - 8< - 8< -
#!/bin/sh

[ -x /usr/bin/ssh-pageant ] || return

_agent="$HOME/.ssh/agent"
eval set -- $( getopt --shell=sh -o 'k' -- "$@" )

test -f "$_agent" && . "$_agent"

if [ "$SSH_PAGEANT_PID" ]; then
  if test "$1" = "-k"; then
/usr/bin/ssh-pageant -qk 2> /dev/null
  fi

  if ! kill -0 "$SSH_PAGEANT_PID" 2> /dev/null; then
# Reap dead agent's socket
rm "$SSH_AUTH_SOCK" "$_agent" 2> /dev/null
unset SSH_AUTH_SOCK SSH_PAGEANT_PID
  fi
fi

test "$1" = "-k" && exit
test "$SSH_PAGEANT_PID" && exit

socket="$( mktemp -u /var/run/ssh- )"
eval $( cygdrop -- /usr/bin/ssh-pageant -qsa "$socket" | tee "$_agent" )

# Remove empty settings file (agent failed to start).
test -s "$_agent" || rm "$_agent"
- >8 - >8 - >8 - >8 -

3. Create login job to run scripts from ~/profile.d/ on user login.

4. If you need agent settings in a different script, that may be run outside
normal terminal/shell workflow, just add

- 8< - 8< - 8< - 8< -
test -f "$HOME/.ssh/agent" && . "$HOME/.ssh/agent"
- >8 - >8 - >8 - >8 -

near the top.

5. Don't forget to `ssh-pageant.sh -k` before running Cygwin setup.


-- 
With best regards,
Andrey Repin
Thursday, April 23, 2020 21:28:24

Sorry for my terrible english...

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

Re: ssh-pageant

So.. one more thing to consider. I just had a look in the cygwin package 
search for packages shipping files in /etc/profile.d/


It turns out that one example already shipping in Cygwin is 
http://www.cygwin.com/packages/x86_64/gnome-ssh-askpass/gnome-ssh-askpass-7.4-1




  gnome-ssh-askpass: GTK+ passphrase grabber for ssh-add

 2017-03-17 00:34   0 etc/
 2017-03-17 00:34   0 etc/profile.d/
 2017-03-17 00:34  97 etc/profile.d/gnome-ssh-askpass.csh
 2017-03-17 00:34  52 etc/profile.d/gnome-ssh-askpass.fish
 2017-03-17 00:34  52 etc/profile.d/gnome-ssh-askpass.sh
 2017-03-17 00:34   0 usr/
 2017-03-17 00:34   0 usr/lib/
 2017-03-17 00:34   0 usr/libexec/
 2017-03-17 00:34   14867 usr/libexec/gnome-ssh-askpass.exe
 2017-03-17 00:34   0 usr/share/
 2017-03-17 00:34   0 usr/share/doc/
 2017-03-17 00:34   0 usr/share/doc/gnome-ssh-askpass/
 2017-03-17 00:341253 usr/share/doc/gnome-ssh-askpass/COPYING
 2017-03-17 00:34 531 usr/share/doc/gnome-ssh-askpass/README
There, 3 shell scripts are provided to cover users of several shells. I 
could do that.


And the contents are:


$ cat gnome-ssh-askpass.sh
export SSH_ASKPASS="/usr/libexec/gnome-ssh-askpass"

$ cat gnome-ssh-askpass.csh
if ( ! $?SSH_ASKPASS ) setenv SSH_ASKPASS ""
setenv SSH_ASKPASS "/usr/libexec/gnome-ssh-askpass"

$ cat gnome-ssh-askpass.fish
set -x SSH_ASKPASS "/usr/libexec/gnome-ssh-askpass"


Is there any mileage in the argument that if we do this for Gnome's SSH 
helper, we can also reasonably do it for ssh-pageant?


I'll leave this for now and see whether anyone else has an opinion.

Best wishes,

Chris.

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

write() on 64 bit platform sometimes returns 32bit -1 as error indicator

2020-04-23 Thread netbsdrat--- via Cygwin

 
write() on 64 bit platform sometimes returns 32bit -1 as error indicator:
 
Using 64 bit cygwin on 64 bit platform.  Doing direct read() / write of
disks,
this example is using the /dev/floppy device.
 
Opening for writing floppy device using open() succeeds.
 
2 cases:
 
CaseA) write() a 512 byte buffer to the floppy, succeeds with return
value of 512, errno = 0.  This works.
 
CaseB) write() a 5120 byte buffer to the floppy.  This fails if we have
recently
formatted the floppy with windows.  Perhaps windows still has some file
descriptor to the floppy open?  But this is not the point.
 
The point is that the return value from the write() is 4294967295
(0x).
This value is a 32 bit -1.  When we compare the return value to -1 (64 bit),
the compare fails, which indicates that the write succeeded, and implies
that
4294967295 bytes were written.
 
The write did not succeed though.  No data was written to the floppy.
Errno is set indicating an error (13 'Permission denied'), but the return
value from write() is not correct for this situation.  Thus the write
failure cannot
be detected (except by looking at errno)!  BTW, return value in this
case == -1U, but not == -1.
 
CaseC) As a third control case to make sure that I was understanding all the
data
widths, I tried opening a fake file, and doing the same write to it,
expecting an error.  The error propagated correctly... the return value
of writing to a bad file descriptor was 64 bit -1 (0x)
and can be compared to -1 directly to detect the error.  Errno is set
correctly.
 
So I think that somewhere in the myriad of pathways between 32 / 64 bit
way down in the depths of cygwin, this unusual write error triggers a return
value of 32 bit -1 instead of 64 bit -1.
 
Is this cygwin issue?  gcc issue?  libc issue??


Thanks,

John Refling



PS:  Equally odd is the errno of 13, 'permission denied' with a different
buffer size.  You can write 512 bytes after getting the permission denied,
and then after that, write as many bytes as you want without 'permission
denied'.  Some strange things in windows, cygwin, or the interaction of the
two. 

Output of attached sample programs:


/* CaseA OUTPUT, here we test 512 which works.

open floppy, which is OK
fno = 3, errno = 0 'No error'
ie: fopen() OK

try write() 512 which is OK
RV = 0x200 or 512, errno = 0 'No error'

Write OK!

*/

/* CaseB OUTPUT: this case triggers bad return value

open floppy, which is OK
fno = 3, errno = 0 'No error'
ie: fopen() OK

try write() 5120 which is NOT ok, sometimes.

RV = 0x or 4294967295, errno = 13 'Permission denied'
but nothing actually written

RV IS NOT == 0
RV IS NOT < 0
RV IS NOT == -1
RV IS NOT == -1L
RV IS == -1U!!!  32 bit -1  !!!

no way to detect this write() failure!

*/

/* CaseC OUTPUT: this case shows usual correct return value for fail

open fake file, which fails, as expected
fno = -1, errno = 2 'No such file or directory'

try write() 512 to bad file, expect fail
RV = 0x or -1, errno = 9 'Bad file descriptor'

RV IS NOT == 0
RV IS < 0
RV IS == -1
RV IS == -1L
RV IS NOT == -1U

can detect this failure.

*/



caseA.c
Description: Binary data


caseC.c
Description: Binary data


caseB.c
Description: Binary data
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Two naive questions

2020-04-23 Thread Christopher Faylor

On Thu, Apr 23, 2020 at 03:13:12PM -0400, Christopher Faylor wrote:
>Information provided information here:

Or, even just "Information provided here:"

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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Achim Gratz

Mark Hansen writes:
> I think Windows knows who I am. I log into the machine using my normal domain 
> login
> credentials. The machine looks the way it does when I log in when the machine 
> is in the
> office - the desktop is the same, etc. - it's not acting like I'm a new user 
> or anything
> like that.

That doesn't necessarily tell you anything about what happens when you
try to log in via ssh (which creates a new session and requires an
independent login).  Again, the fact that Cygwin shows you a different
user name already tells you that there is something quite different from
when you are in the office.  If you can strace id you might get a clue
of what is going on with the queries to the AD sever in both cases
(i.e. what server it asks and whether it gets an answer).

> Everything on the Windows side seems to be working fine. The only issue I've 
> found is with
> Cygwin. Is there a way (short of removing and reinstalling Cygwin) that I can 
> get Cygwin
> to recognize my current user so ssh and git can know where my home directory 
> is located?

Yes, you can force a home directory via config files, but you should
keep in mind that this can fail in even more mysterious ways should the
environment change again.

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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Marco Atzeri via Cygwin




Am 23.04.2020 um 21:19 schrieb Marco Atzeri:

Am 23.04.2020 um 17:25 schrieb Mark Hansen:

On 4/23/2020 5:51 AM, Marco Atzeri via Cygwin wrote:

Am 23.04.2020 um 13:54 schrieb Mark Hansen:

On 4/21/2020 2:52 PM, Mark Hansen wrote:

On 4/21/2020 8:33 AM, Mark Hansen wrote:
I have a Windows 10 laptop, on which I installed Cygwin. I always 
log into the machine using
my corporate domain account. When I log into the machine from my 
office, everything Cygwin

works fine.

When I log into my laptop from home (which I'm working from home 
for a while now, due to
COVID-19), I still log in using my corporate domain account, but 
Cygwin acts differently.


Here is my user id (from the id command) when I log in from the 
office:


uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.





check the differences in outputs for

  "mkpasswd -c" and "id"

in the two cases.





I have the differences for 'id' in the two cases. However, I currently 
don't have access to
my office during the 'stay at home' order we're having to honor these 
days.


I don't understand the difference in the 'id' output, but they are 
different. I showed
the first little bit of each in my first message. Does this help? 
Should I attach the

complete output of the two runs here?



I would look at any differences in the 4th and 5th field of
  "mkpasswd -c" output



5th (SID) and 6th (Home)

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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Marco Atzeri via Cygwin


Am 23.04.2020 um 17:25 schrieb Mark Hansen:

On 4/23/2020 5:51 AM, Marco Atzeri via Cygwin wrote:

Am 23.04.2020 um 13:54 schrieb Mark Hansen:

On 4/21/2020 2:52 PM, Mark Hansen wrote:

On 4/21/2020 8:33 AM, Mark Hansen wrote:
I have a Windows 10 laptop, on which I installed Cygwin. I always 
log into the machine using
my corporate domain account. When I log into the machine from my 
office, everything Cygwin

works fine.

When I log into my laptop from home (which I'm working from home 
for a while now, due to
COVID-19), I still log in using my corporate domain account, but 
Cygwin acts differently.


Here is my user id (from the id command) when I log in from the 
office:


uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.





check the differences in outputs for

  "mkpasswd -c" and "id"

in the two cases.





I have the differences for 'id' in the two cases. However, I currently 
don't have access to

my office during the 'stay at home' order we're having to honor these days.

I don't understand the difference in the 'id' output, but they are 
different. I showed
the first little bit of each in my first message. Does this help? Should 
I attach the

complete output of the two runs here?



I would look at any differences in the 4th and 5th field of
 "mkpasswd -c" output

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

Re: PDDL problem in Eclipse

2020-04-23 Thread cygwinautoreply--- via Cygwin

>1 [main] dos2unix 12596 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>dos2unix: output: No such file or directory
>dos2unix: Skipping output, not a regular file.

>I had error like above
>I think the problem is in path:
>\eclipse\java-latest-released\eclipse\fast-downward\fast-downward-dist\\bin\preprocess.exe
>\eclipse\java-latest-released\eclipse\fast-downward\fast-downward-dist\\bin\dos2unix

>there is double backslash

>Pozdrawiam,
>Robert Szarek

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

PDDL problem in Eclipse

2020-04-23 Thread Robert via Cygwin

1 [main] dos2unix 12596 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
dos2unix: output: No such file or directory
dos2unix: Skipping output, not a regular file.

I had error like above
I think the problem is in path:
\eclipse\java-latest-released\eclipse\fast-downward\fast-downward-dist\\bin\preprocess.exe
\eclipse\java-latest-released\eclipse\fast-downward\fast-downward-dist\\bin\dos2unix

there is double backslash

-- 
Pozdrawiam,
Robert Szarek
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Two naive questions

2020-04-23 Thread Christopher Faylor

On Thu, Apr 23, 2020 at 09:49:34AM -0700, Stephen Carrier wrote:
>On Wed, Apr 22, 2020 at 12:57:50PM +0300, Andrey Repin wrote:
>>You can ask list management software to resend past messages.  I don't
>>recall specifics, and given the recent change, they may be entirely
>>obsolete.  You can check https://www.list.org/ for directions.
>
>As I commented upthread (Monday) I have seen instructions on how to
>recall messages.  I tried them, and they did not work.  I tried again
>more recently, and the instructions did not work, and I received bounce
>messages to the effect that the request was not understood.  I also
>commented above that I had looked at the mailman documentation for
>which you provide a link, and did not find any method described for
>recalling messages.

Apparently you're not reading the whole cygwin mailing list thread on this
subject:

https://cygwin.com/pipermail/cygwin/2020-April/thread.html

To reiterate, cygwin.com's hosting site "sourceware.org" went through a
hardware and software change in March.  If you're attempting to use
instructions from before the move to new hardware and different mailing
list software then they won't work.

>If you think I am mistaken, please find the information on how to do this
>and provide a specific link.  Providing a link to the main documentation
>page and suggesting that others go looking is to send them on a wild-goose
>chase aka waste of time.
>
>It would be a useful feature, I agree, and if I simply failed to find
>what I was looking for, I would welcome correction.

Information provided information here:

https://cygwin.com/pipermail/cygwin/2020-April/244545.html
https://cygwin.com/pipermail/cygwin/2020-April/244546.html

To summarize: You can click on the mailto link of any message in the
archive and it will invoke your email client with the proper In-Reply-To
set.  That will allow you to reply to the sender of the message and
maintain proper threading.  If you want to send to the list, replace the
"To" with the email address of the list.

I am aware that some people may find this incredibly daunting but that's
what's available given the software that we're using.  Read the thread
for why we're using the mailman2 software.

You can download the archive by going to, e.g.,

https://cygwin.com/pipermail/cygwin/

and clicking on the "Downloadable version" for the time period that
you need.  It will be a gzipped mbox-formatted text archive.

If none of this meets your needs then maybe some of the other sites
that archive the cygwin list will have something more to your liking.

cgf

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

Re: ssh-pageant

2020-04-23 Thread Thomas Wolff


Am 23.04.2020 um 20:31 schrieb Andrey Repin:

Greetings, Thomas Wolff!


Am 23.04.2020 um 15:50 schrieb Chris Rodgers:

Hi,

I find the ssh-pageant package helpful to enable cygwin ssh to
interact seamlessly with PuTTY's Pageant SSH agent. One small issue is
that after installing, one has to add the lines:


|# ssh-pageant eval $(/usr/bin/ssh-pageant -r -a
"/tmp/.ssh-pageant-$USERNAME")|

(see https://github.com/cuviper/ssh-pageant)
to .bashrc for each user.

Would it be acceptable to update the ssh-pageant package to add a file
/etc/profile.d/ssh-pageant.sh that does this automatically?

Does what? Add something to other users' profiles? Sounds like MS-style
patronizing of user preferences. Certainly not appreciated by most
people. Also, why should most cygwin users want to use ssh via putty?
Mintty + ssh is a seamless modular solution.

Who said anything about putty?
The Cygwin package manager (setup) in the description of the ssh-pageant 
package:

"SSH agent for Cygwin/MSYS that links to PuTTY's Pageant"

  We're speaking about pageant - the key keeper.
Which has a better support in Windows apps than Cygwin's ssh-agent.

While I agree with your judgement, I don't get your patronizing.




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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Norton Allen


On 4/23/2020 2:10 PM, Mark Hansen wrote:

On 4/23/2020 10:26 AM, ASSI wrote:

Mark Hansen writes:

Here is my user id (from the id command) when I log in from the office:

uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.


That likely means that when you connect from home, you cannot talk to 
the

corporate domain server or you are ion a different domain.  The domain
part is only shown when it isn't the primary domain IIRC and since the
numerical user instead of the name is shown, that SID did not resolve.

The actual problem I'm having is that Cygwin tools like ssh, git, 
etc. can't find my .ssh

directory. They are looking in "/" rather than my home directory.


Depending on how this is set up in your domain, you might need to point
either Cygwin or sshd to use a separate local directory.  You have no
network access on Windows (i.e. you won't be able to access any fils
shares) until you've authenticated with a password.

I tried copying my .ssh directory from my home to "/" and although 
it was created, the

files have the wrong permissions and I'm unable to change them.


You would need to be either an admin and/or the user who installed
Cygwin for that to work, but you shouldn't do that.

Is there something I can tweak to get Cygwin to understand which 
user I am so the ssh

stuff can start working again?


If Cygwin doesn't know who you are, then that means Windows doesn't know
either, so fixing this on the Cygwin side won't get you much further.


Regards,
Achim.



I think Windows knows who I am. I log into the machine using my normal 
domain login
credentials. The machine looks the way it does when I log in when the 
machine is in the
office - the desktop is the same, etc. - it's not acting like I'm a 
new user or anything

like that.

Everything on the Windows side seems to be working fine. The only 
issue I've found is with
Cygwin. Is there a way (short of removing and reinstalling Cygwin) 
that I can get Cygwin
to recognize my current user so ssh and git can know where my home 
directory is located?


I also have had to deal with this problem. You should certainly read 
https://cygwin.com/cygwin-ug-net/ntsec.html.


After much experimenting and consultation with Corinna, we decided the 
best solution for me was:


 * Create /etc/passwd and /etc/group files
 o For /etc/passwd, I included just my account, and I actually
   editted it further to use my preferred username (rather than my
   domain username) and my correct home directory
 * Edit /etc/nsswitch.conf with:
 o passwd: files
 o group: files

This is not the generally recommended configuration, but in the 
situation where you cannot reach the domain server, it may be the best 
alternative. You may or may not need to back these changes out when you 
are back at work. I have not had a problem at work, but we are only 
loosely connected to the domain, so YMMV.


--

=
Norton Allen (he/him/his)
Software Engineer
Harvard University School of Engineering and Applied Sciences
12 Oxford St., Link Bldg. (Office 282)
Cambridge, MA  02138
Phone: (617) 998-5553
=

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

Re: [ITA] python2-wx and related packages for wxPython and wxwidgets

On Thu, 2020-04-23 at 18:09 +0100, Hamish McIntyre-Bhatty wrote:
> On 23/04/2020 17:08, Yaakov Selkowitz wrote:
> > Please keep all discussion on list.
> > 
> My apologies, I thought I'd sent the reply to the list.
> > Most of that has already been figured out in our python-wx package. 
> > Looking at Fedora, it looks like we just need to add their wxPython-
> > 3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0-
> > fix-wxcairo.patch and we'll be in sync.
> > 
> Okay, I'll add those patches. I think I've gotten confused somehow,
> because my cygport and files are based on the source package for
> python-wx at
> http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/python-wx/,
> but the cygport in that archive also builds all of the other packages,
> and doesn't use the system wxWidgets headers, hence me hacking in the
> wxWidgets 3.0.4 files and having to build everything together.

The work to split them out is already published:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/wxWidgets3.0.git
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/python-wx.git

I suppose I just never needed to actually rebuild python-wx after that,
but the work was done in preparation.

> wxPython 3.0.2 itself is shipped with wxWidgets 3.0.2 in the tarball
> from wxpython.org, and seems to insist upon building its own copy of
> wxwidgets.

Maybe by default, but it is buildable without.

> > No, that's just bound to cause problems.
> > 
> This is confusing me because it seems to be what the existing packages do.

That's what they *used* to do.  I moved away from that for the reasons
outlined.

> > Look forward to the follow up.
> > 
> > BTW, did you have any plans to figure out wxPython4?
> 
> Good to hear. I do, I just haven't had the time yet and I figured it'd
> be best to get wxPython 3 in really good shape (and get some practice
> with packaging!) before sorting that one out.

Fair enough.  python-sip will need to be updated for that as well,
which requires also updating python-pyqt5* in sync therewith, so this
will need to be coordinated.

--
Yaakov

Re: ssh-pageant

2020-04-23 Thread Andrey Repin

Greetings, Thomas Wolff!

> Am 23.04.2020 um 15:50 schrieb Chris Rodgers:
>> Hi,
>>
>> I find the ssh-pageant package helpful to enable cygwin ssh to 
>> interact seamlessly with PuTTY's Pageant SSH agent. One small issue is 
>> that after installing, one has to add the lines:
>>
>>> |# ssh-pageant eval $(/usr/bin/ssh-pageant -r -a 
>>> "/tmp/.ssh-pageant-$USERNAME")|
>> (see https://github.com/cuviper/ssh-pageant) 
>> to .bashrc for each user.
>>
>> Would it be acceptable to update the ssh-pageant package to add a file 
>> /etc/profile.d/ssh-pageant.sh that does this automatically?
> Does what? Add something to other users' profiles? Sounds like MS-style 
> patronizing of user preferences. Certainly not appreciated by most 
> people. Also, why should most cygwin users want to use ssh via putty? 
> Mintty + ssh is a seamless modular solution.

Who said anything about putty? We're speaking about pageant - the key keeper.
Which has a better support in Windows apps than Cygwin's ssh-agent.

While I agree with your judgement, I don't get your patronizing.


-- 
With best regards,
Andrey Repin
Thursday, April 23, 2020 21:29:02

Sorry for my terrible english...

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

Re: ssh-pageant

2020-04-23 Thread Brian Inglis

On 2020-04-23 07:50, Chris Rodgers wrote:
> I find the ssh-pageant package helpful to enable cygwin ssh to interact
> seamlessly with PuTTY's Pageant SSH agent. One small issue is that after
> installing, one has to add the lines:
>   # ssh-pageant
>   eval $(/usr/bin/ssh-pageant -r -a "/tmp/.ssh-pageant-$USERNAME")
> (see https://github.com/cuviper/ssh-pageant)
> to .bashrc for each user.
> Would it be acceptable to update the ssh-pageant package to add a file
> /etc/profile.d/ssh-pageant.sh that does this automatically?
> Or is there another preferred way to do this, e.g. a postinstall script?
> I'd be happy to draft a script file for review.

For the general case, you may want to suggest that the maintainer include
instructions about this in each upgrade notice, but nothing should be done in
the package as it assumes too much about users' environments.

For example: what if their default shell/s is/are not bash, or they don't
already have a .bashrc, and shouldn't you do that setup in whatever their shell
profile is, if they have one, and what if they don't; what if Pageant or Cygwin
don't use Cygwin /tmp/ but some other TMPDIR e.g. Windows ~/AppData/Local/Temp/;
what if your users run ssh from cmd without starting Cygwin; etc.?

You may do what your users allow you on their systems, but you have to ensure
that your Putty/Pageant and ssh setup additions work flawlessly on all of them,
coordinating between what you do for Pageant and what you do for ssh.

You may want to consider doing whatever is required in each user's ssh_config if
possible, or /etc/ssh_config to provide users defaults, as those depend least on
each user's environment.

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Hamish McIntyre-Bhatty via Cygwin-apps


On 4/23/2020 10:26 AM, ASSI wrote:

Mark Hansen writes:

Here is my user id (from the id command) when I log in from the office:

uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.


That likely means that when you connect from home, you cannot talk to the
corporate domain server or you are ion a different domain.  The domain
part is only shown when it isn't the primary domain IIRC and since the
numerical user instead of the name is shown, that SID did not resolve.


The actual problem I'm having is that Cygwin tools like ssh, git, etc. can't 
find my .ssh
directory. They are looking in "/" rather than my home directory.


Depending on how this is set up in your domain, you might need to point
either Cygwin or sshd to use a separate local directory.  You have no
network access on Windows (i.e. you won't be able to access any fils
shares) until you've authenticated with a password.


I tried copying my .ssh directory from my home to "/" and although it was 
created, the
files have the wrong permissions and I'm unable to change them.


You would need to be either an admin and/or the user who installed
Cygwin for that to work, but you shouldn't do that.


Is there something I can tweak to get Cygwin to understand which user I am so 
the ssh
stuff can start working again?


If Cygwin doesn't know who you are, then that means Windows doesn't know
either, so fixing this on the Cygwin side won't get you much further.


Regards,
Achim.



I think Windows knows who I am. I log into the machine using my normal domain 
login
credentials. The machine looks the way it does when I log in when the machine 
is in the
office - the desktop is the same, etc. - it's not acting like I'm a new user or 
anything
like that.

Everything on the Windows side seems to be working fine. The only issue I've 
found is with
Cygwin. Is there a way (short of removing and reinstalling Cygwin) that I can 
get Cygwin
to recognize my current user so ssh and git can know where my home directory is 
located?


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

Re: dash vs. bash inconsistency

2020-04-23 Thread Maarten Hoes via Cygwin

Hi,


>>
> >> I have a setup.exe in the root of my Cygwin installation, C:\cygwin64,
> for example.
> >> If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from
> bash.
> >>
> >> C:\>set PATH=C:\cygwin64;C:\cygwin64\bin
> >>
> >> C:\>bash
> >> $ echo $PATH
> >> /:/usr/bin
> >> $ setup-x86_64.exe  --version
> >> Cygwin setup 2.903
> >>
> >> However, in dash:
> >> C:\>dash
> >> $ echo $PATH
> >> /:/usr/bin
> >> $ setup-x86-64.exe --version
> >> dash: 2: setup-x86-64.exe: not found
> >>
> >> Am I misusing Cygwin trying to run executables from the top of the
> installation? Is it expected to all shells would behave the
> >> same?
>
>
>
For what it's worth (which admittedly may not be much):
If I copy

D:\cygwin64\bin\ls.exe to D:\cygwin64\ foo.exe

I can reproduce this issue: bash finds 'foo.exe' in D:\cygwin64, but dash
does not.



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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread ASSI

Mark Hansen writes:
> Here is my user id (from the id command) when I log in from the office:
>
> uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...
>
> Here is the same when I've logged in with the machine at home:
>
> uid=1293438(MAN+User(244862)) gid=1293438
>
> (MAN) is the domain.

That likely means that when you connect from home, you cannot talk to the
corporate domain server or you are ion a different domain.  The domain
part is only shown when it isn't the primary domain IIRC and since the
numerical user instead of the name is shown, that SID did not resolve.

> The actual problem I'm having is that Cygwin tools like ssh, git, etc. can't 
> find my .ssh
> directory. They are looking in "/" rather than my home directory.

Depending on how this is set up in your domain, you might need to point
either Cygwin or sshd to use a separate local directory.  You have no
network access on Windows (i.e. you won't be able to access any fils
shares) until you've authenticated with a password.

> I tried copying my .ssh directory from my home to "/" and although it was 
> created, the
> files have the wrong permissions and I'm unable to change them.

You would need to be either an admin and/or the user who installed
Cygwin for that to work, but you shouldn't do that.

> Is there something I can tweak to get Cygwin to understand which user I am so 
> the ssh
> stuff can start working again?

If Cygwin doesn't know who you are, then that means Windows doesn't know
either, so fixing this on the Cygwin side won't get you much further.

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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITA] python2-wx and related packages for wxPython and wxwidgets

On 23/04/2020 17:08, Yaakov Selkowitz wrote:
> Please keep all discussion on list.
>
My apologies, I thought I'd sent the reply to the list.
> Most of that has already been figured out in our python-wx package. 
> Looking at Fedora, it looks like we just need to add their wxPython-
> 3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0-
> fix-wxcairo.patch and we'll be in sync.
>
Okay, I'll add those patches. I think I've gotten confused somehow,
because my cygport and files are based on the source package for
python-wx at
http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/python-wx/,
but the cygport in that archive also builds all of the other packages,
and doesn't use the system wxWidgets headers, hence me hacking in the
wxWidgets 3.0.4 files and having to build everything together.

wxPython 3.0.2 itself is shipped with wxWidgets 3.0.2 in the tarball
from wxpython.org, and seems to insist upon building its own copy of
wxwidgets.

> No, that's just bound to cause problems.
>
This is confusing me because it seems to be what the existing packages do.
> Look forward to the follow up.
>
> BTW, did you have any plans to figure out wxPython4?

Good to hear. I do, I just haven't had the time yet and I figured it'd
be best to get wxPython 3 in really good shape (and get some practice
with packaging!) before sorting that one out.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Two naive questions

2020-04-23 Thread Stephen Carrier

On Wed, Apr 22, 2020 at 12:57:50PM +0300, Andrey Repin wrote:
> You can ask list management software to resend past messages.
> I don't recall specifics, and given the recent change, they may be entirely
> obsolete.
> You can check https://www.list.org/ for directions.

Glendower: I can call the spirits from the vasty deep.

Hotspur: Why, so can I, or so can any man; But will they come, when you do call 
for them?

As I commented upthread (Monday) I have seen instructions on how to
recall messages.  I tried them, and they did not work.  I tried again
more recently, and the instructions did not work, and I received
bounce messages to the effect that the request was not understood.
I also commented above that I had looked at the mailman documentation
for which you provide a link, and did not find any method described for
recalling messages.

If you think I am mistaken, please find the information on how to do this
and provide a specific link.  Providing a link to the main documentation
page and suggesting that others go looking is to send them on a wild-goose
chase aka waste of time.

It would be a useful feature, I agree, and if I simply failed to find
what I was looking for, I would welcome correction.

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

Re: ssh-pageant


On 23/04/2020 17:40, Chris Rodgers wrote:


Thomas Wolff wrote:


>/Would it be acceptable to update the ssh-pageant package to add a file 
/>//etc/profile.d/ssh-pageant.sh that does this automatically? /Does what? Add 
something to other users' profiles?


P.S. I realise I may have been unclear. By "does this" I mean running


|eval $(/usr/bin/ssh-pageant -r -a "/tmp/.ssh-pageant-$USERNAME")|
when ssh-pageant package is installed on the system, as a line in 
/etc/profile.d/ssh-pageant.sh file included with the package. There 
would then not be any changes to the per-user .bash_profile or .bashrc 
files.


BW

Chris.

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

Re: ssh-pageant

Thomas Wolff wrote:

>/Would it be acceptable to update the ssh-pageant package to add a file 
/>//etc/profile.d/ssh-pageant.sh that does this automatically? /Does what? Add 
something to other users' profiles? Sounds like MS-style
patronizing of user preferences. Certainly not appreciated by most
people. Also, why should most cygwin users want to use ssh via putty?
Mintty + ssh is a seamless modular solution.

>

The sole purpose of installing ssh-pageant is to use pageant as an SSH 
key agent for openssh. It's not a base package. So the users who install 
ssh-pageant on their machines presumably want pageant to be their ssh 
key agent for openssh. So I am proposing that this should work 
immediately after the package is installed, without requiring editing 
the .bash_profile file.

Adding a file to /etc/profile.d/ssh-pageant.sh seems like it would be a 
simple way to achieve this.

I guess there is an issue for multi-user machines where different users 
want to use different SSH agents wherein the default ssh agent would be 
set for all users on installing ssh-pageant package. It can still 
trivially be overridden by a .bash_profile configuration of an SSH key 
agent in the user profile scripts.

What do people think? My driver is that it would be nice to streamline 
the standard setup for folk in my lab.

The other thought I had was to add a postinstall script, like some 
fedora or ubtuntu packages have. Are these allowed to prompt the user 
interactively whether they wish to configure the profile setting?

BW

Chris.

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

Re: [ITA] python2-wx and related packages for wxPython and wxwidgets

On Thu, 2020-04-23 at 16:16 +0100, Hamish McIntyre-Bhatty wrote:
> Thanks for your feedback. I wasn't expecting this to be accepted, it's
> only my first try after all :)

Please keep all discussion on list.

> > I do not recommend building both the C++ libraries and Python bindings
> > from the same source package, for several reasons:
> > 
> > * Python bindings need to be updated/rebuilt with each new version of
> > Python, which occurs much more frequently than updated versions of
> > wxWidgets.  Keeping them separate minimizes the rebuild times.
> > 
> > * wxPython and wxWidgets versions don't always match, as you mentioned
> > above.  Building them separately avoids jumping through those sort of
> > hoops.
> > 
> > * wxPython 3 is obsolete anyway, with current support only for version
> > 4 (which is still for wxWidgets 3), so this scheme won't carry forward
> > anyway.
> > 
> > Since the standalone wxWidgets3.0 package is already at 3.0.4, all you
> > may want to do is revbump and rebuild python-wx.
> 
> This is fair enough. However, I was unable to build wxPython against the
> already-installed system version of wxWidgets, as that isn't how it was
> intended to be compiled, and it would require large changes to the
> pre-existing packaging.

Most of that has already been figured out in our python-wx package. 
Looking at Fedora, it looks like we just need to add their wxPython-
3.0.2.0-suppress-version-mismatch-warning.patch and wxPython-3.0.2.0-
fix-wxcairo.patch and we'll be in sync.

> How about I instead ignore the wxwidgets packages built this way? This
> will result in long build times as per the pre-existing packaging, but
> there will probably not be much need to re-build this.

No, that's just bound to cause problems.

> > Do NOT drop this patch.  You might be aligned now, but as soon as
> > gcc/libstdc++ get updated, the mismatch will reoccur, and programs will
> > unnecessarily fail again.
> Okay, I shall re-instate it and re-build.
> > > The few remaining wxGTK* patches:
> > > - No longer apply without error and don't seem to be needed with the
> > > newer wxwidgets version.
> > Patches were added for a reason; if you don't understand what they do
> > and why they're there, then you should be asking why rather than
> > dismissing them.  In the case of Gentoo's collision patch, this is
> > needed to support parallel installations of X.Y versions of wxWidgets. 
> > The updated patch is named wxGTK-3.0.5-collision.patch.
> > 
> Good to know, I will attempt to find updated patches. Is there an online
> repository where they are held? I will go back through the other patches
> which did not apply and attempt to find replacements/ask what they do.

Look forward to the follow up.

BTW, did you have any plans to figure out wxPython4?

--
Yaakov

Re: dash vs. bash inconsistency

2020-04-23 Thread Sasha Slijepcevic via Cygwin

On 3/28/2020, Thomas Wolff wrote:

> Am 28.03.2020 um 02:09 schrieb Sasha Slijepcevic via Cygwin:
>> I am using Cygwin 3.1.4-1, bash 4.4.12-3 and dash 0.5.9.1-1.
>>
>> I have a setup.exe in the root of my Cygwin installation, C:\cygwin64, for 
>> example.
>> If I set PATH=C:\cygwin64;C:\cygwin64\bin, I can run setup.exe from bash.
>>
>> C:\>set PATH=C:\cygwin64;C:\cygwin64\bin
>>
>> C:\>bash
>> $ echo $PATH
>> /:/usr/bin
>> $ setup-x86_64.exe  --version
>> Cygwin setup 2.903
>>
>> However, in dash:
>> C:\>dash
>> $ echo $PATH
>> /:/usr/bin
>> $ setup-x86-64.exe --version
>> dash: 2: setup-x86-64.exe: not found
>>
>> Am I misusing Cygwin trying to run executables from the top of the 
>> installation? Is it expected to all shells would behave the
>> same?

> Do you happen to have placed a copy of dash into your assumed root, 
> C:\cygwin64\dash.exe?

No, there is no a copy of dash in the root, only in C:\cygwin64\bin.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Problems with ssh when I log into my PC using my corporate domain while working from home


On 4/23/2020 5:51 AM, Marco Atzeri via Cygwin wrote:

Am 23.04.2020 um 13:54 schrieb Mark Hansen:

On 4/21/2020 2:52 PM, Mark Hansen wrote:

On 4/21/2020 8:33 AM, Mark Hansen wrote:
I have a Windows 10 laptop, on which I installed Cygwin. I always log 
into the machine using
my corporate domain account. When I log into the machine from my 
office, everything Cygwin

works fine.

When I log into my laptop from home (which I'm working from home for 
a while now, due to
COVID-19), I still log in using my corporate domain account, but 
Cygwin acts differently.


Here is my user id (from the id command) when I log in from the office:

uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.

The actual problem I'm having is that Cygwin tools like ssh, git, 
etc. can't find my .ssh

directory. They are looking in "/" rather than my home directory.

I tried copying my .ssh directory from my home to "/" and although it 
was created, the

files have the wrong permissions and I'm unable to change them.

Is there something I can tweak to get Cygwin to understand which user 
I am so the ssh

stuff can start working again?

Thanks for any help.



To answer a question posed by someone to my private e-mail:

I didn't have the HOME environment variable set at first. When the PC 
is at my office,
Cygwin worked fine. When I took the PC home and logged in there, I had 
severe Cygwin
issues - I wasn't able to open a Cygwin Terminal or an XTerm terminal 
- it seemed it

didn't know where my HOME directory was.

As a result, I set my HOME directory in the environment settings for 
my user. Once I
did that, I was able to use the Cygwin Terminal and XTerm terminals 
again.


The only thing that is still not working (as far as I can see) is any 
ssh client which

needs to find the .ssh directory (like ssh or git, etc.).



Assuming Cygwin doesn't know about my user (when the PC is at home) - is 
there something

I can run to reset what Cygwin thinks is the user?

Otherwise, I'll try reinstalling Cygwin and see if that helps.

--


check the differences in outputs for

  "mkpasswd -c" and "id"

in the two cases.





I have the differences for 'id' in the two cases. However, I currently don't 
have access to
my office during the 'stay at home' order we're having to honor these days.

I don't understand the difference in the 'id' output, but they are different. I 
showed
the first little bit of each in my first message. Does this help? Should I 
attach the
complete output of the two runs here?


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

Re: [ITA] python2-wx and related packages for wxPython and wxwidgets

2020-04-23 Thread Hamish McIntyre-Bhatty via Cygwin-apps

On Thu, 2020-04-23 at 15:02 +0100, Hamish McIntyre-Bhatty wrote:
> I've gotten a more stable build of wxPython 3.0.2 and wxWidgets 3.0.4 to
> build now. wxPython is now also built against the version of wxWidgets
> that is installed on the system, avoiding ABI mismatch warnings and
> strange behaviour/freezes hat I was experiencing before.

I'm going to recommend nacking this in its current form.

> The test packages can be downloaded from
> https://hamishmb.com/files/cygwin-temp/.
> 
> I say "various other packages", because building wxPython also builds
> the following packages:
> 
> libwx_baseu3.0_0, libwx_gtk3u3.0-devel,  python-wxversion,
> libwx_baseu3.0-devel,  python2-wx, libwx_gtk2u3.0_0, python2-wxversion,
> libwx_gtk2u3.0-devel,  python-wx3.0, wxWidgets3.0-debuginfo,
> libwx_gtk3u3.0_0, python-wx-tools
> 
> The build process is a bit strange because wxPython 3.0.2 ships with
> wxWidgets 3.0.2 instead of the system version (3.0.4), so my build
> script downloads and re-patches the wxWidgets source before proceeding
> with the build. As a result of using wxWidgets 3.0.4 instead of 3.0.2,
> many patches are no longer needed as they were included upstream.
> Removed patches and the reason for removal are listed at the end of this
> email. I've probably got some of this wrong, but it does seem to work
> well at least :)

I do not recommend building both the C++ libraries and Python bindings
from the same source package, for several reasons:

* Python bindings need to be updated/rebuilt with each new version of
Python, which occurs much more frequently than updated versions of
wxWidgets.  Keeping them separate minimizes the rebuild times.

* wxPython and wxWidgets versions don't always match, as you mentioned
above.  Building them separately avoids jumping through those sort of
hoops.

* wxPython 3 is obsolete anyway, with current support only for version
4 (which is still for wxWidgets 3), so this scheme won't carry forward
anyway.

Since the standalone wxWidgets3.0 package is already at 3.0.4, all you
may want to do is revbump and rebuild python-wx.

> Patches removed and the reasons why:
> 
> http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-abicheck.patch
> - No longer needed as we're now using the same ABI for runtime and build
> versions.

Do NOT drop this patch.  You might be aligned now, but as soon as
gcc/libstdc++ get updated, the mismatch will reoccur, and programs will
unnecessarily fail again.

[snip]
> The few remaining wxGTK* patches:
> - No longer apply without error and don't seem to be needed with the
> newer wxwidgets version.

Patches were added for a reason; if you don't understand what they do
and why they're there, then you should be asking why rather than
dismissing them.  In the case of Gentoo's collision patch, this is
needed to support parallel installations of X.Y versions of wxWidgets. 
The updated patch is named wxGTK-3.0.5-collision.patch.

--
Yaakov

Re: ssh-pageant

2020-04-23 Thread Thomas Wolff


Am 23.04.2020 um 15:50 schrieb Chris Rodgers:

Hi,

I find the ssh-pageant package helpful to enable cygwin ssh to 
interact seamlessly with PuTTY's Pageant SSH agent. One small issue is 
that after installing, one has to add the lines:


|# ssh-pageant eval $(/usr/bin/ssh-pageant -r -a 
"/tmp/.ssh-pageant-$USERNAME")|
(see https://github.com/cuviper/ssh-pageant) 
to .bashrc for each user.


Would it be acceptable to update the ssh-pageant package to add a file 
/etc/profile.d/ssh-pageant.sh that does this automatically?
Does what? Add something to other users' profiles? Sounds like MS-style 
patronizing of user preferences. Certainly not appreciated by most 
people. Also, why should most cygwin users want to use ssh via putty? 
Mintty + ssh is a seamless modular solution.




Or is there another preferred way to do this, e.g. a postinstall script?

I'd be happy to draft a script file for review.

Thanks,

Chris.

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


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

[ITA] python2-wx and related packages for wxPython and wxwidgets

Hi all,

I've gotten a more stable build of wxPython 3.0.2 and wxWidgets 3.0.4 to
build now. wxPython is now also built against the version of wxWidgets
that is installed on the system, avoiding ABI mismatch warnings and
strange behaviour/freezes hat I was experiencing before.

The test packages can be downloaded from
https://hamishmb.com/files/cygwin-temp/.

I say "various other packages", because building wxPython also builds
the following packages:

libwx_baseu3.0_0, libwx_gtk3u3.0-devel, python-wxversion,
libwx_baseu3.0-devel, python2-wx, libwx_gtk2u3.0_0, python2-wxversion,
libwx_gtk2u3.0-devel, python-wx3.0, wxWidgets3.0-debuginfo,
libwx_gtk3u3.0_0, python-wx-tools

The build process is a bit strange because wxPython 3.0.2 ships with
wxWidgets 3.0.2 instead of the system version (3.0.4), so my build
script downloads and re-patches the wxWidgets source before proceeding
with the build. As a result of using wxWidgets 3.0.4 instead of 3.0.2,
many patches are no longer needed as they were included upstream.
Removed patches and the reason for removal are listed at the end of this
email. I've probably got some of this wrong, but it does seem to work
well at least :)

I eagerly await feedback - I'm sure there's some stuff I could improve
in this packaging, and I'm excited to soon be maintaining some Cygwin
packages.

Patches removed and the reasons why:

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-abicheck.patch
- No longer needed as we're now using the same ABI for runtime and build
versions.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-upstreamfixes.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-getbestsize.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-media-docs.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-size-alloc-fix.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-font-enumerator-stop.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-init-from-font.patch:
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-gtk-show-uri1.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-draw-elliptic-arc-crash.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-fix-percent-dnd2.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-scrolwin-sizing-loop.patch
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-background-color.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-paint-clipping-region.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-wxpgchoicesdata-protected-destructor.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-check-radio-button-rendering.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

http://pkgs.fedoraproject.org/cgit/rpms/wxGTK3.git/plain/wxGTK3-3.0.2-blank-menubar-toolbar.patch?h=f25
- No longer needed in new wxwidgets source - already applied.

The few remaining wxGTK* patches:
- No longer apply without error and don't seem to be needed with the
newer wxwidgets version.

Hamish McIntyre-Bhatty

0x87B761FE07F548D6.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature

ssh-pageant


Hi,

I find the ssh-pageant package helpful to enable cygwin ssh to interact 
seamlessly with PuTTY's Pageant SSH agent. One small issue is that after 
installing, one has to add the lines:


|# ssh-pageant eval $(/usr/bin/ssh-pageant -r -a 
"/tmp/.ssh-pageant-$USERNAME")|
(see https://github.com/cuviper/ssh-pageant) 
to .bashrc for each user.


Would it be acceptable to update the ssh-pageant package to add a file 
/etc/profile.d/ssh-pageant.sh that does this automatically?


Or is there another preferred way to do this, e.g. a postinstall script?

I'd be happy to draft a script file for review.

Thanks,

Chris.

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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home

2020-04-23 Thread Marco Atzeri via Cygwin


Am 23.04.2020 um 13:54 schrieb Mark Hansen:

On 4/21/2020 2:52 PM, Mark Hansen wrote:

On 4/21/2020 8:33 AM, Mark Hansen wrote:
I have a Windows 10 laptop, on which I installed Cygwin. I always log 
into the machine using
my corporate domain account. When I log into the machine from my 
office, everything Cygwin

works fine.

When I log into my laptop from home (which I'm working from home for 
a while now, due to
COVID-19), I still log in using my corporate domain account, but 
Cygwin acts differently.


Here is my user id (from the id command) when I log in from the office:

uid=1293438(Mark.Hansen) gid=1049089(Domain Users) ...

Here is the same when I've logged in with the machine at home:

uid=1293438(MAN+User(244862)) gid=1293438

(MAN) is the domain.

The actual problem I'm having is that Cygwin tools like ssh, git, 
etc. can't find my .ssh

directory. They are looking in "/" rather than my home directory.

I tried copying my .ssh directory from my home to "/" and although it 
was created, the

files have the wrong permissions and I'm unable to change them.

Is there something I can tweak to get Cygwin to understand which user 
I am so the ssh

stuff can start working again?

Thanks for any help.



To answer a question posed by someone to my private e-mail:

I didn't have the HOME environment variable set at first. When the PC 
is at my office,
Cygwin worked fine. When I took the PC home and logged in there, I had 
severe Cygwin
issues - I wasn't able to open a Cygwin Terminal or an XTerm terminal 
- it seemed it

didn't know where my HOME directory was.

As a result, I set my HOME directory in the environment settings for 
my user. Once I
did that, I was able to use the Cygwin Terminal and XTerm terminals 
again.


The only thing that is still not working (as far as I can see) is any 
ssh client which

needs to find the .ssh directory (like ssh or git, etc.).



Assuming Cygwin doesn't know about my user (when the PC is at home) - is 
there something

I can run to reset what Cygwin thinks is the user?

Otherwise, I'll try reinstalling Cygwin and see if that helps.

--


check the differences in outputs for

"mkpasswd -c" and "id"

in the two cases.



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

Re: Problems with ssh when I log into my PC using my corporate domain while working from home