* [ANNOUNCEMENT] cygwin 3.2.0-1
@ 2021-03-29 17:40 Corinna Vinschen via Cygwin-announce
2021-03-29 18:46 ` Brian Inglis
2021-04-02 14:22 ` Oleksandr Gavenko
0 siblings, 2 replies; 6+ messages in thread
From: Corinna Vinschen via Cygwin-announce @ 2021-03-29 17:40 UTC (permalink / raw)
To: cygwin
The following packages have been uploaded to the Cygwin distribution:
* cygwin-3.2.0-1
* cygwin-devel-3.2.0-1
* cygwin-doc-3.2.0-1
This is a new major release.
What's new:
-----------
- Revamped pseudo console support. Conditionally activating it only when
a non-cygwin application is run.
- New C11 threads API: call_once, cnd_broadcast, cnd_destroy, cnd_init,
cnd_signal, cnd_timedwait, cnd_wait, mtx_destroy, mtx_init, mtx_lock,
mtx_timedlock, mtx_trylock, mtx_unlock, thrd_create, thrd_current,
thrd_detach, thrd_equal, thrd_exit, thrd_join, thrd_sleep, thrd_yield,
tss_create, tss_delete, tss_get, tss_set.
- In cygwin console, new thread which handles special keys/signals such
as Ctrl-Z (VSUSP), Ctrl-\ (VQUIT), Ctrl-S (VSTOP), Ctrl-Q (VSTART) and
SIGWINCH has been introduced. There have been a long standing issue
that these keys/signals are handled only when app calls read() or
select(). Now, these work even if app does not call read() or select().
- fchmodat(2) now has limited support for the AT_SYMLINK_NOFOLLOW flag.
- Cygwin now recognizes native Windows AF_UNIX sockets (as regular
files, not as socket files). This allows tools like 'ls' and 'rm'
to work.
What changed:
-------------
- Allow ~5000 child processes per process on 64 bit, ~1200 child processes
per process on 32 bit. So far, only 256 child processes per process were
supported.
- A few FAQ updates.
- Have tmpfile(3) make use of Win32 FILE_ATTRIBUTE_TEMPORARY via open(2)
flag O_TMPFILE.
Addresses: https://cygwin.com/pipermail/cygwin/2021-January/247304.html
- Utilize Windows 10 1809 FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
flag to allow simpler unlink of files with DOS readonly flags set.
- getdtablesize(3), sysconf(_SC_OPEN_MAX), and
getrlimit(RLIMIT_NOFILE) now return the true limit on the number of
open descriptors, 3200. Previously they returned the current size
of Cygwin's internal file descriptor table, which can grow
dynamically.
- facl(2) now fails with EBADF on a file opened with O_PATH.
- Allow to start Windows Store executables via their "app execution
aliases". Handle these aliases (which are special reparse points)
as symlinks to the actual executables.
Bug Fixes
---------
- Iterate at least 4 times over pthread_key_t destructors per POSIX.
- The pthread_yield declaration in pthread is now visible by default
or when defining _BSD_SOURCE, too.
- Fix SEGV in modfl call.
Addresses: https://cygwin.com/pipermail/cygwin/2020-August/246056.html
- Fix a collision of offical and internally used file flags.
Addresses: https://cygwin.com/pipermail/cygwin/2020-September/246174.html
- Fix assertion failure on an invalid path under /proc/<pid>/fd/.
Addresses: https://cygwin.com/pipermail/cygwin/2020-September/246160.html
- Fix crash on stat(2)'ing /dev/ptmx on 32 bit.
Addresses: https://cygwin.com/pipermail/cygwin/2020-September/246218.html
- Fix return value of sqrtl on negative infinity.
Addresses: https://cygwin.com/pipermail/cygwin/2020-October/246606.html
- Fix a path handling problem if there is a WSL symlink in PATH.
Addresses: https://cygwin.com/pipermail/cygwin/2020-December/246938.html
- Fix a bug in fstatat(2) on 32 bit that could cause it to return garbage.
Addresses: https://cygwin.com/pipermail/cygwin/2021-January/247399.html
- Fix the errno when a path contains .. and the prefix exists but is
not a directory.
Addresses: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00214.html
- Fix the return value when ptsname_r(3) is called with a bad file descriptor
Addresses: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00245.html
- Fix path handling in case the Cygwin installation dir is accessed via
a Windows junction point.
Addresses: https://cygwin.com/pipermail/cygwin-developers/2021-February/012054.html
- Fix potential handle leaks when dup'ing descriptors
Addresses: https://cygwin.com/pipermail/cygwin-developers/2021-February/012041.html
- Fix a bug that could cause fstat(2) to return incorrect results on a FIFO.
- Fix some system calls on AF_LOCAL sockets that are not socket files.
Addresses: https://cygwin.com/pipermail/cygwin-developers/2021-February/012066.html
- Fix access to block devices under /proc/sys.
Addresses: https://sourceware.org/pipermail/cygwin-patches/2020q4/010843.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ANNOUNCEMENT] cygwin 3.2.0-1
2021-03-29 17:40 [ANNOUNCEMENT] cygwin 3.2.0-1 Corinna Vinschen via Cygwin-announce
@ 2021-03-29 18:46 ` Brian Inglis
2021-03-29 18:58 ` Corinna Vinschen
2021-04-02 14:22 ` Oleksandr Gavenko
1 sibling, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2021-03-29 18:46 UTC (permalink / raw)
To: cygwin
On 2021-03-29 11:40, Corinna Vinschen via Cygwin-announce via Cygwin wrote:
> The following packages have been uploaded to the Cygwin distribution:
>
> * cygwin-3.2.0-1
> * cygwin-devel-3.2.0-1
> * cygwin-doc-3.2.0-1
>
> This is a new major release.
> -------------
>
> - Allow ~5000 child processes per process on 64 bit, ~1200 child processes
> per process on 32 bit. So far, only 256 child processes per process were
> supported.
Doesn't cygserver now also need a bump to support up to maybe ~2K/~8K processes
with increased defaults to ~256 process cache, threads to ~256 request, ~16
cleanup?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ANNOUNCEMENT] cygwin 3.2.0-1
2021-03-29 18:46 ` Brian Inglis
@ 2021-03-29 18:58 ` Corinna Vinschen
0 siblings, 0 replies; 6+ messages in thread
From: Corinna Vinschen @ 2021-03-29 18:58 UTC (permalink / raw)
To: cygwin
On Mar 29 12:46, Brian Inglis wrote:
> On 2021-03-29 11:40, Corinna Vinschen via Cygwin-announce via Cygwin wrote:
> > The following packages have been uploaded to the Cygwin distribution:
> >
> > * cygwin-3.2.0-1
> > * cygwin-devel-3.2.0-1
> > * cygwin-doc-3.2.0-1
> >
> > This is a new major release.
>
> > -------------
> >
> > - Allow ~5000 child processes per process on 64 bit, ~1200 child processes
> > per process on 32 bit. So far, only 256 child processes per process were
> > supported.
> Doesn't cygserver now also need a bump to support up to maybe ~2K/~8K
> processes with increased defaults to ~256 process cache, threads to ~256
> request, ~16 cleanup?
PTC for the 3.2.1 release :)
Corinna
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ANNOUNCEMENT] cygwin 3.2.0-1
2021-03-29 17:40 [ANNOUNCEMENT] cygwin 3.2.0-1 Corinna Vinschen via Cygwin-announce
2021-03-29 18:46 ` Brian Inglis
@ 2021-04-02 14:22 ` Oleksandr Gavenko
2021-04-02 18:22 ` Thomas Wolff
1 sibling, 1 reply; 6+ messages in thread
From: Oleksandr Gavenko @ 2021-04-02 14:22 UTC (permalink / raw)
To: cygwin
On 2021-03-29, Corinna Vinschen via Cygwin-announce via Cygwin wrote:
> - Allow to start Windows Store executables via their "app execution
> aliases". Handle these aliases (which are special reparse points)
> as symlinks to the actual executables.
User voice: cool!
# ls -l /cygdrive/c/Users/$USERNAME/AppData/Local/Microsoft/WindowsApps/ | grep '[-]>'
lrwxrwxrwx 1 user user 99 2020-11-26 13:24 Alpine.exe -> /cygdrive/c/Program Files/WindowsApps/36828agowa338.AlpineWSL_1.5.0.0_x64__my43bytk1c4nr/Alpine.exe
lrwxrwxrwx 1 user user 107 2021-02-12 20:52 debian.exe -> /cygdrive/c/Program Files/WindowsApps/TheDebianProject.DebianGNULinux_1.3.0.0_x64__76v4gfsz19hv4/debian.exe
lrwxrwxrwx 1 user user 121 2021-02-25 14:59 ubuntu.exe -> /cygdrive/c/Program Files/WindowsApps/CanonicalGroupLimited.UbuntuonWindows_2004.2021.222.0_x64__79rhkp1fndgsc/ubuntu.exe
WindowsApps is already in PATH (not sure who added) and allows to start WSL
distros from Cygwin!
Before I started debian/alpine via "Win + R" and conhost was used which
doesn't support Shift+Insert (although they added Ctrl+Shift+V to paste).
I use Shift+Ins a lot in Mintty. And Shift+PgUp/PgDown which is absent in
conhost.
> - Revamped pseudo console support. Conditionally activating it only when
> a non-cygwin application is run.
I reread latest mails to see if anyone reported about mintty CPU usage.
I read about a new version and updated and problems seems disappeared but I'm
not sure about who is responsible:
/var/log/setup.log:
2021/04/02 15:56:32 1 install cygwin 3.2.0-1
2021/04/02 15:56:32 2 erase cygwin 3.1.7-1
2021/04/02 15:56:32 15 install mintty 3.4.7-1
2021/04/02 15:56:32 16 erase mintty 3.4.6-1
Basically all mintty processes took about 1-1.5% cpu load. 5 minnty caused
7-10% CPU load (and electrical bills + fan noise) even when terminals were
idling.
Now each idling mintty takes 0.06-.11% CPU load (reported by procexp).
I took stack reports from procexp before updates. There are 2 threads caused
CPU load (first took 0.7% CPU, second 0.5% CPU on average) and the picture
reproduced 100%:
ntoskrnl.exe!KeSynchronizeExecution+0x5b66
ntoskrnl.exe!KeWaitForMutexObject+0x1460
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMutexObject+0x233
ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
ntoskrnl.exe!KeWaitForMutexObject+0x3a29
ntoskrnl.exe!KeWaitForMutexObject+0x1787
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeDelayExecutionThread+0x122
ntoskrnl.exe!SeReleaseSubjectContext+0x21bf
ntoskrnl.exe!setjmpex+0x7c15
ntdll.dll!NtDelayExecution+0x14
KERNELBASE.dll!SleepEx+0x9e
cygwin1.dll!feinitialise+0x5b43a
cygwin1.dll!setprogname+0x3041
cygwin1.dll!setprogname+0x3656
cygwin1.dll!setprogname+0x4126
cygwin1.dll!setprogname+0x41d4
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
ntoskrnl.exe!KeSynchronizeExecution+0x5b66
ntoskrnl.exe!KeWaitForMutexObject+0x1460
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMutexObject+0x233
ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
ntoskrnl.exe!KeWaitForMutexObject+0x3a29
ntoskrnl.exe!KeWaitForMutexObject+0x1787
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMultipleObjects+0x2be
ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0
ntoskrnl.exe!FsRtlCancellableWaitForMultipleObjects+0x229
ntoskrnl.exe!setjmpex+0x7c15
ntdll.dll!NtWaitForMultipleObjects+0x14
KERNELBASE.dll!WaitForMultipleObjectsEx+0xf0
KERNELBASE.dll!WaitForMultipleObjects+0xe
cygwin1.dll!setprogname+0x445c
cygwin1.dll!acl_get_perm+0x4ee0
cygwin1.dll!setprogname+0x3041
cygwin1.dll!setprogname+0x3656
cygwin1.dll!setprogname+0x4126
cygwin1.dll!setprogname+0x41d4
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
With new Cygwin DLL & mintty the picture was changed to a single thread
consuming 0.06-0.11% CPU:
ntoskrnl.exe!KeSynchronizeExecution+0x5b66
ntoskrnl.exe!KeWaitForMutexObject+0x1460
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMutexObject+0x233
ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
ntoskrnl.exe!KeWaitForMutexObject+0x3a29
ntoskrnl.exe!KeWaitForMutexObject+0x1787
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMultipleObjects+0x2be
ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0
ntoskrnl.exe!FsRtlCancellableWaitForMultipleObjects+0x229
ntoskrnl.exe!setjmpex+0x7c15
ntdll.dll!NtWaitForMultipleObjects+0x14
KERNELBASE.dll!WaitForMultipleObjectsEx+0xf0
KERNELBASE.dll!WaitForMultipleObjects+0xe
cygwin1.dll!_assert+0x460c
cygwin1.dll!acl_get_perm+0x52b0
cygwin1.dll!_assert+0x31f1
cygwin1.dll!_assert+0x3806
cygwin1.dll!_assert+0x42d6
cygwin1.dll!_assert+0x4384
KERNEL32.dll!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Next time I try to use real profiler for report, have to get familiar with
good one.
--
http://defun.work/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ANNOUNCEMENT] cygwin 3.2.0-1
2021-04-02 14:22 ` Oleksandr Gavenko
@ 2021-04-02 18:22 ` Thomas Wolff
2021-04-03 13:27 ` Oleksandr Gavenko
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Wolff @ 2021-04-02 18:22 UTC (permalink / raw)
To: cygwin
Am 02.04.2021 um 16:22 schrieb Oleksandr Gavenko via Cygwin:
> On 2021-03-29, Corinna Vinschen via Cygwin-announce via Cygwin wrote:
>
>> - Allow to start Windows Store executables via their "app execution
>> aliases". Handle these aliases (which are special reparse points)
>> as symlinks to the actual executables.
> User voice: cool!
>
> # ls -l /cygdrive/c/Users/$USERNAME/AppData/Local/Microsoft/WindowsApps/ | grep '[-]>'
> lrwxrwxrwx 1 user user 99 2020-11-26 13:24 Alpine.exe -> /cygdrive/c/Program Files/WindowsApps/36828agowa338.AlpineWSL_1.5.0.0_x64__my43bytk1c4nr/Alpine.exe
> lrwxrwxrwx 1 user user 107 2021-02-12 20:52 debian.exe -> /cygdrive/c/Program Files/WindowsApps/TheDebianProject.DebianGNULinux_1.3.0.0_x64__76v4gfsz19hv4/debian.exe
> lrwxrwxrwx 1 user user 121 2021-02-25 14:59 ubuntu.exe -> /cygdrive/c/Program Files/WindowsApps/CanonicalGroupLimited.UbuntuonWindows_2004.2021.222.0_x64__79rhkp1fndgsc/ubuntu.exe
>
> WindowsApps is already in PATH (not sure who added) and allows to start WSL
> distros from Cygwin!
Note that if you do this within mintty, you will lose a subtle part of
the terminal features by the Windows ConPTY terminal emulation enforced
in this case. To avoid that, the wslbridge2 gateway should be used
instead, which is implicitly involved when running mintty with option
--WSL. I guess it would be useful to have wslbridge2 as a cygwin package
in order to support this.
Thomas
>
> Before I started debian/alpine via "Win + R" and conhost was used which
> doesn't support Shift+Insert (although they added Ctrl+Shift+V to paste).
>
> I use Shift+Ins a lot in Mintty. And Shift+PgUp/PgDown which is absent in
> conhost.
>
>> - Revamped pseudo console support. Conditionally activating it only when
>> a non-cygwin application is run.
> I reread latest mails to see if anyone reported about mintty CPU usage.
>
> I read about a new version and updated and problems seems disappeared but I'm
> not sure about who is responsible:
>
> /var/log/setup.log:
>
> 2021/04/02 15:56:32 1 install cygwin 3.2.0-1
> 2021/04/02 15:56:32 2 erase cygwin 3.1.7-1
>
> 2021/04/02 15:56:32 15 install mintty 3.4.7-1
> 2021/04/02 15:56:32 16 erase mintty 3.4.6-1
>
> Basically all mintty processes took about 1-1.5% cpu load. 5 minnty caused
> 7-10% CPU load (and electrical bills + fan noise) even when terminals were
> idling.
>
> Now each idling mintty takes 0.06-.11% CPU load (reported by procexp).
>
> I took stack reports from procexp before updates. There are 2 threads caused
> CPU load (first took 0.7% CPU, second 0.5% CPU on average) and the picture
> reproduced 100%:
>
> ntoskrnl.exe!KeSynchronizeExecution+0x5b66
> ntoskrnl.exe!KeWaitForMutexObject+0x1460
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeWaitForMutexObject+0x233
> ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
> ntoskrnl.exe!KeWaitForMutexObject+0x3a29
> ntoskrnl.exe!KeWaitForMutexObject+0x1787
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeDelayExecutionThread+0x122
> ntoskrnl.exe!SeReleaseSubjectContext+0x21bf
> ntoskrnl.exe!setjmpex+0x7c15
> ntdll.dll!NtDelayExecution+0x14
> KERNELBASE.dll!SleepEx+0x9e
> cygwin1.dll!feinitialise+0x5b43a
> cygwin1.dll!setprogname+0x3041
> cygwin1.dll!setprogname+0x3656
> cygwin1.dll!setprogname+0x4126
> cygwin1.dll!setprogname+0x41d4
> KERNEL32.dll!BaseThreadInitThunk+0x14
> ntdll.dll!RtlUserThreadStart+0x21
>
> ntoskrnl.exe!KeSynchronizeExecution+0x5b66
> ntoskrnl.exe!KeWaitForMutexObject+0x1460
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeWaitForMutexObject+0x233
> ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
> ntoskrnl.exe!KeWaitForMutexObject+0x3a29
> ntoskrnl.exe!KeWaitForMutexObject+0x1787
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeWaitForMultipleObjects+0x2be
> ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0
> ntoskrnl.exe!FsRtlCancellableWaitForMultipleObjects+0x229
> ntoskrnl.exe!setjmpex+0x7c15
> ntdll.dll!NtWaitForMultipleObjects+0x14
> KERNELBASE.dll!WaitForMultipleObjectsEx+0xf0
> KERNELBASE.dll!WaitForMultipleObjects+0xe
> cygwin1.dll!setprogname+0x445c
> cygwin1.dll!acl_get_perm+0x4ee0
> cygwin1.dll!setprogname+0x3041
> cygwin1.dll!setprogname+0x3656
> cygwin1.dll!setprogname+0x4126
> cygwin1.dll!setprogname+0x41d4
> KERNEL32.dll!BaseThreadInitThunk+0x14
> ntdll.dll!RtlUserThreadStart+0x21
>
> With new Cygwin DLL & mintty the picture was changed to a single thread
> consuming 0.06-0.11% CPU:
>
> ntoskrnl.exe!KeSynchronizeExecution+0x5b66
> ntoskrnl.exe!KeWaitForMutexObject+0x1460
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeWaitForMutexObject+0x233
> ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
> ntoskrnl.exe!KeWaitForMutexObject+0x3a29
> ntoskrnl.exe!KeWaitForMutexObject+0x1787
> ntoskrnl.exe!KeWaitForMutexObject+0x98f
> ntoskrnl.exe!KeWaitForMultipleObjects+0x2be
> ntoskrnl.exe!ObWaitForMultipleObjects+0x2f0
> ntoskrnl.exe!FsRtlCancellableWaitForMultipleObjects+0x229
> ntoskrnl.exe!setjmpex+0x7c15
> ntdll.dll!NtWaitForMultipleObjects+0x14
> KERNELBASE.dll!WaitForMultipleObjectsEx+0xf0
> KERNELBASE.dll!WaitForMultipleObjects+0xe
> cygwin1.dll!_assert+0x460c
> cygwin1.dll!acl_get_perm+0x52b0
> cygwin1.dll!_assert+0x31f1
> cygwin1.dll!_assert+0x3806
> cygwin1.dll!_assert+0x42d6
> cygwin1.dll!_assert+0x4384
> KERNEL32.dll!BaseThreadInitThunk+0x14
> ntdll.dll!RtlUserThreadStart+0x21
>
> Next time I try to use real profiler for report, have to get familiar with
> good one.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ANNOUNCEMENT] cygwin 3.2.0-1
2021-04-02 18:22 ` Thomas Wolff
@ 2021-04-03 13:27 ` Oleksandr Gavenko
0 siblings, 0 replies; 6+ messages in thread
From: Oleksandr Gavenko @ 2021-04-03 13:27 UTC (permalink / raw)
To: cygwin
On 2021-04-02, Thomas Wolff wrote:
> Note that if you do this within mintty, you will lose a subtle part of the
> terminal features by the Windows ConPTY terminal emulation enforced in this
> case.
I've just tested Midnight Commander, vim, aptitude, than the same all inside
tmux and the only problem I had was the color schema as I like white
background and apps chose black foreground which is hard to look at because I
made blue pretty dark (resulting in black on dark blue).
I set $TERM to "xterm-256color" in ~/.bashrc unconditionally (so no heuristics
are used by term related code).
> To avoid that, the wslbridge2 gateway should be used instead, which is
> implicitly involved when running mintty with option --WSL. I guess it would
> be useful to have wslbridge2 as a cygwin package in order to support this.
Once I tried to make wslbridge2 to work but so many hassle for unknown for me
gain...
It would be nice to have it integrated into Cygwin transparent to users if it
provides something important (in my case there weren't any blocking issues,
except color schema).
--
http://defun.work/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-03 13:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 17:40 [ANNOUNCEMENT] cygwin 3.2.0-1 Corinna Vinschen via Cygwin-announce
2021-03-29 18:46 ` Brian Inglis
2021-03-29 18:58 ` Corinna Vinschen
2021-04-02 14:22 ` Oleksandr Gavenko
2021-04-02 18:22 ` Thomas Wolff
2021-04-03 13:27 ` Oleksandr Gavenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).