Re: Too many level of symbolic links (still have problem with sbmfs network drives)
On Fri, 11 Mar 2022 18:09:30 +0900 Takashi Yano wrote: > On Wed, 9 Mar 2022 09:58:40 +0900 > Takashi Yano wrote: > > On Tue, 8 Mar 2022 19:16:29 -0500 > > Philippe Debanne wrote: > > > Yes OK, you can send me the DLL, I will test it in the next couple of > > > days. > > > > Thanks for your cooperation. I have just sent you cygwin1.dll > > for the test. Please test it and let me know the resulted > > debug messages. > > I received the debug messages and understood what is happening. > I added a workaround for this issue, so could you please test > the cygwin1.dll with the workaround patch, and let me know the > test result? > > I will send you the patched cygwin1.dll shortly. The problem was that GetDosDeviceW() returns unexpected string such as "\Device\Mup\DfsClient\;Z:0003fb89\dfsserver\dfs\linkname" for the mounted UNC path: "\??\UNC\fileserver\share" . This happens when UNC path for DFS is mounted to a drive with drive letter. Therefore, I would like to propose a workaround patch attached. I will appreciate any comments for the patch. -- Takashi Yano 0001-Cygwin-path-Add-fallback-for-DFS-mounted-drive.patch Description: Binary data -- 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 runs my vim slower than Cygwin's vim
On 2022-03-11, Gary Johnson wrote: > On 2022-03-11, Gary Johnson wrote: > > On 2022-03-11, Adam Dinwoodie wrote: > > > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > > > > So, does anyone know why is takes so much longer for bash to run the > > > > vim I built than the official Cygwin vim? More importantly, how do > > > > I fix this? > > > > - Cygwin packages built using Cygport and packaged for release will have > > > the binaries stripped, removing debug symbols and the like and > > > separating them into a different -debug package. That means that the > > > binaries that are loaded for day-to-day use are smaller, and may well > > > mean they're faster too. > > > > The Cygwin vim was built with -ggdb, but I didn't look for strip and > > Cygwin's file doesn't report whether or not binaries are stripped-- > > it probably can't determine that. I'll try stripping mine. > > Just a quick update: I stripped my version and the real time for my > benchmark test dropped from 1.42 s to 0.40 s. Still not as low as > Cygwin's vim (0.12 s), but a substantial improvement. I installed cygport and built vim using Adam's command. It wanted some libraries that I don't have installed, such as for X, which I don't use on Windows, so I modified vim.cygport to not require those. The result ran a little slower than /usr/bin/vim. So to really understand this, I will probably have to install those libraries and run vim.cygport unmodified. However, by changing CFLAGS to remove -g3 and add -O2 for my own build, and by stripping the binary, the startup time for vim to edit a particular file dropped from 8 seconds to 2 seconds, and even using /usr/bin/vim takes 1.4 seconds, so I'm happy for now. Thanks, Adam, for the help. Regards, Gary -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ITA] unifont 14.0.02
I'd like to adopt Unifont which I use as a low resolution fallback for X and MS Windows. Cygwin builds: https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=unifont=succeeded=Brian+Inglis=3925 GNU just released the latest Unifont with utilities and Truetype fonts providing full coverage of the Unicode 14 Basic Multilingual Plane (Unicode Plane 0), plus over 12,600 glyphs for scripts in the Unicode 14 Supplementary Multilingual Plane (Unicode Plane 1), and some ConScript Unicode Registry (CSUR) and Under CSUR (UCSUR) glyphs in Private Use Areas (PUA). Unifont 14.0.02 Released https://lists.gnu.org/archive/html/info-gnu/2022-03/msg2.html -- 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.]
[PATCH cygport] autotools.cygclass: correctly detect Autoconf 2.70+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual version parts and performing numeric comparison.
While we're at it, add a bit more commentary explaining the intent of
the different behaviour over the different Autoconf versions.
---
cygclass/autotools.cygclass | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index cce9be0..2ab5626 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -619,6 +619,8 @@ cygconf() {
local confdir;
local configure;
local confver;
+ local confver_maj;
+ local confver_min;
local f;
local foo_config;
local prefix;
@@ -651,6 +653,8 @@ cygconf() {
configure="${confdir}/configure"
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -678,18 +682,26 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- case "x${confver}" in
- x2.6[0-9]*)
- confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
- ;;
- *)
- confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
- ;;
- esac
+ if [ $confver_maj -ge 2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
3 ]
+ then
+ # Autoconf version supports --docdir and --htmldir, which will
+ # need to be specified manually. It also supports --infodir
+ # and --mandir, but the defaults for those match the FHS.
+ confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
+ else
+ # Autoconf version does not support --docdir or --htmldir, so
+ # don't specify those. Set --infodir and --mandir, as those
+ # have defaults that don't match the FHS.
+ confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
+ fi
- case "x${confver}" in
- x2.[5-9]*) confargs+=" -C" ;;
- esac
+
+ if [ $confver_maj -ge 2 -a $confver_min -ge 50 ] || [ $confver_maj -ge
3 ]
+ then
+ # Always use a cache file; prior to 2.50, this was the default,
+ # thereafter it needs to be requested explicitly.
+ confargs+=" -C"
+ fi
if cross_compiling || inherited toolchain
then
--
2.35.1
Re: [ITP] git-filter-repo 2.34.0
On Tue, Mar 08, 2022 at 03:42:13PM -0500, James Morris wrote: > Hi Adam, > > Thanks for the feedback! > > > - You've patched the shebang from `/usr/bin/env python3` to > > `/usr/bin/python3`. To what end? /usr/bin/env is part of coreutils > > for Cygwin, so there shouldn't be any risk that it won't be installed. > > If someone has their own compiled python3 in /usr/local/bin, they'd > > probably expect that to be used, so I don't think I'd change the > > shebang unless there's some clear and specific reason for doing so. > > I am trying to prevent exactly what you described. git-filter-repo > needs Python >=3.5 to function and we know that `/usr/bin/python3` is > the correct version. Suppose a user installed Python 3.3 at > `/usr/local/bin/python3`, now git-filter-repo will run with the wrong > Python version and most likely break. This is what other distributions > do when they distribute Python scripts and I'm fairly sure Debian > explicitly calls this out in its policy. I just went and did an entirely unscientific check of the scripts I have installed in my Cygwin /bin/ directory. It looks like there's no great consistency, but the majority of scripts there (20 to 9) are calling the relevant Python interpreter directly rather than relying on env. Personally, I'd probably not bother changing things from the upstream package, but if you'd rather do things this way I'm not going to argue :) > > - You're changing the shebang with both a patch file and with a line in > > src_compile; you don't need to do both! I suspect this is an artefact > > of how Cygport packages the source files, but AIUI the canonical way > > to do this sort of patching with Cygport is to drop the sed line from > > your .cygport file and just keep the patch file that gets generated. > > Yeah the patch file was automatically generated when I ran `cygport > all` and I wasn't sure what to do with it. To me it seems silly to > have a patch just to change the shebang line when `sed` works fine. > I'll try removing `sed` to see what happens. Cygport automatically generates patches when it detects a difference between the "src" and "origsrc" directories. You're changing something in "src", so the patch gets generated. The idea is that you can adjust things in the src directory by hand, then when you run cygport it'll automatically store the diffs so you never need to make the same changes again. I suspect the best solution here would be to either (a) drop the sed line and just use a patch file, or (b) make the change in the inst directory as part of the `src_install` function in the .cygport file, i.e. fixing it up as part of doing the "installation" step rather than the "compilation" step. But the sed command is idempotent, so while having both is redundant and a bit odd, I don't think it does any harm. > > - You've set the category as both Devel and Python. IMO (I've not > > checked what the general consensus on this is) this shouldn't be in > > Python: it's a tool that happens to use Python, but I'd expect the > > Python category to be for things that are specifically useful to > > people doing Python dev, so things like libraries that can be usefully > > imported in a Python module, or tools for debugging Python scripts. I > > think this should only be in the Devel category. > > Yeah I initially didn't have it in the Python category, but then I > thought about how other tools like bzr and mercurial are there so it > seemed appropriate. Granted I didn't check if they also provided > Python libraries, but I thought it made sense to put git-filter-repo > in the Python category to maybe warn users that installing it would > pull in Python. I've just checked both bzr and mercurial, and they definitely do provide Python packages. I don't think it's necessary to warn users about dependencies by using categories; setup provides those warnings already when it does dependency resolution. > > - That said, I think ideally you'd also be packaging git_filter_repo.py, > > which does provide a Python library that users can import. At that > > point, this would unambiguously belong in both categories. > > I wasn't sure how to go about this since I didn't know if that would > mean making a bunch of 'python3*-git-filter-repo' packages. > Do you think I should make it importable, remove it from the Python > category, or just leave it as is? My preference here would be to make it importable. That's not going to be something many people are interested in, but there's no reason not to. It can still be a single package -- as bzr and mercurial are -- providing both the main executable and the Python libraries. There's obviously a balance here: monolith packages that add a bunch of dependencies or eat a bunch of disk space / bandwidth, to provide functions many users won't care about, are clearly a bad idea. But the cost of having both the Python module and the executable in this package is going to
[PATCH] Cygwin: fsync: Return EINVAL for special files.
- Unlike linux, fsync() calls FlushFileBuffers() even for special
files. This cause the problem reported in:
https://cygwin.com/pipermail/cygwin/2022-March/251022.html
This patch fixes the issue.
---
winsup/cygwin/fhandler.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index 98d7a3b2d..fc7bf0a0e 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -1750,7 +1750,7 @@ fhandler_base::utimens (const struct timespec *tvp)
int
fhandler_base::fsync ()
{
- if (!get_handle () || nohandle ())
+ if (!get_handle () || nohandle () || pc.isspecial ())
{
set_errno (EINVAL);
return -1;
--
2.35.1
Re: Typed characters are mis-ordered when CPU usage is high
On Thu, 10 Mar 2022 15:17:03 +0200 Orgad Shaneh wrote: > After using it on more scenarios (3.3 branch), I see have strange problems. > > For example, if I run git log -1 and immediately type, my input is > lost until the prompt appears again. > > It doesn't happen with other commands like git status, I'm not sure > why there's a difference. Thanks for the report. This is not a new problem but has been occurring for many years. I looked into this problem and found the cause. This seems to be due to a bug of fsync(). Cygwin's fsync() flushes the console input buffer unlike linux. I will propose a patch for this issue. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Bash runs my vim slower than Cygwin's vim
On 2022-03-11, Gary Johnson wrote: > On 2022-03-11, Adam Dinwoodie wrote: > > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > > So, does anyone know why is takes so much longer for bash to run the > > > vim I built than the official Cygwin vim? More importantly, how do > > > I fix this? > > - Cygwin packages built using Cygport and packaged for release will have > > the binaries stripped, removing debug symbols and the like and > > separating them into a different -debug package. That means that the > > binaries that are loaded for day-to-day use are smaller, and may well > > mean they're faster too. > > The Cygwin vim was built with -ggdb, but I didn't look for strip and > Cygwin's file doesn't report whether or not binaries are stripped-- > it probably can't determine that. I'll try stripping mine. Just a quick update: I stripped my version and the real time for my benchmark test dropped from 1.42 s to 0.40 s. Still not as low as Cygwin's vim (0.12 s), but a substantial improvement. Regards, Gary -- 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
scallywag cygport fails to detect perl script runtime dependencies
Does cygport require perl modules to be installed as build dependencies in order to enable their detection as runtime dependencies for perl scripts in packages? -- 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.]
Re: Bash runs my vim slower than Cygwin's vim
On 2022-03-11, Adam Dinwoodie wrote: > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > I build my own copy of Vim for the Cygwin terminal from the source > > at https://github.com/vim/vim.git. Lately, I've noticed the startup > > time getting slower, so I investigated. One of the things > > I discovered was this difference between the run times of the > > official Cygwin vim package and the vim I built myself. Both are > > version 8.2.4372 and built using the same configuration and compiler > > flags except for some options such as Ruby that I don't have support > > for on my system. > > > > > > > > So, does anyone know why is takes so much longer for bash to run the > > vim I built than the official Cygwin vim? More importantly, how do > > I fix this? > > There are a few differences that jump to mind between the Cygwin > packaged Vim and your locally built Vim. This isn't my area of > expertise by a long shot, but my guess would be it's one of these: Thanks for taking a look. > - Cygwin packages built using Cygport and packaged for release will have > the binaries stripped, removing debug symbols and the like and > separating them into a different -debug package. That means that the > binaries that are loaded for day-to-day use are smaller, and may well > mean they're faster too. The Cygwin vim was built with -ggdb, but I didn't look for strip and Cygwin's file doesn't report whether or not binaries are stripped-- it probably can't determine that. I'll try stripping mine. > - Binaries installed by Cygwin setup will get automatically added to > Cygwin's rebase database. I don't think that would help here -- > problems with rebase normally manifest as fork failures, not just > slowness -- but it's another difference that seemed like it might be > relevant. > > - Cygwin's Vim has a handful of patches. I've just had a quick look and > none of them seem obviously likely to make a significant perf > difference to me, but it was only a quick look and see above re lack > of expertise :) I looked at those, too, and didn't see anything that I thought would cause a performance issue, either. > I suspect the best way to investigate this further will be to try to > narrow down the possible differences between your build and the official > Cygwin build. To do that, I'd probably start with getting the source > for the official Cygwin build, compiling it using Cygport (`cygport > vim.cygport prep compile install package`), then "installing" it as if > it were a regular Cygwin package (`tar -xaf vim-*/dist/vim/vim-*.tar.* > -C /` is close enough for most purposes). I thought about that, too, but didn't know how to do it and hadn't waded into the cygport docs. Thanks for the instructions. If the problem is due to a difference in the way I built my version, it appears from my strace of bash that it happens in the code that precedes vim's main(). I don't know what that would be. Perhaps it does have something to do with preparing the program for debugging. Regards, Gary -- 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] git-filter-repo 2.34.0
On 10/03/2022 20:52, Marco Atzeri wrote: On 08.03.2022 01:11, James Morris wrote: Hello, I'd like to maintain the package for git-filter-repo, a Python script to quickly edit git history. It's MIT licensed, available in both Debian and Fedora, and I've also just recently packaged git-filter-repo up for MSYS2. Cygport package files can be found here: https://drive.google.com/drive/folders/12RXG0804TmR9ZF2STpV7LXqpJMucYAfx?usp=sharing Thanks, James added to the package list. As soon you and Adam are aligned, you can upload. https://cygwin.com/packaging-contributors-guide.html Please also provide a SSH key as explained here: https://cygwin.com/packaging/key.html
Re: Too many level of symbolic links (still have problem with sbmfs network drives)
On Wed, 9 Mar 2022 09:58:40 +0900 Takashi Yano wrote: > On Tue, 8 Mar 2022 19:16:29 -0500 > Philippe Debanne wrote: > > Yes OK, you can send me the DLL, I will test it in the next couple of days. > > Thanks for your cooperation. I have just sent you cygwin1.dll > for the test. Please test it and let me know the resulted > debug messages. I received the debug messages and understood what is happening. I added a workaround for this issue, so could you please test the cygwin1.dll with the workaround patch, and let me know the test result? I will send you the patched cygwin1.dll shortly. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygport configure script argument handling
On Fri, Mar 11, 2022 at 12:38:47AM -0500, Yaakov Selkowitz wrote:
> On Thu, 2022-03-10 at 16:41 +, Adam Dinwoodie wrote:
> > I've fallen down a slight rabbit hole looking at the cygconf function in
> > Cygport's autotools.cygclass. The specific bit of code that's causing
> > me consternation is thus:
> >
> > case "x${confver}" in
> > x2.6[0-9]*)
> > confargs+=" --docdir=/usr/share/doc/${PN}
> > --htmldir=/usr/share/doc/${PN}/html"
> > ;;
> > *)
> > confargs+=" --infodir=${prefix}/share/info
> > --mandir=${prefix}/share/man"
> > ;;
> > esac
> >
> > Firstly, I think the glob is incorrect: it looks like it was intended to
> > match files that came from Autoconf versions 2.60 and up -- 2.60 is when
> > Autoconf added the docdir and htmldir arguments -- but it has stopped
> > working as expected: Autoconf released 2.70 in December 2020, and is now
> > up to 2.71. The above code won't match those versions.
>
> Yes, this likely needs to be updated for 2.70+.
Grand, I'll see if I can offer a patch shortly :)
> > Secondly -- and I'm not sure if this is intended or not -- I don't
> > understand why --infodir and --mandir are only defined for versions
> > prior to 2.60 (and, apparently unintentionally, 2.70 onwards). Those
> > are valid both before and after 2.60. My best guess is that the intent
> > was for the first option to fall through to the second, so for 2.60+ all
> > four options would be defined, but that would have required `;&` or
> > `;;&` rather than `;;`.
>
> No. 2.60 included changes for these (and other) directory values:
>
> https://lists.gnu.org/archive/html/autotools-announce/2006-06/msg2.html
>
> docdir and htmldir were added in 2.60, hence we don't want to pass them when
> <=2.59 is detected. infodir and mandir were changed in 2.60, from
> $prefix/{info,man} (which cygport needed to override for FHS compliance) to
> $datarootdir/{info,man}, where the new datarootdir is $prefix/share, meaning
> they no longer needed to be overriden by cygport.
Ah! Yes, that makes sense. Thank you for the explanation!
Adam
Re: Bash runs my vim slower than Cygwin's vim
On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > I build my own copy of Vim for the Cygwin terminal from the source > at https://github.com/vim/vim.git. Lately, I've noticed the startup > time getting slower, so I investigated. One of the things > I discovered was this difference between the run times of the > official Cygwin vim package and the vim I built myself. Both are > version 8.2.4372 and built using the same configuration and compiler > flags except for some options such as Ruby that I don't have support > for on my system. > > > > So, does anyone know why is takes so much longer for bash to run the > vim I built than the official Cygwin vim? More importantly, how do > I fix this? There are a few differences that jump to mind between the Cygwin packaged Vim and your locally built Vim. This isn't my area of expertise by a long shot, but my guess would be it's one of these: - Cygwin packages built using Cygport and packaged for release will have the binaries stripped, removing debug symbols and the like and separating them into a different -debug package. That means that the binaries that are loaded for day-to-day use are smaller, and may well mean they're faster too. - Binaries installed by Cygwin setup will get automatically added to Cygwin's rebase database. I don't think that would help here -- problems with rebase normally manifest as fork failures, not just slowness -- but it's another difference that seemed like it might be relevant. - Cygwin's Vim has a handful of patches. I've just had a quick look and none of them seem obviously likely to make a significant perf difference to me, but it was only a quick look and see above re lack of expertise :) I suspect the best way to investigate this further will be to try to narrow down the possible differences between your build and the official Cygwin build. To do that, I'd probably start with getting the source for the official Cygwin build, compiling it using Cygport (`cygport vim.cygport prep compile install package`), then "installing" it as if it were a regular Cygwin package (`tar -xaf vim-*/dist/vim/vim-*.tar.* -C /` is close enough for most purposes). 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
