[PATCH] update site goldstar award types images from jpg/png to webp

2022-02-01 Thread Brian Inglis
Our images at cygwin-htdocs/goldstars/img/ seemed large for small icons: $ wc -c img/* 3473 img/dungbomb.png 1074 img/goldstar.png 1303 img/goldwatch.png 9382 img/pinkwatch.jpg 877 img/platinumwatch.jpg 878 img/plush_hippo.jpg 1055 img/silverstar.png 18042 total so converted

[ANNOUNCEMENT] Updated: libwebp{, -devel, 7, decoder3, demux2, mux3} 1.2.2

2022-02-01 Thread Cygwin libwebp Maintainer
The following packages have been upgraded in the Cygwin distribution: * libwebp 1.2.2 * libwebp-devel 1.2.2 * libwebp7 1.2.2 * libwebpdecoder3 1.2.2 * libwebpdemux2 1.2.2 * libwebpmux3 1.2.2 WebP is a modern web image format with

Updated: libwebp{,-devel,7,decoder3,demux2,mux3} 1.2.2

2022-02-01 Thread Cygwin libwebp Maintainer
The following packages have been upgraded in the Cygwin distribution: * libwebp 1.2.2 * libwebp-devel 1.2.2 * libwebp7 1.2.2 * libwebpdecoder3 1.2.2 * libwebpdemux2 1.2.2 * libwebpmux3 1.2.2 WebP is a modern web image format with

cygwin 3.3.4-2: "GetConsoleMode()" may be missing "Quick Edit Mode", "Insert Mode" state

2022-02-01 Thread Mitchell Hentges
This issue only manifests when using Windows Command Prompt as the terminal instead of MinTTY. When querying Windows for "GetConsoleMode()" of the input handle, a result of 0x0007 is returned. When calling "GetConsoleMode()" from a Command Prompt (outside of Cygwin), 0x00F7 is returned. In both

Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

2022-02-01 Thread Adam Dinwoodie
On Tue, Feb 01, 2022 at 04:53:47PM +, Jon Turney wrote: > On 31/01/2022 22:11, Adam Dinwoodie wrote: > > On Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote: > > > On 2022-01-31 08:46, Andrey Repin wrote: > > > > Greetings, Jon Turney! > > > > > > > > > Probably what's wanted is to

Orphaning fzf

2022-02-01 Thread Adam Dinwoodie
The upstream fzf package moved from Ruby to Go some time ago. I had vague but noble intetions to try to maintain a fork on the basis of the last version of the Ruby code, but never managed anything useful. In that context, I expect it's time that I officially throw in the towel, and mark fzf as

Re: [PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

2022-02-01 Thread Jon Turney
On 01/02/2022 19:22, Corinna Vinschen wrote: Hi Jon, On Feb 1 17:25, Jon Turney wrote: Be more careful not to remove an existing .gnu_debuglink, even if we think this package has no useful debug symbols. (Some versions of 'llvm-objdump -l' fail to find line number info even though it's

Re: [PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

2022-02-01 Thread Corinna Vinschen
Hi Jon, On Feb 1 17:25, Jon Turney wrote: > Be more careful not to remove an existing .gnu_debuglink, even if we > think this package has no useful debug symbols. > > (Some versions of 'llvm-objdump -l' fail to find line number info even > though it's there. Don't break a package which manages

Re: cygport problem with pkg name starting with number

2022-02-01 Thread Marco Atzeri
On 01.02.2022 16:04, Jon Turney wrote: On 30/01/2022 19:44, Marco Atzeri wrote: It is not a huge number of case as we have only two packages in this category 4ti2 and 2048-cli that produces /usr/share/cygport/lib/pkg_pkg.cygpart: line 197: 4ti2_debuginfo_CONTENTS: bad substitution Any

[PATCH cygport 2/2] Don't use llvm-objdump

2022-02-01 Thread Jon Turney
This partially reverts commit e06359bca705624b9712fd16f4ec9945935fd608 This partially reverts commit 6f788165848084d2fb1597689b31faba7d4c483e The polynomially bad runtime of 'objdump' (which made 'llvm-objdump' the only practically usable tool on larger binaries) has been fixed since [1].

[PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

2022-02-01 Thread Jon Turney
Be more careful not to remove an existing .gnu_debuglink, even if we think this package has no useful debug symbols. (Some versions of 'llvm-objdump -l' fail to find line number info even though it's there. Don't break a package which manages it's own debug symbols (e.g. cygwin) when that

[PATCH cygport 0/2] Avoid misbehaviour with llvm-objdump

2022-02-01 Thread Jon Turney
Jon Turney (2): postinst: Never remove an existing .gnu_debuglink Don't use llvm-objdump lib/pkg_info.cygpart | 8 lib/src_postinst.cygpart | 35 +++ 2 files changed, 19 insertions(+), 24 deletions(-) -- 2.34.1

Re: [ANNOUNCEMENT] cygwin 3.3.4-1

2022-02-01 Thread Jim Reisert AD1C
> > The following packages have been uploaded to the Cygwin distribution: > > > > * cygwin-3.3.4-1 > > * cygwin-devel-3.3.4-1 > > * cygwin-doc-3.3.4-1 > > I've tried two mirrors, both with the same result: > > dash.exe - Bad Image > > C:\Cygwin64\bin\cygwin1.dll is either not designed to

Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

2022-02-01 Thread Jon Turney
On 31/01/2022 22:11, Adam Dinwoodie wrote: On Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote: On 2022-01-31 08:46, Andrey Repin wrote: Greetings, Jon Turney! Probably what's wanted is to remember the state of those checkboxes, if this isn't the first time setup has been run? That's a

Re: cygport problem with pkg name starting with number

2022-02-01 Thread Jon Turney
On 30/01/2022 19:44, Marco Atzeri wrote: It is not a huge number of case as we have only two packages in this category 4ti2 and 2048-cli on   /usr/share/cygport/lib/pkg_pkg.cygpart there is this code using indirect variable assignment as ${!dbg_contents_var}

Re: calm and cygport not in sync

2022-02-01 Thread Jon Turney
On 24/01/2022 04:42, Marco Atzeri wrote: It seems calm is now rejecting what cygport is still producing [..] ERROR: package 'python36-sh' version '1.14.2-1' obsoletes: 'python3-sh', but nothing satisfies that ERROR: package 'python36-straight.plugin' version '1.5.0-1' obsoletes:

Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

2022-02-01 Thread Corinna Vinschen
On Feb 1 15:47, Andrey Repin wrote: > Greetings, BRISLANE Mark! > > > We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but > > perhaps our scenario is slightly different because it's still happening. > > SERVER1 has a folder on D: called folder 1, which is a symlink to > >

RE: [EXTERNAL] Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

2022-02-01 Thread BRISLANE Mark
Hi there, I wonder if this is OS dependent? I note you're on Windows 7 / Server 2008 R2 (both EOL by the way!) where as I'm on Windows Server 2016. The server where this works on an older version of Cygwin is Server 2012 R2, and I've copied the cygwin1.dll from that server to my Server 2016

Re: Cygwin 3.3.4 - cmd to symlinked path doesn't work

2022-02-01 Thread Andrey Repin
Greetings, BRISLANE Mark! > We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but > perhaps our scenario is slightly different because it's still happening. > SERVER1 has a folder on D: called folder 1, which is a symlink to > "\\server2\share\folder1" - created with mklink /D

Cygwin 3.3.4 - cmd to symlinked path doesn't work

2022-02-01 Thread BRISLANE Mark
Hi, We had this issue in 3.3.3 and is down as being fixed in 3.3.4-2 but perhaps our scenario is slightly different because it's still happening. SERVER1 has a folder on D: called folder 1, which is a symlink to "\\server2\share\folder1" - created with mklink /D folder1 \\server2\share\folder1

Re: Renaming (with 'mv') very large files is SLOW

2022-02-01 Thread Andrey Repin
Greetings, cyg...@kosowsky.org! > I literally am typing something like: > mv foo bar > In Linux, that just edits the file system table & inode... > UPDATE... > I just tried a second 'mv' and it was near instantaneous. > (and similarly with subsequent renaming of the same file) > So perhaps