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

[Adam Dinwoodie via Cygwin-apps]

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

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

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

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

I really don't like passing strings around to be eval'd, particularly
when they're expected to contain non-trivial code.  Given 

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

[Adam Dinwoodie via Cygwin-apps]

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

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

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

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

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

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

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

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

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

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

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

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

echo
inform "Launching '$cmd $msg'"

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

Re: NetPbm

[Adam Dinwoodie via Cygwin]

On Tue, 16 Apr 2024 at 20:53, Ourson 35 via Cygwin wrote:
>
> Hi,
> I need to use NetPbm 11.6 (2024) for Windows, or at least 10.99 (2022).
>
> But your last version is 10.80 (2017) ... :-(
> Please, is it possible to update ?
> Thanks

Unfortunately this package is unmaintained, per
https://cygwin.com/packages/reports/unmaintained.html. If you'd be
interested in taking over maintainership and getting it up to date,
that would be incredibly welcome! There is advice on maintaining a
package at https://cygwin.com/packages.html, and we're very happy to
help new maintainers pick up a package – we know we need more of them
– but without a new volunteer it's unlikely to get updated for the
foreseeable future.

Adam

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

Re: Cygwin a bit slow

[Adam Dinwoodie via Cygwin]

On Fri, 5 Apr 2024 at 16:19, J M via Cygwin wrote:
>
> Hi,
>
> I'm seeing that Cygwin is a bit slow, directly and after comparing to
> simple ubuntu virtual machines by example.
>
> Specifically:
>
> - Copy and paste texts in vim, I see clearly the slow in paste.
> - Using sed and/or grep that count approx. between 6x and 8x respect to
> virtual machine simple ubuntu.
> - In general multiple bash commands are slower.
>
> Can you analyze this?
>
> I'm use the last updated Windows 11 and a fresh Cygwin.

This is expected. Cygwin runs as a compatibility layer between Windows
and the POSIX applications, and that compatibility layer has
significant performance overheads. Running in a virtual machine –
including WSL – has far fewer of those overheads, at the expense of
requiring a complete separate operating system, all the virtualisation
infrastructure, and poorer access to the Windows OS.

There is clearly a trade-off here, and for a lot of folk who would
have used Cygwin in the past, WSL is going to be a better choice:
those disadvantages are much less relevant than they were five or ten
years ago. Obviously, if you have ideas for how to improve Cygwin
performance, the project is always looking for volunteers; there's
more information at https://cygwin.com/contrib.html.

HTH

Adam

-- 
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: bash builtin printf date format problem

[Adam Dinwoodie via Cygwin]

On Mon, 1 Apr 2024 at 16:29, Chris Elvidge via Cygwin wrote:
>
> Using bash builtin printf '%(fmt)T', when fmt contains %-d (or %_d),
> there is no output - should print daynumber with no preceding 0 (or with
> preceding space). Similarly %-e. date +"%B %-d" works OK.
>
> $ uname -a
> CYGWIN_NT-10.0-19045 ASUS-X550C-WIN 3.5.1-1.x86_64 2024-02-27 11:54 UTC
> x86_64 Cygwin
> $ bash --version
> GNU bash, version 5.2.21(1)-release (x86_64-pc-cygwin)
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:14 pm BST:/home/celvi
> $ printf '%(%B %d)T\n'
> April 01
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:15 pm BST:/home/celvi
> $ printf '%(%B %-d)T\n'
>
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:15 pm BST:/home/celvi
> $ printf '%(%B %_d)T\n'
>
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:19 pm BST:/home/celvi
> $ printf '%(%B %e)T\n'
> April  1
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:19 pm BST:/home/celvi
> $ printf '%(%B %-e)T\n'
>
> [0] ASUS-X550C-WIN!celvi:(pty0):Mon 01 Apr 2024 04:19 pm BST:/home/celvi
>
> Works properly on Slackware current and LMDE6. Anyone any ideas?

`%-d` isn't a portable construct, and it's not supported by Cygwin.
Specifically, Bash uses the system strftime function for this
formatting, and while lots of systems use glibc, which provides an
strftime that supports `%-d`, Cygwin uses newlib, which doesn't.

As ever, patches to the code will be gratefully received and
thoughtfully considered; the code for Cygwin's strftime lives at
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/time/strftime.c

HTH!


Adam

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

jq bug report: jq errors trigger assertion errors rather than being handled

[Adam Dinwoodie via Cygwin]

Hi,

I'm seeing consistent behaviour when running `jq` on Cygwin, where
commands that should trigger jq to produce an error message instead
cause it to assert and die.

Simple test case: run `jq -n 'error("oh no!")'`, which should raise a jq
error with the text "oh no!".

Output on Cygwin:

$ jq -n 'error("oh no!")'
assertion "cb == jq_util_input_next_input_cb" failed: file 
"/cygdrive/d/a/scallywag/jq/jq-1.7.1-1.x86_64/src/jq-1.7.1/src/util.c", line 
360, function: jq_util_input_get_position
 Aborted

Expected output, as seen on my handy Debian box:

$ jq -n 'error("oh no!")'
jq: error (at ): oh no!

I've attached the cygcheck.out file from the system where I ran the
above.

Cheers,

Adam

Cygwin Configuration Diagnostics
Current System Time: Tue Mar 26 17:16:49 2024

Windows 11 Enterprise Ver 10.0 Build 22621 

Running in Terminal Service session

Path:   C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Users\WDAGUtilityAccount\AppData\Local\Microsoft\WindowsApps

Output from C:\cygwin64\bin\id.exe
UID: 197112(WDAGUtilityAccount)
GID: 197121(None)
197121(None)
114(Local account and member of Administrators group)
555(Remote Desktop Users)
545(Users)
544(Administrators)
14(REMOTE INTERACTIVE LOGON)
4(INTERACTIVE)
11(Authenticated Users)
15(This Organization)
113(Local account)
4095(CurrentSession)
66048(LOCAL)
262154(NTLM Authentication)
405504(High Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

PWD = '/home/WDAGUtilityAccount'
HOME = '/home/WDAGUtilityAccount'
USER = 'WDAGUtilityAccount'

ProgramFiles(x86) = 'C:\Program Files (x86)'
!:: = '::\'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
SHELL = '/bin/bash'
NUMBER_OF_PROCESSORS = '20'
PROCESSOR_LEVEL = '6'
TERM_PROGRAM_VERSION = '3.7.1'
USERDOMAIN_ROAMINGPROFILE = '53A298FF-19DC-4'
HOSTNAME = '53a298ff-19dc-4841-bc68-9223d670a672'
PROGRAMFILES = 'C:\Program Files'
EFC_4284 = '0'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
OS = 'Windows_NT'
HOMEDRIVE = 'C:'
USERDOMAIN = '53A298FF-19DC-4'
USERPROFILE = 'C:\Users\WDAGUtilityAccount'
TZ = 'Europe/London'
ALLUSERSPROFILE = 'C:\ProgramData'
ORIGINAL_PATH = 
'/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Users/WDAGUtilityAccount/AppData/Local/Microsoft/WindowsApps'
CommonProgramW6432 = 'C:\Program Files\Common Files'
USERNAME = 'WDAGUtilityAccount'
COMSPEC = 'C:\Windows\system32\cmd.exe'
APPDATA = 'C:\Users\WDAGUtilityAccount\AppData\Roaming'
SYSTEMROOT = 'C:\Windows'
LOCALAPPDATA = 'C:\Users\WDAGUtilityAccount\AppData\Local'
COMPUTERNAME = '53A298FF-19DC-4'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
TERM = 'xterm'
LOGONSERVER = '\\53A298FF-19DC-4'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules'
TEMP = '/tmp'
SHLVL = '1'
PROCESSOR_REVISION = '9a03'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LC_CTYPE = 'en_US.UTF-8'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 154 Stepping 3, GenuineIntel'
SESSIONNAME = '31C5CE94259D4006A9E4#0'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
HOMEPATH = '\Users\WDAGUtilityAccount'
TMP = '/tmp'
ProgramW6432 = 'C:\Program Files'
PROFILEREAD = 'true'
MINTTY_SHORTCUT = '/cygdrive/c/Users/Public/Desktop/Cygwin64 Terminal.lnk'
WINDIR = 'C:\Windows'
PROCESSOR_ARCHITECTURE = 'AMD64'
PUBLIC = 'C:\Users\Public'
CLIENTNAME = 'f33ef77f-51f2-4'
SYSTEMDRIVE = 'C:'
EXECIGNORE = '*.dll'
OLDPWD = '/etc/skel'
TERM_PROGRAM = 'mintty'
ProgramData = 'C:\ProgramData'
_ = '/usr/bin/cygcheck'

HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:\cygwin64'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin64'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: e022582115c10879 Path: C:\cygwin64

c:  hd  NTFS 40830Mb   7% CP CS UN PA FC

C:\cygwin64  /  system  binary,auto
C:\cygwin64\bin  /usr/bin   system  binary,auto
C:\cygwin64\lib  /usr/lib   system  binary,auto
cygdrive prefix  /cygdrive  userbinary,posix=0,auto

Found: C:\cygwin64\bin\awk
 -> C:\cygwin64\bin\gawk.exe
Found: C:\cygwin64\bin\bash.exe
Found: C:\cygwin64\bin\cat.exe
Found: C:\Windows\system32\certutil.exe
Not Found: clinfo
Found: C:\Windows\system32\comp.exe
Found: C:\Windows\system32\convert.exe
Found: C:\cygwin64\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\Windows\system32\curl.exe
Found: C:\cygwin64\bin\expand.exe
Found: C:\Windows\system32\expand.exe
Warning: C:\cygwin64\bin\expand.exe hides C:\Windows\system32\expand.exe
Found: C:\cygwin64\bin\find.exe
Found: C:\Windows\system32\find.exe

Re: How to map a NAS drive in /etc/fstab that is of type

[Adam Dinwoodie via Cygwin]

On Mon, 8 Jan 2024 at 07:46, /dev /local/ca via Cygwin
 wrote:
>
> What would an entry in */etc/fstab* look like on Windows to map a nas
> mapped drive N:
>
> When provisioning the drives, I selected file system type: btrfs
>
> ---
> I am on Windows 10 Pro and want to access the drive with the path:  /n
>
> NAS: Synology 4 hard drives Raid 6
>
> It is mapped to my Windows machine as drive N: and when launching cygwin,
> it would be ideal if it is auto-mounted

If it's mapped as N: in your Windows machine, it will normally be
available as /cygdrive/n/

Cygwin doesn't have any support of btrfs itself, but neither does
Windows; if your NAS is providing a file share that Windows can access
then – subject to file permissions issues and the like – Cygwin should
be able to access anything you can access through the Windows file
system.

See also:

https://cygwin.com/faq/faq.html#faq.using.accessing-drives
https://cygwin.com/cygwin-ug-net/mount.html
https://cygwin.com/cygwin-ug-net/using.html#mount-table

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

Updated: Git v2.43.0-1

[Adam Dinwoodie via Cygwin-announce]

Version 2.43.0-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam
-- 
  *** 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: Cannot set up cron as a service on corporate PC

[Adam Dinwoodie via Cygwin]

On Mon, Dec 11, 2023 at 02:07:08PM +, Jon Turney wrote:
> On 09/12/2023 21:55, Adam Dinwoodie via Cygwin wrote:
> > Hi,
> > 
> > I've been trying to set up Cygwin cron to work as a service on my work
> > PC.  I'm able to get it working just fine on a Windows system where I'm
> > using a personal Microsoft account, but when I attempt the same process
> > using on a Windows system using my work account, I get the following
> > error:
> > 
> >  cygrunsrv: Error starting a service: StartService:  Win32 error 1068:
> >  The dependency service or group failed to start.
> > 
> > I also note that in the failing scenario, I see the following log appear
> > at this time in Windows Event Viewer:
> > 
> > > This computer is configured as a member of a workgroup, not as a
> > > member of a domain. The Netlogon service does not need to run in this
> > > configuration.
> > 
> > I've reproduced this behaviour in virtual machines using fresh
> > installations of Windows, and where the only actions taken were to
> > bootstrap, log in, install Cygwin including cygrunsrv and cron, then
> > attempt to set up cron as a service.  I've attached copies of the MinTTY
> > output and the cronbug.txt files (which appear to include the normal
> > cygcheck -srv output, so I've not added those separately.  I've also
> > attached the full Event Viewer log
> > 
> > My guess is that something about how Windows manages user accounts has
> > changed over the years, and cygrunsrv hasn't been updated to cope, but
> > that's a very wild guess.  Searching the archives hasn't got me very
> 
> You might test this hypothesis by attempting to run 'true', or perhaps it
> needs to be something that runs forever like 'sleep infinity' and see if you
> get the same error about netlogon?
> 
> (Or are you able to run other cygwin services without problems?)

Good question!  Looks like this is common to all services installed with
cygrunsrv and a specific user:

# cygrunsrv -I sleeptest -p /usr/bin/sleep -a infinity -u EUROPE+adinwoodie
Enter password of user `EUROPE\adinwoodie':
Re-enter, please:

# cygrunsrv -Q sleeptest
Service : sleeptest
Current State   : Stopped
Command : /usr/bin/sleep infinity

# cygrunsrv -S sleeptest
cygrunsrv: Error starting a service: StartService:  Win32 error 1068:
The dependency service or group failed to start.

So I think that strongly points towards either (a) an issue with
cygrunsrv, or (b) using usernames like this is just doomed to failure
and cron-config might benefit from suggesting better options or at least
warning there aren't any.

-- 
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: Cannot set up cron as a service on corporate PC

[Adam Dinwoodie via Cygwin]

On Sun, Dec 10, 2023 at 09:22:12AM -0700, Brian Inglis via Cygwin wrote:
> On 2023-12-09 14:55, Adam Dinwoodie via Cygwin wrote:
> > I've been trying to set up Cygwin cron to work as a service on my work
> > PC.  I'm able to get it working just fine on a Windows system where I'm
> > using a personal Microsoft account, but when I attempt the same process
> > using on a Windows system using my work account, I get the following
> > error:
> >  cygrunsrv: Error starting a service: StartService:  Win32 error 1068:
> >  The dependency service or group failed to start.
> > I also note that in the failing scenario, I see the following log appear
> > at this time in Windows Event Viewer:
> > > This computer is configured as a member of a workgroup, not as a
> > > member of a domain. The Netlogon service does not need to run in this
> > > configuration.
> > I've reproduced this behaviour in virtual machines using fresh
> > installations of Windows, and where the only actions taken were to
> > bootstrap, log in, install Cygwin including cygrunsrv and cron, then
> > attempt to set up cron as a service.  I've attached copies of the MinTTY
> > output and the cronbug.txt files (which appear to include the normal
> > cygcheck -srv output, so I've not added those separately.  I've also
> > attached the full Event Viewer log
> > My guess is that something about how Windows manages user accounts has
> > changed over the years, and cygrunsrv hasn't been updated to cope, but
> > that's a very wild guess.  Searching the archives hasn't got me very
> > far; mostly I've found references to cyglsa, which I get the impression
> > is thoroughly deprecated, and based on
> > https://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 I don't
> > think it's appropriate anyway due to the way the password is stored.
> > For now I'm continuing to use a snippet in my .bashrc to start cron when
> > I first start Bash, but that's not the nicest of workarounds.  Does
> > anyone have suggestions for anything better?
> 
> Never any issues here with cron, other than no mail, but I run mainly run
> scripts that log to /var/log/, and syslog rules that chmod a+r.
> I installed cyglsa many years ago, but don't think that's used any more, and
> I also used passwd -R, so that should still be around.
> I have also customized my daemon services so auto-start is delayed, notify
> on pre-shutdown, and depend on others: cron -> syslog-ng -> cygserver ->
> SamSS Security Accounts Manager, as I an not in a domain.
> 
> Given the error, I suggest checking the system config, as it either needs to
> be a domain member, with DC/AD access, or you need your work user created
> locally.

I'm honestly not sure what system config I'd need to check here.  Can
you give any more detailed instructions?

> Also check the deps with `sc qc cron` and follow the chain to see where
> netlogon gets involved.

That doesn't seem useful, sadly: as far as I can tell, cron has no
dependencies, so it's not clear to me why netlogon is getting involved
at all.

$ sc qc cron
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: cron
TYPE   : 10  WIN32_OWN_PROCESS
START_TYPE : 2   AUTO_START
ERROR_CONTROL  : 1   NORMAL
BINARY_PATH_NAME   : C:\cygwin64\bin\cygrunsrv.exe
LOAD_ORDER_GROUP   :
TAG: 0
DISPLAY_NAME   : Cron daemon
DEPENDENCIES   :
SERVICE_START_NAME : EUROPE\adinwoodie

I get the same results running that in Cygwin Bash and in PowerShell,
and with either started normally or running with Administrator
permissions.

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

Cannot set up cron as a service on corporate PC

[Adam Dinwoodie via Cygwin]

Hi,

I've been trying to set up Cygwin cron to work as a service on my work
PC.  I'm able to get it working just fine on a Windows system where I'm
using a personal Microsoft account, but when I attempt the same process
using on a Windows system using my work account, I get the following
error:

cygrunsrv: Error starting a service: StartService:  Win32 error 1068:
The dependency service or group failed to start.

I also note that in the failing scenario, I see the following log appear
at this time in Windows Event Viewer:

> This computer is configured as a member of a workgroup, not as a
> member of a domain. The Netlogon service does not need to run in this
> configuration.

I've reproduced this behaviour in virtual machines using fresh
installations of Windows, and where the only actions taken were to
bootstrap, log in, install Cygwin including cygrunsrv and cron, then
attempt to set up cron as a service.  I've attached copies of the MinTTY
output and the cronbug.txt files (which appear to include the normal
cygcheck -srv output, so I've not added those separately.  I've also
attached the full Event Viewer log

My guess is that something about how Windows manages user accounts has
changed over the years, and cygrunsrv hasn't been updated to cope, but
that's a very wild guess.  Searching the archives hasn't got me very
far; mostly I've found references to cyglsa, which I get the impression
is thoroughly deprecated, and based on
https://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 I don't
think it's appropriate anyway due to the way the password is stored.

For now I'm continuing to use a snippet in my .bashrc to start cron when
I first start Bash, but that's not the nicest of workarounds.  Does
anyone have suggestions for anything better?
EUROPE+adinwoodie@CygwinCronSTC ~
$ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ]

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) yes

Please enter the password for user 'EUROPE+adinwoodie':
Reenter:
Running cron_diagnose ...
WARNING: You do not currently have a crontab file.

... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
cygrunsrv: Error starting a service: StartService:  Win32 error 1068:
The dependency service or group failed to start.


In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
 Names such as "find" and "date" may refer to Windows programs.


EUROPE+adinwoodie@CygwinCronSTC ~
$ cp /dev/clipboard event_details.txt

EUROPE+adinwoodie@CygwinCronSTC ~
$ /usr/bin/cronbug

This script produces an error report for cron.
Please run it while the cron service is running (if possible).
Send cronbug.txt as an attachment to cygwin@cygwin.com
mentioning "cron" in the Subject line
and describing the problem you observe.
Do you want to continue? (yes/no) yes

The report is written to the file ./cronbug.txt
ls: cannot access '/var/cron/tabs/*': No such file or directory
ls: cannot access '/var/cron/tabs/*': No such file or directory
no crontab for EUROPE+adinwoodie

EUROPE+adinwoodie@CygwinCronSTC ~
$ ls /var/log
setup.log  setup.log.full

adam@CygwinCronGood ~
$ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ]

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are 

Re: Please support download setup-x86_64.exe on IPv6-only network

[Adam Dinwoodie via Cygwin]

On Thu, Nov 16, 2023 at 08:13:30AM +0100, Martin Wege via Cygwin wrote:
> On Thu, Nov 16, 2023 at 2:40 AM Bin W via Cygwin  wrote:
> >
> > https://www.cygwin.com/setup-x86_64.exe
> > IPv6-only network can't download the installer.
> 
> Details please. Does
> https://www.cygwin.com/setup-x86_64.exe
> not work on an IPv6-only network?
> 
> Or can setup-x86_64.exe not download data on an IPv6 network?

I've just checked: cygwin.com and www.cygwin.com only have DNS A
records, no  records, so there's no way to get the installer (or
indeed anything else) from cygwin.com if you're on an IPv6-only network.

Fixing this will require setting up the web servers for cygwin.com to be
accessible over IPv6, and configuring the corresponding IPv6 addresses
in the domain's DNS records.

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

New: python-rfc6555 0.1.0-1

[Adam Dinwoodie via Cygwin-announce]

Version 0.1.0-1 of python-rfc6555 has been uploaded to the Cygwin
distribution servers, and should be coming soon to a mirror near you.

python-rfc6555 is an implementation of the RFC 6555 "Happy Eyeballs"
algorithm for improving connection speeds from IPv4/IPv6 dual-stack
systems to some IPv4-only hosts.

This release includes the following Cygwin packages:

- python3-rfc6555
- python38-rfc6555
- python39-rfc6555

Enjoy!

Adam

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

If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. It will be in the 
format:

List-Unsubscribe: , 


The easiest unsubscribe method is to visit the web page associated with the 
mailing list as seen above, and click Unsubscribe.

Alteratively, you can send email to the list server using the address given in 
the mailto: above.

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

https://sourceware.org/lists.html#unsubscribe

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

Re: [ITP] python-rfc6555 0.1.0

[Adam Dinwoodie via Cygwin-apps]

On Fri, Nov 10, 2023 at 04:23:31PM +, Jon Turney wrote:
> On 08/11/2023 17:56, Adam Dinwoodie via Cygwin-apps wrote:
> > I'd like to package python-rfc6555.  This is a Python module that's now
> > required for offlineimap, for which I'm slowly working towards
> > submitting an ITA.
> > 
> > The Python module has an Apache 2.0 license, and is available at least
> > from Debian per https://packages.debian.org/bookworm/python3-rfc6555
> > 
> > cygport file is attached, and cygport build results are available at:
> 
> Attachment seems to be missing, but I looked at the cygport and it seems ok.

D'oh.

> I added this to your packages.

Thank you!

Re: python-requests update request

[Adam Dinwoodie via Cygwin]

On Sun, Nov 12, 2023 at 02:35:38PM +, Jon Turney wrote:
> On 06/11/2023 14:58, Adam Dinwoodie via Cygwin wrote:
> > Hi Marco,
> > 
> > python-requests is currently at v2.27.1, and the latest upstream release
> > is v2.31.0.  I'm chasing down a long requirement chain as part of trying
> > to update Cygwin's OfflineIMAP package to run against Python 3, and one
> > of those requirements wants python-requests to be at least v2.30.0.
> > 
> > I've updated the cygport file for python-requests to compile v2.31.0.
> > The patch files required some updates to account for changes in the
> > upstream code, but none of the changes seemed actually significant.
> > Could you have a look and see if you can upload a new version of
> > python-requests?
> > 
> > My updated cygport file and patch files are available at
> > https://github.com/cygporter/python-requests/tree/2.31.0.
> 
> Since Marco isn't available right now, I did a NMU based on this.

Magic, 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: Missing Python dependencies for venv standard library module

[Adam Dinwoodie via Cygwin]

On Fri, Nov 10, 2023 at 02:35:16PM +, Jon Turney wrote:
> On 08/11/2023 16:17, Adam Dinwoodie via Cygwin wrote:
> > Hullo,
> > 
> > It looks like the python39 package is missing dependencies on
> > python-setuptools-wheel and python-pip-wheel.  I've not checked, but I
> > suspect earlier Python versions are missing the same dependencies.
> > Without these, the Python built-in venv module doesn't work:
> > 
> >  $ python3 -m venv v
> >  Error: Command '['/home/WDAGUtilityAccount/v/bin/python3', '-Im', 
> > 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
> > 
> > Compare when the both python-setuptools-wheel and python-pip-wheel are
> > installed:
> > 
> >  $ python3 -m venv v
> >  $ . v/bin/activate
> >  (v) $ python3 -c 'import sys; print(sys.path)'
> >  ['', '/usr/lib/python39.zip', '/usr/lib/python3.9', 
> > '/usr/lib/python3.9/lib-dynload', 
> > '/home/WDAGUtilityAccount/v/lib/python3.9/site-packages']
> >  (v) $ deactivate
> > 
> > I've attached cygcheck files from sandbox VMs for both the broken and
> > working cases.  I'm not sure what the correct fix is here -- possibly
> > adding dependencies, possibly changing how things are packaged -- but
> > I'd expect Python standard library modules to either work or to give an
> > error message that makes it clearer what additional packages are
> > required to make them work.
> 
> Yeah. I have a vague recollection there was some other case recently where
> one these being missing was causing some confusion.
> 
> I think the easiest way to convince me that this is a historical oversight
> would be to look how other distros do this: If they have python depend on
> python-setuptools and python-wheel, then we probably should as well...

I only have Debian set up to check quickly, but just looking at that
example:

- /usr/share/python-wheels/setuptools-66.1.1-py3-none-any.whl is
  provided by the python3-setuptools-whl package.
- python3-setuptools-whl is required by python3.11-venv
- python3.11-venv is required by python3-venv
- python3-venv is suggested (*not* required) by python3

Slighly confusingly, python3.11-venv looks to only provide the ensurepip
module; the venv module is provided by libpython3.11-stdlib, which is a
requirement for python3, so it's only an Apt "suggestion" that gets this
working there.  However, Debian does provide a more useful error message
when you don't have things installed usefully:

$ python3 -m venv v
The virtual environment was not created successfully because ensurepip is 
not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt install python3.11-venv

You may need to use sudo with that command.  After installing the 
python3-venv
package, recreate your virtual environment.

Failing command: /home/adam/v/bin/python3

So that's at least one other distro that is at least a bit more helpful.
As I say, I don't have strong opinions on what the correct fix is here.
Just adding the dependencies is an obvious option, and probably the
easiest option from a maintainer perspective, but it's clearly not the
only option.

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

[ITP] python-rfc6555 0.1.0

[Adam Dinwoodie via Cygwin-apps]

I'd like to package python-rfc6555.  This is a Python module that's now
required for offlineimap, for which I'm slowly working towards
submitting an ITA.

The Python module has an Apache 2.0 license, and is available at least
from Debian per https://packages.debian.org/bookworm/python3-rfc6555

cygport file is attached, and cygport build results are available at:

- https://tastycake.net/~adam/python-rfc6555/python-rfc6555-0.1.0-1-src.hint
- https://tastycake.net/~adam/python-rfc6555/python-rfc6555-0.1.0-1-src.tar.xz
- 
https://tastycake.net/~adam/python-rfc6555/python3-rfc6555/python3-rfc6555-0.1.0-1.hint
- 
https://tastycake.net/~adam/python-rfc6555/python3-rfc6555/python3-rfc6555-0.1.0-1.tar.xz
- 
https://tastycake.net/~adam/python-rfc6555/python39-rfc6555/python39-rfc6555-0.1.0-1.hint
- 
https://tastycake.net/~adam/python-rfc6555/python39-rfc6555/python39-rfc6555-0.1.0-1.tar.xz
- 
https://tastycake.net/~adam/python-rfc6555/python38-rfc6555/python38-rfc6555-0.1.0-1.hint
- 
https://tastycake.net/~adam/python-rfc6555/python38-rfc6555/python38-rfc6555-0.1.0-1.tar.xz

Missing Python dependencies for venv standard library module

[Adam Dinwoodie via Cygwin]

Hullo,

It looks like the python39 package is missing dependencies on
python-setuptools-wheel and python-pip-wheel.  I've not checked, but I
suspect earlier Python versions are missing the same dependencies.
Without these, the Python built-in venv module doesn't work:

$ python3 -m venv v
Error: Command '['/home/WDAGUtilityAccount/v/bin/python3', '-Im', 
'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

Compare when the both python-setuptools-wheel and python-pip-wheel are
installed:

$ python3 -m venv v
$ . v/bin/activate
(v) $ python3 -c 'import sys; print(sys.path)'
['', '/usr/lib/python39.zip', '/usr/lib/python3.9', 
'/usr/lib/python3.9/lib-dynload', 
'/home/WDAGUtilityAccount/v/lib/python3.9/site-packages']
(v) $ deactivate

I've attached cygcheck files from sandbox VMs for both the broken and
working cases.  I'm not sure what the correct fix is here -- possibly
adding dependencies, possibly changing how things are packaged -- but
I'd expect Python standard library modules to either work or to give an
error message that makes it clearer what additional packages are
required to make them work.

Cheers,

Adam

Cygwin Configuration Diagnostics
Current System Time: Wed Nov 08 15:57:42 2023

Windows 11 Enterprise Ver 10.0 Build 22621 

Running in Terminal Service session

Path:   C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Users\WDAGUtilityAccount\AppData\Local\Microsoft\WindowsApps

Output from C:\cygwin64\bin\id.exe
UID: 197112(WDAGUtilityAccount)
GID: 197121(None)
197121(None)
114(Local account and member of Administrators group)
555(Remote Desktop Users)
545(Users)
544(Administrators)
14(REMOTE INTERACTIVE LOGON)
4(INTERACTIVE)
11(Authenticated Users)
15(This Organization)
113(Local account)
4095(CurrentSession)
66048(LOCAL)
262154(NTLM Authentication)
405504(High Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

PWD = '/home/WDAGUtilityAccount'
HOME = '/home/WDAGUtilityAccount'
USER = 'WDAGUtilityAccount'

ProgramFiles(x86) = 'C:\Program Files (x86)'
!:: = '::\'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
SHELL = '/bin/bash'
NUMBER_OF_PROCESSORS = '8'
PROCESSOR_LEVEL = '6'
TERM_PROGRAM_VERSION = '3.6.5'
USERDOMAIN_ROAMINGPROFILE = 'E7535596-31D4-4'
HOSTNAME = 'e7535596-31d4-4320-9f01-888322d045ef'
PROGRAMFILES = 'C:\Program Files'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
OS = 'Windows_NT'
HOMEDRIVE = 'C:'
USERDOMAIN = 'E7535596-31D4-4'
EFC_3992 = '0'
USERPROFILE = 'C:\Users\WDAGUtilityAccount'
TZ = 'Europe/London'
ALLUSERSPROFILE = 'C:\ProgramData'
ORIGINAL_PATH = 
'/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Users/WDAGUtilityAccount/AppData/Local/Microsoft/WindowsApps'
CommonProgramW6432 = 'C:\Program Files\Common Files'
USERNAME = 'WDAGUtilityAccount'
COMSPEC = 'C:\Windows\system32\cmd.exe'
APPDATA = 'C:\Users\WDAGUtilityAccount\AppData\Roaming'
SYSTEMROOT = 'C:\Windows'
LOCALAPPDATA = 'C:\Users\WDAGUtilityAccount\AppData\Local'
COMPUTERNAME = 'E7535596-31D4-4'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
TERM = 'xterm'
LOGONSERVER = '\\E7535596-31D4-4'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules'
TEMP = '/tmp'
SHLVL = '1'
PROCESSOR_REVISION = '8c01'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LC_CTYPE = 'en_US.UTF-8'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 140 Stepping 1, GenuineIntel'
SESSIONNAME = '31C5CE94259D4006A9E4#0'
PS1 = '$ '
HOMEPATH = '\Users\WDAGUtilityAccount'
TMP = '/tmp'
ProgramW6432 = 'C:\Program Files'
PROFILEREAD = 'true'
MINTTY_SHORTCUT = '/cygdrive/c/Users/Public/Desktop/Cygwin64 Terminal.lnk'
WINDIR = 'C:\Windows'
PROCESSOR_ARCHITECTURE = 'AMD64'
PUBLIC = 'C:\Users\Public'
CLIENTNAME = '451024fb-2f83-4'
SYSTEMDRIVE = 'C:'
EXECIGNORE = '*.dll'
OLDPWD = '/etc/skel'
TERM_PROGRAM = 'mintty'
ProgramData = 'C:\ProgramData'
_ = '/usr/bin/cygcheck'

HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:\cygwin64'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin64'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: e022582115c10879 Path: C:\cygwin64

c:  hd  NTFS 40830Mb   8% CP CS UN PA FC

C:\cygwin64  /  system  binary,auto
C:\cygwin64\bin  /usr/bin   system  binary,auto
C:\cygwin64\lib  /usr/lib   system  binary,auto
cygdrive prefix  /cygdrive  userbinary,posix=0,auto

Found: C:\cygwin64\bin\awk
 -> C:\cygwin64\bin\gawk.exe
Found: C:\cygwin64\bin\bash.exe
Found: C:\cygwin64\bin\cat.exe
Found: C:\Windows\system32\certutil.exe
Not Found: clinfo

python-requests update request

[Adam Dinwoodie via Cygwin]

Hi Marco,

python-requests is currently at v2.27.1, and the latest upstream release
is v2.31.0.  I'm chasing down a long requirement chain as part of trying
to update Cygwin's OfflineIMAP package to run against Python 3, and one
of those requirements wants python-requests to be at least v2.30.0.

I've updated the cygport file for python-requests to compile v2.31.0.
The patch files required some updates to account for changes in the
upstream code, but none of the changes seemed actually significant.
Could you have a look and see if you can upload a new version of
python-requests?

My updated cygport file and patch files are available at
https://github.com/cygporter/python-requests/tree/2.31.0.

Cheers,

Adam

-- 
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 RFC PATCH 1/1] Run install functions separately

[Adam Dinwoodie via Cygwin-apps]

On Sun, Nov 05, 2023 at 10:24:43PM +, Adam Dinwoodie via Cygwin-apps wrote:
> ```
> #!/usr/bin/bash
> 
> src_install () {
>   false
>   echo "This step *does* run"
> }
> 
> src_install && echo "As does this step"
> ```

The above example should have had `set -e` at the top.  Everything I
said holds both with and without it, but the point I was trying to make
is definitely much clearer when both examples have `set -e` and the only
difference is whether there's an && between the function call and the
echo.

Re: [cygport RFC PATCH 1/1] Run install functions separately

[Adam Dinwoodie via Cygwin-apps]

On Fri, Nov 03, 2023 at 05:57:08PM +0100, ASSI via Cygwin-apps wrote:
> Adam Dinwoodie via Cygwin-apps writes:
> > When running as part of a `&&` chain, Bash's `set -e` behaviour is
> > suppressed entirely, which means calls that produce non-zero error codes
> > will be ignored if they're called inside functions that are part of such
> > a chain.
> >
> > To avoid silent failures from commands in a src_install function being
> > ignored, don't chain the function calls with &&, and instead just let
> > Bash's `set -e` behaviour handle failures.
> 
> That patch circumvents the shortcutting of the execution chain at the
> first fail and might produce undesirable results elsewhere.  Unless
> there's another interesting behaviour in Bash, it should suffice to
> follow the last command in the "&&" chain by "|| false" to transfer the
> status of the chain to PIPESTATUS (provided that the return code of the
> functions involved is set correctly).

I think you've misunderstood how `set -e` works.  When `set -e` is
active, any non-zero return code from the final command in a pipeline
will cause the script to exit.  So both with and without my patch, a
non-zero return code from __prepinstalldirs, src_install or
__src_postinst will cause execution to stop.

The issue is that the && chain disables `set -e` for anything other than
the final command in the chain, *including within functions*.  In most
functions in cygport, a non-zero return code will cause cygport to
error, but because the && chain disables `set -e`, failures within
src_install are silently ignored.  Counterintuitively, having the &&
chain present means that execution will _continue_ after a failure!

Compare the two scripts below:

```
#!/usr/bin/bash

set -e

src_install () {
false
echo "This step never runs"
}

src_install
echo "This also doesn't run"
```

```
#!/usr/bin/bash

src_install () {
false
echo "This step *does* run"
}

src_install && echo "As does this step"
```

I believe the intent of using `set -e` in cygport is that when there's a
failure -- as with the false command in the src_install functions above
-- execution will stop.  This works as expected in the first example,
but in the second example, the `false` call has no effect whatsoever:
Bash will run both the echo within the function and the one that follows
the function.

See also:
- https://www.shellcheck.net/wiki/SC2310
- https://mywiki.wooledge.org/BashFAQ/105

Alternatively, just have a look at the test case I attached to the cover
email; I'd expect that cygport file to fail the install stage, because
the first command in the src_install function is an unhandled failure.
Currently, the src_install succeeds, with no hint of any problems, but
with my patch, it produces an error as expected.

Updated: Git v2.42.1-1

[Adam Dinwoodie via Cygwin-announce]

Version 2.42.1-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

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

If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. It will be in the 
format:

List-Unsubscribe: , 


The easiest unsubscribe method is to visit the web page associated with the 
mailing list as seen above, and click Unsubscribe.

Alteratively, you can send email to the list server using the address given in 
the mailto: above.

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

https://sourceware.org/lists.html#unsubscribe

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

Re: Cant install Cygwin Virt-manager that asks for library that asks for python2

[Adam Dinwoodie via Cygwin]

On Wed, 1 Nov 2023 at 06:33, Bill Sharp via Cygwin  wrote:
>
> On Tue, 31 Oct 2023 at 22:58, Jānis Ķengurs via Cygwin 
> wrote:
>
> > I wanted to use some KVM or Qemu or something on linux and windows that can
> > fast open iso files for testing
> > Downloaded on  Windows 10
> > Here shows what depends on this install, but does it select all files it
> > needs?
> > https://cygwin.com/packages/summary/virt-manager.html
> > Cant install Cygwin Virt-manager that asks for library that asks for
> > python2
> > The error is weird- suggest to unselect, but people might not read, instead
> > error should open to install separate if need to install it seperate
> >
> > I selected that library also but now instllation for both files asking for
> > python2
> > Problem 1/2
> > nothing provides python2 needed by python2-libvirt-4.2.0-1
> > Solution 1/1 (default)
> >   - do not ask to install python2-libvirt-4.2.0-1
> > Problem 2/2
> > nothing provides python2 needed by virt-manager-1.5.1-2
> > Solution 1/1 (default)
> >   - do not ask to install virt-manager-1.5.1-2
> >
> > BB
> > Save a tree. Please don't print this e-mail unless it's really necessary.
> > ᐧ
> >
>
> Python2 was removed in July, and per Jon's announcement it was expected
> this would break some orphaned packages:
>
> https://cygwin.com/pipermail/cygwin-announce/2023-July/011186.html

And having just had a look, it's not going to be straightforward to
release virt-manager for Python3: it has several dependencies,
including Gtk3, that are themselves not currently available for
Cygwin.

Volunteers to get that working would likely be well received! Package
maintainer basics are at http://www.cygwin.com/packages.html, although
I expect the key job would be getting the current code building on
Cygwin; once it's built and working, the packaging steps are much more
straightforward…

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

[cygport RFC PATCH 1/1] Run install functions separately

[Adam Dinwoodie via Cygwin-apps]

When running as part of a `&&` chain, Bash's `set -e` behaviour is
suppressed entirely, which means calls that produce non-zero error codes
will be ignored if they're called inside functions that are part of such
a chain.

To avoid silent failures from commands in a src_install function being
ignored, don't chain the function calls with &&, and instead just let
Bash's `set -e` behaviour handle failures.
---
 bin/cygport.in | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/bin/cygport.in b/bin/cygport.in
index 3f89ac67..3bf4a4fa 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -679,7 +679,11 @@ do
inst*)
__stage Installing;
__log_init ${installlog};
-   (__prepinstalldirs && src_install && __src_postinst) 
2>&1 | tee -a ${installlog};
+   {
+   __prepinstalldirs
+   src_install
+   __src_postinst
+   } 2>&1 | tee -a ${installog};
_status=${PIPESTATUS[0]};
;;
postinst*)
@@ -764,12 +768,20 @@ do
__stage Compiling && src_compile 2>&1 | tee -a 
${compilelog} && \
test ${PIPESTATUS[0]} -eq 0 && \
__log_init ${installlog} && \
-   __stage Installing && (__prepinstalldirs && src_install 
&& __src_postinst) 2>&1 | tee -a ${installlog} && \
-   test ${PIPESTATUS[0]} -eq 0 && \
-   __log_init ${pkglog} && \
-   __stage Packaging && (__pkg_binpkg && __pkg_pkgcheck && 
__pkg_srcpkg ${_pkg_tag} && __pkg_dist ${_pkg_tag}) 2>&1 | tee -a ${pkglog} && \
-   test ${PIPESTATUS[0]} -eq 0
-   _status=$?;
+   __stage Installing
+   {
+   __prepinstalldirs
+   src_install
+   __src_postinst
+   } 2>&1 | tee -a ${installlog};
+   if test ${PIPESTATUS[0]} -eq 0; then
+   __log_init ${pkglog} && \
+   __stage Packaging && (__pkg_binpkg && 
__pkg_pkgcheck && __pkg_srcpkg ${_pkg_tag} && __pkg_dist ${_pkg_tag}) 2>&1 | 
tee -a ${pkglog} && \
+   test ${PIPESTATUS[0]} -eq 0
+   _status=$?;
+   else
+   _status=1;
+   fi
;;
help)
__show_help;
-- 
2.40.1

[cygport RFC PATCH 0/1] Bug fix? src_install commands fail silently

[Adam Dinwoodie via Cygwin-apps]

I've discovered what I _think_ is a cygport bug: most functions within
cygport run with `set -e` enabled in Bash, so if a command has a
non-zero return code that isn't explicitly handled, that'll cause the
cygport command overall to fail.  This doesn't work within src_install,
and I _suspect_ that's a bug following from some decidedly unintuitive
Bash behaviour.

The attached test case demonstrates the problem: running `cygport
test.cygport prep compile test` will fail, because of the `false` call
at the start of `src_test`.  Running `cygport test.cygport prep compile
install`, however, won't fail, even though there's a `false` call at the
start of the `src_install` function.

Specifically, when src_install is called in the cygport executable, it's
called as below:

(__prepinstalldirs && src_install && __src_postinst) 2>&1 | tee -a 
${installlog}

The fact that Bash normally only considers the final command in a
pipeline is handled by a subsequent check of ${PIPESTATUS[0]}, but
quoting the Bash man page description for `set -e`:

> The shell does not exit if the command that fails is ... part of any
> command executed in a && or || list except the command following the
> final && or ||   If a compound command other than a subshell
> returns a non-zero status because a command failed while -e was being
> ignored, the shell does not exit.
>
> If a compound command or shell function executes in a context where -e
> is being ignored, none of the commands executed within the compound
> command or function body will be affected by the -e setting, even if
> -e is set and a command returns a failure status.

So because the function call is part of a && chain, the `set -e`
behaviour is completely disabled within that function; the only way a
non-zero return code would be propagated from within the function is if
(a) it were explicitly `return`ed or (b) it came from the final command
in the function.

I've provided a single patch to fix this specific issue, partly because
I'd already written it and thought I might as well share it, but I think
this probably wants a bit more thought.  In particular, there are two
things that might mean we want to handle this differently:

- I've only fixed a single problem, but I think bugs of this style are
  much more common, e.g. in the similar code for the `cygport compile`
  command.  It might make sense to fix this in far more locations.

- I wouldn't be at all surprised if this bug, and others of the same
  ilk, have become load-bearing.  If this gets fixed, it might cause a
  lot of build scripts that have otherwise been happily ignoring benign
  non-zero return codes suddenly start failing unexpectedly.

Adam Dinwoodie (1):
  Run install functions separately

 bin/cygport.in | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

-- 
2.40.1

NAME=test
VERSION=1
RELEASE=1
CATEGORY=Test
SUMMARY='Test package'
HOMEPAGE=
LICENSE=

src_compile () {
cd "$B"
{
echo '#!/usr/bin/env sh'
echo "echo 'Hello, world!'"
} >helloworld
}

src_install () {
false
cd "$B"
dobin helloworld
}

src_test () {
false
PATH="${D}/usr/bin:$PATH"
helloworld | grep 'Hello'
}

Updated: inih v57-1

[Adam Dinwoodie via Cygwin-announce]

Version 57-1 of inih has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

>From the upstream description[0]:

> inih (INI Not Invented Here) is a simple .INI file parser written in
> C.  It's only a couple of pages of code, and it was designed to be
> small and simple, so it's good for embedded systems.  It's also more
> or less compatible with Python's ConfigParser style of .INI files,
> including RFC 822-style multi-line syntax and `name: value` entries.

[0]: https://github.com/benhoyt/inih

This includes the following packages:

- libinih0
- libinih-devel
- inih-debuginfo

Enjoy!

Adam

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

If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. It will be in the 
format:

List-Unsubscribe: , 


The easiest unsubscribe method is to visit the web page associated with the 
mailing list as seen above, and click Unsubscribe.

Alteratively, you can send email to the list server using the address given in 
the mailto: above.

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

https://sourceware.org/lists.html#unsubscribe

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

[cygport PATCH] Check for pythonXX-wheel when using python-wheel

[Adam Dinwoodie via Cygwin-apps]

The python wheel package is required for building using the python-wheel
cygclass, but nothing in cygport verifies its existence, and the error
from the Python commands themselves aren't particularly helpful either.
To avoid other people wasting the time I just did trying to debug Python
build errors, check if the relevant wheel executable is installed, and
complain if it isn't.
---
 cygclass/python-wheel.cygclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cygclass/python-wheel.cygclass b/cygclass/python-wheel.cygclass
index 4f71639d..3f274b98 100644
--- a/cygclass/python-wheel.cygclass
+++ b/cygclass/python-wheel.cygclass
@@ -111,6 +111,7 @@ do
esac
 
check_prog_req pip${ver} python${ver//.}-pip
+   check_prog_req wheel-${ver} python${ver//.}-wheel
 done
 
 #o* python-wheel.cygclass/PKG_NAMES (python-wheel)
-- 
2.40.1

Updated: Git v2.42.0-1

[Adam Dinwoodie via Cygwin-announce]

Version 2.42.0-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

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

If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. It will be in the 
format:

List-Unsubscribe: , 


The easiest unsubscribe method is to visit the web page associated with the 
mailing list as seen above, and click Unsubscribe.

Alteratively, you can send email to the list server using the address given in 
the mailto: above.

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

https://sourceware.org/lists.html#unsubscribe

Please read *all* of the information on unsubscribing that is available 
starting at this URL.

Re: tzdata packaging options

[Adam Dinwoodie via Cygwin-apps]

On Tue, 17 Oct 2023 at 23:48, Brian Inglis via Cygwin-apps
 wrote:
>
> Hi folks,
>
> I have been building and distributing tzdata with maximal backward 
> compatibility
> since adopting the package.
>
> The maintainer and some distros are choosing to consolidate data and drop
> historical details since 1970.
> I question whether there are any Cygwin users who use and need the TAI-offset
> including leap seconds zoneinfo/right subtree, and whether we also need to
> include the zoneinfo/posix subtree, duplicating the data in the main zoneinfo 
> tree?
>
> There could be astrologers, genealogists, modern-history historians, and
> developers of related software who use the complete historical details, and
> astronomers, physicists, who use the TAI-offset including leap seconds
> zoneinfo/right subtree.
>
> I am unsure if anyone depends on the posix subtree duplicating the main tree.
>
> I could split the current package into the main tree and the "posix" subtree
> each 1.7MB, and the "right" subtree 2.3MB.
>
> For tzdata-minimal, which could become the Base package, I could generate
> another build with only zones consolidated with common history since 1970, but
> that would require another build with different options to generate the data 
> to
> compile, so presumably another source package, unless there is a way to 
> generate
> say a minimal subtree with another cygmake with different MAKEOPTS, and have 
> it
> packaged the same as the main subtree, or could cygport go bananas?
>
> Fedora was developing a tzdata-minimal package, which was only to include UTC
> for containers, but it looks like  UTC-only should work by not installing 
> *ANY*
> tzdata, so they shelved their efforts:
>
> https://fedoraproject.org/wiki/Changes/tzdata-minimal
> 
> https://bugzilla.redhat.com/buglist.cgi?component=tzdata=Fedora
>
> Do we think there could be a use case for a UTC-only (Base?) no tzdata package
> e.g. CI, and the no data defaults will be handled adequately?
>
> For RH see RHEL Timezone Data (tzdata) - Development Status Page:
>
> https://access.redhat.com/articles/1187353
>
> Suggestions for how best to proceed with these options, and to ask these
> questions of users on the main list?

I expect that – while I use Cygwin in CI contexts – that's relatively
rare, and most folk using Cygwin will be using it directly. I expect
not having at least a core of tzdata files available by default would
cause some considerable confusion for those users, as I imagine lots
of them consume data from those packages without realising they're
doing so. If Cygwin's setup and dependency resolution tools had, say,
the equivalent of Debian's task package groups and/or
Recommends/Suggests dependencies, it might be sensible to have tzdata
recommended for desktop use but not required for server use. Until and
unless those enhancements happen, though, IMVHO at least a core tzdata
package should be part of the base installation.

That said, I suspect there's very few people who need all the
extensive data, and those people probably know they're doing something
a bit weird, so moving the "posix" and/or "right" trees into separate
packages seems reasonable. (Although if "posix" is just a duplicate of
the main tree, wouldn't that actually make things worse? If they're
duplicated in the same package, I'd expect them to at least be
well-compressed, and potentially to be hardlinks so the additional
space from including both is near-zero…)

_That_ said, given the relatively cheap costs of disk space and
bandwidth, I don't see much value in shaving a few MB here and there
when this is still a relatively small part of most Cygwin
installations. So overall I'd be inclined to do whatever is the least
work that's not going to break things.

FWIW, if you wanted to canvass opinions from the wider list, I think
the email you've sent here would be fine for that purpose, although
I'd probably remove the implementation details (e.g. the discussions
of cygmake) and just list the options available and the different
impacts thereof.

Re: Ruby EOL in Cygwin 3.4.9?

[Adam Dinwoodie via Cygwin]

On Thu, 12 Oct 2023, 22:46 Eric Hendrickson wrote:
> The comparison to Debian Stable - I hear you but I don’t think that is a
> fair comparison. Debian Stable is not shipping EOL packages at the time it
> was released.

To pick a fairly high-profile example, Debian Bullseye was released as
Debian Stable on 14 August 2021.  It included Python 2.7, which by that
time had been EOL for more than 18 months, with the EOL date having been
announced over seven years earlier.

https://www.debian.org/releases/bullseye/
https://packages.debian.org/bullseye/python2
https://peps.python.org/pep-0373/

More generally, lots of OSS projects don't provide support for anything
other than their most recent release, and Debian Stable includes lots of
that software at releases other than the most recent release.  If Debian
had the policy you're asserting it has, the concept of Debian Stable
would be impossible.

> And your point about the effort involved and no known bugs is well taken
> of course but Cygwin is still distributing EOL software.  This is why I
> asked, would it make sense to just not release new non emergency versions
> of Cygwin with EOL packages, until that can be remedied.

Here, the comparison with Debian Stable *is* unhelpful.  The concept of
"versions of Cygwin" that you're using doesn't make sense: unlike
Debian, Cygwin doesn't have an overarching version scheme.  There's no
such thing as "a version of Cygwin" that we could stop releasing because
of problems with a particular package.

We could implement a block on releasing any packages while one package
has a problem.  That seems like a terrible idea to me; I'd be happy to
discuss it -- I might be wrong! -- but I'm much more interested in
having that discussion with people who have been actively contributing
to Cygwin for some time, as they're the folk who are most likely to
understand what the advantages and disadvantages might be, and who I
trust to be willing to provide practical contributions towards the
additional work they're proposing.  At the very least, I'd want that
discussion to be based on something more significant than a nebulous
concept of the project's reputation.

> Security scans are only increasing in scrutiny and frequency - this came
> to my attention because in my environment we are running Cygwin 3.1.6 -
> which admittedly is 3+ years old - and the version of Ruby packaged in it
> got identified in a security scan as EOL.
>
> My first thought was to update the internal Cygwin package to the latest
> but i checked and that too is provisioned with an EOL version of Ruby.
> (2.6.4)

What do you mean by "provisioned"? What do you mean by "the Cygwin
package"?

If you download the Cygwin installer from the Cygwin website, and ask it
to install Ruby, it will install 3.2.2. You *can* install 2.6.4, but
you'd have to deliberately select that version.

If you are seeing the Cygwin installer trying to install Ruby 2.6.4 by
default, that sounds like an installer bug.  If that's what's happening,
please give us a useful bug report so we can work out what's going
wrong.

However, if your concern is merely that it's *possible* to install EOL
software, I don't think that concern will be widely shared.  If someone
wants to install old software, or configure an SSH server with a root
password of "password1", or otherwise go out of their way to do
something that's not ideal from a security perspective, I don't think we
have a responsibility to stop them.

You might have better luck petitioning the Ruby project to remove the
download links for out-of-support software from their releases page,
which offers versions of Ruby that have been out of support for over a
decade.

https://www.ruby-lang.org/en/downloads/releases/

Thankfully, as you say, security scans are only increasing in frequency
and scrutiny, and they are evidently capable of catching scenarios where
someone has deliberately installed out-of-date software.

> Anyway, just wanted to bring this to your attention and ask if there is
> anything that can or should be done about this, again toward the reputation
> of Cygwin.

I say this because I think your concern is genuine: you are coming
across as concern trolling.

Some of your logic is demonstrably false, as with your claims about
Debian project policies.  Some of your problems are unclear, as with
your explanation of "the Cygwin package" being "provisioned with an EOL
version of Ruby".  I understand that you've not found many of the
replies to you to be kind, but that's largely because you haven't shown
us the kindness of clearly explaining your issue or showing you've done
any research into the issue yourself.

If you are concerned about the reputation of Cygwin, I'd suggest you
follow Glenn's excellent advice from earlier in this thread: provide
specific offers to help improve Cygwin, rather than merely expressing
concerns and asserting we should eject people who have spent years
actively contributing to improve Cygwin's reputation.  

Re: Ruby EOL in Cygwin 3.4.9?

[Adam Dinwoodie via Cygwin]

Picking up a few threads that I think others might have missed, and
which I think are worthy of acknowledgement…

On Thu, 12 Oct 2023 at 05:16, Eric D Hendrickson via Cygwin
 wrote:
> How does Cygwin being an all volunteer effort have any bearing on this
> question, other than the time and interest of the volunteers?

The fact that this is a volunteer effort doesn't have much direct
bearing. But the fact that we're volunteers means that time and
interest are very finite quantities. There are really not many folk
involved in actually making Cygwin, and I think everyone actively
involved in the project already has a wishlist of things they'd do if
they had the time.

> Perhaps the volunteer team should consider adopting a process of evaluating
> the support status of every package it redistributes, even at the expense
> of slowing down the rate of releases.  Or dropping packages when no one has
> the time or interest in creating a package from a supported version of the
> tool in question.

Packages do get dropped from the distribution occasionally when
they're no longer being updated and no longer viable.

I don't believe there's any comprehensive package-by-package review,
because that's a lot of work, and it's not even very interesting work.
But if someone provides a reason a specific package should be dropped,
it can happen. The mere fact that a package no longer has upstream
support is probably not enough, though; I expect we'd need no upstream
support and either a genuine significant vulnerability in the package,
or availability of a viable replacement.

> Again for the benefit of Cygwin as a whole - distributing EOL packages
> could put Cygwin as a whole at risk, which I'm sure you would agree is much
> worse than dropping a package from the suite.

I don't agree. If Cygwin mandated that packages be kept rapidly
up-to-date or be dropped, I expect Cygwin would rapidly become
unusable. A lot of our package maintainers – myself included – are
only able to work on Cygwin as and when they have the time. If the
project required maintainers to spend a regular amount of time on
their packages, which a reliable update schedule would require, I
expect a lot of us would just stop contributing.

When there are vulnerabilities identified, we can and do move quickly
to mitigate them. The fact that there's some EOL products available
through Cygwin is at least in part because there aren't any
significant security vulnerabilities that we're aware of. It would, of
course, be nice if the cutting edge were available for everything, but
that has its own disadvantages: rapid release cycles have more chance
of introducing new bugs. There's a reason plenty of people use Debian
Stable; there's lots of critical infrastructure still running on
Python 2.

(But, of course, the package in question here is actually reasonably
up-to-date: as Yasuhiro Kimura noted, the Cygwin mirrors are
distributing ruby 3.2.2-2, which has an advertised upstream EOL date
of March 2026. So a possibly more useful question is why *you* are
deploying an EOL version when more up-to-date versions are available!
To investigate that, I think we'd need a useful bug report explaining
what you're doing to get an install with such an old version.)

I also think it's worth remembering the use case for Cygwin. Cygwin is
designed to provide a *nix-like environment for Windows users, with
relatively little effort required to port software that was originally
written for *nix systems. The sorts of use cases where you really care
about most zero-day vulnerabilities aren't ones where I'd expect
Cygwin to be in use; if you have a public-facing web server, for
example, using Cygwin is a bad idea, not just because of the security
concerns, but also because Cygwin makes a lot of compromises around
performance, and you're likely to have a vastly better experience
using a Windows-native or Linux-native web server.

> This goes back to my other question -
>
> Is there an Issues log or backlog a la GitHub where bugs / enhancement
> requests / feature suggestions like this can be logged for future
> consideration / evaluation, instead of one off discussions in this
> ephemeral medium of email?

Email isn't ephemeral: everything sent to this mailing list is
archived indefinitely. You can browse and search the archives at
https://cygwin.com/lists.html.

That said, there is a reason folk use bug trackers. There's no central
bug tracker for Cygwin; individual maintainers may have their own
systems for tracking problems (I use GitHub), but there's no mandate
about what to use or how to use it. Even if we had someone willing to
set one up and maintain one, migrating to a central bug tracker is a
very significant amount of work, and it's not work that many people
would find fun or interesting.

If you want to help, there's a list of packages that don't have
maintainers at http://www.cygwin.com/packages/reports/unmaintained.html
– if you'd be willing to adopt one of those and keep 

Re: Most git executables are hard links to git.exe?

[Adam Dinwoodie via Cygwin]

On Fri, 21 Jul 2023 at 22:54, Jim Garrison via Cygwin wrote:
>
> On 07/21/23 14:52, Brian Inglis wrote:
> > On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
> >> Git comes with over 100 executables, mostly in /usr/libexec/git-core,
> >> that all appear to be *hard* links to /bin/git, in both Cygwin and
> >> Windows. The Windows fsutil command shows they're all hard linked:
> [snip]
> >> I'm curious to know if there's a specific reason for this implementation
> >> that would make it the choice over symbolic links.
> >
> > For the same reason you are complaining about backups not taking
> > hardlinks into account: to avoid distributing 400MB instead of 3MB.
> >
> > Cygwin backup utilities should be able to deal with these e.g. rsync -H,
> > --hard-links, although it appears xcopy and robocopy may not under
> > Windows 10; don't know about other utilities or Windows 11.
>
> But why not use symbolic links to accomplish the same thing?

A few reasons off the top of my head:

- This is what the Git build tooling does out of the box. Minimising
the number of changes we're making as a downstream packager makes my
life easier as package maintainer.

- This is what happens on *nix systems, and Cygwin generally
prioritises matching function with *nix systems over interoperability
with Windows tools; if you want interoperability with Windows tools,
you might be better off with Git for Windows. That's not trying to
brush you off; the reason Cygwin Git and Git for Windows both exist is
that they're both serving different user needs.

- As others have said, Windows in general has good support for
hardlinks, while it has no inherent support for Cygwin's symlinks.
That means a Windows application would need to be aware of Cygwin to
have any chance of usefully interacting with those files if they were
symlinks, whereas a Windows application doesn't need to be aware of
Cygwin at all to be able to handle hardlinks, it only needs to know
how to handle hardlinks on Windows.

- Although I've not measured it, I expect there's a small runtime cost
from using symlinks over hardlinks. Cygwin's Git is already slow, for
a variety of difficult-to-solve reasons, and I'm reluctant to do
anything that might make that worse.

- Inertia. The current situation works well for most people, and
changing things takes effort and risks breaking other folks' use
cases.

I do acknowledge that while many Windows tools *could* handle
hardlinks, many don't. I'm not at all surprised that some backup
utilities don't handle them well and back up each file separately. I
think switching to using symlinks for Cygwin's executables is the
wrong solution, though.

Instead, I'd suggest (a) finding a backup tool that can handle
hardlinks, (b) finding a backup tool that uses compression so the
"duplicate" data gets deduplicated as part of the backup process, (c)
not backing up most of Cygwin's /usr directory in the first place – in
most cases I wouldn't expect there to be anything in that folder that
couldn't be readily recovered elsewhere anyway – or (d) switching to a
disk imaging backup system rather than a file-based one if it's really
important that you have everything on disk ready to restore.

Hopefully that's all useful and/or interesting, even if it's not the
answer you were hoping for!

-- 
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: git submodule + gettext / envsubst

[Adam Dinwoodie via Cygwin]

On Fri, 23 Jun 2023 at 08:59, Andreas Heckel via Cygwin wrote:
>
> Hi,
>
> I recently faced some error messages when using git submodules. I found, that 
> Cygwin's git works nicely on its own. But when I have MSYS binary paths in my 
> environment, Cygwin's git finds the msys gettext and envsubst binary and 
> tries to use it, resulting in error messages (see below). I did solve the 
> issue, by installing Cygwin's gettext (which git does not seem to be 
> requiring).
> I write, because I found it somewhat odd, that Cygwin's git is not dependent 
> on gettext, but uses it, if it finds it somewhere in the path environment. 
> Just to emphasize, in my Cygwin environment all Cygwin paths come first. So 
> it was only using the wrong msys binary, because there was none in Cygwin.
> Is this behaviour expected and intended or could it be mitigated during 
> installation somehow?

This sounds like a missing dependency in Cygwin's Git package. I'm
slightly surprised – the package is included in the build
requirements, and cygport is normally pretty good at detecting runtime
dependencies in this sort of circumstance – but I'll get it fixed as
soon as I manage to get a new Git release out.

That's going to happen Any Day Now, although it has been Any Day Now
for a few months at this point thanks to a variety of other life
issues taking priority…

Adam

-- 
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: git 2.39.0 change from relative to absolute submodule paths

[Adam Dinwoodie via Cygwin]

On Wed, May 17, 2023 at 06:26:38AM +, Fuchs, Thorsten via Cygwin wrote:
> Hello,
> 
> After submodule update with git 2.39.0 some of our sub modules got
> their worktree settings in the .git/modules//config fil set
> as absolute paths. See the attached config files as example. It seems
> that if the path is changed from relative. Not all submodules are
> effected. It happens also sporadically and not and very frequently.
>
> It is possible to carry on working Cygwin git. However, we are using
> Tortoise git with libgit2 and git for windows in parallel. Due to the
> absolute Cygwin paths this is not working anymore.
>
> We have not yet seen such a behavior in git for windows. Also we can't
> reproduce it at this point in time. We consider it a bug but nor sure
> about it.

This is odd.  I suspect rewriting the paths like this is something in
the upstream Git project, rather than anything Cygwin-specific (although
clearly the issues it's causing are Cygwin-specific).  I don't think
there's enough information here for me to investigate or report
upstream, unfortunately; what I really need is information about what
triggers the behaviour so I can reproduce the problem.

If you manage to work out how to reproduce this behaviour, rather than
just noticing it after the fact, that would be incredibly useful and I
can take things from there.

Adam

-- 
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: ECCN for Cygwin 1.7.34 - FREE

[Adam Dinwoodie via Cygwin]

On Mon, 15 May 2023 at 21:46, Justin Reeves via Cygwin wrote:
>
> To Whom It May Concern;
>
> I am a project manager at Caterpillar and I am working on compliance for 
> programs/applications. I am looking to find the Electronic Classification 
> Control Number (ECCN) for "Cygwin 1.7.34 - FREE". If someone could respond 
> via email to confirm the ECCN, then I can document the response for this 
> program and identify it properly in our various tools/databases. Please let 
> me know if you need assistance. Thank you in advance for your help.

Hi Justin,

Cygwin does not have an ECCN. There is more information on the website
at https://cygwin.com/licensing.html

Adam

-- 
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: python2 removal

[Adam Dinwoodie via Cygwin-apps]

On Sun, 30 Apr 2023 at 19:25, Jon Turney  wrote:
>
> On 25/02/2023 16:51, Adam Dinwoodie via Cygwin-apps wrote:
> > On Sat, 25 Feb 2023 at 16:23, Jon Turney via Cygwin-apps wrote:
> >> On 16/01/2023 12:49, Jon Turney via Cygwin-apps wrote:
> >>> On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote:
> >>> [...]
> >>>> Python 2.7 is the last python2 version, which was sunsetted on January
> >>>> 1, 2020.
> >>> [...]
> [...]
> >>
> >>   From a brief survey, only offlineimap and urlgrabber (which should
> >> probably be named python-urlgrabber, since it contains a python module)
> >> seem to be actively maintained enough to support python3.
> >>
> >> So I will probably remove the others, and consider if it's possible and
> >> worthwhile to update those.
> >>
> >> (I also noted that breezy appears to be the python3 replacement for bzr
> >> and getmail6 appears to be the python3 replacement for getmail.)
> >
> > I'm happy to adopt both of these. I'll give Jari a little while to
> > reclaim them first, not least as I'm not going to have the time to
> > spend on packaging these for at least a week or so, but if Jari (or
> > anyone else) doesn't claim them first, I'll send an ITA once I've
> > checked I can get the packaging to work.
> Gentle ping to ask if you are still intending to package these?

Yes, they're both on my to-do list, but I've had a whole bunch of real
life come up over the past few months. If the delay is causing issues,
though, I can bump them up my priority list…

Re: bash shell script: recently running, now failing

[Adam Dinwoodie via Cygwin]

On Thu, Apr 06, 2023 at 04:43:51AM +, Fergus Daly via Cygwin wrote:
> I have a "hash bang" bash shell script i.e. first line
> #! /bin/sh
> or equivalently
> #! /bin/bash
> For various reasons I want this file to be identified as binary so its second 
> line
> is the single character null \x00 showing up in some editors e.g. nano as
>  ^@
> This does not prevent the script from running to a successful conclusion.
> Or not until recently. Now the script fails with
> /home/user/bin/file.old.sh: cannot execute binary file
> Q1 - was bash recently updated? Would this explain the changed behaviour?
> Q2 - if so, is this newly introduced "glitch" known and presumably intended? 
> Or
> an unintended consequence that will be retracted in a later update? 
> I then altered the first line to
> #! /bin/dash
> whilst retaining the null character at line 2 and subsequent content also 
> unaltered..
> The altered script file.new.sh runs as previously to a successful conclusion.
> Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role and 
> reach of dash.
> Should the edit (dash replacing bash/sh) be incorporated elsewhere or would 
> this be a
> bad idea (and retained only locally in what is indeed an eccentric and 
> one-off context)?

Dash is smaller and much less feature-rich than Bash.  Whether Dash is a
suitable replacement for Bash depends on how much (if at all) you're
relying on Bash-specific functions.  For very simple scripts, the only
difference is likely that Dash will be very slightly faster, but working
out whether your script is using any "Bashisms" isn't always a trivial
job.

(I have previously been involved work in migrating scripts between Ksh
and Bash, which is a similar-but-different problem, and there were *a
lot* of surprises in how the two differed.)

Depending on why you want the file to be identified as a binary, and how
that identification is being done, you could move your null byte later
in the file.  In particular, a pattern I've seen several times in Bash
is to have a normal Bash script, finishing with an explicit `exit`,
followed by an actual binary blob; this can be used to create things
like self-extracting bundles, where the binary blob is a tarball and the
script at the top of the file has the instructions for extracting the
tarball.

-- 
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: xlsx2csv package may not be required.

[Adam Dinwoodie via Cygwin-apps]

On Thu, Mar 16, 2023 at 07:58:48PM -0600, Doug Henderson via Cygwin-apps wrote:
> There is a current pure python version of xlsx2csv which runs for many
> versions of Python 2 and Python 3.
> 
> It may not be necessary to provide a package for it in cygwin.
> Instead, users may install the pure python package from PYPI
> https://pypi.org/ using pip or another python package manager.

Installing using pip or similar is an option for the vast majority of
packages that are available through the Cygwin installer; by that logic
it wouldn't make sense to provide most of the Python packages we
provide.  Which wouldn't be an invalid strategy, but it would be a very
big change in how we handle things!

I think the advantage of using the Cygwin packages is a better
likelihood of packages actually being compatible with Cygwin, rather
than having some weird and unpredictable package dependency issue.  A
pure Python xlsx2csv is very unlikely to be affected by that sort of
issue, but providing it as a Cygwin package means users shouldn't need
to even think about whether the package is a pure Python package or not.

Re: python2 removal

[Adam Dinwoodie via Cygwin-apps]

On Sat, 25 Feb 2023 at 16:23, Jon Turney via Cygwin-apps wrote:
> On 16/01/2023 12:49, Jon Turney via Cygwin-apps wrote:
> > On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote:
> > [...]
> >> Python 2.7 is the last python2 version, which was sunsetted on January
> >> 1, 2020.
> > [...]
> >> 2) Looking for packages whose names don't start with 'python', but
> >> where the current version installs something into
> >> /usr/lib/python2.7/site-packages/ and/or into /usr/bin/ with a shebang
> >> containing 'python2', the following packages appear to need rebuilding
> >> for python3:
> >
> > Hi maintainers,
> >
> > Please consider rebuilding your packages listed below for python3.
> >
> > If you are no longer interested in being a maintainer for these (or all
> > of your) Cygwin packages, please let us know, so we can update our
> > records and stop bothering you about them!
> >
> >> package source package maintainer
> >>
> >> bzrJari Aalto
> >> cfget  Jari Aalto
> >> codeville  Jari Aalto
> >> getmailJari Aalto
> >> offlineimapJari Aalto
> >> tailor Jari Aalto
> >> urlgrabber Jari Aalto
> >>
>
> Hi Jari,
>
> In the absence of any response, I have assumed these are all orphaned.
>
> If that's not what you wanted to happen, please let me know.
>
>  From a brief survey, only offlineimap and urlgrabber (which should
> probably be named python-urlgrabber, since it contains a python module)
> seem to be actively maintained enough to support python3.
>
> So I will probably remove the others, and consider if it's possible and
> worthwhile to update those.
>
> (I also noted that breezy appears to be the python3 replacement for bzr
> and getmail6 appears to be the python3 replacement for getmail.)

I'm happy to adopt both of these. I'll give Jari a little while to
reclaim them first, not least as I'm not going to have the time to
spend on packaging these for at least a week or so, but if Jari (or
anyone else) doesn't claim them first, I'll send an ITA once I've
checked I can get the packaging to work.

Re: Python 3 versions

[Adam Dinwoodie via Cygwin]

On Fri, 10 Feb 2023 at 18:46, Jose Isaias Cabrera via Cygwin wrote:
> Greetings.
>
> I am going to start a project using python, but I need to be able to run some 
> of the python3 libraries. When I use setup to install python, there are a 
> bunch of python* versions:
> python2*
> python3
> python36*
> ...
> python39*
>
> I know that python2 is, probably, on its way out.

Correct. Python2 has been completely unsupported by the Python project
for over three years:
https://devguide.python.org/developer-workflow/development-cycle/index.html#end-of-life-branches

> But, why so many choices for versions of python?

Because some Python-based programs need a specific version. If you're
starting out a new project and don't have a specific version, you can
probably use the latest version available, but that's not always the
case.

> One more question, if I install python3, does that mean that I can use all of 
> those python3x libraries? In other words, can I use the libraries of 
> python37* or python38* or python39? Or are these specific to those versions? 
> Confusing, it is. Thanks.

Some Python libraries will work with any 3.x Python version. Most will
only work with a specific version. You definitely won't be able to
use, say, the python37-requests package with a python39 installation.

The "python3" package isn't a real package; it just means "the latest
package of Python3 available". Right now, that means Python 3.9, but I
expect Python 3.10 and 3.11 will appear at some point as well.

HTH

Adam

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

[ANNOUNCEMENT] Updated: AsciiDoc v10.2.0-1

[Adam Dinwoodie via Cygwin]

asciidoc v10.2.0-1 has been uploaded to the Cygwin distribution servers,
and should be coming soon to a mirror near you.

Quoting the upstream project description at
https://asciidoc-py.github.io

> AsciiDoc.py is a legacy processor for this syntax, handling an older
> rendition of AsciiDoc. As such, this will not properly handle the
> current AsciiDoc specification. It is suggested that unless you
> specifically require the AsciiDoc.py toolchain, you should find a
> processor that handles the modern AsciiDoc syntax.

(Currently I believe this package is the only AsciiDoc processor
available as a Cygwin package.)

This is an update to the latest upstream release.  For the full
changelog, please see https://asciidoc-py.github.io/CHANGELOG.html

Enjoy!

Adam

-- 
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: Version string of package

[Adam Dinwoodie via Cygwin-apps]

On Fri, Jan 13, 2023 at 01:22:44PM +, Jon Turney via Cygwin-apps wrote:
> On 13/01/2023 11:52, Takashi Yano via Cygwin-apps wrote:
> > Hi,
> > 
> > Is it allowed to include '-' in version string (e.g. '20230113-stable')?
> > I'm asking because mksetupini warns:
> > 
> > mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version
> > 
> > though it works as expected.
> 
> Short answer:
> 
> It's a bug that this isn't a fatal error.  Please don't do it!
> 
> Long answer:
> 
> Package naming in Cygwin has a long and tangled history. This isn't
> explicitly precluded by the rules at [1], but probably should be.
> 
> (Fedora, which we generally follow for packaging rules, now doesn't allow
> '-' in versions, just digits, letters and '.')
> 
> We need to be able to unambiguously separate a NVR string into the package
> name, version and release.
> 
> Underscores are allowed in package names, so the simple approach of
> splitting on the rightmost two hyphens would work, if we don't allow
> exceptions like this.
> 
> (We can get it right in this case, because we have a piece of extra
> information: the directory the package is in, which happens to always be
> named N in the current scheme of things, but we might want to change that)
> 
> [1] https://cygwin.com/packaging-package-files.html

I just spotted [0] in the Cygport documentation, and was reminded of
this conversation.  According to that, the version string is explicitly
allowed to include hyphens!  I suspect that's fundamentally a
documentanion bug these days, and should just be expunged...

[0]: https://cygwin.github.io/cygport/syntax_cygpart.html#VERSION

Quick patch below; I can submit this properly as a GitHub PR or with
`git send-email` or otherwise if that'd be useful...

diff --git a/lib/syntax.cygpart b/lib/syntax.cygpart
index 4a400a71..6b992031 100644
--- a/lib/syntax.cygpart
+++ b/lib/syntax.cygpart
@@ -316,7 +316,7 @@ __target_is_embedded() {
 #v* Globals/VERSION
 #  DESCRIPTION
 #  The upstream package version number.  PV must begin with a digit 0-9, and
-#  subsequent characters can be a digit, letter, dot, hyphen, or underscore.
+#  subsequent characters can be a digit, letter, dot, or underscore.
 #
 #v* Globals/RELEASE
 #  DESCRIPTION

[ANNOUNCEMENT] New package: inih v56-1

[Adam Dinwoodie via Cygwin]

inih v56-1 has been uploaded to the Cygwin distribution servers, and
should be coming soon to a mirror near you.

>From the upstream description[0]:

> inih (INI Not Invented Here) is a simple .INI file parser written in
> C.  It's only a couple of pages of code, and it was designed to be
> small and simple, so it's good for embedded systems.  It's also more
> or less compatible with Python's ConfigParser style of .INI files,
> including RFC 822-style multi-line syntax and `name: value` entries.

[0]: https://github.com/benhoyt/inih

This includes the following packages:

- libinih0
- libinih-devel
- inih-debuginfo

Thanks to Lemures Lemniscati and Jon Turney for their help getting this
neatly packaged.

Enjoy!

Adam

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

Re: [ITP] libinih

[Adam Dinwoodie via Cygwin-apps]

On Fri, Jan 13, 2023 at 02:27:46PM +, Jon Turney wrote:
> On 11/01/2023 23:16, Adam Dinwoodie via Cygwin-apps wrote:
> > On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote:
> > > On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote:
> > > > As requested at [0], I've offered to package libinih for Cygwin.  It has
> > > > a BSD license[1] and is already packaged for a bunch of *nix distros,
> > > > including Fedora, Debian and Arch[2].
> > > > 
> [...]
> > > This looks good, except...
> > > 
> > > I'd ask you to split this into libinih0 and libinih-devel packages.
> [...]
> > 
> > Makes sense!  Here's a rebuild:
> > 
> > https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2
> Thanks.
> 
> I added this to your packages.
> 
> > NAME=libinih
> 
> Since the upstream name is just 'inih', the source package should probably
> be named that also.

Can I double-check how that should work from a package naming
perspective?  I *think* that means we'd have:

- libinih0-$PVR, being the libraries themselves
- libinih0-debuginfo-$PVR, being the debugging symbols for the libraries
- inih-devel-$PVR, being the header, static libraries and pkgconfig files
- inih-$PVR.src, being the source code

Is that right?  In particular, is it right that the debuginfo name
matches the library, while the devel package doesn't?  Or should it only
be the source package that has a different name?

(The build linked above as rc2 has the debuginfo package as
inih-debuginfo, and the devel package as libinih-devel, but on
reflection that doesn't seem quite right to me.  If nothing else, I
think I'd expect to find the debug symbols in a package with the same
name as the package I'm debugging...)

> > libinih0_CONTENTS="\
> >   usr/bin/*.dll\
> >   usr/share/\
> > "
> 
> You probably want to write this glob as '*-0.dll', so that when the
> soversion changes, packaging fails, rather than silently ploughing on to
> contain a libinit0 containing cyginit-1.dll...
> 
> (Or factor out the soversion as variable, or something...)

Done, thank you for the suggestion!

Re: vmstat yields error 'Unable to create system stat structure' on W11x64

[Adam Dinwoodie via Cygwin]

On Sun, 15 Jan 2023 at 22:05, System Administrator via Cygwin wrote:
>
> Hello,
>
> I am trying to migrate my framework to Windows 11 running Cygwin.
> When executing vmstat it returns the following error:
>
> "Unable to create system stat structure”
>
> Using the very same packages (install files) on Windows 10, produces the 
> proper vmstat results (i.e. no error).
> I’ve tried W11 pro and Enterprise - same difference (none.) Windows 11 is 
> running in a VMware VM. W11 is the December version wit the latest updates 
> (as of today).
> The working W10 is running on the same physical hardware, using the same 
> version of VMware, also in a VM.
> Cygwin is the latest version 3.4.3, with the latest props-ng package (4.0.2-1)
>
> Any help (or at least hint) is greatly appreciated.

Can you provide the cygcheck output, per
https://cygwin.com/problems.html? It might be useful to have the
cygcheck output from both the Win10 and Win11 VMs to compare, but the
Win11 VM where things aren't working is going to be the most useful
one there.

It might also be useful to know how you're calling vmstat: are you
doing it from a Cygwin Bash shell within MinTTY, or from a PowerShell
prompt using Windows' console, or something else? And are you running
with Administrator privileges?

-- 
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 about slow access to file information

[Adam Dinwoodie via Cygwin]

On Sat, Jan 14, 2023 at 11:42:58AM +1100, Eliot Moss via Cygwin wrote:
> Dear Cygwin'ers -
> 
> I have a separate drive mounted this way:
> 
> d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
> 
> One thing I use it for is to store backup files.  These tend to be 2 Gb
> chunks, and there can be hundreds of them in the backup directory.  (The drive
> is 5Tb.)  The Windows Disk Management tool describes it as NTFS, Basic Data
> Partition.
> 
> Doing ls (for example) takes a very perceptible numbers of seconds (though
> whatever takes a long time seems to be cached, at least for a while, since a
> second ls soon after is fast).
> 
> Windows Explorer (for example) and CMD do not seem to suffer this delay.
> 
> Any notion as to what is happening and what I might do to ameliorate it?
> 
> If it matters, the drive is removable (an external WD MyPassport hard drive).

I *suspect* this will be an issue with `ls` querying some file
metadata that are relatively slow to get out of an NTFS system, to
provide a similar interface to native *nix systems, where Windows' tools
unsurprisigly care more about the sorts of file properties that Windows
filesystems are better optimised for.

Based on experience, you might find using `ls --color=never` to be
quicker: querying some of the properties that `ls` likes to use for
colouring the output seems to require a bunch of extra queries to the
filesystem.  Failing that, if you have control over the directory
layout, making the structure deeper with fewer objects in each directory
will probably help.

-- 
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: newlib-cygwin.git repository: Switching "master" to "main"

[Adam Dinwoodie via Cygwin]

On Fri, Jan 13, 2023 at 02:23:44PM -0500, Mike Frysinger via Cygwin wrote:
> thanks for doing this!
> -mike

Seconded!  This clearly isn't going to solve racism in a single step,
but making our community that bit more welcoming -- particularly when
the cost of the change is essentially zero -- has to be a positive move.

-- 
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: [ATTN MAINTAINER] tig

[Adam Dinwoodie via Cygwin-apps]

On Fri, Jan 13, 2023 at 06:06:22PM +0100, Libor Ukropec via Cygwin-apps wrote:
> Dne 13.01.2023 v 17:59 Libor Ukropec via Cygwin-apps napsal(a):
> > Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a):
> > 
> > > 
> > > Hi, Thanks for the heads up. I've uploaded new version and added the
> > > *.cygport in my Github repository of tig for possible new maintainer
> > > in the future.
> > > 
> > > The patches deal some fixes in the xmlto(1) of manual pages build.
> > > 
> > > Jari
> > > 
> > Hi Jari,
> > 
> > I updated to the latest tig, but when executing, it complains about
> > missing dependency, but recently I saw many updates to the cygwin
> > packages. Any idea if other package was broken, or tig is missing some
> > dependency in the metadata?
> > 
> > C:/cygwin64/bin/tig.exe: error while loading shared libraries:
> > cygpcreposix-0.dll: cannot open shared object file: No such file or
> > directory
> > 
> > Manual installation of "libpcreposix0 8.45-1" seems resolving the problem.
> > 
> > Libor
> > 
> Problem lies somewhere in the compile process?
> here is my output for tig I compiled few weeks ago:
> 
> $ ldd ./ttiigg/tig-2.5.4-1.x86_64/build/src/tig.exe
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
> (0x7ffe8516)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
> (0x7ffe839e)
> cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d)
> cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3)
> 
> 
> and here is from the installed:
> $ ldd /usr/bin/tig.exe
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
> (0x7ffe8516)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll 
> (0x7ffe839e)
> cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d)
> cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d)
> cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3fd63)
> cygreadline7.dll => /usr/bin/cygreadline7.dll (0x579cd)
> cygpcreposix-0.dll => /usr/bin/cygpcreposix-0.dll (0x520b4)

I strongly suspect that, like git, tig will use libpcre if it was
present at compile time, and won't if it isn't.  Typically I'd expect
distribution builds to include libpcre support for this sort of thing.
That would mean Jari's compilation was correct, but the .hint files
didn't correctly list the necessary dependencies.

Jari, your email mentioned a possible new maintainer; are you intending
to hand over responsibility, or do you just mean for a hypothetical
future maintainer at some point in the future?

Re: [ITP] libinih

[Adam Dinwoodie via Cygwin-apps]

On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote:
> On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote:
> > As requested at [0], I've offered to package libinih for Cygwin.  It has
> > a BSD license[1] and is already packaged for a bunch of *nix distros,
> > including Fedora, Debian and Arch[2].
> > 
> > [0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html
> > [1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt
> > [2]: https://repology.org/project/inih/versions
> > 
> > Provisional release packages are available at [3], and I've copied the
> > main .hint file below for reference.
> > 
> > [3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1
> 
> Thanks.
> 
> This looks good, except...
> 
> > I've not maintained this sort of library before; I've defaulted to
> > including everything in a single package, but Lem suggested splitting
> > out a -devel package to contain the header files[4][5].  I don't think
> > it makes much difference either way -- the monolithic package is only
> > ~16 KB compressed -- and it seems plenty of other Cygwin packages have
> > their header files in the same package as the runtime package, but I'd
> > appreciate thoughts from everyone else on what's thought to be best
> > practice these days...
> 
> I'd ask you to split this into libinih0 and libinih-devel packages.
> 
> Firstly, I don't want to get into making judgements about what the size
> threshold is for a package to be "small enough to not bother".
> 
> Secondly, I think, if there's ever a soversion change (i.e. cyginih-0.dll
> becomes cyginih-1.dll), structuring it as a single package makes it
> impossible to parallel install the old and new soversions together, thus
> breaking any other packages linked with the old soversion until they are
> rebuilt.

Makes sense!  Here's a rebuild:

https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2

> If you're aware of other packages "done wrong" based on that understanding,
> I guess that's something that needs looking into...

Ah, I think I was thinking about this backwards.  I'd thought that, for
example, make is a problem, because it's not marked as a "*-devel"
package, but it puts a header file in /usr/include as well as all the
files needed by mere users of make.[0]

[0]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmake%2Fmake-4.4-1

It sounds like that's not a problem at all, though: make doesn't provide
any libraries to link against.

What might be more of a problem is something like file, which does
provide a DLL for other packages to link against, and which isn't
separated out into a "lib*" package.[1]

[1]: 
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Ffile%2Ffile-5.41-2=usr%2Fbin%2F.%2A%5C.dll

(But maybe there's something about file that means we can be confident
it'll never have an soversion change?  Almost all my practical
experience with wrangling library linking is with software appliances
that ignore the issue by replacing all the binaries in an effectively-
atomic operation, so I am well out of my areas of expertise here!)

Re: Maximizing windows during "git log" locks mintty both in "Git for Windows" and cygwin 3.4.3

[Adam Dinwoodie via Cygwin]

On Tue, Jan 10, 2023 at 04:50:26PM +0100, Francesco Pretto via Cygwin wrote:
> Hello,
> 
> I want to report a bug in mintty that is mostly suffered by "Git for
> Windows" users, which in version 2.39.0.2 they are using mintty 3.6.1.
> The bug has been reported in this "Git for Windows" issue[1].
> Basically maximizing the mintty window during a "git log" session
> locks the tty session and the window must be quit/killed. I can
> reproduce within a vanilla cygwin mintty 3.6.3 session, which is
> present in the latest cygwin 3.4.3, using the same "Git for Windows"
> git binary. To reproduce;
> 
> - Open a cygwin mintty window, keep it **default** size, don't maximize here;
> - Go to a git repository directory;
> - Enter "git log" (I'm using the git binary from "Git for Windows",
> location "/cygdrive/c/Program Files/Git/cmd/git";
> - Maximize the window;
> - Try to exit "git log" by pressing "q" -> lock!

I've tried this, as described, using both Cygwin's git and MinTTY, and
using the Git for Windows versions, and both work just fine for me.
However...

> There was some debate of who was supposed to report the issue to this
> ML. Please, ask for more details "Git for Windows" maintainers, if you
> need, either by contacting them here/privately or writing to their
> Github issue.
> 
> Regards,
> Francesco Pretto
> 
> [1] https://github.com/git-for-windows/git/issues/4060

...this is the same issue on GitHub as was reported at [0], however
in that email thread the problem occurred only when using the Windows
terminal emulators, calling git or less from within a PowerShell or cmd
window, *not* when using MinTTY.  I believe that's fixed in an upcoming
Cygwin release, per [1], although I don't know when that release will
happen, or how long it will take downstream projects like Git for
Windows to pick it up.

[0]: https://cygwin.com/pipermail/cygwin/2022-December/252737.html
[1]: https://cygwin.com/pipermail/cygwin/2022-December/252745.html

I'll put a comment on the Git for Windows issue now, more-or-less
duplicating the above.

Adam

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

[ITP] libinih

[Adam Dinwoodie via Cygwin-apps]

As requested at [0], I've offered to package libinih for Cygwin.  It has
a BSD license[1] and is already packaged for a bunch of *nix distros,
including Fedora, Debian and Arch[2].

[0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html
[1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt
[2]: https://repology.org/project/inih/versions

Provisional release packages are available at [3], and I've copied the
main .hint file below for reference.

[3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1

~~~
category: Libs
requires: cygwin libgcc1 libstdc++6
sdesc: "Simple .ini file parser"
ldesc: "inih (INI Not Invented Here) is a simple .INI file parser written in C"
~~~

I've not maintained this sort of library before; I've defaulted to
including everything in a single package, but Lem suggested splitting
out a -devel package to contain the header files[4][5].  I don't think
it makes much difference either way -- the monolithic package is only
~16 KB compressed -- and it seems plenty of other Cygwin packages have
their header files in the same package as the runtime package, but I'd
appreciate thoughts from everyone else on what's thought to be best
practice these days...

[4]: https://github.com/me-and/Cygwin-inih/pull/1
[5]: https://cygwin.com/pipermail/cygwin/2023-January/252791.html

Cheers,

Adam

Re: Package request libinih & libinih-devel

[Adam Dinwoodie via Cygwin]

On Thu, 5 Jan 2023 at 12:32, miloskomarcevic--- wrote:
>
> Please package https://github.com/benhoyt/inih as it will be a new dependency 
> for exiv2
> Thanks, and best regards,
> Milos & the Exiv2 team

Hi Milos,

I've just attempted to package this for Cygwin.  Are you able to test
the packaging?  The below command, run from a Cygwin Bash shell and
assuming you have all the relevant dependencies already installed,
should install the test package.

curl -L 
https://github.com/me-and/Cygwin-inih/releases/download/v56-1/libinih-56-1.tar.xz
 | tar -xJC/

The test scripts seem to pass, but I'm not familiar with the library so
I'm not able to test it's actually usable as packaged.

If this works, I'm happy to submit this for packaging for Cygwin. If
not, it'll need someone with more time and energy; I can look after a
package that builds simply and straightforwardly, but I don't currently
have the bandwidth to look after something more complex.

Adam

-- 
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: Resizing window while showing git log locks up Command Line

[Adam Dinwoodie via Cygwin]

On Wed, 21 Dec 2022 at 16:08, Gregory Mason via Cygwin wrote:
>
> Hello Cygwin volunteers,
>
> I was asked to forward this bug report from the git-for-windows bug report: 
> https://github.com/git-for-windows/git/issues/4060
> Original bug report from garretwilson
>
> > Find a Git repository with a long commit history.
> > Enter `git log`
> > Git will show the log history and wait for you to page through the history 
> > or hit q to exit.
> > Press Win+Left-Arrow to snap the window to the left side of the screen.
> > The window is now hung. Nothing can be typed to get it un-hung. Typing q 
> > does nothing. Typing Ctrl+C does nothing. Typing  does nothing. > 
> > The only way out of this is to close the terminal window and start a new 
> > Command Prompt or PowerShell session.
> >
> > I've reproduced this with Command Line and with PowerShell 7.2.6.
>
> I am also experiencing this issue with the following setup:
> CYGWIN_NT-10.0-19044 version 3.4.3-1.x86_64 (runneradmin@fv-az479-541) (gcc 
> version 11.3.0 (GCC) ) 2022-12-16 12:38 UTC
>
> Windows 10
> Version 21H2
> Installed on?7/?11/?2022
> OS build19044.2251
> Experience  Windows Feature Experience Pack 120.2212.4180.0
>
> If you need further information, please let me know.

This looks like it's an issue with less, which will be the pager that
Git is using. I've just verified I can reproduce it by running
`C:\cygwin64\bin\less.exe C:\cygwin64\var\log\setup.log` from within a
PowerShell terminal, then resizing the terminal; it doesn't need to be
a "snap" to trigger the behaviour.

Somewhat to my surprise, `more` and `vim` don't exhibit this behaviour.

-- 
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: Long lines in posts to this mailing list

[Adam Dinwoodie via Cygwin]

On Wed, Dec 14, 2022 at 10:53:47AM +, Fergus Daly via Cygwin wrote:
> What causes long lines without word wrap in posts to this list (such as the 
> immediately preceding
> "gcc v.11.3.0 failing") and how can they be avoided?
> (They are very inconvenient - sorry!)

This is entirely down to your email client.  The Cygwin mailing list
won't be doing anything to change how text is wrapped.  You'll need to
either configure your mail client to properly wrap plain text emails, or
switch to a mail client that has that configuration (or does it sensibly
by default).

Personally, I like Neomutt, but there are *lots* of other options.

-- 
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: [ATTN MAINTAINER] tig

[Adam Dinwoodie via Cygwin-apps]

On Tue, 13 Dec 2022 at 17:16, Libor Ukropec via Cygwin-apps wrote:
>
> Dne 12.12.2022 v 17:32 Adam Dinwoodie via Cygwin-apps napsal(a):
> > On Sun, Dec 11, 2022 at 11:15:35PM +0100, Libor Ukropec via Cygwin-apps 
> > wrote:
> >> Hello Jari,
> >>
> >> cygwin contains "tig" in version 2.4.1 (2019-07-30) and there's already
> >> 2.5.4 (2021) with many bug fixes and improvements available.
> >> Can I kindly ask whether it is possible to update the package?
> >> I do not see a git repository for the tig package, so I attached the 
> >> cygport
> >> file if it can save you some effort (in compare to the following scallywag,
> >> I've added the LICENSE info the script)
> >>
> >> Scallywag report is here: 
> >> https://github.com/cygwin/scallywag/actions/runs/3670966767
> >
> > I believe Jari's repo for the tig Cygwin packaging is on GitHub[0], and
> > it looks like it's using the old pre-Cygport packaging mechanism.  I've
> > not looked through that repo myself (yet, at least) but it looks like
> > there are some patches that imply a naïve build might not work
> > perfectly.  Or those packages might be entirely obsolete...
> I did not look for the GitHub, but the naive compile and run worked with few 
> custom
> actions in the cygport script.
> >
> > [0]: https://github.com/jaalto/cygwin-package--tig
> >
> > FWIW, I'd be happy to at least attempt to add this package to my small
> > Cygwin Git packaging empire, and take responsibility for keeping it up
> > to date going forwards.  But that's only if Jari wants to relinquish
>
> Yes, let's wait for Jari's answer
> > that hat, and even then I think Libor clearly gets first refusal given
> > they've written the new Cygport file.
> >
> Here comes my weak English. Will I be refused by Jari or do you mean that I 
> will refuse
> you because I did the Cygport file?
>
> If the latter, I have no objections you are the maintainer (let's wait for 
> Jari), I just
> wanted to give a helpful hand, not only to rudely ask for the update. And 
> also to play
> more with the cygports and expand my portfolio (I am shy to say `empire`)  :)

Apologies for the idioms! I mean that if Jari wants to stop being the
maintainer, you should be allowed to become the maintainer if you want
to, because you wrote the up-to-date cygport file.

"First refusal" means, essentially, that you get given the chance to
do something before anyone else does. In this case, you'd get the
option to become maintainer, and I would only get the option to do so
if you refused.

[ANNOUNCEMENT] Updated: Git v2.39.0

[Adam Dinwoodie via Cygwin]

Version 2.39.0-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

Key extracts from the changelog:

> UI, Workflows & Features
> 
>
>  * "git grep" learned to expand the sparse-index more lazily and on
>demand in a sparse checkout.
>
>  * After checking out a "branch" that is a symbolic-ref that points at
>another branch, "git symbolic-ref HEAD" reports the underlying
>branch, not the symbolic-ref the user gave checkout as argument.
>The command learned the "--no-recurse" option to stop after
>dereferencing a symbolic-ref only once.
>
>  * "git branch --edit-description @{-1}" is now a way to edit branch
>description of the branch you were on before switching to the
>current branch.
>
>  * "git merge-tree --stdin" is a new way to request a series of merges
>and report the merge results.
>
>  * "git shortlog" learned to group by the "format" string.
>
>  * A new "--include-whitespace" option is added to "git patch-id", and
>existing bugs in the internal patch-id logic that did not match
>what "git patch-id" produces have been corrected.
>
>  * Enable gc.cruftpacks by default for those who opt into
>feature.experimental setting.
>
>  * "git repack" learns to send cruft objects out of the way into
>packfiles outside the repository.
>
>  * 'scalar reconfigure -a' is taught to automatically remove
>scalar.repo entires which no longer exist.
>
>  * Redact headers from cURL's h2h3 module in GIT_CURL_VERBOSE and
>others.
>
>  * 'git maintenance register' is taught to write configuration to an
>arbitrary path, and 'git for-each-repo' is taught to expand tilde
>characters in paths.
>
>  * When creating new notes, the template used to get a stray empty
>newline, which has been removed.
>
>  * "git receive-pack" used to use all the local refs as the boundary for
>checking connectivity of the data "git push" sent, but now it uses
>only the refs that it advertised to the pusher. In a repository with
>the .hideRefs configuration, this reduces the resources needed to
>perform the check.
>
>  * With '--recurse-submodules=on-demand', all submodules are
>recursively pushed.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

-- 
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: [ATTN MAINTAINER] tig

[Adam Dinwoodie via Cygwin-apps]

On Sun, Dec 11, 2022 at 11:15:35PM +0100, Libor Ukropec via Cygwin-apps wrote:
> Hello Jari,
> 
> cygwin contains "tig" in version 2.4.1 (2019-07-30) and there's already
> 2.5.4 (2021) with many bug fixes and improvements available.
> Can I kindly ask whether it is possible to update the package?
> I do not see a git repository for the tig package, so I attached the cygport
> file if it can save you some effort (in compare to the following scallywag,
> I've added the LICENSE info the script)
> 
> Scallywag report is here: 
> https://github.com/cygwin/scallywag/actions/runs/3670966767

I believe Jari's repo for the tig Cygwin packaging is on GitHub[0], and
it looks like it's using the old pre-Cygport packaging mechanism.  I've
not looked through that repo myself (yet, at least) but it looks like
there are some patches that imply a naïve build might not work
perfectly.  Or those packages might be entirely obsolete...

[0]: https://github.com/jaalto/cygwin-package--tig

FWIW, I'd be happy to at least attempt to add this package to my small
Cygwin Git packaging empire, and take responsibility for keeping it up
to date going forwards.  But that's only if Jari wants to relinquish
that hat, and even then I think Libor clearly gets first refusal given
they've written the new Cygport file.

[ANNOUNCEMENT] Updated: Git v2.38.2

[Adam Dinwoodie via Cygwin]

Version 2.38.2-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

Key extracts from the changelog:

> This is to backport various fixes accumulated during the development
> towards Git 2.39, the next feature release.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

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