Re: native symlinks and non-existent targets

2024-04-29 Thread Lee via Cygwin
On Mon, Apr 29, 2024 at 4:11 PM Csaba Ráduly wrote:
>
> On 25/04/2024 15:15, Jon Turney via Cygwin wrote:
> > On 24/04/2024 23:36, Christopher Layne via Cygwin wrote:
> > [...]
> >> If it isn't true then this seems trivial to fix.
> >
> > This assertion is trivially disproven by the lack of a patch attached. :)
> >
> >
> I don't think this is worth a gold star, but a jester's cap is surely
> warranted :)

I disagree.
  "This assertion is trivially disproven by the lack of a patch attached."
is totally worth a gold star

Regards,
Lee

-- 
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: Change for the initial installation of Cygwin to set the default terminal terminal 256 color

2024-04-12 Thread Lee via Cygwin
On Fri, Apr 12, 2024 at 4:05 AM J M  wrote:
>
> Some examples that I view that can do Cygwin better by default:
>
> tput colors
> 8
>
> echo $TERM
> xterm

I made my mintty changes by point & click experimentation - if you
want to make system-wide changes the place to do that is in
/etc/minttyrc
  https://github.com/mintty/mintty/wiki/Tips
  Configuring mintty
  For its configuration, it reads configuration files in this order:
  /etc/minttyrc
  ... etc.

$ grep -i term .minttyrc
Term=xterm-256color

$ tput colors
256

$ echo $TERM
xterm-256color


> And if use vim, comparing with one Ubuntu terminal:
>
> I need to set "set mouse-=a" because the copy paste is difficult.
> The colors are very bright.
> The cursor does not look good when doing a search and moves over the yellow
> background text.
>
> What settings would I need to make it look like Ubuntu's vim?

I'd suggest doing a 'man vim' to find out where all the possible
configuration files are & then copy them to your cygwin machine.

Regards,
Lee

> El jue., 11 abr. 2024 14:36, J M  escribió:
>
> > Hi,
> >
> > You can change in the initial install setup of Cygwin to set the default
> > terminal to 256 color as Ubuntu does?

-- 
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: Cygwin a bit slow

2024-04-06 Thread Lee via Cygwin
On Fri, Apr 5, 2024 at 11:18 AM J M  wrote:
>
> Hi,
>
> I'm seeing that Cygwin is a bit slow, directly and after comparing to
> simple ubuntu virtual machines by example.
>
> Specifically:
>
> - Copy and paste texts in vim, I see clearly the slow in paste.

I don't know about the rest, but paste being slow is an old problem - eg:
Subject: speeding up a paste operation
To:  cygwin@cygwin.com
Date:Fri, Aug 24, 2018 at 7:30 PM

at least on my machine, there's a clear
winner for pasting in an absurdly large amount of text:

$ time d2u < /dev/clipboard > hosts-3.txt

real0m11.372s
user0m3.749s
sys 0m6.984s

$ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt

real0m4.405s
user0m0.124s
sys 0m3.577s

$ time getclip -u > hosts.txt

real0m0.734s
user0m0.031s
sys 0m0.031s

Regards,
Lee

-- 
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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu

2024-02-10 Thread Lee via Cygwin
On Fri, Feb 9, 2024 at 11:21 PM Yang Yu Lin via Cygwin wrote:
>
> It would be convenient for users to open specific folder in terminal by just 
> right-click it, like Git Bash and Windows Terminal.

search for the 'chere' package in setup

I use this .reg file:

C:\Installed>cat cygwinHere.reg
Windows Registry Editor Version 5.00

; add a Windows Explorer right-click option for folders to
;   Open Bash Shell Here

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\bashShell]
@="Open Bash Shell Here"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\bashShell\command]
@="C:\\Windows\\system32\\cmd.exe /c \"pushd %L && set
CHERE_INVOKING=1 && c:\\cygwin\\bin\\bash.exe --login -i\""

; @="C:\Windows\system32\cmd.exe /c \"pushd %L && set CHERE_INVOKING=1
&& c:\cygwin\bin\mintty.exe - \""
; which has the annoying flash of the DOS cmd window opening & closing
before the mintty window opens

C:\Installed>

> Note: I hope this change would work on Windows 11 right-click menu. (Because 
> I don't like "Show more options" or Shift + Right-click)

I'm still on Windows 10; I have no idea what does/doesn't work on Windows 11

Regards,
Lee

-- 
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: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 2:45 PM gs-cygwin wrote:
>
> On Wed, Dec 20, 2023 at 02:23:49PM -0500, Lee via Cygwin wrote:
> > If anyone has access to a redhat linux system, do they 'alias vi=vim'
> > or put vi under /etc/alternatives?
>
> FYI: neither.

Wow!  I would have never guessed 'wrapper script'
Thank you!

Lee


>
> $ cat /etc/fedora-release
> Fedora release 39 (Thirty Nine)
>
> $ cat /usr/bin/vi
> #!/usr/bin/sh
>
> # run vim if:
> # - 'vi' command is used and 'vim' binary is available
> # - 'vim' command is used
> # NOTE: Set up a local alias if you want vim -> vi functionality. We will not
> # do it globally, because it messes up with available startup options (see
> # ':help starting', 'vi' is not capable of '-d'). The introducing an 
> environment
> # variable, which an user must set to get the feature, will do the same trick
> # as setting an alias (needs user input, does not work with sudo), so it is 
> left
> # on user whether he decides to use an alias:
> #
> # alias vim=vi
> #
> # in bashrc file.
>
> if test -f /usr/bin/vim
> then
>   exec /usr/bin/vim "$@"
> fi
>
> # run vi otherwise
> exec /usr/libexec/vi "$@"

-- 
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: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 2:44 PM Brian Inglis wrote:
>
> On 2023-12-20 12:30, matthew patton via Cygwin wrote:
> >> I'd say vi/vim needs to be put under /etc/alternatives
>
> > No, because that's system-wide.
> > Vi vs Vim is a personal choice. Also alternatives is for supporting multiple
> > versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin
> > and the other in /usr/local/bin just as an example. And the sysadmin 
> > choosing
> > (for whatever good reason) to preference the v9 software over the v8.
>
> Most of us run Cygwin on a device called a /Personal Computer/ that allows us 
> to
> make our own choices about OS, desktop UI, services, and configuration. ;^>
>
> How many of you run shared server or administered Cygwin desktop setups?

I have a normal user login with no privs and an administer login for
doing things like installing programs or updating the system.
I love Nancy Reagans' "Just Say No" to UAC prompts when I'm logged in
as a normal user :)

I suspect my wife has forgotten her password on this machine.

Lee

-- 
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: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 2:30 PM matthew patton  wrote:
>
>  > I'd say vi/vim needs to be put under /etc/alternatives
>
> No, because that's system-wide.

Which is what I want.

> Vi vs Vim is a personal choice.

Which I've made :)
Anyone that doesn't like that decision can make their own work-around,
but me with my normal and admin logins wants 'vi' to always behave the
same way.
I kinda doubt my wife would notice.. except maybe if syntax
hilighting/coloring broke

> Also alternatives is for supporting multiple versions. Say v8.02 versus v9.1 
> of 'vim' on a system, one being in /usr/bin and the other in /usr/local/bin 
> just as an example. And the sysadmin choosing (for whatever good reason) to 
> preference the v9 software over the v8.

man alternatives
NAME
   alternatives - maintain symbolic links determining default commands

It allows picking among multiple versions but it also allows picking
between different programs.

Regards,
Lee

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


Re: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 2:24 PM Ken Brown via Cygwin  wrote:
>
> On 12/20/2023 1:34 PM, Lee via Cygwin wrote:
> > On Wed, Dec 20, 2023 at 9:01 AM marco atzeri  wrote:
> >>
> >> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
> >>>
> >>> On 20/12/2023 03:47, Beau James via Cygwin wrote:
> >>>> This problem appeared with my most recent Cygwin update that included an
> >>>> update to "vim".
> >>>
> >>> vi is usually an alias to vim
> >>>
> >>> $ alias | grep vi
> >>>
> >>>alias vi='vim'
> >>>
> >>> so you are in reality calling vim
> >>>
> >>> $ which vim
> >>> /usr/bin/vim
> >>>
> >>>
> >>> I am investigating the /usr/bin/vi issue
> >>>
> >>
> >> -2 version should have solved the issue
> >
> > I don't get any error or warning messages now but 'vi' still doesn't
> > always get me the same thing:
> >
> > $ vi --version | head -5
> > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02)
> > Included patches: 1-2155
> > Modified by 
> > Compiled by 
> > Huge version without GUI.  Features included (+) or not (-):
> >
> > $ /bin/sh
> >
> > $ vi --version | head -5
> > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22)
> > Included patches: 1-2155
> > Modified by 
> > Compiled by 
> > Tiny version without GUI.  Features included (+) or not (-):
>
> Your second shell is not a login shell.  Could that be the problem?

You need to define "problem" first :)

I want "vi" to always call "vim" .. hrmm.. unless I've explicitly done
something to explicitly over-ride that.

So anytime I type in 'vi' and don't get the VIM Huge version without
GUI I'd say that's a problem.

I've got "export EDITOR=vi" in my .bash_profile, so anytime $EDITOR is
called I want the huge version of vim.
If that doesn't happen I'd say that is a problem.

If I'm in a bash sheel & do /bin/sh I expect typing in 'vi' will get
me the same results as when I was in bash
Same deal with dash -- I still want my expected version of vim to run

So ... a very long way of saying No, I don't think the second shell
not being a login shell is 'the problem.'
My experience is that Debian always does the right thing wrt vi/vim.
Cygwin does not.  It'd be interesting to know if redhat linux uses
alternatives or an alias to decide which vi/vim gets called.

Regards,
Lee

-- 
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: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 1:57 PM matthew patton wrote:
>
> > Would you please let me know how to make an /etc/alternatives for vi/vim?
>
> did you install the alternatives package?

I installed cygwin back in 2017; I don't remember what all I've
installed but it seems to be there:
$ ls -l /usr/sbin/alt*
-rwxr-xr-x 1 root None 20499 Apr  4  2013 /usr/sbin/alternatives.exe

> I just use aliases (actually I set EDITOR=xxx) after I enumerate the editors 
> I consider worthy of inclusion and resident.

That's my current work-around

# set the bash prompt
#   "$SHLVL" = 1 is true for the 1st shell, and incremented
#   each time another instance of bash is started.  eg
# vi /tmp/foo
# :sh
#   and you're in a new shell so SHLVL was incremented
#
if [  "$SHLVL" = 1 ]; then
PS1='\[\e]2;\u@\h  \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
else
PS1='\[\e]2;\u@\h  \w\a\]\n\u@\h \w\n\$ '
alias vi=vim
fi

> What DOES need nuking is the forced alias in /etc/profile.d. That's 
> inexcusable interference in the system.

I'd say vi/vim needs to be put under /etc/alternatives
If anyone has access to a redhat linux system, do they 'alias vi=vim'
or put vi under /etc/alternatives?

Debian uses alternatives:
$ update-alternatives --query vi
Name: vi
Link: /usr/bin/vi
Slaves:
 vi.1.gz /usr/share/man/man1/vi.1.gz
 vi.da.1.gz /usr/share/man/da/man1/vi.1.gz
 vi.de.1.gz /usr/share/man/de/man1/vi.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vi.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vi.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vi.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vi.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vi.1.gz
Status: auto
Best: /usr/bin/vim.basic
Value: /usr/bin/vim.basic

Alternative: /usr/bin/vim.basic
Priority: 30
Slaves:
 vi.1.gz /usr/share/man/man1/vim.1.gz
 vi.da.1.gz /usr/share/man/da/man1/vim.1.gz
 vi.de.1.gz /usr/share/man/de/man1/vim.1.gz
 vi.fr.1.gz /usr/share/man/fr/man1/vim.1.gz
 vi.it.1.gz /usr/share/man/it/man1/vim.1.gz
 vi.ja.1.gz /usr/share/man/ja/man1/vim.1.gz
 vi.pl.1.gz /usr/share/man/pl/man1/vim.1.gz
 vi.ru.1.gz /usr/share/man/ru/man1/vim.1.gz

$ update-alternatives --query vim
Name: vim
Link: /usr/bin/vim
Status: auto
Best: /usr/bin/vim.basic
Value: /usr/bin/vim.basic

Alternative: /usr/bin/vim.basic
Priority: 30

Regards,
Lee

-- 
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: vim: errors launching "/usr/bin/vi

2023-12-20 Thread Lee via Cygwin
On Wed, Dec 20, 2023 at 9:01 AM marco atzeri  wrote:
>
> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote:
> >
> > On 20/12/2023 03:47, Beau James via Cygwin wrote:
> > > This problem appeared with my most recent Cygwin update that included an
> > > update to "vim".
> >
> > vi is usually an alias to vim
> >
> > $ alias | grep vi
> >
> >   alias vi='vim'
> >
> > so you are in reality calling vim
> >
> > $ which vim
> > /usr/bin/vim
> >
> >
> > I am investigating the /usr/bin/vi issue
> >
>
> -2 version should have solved the issue

I don't get any error or warning messages now but 'vi' still doesn't
always get me the same thing:

$ vi --version | head -5
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02)
Included patches: 1-2155
Modified by 
Compiled by 
Huge version without GUI.  Features included (+) or not (-):

$ /bin/sh

$ vi --version | head -5
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22)
Included patches: 1-2155
Modified by 
Compiled by 
Tiny version without GUI.  Features included (+) or not (-):



Would you please let me know how to make an /etc/alternatives for vi/vim?
I want 'vi' to always invoke 'vim' and everything I tried with
alternatives failed :(

Thanks
Lee

-- 
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: /usr/bin/vi: errors parsing .vim files from vim-common package

2023-12-18 Thread Lee via Cygwin
tl,dr:  Did vi/vim change from /etc/alternatives to an alias?

$ ls -l $(which vi) $(which vim)
-rwxr-xr-x 1 root Administrators 1507859 Dec 12 09:07 /usr/bin/vi.exe
-rwxr-xr-x 1 root Administrators 3565587 Dec 12 09:07 /usr/bin/vim.exe

$ alias vi
alias vi='vim'


On Sat, Dec 16, 2023 at 3:11 PM John Hein wrote:
>
> I just updated vim packages (including vim-minimal and vim-common) to 
> 9.0.2155-1

I've got the same version installed
$ grep '^vi' cygcheck-srv_2023-12-17.txt
vim 9.0.2155-1OK
vim-common  9.0.2155-1OK
vim-minimal 9.0.2155-1OK

> Now when I run 'vi', I get this:
>
> Error detected while processing /usr/share/vim/vim90/filetype.vim:
> line   11:
  <.. snip ..>
> and so on.

I can duplicate the problem by

cd /tmp
touch f1 f2
vi f1
:sh
vi f2

 ... and I get the same thing:
Error detected while processing /usr/share/vim/vim90/filetype.vim:
line   11:
E319: Sorry, the command is not available in this version: let
did_load_filetypes = 1
line   14:
  ... etc.


Tracking down bash startup processing is not my thing, so I could be wrong but

/etc/profile has this bit:
for file in /etc/profile.d/*.$1; do
  [ -e "${file}" ] && . "${file}"
done

and /etc/profile.d/vim.sh has this bit:
if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ]; then
  # for bash and zsh, only if no alias is already set
  alias vi >/dev/null 2>&1 || alias vi=vim
fi

So I end up with
$ alias | grep ' vi'
alias vi='vim'

and vi works in the shell but gives all those errors in a sub shell - eg
vi /tmp/f1
   no error messages
bash
vi /tmp/f1
   lots of error messages

Regards,
Lee

-- 
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: Cygwin 3.4.9 - how to install ssh-keygen

2023-11-21 Thread Lee via Cygwin
On Tue, Nov 21, 2023 at 2:07 PM Hans-Bernhard Bröker wrote:
>
> I  can't see a command like
>
> cygcheck -p ssh-keygen
>
> as noticeably more cumbersome than comparable commands of other
> distributions

But you _can_ see/realize the implications of that command :)
I did a 'man cygcheck' before posting my reply, but somehow didn't notice

 -p, --package-query  search for REGEXP in the entire
cygwin.com package
  repository (requires internet connectivity)

which, in hindsight, seems really obvious but somehow I did miss it so
thanks for pointing it out!

Regards,
Lee


>
> Lee via Cygwin  schrieb am Mo., 20. Nov. 2023, 23:42:
>
> > On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote:
> > >
> > > Dear all,
> > >
> > > I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10.
> > > After installing defaults plus openssh 9.5p 1-1, I open the
> > Cygwin64-Terminal as Administrator and
> > > run ssh-host-config.
> > >  * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config
> > >  * Answered "no" to use StrictMode
> > >  * and "yes" to install sshd as a service
> > >  * I just press  for the question for "Value of CYGWIN for the
> > daemon".
> > > cygrunsrv -S cygsshd will not start the sshd. The logfile say "no
> > hostkeys available".
> > >
> > > Unfortunately  I can't find ssh-keygen in the installable packages.
> > > Howto install ssh-keygen or how to create hostkeys?
> >
> > The easy way to see if it's already installed
> >   $ which ssh-keygen
> >   /usr/bin/ssh-keygen
> >
> > If no, Cygwin is a bit of a pain when looking for a program that's
> > included in another package.
> >
> > There's probably a better way, but I use the cygwin package search - eg:
> >   https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen
> > and then take a guess as the most likely candidate in the results list
> > and click on that link to see if it's included in that package - eg
> >
> > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen
> >
> >
> > Regards
> > Lee

-- 
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: Please support download setup-x86_64.exe on IPv6-only network

2023-11-21 Thread Lee via Cygwin
On Tue, Nov 21, 2023 at 12:35 AM Brian Inglis wrote:
>
> On 2023-11-20 17:45, Lee via Cygwin wrote:
> > On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote:
> >>
> >> On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote:
> >>> The whole IP v4 internet is available as a compatibility subnet 
> >>> :::0:a.b.c.d
> >>> on IP v6, so there is no excuse for not supporting interconnection, as it 
> >>> will
> >>> be required until the last backbone routers drop IP v4 support.
> >>
> >> Just a small correction for the mail archives as this appears solved.
> >> The correct IPV6 address for the IPV4 address range is
> >> :::a.b.c.d  (no '0')
> >
> > If you're going for correcting the record, let's make it correct.
> > :::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over
> > the Internet.
> >
> > from:  https://www.rfc-editor.org/rfc/rfc5156
> >
> > 2.2.  IPv4-Mapped Addresses
> >
> > :::0:0/96 are the IPv4-mapped addresses [RFC4291].  Addresses
> > within this block should not appear on the public Internet.
>
> These internal addresses are used by dual stack hosts to allow clients or
> servers to handle connections to IPv4 hosts the same as IPv6 hosts.

I think that at best you're terribly confused, but let's play this out.

> Whereas :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without
> assigned IPv4 addresses to connect to IPv4 only hosts via SIIT see:
>
> https://www.rfc-editor.org/rfc/rfc7915 Stateless IP/ICMP Translation.

I did see RFC 7915.  I searched for '' and there were no matches.

You need something else to back up your claim that
  :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without
  assigned IPv4 addresses to connect to IPv4 only hosts.

And please explain how an ipv6 host is going to get a packet with a
0::/8 address delivered across the internet.

see:  
https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

An ipv6 prefix of 2000::/3 is defined as Global Unicast.  In other
words, an ipv6 unicast address MUST start off with 2000::/3 to be
routed across the Internet.

And look at footnotes 3 and 4
:::0:0/96 reserved for IPv4-mapped Address [RFC4291].
0::/96 deprecated by [RFC4291]. Formerly defined as the
"IPv4-compatible IPv6 address" prefix.

Nothing about :::0:0:0/96

Regards,
Lee

-- 
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: Please support download setup-x86_64.exe on IPv6-only network

2023-11-20 Thread Lee via Cygwin
On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote:
>
> On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote:
> > The whole IP v4 internet is available as a compatibility subnet 
> > :::0:a.b.c.d
> > on IP v6, so there is no excuse for not supporting interconnection, as it 
> > will
> > be required until the last backbone routers drop IP v4 support.
>
> Just a small correction for the mail archives as this appears solved.
> The correct IPV6 address for the IPV4 address range is
> :::a.b.c.d  (no '0')

If you're going for correcting the record, let's make it correct.
:::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over
the Internet.

from:  https://www.rfc-editor.org/rfc/rfc5156

2.2.  IPv4-Mapped Addresses

   :::0:0/96 are the IPv4-mapped addresses [RFC4291].  Addresses
   within this block should not appear on the public Internet.


Regards,
Lee

-- 
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: Please support download setup-x86_64.exe on IPv6-only network

2023-11-20 Thread Lee via Cygwin
On Mon, Nov 20, 2023 at 8:55 AM Jon Turney wrote:
>
> On 16/11/2023 01:40, Bin W via Cygwin wrote:
> > https://www.cygwin.com/setup-x86_64.exe
> > IPv6-only network can't download the installer.
>
> I've spoken to the people who speak to the people who actually
> administer the DNS for us, and an IPv6 DNS record has been added for
> cygwin.com.

Thank you!!

As admin:
  ipconfig /release
so the only IPv4 address I've got is a 169.254.x.x address and I can
- open https://cygwin.com/
- download and run https://cygwin.com/setup-x86_64.exe
- get the current package info and update an already installed package

Regards,
Lee

-- 
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: Cygwin 3.4.9 - how to install ssh-keygen

2023-11-20 Thread Lee via Cygwin
On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote:
>
> Dear all,
>
> I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10.
> After installing defaults plus openssh 9.5p 1-1, I open the Cygwin64-Terminal 
> as Administrator and
> run ssh-host-config.
>  * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config
>  * Answered "no" to use StrictMode
>  * and "yes" to install sshd as a service
>  * I just press  for the question for "Value of CYGWIN for the daemon".
> cygrunsrv -S cygsshd will not start the sshd. The logfile say "no hostkeys 
> available".
>
> Unfortunately  I can't find ssh-keygen in the installable packages.
> Howto install ssh-keygen or how to create hostkeys?

The easy way to see if it's already installed
  $ which ssh-keygen
  /usr/bin/ssh-keygen

If no, Cygwin is a bit of a pain when looking for a program that's
included in another package.

There's probably a better way, but I use the cygwin package search - eg:
  https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen
and then take a guess as the most likely candidate in the results list
and click on that link to see if it's included in that package - eg
  
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen


Regards
Lee

-- 
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: Difference between cygwin versions

2023-08-28 Thread Lee via Cygwin
On 8/28/23, Cary Lewis via Cygwin  wrote:

> On one machine I have cygwin version  3.1.7(0.340/5/3), I can copy cygwin
> binaries and the corresponding dlls to a folder and then run the cygwin
> programs without any problems.
>
> But on another machine I have a newer cygwin,  3.4.7-1.x86_64, and when I
> do the same thing, the programs do not work:
>
> e.g.
>
> mkdir /tmp/test
> cd /tmp/test
> $ ls -1
> bash.exe
> chroot.exe
> cygiconv-2.dll
> cygintl-8.dll
> cygncursesw-10.dll
> cygreadline7.dll
> cygwin1.dll
>
> I copied all of bash's required dlls to /tmp/test
>
> When I do a ./bash, it exits immediately on 3.4.7, but on 3.1.7 it works
> correctly.

*forward slash* ??  That doesn't work for me, but .\bash does

$ uname -a
CYGWIN_NT-10.0-19044 i3668 3.4.7-1.x86_64 2023-06-16 14:04 UTC x86_64 Cygwin

works for me:

C:\Temp\test>dir
 Directory of C:\Temp\test

08/28/2023  10:04 AM  .
08/28/2023  10:04 AM  ..
08/28/2023  09:59 AM   854,035 bash.exe
08/28/2023  10:04 AM43,539 chroot.exe
08/28/2023  10:00 AM 1,088,019 cygiconv-2.dll
08/28/2023  10:00 AM   108,563 cygintl-8.dll
08/28/2023  10:01 AM   334,867 cygncursesw-10.dll
08/28/2023  10:00 AM   262,675 cygreadline7.dll
08/28/2023  09:59 AM 2,952,245 cygwin1.dll

C:\Temp\test>.\bash.exe
bash.exe: warning: could not find /tmp, please create!
bash-5.2$ uname
windows32
bash-5.2$ exit
exit

Regards,
Lee

-- 
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: Entering Cygwin command line (bash login) from Windows cmd.exe ?

2023-08-07 Thread Lee via Cygwin
On 8/7/23, Roland Mainz via Cygwin  wrote:
> On Sat, Jul 29, 2023 at 6:18 AM Roland Mainz  wrote:
>> Is there an official way to enter the Cygwin command line (e.g. bash
>> login) from Windows cmd.exe, e.g. if someone ssh's into a Windows
>> machine he/she ends/up in a cmd.exe and not bash...
>
> ping!

Years ago this was the default way to start cygwin (I don't think I've
changed it, but who knows??)

C:\cygwin>type Cygwin.bat
@echo off

C:
chdir C:\cygwin\bin

bash --login -i


There's a Cygwin.bat in /etc/defaults that needs to be copied to the
cygwin root directory:

C:\cygwin>type etc\defaults\Cygwin.bat
@echo off
setlocal enableextensions
set TERM=
cd /d "%~dp0bin" && .\bash --login -i

C:\cygwin>

"cd /d" - Use the /D switch to change current drive in addition to
changing current directory for a drive.

"%~dp0" gives the path of the script, so if the .bat file is in
C:\cygwin then "%~dp0bin" expands to C:\cygwin\bin

Regards
Lee

-- 
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: [EXTERNAL] dig and host don't work in IPv6

2023-07-31 Thread Lee via Cygwin
On 7/29/23, Andrew Schulman via Cygwin  wrote:
>> Sorry...  Did you try using the -d option to see what DNS servers these
>> commands try to actually connect to (and time out, eventually).
>
> No help unfortunately.
>
> $ host -d6 cygwin.com
> Trying "cygwin.com"
> ;; connection timed out; no servers could be reached

Have you tried the windows version of bind from isc.org?

I don't remember when ISC dropped (will drop?) support for windows,
but I've been using dig from the bind9.16.41 package for a while.  Not
that I use it all that much, but it works for me.. or at  least dig
does.  named on windows has something funky going on that I never
figured out, so I'm running named on Debian.

Get it here
https://ftp.isc.org/isc/bind9/9.16.41/BIND9.16.41.x64.zip

unzip and put that directory in your path
$ which dig
/cygdrive/c/Temp/BIND/dig

and have fun!
$ dig @2600:x:x:x::x:x www.google.com  +short
2607:f8b0:4004:c09::67
2607:f8b0:4004:c09::69
2607:f8b0:4004:c09::93
2607:f8b0:4004:c09::63

Lee@i3668 ~
$ dig @2600:x:x:x::x:x www.google.com a +short
172.253.122.147
172.253.122.103
172.253.122.99
172.253.122.104
172.253.122.105
172.253.122.106

ipv6 address hidden to protect the guilty :)

... hrmmm ... I just tried your "host -d6 cygwin.com" and got
$ host -d6 cygwin.com
Trying "cygwin.com"
;; connection timed out; no servers could be reached

Do you have a firewall blocking outbound udp/tcp to port 53?  I do,
which is most probably why I get the timeout.  But this works:
$ host cygwin.com 2600:x:x:x::x:x
Using domain server:
Name: 2600:x:x:202::x:x
Address: 2600:x:x:202::x:x#53
Aliases:

cygwin.com has address 8.43.85.97
cygwin.com mail is handled by 10 sourceware.org.


Maybe try using whatever dig you already have installed and do
  ipconfig /all | grep "DNS Server"
and then
  dig @ cygwin.com

Regards,
Lee


>
>> (strace can help as well, I think.)
>
> Posted at https://pastebin.com/XWwxJ41b. I'm not able to make much sense of
> it,
> except that on line 1339, I waited almost 5 seconds for sendmsg:
>
> 4964291 6958349 [isc-worker] host 20999 cygwin_sendmsg: 28 =
> sendmsg(20,
> 0x7FFDFC830, 0x0)
>
> Thanks for taking a look. I'm looking at other options in resolv.conf, but
> haven't found anything useful.
>
> I can't find any documention of the osquery option. This answer[1] says
> "res_init() uses the Windows resolver if either /etc/resolv.conf does not
> exist,
> or /etc/resolv.conf contains options osquery." Doesn't help in this case
> though.
>
> Andrew
>
> [1]
> https://stackoverflow.com/questions/10523828/how-does-gcc-cygwin-get-the-dns-server
>
>
> --
> 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


cygcheck: Missing file:

2023-07-22 Thread Lee via Cygwin
I just noticed this
  Missing file: /etc/preremove/openssl.sh from package libssl1.1
  Missing file: /etc/preremove/openssl.sh from package libssl3
in the output of 'cygcheck -srv'?

Is there something I should do about it?

TIA,
Lee

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


OpenSSL: FATAL

2023-07-21 Thread Lee via Cygwin
I've been getting random
  OpenSSL: FATAL
  OPENSSL_Uplink(008A7C34,08): no OPENSSL_Applink
crashes in an app built using
  ./configure  --host=i686-w64-mingw32

https://www.openssl.org/docs/faq.html
has this bit under
  I’ve compiled a program under Windows and it crashes: why?

  As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL
.DLLs compiled with some specific run-time option [we insist on the
default /MD] can be deployed with application compiled with different
option or even different compiler. But there is a catch! Instead of
re-compiling OpenSSL toolkit, as you would have to with prior
versions, you have to compile small C snippet with compiler and/or
options of your choice. The snippet gets installed as
/include/openssl/applink.c and should be either added to
your application project or simply #include-d in one [and only one] of
your application source files. Failure to link this shim module into
your application manifests itself as fatal “no OPENSSL_Applink”
run-time error.


I'm statically linking the app, so it isn't pulling in any mingw
openssl DLLs, but adding a
  #include 
to one of the source files in the app does seem to fix the crashing.

So here's my questions:
1. Is including  really the fix for the no
OPENSSL_Applink crashes or am I just (un?)lucky that the app hasn't
crashed again in my very limited testing?

2. I have mingw64-i686-openssl 3.0.9-0.1 installed.  Assuming I do
need the new include now, is this going to be a permanent requirement
or might a later mingw64-i686-openssl fix ??something?? and I won't
need that include?

TIA
Lee

-- 
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: Noticeable delay in copy paste

2023-07-04 Thread Lee via Cygwin
On 7/4/23, ravi r via Cygwin  wrote:
> After two years of using an older version of cygwin, a week ago, I
>CYGWIN_NT-10.0-19045 version 3.4.7-1.x86_64
> (runneradmin@fv-az416-306) (gcc version 11.4.0 (GCC) ) 2023-06-16
> 14:04 UTC
> upgraded cygwin to the latest version.
>
> Ever since the upgrade, I see noticeable delay in copy pasting text
> from Chrome browser to 'vim' editor session
> running inside a xterm under fvwm.
>
> Need assistance on additional commands that I could  run to find the
> cause of this issue.

Maybe this will help
  https://cygwin.com/pipermail/cygwin/2018-August/238351.html

Regards,
Lee

-- 
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: [ITP] openh264 (2.3.1)

2023-02-06 Thread Lee via Cygwin-apps
On 2/6/23, Yaakov Selkowitz via Cygwin-apps  wrote:
> On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
>> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
>> > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
>> > > I would like to propose new package openh264, which is
>> > > a H264 video codec library. This is needed by ffmpeg
>> > > package I had proposed, and also provided for ffmpeg-free
>> > > package in fedora.
>> > >
>> > > I already prepared the package at the following location.
>> > >
>> > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
>>
>> > Unfortunately, this cannot be included in the Cygwin distribution.
>> > Cisco's
>> > patent license only covers binaries they distribute.  Fedora has a
>> > special
>> > arrangement with Cisco where they build their RPMs on Fedora
>> > infrastructure,
>> > but the packages are hosted by Cisco in a separate repository.
>>
>> http://www.openh264.org/
>> "Cisco has taken their H.264 implementation, and open sourced it under BSD
>>
>> license terms. Development and maintenance will be overseen by a board
>> from
>> industry and the open source community. Furthermore, we have provided a
>> binary
>> form suitable for inclusion in applications across a number of different
>> operating systems, and make this binary module available for download
>> from
>> the
>> Internet. We will not pass on our MPEG-LA licensing costs for this
>> module,
>> and
>> based on the current licensing environment, this will effectively make
>> H.264
>> free for use on supported platforms."
>
> This is exactly the point.  Cisco paid for a license, but that license is
> limited to binaries they distribute.

IANAL but it sure looks like redistribution is allowed:

cisco/openh264 is licensed under the
BSD 2-Clause "Simplified" License

  https://github.com/cisco/openh264/blob/master/LICENSE
<.. snip ..>
  Redistribution and use in source and binary forms, with or without
modification,
are permitted provided that the following conditions are met:

Lee


gcc -mno-cygwin

2023-01-07 Thread Lee via Cygwin
The "-mno-cygwin" gcc option went away years ago.  Correct?

It still shows up in the output of 'man gcc':

$ man gcc | grep mno-cygwin
   x86 Windows Options -mconsole  -mcygwin  -mno-cygwin  -mdll
-mnop-fun-dllimport  -mthread -municode  -mwin32

Is that a cygwin specific or a generic gcc man page oversight?

TIA,
Lee

-- 
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: Setting up toolchains

2021-09-27 Thread Lee via Cygwin
On 9/27/21, Anthony Webber wrote:
> Please excuse the naivety of this question, but I've looked elsewhere
> and can't find a good answer. Perhaps a good answer is to install MSYS2
> alongside Cygwin.

that seems to be the usual answer here :(

> Anyway, I am trying to set up my gcc toolchains in Cygwin, by which I
> mean that I'm trying to set up the environment so that the right
> programs are called at the right time by build systems like cmake and
> waf,

cmake supposedly supports cross-compilation.  I've never figured out
how to do it :(

> or if I want to build in a more manual fashion. Particularly, I
> want to be able to switch between toolchains easily.

GNU autoconf.  Switching between toolchains is as easy as

autoconf
autoheader
./configure  --host=i686-w64-mingw32


> I have installed both the x86_64-pc-cygwin-gcc/g++ and
> x86_64-w64-mingw32-gcc/g++ packages using setup-x86_64.exe.
>
> The first thing I notice is that the gcc/g++ programs in /bin are
> identical to  x86_64-pc-cygwin-gcc/g++, and that symbolic links aren't
> being used. I presume it's being done this way because this is
> considered the default, native Cygwin toolchain, and that there should
> be be relatively little to do in the way of configuration if I want to
> build Cygwin software.
>
> If I do want to cross-compile using x86_64-w64-mingw32-gcc/g++, then I
> imagine that the very least I should do is set a bunch of environment
> variables like CC and CXX (perhaps by sourcing a shell script), but
> really I'd like some advice here. What do you guys do?

I've never written anything that needed a make file; I just use the
correct compiler. eg

$ tail -3 getenv.c
}
/* i686-w64-mingw32-gcc -o getenv.exe getenv.c
 */

The only time I've had to use environment variables was for building mbedtls:

export WINDOWS_BUILD=1
#  build for a Windows platform

export SHARED=1
#  want the shared libraries created

export CC=i686-w64-mingw32-gcc
export LD=i686-w64-mingw32-gcc
export CFLAGS="-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2"
export LDFLAGS="${LDFLAGS} -fstack-protector-strong"

make lib
#  build the libraries

PATH="${PWD}/library:/usr/i686-w64-mingw32/sys-root/mingw/bin:${PATH}"
#  so the tests are able to find the mbedtls and mingw libraries

make check
#  run the test suite


Regards,
Lee

-- 
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: Incompatible clipboard format between 32bit and 64bit cygwin

2021-09-26 Thread Lee via Cygwin
On 9/26/21, Thomas Wolff wrote:
>
> Am 26.09.2021 um 20:37 schrieb Thomas Wolff:
>>
>> Am 26.09.2021 um 11:50 schrieb Mark Geisert:
>>> Hi Takashi,
>>>
>>> Takashi Yano via Cygwin wrote:
 I noticed that cygwin clipboard is not compatible
 between 32bit and 64bit cygwin.

 If I run 'echo  > /dev/clipboard' in 32bit cygwin,
 and run 'cat /dev/clipboard' in 64bit cygwin, this result in
 cat: /dev/clipboard: Bad address

 This is because the structure
 typedef struct
 {
timestruc_t   timestamp;
size_tlen;
char  data[1];
 } cygcb_t;
 defined in fhandler_clipboard.cc has different size.

 Is this the known issue?
>>>
>>> I doubt anybody has ever tried what you did.
>> I have and it failed; I just didn't find it important enough to report
>> it here... Thanks for the plan to fix it.
>>
>>> I have been testing getclip and putclip between 32- and 64-bit
>>> environments, but neglected to test Cygwin-internal clipboard format
>>> that prepends cygcb_t to the user-supplied data.
> As we're at it, what's the purpose of a cygwin-internal clipboard format
> at all?

speed?

Maybe I'm not understanding the question, but I put a question to this
list ~3 years ago about right-click/paste into a mintty window being
**really** slow and the answer was to use getclip:
$ time d2u < /dev/clipboard > hosts-3.txt

real0m11.372s
user0m3.749s
sys 0m6.984s

$ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt

real0m4.405s
user0m0.124s
sys 0m3.577s

$ time getclip -u > hosts.txt

real0m0.734s
user0m0.031s
sys 0m0.031s

Lee

-- 
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: Previously-functional gawk script now failing to execute - PLEASE HELP!!!

2021-09-15 Thread Lee via Cygwin
On 9/15/21, Bryan VanSchouwen via Cygwin wrote:
> Hello.
>
> I just tried executing an old, previously-functional awk script using a
> version of gawk that I had downloaded last year, and a command of the
> following format (as recommended in a previous communication with the
> Cygwin mailing list):
> gawk -vRS="\r\n" -f data_collect_e_-_FF_4-state.awk
> but this time, the script failed to execute!!

The data file you attached doesn't have "\r\n" line endings:
$ file rpcg_FF_filtrd.txt
rpcg_FF_filtrd.txt: ASCII text

compare with one that does:
$ file test.txt
test.txt: ASCII text, with CRLF line terminators

<.. snip ..>
> What the heck is going on with this software, and is there a way to fix
> it?!

I don't use RS and start my awk scripts off with
  sub("\r$", "", $0)  # fix any \r\n line endings
so my scripts work with either flavor of line endings.

If you don't want to change your script try changing your input
  unix2dos 

Regards,
Lee

-- 
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: github password policy

2021-08-16 Thread Lee via Cygwin-apps
On 8/16/21, Thomas Wolff wrote:
> github have changed their authentication policy not to allow passwords
> anymore.
> So they are asking maintainers to acquire another kind of password (a
> "token"), which I did a while ago.
> But they refuse to support users with the transition, there is no
> "plug-and-play" howto available, except for those who are willing to
> dive into details of authentication stuff and spend a few study hours on
> that useless policy change.
> As I cannot update mintty anymore right now from the git command line,
> is any maintainer here impacted by the same issue and can help out with
> some advice how to get rid of this nuisance?

ssh keys work - start here:
https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh

Regards
Lee


Fw: Web Designing

2021-05-12 Thread Lizelle Lee via Cygwin
Hi Cygwin,

Hope this mail finds you good..!  

 

My Name is Lizella Lee, I am a professional Web design & Mobile App
Developer; I can upgrade, Repair and Redesign your website. Would you be
interested in: - 

We Provides SEO & Web services at a minimum cost, May I send you quote? If
interested.

Thanks.!!!

Business Development Consultant 

 


-- 
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: Cygwin DLL 3.2.0 (W10) Problem with touch (8.26) for old dates < 1970

2021-04-14 Thread Lee via Cygwin
On 4/14/21, akiki--- via Cygwin wrote:
> Hi,
> I encountered problems with the use of timestamps in cygwin.
> May be it's an old problem, I don't know, using essentially files "recently"
> created/modified.
>
>
> I want to say after 1970 No problem, but before ...
>
>
> To day:
> touch -m -t 190001011200.00 x gives touch: format de date « 190001011200.00
> » incorrect
> touch -m -t 190101011200.00 x gives ok - with ls -l x:
> -rw-r--r-- 1 user group 0 1 janv. 1910 x

Do you have the 32 bit cygwin installed?  x86_64 Cygwin looks OK to me:

$ touch -m -t 190001011200.00 x

$ ls -l x
-rw-rw-rw- 1 Lee None 0 Jan  1  1900 x

$ uname -a
CYGWIN_NT-10.0 i3668 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

Regards,
Lee
--
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


gcc -fsanitize supported?

2021-03-21 Thread Lee via Cygwin
Is the gcc option "-fsanitize=address" supported in cygwin?  If yes,
what else do I need to install?

$ gcc -fsanitize=address args.c
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lasan
collect2: error: ld returned 1 exit status

$ i686-w64-mingw32-gcc -fsanitize=address args.c
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lasan
collect2: error: ld returned 1 exit status

Thanks
Lee
--
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: problem using gcc-core for compile qemu

2021-01-08 Thread Lee via Cygwin
On 1/8/21, juan carlos rebate rodriguez via Cygwin  wrote:
>
> I think I expressed myself incorrectly or I am not able to be
> understood, no matter what package I choose. gcc-core does not compile
> using the cygwin dll, the one that compiles for that library is cygwin-
> gcc.
> now I will try to explain my case better,
> 1 when I use the gcc-core package if it is able to detect the whole
> set, the only thing that happens is that the script does not recognize
> cygwin nt as a valid operating system.
> 2 when I use the mingw64-x86_64-gcc package it is not able to compile
> without add-ons.
> for example when I compile with gcc-core if it is able to detect the
> libcaca-devel library, this is the library that qemu asks me for sd-
> card support,
> However, when I use the package mingw64-x86_64-gcc it is not able to
> find it in the system because it is not in its set,

If you use the mingw cross compiler you'll also need some cross compiler tools.
Take a look at
  https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libcaca=x86_64

You probably need to install
mingw64-x86_64-libcaca-0.99.beta19-1 - mingw64-x86_64-libcaca: Color
ASCII art library for Win64 toolchain

Regards,
Lee
--
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: creating a current mingw64-i686-pcre package

2020-12-21 Thread Lee via Cygwin-apps
On 12/22/20, gs-cygwin@gluelogic.com  wrote:
> On Tue, Dec 22, 2020 at 02:38:19AM +0000, Lee via Cygwin-apps wrote:
>> I'd like to update the orphaned mingw64-i686-pcre package.
>>
>> The download and prep steps work but compile dies & I don't know why:
>>
>> >>> Preparing mingw64-i686-pcre-8.44-1.noarch
>> *** Info: SOURCE 1 signature follows:
>> gpg: Signature made Wed Feb 12 12:36:22 2020 EST
>> gpg:using RSA key 0x9766E084FB0F43D8
>> gpg: Good signature from "Philip Hazel "
>> gpg: aka "Philip Hazel "
>> gpg: aka "Philip Hazel "
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg:  There is no indication that the signature belongs to the
>> owner.
>> Primary key fingerprint: 45F6 8D54 BBE2 3FB3 039B  46E5 9766 E084 FB0F
>> 43D8
>> >>> Unpacking source pcre-8.44.tar.gz
>> >>> Preparing working source directory
>> >>> Compiling mingw64-i686-pcre-8.44-1.noarch
>> autoreconf-2.69: Entering directory `.'
>> autoreconf-2.69: configure.ac: not using Gettext
>> autoreconf-2.69: running: aclocal --force -I m4
>> autoreconf-2.69: configure.ac: tracing
>> autoreconf-2.69: running: libtoolize --copy --force
>> libtoolize: putting auxiliary files in '.'.
>> libtoolize:   error: copying '/usr/share/libtool/build-aux/ltmain.sh'
>> to './' failed
>> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
>> libtoolize:   error: copying '/usr/share/aclocal/libtool.m4' to 'm4/'
>> failed
>> libtoolize:   error: copying '/usr/share/aclocal/ltoptions.m4' to 'm4/'
>> failed
>> libtoolize:   error: copying '/usr/share/aclocal/ltsugar.m4' to 'm4/'
>> failed
>> libtoolize:   error: copying '/usr/share/aclocal/ltversion.m4' to 'm4/'
>> failed
>> libtoolize:   error: copying '/usr/share/aclocal/lt~obsolete.m4' to 'm4/'
>> failed
>> autoreconf-2.69: libtoolize failed with exit status: 1
>> *** ERROR: autoreconf failed
>>
>>
>> Hopefully I just need to install something else, but what?
>
> These are the usual suspects: autoconf automake libtool m4 pkg-config
> Do you have them installed?

Thanks for making me double-check.  I was doing package searches using
the name from the warning message and not finding anything that looked
applicable for Gettext.

The missing package was lower-case-g
  mingw64-i686-gettext

Should I be concerned about

  CC   libpcre16_la-pcre16_compile.lo
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:56:
warning: "PCREPOSIX_EXP_DECL" redefined
   56 | #  define PCREPOSIX_EXP_DECL extern __declspec(dllexport)
  |
In file included from
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:46:
./config.h:254: note: this is the location of the previous definition
  254 | #define PCREPOSIX_EXP_DECL extern __attribute__ ((visibility
("default")))
  |
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:57:
warning: "PCREPOSIX_EXP_DEFN" redefined
   57 | #  define PCREPOSIX_EXP_DEFN __declspec(dllexport)
  |
In file included from
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:46:
./config.h:257: note: this is the location of the previous definition
  257 | #define PCREPOSIX_EXP_DEFN extern __attribute__ ((visibility
("default")))
  |

Thanks,
Lee


creating a current mingw64-i686-pcre package

2020-12-21 Thread Lee via Cygwin-apps
I'd like to update the orphaned mingw64-i686-pcre package.

The download and prep steps work but compile dies & I don't know why:

>>> Preparing mingw64-i686-pcre-8.44-1.noarch
*** Info: SOURCE 1 signature follows:
gpg: Signature made Wed Feb 12 12:36:22 2020 EST
gpg:using RSA key 0x9766E084FB0F43D8
gpg: Good signature from "Philip Hazel "
gpg: aka "Philip Hazel "
gpg: aka "Philip Hazel "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 45F6 8D54 BBE2 3FB3 039B  46E5 9766 E084 FB0F 43D8
>>> Unpacking source pcre-8.44.tar.gz
>>> Preparing working source directory
>>> Compiling mingw64-i686-pcre-8.44-1.noarch
autoreconf-2.69: Entering directory `.'
autoreconf-2.69: configure.ac: not using Gettext
autoreconf-2.69: running: aclocal --force -I m4
autoreconf-2.69: configure.ac: tracing
autoreconf-2.69: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize:   error: copying '/usr/share/libtool/build-aux/ltmain.sh'
to './' failed
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize:   error: copying '/usr/share/aclocal/libtool.m4' to 'm4/' failed
libtoolize:   error: copying '/usr/share/aclocal/ltoptions.m4' to 'm4/' failed
libtoolize:   error: copying '/usr/share/aclocal/ltsugar.m4' to 'm4/' failed
libtoolize:   error: copying '/usr/share/aclocal/ltversion.m4' to 'm4/' failed
libtoolize:   error: copying '/usr/share/aclocal/lt~obsolete.m4' to 'm4/' failed
autoreconf-2.69: libtoolize failed with exit status: 1
*** ERROR: autoreconf failed


Hopefully I just need to install something else, but what?

Thanks,
Lee


mingw64-i686-pcre.cygport
Description: Binary data


Re: why does i686-w64-mingw32-gcc -static fail?

2020-12-18 Thread Lee via Cygwin
On 12/18/20, Brian Inglis wrote:
> On 2020-12-17 20:45, Lee via Cygwin wrote:
>> Would someone please explain why adding "-static" makes
>> i686-w64-mingw32-gcc fail?
>>
>> This works (or at least the compiler doesn't complain)
>>
>> $ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix
>> -lpcre
>>
>> This does not work
>>
>> $ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix
>> -lpcre
>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>> cannot find -lpcreposix
>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>> cannot find -lpcre
>> collect2: error: ld returned 1 exit status
>>
>> Why does adding "-static" make it fail?
>
> Because the mingw64-*86*-pcre/2 packages provide only dynamic libraries and
> their linkage archives:
 <.. snip list of libpcre*.dll and .dll.a files ..>
> where others provide both dynamic and static libraries e.g.
> mingw64-i686-zstd:
>
> usr/i686-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.a
> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.dll.a
>
> possibly where the size of useful library members are reasonably small
> enough,
> and unlikely to need significantly updated, to be statically linked into an
> standalone executable or embedded system component, that itself may be
> regularly
> updated, rather than requiring large chunks of a framework to be linked that
> may need regular updates.

Thanks for the explanation :)

I went looking to see how the mingw pcre package was built and ended up here:
  
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=summary

If that's correct and the latest then it looks to be a bit out of
date; the current release is 8.44
  https://ftp.pcre.org/pub/pcre/

Looking at the latest cygport info
  
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=blob;f=mingw64-i686-pcre.cygport;h=7456c41e6c45aad8403303aee413144fcf5d1b58;hb=3200774765aabbdda5cf4e5e9934c3d25e6e7196

and going off the current pcre doc included with the 8.44 tarball:
 The Autotools PCRE building process uses libtool to build both shared
and static libraries by default. You can suppress one of these by
adding one of

  --disable-shared
  --disable-static

to the configure command, as required.

The cygport info doesn't have "--disable-static" so maybe not having
static libraries wasn't an intentional omission??

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


why does i686-w64-mingw32-gcc -static fail?

2020-12-17 Thread Lee via Cygwin
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?

This works (or at least the compiler doesn't complain)

$ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre

This does not work

$ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcreposix
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcre
collect2: error: ld returned 1 exit status

Why does adding "-static" make it fail?

$ cat conftest-pcre.c
/* i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
 *   and yet this works
 * i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
 */
char pcre_compile ();
char regcomp ();
int main () {
return pcre_compile ();
return regcomp ();
  ;
  return 0;
}


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


php memory errors

2020-06-19 Thread Richard H Lee via Cygwin
I've recently gotten out of memory errors with php, with tasks that 
previously have worked fine.


Has anybody else experienced this too?

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


building net-snmp: (was: Updated: net-snmp-5.8-1)

2020-04-28 Thread Lee via Cygwin
> If you want to make a point or ask a question the Cygwin mailing list is
> the appropriate place.

You don't need this anymore
  02-path-separator.patch
if you build net-snmp with
  export ENV_SEPARATOR=":"

And maybe now they'll accept a patch so that building on cygwin
doesn't require an evar.  I think  "gcc -mno-cygwin ..."  might still
have been supported when I tried to get it changed and the best they'd
do was an evar when building.


Is 06-winstub.patch necessary?  Necessary if all you're using is the
command line tools?
The changelog has this
commit fda421625d20d8f8201479fa7f33c257fdc72015
Author: Bart Van Assche 
Date:   Sun Nov 27 11:25:40 2016 -0800

Cygwin: getnetent() / getnetbyaddr() build fix

Recent versions of Cygwin have prototypes but no implementation for
these functions. Hence avoid that the Cygwin prototypes conflict
with the implementation.

In other words, if I'm using just the snmp{get,set} command line
tools, should I be applying this patch?

Thanks,
Lee



On 4/27/20, David Rothenberger wrote:
> DESCRIPTION:
> 
> Simple Network Management Protocol (SNMP) is a widely used protocol
> for monitoring the health and welfare of network equipment
> (eg. routers), computer equipment and even devices like
> UPSs. Net-SNMP is a suite of applications used to implement SNMP v1,
> SNMP v2c and SNMP v3 using both IPv4 and IPv6. The suite includes:
>
>   * Command-line applications to:
> * retrieve information from an SNMP-capable device, either using
>   single requests (snmpget, snmpgetnext), or multiple requests
>   (snmpwalk, snmptable, snmpdelta).
> * manipulate configuration information on an SNMP-capable device
>   (snmpset).
> * retrieve a fixed collection of information from an
>   SNMP-capable device (snmpdf, snmpnetstat, snmpstatus).
> * convert between numerical and textual forms of MIB OIDs, and
>   display MIB content and structure (snmptranslate).
>   * A graphical MIB browser (tkmib), using Tk/perl.
>   * A daemon application for receiving SNMP notifications
>  (snmptrapd). Selected notifications can be logged (to syslog,
>  the NT Event Log, or a plain text file), forwarded to another
>  SNMP management system, or passed to an external application.
>   * An extensible agent for responding to SNMP queries for
> management information (snmpd). This includes built-in support
> for a wide range of MIB information modules, and can be extended
> using dynamically loaded modules, external scripts and commands,
> and both the SNMP multiplexing (SMUX) and Agent Extensibility
> (AgentX) protocols.
>   * A library for developing new SNMP applications, with both C and
> perl APIs.
>
> CYGWIN NOTES:
> =
>  * The snmpd daemon does not provide much useful information.
>Installing it as a service under Cygwin is left as an exercise
>for the user.
>
> QUESTIONS:
> ==
> If you want to make a point or ask a question the Cygwin mailing list is
> the appropriate place.
>
>
> --
> David Rothenberger
>
> Remember:  Silly is a state of Mind, Stupid is a way of Life.
> -- Dave Butler
> --
> 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