[ITP] perl-Parse-Yapp-1.21

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-03 Thread 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

2024-05-02 Thread 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

2024-05-02 Thread 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)

2024-05-02 Thread Ziemowit Laski via Cygwin-apps
Name: Ziemowit Laski
 BEGIN SSH2 PUBLIC KEY 
C3NzaC1lZDI1NTE5IBlHSdOpkyPkqoVmAqoq8tSpKepnFanhk+/B8byFumt8
 END SSH2 PUBLIC KEY 



My SSH key

2024-05-02 Thread 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 ?

2024-05-02 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-05-01 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

2024-04-30 Thread 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

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

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

Regards,
Lee

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


[ITA] bash-completion/-devel

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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

2024-04-29 Thread 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


XDMCP connection hangs, then blanks, after a while

2024-04-29 Thread Henry S. Thompson via Cygwin
I've enabled XDMCP on a local (debian/lightdm) box, and can
successfully connect to it from Cygwin using a modified version of
startxwin in order to launch

  /usr/bin/XWin :1 -clipboard -dpi 100 -query [my host] -auth 
[me]/.serverauth.6351

All works well, useful work is done, go and have a coffee, come back
and it's frozen (cursor follows mouse, but no kbd or click has any
effect).

Leave it a while longer, and it goes black.  I _think_ the problem is
at the Cygwin end, because if I ssh to the Linux box, I can, for
example, connect to and use an (x)emacs instance I launched inside the
XDMCP instance while it was still working.  But the changes to that
editor window are not reflected on what I can see (but not affect) on
the Cygwin viewer.

Any suggestions welcome, wrt configuration, XWin args or debugging
steps I might try, on either side.

And yes, I do know about vnc, and will probably give up and go back to
that, but it has some frustrating niggles of its own...

Thanks,

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND
   e-mail: h...@inf.ed.ac.uk
  URL: https://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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


Register ssh key with cygwin

2024-04-28 Thread Đoàn Bảo Trung via Cygwin-apps
Name: Trung Doan

 BEGIN SSH2 PUBLIC KEY 
Comment: "256-bit ED25519, converted by Trung Doan@TrungPC from OpenSS"
C3NzaC1lZDI1NTE5IHwmvMOZsZM8JIAkDK0eT/KXTGyedtvSVz6tJw6i29vb
 END SSH2 PUBLIC KEY 


Test: ncurses/-demo terminfo/-extra libncurses/-devel/++/w10 6.5+20240427 (TEST)

2024-04-28 Thread Cygwin ncurses Maintainer
The following test packages have been uploaded to 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
* libncurses++w10   6.5+20240427
* libncursesw10 6.5+20240427

The ncurses (new curses) library is an emulation of Sys V R 4
curses, and more. It uses terminfo format, supports pads, color,
multiple highlights, forms characters, function key mapping,
and has all the other SVR4 curses enhancements over BSD curses.

For more information see the project home page:

https://invisible-island.net/ncurses


Please test these packages as extensively as possible (especially if you
are a Cygwin package maintainer) as libncursesw10 is used in many
libraries including libreadline and utilities including less, vim,
emacs, most other editors, screen, tmux, mail and web clients, and bash.
Package maintainers should install this test release and rerun checks of
as many libraries and packages depending on libncurses{,++}w10 as
possible.
If no issues are reported in the next few weeks, this release may be
promoted to current stable.


As there are multiple components and may be 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 (patches by Branden Robinson).
  - fix redefinition of CASTxPTR, for legacy Unix.

20240420
  - improve formatting/style of manpages (patches by Branden Robinson).
  - compiler warning/portability fixes.

20240414
  - build/bug-fix for check-size feature (reports by Sam James, Gabriele
  Balducci).

20240413
  - improve formatting/style of manpages (patches by Branden Robinson).
  - provide for padding in check-size feature, using new_prescr() to
  pass interim SCREEN pointer.
  - complete change for opaque options (Gentoo #928973, cf: 20231021).
  - 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 

X.Org X11 package refresh

2024-04-28 Thread Jon Turney



The following packages have been uploaded to the Cygwin distribution:

* libX11-1.8.9-1
* libXaw-1.0.16-1
* libXaw3d-1.6.6-1
* libXcursor-1.2.2-1
* libXdmcp-1.1.5-1
* libXext-1.3.6-1
* libXmu-1.2.1-1
* libfontenc-1.1.8-1
* libxcb-1.17.0-1
* libxkbcommon-1.7.0-1
* libxkbfile-1.1.3-1
* pixman-0.43.4-1

* bitmap-1.1.1-1
* editres-1.0.9-1
* iceauth-1.0.10-1
* listres-1.0.6-1
* mkfontscale-1.2.3-1
* xauth-1.1.3-1
* xbiff-1.0.5-1
* xditview-1.0.7-1
* xedit-1.2.4-1
* xev-1.2.6-1
* xfontsel-1.1.1-1
* xkbcomp-1.4.7-1
* xkbutils-1.0.6-1
* xload-1.2.0-1
* xlsfonts-1.0.8-1
* xman-1.2.0-1
* xmessage-1.0.7-1
* xmh-1.0.5-1
* xmore-1.0.4-1
* xpr-1.2.0-1
* xprop-1.2.7-1
* xrefresh-1.1.0-1
* xsm-1.0.6-1

* gccmakedep-1.0.4-1
* imake-1.0.10-1
* lndir-1.0.5-1
* makedepend-1.0.9-1
* xorg-sgml-doctools-1.12.1-1
* xorg-util-macros-1.20.1-1

* encodings-1.1.0-1
* xcb-proto-1.17.0-1
* xorgproto-2024.1-1
* xorg-docs-1.7.3-1

This is an update to the latest individual releases of several of the
X.Org X11 components.  Please see the upstream xorg-announce archives
for details about these releases.
--
 *** 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: setup (2.932)

2024-04-28 Thread Jon Turney


A new version of Setup (2.932) has been uploaded to:

 https://cygwin.com/setup-x86_64.exe  (64 bit version)
 https://cygwin.com/setup-x86.exe (32 bit version)

Changes compared to 2.931:

- Fix '--help' going into an endless loop when trying to line-break 
localized text which doesn't contain a space (Thanks to 赵伟)


- Fix handling of unicode in "Contribute to translations" link text

- Use "Microsoft YaHei UI" font for zh localized dialogs (Thanks to Yang 
Yu Lin)


- Use the actual processor architecture of the running setup (rather 
than the processor architecture selected for installation) in the URLs 
suggested for obtaining an updated setup.


- Likewise, display the actual processor architecture of the running 
setup (rather than the processor architecture selected for installation) 
in the splash page.



Replies to this message are not the place for setup feature requests.

For instructions on obtaining and building the source code for setup, 
see https://sourceware.org/cygwin-apps/setup.html


Please send bug reports, as usual, to the public mailing list cygwin AT 
cygwin DOT com.

--
 *** 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] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

2024-04-28 Thread Christian Franke via Cygwin-apps

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

--
Regards,
Christian



Updated: {,mingw64-{x86_64,i686}-}libarchive-3.7.4-1

2024-04-28 Thread ASSI


Libarchive has been updated to version 3.7.4-1, the following
(sub-)packages:

libarchive (source)
libarchive-devel
libarchive13
bsdcat
bsdcpio
bsdtar
bsdunzip

are available in the Cygwin distribution.  The MinGW64 packages for
the cross-compilation toolchains have been updated as well:

mingw64-i686-libarchive
mingw64-x86_64-libarchive

This is a minor upstream bugfix release.

DESCRIPTION
Multi-format archive and compression library
It is a portable, efficient C library that can read and write streaming
archives in a variety of formats. It also includes implementations
of the common tar, cpio, and zcat command-line tools that use the
libarchive library.

HOMEPAGE
https://www.libarchive.org/

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

2024-04-28 Thread ASSI


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

x86_64
--
 perl-Crypt-OpenSSL-Bignum-0.09-5
 perl-Net-DNS-SEC-1.24-1
 perl-Text-CSV_XS-1.54-1
 perl-XS-Parse-Keyword-0.41-1

noarch
--
 perl-Business-ISBN-Data-20240426.001-1
 perl-DateTime-Locale-1.42-1
 perl-ExtUtils-Config-0.009-1
 perl-ExtUtils-InstallPaths-0.013-1
 perl-MIME-tools-5.515-1
 perl-Test-MockModule-0.178.0-1
 perl-Test2-Suite-0.000162-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: 
.



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

2024-04-28 Thread ASSI via Cygwin-apps
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?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves


aom 3.9.0-1

2024-04-28 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* aom-3.9.0-1
* libaom3-3.9.0-1
* libaom-devel-3.9.0-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: 
.



Re: Cygwin X - Vast performance difference between X-over-ssh and xdmcp

2024-04-27 Thread Jim Garrison via Cygwin

On 4/27/2024 13:56, jojelino via Cygwin wrote:

On 4/28/2024 4:36 AM, Jim Garrison via Cygwin wrote:
The speed difference is stark.  With X-over-ssh Eclipse is unusable, 
PyCharm barely so.  When running in an xdmcp session both are 
blazingly fast with no detectable lag.


What would make such a huge difference?


Why don't you allow Compression in sshd_config? there's no skin support 
in those IDEs..




Compression is on.  An example... in X-over-ssh, the simple action of 
displaying a dropdown menu in Eclipse takes 1500-2000 ms.  In xdmcp it's 
not perceptible.


--
Jim Garrison
j...@acm.org


--
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 X - Vast performance difference between X-over-ssh and xdmcp

2024-04-27 Thread jojelino via Cygwin

On 4/28/2024 4:36 AM, Jim Garrison via Cygwin wrote:
The speed difference is stark.  With X-over-ssh Eclipse is unusable, 
PyCharm barely so.  When running in an xdmcp session both are blazingly 
fast with no detectable lag.


What would make such a huge difference?


Why don't you allow Compression in sshd_config? there's no skin support 
in those IDEs..


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


Cygwin X - Vast performance difference between X-over-ssh and xdmcp

2024-04-27 Thread Jim Garrison via Cygwin

This may be off-top, please advise if so

TL;DR

Running X clients (pyCharm, git gui, Eclipse) on a Debian 12 system with 
Cygwin-X as the display server exhibits vast performance differences 
depending on how the X session is connected. X-over-ssh is sluggish and 
laggy, but the same apps are lightning fast in an xdmcp desktop session.


Details:

Cygwin/X Server: Ryzen 9 7940HS, 32GB RAM, Windows 11, fully updated
Client: Intel i5-1135G7, 16GB RAM, Debian 12, fully updated
Network: 2.5GB ethernet (verified with iperf3)

The speed difference is stark.  With X-over-ssh Eclipse is unusable, 
PyCharm barely so.  When running in an xdmcp session both are blazingly 
fast with no detectable lag.


What would make such a huge difference?

--
Jim Garrison


--
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: |FILE_ID_BOTH_DIR_INFORMATION| fields |ShortName|+|ShortNameLength| mandatory for Cygwin and Window 10 ?

2024-04-27 Thread Brian Inglis via Cygwin

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

This really makes a big difference on directories like /var/log/ and /tmp/ if 
apps create a lot of files with similar name prefixes there, for example, 
date/time suffixed long file names from multiple hourly cron jobs, as long names 
can be queried via the B-tree but short names have to be scanned sequentially.



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

% fsutil 8dot3name set /?
usage : fsutil 8dot3name set [0 through 3] | [ 1 | 0]

When a volume is not specified the operation updates the registry value:

0 - Enable 8dot3 name creation on all volumes on the system
1 - Disable 8dot3 name creation on all volumes on the system
2 - Set 8dot3 name creation on a per volume basis
3 - Disable 8dot3 name creation on all volumes except the
  system volume

When a volume is specified the operation updates the individual
volume's on disk flag.  This operation is only meaningful
if the registry value is set to 2.

0 - Enable 8dot3 name creation on this volume
1 - Disable 8dot3 name creation on this volume

This operation takes effect immediately (no reboot required).

Sample commands:
  "fsutil 8dot3name set 1"  - disable 8dot3 name creation on all volumes
  "fsutil 8dot3name set C: 1"   - disable 8dot3 name creation on c:

% regtool get -v 
/proc/registry/HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/FileSystem/NtfsDisable8dot3NameCreation

2

% fsutil 8dot3name query c:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).

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

Based on the above settings, 8dot3 name creation is enabled on d:

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


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

2024-04-27 Thread Roland Mainz via Cygwin
Hi!



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 ?

Is there anything else for a filesystem driver to do to indicate that
|ShortName| support is not available ?



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: [ITA] libkate

2024-04-27 Thread Takashi Yano via Cygwin-apps
On Sat, 27 Apr 2024 20:35:34 +0900
Takashi Yano wrote:
> Hi,
> 
> I would like to adopt libkate package.
> Thanks.

Sorry, the package seems to be already the latest version.
Update is not necessary so far.

-- 
Takashi Yano 


vorbis-tools 1.4.2-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* vorbis-tools-1.4.2-1

vorbis-tools contains oggenc (an encoder) and ogg123 (a playback tool).
It also has vorbiscomment (to add comments to vorbis files), ogginfo (to give
all useful information about an ogg file, including streams in it), oggdec (a
simple command line decoder), and vcut (which allows you to cut up vorbis
files).
-- 
  *** 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: 
.



[ITA] libkate

2024-04-27 Thread Takashi Yano via Cygwin-apps
Hi,

I would like to adopt libkate package.
Thanks.

-- 
Takashi Yano 


speexdsp 1.2.1-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* speexdsp-1.2.1-1
* speexdsp-devel-1.2.1-1
* libspeexdsp1-1.2.1-1

Speex is a patent-free audio codec designed especially for voice
(unlike Vorbis which targets general audio) signals and providing good
narrowband and wideband quality. This project aims to be complementary to
the Vorbis codec.
-- 
  *** 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: 
.



speex 1.2.1-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* speex-1.2.1-1
* speex-devel-1.2.1-1
* libspeex1-1.2.1-1

Speex is a patent-free audio codec designed especially for voice
(unlike Vorbis which targets general audio) signals and providing good
narrowband and wideband quality. This project aims to be complementary to
the Vorbis codec.
-- 
  *** 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: 
.



libvorbis 1.3.7-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* libvorbis-1.3.7-1
* libvorbis-devel-1.3.7-1
* libvorbis0-1.3.7-1
* libvorbisenc2-1.3.7-1
* libvorbisfile3-1.3.7-1

Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
and general-purpose compressed audio format for audio and music at
fixed and variable bitrates from 16 to 128 kbps/channel.
-- 
  *** 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: 
.



libogg 1.3.4-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* libogg-1.3.4-1
* libogg-devel-1.3.4-1
* libogg0-1.3.4-1

Libogg is a library for manipulating ogg bitstreams.  It handles both
making ogg bitstreams and getting packets from ogg bitstreams.
-- 
  *** 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: 
.



flac 1.4.3-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* flac-1.4.3-1
* flac-devel-1.4.3-1
* flac-docs-1.4.3-1
* libFLAC12-1.4.3-1
* libFLAC++10-1.4.3-1

FLAC is an Open Source lossless audio codec developed by Josh Coalson.
-- 
  *** 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: 
.



mpg123 1.32.6-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* mpg123-1.32.6-1
* mpg123-pulse-1.32.6-1
* libmpg123_0-1.32.6-1
* libmpg123-devel-1.32.6-1
* libout123_0-1.32.6-1
* libout123-devel-1.32.6-1

mpg123 is a cross-platform, real time MPEG 1.0/2.0/2.5 audio
player/decoder for layers 1,2 and 3 (MPEG 1.0 layer 3 aka MP3 most
commonly tested).
-- 
  *** 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: 
.



fribidi 1.0.14-1

2024-04-27 Thread Takashi Yano via Cygwin-announce
The following packages have been uploaded to the Cygwin distribution:

* fribidi-1.0.14-1
* libfribidi0-1.0.14-1
* libfribidi-devel-1.0.14-1
* libfribidi-doc-1.0.14-1

A library that implements the Unicode Bidirectional Algorithm
(also knows as BiDi).
-- 
  *** 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: 
.



Need to update file package utility 5.44 to 5.45 and keychain 2.7.1 to 2.8.5

2024-04-26 Thread J M via Cygwin
Hi,

The keychain package already has updated by the Ubuntu Team:
dpkg --list | grep keychain
ii  keychain  2.8.5-2
all  key manager for OpenSSH

And the file package utility because I find bugs inside 5.44 version, and
widely used, already inquiry to Ubuntu Team to update (5.41).

Here is an example use case that I detected:
https://bugs.astron.com/changelog_page.php
#  Private PKCS8 SSH keys show up as ASCII text.
https://bugs.astron.com/view.php?id=443


Regards,
Cesar Jorge

-- 
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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

2024-04-26 Thread Andrey Repin via Cygwin
Greetings, Dan Shelton!

>> Then just change /etc/nsswitch.conf to enumerate "local" as well
>> and be done with it.

> That file is read-only for some customer installations, and we are not
> allowed to touch it.

Then tell the system administrator to touch it.

>>
>> You can even go so far as to use the Windows enumerator, i.e.,
>>
>>   $ net localgroup
>>
>> and than script it to use its output as input to getent group
>> for only the groups you really need info for.

> net localgroup changes layout and messages per system locale. That
> might be nice to watch as a human user, but impossible to write a
> parser. That damn thing does not honor LC_ALL, and I am now basically
> forced to write custom parsers for each customers language.

Try `chcp 65001` before calling to it. It may behave better then.


-- 
With best regards,
Andrey Repin
Friday, April 26, 2024 12:02:05

Sorry for my terrible english...


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


Re: Issue with cygdrive mount, native symlinks, and noacl option

2024-04-26 Thread Andrey Repin via Cygwin
Greetings, Christopher Layne!

> I noticed recently while attempting to rsync directories from one drive to
> another that I was getting the familiar "NULL SID", "incorrectly ordered",
> etc. type ownership issues on the destination even though I use noacl for
> cygdrive mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence
> why I use "noacl" for cygdrive). I was able to track down the issue to a
> specific combination of things that creates the problem:

> 1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s 
> /cygdrive/ /.

Just make cygdrive prefix / in this case.
Portable apps should use /proc/cygdrive/ regardless.

> 2. All symlinks are actually native reparse points as a I run with
> CYGWIN=winsymlinks:nativestrict by default.

> Example:

> clayne@sv590:/ $ ls -lad /[a-z]
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
> lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s

What is the actual symlink target? (not what is reported by Cygwin)

> 3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ 
> /s/some-dir/

> The issue here is that it appears mount related options such as noacl are
> evaluated differently when native symlinks are used. If I change the
> destination to instead be "/cygdrive/s/dest/dir" then noacl works
> appropriately. On top of all this, if I instead create the /s symlink as a
> "cygwin" style symlink via CYGWIN=winsymlinks things also work correctly -
> that is, the noacl option is used. What I would intuitively expect, atleast
> within the context of acl vs noacl, is for the symlinks to be resolved first
> and then mount options specific to the target resolved based off what the
> symlink actually points to. In the native/nativestrict case, it appears to
> be doing this in reverse and inheriting /'s standard default acl option
> rather than /cygdrive's noacl option.

> Footnotes on workarounds:

> * I know how to workaround using the root-level symlinks in the first place
> by just mounting cygdrive to /, but I'd have to update various scripts which
> already use /cygdrive and I like having the "windows drives" self-contained
> under /cygdrive (even though I frequently use the / level symlinks as 
> shorthand).

See the note above about portable apps.

> * I also know how to avoid the issue entirely by using /cygdrive/ for
> the destination but the underlying issue still seems like a bug or an
> oversight to me, particularly given that nativestrict behaves differently
> when it comes to evaluating mount options.

See...

> * Another workaround would be to use non-nativestrict symlinks but I want
> to preserve interoperability with native windows applications outside of
> cygwin and I've learned over the years to just avoid anything that isn't
> nativestrict.

I'm with you here.


-- 
With best regards,
Andrey Repin
Friday, April 26, 2024 10:20:43

Sorry for my terrible english...


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


Re: DOS namespaces, accessible/walk-able as Admin via Cygwin?

2024-04-25 Thread Brian Inglis via Cygwin

On 2024-04-25 19:45, Dan Shelton via Cygwin wrote:

On Mon, 22 Apr 2024 at 07:01, Brian Inglis via Cygwin wrote:

On 2024-04-21 17:24, Dan Shelton via Cygwin wrote:

On Sat, 20 Apr 2024 at 05:37, Brian Inglis via Cygwin wrote:

2. If I have Administrator rights, is there a way in /proc where I can
/bin/ls -la  or /bin/find -ls all those DOS namespaces and soft links
to the real devices?


Cygwin exposes these MS Windows Executive Object Manager subsystem resource
objects under /proc/sys/ and object namespaces are per session under
/proc/sys/Sessions/ you have e.g.



$ ls -glo /proc/sys/Sessions/BNOLINKS/
total 0
lr--r--r-- 1 0 Apr 19 21:23 0 -> /proc/sys/BaseNamedObjects
lr--r--r-- 1 0 Apr 19 21:23 1 -> /proc/sys/Sessions/1/BaseNamedObjects

so each session has its own set of BaseNamedObjects, which you can list with
appropriate permissions, or using a tree browser.



Now where does the "1" in /proc/sys/Sessions/1/BaseNamedObjects come
from? Is there a Cygwin or Win32 API for that?


It's the MS Windows session number for the first user session.
You can access them using Cygwin or MS Windows directory lookups or tree
browsers, as I said.
Search microsoft.com for Windows sessions for details about MS Windows APIs.


Windows has multiple session apis (terminal, logon, ...), which is
used for the DOS namespace?


There really does not appear to be a "DOS" namespace, rather there are a bunch 
of legacy object names in the namespaces which may be used by console and GUI 
programs to access and operate on the underlying objects, possibly also using 
legacy APIs.



Under MS Windows you can use Sysinternals WinObj64 to browse the hierarchy and
objects.


What is that?


If you do not yet know that, perhaps you should not yet be digging into these MS
Windows Executive subsystem objects.

Some of these questions seem very abstract - are these academic questions or
projects?


Building knowledge, learning, and debugging actual code.


Have a look at the object hierarchies either using a Cygwin tree browser or the 
winobj64 object browser to see what is actually out there and their properties.


The Cygwin all-volunteer spare time project's interest is in using newlib libc 
and Windows APIs to provide Unix functionality, to relevant POSIX standards if 
available and appropriate.


For anything else you should consult the available project documentation in the 
cygwin-doc package or online, in the newlib-cygwin/winsup/cygwin C++ source code 
providing the emulation, any MS Windows documentation that the vendor cares to 
make available, and perhaps other MS Windows emulation based open source 
projects like Wine, mingw64, msys2, etc.


--
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: cygrunserv: sc config start=boot supported?

2024-04-25 Thread Brian Inglis via Cygwin

On 2024-04-25 19:54, Dan Shelton via Cygwin wrote:

Does Cygwin cygrunserv support the start mode start=boot?


Please install the packages cygwin-doc and cygrunsrv, and read the User Guide, 
the FAQ, the API docs, and the relevant program manual page, or search and read 
the online versions e.g.


https://cygwin.com/git/?p=newlib-cygwin.git=search=HEAD=pickaxe=cygrunsrv

and the underlying files referenced for more information.

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


cygrunserv: sc config start=boot supported?

2024-04-25 Thread Dan Shelton via Cygwin
Hello!

Does Cygwin cygrunserv support the start mode start=boot?

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
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: DOS namespaces, accessible/walk-able as Admin via Cygwin?

2024-04-25 Thread Dan Shelton via Cygwin
On Mon, 22 Apr 2024 at 07:01, Brian Inglis via Cygwin  wrote:
>
> On 2024-04-21 17:24, Dan Shelton via Cygwin wrote:
> > On Sat, 20 Apr 2024 at 05:37, Brian Inglis via Cygwin  
> > wrote:
> >>> 2. If I have Administrator rights, is there a way in /proc where I can
> >>> /bin/ls -la  or /bin/find -ls all those DOS namespaces and soft links
> >>> to the real devices?
> >>
> >> Cygwin exposes these MS Windows Executive Object Manager subsystem resource
> >> objects under /proc/sys/ and object namespaces are per session under
> >> /proc/sys/Sessions/ you have e.g.
>
> >> $ ls -glo /proc/sys/Sessions/BNOLINKS/
> >> total 0
> >> lr--r--r-- 1 0 Apr 19 21:23 0 -> /proc/sys/BaseNamedObjects
> >> lr--r--r-- 1 0 Apr 19 21:23 1 -> /proc/sys/Sessions/1/BaseNamedObjects
> >>
> >> so each session has its own set of BaseNamedObjects, which you can list 
> >> with
> >> appropriate permissions, or using a tree browser.
>
> > Now where does the "1" in /proc/sys/Sessions/1/BaseNamedObjects come
> > from? Is there a Cygwin or Win32 API for that?
>
> It's the MS Windows session number for the first user session.
> You can access them using Cygwin or MS Windows directory lookups or tree
> browsers, as I said.
> Search microsoft.com for Windows sessions for details about MS Windows APIs.

Windows has multiple session apis (terminal, logon, ...), which is
used for the DOS namespace?

> >> Under MS Windows you can use Sysinternals WinObj64 to browse the hierarchy 
> >> and
> >> objects.
> >
> > What is that?
>
> If you do not yet know that, perhaps you should not yet be digging into these 
> MS
> Windows Executive subsystem objects.
>
> Some of these questions seem very abstract - are these academic questions or
> projects?

Building knowledge, learning, and debugging actual code.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

-- 
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: Why python > 36 so many dependencies?

2024-04-25 Thread Jon Turney via Cygwin

On 25/04/2024 18:46, gs-cygwin.com--- via Cygwin wrote:

On Thu, Apr 25, 2024 at 10:19:05AM -0400, Peter Lai via Cygwin wrote:

Why does installing python > py36 result in bringing in so many
dependencies like libXdmcp etc, when the intent is to just run python
interpreter from cli? Is this because of the way it's built for cygwin? I
build python all the time in NetBSD using pkgsrc and in FreeBSD ports,
without needing all of those deps. I don't know much about how cygport
works, is there a repo of cygport files I can look at?


The load at https://cygwin.com/git/ is too high at the moment
and I get "503 - The load average on the server is too high"


https://cygwin.com/cgit/ may behave better.


Take a look at some mirrors.

For cygport code:
https://github.com/cygwin/cygport


This is just a mirror of https://cygwin.com/cgit/cygwin-apps/cygport/

You should probably take a look at the cygport manual () before reading 
the source code.



Lots of individual repositories under here with cygport projects
https://github.com/cygwinports/


No, don't look there!

Those repositories haven't been updated for some time, and really should 
really be archived, but the owner is too busy.



e.g.
https://github.com/cygwinports/python36


https://cygwin.com/cgit/cygwin-packages/python36/


--
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: Why python > 36 so many dependencies?

2024-04-25 Thread gs-cygwin.com--- via Cygwin
On Thu, Apr 25, 2024 at 10:19:05AM -0400, Peter Lai via Cygwin wrote:
> Why does installing python > py36 result in bringing in so many
> dependencies like libXdmcp etc, when the intent is to just run python
> interpreter from cli? Is this because of the way it's built for cygwin? I
> build python all the time in NetBSD using pkgsrc and in FreeBSD ports,
> without needing all of those deps. I don't know much about how cygport
> works, is there a repo of cygport files I can look at?

The load at https://cygwin.com/git/ is too high at the moment
and I get "503 - The load average on the server is too high" 

Take a look at some mirrors.

For cygport code:
https://github.com/cygwin/cygport

Lots of individual repositories under here with cygport projects
https://github.com/cygwinports/
e.g.
https://github.com/cygwinports/python36

Cheers, Glenn

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


Why python > 36 so many dependencies?

2024-04-25 Thread Peter Lai via Cygwin
Why does installing python > py36 result in bringing in so many
dependencies like libXdmcp etc, when the intent is to just run python
interpreter from cli? Is this because of the way it's built for cygwin? I
build python all the time in NetBSD using pkgsrc and in FreeBSD ports,
without needing all of those deps. I don't know much about how cygport
works, is there a repo of cygport files I can look at?

-- 
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: native symlinks and non-existent targets

2024-04-25 Thread Jon Turney via Cygwin

On 24/04/2024 23:36, Christopher Layne via Cygwin wrote:

On Wed, Apr 24, 2024 at 10:11:52PM +, Christopher Layne via Cygwin wrote:

Based on past threads I've read I believe the issue is actually with
windows not allowing a symlink to be created with a non-existent target,
but I do know windows does not care if you break a link after the fact.


Actually, after referring to some microsoft documentation, is this even
true?


No.

However, native symlinks do record the type (file or directory) of the 
destination, and (absent special knowledge) this cannot be determined if 
the destination doesn't exist (yet).


If I recall correctly, Cygwin doesn't care if the type recorded in the 
symlink is incorrect, but some parts of Windows do...



If it isn't true then this seems trivial to fix.


This assertion is trivially disproven by the lack of a patch attached. :)


--
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: native symlinks and non-existent targets

2024-04-24 Thread Christopher Layne via Cygwin
On Wed, Apr 24, 2024 at 10:11:52PM +, Christopher Layne via Cygwin wrote:
> Based on past threads I've read I believe the issue is actually with
> windows not allowing a symlink to be created with a non-existent target,
> but I do know windows does not care if you break a link after the fact.

Actually, after referring to some microsoft documentation, is this even
true?

https://learn.microsoft.com/en-us/windows/win32/fileio/symbolic-link-programming-considerations
---
Programming Considerations (Local File Systems)

Article 03/03/2021 5 contributors

Keep the following programming considerations in mind when working with 
symbolic links:

* Symbolic links can point to a non-existent target.
* When creating a symbolic link, the operating system does not check to see if 
the target exists.
* If an application tries to open a non-existent target, ERROR_FILE_NOT_FOUND 
is returned.
* Symbolic links are reparse points. For more information, see Determining 
Whether a Directory Is a Mounted Folder.
* There is a maximum of 63 reparse points (and therefore symbolic links) 
allowed in a particular path.
  (Windows Server 2003 and Windows XP: There is a limit of 31 reparse points on 
any given path.)
---

If it isn't true then this seems trivial to fix.

-cl

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


native symlinks and non-existent targets

2024-04-24 Thread Christopher Layne via Cygwin
Since I recently sent an email about symlinks and cygdrive mounts, I
figured I'd report another issue that's plagued me over the years and
that I know others have reported in the past: You can't create native
symlinks to non-existent targets and this causes a bunch of issues when
rsyncing directories containing symlinks unless one does a multi-pass
approach which takes special precautions to sync all the non-symlink
contents first and then syncs the symlinks right after (note: this also
has its own problems with links to links).

Example:

clayne@sv590:/tmp/link-test $ ls -la
total 32
drwxr-xr-x 1 clayne None 0 Apr 24 14:13 .
drwxrwxrwt 1 clayne None 0 Apr 24 14:34 ..
lrwxrwxrwx 7 clayne None 3 Apr 24 14:11 _foo -> foo
-rw-r--r-- 5 clayne None 0 Apr 24 14:11 foo
lrwxrwxrwx 4 clayne None 3 Apr 24 14:13 foo-ln -> foo

clayne@sv590:/tmp/link-test $ rsync -vaHSP /tmp/link-test/ 
/tmp/link-test-sync-test/
sending incremental file list
created directory /tmp/link-test-sync-test
./
rsync: [generator] symlink "/tmp/link-test-sync-test/_foo" -> "foo" failed: No 
such file or directory (2)
rsync: [generator] symlink "/tmp/link-test-sync-test/foo-ln" -> "foo" failed: 
No such file or directory (2)
foo
  0 100%0.00kB/s0:00:00 (xfr#1, to-chk=1/4)

sent 178 bytes  received 89 bytes  534.00 bytes/sec
total size is 6  speedup is 0.02
rsync error: some files/attrs were not transferred (see previous errors) (code 
23) at main.c(1336) [sender=3.2.7]

clayne@sv590:/tmp/link-test $ rsync -vaHSP /tmp/link-test/ 
/tmp/link-test-sync-test/
sending incremental file list
_foo -> foo
foo-ln -> foo

sent 134 bytes  received 18 bytes  304.00 bytes/sec
total size is 6  speedup is 0.04

This only works in a straight-forward manner when using non-native symlinks
(which can also _change_ the symlinks such that they're broken/unusable
outside of cygwin):

clayne@sv590:/tmp/link-test $ rm -rf /tmp/link-test-sync-test
clayne@sv590:/tmp/link-test $ CYGWIN= rsync -vaHSP /tmp/link-test/ 
/tmp/link-test-sync-test/
sending incremental file list
created directory /tmp/link-test-sync-test
./
_foo -> foo
foo
  0 100%0.00kB/s0:00:00 (xfr#1, to-chk=1/4)
foo-ln -> foo

sent 184 bytes  received 95 bytes  558.00 bytes/sec
total size is 6  speedup is 0.02

Or another very simple test-case not involving rsync:

clayne@sv590:/tmp/link-test $ ln -s this-does-not-exist some-link
ln: failed to create symbolic link 'some-link': No such file or directory

Relevant sections of an strace for the above:

  102   83054 [main] ln 1379 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\cygwin64\tmp\link-test)
  114   83168 [main] ln 1379 symlink_info::check: not a symlink
   91   83259 [main] ln 1379 symlink_info::check: 0 = 
symlink.check(C:\cygwin64\tmp\link-test, 0x7B140) (mount_flags 0x30008, 
path_flags 0x0)
   92   83351 [main] ln 1379 path_conv::check: 
this->path(C:\cygwin64\tmp\link-test\this-does-not-exist), has_acls(1)
   91   83442 [main] ln 1379 seterrno_from_win_error: 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/path.cc:2063 windows error 2
   90   83532 [main] ln 1379 geterrno_from_win_error: windows error 2 == errno 2
   83   83615 [main] ln 1379 symlink_worker: -1 = 
symlink_worker(this-does-not-exist, /tmp/link-test/some-link, 0)

However, you _can_ do this:

clayne@sv590:/tmp/link-test $ tmp="$(mktemp)" && ln -s "$tmp" some-link && rm 
-f "$tmp" && ls -la some-link
lrwxrwxrwx 1 clayne None 19 Apr 24 14:58 some-link -> /tmp/tmp.o7xpJxaqig

And here's a case showing where "hard-linked" symlinks work with
non-existent targets:

clayne@sv590:/tmp/link-test $ find -type l -print0 | rsync -avSHP 
--files-from=- --from0 --link-dest=/tmp/link-test /tmp/link-test 
/tmp/link-test-link-dest
building file list ... 
3 files to consider
created directory /tmp/link-test-link-dest

sent 113 bytes  received 59 bytes  344.00 bytes/sec
total size is 6  speedup is 0.03

clayne@sv590:/tmp/link-test $ ls -l /tmp/link-test-link-dest
total 0
lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 _foo -> foo
lrwxrwxrwx 5 clayne None 3 Apr 24 14:13 foo-ln -> foo

clayne@sv590:/tmp/link-test $ ls -lai _foo /tmp/link-test-link-dest/_foo
48413695994484407 lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 
/tmp/link-test-link-dest/_foo -> foo
48413695994484407 lrwxrwxrwx 8 clayne None 3 Apr 24 14:11 _foo -> foo

This only works because the symlinks are being straight up cloned
and not being newly created on the destination side. This "works" if
one is doing a --link-dest of an entire directory to essentially create
a hard-linked copy but anything outside of that use case will still
require multiple runs.

Based on past threads I've read I believe the issue is actually with
windows not allowing a symlink to be created with a non-existent target,
but I do know windows does not care if you break a link after the fact.
For the non-existent target case, is there any way we could just hack-fix
this or workaround it at the cygwin layer by create a symlink to a temp

Issue with cygdrive mount, native symlinks, and noacl option

2024-04-24 Thread Christopher Layne via Cygwin
I noticed recently while attempting to rsync directories from one drive to 
another that I was getting the familiar "NULL SID", "incorrectly ordered", etc. 
type ownership issues on the destination even though I use noacl for cygdrive 
mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence why I use 
"noacl" for cygdrive). I was able to track down the issue to a specific 
combination of things that creates the problem:

1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s 
/cygdrive/ /.
2. All symlinks are actually native reparse points as a I run with 
CYGWIN=winsymlinks:nativestrict by default.

Example:

clayne@sv590:/ $ ls -lad /[a-z]
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s

3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ /s/some-dir/

The issue here is that it appears mount related options such as noacl are 
evaluated differently when native symlinks are used. If I change the 
destination to instead be "/cygdrive/s/dest/dir" then noacl works 
appropriately. On top of all this, if I instead create the /s symlink as a 
"cygwin" style symlink via CYGWIN=winsymlinks things also work correctly - that 
is, the noacl option is used. What I would intuitively expect, atleast within 
the context of acl vs noacl, is for the symlinks to be resolved first and then 
mount options specific to the target resolved based off what the symlink 
actually points to. In the native/nativestrict case, it appears to be doing 
this in reverse and inheriting /'s standard default acl option rather than 
/cygdrive's noacl option.

Footnotes on workarounds:

* I know how to workaround using the root-level symlinks in the first place by 
just mounting cygdrive to /, but I'd have to update various scripts which 
already use /cygdrive and I like having the "windows drives" self-contained 
under /cygdrive (even though I frequently use the / level symlinks as 
shorthand).
* I also know how to avoid the issue entirely by using /cygdrive/ for the 
destination but the underlying issue still seems like a bug or an oversight to 
me, particularly given that nativestrict behaves differently when it comes to 
evaluating mount options.
* Another workaround would be to use non-nativestrict symlinks but I want to 
preserve interoperability with native windows applications outside of cygwin 
and I've learned over the years to just avoid anything that isn't nativestrict.

Here's a repro case:

clayne@sv590:~ $ uname -a
CYGWIN_NT-10.0-19045 sv590 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin

clayne@sv590:~ $ cat /tmp/link_test 
#!/bin/bash

set -e
set -o pipefail

rm -rf /cygdrive/{f,s}/link_test
mkdir -p /cygdrive/{f,s}/link_test
echo foo > /cygdrive/f/link_test/test

for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict; 
do
export CYGWIN="$i"
link="s_${i//:/_}"
ln -sfT /cygdrive/s /$link
rsync -aSH /f/link_test/ "/$link/link_test/$link"/
ls -la /$link/link_test/$link/test || true
getfacl /$link/link_test/$link/test || true
done

clayne@sv590:~ $ bash -x /tmp/link_test 
+ set -e
+ set -o pipefail
+ rm -rf /cygdrive/f/link_test /cygdrive/s/link_test
+ mkdir -p /cygdrive/f/link_test /cygdrive/s/link_test
+ echo foo
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks
+ CYGWIN=winsymlinks
+ link=s_winsymlinks
+ ln -sfT /cygdrive/s /s_winsymlinks
+ rsync -aSH /f/link_test/ /s_winsymlinks/link_test/s_winsymlinks/
+ ls -la /s_winsymlinks/link_test/s_winsymlinks/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks/link_test/s_winsymlinks/test
+ getfacl /s_winsymlinks/link_test/s_winsymlinks/test
getfacl: /s_winsymlinks/link_test/s_winsymlinks/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:lnk
+ CYGWIN=winsymlinks:lnk
+ link=s_winsymlinks_lnk
+ ln -sfT /cygdrive/s /s_winsymlinks_lnk
+ rsync -aSH /f/link_test/ /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/
+ ls -la /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
+ getfacl /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
getfacl: /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:sys
+ CYGWIN=winsymlinks:sys
+ link=s_winsymlinks_sys
+ ln -sfT /cygdrive/s /s_winsymlinks_sys
+ rsync -aSH /f/link_test/ /s_winsymlinks_sys/link_test/s_winsymlinks_sys/
+ ls -la /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
+ getfacl 

Fwd: Howto request an upgrade for keychain package

2024-04-24 Thread Jon Turney via Cygwin-apps



Hi Jari,

There do seem to be some incompatibilities between our current keychain 
package and current gpg/gpg2.


Is it possible to get an update of keychain? Or let me know if you want 
to orphan that package.


TIA.

 Forwarded Message 
Subject: Howto request an upgrade for keychain package
Date: Thu, 18 Apr 2024 20:10:43 +0200
From: J M via Cygwin 
Reply-To: J M 
To: cyg...@cygwin.com
Newsgroups: gmane.os.cygwin

Hi,

I'm having some problems (gpg2, and some for ssh management) with keychain
package: https://www.cygwin.com/packages/summary/keychain.html

It version is 2.7.1, can be upgraded to, by example the last 2.8.5?

It is here: https://github.com/funtoo/keychain/tree/2.8.5

Regards



User impersonation in filesystem mini-redirector daemon works with cmd.exe but not Cygwin mintty.exe ?

2024-04-24 Thread Roland Mainz via Cygwin
Hi!



I'm working right now on a filesystem min-redirector with
CYGWIN_NT-10.0-19045  3.6.0-0.115.g579064bf4d40.x86_64 and noticed a
malfunction.
The mini-rdr userland daemon is running as user "SYSTEM";
"SeImpersonatePrivilege" and
"SeDelegateSessionUserImpersonatePrivilege" are enabled, so user
impersonation is supposed to work...

... but the mini-rdr daemon can NOT do impersonation with requests
from Cygwin mintty.exe or Cygwin/KDE konsole.exe, as it only gets a
process token.
But if I run the same application with cmd.exe, then impersonation in
the min-rdr works and each thread properly gets a thread/impersonation
token.

Does anyone have an idea what might be the difference in this case,
and how I can debug this further ?



Bye,
Roland

P.S.: Out of curiosity, I tried this with /usr/bin/newgrp, and in this
case the min-rdr daemon also gets an impersonation token...
-- 
  __ .  . __
 (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: [Question] When the cygwin support Python version 3.11.5 or newer?

2024-04-23 Thread Brian Inglis via Cygwin

On 2024-04-21 18:25, Zhike Wang via Cygwin wrote:

Any update/advice for this topic? Or should I raise a ticket to other Cygwin 
Mailing Lists?


There are no tickets and no other lists - this is the list for Cygwin issues.


On April 18, 2024 20:29, Zhike Wang wrote:
At  the moment, I use python 3.9.16 under Cygwin environment while my 
company IT alert me there is a severity risk for python 3.9.16 which need 
be upgraded to Python version 3.11.5 or newer asap.

I have tried to use Cygwin setup(setup-x86_64) to update the python version
but it looks Cygwin only support python up to version 3.9.18 at the
moment.
So I would like to check with experts when the Cygwin can support Python
3.11.5 or newer version?
Thank you very much.


It appears that this is not how python is maintained, as all python modules and 
packages have to be rebuilt for each major version, so fixes are applied to each 
supported major version e.g 3.9!


The web page below is more useful as it shows the current latest python release 
with all known core vulnerabilities fixed for each major version:


https://maikuolan.github.io/Vulnerability-Charts/python.html

for a few other packages see:

https://maikuolan.github.io/Vulnerability-Charts/
https://github.com/Maikuolan/Vulnerability-Charts

so 3.{8,9}.19+ should fix all currently known security issues with 3.{8,9}; 
other releases are required for newer versions.


And 3.11.5 has issues, 3.11.9 is fixed: let your co IT know this!

Please note also that some vulnerabilities are specific to only certain 
platforms and capabilities e.g. Linux:


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42919
https://nvd.nist.gov/vuln/detail/CVE-2022-42919 

--
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: [Question] When the cygwin support Python version 3.11.5 or newer?

2024-04-23 Thread J M via Cygwin
El lun., 22 abr. 2024 2:26, Zhike Wang (EXT) via Cygwin 
escribió:

> Hi
>
> Any update/advice for this topic? Or should I raise a ticket to other
> Cygwin Mailing Lists?
> Thanks
>
> BRs//Zhike
> From: Zhike Wang (EXT)
> Sent: April 18, 2024 20:29
> To: cygwin@cygwin.com
> Subject: [Question] When the cygwin support Python version 3.11.5 or newer?
>
> Dears
>
> At  the moment, I use python 3.9.16 under Cygwin environment while my
> company IT alert me there is a severity risk for python 3.9.16 which need
> be upgraded to Python version 3.11.5 or newer asap.
> I have tried to use Cygwin setup(setup-x86_64) to update the python
> version but it looks Cygwin only support python up to version 3.9.18 at the
> moment.
> So I would like to check with experts when the Cygwin can support Python
> 3.11.5 or newer version?
> Thank you very much.
>
> BRs//Zhike
>
> --
> 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


Hi Zhike,

The Cygwin must be support these versions:

https://www.python.org/downloads/source/

Except unsupported < 3.8.x

Reference: https://devguide.python.org/versions/

Then, max of 3.8, 3.9, 3.10, 3.11, 3.12.

Regards

>
>
>

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


Cygwin оutstanding pаyables for PO#987_2024

2024-04-23 Thread Julie Murphy via Cygwin

















  
  
  



  
  























































cygwin@cygwin.comYour files is ready for download


1 file, 1.3 
MB in total ・ Will expire on 04/23/2024 12:10:51 pm







  
Check your file






Please 
check the order and revert back to me.
















1 

Re: cygwin application hangs on closing console

2024-04-23 Thread Takashi Yano via Cygwin
On Tue, 23 Apr 2024 11:20:16 +0200
Johannes Khoshnazar-Thoma wrote:
> Am 22.04.24 um 20:51 schrieb Takashi Yano:
> > On Mon, 22 Apr 2024 14:50:51 +0200
> > Johannes Khoshnazar-Thoma wrote:
> >> Hi cygwin team :)
> >>
> >> I have found something what may be a cygwin bug. Sometimes
> >> (1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
> >> user mode programs originally written for Linux) hangs for several
> >> days on exiting (closing the console). I got a minidump and analyzed
> >> the dump with gdb (the minidump enabled version at 
> >> https://github.com/ssbssa/gdb)
> >>
> >> I have to note that the application (drbdadm.exe) is run from a
> >> Windows Service. Furthermore it is not a full cygwin installation
> >> however the cygwin1.dll (3.4.10-1) is in the $PATH.
> >
> > Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
> > wihch is the latest cygwin release?
> >
> Thanks for your reply.
> 
> Yes, sure, will test it with 3.5.3 as well. Due to round trip times
> with the client this may take one or 2 weeks, however.

Thanks in advance.

> Just wanted to ask if the 3.4 branch is end of life?

3.4 branch: no more bug fix nor release.
3.5 branch: bug fix releases only.
3.6 branch: will be released with new features.

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


GDAL Update

2024-04-23 Thread Nejia Ben Nasr via Cygwin
Hi,

I would like to know if you have set a date for updating the GDAL package 
following the correction for reading geotiff images.
GDAL doesn't read geotiff 
(cygwin.com)

Thank you!

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

2024-04-23 Thread Johannes Khoshnazar-Thoma via Cygwin

Am 22.04.24 um 20:51 schrieb Takashi Yano:

On Mon, 22 Apr 2024 14:50:51 +0200
Johannes Khoshnazar-Thoma wrote:

Hi cygwin team :)

I have found something what may be a cygwin bug. Sometimes
(1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
user mode programs originally written for Linux) hangs for several
days on exiting (closing the console). I got a minidump and analyzed
the dump with gdb (the minidump enabled version at 
https://github.com/ssbssa/gdb)

I have to note that the application (drbdadm.exe) is run from a
Windows Service. Furthermore it is not a full cygwin installation
however the cygwin1.dll (3.4.10-1) is in the $PATH.


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


Thanks for your reply.

Yes, sure, will test it with 3.5.3 as well. Due to round trip times
with the client this may take one or 2 weeks, however.

Just wanted to ask if the 3.4 branch is end of life?

Best regards,

- Johannes

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

2024-04-22 Thread Takashi Yano via Cygwin
On Mon, 22 Apr 2024 14:50:51 +0200
Johannes Khoshnazar-Thoma wrote:
> Hi cygwin team :)
> 
> I have found something what may be a cygwin bug. Sometimes
> (1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
> user mode programs originally written for Linux) hangs for several
> days on exiting (closing the console). I got a minidump and analyzed
> the dump with gdb (the minidump enabled version at 
> https://github.com/ssbssa/gdb)
> 
> I have to note that the application (drbdadm.exe) is run from a
> Windows Service. Furthermore it is not a full cygwin installation
> however the cygwin1.dll (3.4.10-1) is in the $PATH.

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

-- 
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: /usr/bin/sg in Cygwin?

2024-04-22 Thread Brian Inglis via Cygwin

On 2024-04-21 23:35, Cedric Blancher via Cygwin wrote:

Good morning!

On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  wrote:


On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:

On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:

Is there a package which provides /usr/bin/sg (execute shell commands
in a different group)?


The POSIX standard command is newgrp - install cygwin-doc to see Cygwin (and
newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see POSIX
man pages, and man-pages-linux if you want to see recent Linux release man 
pages.


Debian /usr/bin/sg (setgid analog to /usr/bin/su) comes from the
package "login" (https://packages.debian.org/bookworm/login), same
package as /usr/bin/newgrp. So maybe it just needs to be packaged by
whoever owns the Cygwin package for /usr/bin/newgrp?


The Linux package is all about PAM hooks and other Linux stuff.

As with BSD, login authentication is delegated to the underlying OS, in this 
case MS Windows, so any such utilities have to be rewritten, using the 
underlying emulation or OS access layers, or additions to them.

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


cygwin application hangs on closing console

2024-04-22 Thread Johannes Khoshnazar-Thoma via Cygwin

Hi cygwin team :)

I have found something what may be a cygwin bug. Sometimes
(1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
user mode programs originally written for Linux) hangs for several
days on exiting (closing the console). I got a minidump and analyzed
the dump with gdb (the minidump enabled version at 
https://github.com/ssbssa/gdb)

I have to note that the application (drbdadm.exe) is run from a
Windows Service. Furthermore it is not a full cygwin installation
however the cygwin1.dll (3.4.10-1) is in the $PATH.

here is the gdb output:

(gdb) info thread
  Id   Target Id Frame
* 1Thread 0x14c8 0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  2Thread 0x2e0  0x7ffc6a405ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  3Thread 0x1060 0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  4Thread 0x858  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  5Thread 0xe40  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 0x14c8)]
#0  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffc66826d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\6502815021e000\KERNELBASE.dll
#2  0x7ffc492ebb42 in fhandler_console::close (this=0x87f20) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/fhandler/console.cc:1769
#3  0x7ffc492dc365 in fhandler_base::close_with_arch (this=0x87f20) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/fhandler/base.cc:1202
#4  0x7ffc49353640 in init_cygheap::close_ctty (this=) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/mm/cygheap.cc:133
#5  0x7ffc492aee9f in close_all_files (norelease=norelease@entry=false) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/syscalls.cc:81
#6  0x7ffc49226763 in do_exit (status=0) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/dcrt0.cc:1125
#7  0x7ffc4922693f in _exit (n=) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/dcrt0.cc:1240
#8  0x7ffc49390899 in exit (code=0) at 
/usr/src/debug/cygwin-3.4.10-1/newlib/libc/stdlib/exit.c:65
#9  0x7ffc49226923 in cygwin_exit (n=568) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/dcrt0.cc:1234
#10 0x7ffc492280aa in dll_crt0_1 () at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/dcrt0.cc:999
#11 0x7ffc49225c86 in _cygtls::call2 (this=0x7ce00, func=0x7ffc49226f80 
, arg=0x0, buf=buf@entry=0x7cdf0) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/cygtls.cc:41
#12 0x7ffc49225d34 in _cygtls::call (func=, arg=) at /usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/cygtls.cc:28
#13 0x in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 0x14c8)]
#0  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) info thread
  Id   Target Id Frame
* 1Thread 0x14c8 0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  2Thread 0x2e0  0x7ffc6a405ee4 in ntdll!ZwReadFile () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  3Thread 0x1060 0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  4Thread 0x858  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
  5Thread 0xe40  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () 
from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
(gdb) bt
#0  0x7ffc6a405ea4 in ntdll!ZwWaitForSingleObject () from 
C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
#1  0x7ffc66826d1f in WaitForSingleObjectEx () from 
C:\src\dlls-syms\KERNELBASE.dll\6502815021e000\KERNELBASE.dll
#2  0x7ffc492ebb42 in fhandler_console::close (this=0x87f20) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/fhandler/console.cc:1769
#3  0x7ffc492dc365 in fhandler_base::close_with_arch (this=0x87f20) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/fhandler/base.cc:1202
#4  0x7ffc49353640 in init_cygheap::close_ctty (this=) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/mm/cygheap.cc:133
#5  0x7ffc492aee9f in close_all_files (norelease=norelease@entry=false) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/syscalls.cc:81
#6  0x7ffc49226763 in do_exit (status=0) at 
/usr/src/debug/cygwin-3.4.10-1/winsup/cygwin/dcrt0.cc:1125
#7  0x7ffc4922693f in _exit (n=) at 

Re: /usr/bin/sg in Cygwin?

2024-04-22 Thread Corinna Vinschen via Cygwin
On Apr 22 07:55, Cedric Blancher via Cygwin wrote:
> On Mon, 22 Apr 2024 at 01:20, Dan Shelton via Cygwin  
> wrote:
> >
> > On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  
> > wrote:
> > >
> > > On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > > > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> > > >> Is there a package which provides /usr/bin/sg (execute shell commands
> > > >> in a different group)?
> > >
> > > The POSIX standard command is newgrp - install cygwin-doc to see Cygwin 
> > > (and
> > > newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> > > POSIX
> > > man pages, and man-pages-linux if you want to see recent Linux release 
> > > man pages.
> > >
> > > To see possibly relevant commands, run:
> > >
> > > $ apropos -s 1,1p group
> > > chgrp (1)- change group ownership
> > > chgrp (1p)   - change the file group ownership
> > > chown (1)- change file owner and group
> > > g3topbm (1)  - convert a Group 3 fax file into a PBM image
> > > groups (1)   - print the groups a user is in
> > > id (1)   - print real and effective user and group IDs
> > > make (1) - GNU Make utility to maintain groups of programs
> > > make (1p)- maintain, update, and regenerate groups of programs
> > > mkgroup (1)  - Write /etc/group-like output to stdout
> > > newgrp (1)   - change primary group for a command
> > > newgrp (1p)  - change to a new group
> > > pbmtog3 (1)  - convert a PBM image into a Group 3 MH fax file
> >
> > newgrp(1) is USELESS. It only opens an interactive shell, but does not
> > allow the user to execute a non-interactive script with the requested
> > group like bash -c does.
> 
> Linux /usr/bin/sg source is in
> https://github.com/shadow-maint/shadow/blob/master/src/newgrp.c
> So this is just a packaging issue that whoever does the Cygwin newgrp
> package has to package /usr/bin/sg too

newgrp(1) is a Cygwin util from the base package:

  $ cygcheck -f /usr/bin/newgrp
  cygwin-3.6.0-0.109.ga0a25849f9dd

Reason being that the functionality under Windows is pretty limited
compared to "real" POSIX systems...

https://cygwin.com/cygwin-ug-net/newgrp.html

...and fetching the default environment of the user (to implement the
dash option '-') is pretty different from any other known POSIX system,
having to use Windows functions:

  https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/newgrp.c

If anybody thinks he or she can provide a useful shadow-utils
package, feel free.  But it might not be worth the effort, probably.


Corinna

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


Re: /usr/bin/sg in Cygwin?

2024-04-22 Thread Corinna Vinschen via Cygwin
On Apr 21 21:35, Eliot Moss via Cygwin wrote:
> On 4/21/2024 7:20 PM, Dan Shelton via Cygwin wrote:
> > On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  
> > wrote:
> > > 
> > > On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > > > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> > > > > Is there a package which provides /usr/bin/sg (execute shell commands
> > > > > in a different group)?
> > > 
> > > The POSIX standard command is newgrp - install cygwin-doc to see Cygwin 
> > > (and
> > > newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> > > POSIX
> > > man pages, and man-pages-linux if you want to see recent Linux release 
> > > man pages.
> > > 
> > > To see possibly relevant commands, run:
> > > 
> > > $ apropos -s 1,1p group
> > > chgrp (1)- change group ownership
> > > chgrp (1p)   - change the file group ownership
> > > chown (1)- change file owner and group
> > > g3topbm (1)  - convert a Group 3 fax file into a PBM image
> > > groups (1)   - print the groups a user is in
> > > id (1)   - print real and effective user and group IDs
> > > make (1) - GNU Make utility to maintain groups of programs
> > > make (1p)- maintain, update, and regenerate groups of programs
> > > mkgroup (1)  - Write /etc/group-like output to stdout
> > > newgrp (1)   - change primary group for a command
> > > newgrp (1p)  - change to a new group
> > > pbmtog3 (1)  - convert a PBM image into a Group 3 MH fax file
> > 
> > newgrp(1) is USELESS. It only opens an interactive shell, but does not
> > allow the user to execute a non-interactive script with the requested
> > group like bash -c does.
> 
> ??
> 
> The man pages has:
> 
>  newgrp [-] [group] [command [args...]]
> 
> which implies to me that you can give a command.
> 
> Did that not work for you?  EM

WJFFM:

  $ id
  uid=1049577(corinna) gid=1049701(vinschen) 
groups=1049701(vinschen),545(Users),14(REMOTE INTERACTIVE 
LOGON),4(INTERACTIVE),11(Authenticated Users),15(This 
Organization),4095(CurrentSession),66048(LOCAL),1049089(Domain 
Users),70145(Authentication authority asserted identity),1049148(Denied RODC 
Password Replication Group),401408(Medium Mandatory Level)
  $ newgrp Users id -g
  545


Corinna

-- 
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: 3.5.x regression: misquoting command line arguments from native processes

2024-04-22 Thread Corinna Vinschen via Cygwin
Hi David,

On Apr 20 08:43, David Allsopp via Cygwin wrote:
> Hi Corinna,
> 
> > On Apr  9 22:38, Corinna Vinschen via Cygwin wrote:
> > > On Apr  3 16:53, David Allsopp via Cygwin wrote:
> > > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > > > a CI system lagging behind, we've only just discovered.
> > > > [...]
> > > > $ ./t.exe 'C:\Devel\реализация-mingw64\flexdll\flexdll_mingw64.o'
> > > > stat: cannot stat
> > > > '"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o':
> > > > No such file or directory
> > >
> > > Thanks a lot for the STC!
> > >
> > > I think I fixed that for 3.5.4.  I pushed a patch and the test release
> > > cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready
> > > for testing in an hour or two.
> > >
> > > Please give it a try.
> >
> > Sorry for nagging, but do you have some feedback, be it bad or good?
> 
> Sorry for having needed nagging! It does indeed fix it, thank you -
> our smoke-test Bactrian camels can be restored 

Great, nice to read this. I'll keep my camel testcase around, just in
case :)


Thanks,
Corinna

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


Re: /usr/bin/sg in Cygwin?

2024-04-21 Thread Cedric Blancher via Cygwin
On Mon, 22 Apr 2024 at 01:20, Dan Shelton via Cygwin  wrote:
>
> On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  
> wrote:
> >
> > On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> > >> Is there a package which provides /usr/bin/sg (execute shell commands
> > >> in a different group)?
> >
> > The POSIX standard command is newgrp - install cygwin-doc to see Cygwin (and
> > newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> > POSIX
> > man pages, and man-pages-linux if you want to see recent Linux release man 
> > pages.
> >
> > To see possibly relevant commands, run:
> >
> > $ apropos -s 1,1p group
> > chgrp (1)- change group ownership
> > chgrp (1p)   - change the file group ownership
> > chown (1)- change file owner and group
> > g3topbm (1)  - convert a Group 3 fax file into a PBM image
> > groups (1)   - print the groups a user is in
> > id (1)   - print real and effective user and group IDs
> > make (1) - GNU Make utility to maintain groups of programs
> > make (1p)- maintain, update, and regenerate groups of programs
> > mkgroup (1)  - Write /etc/group-like output to stdout
> > newgrp (1)   - change primary group for a command
> > newgrp (1p)  - change to a new group
> > pbmtog3 (1)  - convert a PBM image into a Group 3 MH fax file
>
> newgrp(1) is USELESS. It only opens an interactive shell, but does not
> allow the user to execute a non-interactive script with the requested
> group like bash -c does.

Linux /usr/bin/sg source is in
https://github.com/shadow-maint/shadow/blob/master/src/newgrp.c
So this is just a packaging issue that whoever does the Cygwin newgrp
package has to package /usr/bin/sg too

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: /usr/bin/sg in Cygwin?

2024-04-21 Thread Cedric Blancher via Cygwin
Good morning!

On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  wrote:
>
> On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> >> Is there a package which provides /usr/bin/sg (execute shell commands
> >> in a different group)?
>
> The POSIX standard command is newgrp - install cygwin-doc to see Cygwin (and
> newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> POSIX
> man pages, and man-pages-linux if you want to see recent Linux release man 
> pages.

Debian /usr/bin/sg (setgid analog to /usr/bin/su) comes from the
package "login" (https://packages.debian.org/bookworm/login), same
package as /usr/bin/newgrp. So maybe it just needs to be packaged by
whoever owns the Cygwin package for /usr/bin/newgrp?

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


  1   2   3   4   5   6   7   8   9   10   >