Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Eliot Moss via Cygwin]

On 5/17/2024 11:21 AM, Cedric Blancher via Cygwin wrote:

On Fri, 17 May 2024 at 16:50, Brian Inglis via Cygwin  wrote:


On 2024-05-17 01:48, Cedric Blancher via Cygwin wrote:

Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows? We like to create a CI build pipeline, and want to
create binaries for 32bit and 64bit Cygwin on the same machine, but
setup.exe for 32bir Cygwin refuses to install


Practical reason is 32 bit usage < 1%


I would agree for commercial, well-funded enterprises. The situation
is much different for funding-starved education, i.e. schools and
universities, where Win10 32bit is squatting cheap computers in the
*millions*. For example the schools in Paris alone have 22000 active
Win10 32bit licenses in 2022 (last time this was counted).


and Cygwin is all volunteer, with
professionally and/or personally busy developers lacking time to do more.
You are on your own with 32 bit dropped,


Does Cygwin 3.6 still compile on 32bit?


AFAIK, yes, though most folks don't compile it themselves.
I just download things.


so ask questions on forums like SO.


What is SO?


StackOverflow.

Cheers - Eliot Moss


--
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: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Cedric Blancher via Cygwin]

On Fri, 17 May 2024 at 16:50, Brian Inglis via Cygwin  wrote:
>
> On 2024-05-17 01:48, Cedric Blancher via Cygwin wrote:
> > Is there a technical reason why 32bit Cygwin cannot be installed on
> > 64bit Windows? We like to create a CI build pipeline, and want to
> > create binaries for 32bit and 64bit Cygwin on the same machine, but
> > setup.exe for 32bir Cygwin refuses to install
>
> Practical reason is 32 bit usage < 1%

I would agree for commercial, well-funded enterprises. The situation
is much different for funding-starved education, i.e. schools and
universities, where Win10 32bit is squatting cheap computers in the
*millions*. For example the schools in Paris alone have 22000 active
Win10 32bit licenses in 2022 (last time this was counted).

> and Cygwin is all volunteer, with
> professionally and/or personally busy developers lacking time to do more.
> You are on your own with 32 bit dropped,

Does Cygwin 3.6 still compile on 32bit?

> so ask questions on forums like SO.

What is SO?

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Brian Inglis via Cygwin]

On 2024-05-17 01:48, Cedric Blancher via Cygwin wrote:

Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows? We like to create a CI build pipeline, and want to
create binaries for 32bit and 64bit Cygwin on the same machine, but
setup.exe for 32bir Cygwin refuses to install


Practical reason is 32 bit usage < 1% and Cygwin is all volunteer, with 
professionally and/or personally busy developers lacking time to do more.

You are on your own with 32 bit dropped, so ask questions on forums like SO.

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Dimitry Andric via Cygwin]

On 17 May 2024, at 09:48, Cedric Blancher via Cygwin  wrote:
> 
> Is there a technical reason why 32bit Cygwin cannot be installed on
> 64bit Windows? We like to create a CI build pipeline, and want to
> create binaries for 32bit and 64bit Cygwin on the same machine, but
> setup.exe for 32bir Cygwin refuses to install

How exactly does it "refuse to install" ? If it says "mbox : Cygwin is not 
supported on 32-bit Windows", you may not have followed the instructions at 
https://cygwin.com/pipermail/cygwin/2022-November/252542.html, which say:

> To install the last cygwin version for x86, run setup using the options 
> '--allow-unsupported-windows option --site circa_URL', where circa_URL can be 
> one of:
> * The URL for any sourceware mirror[1], followed by cygwin-archive/20221123
> * 
> http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/2022/11/23/063457

I tried exactly that just now (with the second URL), and it installed OK, with 
the default package set. This is on a Windows 10 22H2 x64 host. The resulting 
Cygwin installation appears to work fine, with light testing.

-Dimitry


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

Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Cedric Blancher via Cygwin]

Good morning!

Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows? We like to create a CI build pipeline, and want to
create binaries for 32bit and 64bit Cygwin on the same machine, but
setup.exe for 32bir Cygwin refuses to install

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Brian Inglis via Cygwin-apps]

Date manipulation utilities

Dateutils are a bunch of tools that revolve around fiddling with
dates and times on the command line with a strong focus on use cases
that arise when dealing with large amounts of financial data.

For more information see the project home pages:

http://www.fresse.org/dateutils
https://github.com/hroptatyr/dateutils

I would like to adopt the above orphaned package.

Below are links to the existing package, build repo, scallywag runs,
and changes.

Existing package:

https://cygwin.com/packages/summary/dateutils-src.html

https://cygwin.com/packages/summary/dateutils.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils

The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?

Changes since the last Cygwin release:

https://github.com/hroptatyr/dateutils/compare/v0.4.0...v0.4.11

-- 

Re: libtool can't build shared library unless -no-undefined specified

[Brian Inglis via Cygwin-apps]

On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless 
-no-undefined is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
  --enable-contrib
  --enable-tzmap-fetch
  lt_no_undefined_flag=--no-undefined
  no_undefined_flag=--no-undefined


You and I discussed this a few years ago in connection with curl.  The solution 
there, and in most similar cases, is to add -no-undefined to the appropriate 
lib*_la_LDFLAGS variable(s) in Makefile.am.  See


   https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html


Thanks for the reminder Ken,

You must have a great memory and/or search strategy.
Even checking back on curl and github I have zero memory of making this patch, 
and it being accepted upstream, but this should prompt me to remember to search 
wider in my email hierarchy, and in my own package repo clones and directories 
for patches.

Now your response is starred in my email.
Perhaps I worked contract gigs too long, my memory compressor kicked in, and 
swapped that out to external storage (here!)

Hoping this will perhaps hammer a nail in my memory to hang that info on.

Cheers!

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

cygwin.cygwin.narkive.com

[Alyssa Hoffman via Cygwin]

Hi ,

Your website's current version might be holding back its performance on
search engines. I've got some great methods to improve your online
visibility and attract quality visitors.

Would you be open to a brief chat and info/quote? No obligations, just
exploring ways to benefit your company.

Thanks
Alyssa Hoffman


*PrimeVisions LLC We are awesome!*
5859 McDovie Ave, Woodland Hills, CA 91367
Other Presence: MA | WA | CO | ID | DE | CT | UT | GA and FL
You are notified that disclosing, copying, distributing, or taking any
action in reliance on the contents of this information is strictly
prohibited. Please ignore this email, if you received it by an error.   .

-- 
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: libtool can't build shared library unless -no-undefined specified

[Ken Brown via Cygwin-apps]

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless 
-no-undefined is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
  --enable-contrib
  --enable-tzmap-fetch
  lt_no_undefined_flag=--no-undefined
  no_undefined_flag=--no-undefined


You and I discussed this a few years ago in connection with curl.  The 
solution there, and in most similar cases, is to add -no-undefined to 
the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See


  https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html

Ken

libtool can't build shared library unless -no-undefined specified

[Brian Inglis via Cygwin-apps]

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless -no-undefined 
is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
 --enable-contrib
 --enable-tzmap-fetch
 lt_no_undefined_flag=--no-undefined
 no_undefined_flag=--no-undefined
"

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Wed, 15 May 2024 17:48:49 +0200
Johannes Khoshnazar-Thoma wrote:
> Hi again,
> 
> Am 15.05.24 um 17:37 schrieb Johannes Khoshnazar-Thoma:
> > Hi again,
> >
> > Am 23.04.24 um 12:26 schrieb Takashi Yano:
>  Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
>  wihch is the latest cygwin release?
> 
> >
> > We retried the tests with cygwin1.dll 3.5.3-1 and it looks like
> > the issue is still there. Here's an excerpt from the gdb debug
> > session:
> >
> Sorry somehow the formatting got messed up I try again:

Thanks for testing and the additional information.

> (gdb) info thread
>Id   Target Id Frame
> * 1Thread 0x11cc 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
> from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>2Thread 0x8ec  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>3Thread 0x55c  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject 
> () from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>4Thread 0x131c 0x7ffe579d95f4 in 
> ntdll!ZwWaitForWorkViaWorkerFactory () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>5Thread 0x9b8  0x7ffe579d95f4 in 
> ntdll!ZwWaitForWorkViaWorkerFactory () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x11cc)]
> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) bt
> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> #1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
> C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
> #2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914

Line 1914 of fhandler/console.cc is:
  WaitForSingleObject (thread_sync_event, INFINITE);

This waits termination of cons_master_thread(). However, it does not seem
that the cons_master_thread exists in thread list obove. If the thread was
terminated normally, thread_sync_event should has been set.

> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) up
> #1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
> C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
> (gdb)
> #2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
> 1914in /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc
> (gdb) p thread_sync_event
> $6 = (HANDLE) 0x1510
> (gdb) p name
> $7 = "cygcons.thread_sync.0", '\000' , "r", '\000'  183 times>...
> (gdb) p con.owner
> No symbol "con" in current context.
> (gdb) p master_thread_started
> $8 = true
> (gdb) p unit
> $9 = 0
> (gdb) p shared_console_info
> $10 = {0x1a003, 0x0 }
> (gdb)

fhandler_console::close() was called twice? Or master thread had crashed
without setting thread_sync_event?

-- 
Takashi Yano 

-- 
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 application hangs on closing console

[Brian Inglis via Cygwin]

On 2024-05-15 09:48, Johannes Khoshnazar-Thoma via Cygwin wrote:

Hi again,

Am 15.05.24 um 17:37 schrieb Johannes Khoshnazar-Thoma:

Hi again,

Am 23.04.24 um 12:26 schrieb Takashi Yano:

Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
wihch is the latest cygwin release?



We retried the tests with cygwin1.dll 3.5.3-1 and it looks like
the issue is still there. Here's an excerpt from the gdb debug
session:


Sorry somehow the formatting got messed up I try again:

(gdb) info thread
   Id   Target Id Frame
* 1    Thread 0x11cc 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
   2    Thread 0x8ec  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
   3    Thread 0x55c  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
   4    Thread 0x131c 0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
   5    Thread 0x9b8  0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

(gdb) thread 1
[Switching to thread 1 (Thread 0x11cc)]
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

(gdb) bt
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
#3  0x7ffe4a1f6ce7 in fhandler_base::close_with_arch (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/base.cc:1288
#4  0x7ffe4a26a4cd in init_cygheap::close_ctty (this=0x8) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/mm/cygheap.cc:135
#5  0x7ffe4a1c7c4e in close_all_files (norelease=norelease@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/syscalls.cc:81
#6  0x7ffe4a146840 in do_exit (status=0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1128
#7  0x7ffe4a1469f7 in _exit (n=) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1243
#8  0x7ffe4a2a4bb9 in exit (code=0) at 
/usr/src/debug/cygwin-3.5.3-1/newlib/libc/stdlib/exit.c:65
#9  0x7ffe4a1469e7 in cygwin_exit (n=5392) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1237
#10 0x7ffe4a14809a in dll_crt0_1 () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1002
#11 0x7ffe4a145e08 in _cygtls::call2 (this=0x7ce00, func=0x7ffe4a146fb8 
, arg=0x0, buf=buf@entry=0x7cdf0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#12 0x7ffe4a145e86 in _cygtls::call (func=, arg=out>) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28

#13 0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x8ec)]
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

(gdb) bt
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe5415e704 in ReadFile () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a1bada6 in wait_sig () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/sigproc.cc:1324
#3  0x7ffe4a144d5f in cygthread::callfunc (this=this@entry=0x7ffe4a335560 
, issimplestub=issimplestub@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:48
#4  0x7ffe4a145270 in cygthread::stub (arg=arg@entry=0x7ffe4a335560 
) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:91
#5  0x7ffe4a145e08 in _cygtls::call2 (this=0xdbce00, func=0x7ffe4a1451ea 
, arg=0x7ffe4a335560 , buf=buf@entry=0xdbcd50) 
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#6  0x7ffe4a145e86 in _cygtls::call (func=, arg=out>) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#7  0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from 
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#8  0x7ffe57981791 in ntdll!RtlUserThreadStart () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

#9  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 0x55c)]
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

(gdb) bt
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a1452ab in cygthread::stub (arg=arg@entry=0x7ffe4a3355b8 
) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:112
#3  

Re: cygwin application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi again,

Am 15.05.24 um 17:37 schrieb Johannes Khoshnazar-Thoma:

Hi again,

Am 23.04.24 um 12:26 schrieb Takashi Yano:

Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
wihch is the latest cygwin release?



We retried the tests with cygwin1.dll 3.5.3-1 and it looks like
the issue is still there. Here's an excerpt from the gdb debug
session:


Sorry somehow the formatting got messed up I try again:

(gdb) info thread
  Id   Target Id Frame
* 1Thread 0x11cc 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  2Thread 0x8ec  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  3Thread 0x55c  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  4Thread 0x131c 0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  5Thread 0x9b8  0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 0x11cc)]
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
#3  0x7ffe4a1f6ce7 in fhandler_base::close_with_arch (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/base.cc:1288
#4  0x7ffe4a26a4cd in init_cygheap::close_ctty (this=0x8) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/mm/cygheap.cc:135
#5  0x7ffe4a1c7c4e in close_all_files (norelease=norelease@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/syscalls.cc:81
#6  0x7ffe4a146840 in do_exit (status=0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1128
#7  0x7ffe4a1469f7 in _exit (n=) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1243
#8  0x7ffe4a2a4bb9 in exit (code=0) at 
/usr/src/debug/cygwin-3.5.3-1/newlib/libc/stdlib/exit.c:65
#9  0x7ffe4a1469e7 in cygwin_exit (n=5392) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1237
#10 0x7ffe4a14809a in dll_crt0_1 () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1002
#11 0x7ffe4a145e08 in _cygtls::call2 (this=0x7ce00, func=0x7ffe4a146fb8 
, arg=0x0, buf=buf@entry=0x7cdf0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#12 0x7ffe4a145e86 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#13 0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x8ec)]
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe5415e704 in ReadFile () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a1bada6 in wait_sig () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/sigproc.cc:1324
#3  0x7ffe4a144d5f in cygthread::callfunc (this=this@entry=0x7ffe4a335560 
, issimplestub=issimplestub@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:48
#4  0x7ffe4a145270 in cygthread::stub (arg=arg@entry=0x7ffe4a335560 
) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:91
#5  0x7ffe4a145e08 in _cygtls::call2 (this=0xdbce00, func=0x7ffe4a1451ea 
, arg=0x7ffe4a335560 , buf=buf@entry=0xdbcd50) 
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#6  0x7ffe4a145e86 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#7  0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from 
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#8  0x7ffe57981791 in ntdll!RtlUserThreadStart () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#9  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 0x55c)]
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a1452ab in cygthread::stub (arg=arg@entry=0x7ffe4a3355b8 
) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:112
#3  0x7ffe4a145e08 in _cygtls::call2 (this=0x2aece00, func=0x7ffe4a1451ea 
, arg=0x7ffe4a3355b8 

Re: cygwin application hangs on closing console

[Johannes Khoshnazar-Thoma via Cygwin]

Hi again,

Am 23.04.24 um 12:26 schrieb Takashi Yano:

Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
wihch is the latest cygwin release?



We retried the tests with cygwin1.dll 3.5.3-1 and it looks like
the issue is still there. Here's an excerpt from the gdb debug
session:

(gdb) info thread
  Id   Target Id Frame  

 * 
1Thread 0x11cc 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  2Thread 0x8ec  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  3Thread 0x55c  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

 4Thread 0x131c 0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  5Thread 0x9b8  0x7ffe579d95f4 in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll 
  (gdb) thread 1
[Switching to thread 1 (Thread 0x11cc)] 

 #0 
 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
#3  0x7ffe4a1f6ce7 in fhandler_base::close_with_arch (this=0x89030) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/base.cc:1288
#4  0x7ffe4a26a4cd in init_cygheap::close_ctty (this=0x8) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/mm/cygheap.cc:135
#5  0x7ffe4a1c7c4e in close_all_files (norelease=norelease@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/syscalls.cc:81
#6  0x7ffe4a146840 in do_exit (status=0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1128
#7  0x7ffe4a1469f7 in _exit (n=) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1243
#8  0x7ffe4a2a4bb9 in exit (code=0) at 
/usr/src/debug/cygwin-3.5.3-1/newlib/libc/stdlib/exit.c:65
#9  0x7ffe4a1469e7 in cygwin_exit (n=5392) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1237
#10 0x7ffe4a14809a in dll_crt0_1 () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:1002
#11 0x7ffe4a145e08 in _cygtls::call2 (this=0x7ce00, func=0x7ffe4a146fb8 
, arg=0x0, buf=buf@entry=0x7cdf0) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#12 0x7ffe4a145e86 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#13 0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x8ec)]
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffe5415e704 in ReadFile () from 
C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
#2  0x7ffe4a1bada6 in wait_sig () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/sigproc.cc:1324
#3  0x7ffe4a144d5f in cygthread::callfunc (this=this@entry=0x7ffe4a335560 
, issimplestub=issimplestub@entry=false) at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:48
#4  0x7ffe4a145270 in cygthread::stub (arg=arg@entry=0x7ffe4a335560 
) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygthread.cc:91
#5  0x7ffe4a145e08 in _cygtls::call2 (this=0xdbce00, func=0x7ffe4a1451ea 
, arg=0x7ffe4a335560 , buf=buf@entry=0xdbcd50) 
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:41
#6  0x7ffe4a145e86 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/cygtls.cc:28
#7  0x7ffe84d4 in KERNEL32!BaseThreadInitThunk () from 
C:\src\dlls-syms\kernel32.dll\640993B0ad000\kernel32.dll
#8  0x7ffe57981791 in ntdll!RtlUserThreadStart () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#9  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 0x55c)]
#0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll

RE: [EXTERNAL] Re: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin]

> Looking at /usr/include/w32api/minwinbase.h:
>  snip 
>   typedef enum _FILE_INFO_BY_HANDLE_CLASS {
>FileBasicInfo /* is zero? */,
>FileStandardInfo,
>FileNameInfo,
>FileRenameInfo,
>FileDispositionInfo,
>FileAllocationInfo,
>FileEndOfFileInfo,
>FileStreamInfo,
>FileCompressionInfo,
>FileAttributeTagInfo,
>FileIdBothDirectoryInfo,
>FileIdBothDirectoryRestartInfo,
>FileIoPriorityHintInfo,
>FileRemoteProtocolInfo,
>FileFullDirectoryInfo,
>FileFullDirectoryRestartInfo,
> #if _WIN32_WINNT >= 0x0602
>FileStorageInfo,
>FileAlignmentInfo,
>FileIdInfo,
>FileIdExtdDirectoryInfo,
>FileIdExtdDirectoryRestartInfo,
> #endif
> #if _WIN32_WINNT >= 0x0A02
>FileDispositionInfoEx,
>FileRenameInfoEx,
> #endif
>FileCaseSensitiveInfo,
>FileNormalizedNameInfo,
>MaximumFileInfoByHandleClass
>  } FILE_INFO_BY_HANDLE_CLASS, *PFILE_INFO_BY_HANDLE_CLASS;
> #endif
>  snip 

FWIW, this is how it is defined by the native M$ SDK:

#if (NTDDI_VERSION >= NTDDI_LONGHORN)
typedef enum _FILE_INFO_BY_HANDLE_CLASS {
FileBasicInfo,
FileStandardInfo,
FileNameInfo,
FileRenameInfo,
FileDispositionInfo,
FileAllocationInfo,
FileEndOfFileInfo,
FileStreamInfo,
FileCompressionInfo,
FileAttributeTagInfo,
FileIdBothDirectoryInfo,
FileIdBothDirectoryRestartInfo,
FileIoPriorityHintInfo,
FileRemoteProtocolInfo,
FileFullDirectoryInfo,
FileFullDirectoryRestartInfo,
#if (NTDDI_VERSION >= NTDDI_WIN8)
FileStorageInfo,
FileAlignmentInfo,
FileIdInfo,
FileIdExtdDirectoryInfo,
FileIdExtdDirectoryRestartInfo,
#endif
#if (NTDDI_VERSION >= NTDDI_WIN10_RS1)
FileDispositionInfoEx,
FileRenameInfoEx,
#endif
#if (NTDDI_VERSION >= NTDDI_WIN10_19H1)
FileCaseSensitiveInfo,
FileNormalizedNameInfo,
#endif
MaximumFileInfoByHandleClass
} FILE_INFO_BY_HANDLE_CLASS, *PFILE_INFO_BY_HANDLE_CLASS;
#endif

Anton Lavrentiev
Contractor NIH/NLM/NCBI


-- 
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] Re: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...

[Brian Inglis via Cygwin]

On 2024-05-13 07:34, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:

*FileNormalizedNameInformation* 44/0x2e is defined in winternl.h
FILE_INFORMATION_CLASS for NtQueryInformationFile:


I see it's defined as 48/0x30 there, though...


Good catch and point!
My computer glasses did not seem to be working well last weekend!

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...

[Roland Mainz via Cygwin]

On Sat, May 11, 2024 at 6:17 PM Brian Inglis via Cygwin
 wrote:
> On 2024-05-11 05:30, Roland Mainz via Cygwin wrote:
> > I'm writing a test program for |FileNormalizedNameInfo| right now (see
> > https://rovema.kpaste.net/07074abc).
> > Per 
> > https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ne-minwinbase-file_info_by_handle_class
> > |FileNormalizedNameInfo| should be |24|, but on Cygwin 3.6 I get the
> > value |48|.
> > Since |GetFileInformationByHandleEx()| gives me error 87 (="Invalid
> > Parameter") for |48|, but works as intended for |24| I assume that the
> > Cygwin header is wrong.
> >
> > Could someone please check the Cygwin header files ?
>
> Could someone please read the enum constant names and classes carefully?
>
> Package w32api-headers:
>
> > Headers:
> >  snip 
> > $ grep -r FileNormalizedNameInfo /usr/include/
> > /usr/include/w32api/ddk/wdm.h:  FileNormalizedNameInformation,
> > /usr/include/w32api/minwinbase.h:*FileNormalizedNameInfo*,
> > /usr/include/w32api/winternl.h:FileNormalizedNameInformation = 48,
> >  snip 
>
> *FileNormalizedNameInfo* 24/0x18 is defined in minwinbase.h
> FILE_INFO_BY_HANDLE_CLASS for GetFileInformationByHandleEx whereas
> *FileNormalizedNameInformation* 44/0x2e is defined in winternl.h
> FILE_INFORMATION_CLASS for NtQueryInformationFile:
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile
>
> ditto in ddk/wdm.h!

Something is still wrong on my side, with Cygwin 3.6 on Windows 10:

Example:
 snip 
#define UNICODE 1
#define _UNICODE 1

#include 
#include 
#include 
#include 

int main(int ac, char *av[])
{
(void)printf("FileNormalizedNameInfo=%d/0x%x\n",
(int)FileNormalizedNameInfo,
(int)FileNormalizedNameInfo);

return EXIT_SUCCESS;
}
 snip 

Compiling this with $ gcc -Wall test4.c -o test4 # and running it returns this:
 snip 
$ ./test4
FileNormalizedNameInfo=22/0x16
 snip 
The expected output would be "FileNormalizedNameInfo=24/0x18", because
in 
https://learn.microsoft.com/de-de/windows/win32/api/minwinbase/ne-minwinbase-file_info_by_handle_class
|FileNormalizedNameInfo| is in position 24.

Looking at /usr/include/w32api/minwinbase.h:
 snip 
  typedef enum _FILE_INFO_BY_HANDLE_CLASS {
   FileBasicInfo /* is zero? */,
   FileStandardInfo,
   FileNameInfo,
   FileRenameInfo,
   FileDispositionInfo,
   FileAllocationInfo,
   FileEndOfFileInfo,
   FileStreamInfo,
   FileCompressionInfo,
   FileAttributeTagInfo,
   FileIdBothDirectoryInfo,
   FileIdBothDirectoryRestartInfo,
   FileIoPriorityHintInfo,
   FileRemoteProtocolInfo,
   FileFullDirectoryInfo,
   FileFullDirectoryRestartInfo,
#if _WIN32_WINNT >= 0x0602
   FileStorageInfo,
   FileAlignmentInfo,
   FileIdInfo,
   FileIdExtdDirectoryInfo,
   FileIdExtdDirectoryRestartInfo,
#endif
#if _WIN32_WINNT >= 0x0A02
   FileDispositionInfoEx,
   FileRenameInfoEx,
#endif
   FileCaseSensitiveInfo,
   FileNormalizedNameInfo,
   MaximumFileInfoByHandleClass
 } FILE_INFO_BY_HANDLE_CLASS, *PFILE_INFO_BY_HANDLE_CLASS;
#endif
 snip 

This code cannot work, because the integer value for
|FileNormalizedNameInfo| enum shift with different Windows versions,
e.g. |FileNormalizedNameInfo| has value |22| if |_WIN32_WINNT==0x0602|
but value |24| if |_WIN32_WINNT==0x0A02|.

I filed https://github.com/mingw-w64/mingw-w64/issues/48 for the
issue, but it would be nice if this can be fixed in both Cygwin 3.5
and 3.6...



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

Updated: cmus-2.11.0-1

[Federico Kircheis]

Version 2.11.0-1 of cmus has been uploaded.

cmus is a command line audio player

On GitHub it is possible to find the changelog for the new release:

https://github.com/cmus/cmus/releases

Federico

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

gdalinfo - Driver: GTiff/GeoTIFF Segmentation fault

[Jonas Ardö via Cygwin]

Hi

gdalinfo and other GDAL commands fail to access GTiff files properly 
(other formats works OK) with segmentation fault as a result.

I have used CYGWIN/GDAL without problems for years.
I don't know how to solve this.
Suggestions?

Regards
/Jonas


*$ gdalinfo --version*
GDAL 3.8.3, released 2024/01/04

Jonas.Ardo@JonasAr /cygdrive/D/tmp/JONAS
$ gdalinfo nh_65_7.tif
Driver: GTiff/GeoTIFF
Segmentation fault


*$ gdalinfo h18v02.2001001.img*
Driver: ENVI/ENVI .hdr Labelled
Files: h18v02.2001001.img
   h18v02.2001001.hdr
Size is 2400, 2400
Coordinate System is:
PROJCRS["Sinusoidal",
    BASEGEOGCRS["GCS_ELLIPSE_BASED_1",



*$ cygcheck -V
cygcheck (cygwin) 3.5.3
*System Checker for Cygwin
Copyright (C) 1998 - 2024 Cygwin Authors
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--
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: OpenMPI - Cannot find -lmpich file or directory

[marco atzeri via Cygwin]

On Mon, May 13, 2024 at 8:29 PM Karel Ziminsky via Cygwin  wrote:
>
> Hi,
>
>
> I am trying to install a software package that requires MPI support. I
> installed OpenMPI and the C and C++ libraries for Cygwin, but my software
> package is looking for an -lmpich extension that it cannot find.
>
> Could someone provide me more information on what this extension is for? Is
> there a different package I need to install for Cygwin that has it?
>
>
> V/r,
> --
> *Karel Ziminsky*

MPICH is not OpenMPI.

So or your software is looking for the wrong library , or it is not
correctly detecting OpenMPI

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

install error: xinit.sh exit code 3

[Harry Rockefeller via Cygwin]

I don't use those two Cygwin-X shortcuts that failed to be created by
mkshortcut when /etc/postinstall/xinit.sh tried to do that.  I commented
out those two lines near the end of xinit.sh.  I hope that has no unwanted
side effect(s).

-- 
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: calm: ncurses untest/vault previous version

[Jon Turney via Cygwin-apps]

On 13/05/2024 17:06, Brian Inglis via Cygwin-apps wrote:

On 2024-05-13 09:32, Jon Turney via Cygwin-apps wrote:

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all 
comparison chunks are equal, the string with any suffix remaining is 
the greater" clause of the comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.


Thanks Jon,

Missed that focusing on the versions not the labels in setup.ini.


(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)

I can vault the old versions but could someone please unvault 
6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?


Sorry, I should have noticed and untest-ed that immediately before 6.5!
Please remove test label to unvault as "prev" not test.
I've been running with it since released as test, until 6.5, and it is 
the final 6.4 we made available, in case anyone has issues with 6.5.


OK. Done.

6.4-20231230 was vaulted to stay under the count of kept versions.

OpenMPI - Cannot find -lmpich file or directory

[Karel Ziminsky via Cygwin]

Hi,


I am trying to install a software package that requires MPI support. I
installed OpenMPI and the C and C++ libraries for Cygwin, but my software
package is looking for an -lmpich extension that it cannot find.

Could someone provide me more information on what this extension is for? Is
there a different package I need to install for Cygwin that has it?


V/r,
-- 
*Karel Ziminsky*
kzim...@g.clemson.edu

-- 
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: calm: ncurses untest/vault previous version

[Brian Inglis via Cygwin-apps]

On 2024-05-13 09:32, Jon Turney via Cygwin-apps wrote:

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all comparison chunks 
are equal, the string with any suffix remaining is the greater" clause of the 
comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.


Thanks Jon,

Missed that focusing on the versions not the labels in setup.ini.


(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)


I can vault the old versions but could someone please unvault 6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?


Sorry, I should have noticed and untest-ed that immediately before 6.5!
Please remove test label to unvault as "prev" not test.
I've been running with it since released as test, until 6.5, and it is the final 
6.4 we made available, in case anyone has issues with 6.5.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: calm: ncurses untest/vault previous version

[Jon Turney via Cygwin-apps]

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all 
comparison chunks are equal, the string with any suffix remaining is the 
greater" clause of the comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.

(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)

I can vault the old versions but could someone please unvault 
6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?

Re: calm: ncurses untest/vault previous version

[Brian Inglis via Cygwin-apps]

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the previous version 
in the recommended format 6.4+20240330-1 was older than prev:


6.4-20231230
6.1-1.20190727
6.0-12.20171125
6.0-11.20170617
6.4-20240120

I can vault the old versions but could someone please unvault 6.4+20240330-1?

On 2024-05-12 07:47, cygwin-no-re...@cygwin.com wrote:

INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1-src.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1-src.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4+20240330-1.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114-src.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114-src.tar.xz
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114.hint
INFO: vaulting x86_64/release/ncurses/ncurses-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses++w10/libncurses++w10-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncurses-devel/libncurses-devel-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/libncursesw10/libncursesw10-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-debuginfo/ncurses-debuginfo-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/ncurses-demo/ncurses-demo-6.4-3.20230114.tar.xz
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4+20240330-1.hint
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4+20240330-1.tar.xz
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4-3.20230114.hint
INFO: vaulting x86_64/release/ncurses/terminfo/terminfo-6.4-3.20230114.tar.xz
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4+20240330-1.hint
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4+20240330-1.tar.xz
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-3.20230114.hint
INFO: vaulting 
x86_64/release/ncurses/terminfo-extra/terminfo-extra-6.4-3.20230114.tar.xz
SUMMARY: 36 INFO(s)


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Updated: ncurses/-demo terminfo/-extra libncurses/-devel/++/w10 6.5+20240427

[Cygwin ncurses Maintainer]

Terminal display utilities, demos, definitions, development, C and C++ libraries

The following packages have been upgraded in the Cygwin distribution:

* ncurses   6.5+20240427
* ncurses-demo  6.5+20240427
* terminfo  6.5+20240427
* terminfo-extra6.5+20240427
* libncurses-devel  6.5+20240427
* libncursesw10 6.5+20240427
* libncurses++w10   6.5+20240427

New curses is an emulation of Sys V R 4 curses, and more.
It uses and includes thousands of terminal definitions in terminfo
format, supports pads, color, multiple highlights, forms characters,
function key mapping, has all the other SVR4 curses enhancements
over BSD curses, plus terminal utilities, and demo programs packages.

For more information see the project home page:

https://invisible-island.net/ncurses

These packages have been available in test for a few weeks, and no
significant issues have been reported or patched, so this major release
is being promoted to current stable.

For changes since the previous Cygwin release, as there are multiple
components and many changes each release, see below or read
/usr/share/doc/ncurses/ANNOUNCE and /usr/share/doc/ncurses/NEWS after
installation:


20240427 6.5 release for upload to ftp.gnu.org
- update announcement
- fixes/corrections for manpages.
- fix redefinition of CASTxPTR, for legacy Unix.

20240420
- improve formatting/style of manpages.
- compiler warning/portability fixes.

20240414
- build/bug-fix for check-size feature.

20240413
- improve formatting/style of manpages.
- provide for padding in check-size feature, using new_prescr() to pass interim 
SCREEN pointer.
- complete change for opaque options.
- update package /debian/rules and related lintian overrides
- revise progs.priv.h to provide for NC_ISATTY reuse

20240330
- remove masking of ISIG in cbreak().
- modify test/test_mouse.c to use curses api for raw/noraw.
- improved configure macros from other program development:
  - build-fix for clang on Solaris
  - suppress filename/timestamp in gzip'd manpages

20240323
- modify tput/tset reset feature to avoid 1-second sleep if running in
  a pseudo-terminal.
- modify check-size feature to avoid using it in a pseudoterminal
- improve formatting/style of manpages.
- trim a space after some "-R" options, fixing builds for applications
  built using clang and ncurses on Solaris.

20240309
- modify xgterm to work around line-drawing bug
- use CSI 3J in vte-2017

20240302
- add configure check for MB_LEN_MAX, to provide warning as needed.
- improve formatting/style of manpages.
- fix regression in tput which disallowed hex/octal parameters
- update config.guess, config.sub

20240224
- improve man/curs_mouse.3x style.
- provide for CCHARW_MAX greater than 1
- eliminate use of PATH_MAX in lib_trace.c
- work around misconfiguration of MacPorts gcc13, which exposes invalid
  definition of MB_LEN_MAX in gcc's fallback copy of limits.h.

20240217
- add vt100+noapp, vt100+noapp+pc, xterm+app+pc, xterm+decedit from
  xterm #389
- fix inconsistent description of wmouse_trafo().
- modify wenclose() to handle pads.
- improve manpage discussion of mouseinterval().

20240210
- compiler-warning fixes, while investigating an optimizer bug in
  MacPorts gcc13 13.2.0_4+stdlib_flag which results in only the first
  byte of a multibyte character being printed to the screen.

20240203
- minor changes to tracing and locale-checks.

20240127
- amend change to z39-a.
- use xterm+nopcfkeys, vt52-basic, dec+pp, dec+sl, vt52+arrows,
  hp+pfk+cr, klone+acs, klone+color, klone+sgr, ncr160wy50+pp
  to trim
- NetBSD-related fixes for x68k and wsvt52


ncurses 6.5 April 27, 2024

This release is designed to be source-compatible with ncurses 5.0
through 6.4; providing extensions to the application binary interface
(ABI).
Although the source can still be configured to support the ncurses 5
ABI, the reason for the release is to reflect improvements to the
ncurses 6 ABI and the supporting utility programs.

There are, of course, numerous other improvements, listed in this
announcement.

The most important bug-fixes/improvements dealt with robustness issues. 
The release notes also mention some other bug-fixes, but are focused on
new features and improvements to existing features since ncurses 6.4
release.

Library improvements

New features

These are new features:

- The low-level terminfo and termcap interfaces are used both by the
  higher-level curses library, as well as by many applications.
  The functions which convert parameterized terminal capability strings
  for output to the terminal (tiparm and tparm) analyze the capability
  string to determine which parameters are strings (i.e., addresses),
  versus numbers (not addresses).
  The library's analysis of a capability string may differ from the
  calling application's design if environment variables are used to
  point to an invalid terminal database.
  This is a longstanding problem with all 

Updated: bash-completion/-devel 2.14

[Cygwin bash-completion Maintainer]

Command options and arguments auto-completion under the Bash shell

The following packages have been upgraded in the Cygwin distribution:

* bash-completion   2.14
* bash-completion-devel 2.14

bash-completion provides auto-completion for options of and arguments to
hundreds of commands; and a collection of shell functions to develop
those using the bash programmable completion commands.

For more information see the project home page:

https://github.com/scop/bash-completion

See below for changes since the last Cygwin release: for full details
see /usr/share/doc/bash-completion/CHANGELOG.md after installation or:

https://github.com/scop/bash-completion/blob/master/CHANGELOG.md


2.14.0  2024-05-09

Features

- cryptsetup: complete --header with filenames
- env: complete commands and variable assignments
- env: treat `-*` as the command name after `-` and `--`
- env: treat `-*` as the command name after assignments
- ip: Complete 'route get' options
- ip: Complete addr add/change/replace options
- ip: Complete ip route list options
- ip: Complete link afstats command
- ip: Complete neigh add, del, change, replace
- ip: Complete route save/showdump
- iperf: --tos/-S argument completion
- ssh-copy-id: (non-)complete args to `-t` and `-F`
- ssh-keygen: complete -r/-Y specific -O args
- ssh-keyscan: complete -O argument

Bug Fixes

- _comp_{compgen,xfunc}: use `declare -F --` for arbitrary funcs
- _comp_{load,realcommand}: handle option-like command name
- available_interfaces: strip only trailing colon from entries
- bash_completion,conftest: use `complete -p --` for arbitrary cmds
- fio: engines completion
- ip: Complete link change as well as set
- ip: Don't stop at proxy and nomaster in neigh
- scp remote_files: do not filter generated paths with "$cur"
- scp remote_files: localize variable `cur`
- ssh-keygen: handling of bundled short options
- ssh-keygen: make work with custom IFS
- ssh-keygen: suggest -O arg completions depending on mode
- use -- to pass arbitrary cmdnames to `_comp_load`
- use `pathcmd=$(type -P -- "$1")` for arbitrary cmds

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: Perl distributions

[ASSI]

The following Perl distributions have been updated to their latest
release version available on CPAN:

noarch
--
 perl-Business-ISBN-Data-20240509.001-1
 perl-Path-Tiny-0.146-1
 perl-Test-Compile-3.3.3-1

-- 
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: upx-4.2.4-1

[ASSI]

UPX has been updated to version 4.2.4, see the release news for changes:

https://upx.github.io/upx-news.txt

UPX is a free, portable, extendable, high-performance executable packer
for several executable formats.

-- 
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...

[Brian Inglis via Cygwin]

On 2024-05-11 05:30, Roland Mainz via Cygwin wrote:

I'm writing a test program for |FileNormalizedNameInfo| right now (see
https://rovema.kpaste.net/07074abc).
Per 
https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ne-minwinbase-file_info_by_handle_class
|FileNormalizedNameInfo| should be |24|, but on Cygwin 3.6 I get the
value |48|.
Since |GetFileInformationByHandleEx()| gives me error 87 (="Invalid
Parameter") for |48|, but works as intended for |24| I assume that the
Cygwin header is wrong.

Could someone please check the Cygwin header files ?


Could someone please read the enum constant names and classes carefully?

Package w32api-headers:


Headers:
 snip 
$ grep -r FileNormalizedNameInfo /usr/include/
/usr/include/w32api/ddk/wdm.h:  FileNormalizedNameInformation,
/usr/include/w32api/minwinbase.h:*FileNormalizedNameInfo*,
/usr/include/w32api/winternl.h:FileNormalizedNameInformation = 48,
 snip 


*FileNormalizedNameInfo* 24/0x18 is defined in minwinbase.h 
FILE_INFO_BY_HANDLE_CLASS for GetFileInformationByHandleEx whereas 
*FileNormalizedNameInformation* 44/0x2e is defined in winternl.h 
FILE_INFORMATION_CLASS for NtQueryInformationFile:


https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile

ditto in ddk/wdm.h!

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: Build machines

[ASSI via Cygwin-apps]

ASSI via Cygwin-apps writes:
>> I misremembered the code names.  The direct successor to the 7735HS
>> (Rembrandt Refresh) are the 7840HS / 7940HS (Phoenix-H at 8 cores and
>> upgraded to 4nm Zen4/RDNA3 and about 15% better performance per Watt);
>> the upcoming 16 core is the 7945HX (Dragon Range, 5nm Zen4/RDNA2).
>
> The Phoenix mini PC are starting to appear right now, about 15%…20% more
> performance for about 150€…200€ higher price (about 40…50%) right now.
> Still waiting for Dragon Range, first teasers have popped up, so I think
> it'll be available before the end of the year.

I've finally got my hands on that Dragon Range mITX motherboard, paired
it with 96 GiB memory, 2×4TB NVMe and built it into a nice small
form-factor case.  I've decided to run it under Linux for now and
virtualize Windows via KVM.  Running the gcc compilation test as before,
but with a different version of gcc to be built and the objdump
improvements, so not directly comparable.  I'll see if and when I can
re-do the older tests with the current versions later.

   | Processor  | HW | Core| TDP |  Base | Turbo | aTurbo | 
L1i/L1d+L2 |L3 | Mem |  comp |  inst |  pack |  test |   tot |
   ||| | [W] | [MHz] | [MHz] |  [MHz] | 
[kiB]  | [MiB] | [GiB/s] | [min] | [min] | [min] | [min] | [min] |
   
|++-+-+---+---+++---+-+---+---+---+---+---|
   | Xeon E3-1276v3 | 1S/4C/8T   | Haswell |  84 |  3600 |  4000 |   3800 | 
32/32+256  | 8 |25.6 |   101 |15 | 9 |   445 |   570 |
   | EPYC 7252  | 2S/16C/32T | Zen2| 120 |  3100 |  3200 |   3200 | 
32/32+512  |   128 |   170.6 |   123 | 9 |10 |   200 |   342 |
   | Ryzen 7735HS   | 1S/8C/16T  | Zen3+   |  54 |  3200 |  4750 |   3850 | 
32/32+512  |16 |75.0 |68 |32 | 7 |   200 |   307 |
   
|++-+-+---+---+++---+-+---+---+---+---+---|
   | Ryzen 7845HX   | 1S/16C/32T | Zen4|  75 |  3000 |  5200 |   4000 | 
32/32+1024 |64 |81.2 |43 | 2 | 4 |   122 |   171 |

Efficiency wise this (expectedly) doesn't quite reach the level of the
miniPC for low and medium load, hovering around 23W at idle under Linux
and 60W with the Windows VM started and idling, peaking at about 130W
under full load, which makes it slightly more efficient than two miniPC
for this scenario.  Virtualization seems to consume around two cores
with high filesystem activity, so maybe bare-metal via dual-boot would
help a bit.  I can't test direct hardware passthrough for disks at the
moment, which might also help.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Wrong value for |FileNormalizedNameInfo| (|24| vs. |48|) in Cygwin 3.6 /usr/include ...

[Roland Mainz via Cygwin]

Hi!



I'm writing a test program for |FileNormalizedNameInfo| right now (see
https://rovema.kpaste.net/07074abc).

Per 
https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ne-minwinbase-file_info_by_handle_class
|FileNormalizedNameInfo| should be |24|, but on Cygwin 3.6 I get the
value |48|.
Since |GetFileInformationByHandleEx()| gives me error 87 (="Invalid
Parameter") for |48|, but works as intended for |24| I assume that the
Cygwin header is wrong.

Could someone please check the Cygwin header files ?

Headers:
 snip 
$ grep -r FileNormalizedNameInfo /usr/include/
/usr/include/w32api/ddk/wdm.h:  FileNormalizedNameInformation,
/usr/include/w32api/minwinbase.h:FileNormalizedNameInfo,
/usr/include/w32api/winternl.h:FileNormalizedNameInformation = 48,
 snip 

Cygwin version:
 snip 
$ uname -a
CYGWIN_NT-10.0-19045 okkoto 3.6.0-0.115.g579064bf4d40.x86_64
2024-04-09 21:11 UTC x86_64 Cygwin
 snip 



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

-- 
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: New installation of Cygwin64: xinit.sh exit code 3

[Frank-Ulrich Sommer via Cygwin]

I seem to have almost excatly the same problem except that I could not solve it 
by removing the Cygwin-X folder. In this case during the reinstallation of the 
xinit package the folder is recreated again and then the original error message 
(xinit.sh exit code 3) reappears. The directory again has strange permissions  
when checked with Windows Explorer and I am not allowed the enter it or see its 
contents before resetting the security settings.

When doing an "ls -l" (within Cygwin) in the "Start Menu" folder the group and 
owner for the Cygwin-X directory seem to be reversed compared to other folders manually created 
from Windows Explorer (i.e. the user name appears in the group column and vice versa) but I'm not 
sure if this is important:

d---rwxr-x+ 1 myusername Administratoren    0 May 10 02:27  Cygwin-X

For all other folders the group is displayed before the username.

I had to fix the security settings for the Cygwin-X folder and then manually execute the last two 
"mkshortcut" commands from "/etc/postinstall/xinit.sh" (replacing $CYGWINFORALL with 
"-A" and ${wow64} with an empty string).

Should this be the only problem and should my "fix" be correct? And is there 
anything I can do to help find the cause for this problem?



On 23.10.2023 17:41, Brian Inglis via Cygwin wrote:

On 2023-10-23 06:05, Fergus Daly via Cygwin wrote:

<< Detail >>


When I used Explorer to visit C:\ProgramData\Microsoft\Windows\Start 
Menu\Cygwin-X I was told:
"You don't currently have permission to access this folder"
and clicking on Continue to get access I was told:
"You have been denied permission to access this folder"
There was then offered an option to edit Permissions which I didn't feel like 
pursuing.
(I am the Administrator on my own standalone Windows machine. The denial of 
access to Cygwin-X feels odd.
PS I also have Cygwin32 installed and running. I _am_ permitted access to the 
equivalent folder Cygwin-X (32-bit).)



Please try running the following command/s, under Cygwin 32 and 64, and posting
the outputs:



$ for p in "`cygpath -A -P -U`"{,/Cygwin-X}; do for c in 'lsattr -d' 'ls -dl'
getfacl; do $c "$p"; echo; done; icacls "`cygpath -m "$p"`"; done


Thank you. (Again.)
1. Actually before reading this I had deleted both folders
(successfully, despite not being permitted entry into one
of them) and the re-ran the xinit installation with no
bother at all.
I'm guessing the Permissions glitch resulted from some local
recent accidental keypress or sequence.
2. icacls? Haven't got this though I have got getfacl; found icacl in
"Search packages" under libattica-devel and ng-spice-debuginfo?


$ /proc/cygdrive/c/WINDOWS/system32/icacls /?




--
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: couldn't write bp1, panic!

[cygwinautoreply--- via Cygwin]

> ***
> *  Installing Permanent Root  *
> ***

> ***
> * Activating Fastboot (4002)  *
> ***

>4561 KB/s (510876 bytes in 0.109s)
>couldn't write bp1, panic!

> The kindle has been told to reboot in Fastboot Mode.

> twrp.img is missing.
> So we will download it for you!

>  1 [main] cat 4192 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>wget: missing URL
>Usage: wget [OPTION]... [URL]...

>Try `wget --help' for more options.
> Download successful.
> fff.bin is missing.
> So we will download it for you!

>  1 [main] cat 11280 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>  2 [main] cat 10388 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>wget: missing URL
>Usage: wget [OPTION]... [URL]...

>Try `wget --help' for more options.
>Cannot open input file recovery\fff.bin
> Download successful.

> ***
> *NOTICE   *
> ***

>  1 [main] cat 4948 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>  1 [main] cat 11904 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com

> Fastboot uses a different device than ADB.
> You should check device manager for "Kindle" or "Amazon"

> If you see it, rerun the driver installer that came packaged with KFU.

> Installing FFF...
>< waiting for device >
>^CTerminate batch job (Y/N)? Y


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

couldn't write bp1, panic!

[PS Fun via Cygwin]

 ***
 *  Installing Permanent Root  *
 ***

 ***
 * Activating Fastboot (4002)  *
 ***

4561 KB/s (510876 bytes in 0.109s)
couldn't write bp1, panic!

 The kindle has been told to reboot in Fastboot Mode.

 twrp.img is missing.
 So we will download it for you!

  1 [main] cat 4192 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
 Download successful.
 fff.bin is missing.
 So we will download it for you!

  1 [main] cat 11280 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  2 [main] cat 10388 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
Cannot open input file recovery\fff.bin
 Download successful.

 ***
 *NOTICE   *
 ***

  1 [main] cat 4948 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] cat 11904 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com

 Fastboot uses a different device than ADB.
 You should check device manager for "Kindle" or "Amazon"

 If you see it, rerun the driver installer that came packaged with KFU.

 Installing FFF...
< waiting for device >
^CTerminate batch job (Y/N)? Y

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

double-fork issue on Windows on ARM64

[Jeremy Drake via Cygwin-developers]

(this is the same issue discussed in
https://cygwin.com/pipermail/cygwin-patches/2024q1/012621.html)

On MSYS2, running on Windows on ARM64 only, we've been plagued by issues
with processes hanging up.  Usually pacman, when it is trying to validate
signatures with gpgme.  When a process is hung in this way, no debugger
seems to be able to attach properly.

After many months of off-and-on progress trying to debug this, we've
*finally* got an idea of what behavior is causing this, and a standalone
reproducer that runs on Cygwin.

> A common symptom is that the hanging process has a command-line that is
> identical to its parent process' command-line (indicating that it has
> been fork()ed), and anecdotally, the hang occurs when _exit() calls
> proc_terminate() which is then blocked by a call to TerminateThread()
> with an invalid thread handle (for more details, see
> https://github.com/msys2/msys2-autobuild/issues/62#issuecomment-1951796327).
>
> In my tests, I found that the hanging process is spawned from
> _gpgme_io_spawn() which lets the child process immediately spawn another
> child. That seems like a fantastic way to find timing-related bugs in
> the MSYS2/Cygwin runtime.
>
> As a work-around, it does seem to help if we avoid that double-fork.

That led me to make the attached reproducer, which is based on the code
from _gpgme_io_spawn.  I originally expected that this would require some
timing adjustment, hence the defines to change the binary and argument (I
expected to use /bin/sleep and different values).  It turns out, this
reproduces readily with /bin/true.

I build this with `gcc -ggdb -o testfork testfork.c`, and this reproduces:
* on a Raspberry PI 4 running Windows 10, with an i686 msys2 runtime
* on a QC710 running Windows 11 23H2, with x86_64 msys2 runtime (this
seems to reproduce it most readily).
* on a hyper-v virtual machine on Dev Kit 2023 running Windows 11 23H2,
with x86_64 msys2 runtime or Cygwin 3.5.3.  This seems to require running
two instances of testfork.exe at the same time.

When attaching to the hung process, gdb shows
(gdb) i thr
  Id   Target IdFrame
  1Thread 6516.0xbe8error return
/cygdrive/d/a/scallywag/gdb/gdb-13.2-1.x86_64/src/gdb-13.2/gdb/windows-nat.c:748
was 31: A device attached to the system is not functioning.
0x in ?? ()
  2Thread 6516.0x1b28 "sig" 0x7ff8051a8a64 in ?? ()
* 3Thread 6516.0x12b4   0x7ff8051b4374 in ?? ()


Let me know if I can provide any additional info, or anything else we can
try to help debug this.#include 
#include 
#include 

#ifndef BINARY
#define BINARY "/bin/true"
#endif

#ifndef ARG
#define ARG "0.1"
#endif

int main(int argc, char ** argv)
{
	while (1)
	{
		int pid;
		printf("Starting group of 100x " BINARY " " ARG "\n");
		for (int i = 0; i < 100; ++i)
		{
			pid = fork();
			if (pid == -1)
			{
perror("fork error");
return 1;
			}
			else if (pid == 0)
			{
if ((pid = fork()) == 0)
{
	char * const args[] = {BINARY, ARG, NULL};
	execv(BINARY, args);
	perror("execv failed");
	_exit(5);
}
if (pid == -1)
{
	perror("inner fork error");
	_exit(1);
}
else
{
	_exit(0);
}
			}
			else
			{
int status;
if (waitpid(pid, , 0) == -1)
{
	perror("waitpid error");
	return 2;
}
else if (status != 0)
{
	fprintf(stderr, "subprocess exited non-zero: %d\n", status);
	return WEXITSTATUS(status);
}
			}
		}
	}
	return 0;
}

unbound 1.20.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* unbound-1.20.0-1
* libunbound8-1.20.0-1
* libunbound-common-1.20.0-1
* libunbound-devel-1.20.0-1
* python3-unbound-1.20.0-1

Unbound is a validating, recursive, and caching DNS resolver.
Unbound is designed as a set of modular components, so that also DNSSEC
validation and stub-resolvers (that do not run as a server, but are linked
into an application) are easily possible.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

SIGALRM is not interrupting a blocking write to a pipe

[ilya Basin via Cygwin]

Hi List!

I need your help with troubleshooting an issue with "pv": 
https://codeberg.org/a-j-wood/pv/issues/87

This app uses SIGALRM to interrupt a blocking write to STDOUT and read more 
data into the buffer.
On Linuxes write() returns 0 after the signal, but on Cygwin even though the 
signal handler is called, the write call does not return, at least when writing 
to a pipe.

In the user guide it says "All sockets are non-blocking under the hood to allow 
to interrupt blocking calls by POSIX signals". It doesn't mention pipes, but I 
think the pipes should also be non-blocking under the hood.

In main.c the use of O_NONBLOCK is commented with "this can cause problems with 
(broken) applications such as dd". If I uncomment it the app is able to detect 
that the pipe is ready for writing. Have you ever heard about O_NONBLOCK 
breaking dd?


-- 
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: calm: vaulting ancient unifont

[Brian Inglis via Cygwin-apps]

On 2024-05-06 09:27, Jon Turney via Cygwin-apps wrote:

On 04/05/2024 20:21, Brian Inglis via Cygwin-apps wrote:

Thanks Jon? - yay!


Right, I deployed some changes to calm which will gradually let us get rid of 
the "old-style" of obsoletion (where, as here, the old name of a package (i.e. 
font-unifont-misc, font-unifont-ttf) continues to exist with a category of 
_obsolete and requires: its replacement)


(cygport stopped generating these some time ago (0.34.1, 2022), but they've been 
lingering around indefinitely, because in some cases it's only the existence of 
these packages which currently records the fact of the obsoletion)



Since someone's bound to get the wrong end of the stick: This doesn't mean 
package maintainers should change anything.


And just to reiterate: As a principle, every version of a package must contain 
complete instructions for upgrading to it. So, it is almost never correct to go 
"I'll remove these OBSOLETE instruction after one package release with them, 
since they've already happened everywhere..."


On 2024-05-04 09:48, cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org 
wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz

SUMMARY: 8 INFO(s)


Anyhow, double checking that the "right thing" happened here, I notice that 
'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, especially 
since it contains the expected .dbg files etc.


Brian,

Are you sure that's right?


It appears not!
My reasoning was that as unifont-viewer was split out from unifont-fonts, 
unifont-viewer-debuginfo would be generated, but it appears that is not how that 
works.
Is there any way to make that work, or should I just drop it in the next 
release, or a new -RELEASE?


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

On 2024-05-06 09:52, Jon Turney via Cygwin-apps wrote:

On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:
Some package upstreams offer only checksums, for example .sha512sum, 
.sha256sum, for verification rather than gpg signatures, for example

.asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed
on download to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;

use coreutils cksum as it supports all modern and legacy checksums and formats.



https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d


Two similar independent implementations mean it would be a good idea to add 
the feature!


Mine preferred cksum as being the most general approach, while not worrying or 
knowing too much about ancient sums, although your implementation is better, 
that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes only 
without sum, not enumerating them all in the unpack() case, and respecting the 
cksum crc default.


I guess this makes sense as a part of the fetch operation, in those cases where 
upstream provides signatures or checksums.


I will retry incorporating Achim's approach so hopefully we can both retire our 
local cygport patches.


I would also appreciate other comments or feedback to my reply to Achim's NAK on 
my patch for `gpgv` replacing `gnupg2 --verify`?


But as briefly discussed in [1], independently of that it would also be a good 
idea for cygport to specify it's own checksum file, which is incorporated into 
the source package, and verified at build prep time.


As in Fedora RPM package `sources` BSD-style sum prefix, for example (one line):

https://src.fedoraproject.org/rpms/bash-completion/blob/rawhide/f/sources
SHA512 (bash-completion-2.13.0.tar.xz) = 
7c65fea599a25c2c9d6ef300a9cc2d5fbabd0bcc9e09fe32bb706d3398936f40501171f03280f042465bc0d9aca4b1b53c2c13a99bbdfb6fe916767a267158af


or also in the source package for cygport and each source file included, as in 
Debian dsc, for example:


https://deb.debian.org/debian/pool/main/b/bash-completion/bash-completion_2.13.0-1.dsc
Checksums-Sha1:
 0c045cc06b57bbe8945bc6c4ea8f2b52f1285903 484155 
bash-completion_2.13.0.orig.tar.gz
 66f10d161e71c0725a61d5bde1c6b89f9bdb61e3 17840 
bash-completion_2.13.0-1.debian.tar.xz

Checksums-Sha256:
 6c1cc04bb506e7ba6bd7bb3c7c6f6ad2b46e6198e8ef4c88139597250601 484155 
bash-completion_2.13.0.orig.tar.gz
 d2de6c33d14843da64e4b20e6330c14079b2c73f04c9b4c544d6435930003a67 17840 
bash-completion_2.13.0-1.debian.tar.xz

Files:
 93527b12850a781744e3f335f904bdf1 484155 bash-completion_2.13.0.orig.tar.gz
 a831ae35940daf95016fce1b655955a1 17840 bash-completion_2.13.0-1.debian.tar.xz

(Since this would protect against such screw ups, help with build 
reproducibility, and defend against supply chain attacks on upstream)


[1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html


Coreutils `cksum` does BSD-style checksums, although I would prefer sha256 sums 
for brevity and consistency with setup.ini, and base64 encoding rather than hex 
to shorten the checksum representation, in recent coreutils.


We all have SSH keys, which I also have as a GPG key, could we also use them for 
signing source packages?
Calm could validate ours and checksums, and re-sign with Cygwin key, which setup 
could validate.

Could osslsigncode have any application here?

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Jon Turney via Cygwin-apps]

On 01/05/2024 17:48, Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:
Some package upstreams offer only checksums, for example .sha512sum, 
.sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, 
.sign, etc;
use these checksum files when provided in a similar manner to gpg 
signatures;
these files are often provided with fixed names which may be renamed 
on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums 
and formats.



https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d


Two similar independent implementations mean it would be a good idea to 
add the feature!


Mine preferred cksum as being the most general approach, while not 
worrying or knowing too much about ancient sums, although your 
implementation is better, that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes 
only without sum, not enumerating them all in the unpack() case, and 
respecting the cksum crc default.


I guess this makes sense as a part of the fetch operation, in thsose 
cases where upstream provides signatures or checksums.



But as briefly discussed in [1], independently of that it would also be 
a good idea for cygport to specify it's own checksum file, which is 
incorporated into the source package, and verified at build prep time.


(Since this would protect against such screw ups, help with build 
reproducibility, and defend against supply chain attacks on upstream)


[1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html

Re: calm: vaulting ancient unifont

[Jon Turney via Cygwin-apps]

On 04/05/2024 20:21, Brian Inglis via Cygwin-apps wrote:

Thanks Jon? - yay!


Right, I deployed some changes to calm which will gradually let us get 
rid of the "old-style" of obsoletion (where, as here, the old name of a 
package (i.e. font-unifont-misc, font-unifont-ttf) continues to exist 
with a category of _obsolete and requires: its replacement)


(cygport stopped generating these some time ago (0.34.1, 2022), but 
they've been lingering around indefinitely, because in some cases it's 
only the existence of these packages which currently records the fact of 
the obsoletion)



Since someone's bound to get the wrong end of the stick: This doesn't 
mean package maintainers should change anything.


And just to reiterate: As a principle, every version of a package must 
contain complete instructions for upgrading to it. So, it is almost 
never correct to go "I'll remove these OBSOLETE instruction after one 
package release with them, since they've already happened everywhere..."


On 2024-05-04 09:48, 
cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz

SUMMARY: 8 INFO(s)


Anyhow, double checking that the "right thing" happened here, I notice 
that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, 
especially since it contains the expected .dbg files etc.


Brian,

Are you sure that's right?

cygport 0.36.9-1

[Jon Turney]

The following packages have been uploaded to the Cygwin distribution:

* cygport-0.36.9-1

cygport is the standard method for building and maintaining packages for 
the Cygwin distribution.



Christian Franke (7):
  Use correct wording if only one package is announced
  Fix variable expansion in error message of embedded SMTP perl script
  Modify origsrc timestamp in patch files if SOURCE_DATE_EPOCH is used
  dodoc: Document handling of .md, .rst and .txt extensions
  Add repro-build, repro-diff und repro-check commands
  dodoc: Skip a file if a compressed version already exists
  Add repro-finish command

Daisuke Fujimura (1):
  Avoid using ruby to look for dependencies when building ruby package

Jon Turney (6):
  Update copyrights to 2024
  Update supported WX_VERSION range listed in doc
  Correct logic for suppressing cygwin-debuginfo self-requires
  Avoid the package's provides appearing in requires
  CI: Update deprecated github actions
  Bump version to 0.36.9

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package

[Jon Turney via Cygwin-apps]

On 03/04/2024 15:18, Daisuke Fujimura via Cygwin-apps wrote:

Thank you for reviewing this.


Can you clarify what the "failure" is here?



[...]


/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)


[...]

Thanks very much for the detailed explanation.

So this is an error (or warning?) generated by invoking the 
not-yet-properly installed, just-built ruby in ${D}.


I applied your patch.


On Sun, Mar 10, 2024 at 10:34 PM Jon Turney  wrote:


On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote:

Attempting to create a package for ruby-3.3, but it fails when trying
to detect a dependency on itself.


Thanks for this patch.

Can you clarify what the "failure" is here?


To avoid this, skip them if the target is `ruby`.


The second hunk seems like a removes the dependency on ruby_xy for the
ruby package, which also provides ruby_xy.

Historically, we've allowed self-dependencies like this, because they
seem to be benign, although it seems like we could do with some generic
code to suppress them


... except I added something to generically prevent a packages provides: 
appearing it it's requires:

Re: AndeSight Problem

[cygwinautoreply--- via Cygwin]

>您好：
>
>我正使用AndeSight 開發 Hycon的MCU Firmware，
>最近突然跳出此警示，
>1 [main] make 20416 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
>pointer.  Please report this problem to the public mailing list
>cygwin@cygwin.com
>請問該如何解決?
>會影響到Firmware的功能嗎?
>
>Best regards,
>
>Shao-Hung, Lu 呂紹弘
>鑠騰生醫科技有限公司 69761285
>Ritum Biomedical Company, Limited.
>(M)：0986610696
>E-Mail：how9...@gmail.com
>


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

AndeSight Problem

[呂紹弘 via Cygwin]

您好：

我正使用AndeSight 開發 Hycon的MCU Firmware，
最近突然跳出此警示，
1 [main] make 20416 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to the public mailing list
cygwin@cygwin.com
請問該如何解決?
會影響到Firmware的功能嗎?

Best regards,

Shao-Hung, Lu 呂紹弘
鑠騰生醫科技有限公司 69761285
Ritum Biomedical Company, Limited.
(M)：0986610696
E-Mail：how9...@gmail.com


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

RFC: postinstall fontconfig cache changes

[Brian Inglis via Cygwin-apps]

Hi folks,

Since Yaakov added the fontconfig cache postinstall script, it has been 
selecting only fonts created by 'Microsoft Corp' and (recently?) matching 
'*.ttf' (lower case only) for whatever reasons?


I have been running my own attached local fontconfig cache postinstall script, 
with some tweaks, such as putting my symlinks into font directory 'windows' 
instead of fontconfig package's 'microsoft', using `cygpath -UW` so the symlinks 
to Windows/Fonts created survive changes I made to cygdrive over the years, 
adding .ttf fonts not created by 'Microsoft Corp' including those only 
'Microsoft supplied', original Windows .TTF (uppercase) fonts installed with the 
system, .ttc font collections which are supported by recent fontconfig, and .otf 
OpenType fonts provided with newer font packages, as Pango and Harfbuzz do not 
appear to support some recent TrueType hinting changes.


I also have to clean up the cache directory, as it sometimes got to *many* 1000s 
of cache files, taking up GB, a known but unsolved? (may now be fixed) issue 
with "broken" [see NEWS] font cache handling, whereas after resetting it has 
only dozens of cache files taking a dozen MB, created in ~10s for ~3600 fonts, 
from Windows, packages, and local downloads and installs.


I would like to request consideration for adding all Windows fonts of supported 
types of any case to the cache every startup.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry#!/bin/dash
# zp_l_fontconfig_cache.dash - update Windows non-MS Corp ttf, TTF, ttc, and 
otf font links and rebuild font cache

winfontsdir=/usr/share/fonts/windows
cache=/var/cache/fontconfig
mscorp='Microsoft Corp'
win="$(cygpath -UW)/Fonts"  # ln to /proc/cygdrive in case mount changes 
later

/bin/mkdir -p $winfontsdir

# remove any broken links (-L -type l together)
/usr/bin/find -L $winfontsdir -type l -delete

# find Windows .TTF, .otf, .ttc and non-MS Corp .ttf fonts and link between 
fonts dirs
# Notes:
# system 
# DUBAI-*, MTEXTRA, others are 'Microsoft supplied font';
# all *.TTF are 'Microsoft Corp'; some are also 'Microsoft supplied font';
# .../Fonts may have Deleted subdirectory;
# grep -L returns names of files with no pattern matches;
# fontconfig handles ttc TrueType collections and otf OpenType fonts
/usr/bin/find "$win" -maxdepth 1 -type f\
   \(  -name '*.ttf' -exec /bin/grep -FaL "$mscorp" '{}' + \)   \
-o \(  -name '*.TTF' -print \)  \
-o \( -iname '*.ttc' -print \)  \
-o \( -iname '*.otf' -print \)  | \
while read f
do
[ -e "$winfontsdir/${f##*/}" ] || /bin/ln -st $winfontsdir/ "$f"
done

/usr/bin/mkfontscale$winfontsdir
/usr/bin/mkfontdir  $winfontsdir

# get cache file suffix currently -le64.cache-9 from latest fontconfig dll
dll=$(/bin/ls -rv /bin/cygfontconfig-*.dll | /usr/bin/head -n1)
suf=$(/bin/grep -Eao '[[:graph:]]*\.cache-[[:graph:]]+' $dll)

# cleanup cache every install - can become 100k+ files using GBs
/bin/rm -f $cache/*$suf
/usr/bin/find $cache -iname "*$suf" -delete

# reset and cache system dirs
/usr/libexec/fc-cache-1 -rs || :

# ensure TAG later for cleanup cron job
/usr/bin/touch -c $cache/CACHEDIR.TAG

RE: [ITP] perl-Parse-Yapp-1.21

[Ziemowit Laski via Cygwin-apps]

Achim,

I stumbled upon this dependency while building smbclient (which _is_ useful on 
Windows, BTW).

Methinks you should package this if you believe that other people might find it 
useful.  Also, I really can't foresee any maintenance burdens moving forward.

Please tell me if/how to proceed.  Thanks,

--Zem

> -Original Message-
> From: ASSI 
> Sent: Saturday, May 4 2024 8:55
> To: cygwin-apps@cygwin.com
> Subject: Re: [ITP] perl-Parse-Yapp-1.21
> 
> Ziemowit Laski via Cygwin-apps writes:
> > This is a straightforward port, akin to other Perl packages.
> 
> The question is: what do you need it for and why should it get packaged
> in Cygwin?
> 
> […]
> > I can be the maintainer-at-large for this if you'd like.
> 
> I'd rather not have separate maintenance of random Perl packages, so if
> it gets accepted into Cygwin I would suggest to assign it to me.
> 
> 
> 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

Updated: Perl distributions

[ASSI]

The following Perl distributions have been updated to their latest
release version available on CPAN:

x86_64
--
 perl-GD-2.81-1
 perl-XS-Parse-Keyword-0.42-1

noarch
--
 perl-CPAN-Changes-0.54-1
 perl-Net-DNS-1.45-1
 perl-Test-Compile-3.3.2-1

-- 
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

lynx 2.9.1 available

[Brian Inglis via Cygwin-apps]

Package lynx seems to have moved on from lynx.browser.org which is outdated at 
2.8.8, to lynx.invisible-island.net where 2.9.1 is the latest stable release 
following on from 2.9.0:


https://lynx.invisible-island.net/index.html

https://lynx.invisible-island.net/lynx.html

https://lynx.invisible-island.net/release/index.html

https://invisible-island.net/archives/lynx/tarballs/\
lynx2.9.1.tar.bz2{,.asc}

https://github.com/ThomasDickey/lynx-snapshots/tags

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Updated: tack 1.10+20240501

[Cygwin tack Maintainer]

terminfo file diagnostic

The following packages have been upgraded in the Cygwin distribution:

* tack  1.10+20240501

Terminfo Action ChecKer is a diagnostic designed to create,
verify, and refine terminal information descriptions.

For more information see the project home page:

https://invisible-island.net/ncurses/tack.html

For changes please see below or read /usr/share/doc/tack/CHANGES
after installation:

https://invisible-island.net/ncurses/tack/CHANGES.html


1.102024-05-01

- init.c, configure.in, package/tack.spec, package/debian/changelog,
  tack.h, HISTORY: bump to 1.10
- configure: regen
- configure.in: add a configure-check if terminfo functions use "const"
  strings, to fix compiler warnings with NetBSD
- init.c, edit.c: gcc warning (NetBSD)
- edit.c: check to avoid printing a non-printable character, per Coverity
- tack.c: initialize variables, per Coverity
- aclocal.m4: correction for CF_ANSI_CC_CHECK, works around MacOS "c89"
  confusion of "-O"
- tack.1: change limit for SGR tool to allow for aixterm's colors
- ansi.c: change the SGR tool to show up to 120 (past aixterm's 108)
- color.c: when reloading the colors 0-7, use the index for the named
  color rather than just the array-index (fixing an interchanged
  red/blue for instance). Also, initialize the palette using the ANSI
  codes if the terminal supports setaf/setab.
- color.c, charset.c, ansi.c, edit.c, crum.c, pad.c, tack.c, tack.h:
  use "const" in a few places reported by cppcheck
- tack.1: improve formatting/style
- aclocal.m4: resync with my-autoconf, fixing compiler-warnings inside
  configure script
- config.sub, config.guess: update

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Updated: bash-completion/-devel 2.13

[Cygwin bash-completion Maintainer]

Command options and arguments auto-completion under the Bash shell

The following packages have been upgraded in the Cygwin distribution:

* bash-completion   2.13
* bash-completion-devel 2.13

bash-completion provides auto-completion for options of and arguments to
hundreds of commands; and a collection of shell functions to develop
those using the bash programmable completion commands.

For more information see the project home page:

https://github.com/scop/bash-completion

See below for details of changes since the last Cygwin release:

https://github.com/scop/bash-completion/blob/master/CHANGELOG.md


2.13.0  2024-04-03

Features

- curl: Complete protocols for --proto-default
- ip: Add completion for netconf subcommand
- ip: Complete commands for netns exec
- ip: Complete help for unknown subcommands
- ip: Complete ip link property
- ip: Complete link types for address show
- ip: Complete neigh show and flush
- ip: Complete stats subcommand
- ip: Create function to get link types
- rg: add fallback 3rd party completion loader
- xmllint,xmlwf: also suggest *.rss files

Bug Fixes

- available_interfaces: fix regression of unwanted trailing colons
- ip: Complete addrlabel add/del properties
- ip: Complete ip delete with type correctly
- ip: Complete more variations of subcommands
- ip: Complete netns attach subcommand
- ip: Complete only relevant addrlabel subcmds
- ip: Keep completing after -netns name
- ip: Quote all instantiation of ip as "$1"
- ip: Quote network namespace names
- Makefile: include api-and-naming.md in dist


2.12.0  2024-02-21

Features

- _comp_backup_glob: add `ucf` generated backup files
- _comp_backup_glob: require dash in dpkg backup files
- _comp_compgen_{filedir,set}: define exit status
- _comp_compgen_commands: align return value with other compgens
- _comp_compgen_commands: auto set `-o filenames` when appropriate
- _comp_compgen_commands: include dirs
- _comp_compgen_known_hosts: return 2 on usage error
- _comp_compgen: support `-i cmd` and `-x cmd`
- _comp_compgen: support `-U var` to unlocal var
- _comp_compgen: support option -C
- _comp_expand_glob: fail when no paths are generated
- _comp_get_fist_arg: support "-o GLOB" to skip optargs
- _ip_addresses: auto ltrim colon completions when appropriate
- add _comp_compgen_split
- add `_comp_locate_first_arg`
- airflow: add fallback 3rd party completion loader
- ansible*: add fallback 3rd party completion loader
- apt-get: prefer `apt-cache` in same dir as command
- b2sum: new completion
- bash_completion: add function _comp_compgen_ltrim_colon
- black,blackd: add fallback 3rd party completion loader
- carton: support exec command completions
- chezmoi: add 3rd-party completion loader (cobra)
- conda: add 3rd-party completion loader (argcomplete)
- crc: add 3rd-party completion loader (cobra)
- cz: add fallback 3rd party completion loader
- dot: support filename extension .gv
- dprint: add fallback 3rd party completion loader
- eog: add missing extension .heif
- eog: associate with `*.avif` and `*.webp`
- eog: associate with `*.heic` and `*.jxl`
- eog: associate with `*.pbm`
- feh: associate with y4m and heic/heif/avif
- feh: deassociate with avci/avcs
- flask: add fallback 3rd party completion loader
- hash: new completion
- httpx: add fallback 3rd party completion loader
- ip: Add completion for monitor subcommand
- jungle: add fallback 3rd-party completion loader
- keyring: add fallback 3rd party completion loader
- kontena: add fallback 3rd-party completion loader
- lefthook: add fallback 3rd party completion loader
- mailman: prefer `list_lists` in same dir as command
- mysql: prefer `mysqlshow` from same dir
- no empty command completion if `no_empty_cmd_completion` is on
- npm: add fallback 3rd-party completion loader
- nvm: add fallback 3rd-party completion loader
- oc: add 3rd-party completion loader (cobra)
- pip{,3}: add fallback 3rd-party completion loader
- pipenv: add fallback 3rd party completion loader
- pytest: complete new --import-mode value
- rtx: add fallback 3rd party completion loader
- scp,sftp: prefer `ssh` from same dir to resolve options etc
- ssh-copy-id,ssh-keygen: prefer `ssh` from same dir
- ssh-inscribe: add fallback 3rd party completion loader
- ssh: complete RequiredRSASize
- tkn-pac: add 3rd-party completion loader (cobra)
- tkn: add 3rd-party completion loader (cobra)
- xrandr: comma separated `--setmonitor` third argument

Bug Fixes

- __load_completion: quoted compspec for variants
- _cd_devices: `/dev/cdc-*` CDC device false positives
- _comp__init_set_up_service_completions: work around failglob
- _comp_{first_arg,count_args}: count - as argument
- _comp_{first_arg,count_args}: count any arguments after --
- _comp_command_offset: Support complete -C
- _comp_compgen_fstypes: avoid unexpected expansions
- _comp_compgen_help: allow dots to connect names in longopt
- _comp_compgen_known_hosts: work around bash-4.2 nounset
- _comp_compgen_split: work around nounset
- 

Re: calm: vaulting ancient unifont

[Brian Inglis via Cygwin-apps]

Thanks Jon? - yay!

On 2024-05-04 09:48, cygwin-no-re...@cygwin.com wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz
SUMMARY: 8 INFO(s)


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [ITP] perl-Parse-Yapp-1.21

[ASSI via Cygwin-apps]

Ziemowit Laski via Cygwin-apps writes:
> This is a straightforward port, akin to other Perl packages.

The question is: what do you need it for and why should it get packaged
in Cygwin?

[…]
> I can be the maintainer-at-large for this if you'd like.

I'd rather not have separate maintenance of random Perl packages, so if
it gets accepted into Cygwin I would suggest to assign it to me.


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

[ITP] perl-Parse-Yapp-1.21

[Ziemowit Laski via Cygwin-apps]

This is a straightforward port, akin to other Perl packages.

It is already available in numerous Linux distros (and FreeBSD): 
https://pkgs.org/download/perl(Parse::Yapp)

License: "Artistic-1.0" OR "GPL-2.0-or-later".

Running 'cygport test' yields no failures.

https://drive.google.com/file/d/1gYVsNOOj0-YJEB2uWEY4NjArklzcyUmT/view?usp=sharing
https://drive.google.com/file/d/1H1Kf8IeZQtadXBCg7QDZRuv8_hPSABNv/view?usp=sharing
https://drive.google.com/file/d/1SFYn8aeHfeLXr4rguj05QVxKCYe4s72B/view?usp=sharing
https://drive.google.com/file/d/1OzEATt9Y7rarnEa-nDJ3Cks01FLvL1NJ/view?usp=sharing

I can be the maintainer-at-large for this if you'd like.

--Zem

Re: pagefile.sys is reported as being a directory

[Ken Brown via Cygwin]

On 5/3/2024 3:31 PM, Bruno Haible wrote:

Hi Ken,


It turns out that this was a regression in 3.5.3 and was already
reported (in a slightly different form) in

https://cygwin.com/pipermail/cygwin/2024-April/255812.html

and fixed for 3.5.4.


Thanks for the investigations!


Do you have a workaround? In Gnulib we wish to have a way to access this file,
that works on all versions of Cygwin.


3.5.3 is the only version that's bad.


The regression was apparently caused by commit
c1cf14a871528d1adba88a0128813b58d52ba926 on the cygwin-3_5-branch. Therefore
the affected versions are 3.5.2 and 3.5.3.


Just for the record, there never was a release 3.5.2.  But that doesn't 
matter for your workaround.



I can't think of a workaround


I think I'll just make the boot time function skip that file if it
appears to be a directory.


Sounds good.

Ken

--
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: pagefile.sys is reported as being a directory

[Bruno Haible via Cygwin]

Hi Ken,

> It turns out that this was a regression in 3.5.3 and was already 
> reported (in a slightly different form) in
> 
>https://cygwin.com/pipermail/cygwin/2024-April/255812.html
> 
> and fixed for 3.5.4.

Thanks for the investigations!

> > Do you have a workaround? In Gnulib we wish to have a way to access this 
> > file,
> > that works on all versions of Cygwin.
> 
> 3.5.3 is the only version that's bad.

The regression was apparently caused by commit
c1cf14a871528d1adba88a0128813b58d52ba926 on the cygwin-3_5-branch. Therefore
the affected versions are 3.5.2 and 3.5.3.

> I can't think of a workaround

I think I'll just make the boot time function skip that file if it
appears to be a directory.

Bruno




-- 
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: pagefile.sys is reported as being a directory

[Ken Brown via Cygwin]

On 5/2/2024 7:40 PM, Bruno Haible wrote:

Hi,

Ken Brown noticed this: pagefile.sys and swapfile.sys are being
reported by Cygwin 3.5.3 as being directories.

Cygwin 3.5.3 on Windows 10:

$ ls -ld /proc/cygdrive/c/pagefile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/swapfile.sys


It turns out that this was a regression in 3.5.3 and was already 
reported (in a slightly different form) in


  https://cygwin.com/pipermail/cygwin/2024-April/255812.html

and fixed for 3.5.4. Until that's released, you can try the latest test 
release (3.6.0-0.115.g579064bf4d40).



Do you have a workaround? In Gnulib we wish to have a way to access this file,
that works on all versions of Cygwin.


3.5.3 is the only version that's bad.  I can't think of a workaround, 
but maybe someone else can.  If not, I guess Gnulib will just have to 
bail out and return a boot time of 0 on Cygwin 3.5.3.


Ken

--
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] bash-completion/-devel

[Brian Inglis via Cygwin-apps]

On 2024-05-03 07:40, Jon Turney via Cygwin-apps wrote:

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which was 
adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.


Thanks Jon

I guess I need to ask eblake if he wants to orphan his packages, since he seems 
to be no longer active...


Looks like he's busy with Austin Group POSIX + IEEE update plus work

Below are links to existing source packages, build repos, scallywag runs, and 
updated package info.


I would like to further improve the sdesc and ldesc provided to reflect that 
completions are provided for thousands of commands and their options and 
arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground


A few comments:



DEPEND="automake dejagnu make screen"    # tcllib
BUILD_REQUIRES="$DEPEND"


Just set BUILD_REQUIRES.

I assume the comment about tcllib means something to someone. :)


Checked Fedora spec for "advice" - required for testing - n/a on Cygwin


src_test() {
    cd $B
# For some tests involving non-ASCII filenames
    export LANG=C.UTF-8
    export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
    tmpfile=$(mktemp bash-completion.screen.XX.tmp)
#   cygtest


At first glance, because this is commented out, I thought "so this doesn't run 
tests at all"


Maybe remove the commented out line, and write a comment saying something like 
"run tests under screen, since they need a terminal"



    screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
    cat $tmpfile
 result=$(tail -n 1 $tmpfile)


Also borrowed from Fedora spec.
Plan to do more comments and cleanup before merging to master.
They also had a ChangeLog generation problem so reported upstream and made my 
own; they are trying a fix and update or may have a newer package release.


This cleverness to propagate the exit code is probably also worthy of comment, 
since I had to think about it for a few minutes before I realized what it was 
doing...


Perhaps should remove tmpfile here?


Must have deleted instead of commenting out!


    return $result
}


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [ITA] bash-completion/-devel

[Jon Turney via Cygwin-apps]

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which 
was adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.

I guess I need to ask eblake if he wants to orphan his packages, since 
he seems to be no longer active...


Below are links to existing source packages, build repos, scallywag 
runs, and updated package info.


I would like to further improve the sdesc and ldesc provided to reflect 
that completions are provided for thousands of commands and their 
options and arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground


A few comments:


DEPEND="automake dejagnu make screen" # tcllib
BUILD_REQUIRES="$DEPEND"


Just set BUILD_REQUIRES.

I assume the comment about tcllib means something to someone. :)


src_test() {
cd $B
# For some tests involving non-ASCII filenames
export LANG=C.UTF-8
export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
tmpfile=$(mktemp bash-completion.screen.XX.tmp)
#   cygtest


At first glance, because this is commented out, I thought "so this 
doesn't run tests at all"


Maybe remove the commented out line, and write a comment saying 
something like "run tests under screen, since they need a terminal"



screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
cat $tmpfile

> result=$(tail -n 1 $tmpfile)

This cleverness to propagate the exit code is probably also worthy of 
comment, since I had to think about it for a few minutes before I 
realized what it was doing...


Perhaps should remove tmpfile here?


return $result
}

Re: [URGENT] Issue relating to cygwin

[cygwinautoreply--- via Cygwin]

>Dear team,
>Please help me check the issue below:
>
>C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with 
>'str' literal. Did you mean "!="?
>  if(qa.name is not 'QA4'):
>  0 [main] cntlm 25920 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
> pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>cygwin warning:
>  MS-DOS style path detected: C:\ESO\RTA-QualityKit\cntlm\cntlm.conf
>  Preferred POSIX equivalent is: /cntlm/cntlm.conf
>  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
>  Consult the user's guide for more details about POSIX paths:
>http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
>Exitting with error. Check daemon logs or run with -v.
>(root) INFO: Checking if epic_ticket_id is available
>(root) INFO: Creating EPIC Ticket for project: RTA-HVR_NXP_S32Z
>(root) INFO: Serialize Issues to json file
>(root) INFO: Serialize Issues to json file C:\ESO\tmp\qualitykit.json - Done
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
>100 242980 23960  100   338  15029212  0:00:01  0:00:01 --:--:-- 15233
>(root) INFO: Creating EPIC Ticket for project: RTA-HVR_NXP_S32Z was executed 
>successfully
>
>Trân trọng / Best regards,
>
>Ngan Nguyen Pham Thuy
>BGSV/QMM
>
>Mobile +84 365 94-0917
>​


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

[URGENT] Issue relating to cygwin

[Nguyen Pham Thuy Ngan (BGSV/QMM1) via Cygwin]

Dear team,
Please help me check the issue below:

C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with 'str' 
literal. Did you mean "!="?
  if(qa.name is not 'QA4'):
  0 [main] cntlm 25920 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
cygwin warning:
  MS-DOS style path detected: C:\ESO\RTA-QualityKit\cntlm\cntlm.conf
  Preferred POSIX equivalent is: /cntlm/cntlm.conf
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Exitting with error. Check daemon logs or run with -v.
(root) INFO: Checking if epic_ticket_id is available
(root) INFO: Creating EPIC Ticket for project: RTA-HVR_NXP_S32Z
(root) INFO: Serialize Issues to json file
(root) INFO: Serialize Issues to json file C:\ESO\tmp\qualitykit.json - Done
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 242980 23960  100   338  15029212  0:00:01  0:00:01 --:--:-- 15233
(root) INFO: Creating EPIC Ticket for project: RTA-HVR_NXP_S32Z was executed 
successfully

Trân trọng / Best regards,

Ngan Nguyen Pham Thuy
BGSV/QMM

Mobile +84 365 94-0917
​

-- 
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: pagefile.sys is reported as being a directory

[Thomas Wolff via Cygwin]

Am 03.05.2024 um 01:40 schrieb Bruno Haible via Cygwin:

Hi,

Ken Brown noticed this: pagefile.sys and swapfile.sys are being
reported by Cygwin 3.5.3 as being directories.

Cygwin 3.5.3 on Windows 10:

$ ls -ld /proc/cygdrive/c/pagefile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/swapfile.sys

In Cygwin 2.9.0 and 3.4.6 (also on Windows 10) it was reported as a regular 
file:

Also still worked in 3.5.1.


$ ls -ld /proc/cygdrive/c/pagefile.*
-rw-r- 1 Unknown+User Unknown+Group 671088640 May  3 01:25 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
-rw-r- 1 Unknown+User Unknown+Group 268435456 May  3 01:25 
/proc/cygdrive/c/swapfile.sys

Gnulib is interested in the modification time of this file.

Do you agree that it's a bug?

Do you have a workaround? In Gnulib we wish to have a way to access this file,
that works on all versions of Cygwin.

Bruno







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

pagefile.sys is reported as being a directory

[Bruno Haible via Cygwin]

Hi,

Ken Brown noticed this: pagefile.sys and swapfile.sys are being
reported by Cygwin 3.5.3 as being directories.

Cygwin 3.5.3 on Windows 10:

$ ls -ld /proc/cygdrive/c/pagefile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
drwxr-x--- 17664 Unknown+User Unknown+Group 0 Jan  1  1601 
/proc/cygdrive/c/swapfile.sys

In Cygwin 2.9.0 and 3.4.6 (also on Windows 10) it was reported
as a regular file:

$ ls -ld /proc/cygdrive/c/pagefile.*
-rw-r- 1 Unknown+User Unknown+Group 671088640 May  3 01:25 
/proc/cygdrive/c/pagefile.sys
$ ls -ld /proc/cygdrive/c/swapfile.*
-rw-r- 1 Unknown+User Unknown+Group 268435456 May  3 01:25 
/proc/cygdrive/c/swapfile.sys

Gnulib is interested in the modification time of this file.

Do you agree that it's a bug?

Do you have a workaround? In Gnulib we wish to have a way to access this file,
that works on all versions of Cygwin.

Bruno




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

My SSH key (take 2)

[Ziemowit Laski via Cygwin-apps]

Name: Ziemowit Laski
 BEGIN SSH2 PUBLIC KEY 
C3NzaC1lZDI1NTE5IBlHSdOpkyPkqoVmAqoq8tSpKepnFanhk+/B8byFumt8
 END SSH2 PUBLIC KEY 

My SSH key

[Ziemowit Laski via Cygwin-apps]

 BEGIN SSH2 PUBLIC KEY 
Comment: "256-bit ED25519, converted by zlaski@RUMCAJS from OpenSSH"
C3NzaC1lZDI1NTE5IBlHSdOpkyPkqoVmAqoq8tSpKepnFanhk+/B8byFumt8
 END SSH2 PUBLIC KEY 

Re: |FILE_ID_BOTH_DIR_INFORMATION| fields |ShortName|+|ShortNameLength| mandatory for Cygwin and Window 10 ?

[Roland Mainz via Cygwin]

On Sat, Apr 27, 2024 at 5:03 PM Brian Inglis via Cygwin
 wrote:
>
> On 2024-04-27 07:08, Roland Mainz via Cygwin wrote:
> > Are the |FILE_ID_BOTH_DIR_INFORMATION| fields
> > |ShortName|+|ShortNameLength| mandatory these days, e.g. is it legal
> > to set |ShortNameLength = 0;| for Cygwin 3.4/3.5 in Windows 10 ?
>
> MS Windows 8/Server 2012+ disabled 8.3 short name generation on new
> volumes/partitions, for example see:
>
> https://ss64.com/nt/syntax-filenames.html
>
> https://archive.techarp.com/showarticle53b4.html?artno=827
>
> https://learn.microsoft.com/en-ca/archive/blogs/josebda/windows-server-2012-file-server-tip-disable-8-3-naming-and-strip-those-short-names-too
>
> https://learn.microsoft.com/en-ca/windows-server/administration/windows-commands/fsutil-8dot3name

Thanks...:-)
... for now I've disabled 8.3 short name generation in the
ms-nfs41-client driver (see
https://github.com/kofemann/ms-nfs41-client/commit/f5f276db6337f34d7705e9c981213e31adbb0c7d),
until I have time to implement working 8.3. short name algorithm...

[snip]
> > Is there anything else for a filesystem driver to do to indicate that
> > |ShortName| support is not available ?
>
> Also see fsutil behavior query|set disable8dot3 [[ 
> [{1|0}]]|]
[snip]
> Sample commands:
>"fsutil 8dot3name set 1"  - disable 8dot3 name creation on all volumes
>"fsutil 8dot3name set C: 1"   - disable 8dot3 name creation on c:

Is there any filesystem driver/kernel API for this ?

[snip]
> Based on the above settings, 8dot3 name creation is enabled on c:
>
> % fsutil 8dot3name query d:
> The volume state is: 0 (8dot3 name creation is enabled).
> The registry state is: 2 (Per volume setting - the default).

Same question: Is there a driver/kernel API ?



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

ffmpeg 7.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ffmpeg-7.0-1
* libavutil59-7.0-1
* libavcodec61-7.0-1
* libavformat61-7.0-1
* libavdevice61-7.0-1
* libavfilter10-7.0-1
* libswscale8-7.0-1
* libswresample5-7.0-1
* libpostproc58-7.0-1
* libavutil-devel-7.0-1
* libavcodec-devel-7.0-1
* libavformat-devel-7.0-1
* libavdevice-devel-7.0-1
* libavfilter-devel-7.0-1
* libswscale-devel-7.0-1
* libswresample-devel-7.0-1
* libpostproc-devel-7.0-1
* ffmpeg-examples-7.0-1
* ffmpeg-doc-7.0-1

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, 
mux, demux, stream and filter pretty much anything that humans and machines 
have created. It supports the most obscure ancient formats up to the cutting 
edge.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

SDL2 2.30.3-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.3-1
* libSDL2-devel-2.30.3-1

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

libvpl 2.11.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libvpl-2.11.0-1
* libvpl-devel-2.11.0-1

This package provides the headers and the library which loads Intel MediaSDK 
dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU.
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [PATCH cygport] Add customization support for announce command

[Adam Dinwoodie via Cygwin-apps]

On Wed, May 01, 2024 at 04:49:10PM +0200, Christian Franke via Cygwin-apps 
wrote:
> Adam Dinwoodie via Cygwin-apps wrote:
> > On Tue, Apr 30, 2024 at 12:27:35PM +0200, Christian Franke via Cygwin-apps 
> > wrote:
> > > Jon Turney wrote:
> > > > On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
> > > > > +    /bin/bash -c "cd ${top} || exit 1
> > > > > +${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
> > > > > +P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
> > > > > +${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
> > > > > +${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
> > > > > +${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
> > > > > +${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
> > > > > +${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
> > > > > +${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
> > > > > +${cmd}
> > > > > +" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}'
> > > > > (cwd=${top}) failed"
> > > > > +}
> > > > Sorry I didn't notice this before, and I am terrible at writing shell,
> > > > but perhaps you could share the reasoning behind writing this as above,
> > > > and not as, e.g.
> > > > 
> > > > (cd ${top} && env BLAH ${cmd})
> > > > 
> > > > avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
> > > > being fed into 'bash -c' (and hence getting evaluated twice??) rather
> > > > than just run?
> > > > 
> > > > 
> > > None of the mentioned variables are exported to the environment by 
> > > cygport.
> > > I wanted to keep this fact in the subshell. Therefore the assignments are
> > > added to the script instead of passing via env(ironment). The latter won't
> > > even work with the PV variable because arrays could not be exported.
> > > 
> > > Variables would not be evaluated twice. For example in the rare case that
> > > someone uses something like
> > > 
> > > SMTP_SERVER="smtp.$(hostname -d)"
> > > 
> > > in cygport.conf, this would immediately expand to
> > > SMTP_SERVER="smtp.some.domain". The above
> > > 
> > > ${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
> > > 
> > > would expand to
> > > 
> > > SMTP_SERVER=${SMTP_SERVER@Q}
> > > 
> > > and then to
> > > 
> > > SMTP_SERVER='smtp.some.domain'
> > > 
> > > (The @Q bash extension ensures proper quoting).
> > Using a subshell created by ( ... ) would achieve the behaviour you're
> > after, without requiring nearly so much quote handling.  The code Jon
> > has pulled out could be rewritten as below; using ( ... ) would mean
> > that everything happens in a subshell and the exports don't affect the
> > rest of the environment.
> > 
> > ```
> > (
> > cd "$top"
> > export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER SMTP_SERVER_PORT 
> > SMTP_ENCRYPTION SMTP_USER SMTP_PASS
> 
> This unnecessarily exports all variables (except PV, see below) to the
> subcommands run by $cmd.
> 
> 
> > "$cmd" "$msg" || error "Command $cmd $msg (cwd=${top}) failed"
> 
> This would limit $cmd to simple commands instead of multiline scripts. This
> reduces flexibility and some of the examples I provided in my original post
> would no longer work:
> https://sourceware.org/pipermail/cygwin-apps/2024-February/043501.html

Ah, right!  Apologies, I'd missed/forgotten that context.

I still think this is the wrong approach.  Cygport has a very well
established design paradigm for running non-trivial custom code: there's
a default Bash function in the Cygport library files, and an individual
cygport file can override that function with its own version.  If
running something more than a simple command is required here, I'd have
thought following that established paradigm would be a much more
sensible approach.  This would also completely avoid the need for any
special variable handling, because the function will run in an
environment where the variables are already set.

I'd suggest a pair of functions that _aren't_ read-only, say
`announce_edit` and `announce_send`, that default to the current code
for editing and sending the announcement, but which a maintainer can
override in their cygport file should they so desire.

I really don't like passing strings around to be eval'd, particularly
when they're expected to contain non-trivial code.  Given how difficult
Bash quoting can be to get right, I worry that even if your patch is
correct now, it'll be a ripe site for bugs when other people try to
amend the code.

> > )
> > ```
> > 
> > I've removed the array handling for $PV, as it's not an array; possibly
> > you've confused it with $PVP?
> > 
> 
> No. PV it is initialized as a regular shell variable but is later changed to
> an array by appending the PVP array.
> 
> /bin/cygport:
> ...
> declare PV=${VERSION}
> ...
>     PV=$(echo ${PF} | sed -e "s/${PN}\-\(.*\)\-${PR}$/\1/");
> ...
> declare -r  PV=(${PV} ${PVP[*]});
> ...
> 
> $ git blame bin/cygport.in | grep 'declare -r  PV='
> deb528a88 (Yaakov Selkowitz   2009-12-31 08:05:52 + 397) declare -r 
> PV=(${PV} ${PVP[*]});

Oh.  Oh I don't like 

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:

Some package upstreams offer only checksums, for example .sha512sum, .sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.



https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d


Two similar independent implementations mean it would be a good idea to add the 
feature!


Mine preferred cksum as being the most general approach, while not worrying or 
knowing too much about ancient sums, although your implementation is better, 
that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes only 
without sum, not enumerating them all in the unpack() case, and respecting the 
cksum crc default.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

[Brian Inglis via Cygwin-apps]

On 2024-04-30 23:50, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:

Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'


NAK. This tool doesn't check for expired keys and also searches for
keys in different places, so you'd have to change your setup.  More
specifically you'd either have to explicitly trust all keys you want to
check (not going to happen) or use a "--keyring" argument to force it to
use the pubring.


Questioning FMI but not disagreeing with your decision ;^>

Not seeing any key issues as my pubring.gpg is symlinked as trustedkeys.gpg?

Although scallywag runs can not even check keys, so what can we do about that?

2024-04-28T21:41:01.4042065Z >>> Preparing ncurses-6.5+20240427-1.x86_64
2024-04-28T21:41:01.4235798Z *** Info: SOURCE 1 signature follows:
2024-04-28T21:41:01.4407160Z gpg: directory '/home/runneradmin/.gnupg' created
2024-04-28T21:41:01.4508023Z gpg: keybox '/home/runneradmin/.gnupg/pubring.kbx' 
created

2024-04-28T21:41:01.4775748Z gpg: Signature made Sat, Apr 27, 2024  8:27:29 PM 
UTC
2024-04-28T21:41:01.4776513Z gpg:using RSA key 
19882D92DDA4C400C22C0D56CC2AF4472167BE03

2024-04-28T21:41:01.4784503Z gpg: Can't check signature: No public key

Other advantage is not seeing Eric Blake and others' pictures pop up ;^>

I tested with all my cached signed upstream package downloads and compared the 
logs from gpg2 --verify and gpgv2, so what benefit is reporting trust level 
"[unknown]" and expired keys from cygport, and what are you meant to do about 
expired keys for upstream package signers?


[While checking also came across keys from 1998 with my dialup email address!]

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Test: gcc-13.2.1+20240426-0.1

[ASSI]

The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-13 branch:

 gcc-13.2.1+20240426

This build incorporates the experimental v4 patch from T. Yano to use
the newlib locale function in libstdc++ so that other locales (aside
from "C") become usable.

Cygwin does not allow multiple versions of the compilers to be installed
concurrently.

For this build, the D compiler has been disabled since it does not
bootstrap due to the missing Phobos runtime on Cygwin.  No testing
beyond the compiler testsuite has been done.  Libgccjit could not be
built because it overflows the DLL symbol table currently.

-- 
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Test: gcc-12.3.1+20240419-0.1

[ASSI]

The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-12 branch:

 gcc-12.3.1+20240419

This build incorporates the experimental v4 patch to use the newlib
locale function in libstdc++ so that other locales (aside from "C")
become usable.

Cygwin does not allow multiple versions of the compilers to be installed
concurrently.

For this build, the D compiler has been disabled since it does not
bootstrap due to the missing Phobos runtime on Cygwin.  No testing
beyond the compiler testsuite has been done.

-- 
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [PATCH cygport] Add customization support for announce command

[Christian Franke via Cygwin-apps]

Adam Dinwoodie via Cygwin-apps wrote:

On Tue, Apr 30, 2024 at 12:27:35PM +0200, Christian Franke via Cygwin-apps 
wrote:

Jon Turney wrote:

On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:

+    /bin/bash -c "cd ${top} || exit 1
+${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
+P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
+${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
+${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
+${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
+${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
+${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
+${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
+${cmd}
+" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}'
(cwd=${top}) failed"
+}

Sorry I didn't notice this before, and I am terrible at writing shell,
but perhaps you could share the reasoning behind writing this as above,
and not as, e.g.

(cd ${top} && env BLAH ${cmd})

avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
being fed into 'bash -c' (and hence getting evaluated twice??) rather
than just run?



None of the mentioned variables are exported to the environment by cygport.
I wanted to keep this fact in the subshell. Therefore the assignments are
added to the script instead of passing via env(ironment). The latter won't
even work with the PV variable because arrays could not be exported.

Variables would not be evaluated twice. For example in the rare case that
someone uses something like

SMTP_SERVER="smtp.$(hostname -d)"

in cygport.conf, this would immediately expand to
SMTP_SERVER="smtp.some.domain". The above

${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}

would expand to

SMTP_SERVER=${SMTP_SERVER@Q}

and then to

SMTP_SERVER='smtp.some.domain'

(The @Q bash extension ensures proper quoting).

Using a subshell created by ( ... ) would achieve the behaviour you're
after, without requiring nearly so much quote handling.  The code Jon
has pulled out could be rewritten as below; using ( ... ) would mean
that everything happens in a subshell and the exports don't affect the
rest of the environment.

```
(
cd "$top"
export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER SMTP_SERVER_PORT 
SMTP_ENCRYPTION SMTP_USER SMTP_PASS


This unnecessarily exports all variables (except PV, see below) to the 
subcommands run by $cmd.




"$cmd" "$msg" || error "Command $cmd $msg (cwd=${top}) failed"


This would limit $cmd to simple commands instead of multiline scripts. 
This reduces flexibility and some of the examples I provided in my 
original post would no longer work:

https://sourceware.org/pipermail/cygwin-apps/2024-February/043501.html



)
```

I've removed the array handling for $PV, as it's not an array; possibly
you've confused it with $PVP?



No. PV it is initialized as a regular shell variable but is later 
changed to an array by appending the PVP array.


/bin/cygport:
...
declare PV=${VERSION}
...
    PV=$(echo ${PF} | sed -e "s/${PN}\-\(.*\)\-${PR}$/\1/");
...
declare -r  PV=(${PV} ${PVP[*]});
...

$ git blame bin/cygport.in | grep 'declare -r  PV='
deb528a88 (Yaakov Selkowitz   2009-12-31 08:05:52 + 397) declare -r  
PV=(${PV} ${PVP[*]});


Bash silently ignores 'export PV'.


   In any case, there is no way to pass an
array to "$cmd" unless "$cmd" is itself a Bash function, as there's no
standard way to store anything other than strings in environment
variables.


That's why I use 'PV=(${PV[*]@Q})' as a prefix of the configured $cmd 
string instead of passing any new environment to $cmd.




I've also removed the `|| return 1` part, since cygport runs with `set
-e` enabled so you only want to catch non-zero return codes if you want
specific error handling.


There is no 'return 1' is my patch.



Finally, I've also added "$msg" to the arguments to "$cmd"; that seems
to be missing and seems to be critical to this working at all!


$msg is not missing in my patch but passed to the launched /bin/bash as $1.



Alternatively, if you really wanted to avoid the export statement, the
below will achieve the same thing; the only use of the subshell at this
point is to avoid the `cd` changing the working directory for the rest
of the script.

```
(
cd "$top"
HOMEPAGE="$HOMEPAGE" P="$P" PF="$PF" PN="$PN" PR="$PR" PV="$PV" SMTP_SENDER="$SMTP_SENDER" SMTP_SERVER="$SMTP_SERVER" 
SMTP_SERVER_PORT="$SMTP_SERVER_PORT" SMTP_ENCRYPTION="$SMTP_ENCRYPTION" SMTP_USER="$SMTP_USER" SMTP_PASS="$SMTP_PASS" "$cmd" "$msg" || error "Command $cmd $msg 
(cwd=${top}) failed"
)
```


Same problem with missing flexibility for $cmd as above.

Re: [PATCH cygport] Add customization support for announce command

[Adam Dinwoodie via Cygwin-apps]

On Tue, Apr 30, 2024 at 12:27:35PM +0200, Christian Franke via Cygwin-apps 
wrote:
> Jon Turney wrote:
> > On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
> > > +    /bin/bash -c "cd ${top} || exit 1
> > > +${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
> > > +P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
> > > +${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
> > > +${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
> > > +${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
> > > +${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
> > > +${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
> > > +${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
> > > +${cmd}
> > > +" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}'
> > > (cwd=${top}) failed"
> > > +}
> > 
> > Sorry I didn't notice this before, and I am terrible at writing shell,
> > but perhaps you could share the reasoning behind writing this as above,
> > and not as, e.g.
> > 
> > (cd ${top} && env BLAH ${cmd})
> > 
> > avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it
> > being fed into 'bash -c' (and hence getting evaluated twice??) rather
> > than just run?
> > 
> > 
> 
> None of the mentioned variables are exported to the environment by cygport.
> I wanted to keep this fact in the subshell. Therefore the assignments are
> added to the script instead of passing via env(ironment). The latter won't
> even work with the PV variable because arrays could not be exported.
> 
> Variables would not be evaluated twice. For example in the rare case that
> someone uses something like
> 
> SMTP_SERVER="smtp.$(hostname -d)"
> 
> in cygport.conf, this would immediately expand to
> SMTP_SERVER="smtp.some.domain". The above
> 
> ${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
> 
> would expand to
> 
> SMTP_SERVER=${SMTP_SERVER@Q}
> 
> and then to
> 
> SMTP_SERVER='smtp.some.domain'
> 
> (The @Q bash extension ensures proper quoting).

Using a subshell created by ( ... ) would achieve the behaviour you're
after, without requiring nearly so much quote handling.  The code Jon
has pulled out could be rewritten as below; using ( ... ) would mean
that everything happens in a subshell and the exports don't affect the
rest of the environment.

```
(
cd "$top"
export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER SMTP_SERVER_PORT 
SMTP_ENCRYPTION SMTP_USER SMTP_PASS
"$cmd" "$msg" || error "Command $cmd $msg (cwd=${top}) failed"
)
```

I've removed the array handling for $PV, as it's not an array; possibly
you've confused it with $PVP?  In any case, there is no way to pass an
array to "$cmd" unless "$cmd" is itself a Bash function, as there's no
standard way to store anything other than strings in environment
variables.

I've also removed the `|| return 1` part, since cygport runs with `set
-e` enabled so you only want to catch non-zero return codes if you want
specific error handling.

Finally, I've also added "$msg" to the arguments to "$cmd"; that seems
to be missing and seems to be critical to this working at all!

Alternatively, if you really wanted to avoid the export statement, the
below will achieve the same thing; the only use of the subshell at this
point is to avoid the `cd` changing the working directory for the rest
of the script.

```
(
cd "$top"
HOMEPAGE="$HOMEPAGE" P="$P" PF="$PF" PN="$PN" PR="$PR" PV="$PV" 
SMTP_SENDER="$SMTP_SENDER" SMTP_SERVER="$SMTP_SERVER" 
SMTP_SERVER_PORT="$SMTP_SERVER_PORT" SMTP_ENCRYPTION="$SMTP_ENCRYPTION" 
SMTP_USER="$SMTP_USER" SMTP_PASS="$SMTP_PASS" "$cmd" "$msg" || error "Command 
$cmd $msg (cwd=${top}) failed"
)
```

Jon suggested using `env`, although I don't think it provides any
function here that isn't already provided by built-in Bash function.

Personally, I'd rewrite the whole __pkg_announce_run_cmd_on_msg function
as below, although some of this is just my own stylistic preferences (in
particular, I try to avoid `eval` if at all possible, and here `local -n`
works just fine):

```
__pkg_announce_run_cmd_on_msg() {
local cmdvar="$1"
local -n cmd="$1"
local msg="$2"

if [[ ! "$cmd" ]]; then
inform "$cmdvar is empty"
return 0
fi

echo
inform "Launching '$cmd $msg'"

(
cd "$top"
export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER \
SMTP_SERVER_PORT SMTP_ENCRYPTION SMTP_USER \
SMTP_PASS
"$cmd" "$msg" || error "Command '$cmd $msg' (cwd=${top}) failed"
)
}
```

Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Christian Franke via Cygwin-apps]

Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 15:07, Christian Franke via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
The new script uses the SPDX webpages to create the license file. I 
didn't find a usable single license list at https://github.com/spdx


As usual, it is easier if you clearly state the purpose of the file 
you want, and its desired properties, like data content, format, etc.



What about:
https://spdx.github.io/license-list-data/


This is apparently a draft version of 
https://spdx.org/licenses/index.html which is used by the script to 
generate the local license file.


Strip out the table entries and create what you want with a command or 
script.


The spdx-check script from the patch optionally (-m, -u) downloads 
https://spdx.org/licenses/index.html and creates the local spdx-licenses 
file intended to distribute with cygport. The file is grep'able.and 
reduced to the bare minimum for this use case.






and everything under:
https://github.com/spdx/license-list-data



I didn't find a single file which lists the licenses there.


GH does not always make access easy, ...


... including that github.com is still unreachable via IPv6 without 
NAT64 (except for downloads from raw.githubusercontent.com) ...



... with its limited online displays and fixed display orders, and 
searches return a lot of junk, without easy access to better searching 
in context, but try:


https://github.com/spdx/license-list-data/blob/main/licenses.md

which also has xrefs to the text files; also there are:

https://github.com/spdx/license-list-data/blob/main/json/licenses.json 

https://github.com/spdx/license-list-data/blob/main/json/exceptions.json 



which can be easily processed using `jq`.



Indeed, thanks. I obviously missed these files when I wrote the 
spdx-check script some month ago.


The current file format used by the script could then be created with:

url="https://raw.githubusercontent.com/spdx/license-list-data/main/json;

wget -O - "$url/licenses.json" \
| jq -j '
    .licenses[] | (
  if .isDeprecatedLicenseId then "!" else "" end,
  .licenseId,
  "\n"
    )'

wget -O - "$url/exceptions.json" \
| jq -j '
    .exceptions[] | (
  if .isDeprecatedLicenseId then "!&" else "&" end,
  .licenseExceptionId,
  "\n"
    )'

This adds these license ids not yet mentioned at 
https://spdx.org/licenses/index.html:

AMD-newlib, BSD-2-clause-first-lines, Catharon, HPND-UC-export-US,
MIT-Khronos-old, NCL, OAR, Sun-PPP-2000, pkgconf, threeparttable, xzoom

I could provide a new patch with an updated script if desired.

Re: [PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

[ASSI via Cygwin-apps]

Brian Inglis via Cygwin-apps writes:
> Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
> single operation gpg verification helper designed for use in scripts
> instead of gpg2 --verify: see 'info gpg2 helper gpgv'

NAK.  This tool doesn't check for expired keys and also searches for
keys in different places, so you'd have to change your setup.  More
specifically you'd either have to explicitly trust all keys you want to
check (not going to happen) or use a "--keyring" argument to force it to
use the pubring.

(I've used an old key file for Cygwin in the following for
demonstration, the current key is not expired obviously.)

--8<---cut here---start->8---
~> gpg2 --verify cygwin/setup64.zst{.sig,}
gpg: Signature made So 07 Apr 2024 16:30:47 CEST
gpg:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpg: Good signature from "Cygwin " [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 5640 5CF6 FCC8 1574 682A  5D56 1A69 8DE9 E2E5 6300
~> gpgv2 cygwin/setup64.zst{.sig,}
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/gratz/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made So 07 Apr 2024 16:30:47 CEST
gpgv:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpgv: Can't check signature: No public key
~> gpgv2 --keyring .gnupg/pubring.gpg cygwin/setup64.zst{.sig,}
gpgv: Signature made So 07 Apr 2024 16:30:47 CEST
gpgv:using RSA key 56405CF6FCC81574682A5D561A698DE9E2E56300
gpgv: Good signature from "Cygwin "
--8<---cut here---end--->8---


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[ASSI via Cygwin-apps]

Brian Inglis via Cygwin-apps writes:
> Some package upstreams offer only checksums, for example .sha512sum, 
> .sha256sum,
> for verification rather than gpg signatures, for example .asc, .sig, .sign, 
> etc;
> use these checksum files when provided in a similar manner to gpg signatures;
> these files are often provided with fixed names which may be renamed on 
> download
> to unique values using cygport URI fragment support like 
> #/$NAME-VERSION.sha...sum;
> use coreutils cksum as it supports all modern and legacy checksums and 
> formats.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Brian Inglis via Cygwin-apps]

From: "Brian Inglis" 

Some package upstreams offer only checksums, for example .sha512sum, .sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, .sign, etc;
use these checksum files when provided in a similar manner to gpg signatures;
these files are often provided with fixed names which may be renamed on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums and formats.

define __sum_verify() after __gpg_verify();
add to readonly function definition list
unpack(): skip files matching *.*sum
__src_prep():
define file types or prefixes in variable sum_exts;
in src files loop after __gpg_verify():
match file checksum type and call __sum_verify()

Signed-off-by: Brian Inglis 
---
 lib/src_prep.cygpart |   56 
++-
 1 file changed, 55 insertions(+), 1 deletion(-)

--- lib/src_prep.cygpart2024-01-15 05:09:23.0 -0700
+++ lib/src_prep.cygpart2024-04-30 11:41:01.218878400 -0600
@@ -88,6 +88,7 @@ unpack() {
# determine correct source decompression command
case ${unpack_file_path} in
*.asc|*.md5|*.sig|*.sign)  continue ;;
+   *.*sum)continue ;;
*.tar.lrz)
check_prog_req lrzuntar lrzip
unpack_cmd="lrzuntar"
@@ -200,6 +201,43 @@ __gpg_verify() {
fi
 }
 
+__sum_verify() {
+   local _file=${1#${DISTDIR}/};
+   local _filedesc=${2};
+   local _filetype=${3};
+   local _sum=${3%sum};
+
+   if ! check_prog cksum
+   then
+   # display notice only once
+   if ! defined _cksum_not_found_
+   then
+   inform "cksum must be installed in order to check 
checksums.";
+   _cksum_not_found_=1
+   fi
+
+   return 0;
+   fi
+
+   # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
+   [ -z "${_sum}" ]&& _sum=${_sum:-bsd}
+   [ "b2" = "${_sum}" ]&& _sum=blake2b
+   [ "b2b" = "${_sum}" ]   && _sum=blake2b
+   [ "ck" = "${_sum}" ]&& _sum=crc
+
+   if defined DISTDIR && [ -d ${DISTDIR} ] && [ -f ${DISTDIR}/${_file} ]
+   then
+   cd ${DISTDIR}
+   inform "${_filedesc} ${_filetype} checksum verification 
follows:";
+   if [ "${_sum}" = "crc" ] || [ "${_sum}" = "bsd" ] || [ 
"${_sum}" = "sysv" ]
+   then
+   cksum -a ${_sum} ${_file%.${_filetype}} || true;
+   else
+   cksum -a ${_sum} -c ${_file} || true;
+   fi
+   fi
+}
+
 __mkdirs() {
cd ${top};
mkdir -p ${srcdir} ${origsrcdir} ${B} ${D} ${T} ${configdir} ${logdir} 
${distdir} ${patchdir} ${spkgdir};
@@ -298,6 +336,10 @@ __src_prep() {
local src_pkg;
local tar_patch;
local n=1;
+   local sum_exts="sha512 sha384 sha256 sha224 b2 b2b blake2b sm3 sha1 md5 
ck crc bsd sysv";
+   # prefer newer stronger keys for faster lookup
+   # blake2b bsd crc md5 sha1 sha224 sha256 sha384 sha512 sm3 sysv
+   # {b2,b2b}{,sum} -> blake2b; ck{,sum} -> crc; {,sum} -> bsd
 
cd ${top};
 
@@ -328,6 +370,18 @@ __src_prep() {
__gpg_verify ${src_pkg} "SOURCE $((n++))" 
${sigext};
fi
done
+   for sigext in ${sum_exts} ''# final entry is BSD .sum -> ''
+   do
+   if [ "${src_pkg}" != "${src_pkg%.${sigext}sum}" ]
+   then
+   __sum_verify ${src_pkg} "SOURCE $((n++))" 
"${sigext}sum";
+   break;
+   elif [ "${src_pkg}" != "${src_pkg%.${sigext}}" ]  # 
fail if '' unless *.
+   then
+   __sum_verify ${src_pkg} "SOURCE $((n++))" 
"${sigext}";
+   break;
+   fi
+   done
done
 
for src_patch in ${_src_orig_patches}
@@ -510,4 +564,4 @@ __src_prep() {
 }
 
 readonly -f __cpio_gz_extract __gem_extract __srpm_extract unpack \
-__gpg_verify __mkdirs cygpatch __src_prep
+__gpg_verify __sum_verify __mkdirs cygpatch __src_prep

[PATCH] cygport/lib/src_prep.cygpart: use gpgv2 not gpg2 --verify

[Brian Inglis via Cygwin-apps]

From: "Brian Inglis" 

Utility gpgv2 is the gpg2 release of gpgv, a lighter, script friendly,
single operation gpg verification helper designed for use in scripts
instead of gpg2 --verify: see 'info gpg2 helper gpgv'

__gpg_verify(): use gpgv2 not gpg2 --verify

Signed-off-by: Brian Inglis 
---
 lib/src_prep.cygpart |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/lib/src_prep.cygpart  2024-01-15 05:09:23.0 -0700
+++ b/lib/src_prep.cygpart  2024-04-30 01:49:54.294030400 -0600
@@ -181,7 +181,7 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg2
+   if ! check_prog gpgv2
then
# display notice only once
if ! defined _gpg_not_found_
@@ -196,7 +196,7 @@ __gpg_verify() {
if [ -f ${_file}.${_sigext} ]
then
inform "${_filetype} signature follows:";
-   gpg2 --verify ${_file}.${_sigext} ${_file} || true;
+   gpgv2 ${_file}.${_sigext} ${_file} || true;
fi
 }
 

Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

[Jon Turney via Cygwin-apps]

On 28/04/2024 13:21, Christian Franke via Cygwin-apps wrote:

ASSI via Cygwin-apps wrote:

Christian Franke via Cygwin-apps writes:

_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
13.2.1 test release.

Silently falls back to level 2 if level 3 is unsupported (older
headers or gcc) or to level 0 if unsupported at all (C++, clang).

Well, if only that was the case…

--8<---cut here---start->8---
  from /usr/include/w32api/windows.h:9,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/test_utils/test_common.h:88,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test.h:38,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test_extract_tar_lrz.c:25:
/usr/include/w32api/_mingw_mac.h:319:8: warning: #warning Using 
_FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size 
support) [-Wcpp]
   319 | #  warning Using _FORTIFY_SOURCE=2 (level 3 requires 
__builtin_dynamic_object_size support)

--8<---cut here---end--->8---

Can't we conditiohnalize this to depend on the actual compiler support?


This is a bogus warning. Sorry, my bad.

In my contribution of _FORTIFY_SOURCE support to MinGW-w64 from 2019, I 
didn't realize that these warnings also appear if only Win32 API 
includes (windows.h, ...) are used. The related internal macros have 
only an effect if MinGW-w64 runtime includes (stdio.h, string.h, ...) 
are used.


Meantime this has been fixed upstream:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f8e088e


I guess that means we need an updated w32api-header package, with this 
patch added, if it's not yet in a release...

Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Brian Inglis via Cygwin-apps]

On 2024-04-30 15:07, Christian Franke via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
The new script uses the SPDX webpages to create the license file. I didn't 
find a usable single license list at https://github.com/spdx


As usual, it is easier if you clearly state the purpose of the file you want, 
and its desired properties, like data content, format, etc.



What about:
https://spdx.github.io/license-list-data/


This is apparently a draft version of https://spdx.org/licenses/index.html which 
is used by the script to generate the local license file.


Strip out the table entries and create what you want with a command or script.


and everything under:
https://github.com/spdx/license-list-data



I didn't find a single file which lists the licenses there.


GH does not always make access easy, with its limited online displays and fixed 
display orders, and searches return a lot of junk, without easy access to better 
searching in context, but try:


https://github.com/spdx/license-list-data/blob/main/licenses.md

which also has xrefs to the text files; also there are:

https://github.com/spdx/license-list-data/blob/main/json/licenses.json
https://github.com/spdx/license-list-data/blob/main/json/exceptions.json

which can be easily processed using `jq`.

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Christian Franke via Cygwin-apps]

Brian Inglis via Cygwin-apps wrote:

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:
...

Attached.
The new script uses the SPDX webpages to create the license file. I 
didn't find a usable single license list at https://github.com/spdx


What about:

https://spdx.github.io/license-list-data/



This is apparently a draft version of 
https://spdx.org/licenses/index.html which is used by the script to 
generate the local license file.




and everything under:

https://github.com/spdx/license-list-data


I didn't find a single file which lists the licenses there.

Re: [PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Brian Inglis via Cygwin-apps]

On 2024-04-30 11:45, Christian Franke via Cygwin-apps wrote:

Jon Turney via Cygwin-apps wrote:
PS: I have a local script which checks SPDX Identifiers and expressions. Any 
interest to add this to cygport and then check LICENSE settings?

Oh, yes please. That sounds like a good idea.



Attached.
The new script uses the SPDX webpages to create the license file. I didn't find 
a usable single license list at https://github.com/spdx


What about:

https://spdx.github.io/license-list-data/

and everything under:

https://github.com/spdx/license-list-data

The data/spdx-licenses file is not included in the patch. It could be generated 
from the source dir with:

$ tools/spdx-check -f data/spdx-licenses -m
...
data/spdx-licenses: created
$ sha1sum data/spdx-licenses
80a19d6891d08bf34113464464ee12308374c792 *data/spdx-licenses
The changes to the meson files are guessed. I didn't test the meson build yet.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Costing and Designing Solutions

[arnoldroberts123--- via Cygwin]

Hello,

I'm hoping you receive this email. Our staff specializes in precise and 
effective estimate takeoffs for building firms such as yours. 
Our group is prepared to make your estimating problems easier. 

Think for a moment about how much time and accuracy our services could save you 
on your projects. We can't wait to help you succeed.

With regards,
Arnold Robert
Estimating Dept. 
Classic Estimation LLC


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

[PATCH cygport] Add check of SPDX expression provided by LICENSE variable

[Christian Franke via Cygwin-apps]

Jon Turney via Cygwin-apps wrote (thread "[PATCH cygport] Add 
repro-finish command"):

...
PS: I have a local script which checks SPDX Identifiers and 
expressions. Any interest to add this to cygport and then check 
LICENSE settings?


Oh, yes please. That sounds like a good idea.



Attached.

The new script uses the SPDX webpages to create the license file. I 
didn't find a usable single license list at https://github.com/spdx


The data/spdx-licenses file is not included in the patch. It could be 
generated from the source dir with:


$ tools/spdx-check -f data/spdx-licenses -m
...
data/spdx-licenses: created

$ sha1sum data/spdx-licenses
80a19d6891d08bf34113464464ee12308374c792 *data/spdx-licenses

The changes to the meson files are guessed. I didn't test the meson 
build yet.


--
Regards,
Christian

From 61f75757fa8e9118207cc09cf4a621aac8a4da78 Mon Sep 17 00:00:00 2001
From: Christian Franke 
Date: Tue, 30 Apr 2024 19:28:01 +0200
Subject: [PATCH] Add check of SPDX expression provided by LICENSE variable

The new script 'tools/spdx-checks' checks a SPDX license expression.
License identifiers are provided by the new file 'spdx-licenses'
which could be created by the script from the related SPDX webpages.
---
 bin/cygport.in|  17 
 data/meson.build  |   1 +
 tools/meson.build |   1 +
 tools/spdx-check  | 198 ++
 4 files changed, 217 insertions(+)
 create mode 100644 tools/spdx-check

diff --git a/bin/cygport.in b/bin/cygport.in
index 15bd559e..3166beba 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -41,6 +41,7 @@ declare -r  _cygport_version=@VERSION@;
 declare -r _privdatadir=@pkgdatadir@;
 declare -r _privclassdir=@cygclassdir@;
 declare -r _privlibdir=@cygpartdir@;
+declare -r _privtoolsdir=@pkgdatadir@/tools;
 declare -r _privgnuconfigdir=@gnuconfigdir@;
 declare -r _privsysconfdir=@sysconfdir@;
 
@@ -489,6 +490,22 @@ do
fi
 done
 
+if [ "${LICENSE+y}" = "y" ]
+then
+   if ! _out=$(${_privtoolsdir}/spdx-check -f 
${_privdatadir}/spdx-licenses "${LICENSE}" 2>&1)
+   then
+   warning "LICENSE='${LICENSE}' is invalid:"
+   echo "${_out}"
+   elif [ "${_out:+y}" = "y" ]
+   then
+   warning "LICENSE='${LICENSE}' has warnings:"
+   echo "${_out}"
+   else
+   inform "LICENSE='${LICENSE}' is valid"
+   fi
+   unset _out
+fi
+
 for restrict in ${RESTRICT//,/ }
 do
declare _CYGPORT_RESTRICT_${restrict//-/_}_=1
diff --git a/data/meson.build b/data/meson.build
index 51c6a5fd..e83a90fe 100644
--- a/data/meson.build
+++ b/data/meson.build
@@ -2,6 +2,7 @@ datadocs = files('cygport.conf', 'mirrors')
 
 install_data('mirrors',
  'sample.cygport',
+ 'spdx-licenses',
  install_dir: pkgdatadir)
 
 install_data('gnuconfig/config.guess',
diff --git a/tools/meson.build b/tools/meson.build
index acd83926..96d8d19e 100644
--- a/tools/meson.build
+++ b/tools/meson.build
@@ -1,6 +1,7 @@
 tools = files(
 'deb2targz',
 'pkgrip',
+'spdx-check',
 'sysrootize'
 )
 
diff --git a/tools/spdx-check b/tools/spdx-check
new file mode 100644
index ..bffcaae0
--- /dev/null
+++ b/tools/spdx-check
@@ -0,0 +1,198 @@
+#! /bin/bash
+###
+#
+# spdx-check - check SPDX license expression
+#
+# Copyright (C) 2024 Christian Franke
+#
+# SPDX-License-Identifier: BSD-3-Clause
+#
+
+
+set -e -o pipefail
+myname=$0
+
+# SPDX license list web pages
+spdx_url_lic="https://spdx.org/licenses/index.html;
+spdx_url_exc="https://spdx.org/licenses/exceptions-index.html;
+
+# Default license file
+def_spdx_file="$(dirname "$myname")/spdx-licenses"
+
+usage()
+{
+  cat <&2
+  exit 1
+}
+
+warning()
+{
+  echo "Warning:" "$@" >&2
+}
+
+check_spdx_id()
+{
+  local id=$1
+  local m m_id
+
+  if ! [ -f "$spdx_file" ]; then
+warning "Missing '$spdx_file' - SPDX identifier '$1' not checked"
+return 0
+  fi
+
+  # SPDX identifiers are case insensitive but the correct case is recommended
+  m=$(grep -Ei -m 1 "^!?&?${id//+/\\+}\$" "$spdx_file" 2>/dev/null) \
+|| error "Unknown SPDX identifier '$id'"
+
+  # TODO: Distinguish licenses and exceptions
+  m_id=${m#!}; m_id=${m_id#&}
+
+  [ "$m_id" = "$id" ] || warning "It is recommended to use '$m_id' instead of 
'$id'"
+  [ "$m" = "${m#!}" ] || warning "SPDX identifier '$m_id' is deprecated"
+}
+
+check_spdx_expr()
+{
+  local x=$1
+  local f s t
+
+  # Insert spaces around tokens to simplify parsing
+  x=" $x "; x=${x//(/ ( }; x=${x//)/ ) }
+
+  # Check tokens
+  f=false
+  for t in $x; do
+f=true
+case $t in
+  AND|OR|WITH|[\(\)])
+;;
+  [Aa][Nn][Dd]|[Oo][Rr]|[Ww][Ii][Tt][Hh])
+error "Invalid token '$t' - use '${t@U}' instead" ;;
+  [0-9A-Za-z]*)
+s=${t%+}; s=${s//[-.0-9A-Za-z]/}
+[ -z 

Re: Cygwin - rsync / new release 3.2.7 => 3.3.0

[Jon Turney via Cygwin-apps]

On 29/04/2024 15:10, Jari Aalto wrote:

On 2024-04-28 21:41, Chad Dougherty wrote:

Hello Jari,

On 4/27/24 05:12, Jari Aalto wrote:

Hi Chad, you seemed to take care of rsync while I was unavailable.  If
you still want to maintain rsync, would you update it to latest
version.

I checked and it compiles ok.

... but you might want to also apply the Debian patches to the latest
version


It's good to hear from you.  I'd be happy for you to resume maintainership
of this package if you're willing.  I no longer actively use Cygwin so it
would make more sense for someone else to do it.


Chad,

I guess that means that your other packages are orphaned?

$ grep 'Chad Dougherty' cygwin-pkg-maint
lz4  Chad Dougherty
mingw64-i686-lz4 Chad Dougherty
mingw64-x86_64-lz4   Chad Dougherty
minisign Chad Dougherty
passwdqc Chad Dougherty

Thanks for your work on these as a maintainer.


Thanks Chad, I have the latest ready, so I can continue maintaining.

Jon, would someone update the Cygwin Porters file in order to proceed
with the upload.


Jari,

Done.

I set your rsync-3.3.0-1 upload to be retried, which seems to have 
succeeded.

Re: [PATCH cygport] Add customization support for announce command

[Christian Franke via Cygwin-apps]

Jon Turney wrote:

On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:

Christian Franke wrote:
The email generated by the cygport announce command is useful, but 
actual use cases are somewhat limited due to the hard-coded email 
submission.


The attached patch adds more flexibility. The patch is on top of 
the "Use correct wording if only one package is announced" patch.


Slightly changed patch attached. Also adjusted to new version of 
"Use correct wording if only one package is announced" patch.




[...]

Thanks for this.


Possible (better?) alternative names for the new settings:
ANNOUNCEMENT_EDITOR
ANNOUNCEMENT_MAILER


Hmmm... I think "ANNOUNCE_EDITOR" and "ANNOUNCE_MAILER" would be
the best for clarity and conciseness.


New patch attached. Is still on top of "Use correct wording ..." patch.

I also added HOMEPAGE to the propagated variables as this should be 
included in an announcement.


Thanks.


+    /bin/bash -c "cd ${top} || exit 1
+${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
+P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
+${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
+${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
+${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
+${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
+${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
+${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
+${cmd}
+" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}' 
(cwd=${top}) failed"

+}


Sorry I didn't notice this before, and I am terrible at writing shell, 
but perhaps you could share the reasoning behind writing this as 
above, and not as, e.g.


(cd ${top} && env BLAH ${cmd})

avoiding all the verbiage in the description of ANNOUNCE_EDITOR about 
it being fed into 'bash -c' (and hence getting evaluated twice??) 
rather than just run?





None of the mentioned variables are exported to the environment by 
cygport. I wanted to keep this fact in the subshell. Therefore the 
assignments are added to the script instead of passing via 
env(ironment). The latter won't even work with the PV variable because 
arrays could not be exported.


Variables would not be evaluated twice. For example in the rare case 
that someone uses something like


SMTP_SERVER="smtp.$(hostname -d)"

in cygport.conf, this would immediately expand to 
SMTP_SERVER="smtp.some.domain". The above


${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}

would expand to

SMTP_SERVER=${SMTP_SERVER@Q}

and then to

SMTP_SERVER='smtp.some.domain'

(The @Q bash extension ensures proper quoting).

Re: native symlinks and non-existent targets

[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

[ITA] bash-completion/-devel

[Brian Inglis via Cygwin-apps]

I would like to co-maintain or adopt and revive the above package, which was 
adopted by Eric but not updated since Yaakov.


Below are links to existing source packages, build repos, scallywag runs, and 
updated package info.


I would like to further improve the sdesc and ldesc provided to reflect that 
completions are provided for thousands of commands and their options and arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground

Scallywag runs:

https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=bash-completion

Bash Completions and development

bash-completion is a collection of shell functions that use the
programmable completion feature of bash.

For more information see the project home page:

https://github.com/scop/bash-completion

See below for details of changes:

https://github.com/scop/bash-completion/blob/master/CHANGELOG.md


bash-completion Bash Completions

Existing package:

https://cygwin.com/packages/summary/bash-completion.html


bash-completion-devel   Bash Completions (development)

Existing package:

https://cygwin.com/packages/summary/bash-completion-devel.html

Re: native symlinks and non-existent targets

[Csaba Ráduly via Cygwin]

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


Csaba

--
Life is complex, with real and imaginary parts.


--
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: cygport may not create debug info if top directory contains a symlink

[Jon Turney via Cygwin-apps]

On 18/09/2023 18:24, Brian Inglis via Cygwin-apps wrote:

On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:

Brian Inglis wrote:

On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:

On 16/09/2023 15:17, Christian Franke via Cygwin wrote:

Found during tests of busybox package:
If the path of the top build directory contains a symlink and the 
project's build scripts normalize pathnames, no debug info is 
created by cygport.


This is because options like
  -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler is 
run with the real source path.



[...]


Sidenote: we should probably also be using file-prefix-map, now 
we're on a gcc which supports it.


... also macro-prefix-map, although it looks like changing to 
-ffile-prefix-map is equivalent to -f*-prefix-map which future proofs 
the options!


So I updated to using -ffile-prefix-map in cygport 0.36.8, since that 
seems like the "Right Thing(TM)"


I discovered today that, amazingly, this breaks compiling ruby, since in 
one place it does:


#include __FILE__

(yeah, that's pretty jaw dropping...)

Re: [PATCH cygport] Add customization support for announce command

[Jon Turney via Cygwin-apps]

On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:

Christian Franke wrote:
The email generated by the cygport announce command is useful, but 
actual use cases are somewhat limited due to the hard-coded email 
submission.


The attached patch adds more flexibility. The patch is on top of the 
"Use correct wording if only one package is announced" patch.


Slightly changed patch attached. Also adjusted to new version of "Use 
correct wording if only one package is announced" patch.




[...]

Thanks for this.


Possible (better?) alternative names for the new settings:
ANNOUNCEMENT_EDITOR
ANNOUNCEMENT_MAILER


Hmmm... I think "ANNOUNCE_EDITOR" and "ANNOUNCE_MAILER" would be
the best for clarity and conciseness.


New patch attached. Is still on top of "Use correct wording ..." patch.

I also added HOMEPAGE to the propagated variables as this should be 
included in an announcement.


Thanks.


+   /bin/bash -c "cd ${top} || exit 1
+${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
+P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
+${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
+${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
+${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
+${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
+${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
+${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
+${cmd}
+" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}' (cwd=${top}) 
failed"
+}


Sorry I didn't notice this before, and I am terrible at writing shell, 
but perhaps you could share the reasoning behind writing this as above, 
and not as, e.g.


(cd ${top} && env BLAH ${cmd})

avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it 
being fed into 'bash -c' (and hence getting evaluated twice??) rather 
than just run?

Re: [PATCH cygport] Add repro-finish command

[Jon Turney via Cygwin-apps]

On 11/03/2024 11:41, Christian Franke via Cygwin-apps wrote:
Thanks for accepting the repro-check patch. A minor enhancement is 
attached.


Applied. Thanks!

The function is in pkg_pkg.cygpart instead of pkg_cleanup.cygpart 
because then it is easier to keep it in sync with the other __repro_* 
functions.


PS: I have a local script which checks SPDX Identifiers and expressions. 
Any interest to add this to cygport and then check LICENSE settings?


Oh, yes please. That sounds like a good idea.

Re: [PATCH cygport] dodoc: Skip a file if a compressed version already exists

[Jon Turney via Cygwin-apps]

On 10/03/2024 15:44, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like 
change logs. This seems to be common practice on Debian etc.


With current cygport, the following results in ChangeLog and 
ChangeLog.gz in the docdir:


src_install()
{
   ...
   dodoc ChangeLog
   gzip -9 -n "${D}/usr/share/doc/${PN}/ChangeLog"
}


Uh, I don't quite see how this patch will change the behavior of this 
fragment.




Yes, it actually doesn't change the behavior of this fragment itself.


Even more confusing, why isn't this already doing what you want? 
Unless you specify -k/--keep to gzip, the input file is removed, right?


Yes - but after this src_install() the file will be re-added by 
__predoc() unless _CYGPORT_RESTRICT_postinst_doc_ is set. The patch 
avoids this because __predoc() also uses dodoc().


Ah, I get it.

Applied with a bit of rewording of the commit commentary for dullards 
like myself.


Thanks.

Re: OpenSSL 3.0.14

[ASSI via Cygwin]

FOPPE, JEFFERY B CIV USAF AFMC AFLCMC/WFRQ via Cygwin writes:
> Is the OpenSSL 3.0.14 package going to be released soon?

You should ask that question upstream first.


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

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

[FOPPE, JEFFERY B CIV USAF AFMC AFLCMC/WFRQ via Cygwin]

Is the OpenSSL 3.0.14 package going to be released soon?



Jeff Foppe
AFLCMC/WFRQ

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