Re: cat fifo hang [Re: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)]
On 10/17/2021 4:52 PM, Chris Roehrig wrote: Here's a script that pretty reliably hangs cat after some iterations. [...] Thanks! I can reproduce the hang. I'll look into it. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
cat fifo hang [Re: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)]
On Sun Oct 17 2021, at 9:19 AM, Ken Brown via Cygwin wrote:
> On 10/16/2021 1:42 PM, Chris Roehrig wrote:
>> On Mon Sep 27 2021, at 7:26 AM, Ken Brown via Cygwin
>> wrote:
>>> On 9/26/2021 8:57 PM, Chris Roehrig wrote:
I have installed this (completely this time) and have encountered no
issues with it. I'm getting full gigabit speeds with my rsync transfers.
Looks great!
>>>
>>> Thanks for testing.
>> I've encountered a crash that might be related. I had previously been
>> having occasional crashes/hangs of cat.exe over the years, but this is the
>> first time I've ever gotten an error message:
>> cygwin error: 0 [fifo_reader] cat 11398 C:\cygwin\bin\cat.exe: *** fatal
>> error - Can't add a client handler, Win32 error 123
>
> This isn't a crash in the usual sense. It's the Cygwin fifo code issuing a
> fatal error because an attempt to create a new Windows pipe instance failed.
> And it's in code that's been around for a while, so it's not related to the
> new pipe implementation.
>
>> cat here is reading from a fifo created with mkfifo.
>> I've only encountered it once (out of daily runs over the last couple weeks)
>> and don't know how to replicate it. Possibly a race?Looks like my
>> script has tried to mitigate this with a sleep 1 between the mkfifo and the
>> fork: cat < $fifo &
>
> The sleep shouldn't be necessary. If it is, there's a bug in the fifo code.
> Can you remove the sleep and see what happens? It would be great if that
> made it possible to replicate the problem.
Here's a script that pretty reliably hangs cat after some iterations.I
haven't yet gotten a repeat of that error message though.
It runs fine on Ubuntu 20.04 and Mac OS X 10.8.4.
#!/bin/bash
# take arg as number of iterations (default=100)
STEPS="${1-100}"
FIFO_PFX="/tmp/catfifo_"
FIFO_WAIT=0
STEP_WAIT=0
function mysleep() { if [ -n "$1" -a "$1" != "0" ]; then sleep "$1"; fi }
function cleanup(){
rm -f "$FIFO_PFX"*
}
trap cleanup EXIT
printf "Creating $STEPS fifo readers...\n"
for ((i=0; i"$fifo"
printf "FIFO %d\n" "$i" >&3
# close the file descriptor, wait for process to exit and clean up
exec 3>&-
wait $pid
rm -f "$fifo"
mysleep $STEP_WAIT
done
--
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: tzcode, tzdata 2021d
The following packages have been upgraded in the Cygwin distribution: * tzcode2021d * tzdata2021d The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to daylight saving (summer time) rules, UTC offsets, and time zone boundaries. The tzcode package provides the tzselect, zdump, and zic utilities. For more details on changes, please see the announcement or below: https://mm.icann.org/pipermail/tz-announce/2021-October/68.html Release 2021d - 2021-10-15 13:48:18 -0700 Briefly: Fiji suspends DST for the 2021/2022 season. 'zic -r' marks unspecified timestamps with "-00". Changes to future timestamps Fiji will suspend observance of DST for the 2021/2022 season. Assume for now that it will return next year. (Thanks to Jashneel Kumar and P Chan.) Changes to code 'zic -r' now uses "-00" time zone abbreviations for intervals with UT offsets that are unspecified due to -r truncation. This implements a change in draft Internet RFC 8536bis. -- 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: tzcode, tzdata 2021d
The following packages have been upgraded in the Cygwin distribution: * tzcode2021d * tzdata2021d The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to daylight saving (summer time) rules, UTC offsets, and time zone boundaries. The tzcode package provides the tzselect, zdump, and zic utilities. For more details on changes, please see the announcement or below: https://mm.icann.org/pipermail/tz-announce/2021-October/68.html Release 2021d - 2021-10-15 13:48:18 -0700 Briefly: Fiji suspends DST for the 2021/2022 season. 'zic -r' marks unspecified timestamps with "-00". Changes to future timestamps Fiji will suspend observance of DST for the 2021/2022 season. Assume for now that it will return next year. (Thanks to Jashneel Kumar and P Chan.) Changes to code 'zic -r' now uses "-00" time zone abbreviations for intervals with UT offsets that are unspecified due to -r truncation. This implements a change in draft Internet RFC 8536bis.
Windows October Update Patch Could Affect Symlinks
While checking Windows October update patches found a vague reference to
a new Windows update patch affecting symlinks in the article:
https://www.computerworld.com/article/3637013/four-zero-day-exploits-add-urgency-to-octobers-patch-tuesday.html
"On the topic of lesser-used Windows features, the Microsoft NTFS file
system was updated to include a fix for symbolic links (helpful with
UNIX migrations). If you are in the middle of a large UNIX migration,
you may want to pause things a little and test out some large (and
parallel) file transfers before deploying this update."
Could not find anything definite about this patch or its effects or
whether it will create any issues. So this is just a heads up about
potential issues implied by the article. If anyone can find the actual
patch and any docs documenting potential changes or issues that may help.
The article's links to overview and generic articles on NTFS and
symlinks did not help:
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links#security-considerations
pointing to existing:
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior
On my system, that shows:
Elevated > fsutil behavior set symlinkevaluation /? | grep -E "sym|link"
...
symlinkEvaluation {L2L|L2R|R2R|R2L}:{0|1} [...]
...
Sample SymlinkEvaluation command:
"fsutil behavior set symlinkEvaluation L2L:1 L2R:0"
- Will enable local to local symbolic links and disable local to
remote symbolic links. It will not change the state of remote to
remote links or remote to local links.
- This operation takes effect immediately (no reboot required)
...
Elevated > fsutil behavior query symlinkevaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
...
--
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.]
--
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: Apache Fork Errors - Found on Windows Server 2019
On 2021-10-17 09:54, Ken Brown via Cygwin wrote: On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote: Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though. And again, I tried it on three different fresh installs of different Windows operating systems (with no bloatware or BLODA), and all of them had the same issue. I have one other thought. There was a recent packaging change in harfbuzz and freetype2 that introduced a circular dependency between the two: https://cygwin.com/pipermail/cygwin/2021-September/249316.html https://cygwin.com/pipermail/cygwin/2021-September/249317.html Since those are the two DLLs that are causing a problem for you, maybe that circular dependency doesn't work well on Cygwin for some reason. Please try downgrading to the previous versions of harfbuzz and freetype2 and see if that fixes the problem. Is /etc/postinstall/0p_000_autorebase.dash rebase completing successfully after the new installs? Maybe check and/or attach the cygwin install log /var/log/setup.log.full for dependency, install, or postinstall errors, and run $ rebase -is > /var/log/rebase-is.log on one of those systems and attach the log. Is there a patch, update, or GP enabling ASLR on all processes? -- 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.] -- 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: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)
On 10/16/2021 1:42 PM, Chris Roehrig wrote: On Mon Sep 27 2021, at 7:26 AM, Ken Brown via Cygwin wrote: On 9/26/2021 8:57 PM, Chris Roehrig wrote: I have installed this (completely this time) and have encountered no issues with it. I'm getting full gigabit speeds with my rsync transfers. Looks great! Thanks for testing. I've encountered a crash that might be related. I had previously been having occasional crashes/hangs of cat.exe over the years, but this is the first time I've ever gotten an error message: cygwin error: 0 [fifo_reader] cat 11398 C:\cygwin\bin\cat.exe: *** fatal error - Can't add a client handler, Win32 error 123 This isn't a crash in the usual sense. It's the Cygwin fifo code issuing a fatal error because an attempt to create a new Windows pipe instance failed. And it's in code that's been around for a while, so it's not related to the new pipe implementation. cat here is reading from a fifo created with mkfifo. I've only encountered it once (out of daily runs over the last couple weeks) and don't know how to replicate it. Possibly a race?Looks like my script has tried to mitigate this with a sleep 1 between the mkfifo and the fork: cat < $fifo & The sleep shouldn't be necessary. If it is, there's a bug in the fifo code. Can you remove the sleep and see what happens? It would be great if that made it possible to replicate the problem. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Apache Fork Errors - Found on Windows Server 2019
On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote: Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though. And again, I tried it on three different fresh installs of different Windows operating systems (with no bloatware or BLODA), and all of them had the same issue. I have one other thought. There was a recent packaging change in harfbuzz and freetype2 that introduced a circular dependency between the two: https://cygwin.com/pipermail/cygwin/2021-September/249316.html https://cygwin.com/pipermail/cygwin/2021-September/249317.html Since those are the two DLLs that are causing a problem for you, maybe that circular dependency doesn't work well on Cygwin for some reason. Please try downgrading to the previous versions of harfbuzz and freetype2 and see if that fixes the problem. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] jpegoptim
Please ignore this email, it has been sent by accident. On 17/10/2021 15.58, Federico Kircheis wrote: Hello to everyone, I'm interested in becoming a package maintainer for the program jpegoptim. https://www.kokkonen.net/tjko/projects.html and https://github.com/tjko/jpegoptim are the homepages of the project. It would be a new package for the cygwin distribution, but it is already distributed on different systems, like Debian and derivatives (see for example https://packages.debian.org/sid/jpegoptim) Currently there is no Windows port (there has never been one as far as I know), therefore I would like to maintain a cygwin port, since i was able to compile and use the program without any patch. The program is licensed GPL2. Best regards Federico Kircheis
[ITP] jpegoptim
Hello to everyone, I'm interested in becoming a package maintainer for the program jpegoptim. https://www.kokkonen.net/tjko/projects.html and https://github.com/tjko/jpegoptim are the homepages of the project. It would be a new package for the cygwin distribution, but it is already distributed on different systems, like Debian and derivatives (see for example https://packages.debian.org/sid/jpegoptim) Currently there is no Windows port (there has never been one as far as I know), therefore I would like to maintain a cygwin port, since i was able to compile and use the program without any patch. The program is licensed GPL2. Best regards Federico Kircheis
Re: CYGPORT: using WAF build system.
Hello,
in addition to my previous message, I would like to say that I tried
to build the existing old sources of lv2-1.12.0-1.x86_64 package, but
an error is generated.
I attached what happens and I hope that you will find this report useful.
Sincerely.
=
$ cygport lv2.cygport all
>>> Preparing lv2-1.12.0-1.x86_64
>>> Unpacking source lv2-1.12.0.tar.bz2
*** Info: applying patch 1.12.0-cygwin-shlib.patch (-p2):
patching file plugins/eg-amp.lv2/wscript
patching file plugins/eg-fifths.lv2/wscript
patching file plugins/eg-metro.lv2/wscript
patching file plugins/eg-midigate.lv2/wscript
patching file plugins/eg-sampler.lv2/wscript
patching file plugins/eg-scope.lv2/wscript
>>> Preparing working source directory
>>> Compiling lv2-1.12.0-1.x86_64
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 293, in ant_iter
raise StopIteration
StopIteration
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 103, in waf_entry_point
run_commands()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 160, in run_commands
parse_options()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 133, in parse_options
Context.create_context('options').execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Options.py",
line 141, in execute
super(OptionsContext,self).execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 92, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 133, in recurse
user_function(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/wscript",
line 25, in options
opt.load('compiler_c')
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 89, in load
fun(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Tools/compiler_c.py",
line 36, in options
opt.load_special_tools('c_*.py',ban=['c_dumbpreproc.py'])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 296, in load_special_tools
lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in ant_glob
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
RuntimeError: generator raised StopIteration
*** ERROR: waf configure failed
Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis
ha scritto:
>
> On 2021-10-14 04:02, Carlo B. via Cygwin wrote:
> > I would like to make a package with LV2 plugins for CYGWIN.
> > The problem is that those plugins are using the WAF build system and
> > it is not clear to me how to proceed. Do you know if some of the
> > existing packages for CYGWIN are using WAF, so that they could be uses
> > as example for starting?
>
> In connection with other queries, I just came across a few lv2 packages
> already available in Cygwin:
>
> lv2
> lv2core
> lv2-calf
> lv2-devel
> lv2-examples
> lv2-swh
>
> slv2
> libslv2_9
> libslv2-devel
>
> with cygport build control script definitions and patches available
> which use WAF:
>
> https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2.git
> https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2-swh.git
> https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/slv2.git
>
> so you could install cygport and any *lv2*
Re: CYGPORT: using WAF build system.
Hello, thank you very much for the replies. I have successfully compiled lv2, lilv, serd, sord, sratom (but not suil yet) for CYGWIN and I made the packages for building the master branch of Audacity. I also tried to do the same thing for i686 and x86_64, by using provided MinGW-w64 cross compiler, but I'm getting this message: *** ERROR: waf.cygclass does not yet support cross-compiling I hope that somebody may fix this in the future. Sincerely. Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis ha scritto: > > On 2021-10-14 04:02, Carlo B. via Cygwin wrote: > > I would like to make a package with LV2 plugins for CYGWIN. > > The problem is that those plugins are using the WAF build system and > > it is not clear to me how to proceed. Do you know if some of the > > existing packages for CYGWIN are using WAF, so that they could be uses > > as example for starting? > > In connection with other queries, I just came across a few lv2 packages > already available in Cygwin: > > lv2 > lv2core > lv2-calf > lv2-devel > lv2-examples > lv2-swh > > slv2 > libslv2_9 > libslv2-devel > > with cygport build control script definitions and patches available > which use WAF: > > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2-swh.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/slv2.git > > so you could install cygport and any *lv2* package dependencies, clone > these repos or download and untar the current source packages which > contain these files plus upstream tars, and build the current packages > as a proof of concept and way of learning cygport, before trying to > build more current versions. > > The simple approach to running cygport is to change to the directory > containing the .cygport definitions and .patch file(s) or move them to a > working directory (normally named for the source package), then run e.g. > > $ cygport lv2.cygport get prep > > which downloads the upstream (not Cygwin) package sources for the > specified version to a central cache directory, creates a package build > directory, copies or untars sources if required, and (tries to) apply > any patches to the original sources, to give you working sources, which > you can then use to compile and make install-able Cygwin packages for > the current arch. > You can try one of the following examples, depending whether you want to > watch the builds run or review the results later: > > $ cygport lv2.cygport all |& tee lv2-cygport-`arch`-all.log > > $ cygport lv2.cygport all | tee lv2-cygport-`arch`-all.log 2>&1 > > $ cygport lv2.cygport all &> tee lv2-cygport-`arch`-all.log & > >$ cygport lv2.cygport all > tee lv2-cygport-`arch`-all.log 2>&1 & > > Browse the created build subdirectories to see what is produced and > review all detail logs generated during the process. > > After a successful build and package creation, it is always a good idea > to try to run any test suites with: > >$ cygport lv2.cygport check > tee lv2-cygport-`arch`-check.log 2>&1 & > > I use the cygport command check instead of test as test is used > ambiguously by cygport, as it may also refer to test vs stable or > production releases produced by cygport using commands e.g. all-test. > > -- > 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.] -- 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: neomutt-20211015-1
Version 20211015-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20211015. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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: neomutt-20211015-1
Version 20211015-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20211015. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico
Re: Apache Fork Errors - Found on Windows Server 2019
Greetings, OwN-3m-All! > I can't seem to get apache via cygwin to work on Windows Server 2019. My question is tangential to Cygwin: why can't you run native Apache with native PHP? What Cygwin specific is in your needs? > Any idea why this is happening or how to fix it? cygcheck may provide a clue. -- With best regards, Andrey Repin Sunday, October 17, 2021 12:39:14 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
