Re: cygport development
I did not get any response to my last questions, so I hope this patch is
enough.
Any thought about my other arguments?
Federico
On 5/17/20 7:54 PM, Federico Kircheis wrote:
Thank you for the feedback.
This patch is clearly not limited to the protection of data, as it
quotes variables that could in no way contain a space or have anything
to do with file paths.
Could you please point me to which variables are unrelated to files.
AFAIK i quoted files and arguments, which can all contain whitespace.
For example I did quote ${unpack_file_path}, but not ${unpack_cmd}.
As mentioned multiple times, using filenames
ore directories with spaces is asking for trouble, and I have no
interest in trying to support such a case.
The first commit makes sure that no information is lost while processing
file with spaces or other characters that cause globbing. This prevents
writing or modifying the wrong files, which is what happened to me.
The second commit add exit in case `cd` fails, which prevents other
errors afterwards.
Those modification do not add support for path with whitespace, as I was
still unable to compile the software, they did however prevent cygport
to delete unrelated data (or create data in the wrong location).
I'm willing to consider a
*limited* patch that makes sure that cygport doesn't do something it
shouldn't in that case, but that's about it.
Also because if the underlying tool like `make` does not support spaces,
it has no benefit.
The most minimal patch I can imagine is exiting if `cd` fails (just the
second commit).
Would you accept that?
But please also consider my other arguments.
Yaakov
PS:
A "nice" side-effect to quoting most variables that could contain white
space is that static-analyzers like shellcheck will emit less
diagnostic, making it easier to discover potential errors.
>From 9dec371efa2f4f943bdd660618a0e1d91b6cfb4a Mon Sep 17 00:00:00 2001
From: Federico Kircheis
Date: Tue, 2 Jul 2019 21:02:36 +0200
Subject: [PATCH] Exit in case `cd` fails
---
lib/src_fetch.cygpart | 2 +-
lib/src_prep.cygpart | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/src_fetch.cygpart b/lib/src_fetch.cygpart
index a273045..acea3a6 100644
--- a/lib/src_fetch.cygpart
+++ b/lib/src_fetch.cygpart
@@ -156,7 +156,7 @@ __src_fetch() {
done
# the RCS_fetch functions change PWD
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}"
for uri in ${SRC_URI} ${PATCH_URI}
do
diff --git a/lib/src_prep.cygpart b/lib/src_prep.cygpart
index 80ba8d5..fb99bfd 100644
--- a/lib/src_prep.cygpart
+++ b/lib/src_prep.cygpart
@@ -189,7 +189,7 @@ __gpg_verify() {
}
__mkdirs() {
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}";
mkdir -p ${srcdir} ${origsrcdir} ${B} ${D} ${T} ${configdir} ${logdir} ${distdir} ${patchdir} ${spkgdir};
}
@@ -286,7 +286,7 @@ __src_prep() {
local tar_patch;
local n=1;
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}";
__mkdirs;
@@ -345,7 +345,7 @@ __src_prep() {
__gpg_verify ${top}/${src_patchfile} "SOURCE PATCH";
fi
- cd ${origsrcdir};
+ cd ${origsrcdir} || error "Unable to cd to ${origsrcdir}";
for src_pkg in ${_src_orig_pkgs}
do
@@ -377,7 +377,7 @@ __src_prep() {
# cd will fail if not executable (e.g. dot2tex)
chmod +x ${origsrcdir}/${SRC_DIR};
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} || error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
#v* Preparation/DISTCLEANFILES
# DESCRIPTION
@@ -404,7 +404,7 @@ __src_prep() {
if __check_function src_unpack_hook
then
__check_unstable src_unpack_hook;
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} | error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
fi
for src_patch in ${_src_orig_patches}
@@ -446,7 +446,7 @@ __src_prep() {
if __check_function src_patch_hook
then
__check_unstable src_patch_hook;
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} || error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
fi
__step "Preparing working source directory";
@@ -456,7 +456,7 @@ __src_prep() {
mkdir -p ${C};
ln -sfn ${C} ${workdir}/CYGWIN-PATCHES;
- cd ${S};
+ cd ${S} || error "Unable to cd to ${S}";
if [ -f ${top}/${cygwin_patchfile} ]
then
--
2.26.2
Re: Updating glib2.0
On 5/28/2020 7:20 AM, Achim Gratz wrote: 1. It's probably unrealistic to expect someone to adopt all the GNOME components. If such a person existed, I think we would have heard from him/her by now. Ideally that person would have some ties into the upstream development community as well. It might be worth asking there directly if anybody has any points of contact already (I don't). I'm pretty sure there's no one there (or at least no one who works on glib) who understands Cygwin. For years, Yaakov has used a "Cygwin is not win32" patch in his Cygwin build of glib2.0. About a year ago someone noticed this and patched the glib sources in an effort to capture the intent of Yaakov's patch. (They didn't just apply his patch!) They didn't get it quite right, but they made progress, and the corresponding patch needed today is much smaller than the old one. My point here is that whoever made this change had good intentions but is not qualified to be a Cygwin maintainer, even if they wanted to be. And no one else has touched that code. 2. I'm willing to adopt various components on an as-needed basis. For example, since I want to update gimp and it needs an updated glib2.0, I'm willing to adopt the latter and update it to its latest release. I've just started working on it and discovered that it needs an updated gtk-doc, so I'll plan on adopting that too. I think the current way of adopting as needed and then immediately letting it fall into orphaned status again is better than doing nothing, but eventually we'll run into troublöe with that model. If I were to adopt some of these packages, I would do it with the intention of keeping them up to date. But I'll wait to hear from Yaakov. If he thinks it's better to keep the GNOME components at their current state until someone is willing to adopt all of them, I'll go along with that. Ken
Re: Update of packages by non-maintainer
Thank for reply, and sorry for late response I had some troubles to upgrade anthy port to version 0.4 from Debian. But I managed to success to build new anthy packages and am now testing them with my daily use. From: Marco Atzeri Subject: Re: Update of packages by non-maintainer Date: Thu, 21 May 2020 23:11:34 +0200 >> currently we have no solution. There were in the past discussion >> to overcome such problem but they are not yet implemented. > > I was wrong, the mechanism was created > > https://cygwin.com/packaging-hint-files.html#override.hint In my case following line should be put as override.hint. Right? -- curr: 0.4-1 -- And is there any way to generate override.hint from .cygport file with cygport command? --- Yasuhiro KIMURA
Re: Seems like a bug with mkfifo -m
you say 'ls' is a problem source. Then i have to be more specific with the problem to not miss any other possible problems around it. My use case is this: I have an ssh rsa keys dynamically loaded in environment variables. Those variables then expaned and piped to the named pipe and then the pipe instantly read by ssh-add. I know there could be other ways to ssh-add from environment, but its just our specifics. So the actual commands looks like this: $ mkfifo -m 0600 somefifo # The KEY contains ssh rsa private key data $ echo $KEY > somefifo | ssh-add somefifo @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Permissions 0644 for 'somefifo' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue with lyx and recent dll
On 28.05.2020 20:25, Enrico Forestieri wrote: On Thu, May 28, 2020 at 08:09:49PM +0200, Marco Atzeri via Cygwin wrote: after installing also another package texlive-collection-pstricks I was able to have an instant preview can you check if the test 2.3.4.2-2 solve the issue also for you ? Than I can promote it to stable Yes, that did it! I am curious to know how you compiled it, because I see the same strange behavior when compiling lyx from source. --enable-qt5 PYTHON="python3" Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue with lyx and recent dll
On Thu, May 28, 2020 at 08:09:49PM +0200, Marco Atzeri via Cygwin wrote: > > after installing also another package > texlive-collection-pstricks > > I was able to have an instant preview > > can you check if the test 2.3.4.2-2 > solve the issue also for you ? > Than I can promote it to stable Yes, that did it! I am curious to know how you compiled it, because I see the same strange behavior when compiling lyx from source. -- Enrico -- 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: Seems like a bug with mkfifo -m
On May 28 13:39, Ken Brown via Cygwin wrote: > On 5/28/2020 1:31 PM, yoshi kakbudto wrote: > > you say 'ls' is a problem source. Then i have to be more specific with the > > problem to not miss any other possible problems around it. > > > > My use case is this: I have an ssh rsa keys dynamically loaded in > > environment variables. > > Those variables then expaned and piped to the named pipe and then the pipe > > instantly read by ssh-add. > > I know there could be other ways to ssh-add from environment, but its just > > our specifics. > > So the actual commands looks like this: > > > > $ mkfifo -m 0600 somefifo > > > > # The KEY contains ssh rsa private key data > > $ echo $KEY > somefifo | ssh-add somefifo > > > > > > @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ > > > > Permissions 0644 for 'somefifo' are too open. > > It is required that your private key files are NOT accessible by others. > > This private key will be ignored. > > Sorry, I shouldn't have said the problem was with ls. The problem was > actually with stat, and it's fixed now. You should be able to test it the > next time Corinna creates a snapshot. Done. Try the latest snapshot from https://cygwin.com/snapshots/ Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue with lyx and recent dll
On Thu, May 28, 2020 at 07:35:12PM +0200, Marco Atzeri via Cygwin wrote: > On 28.05.2020 12:50, Enrico Forestieri wrote: > > Hi, > > > > when activating instant preview in Tools>Preferences>Display, one can > > preview a latex snippet in the lyx work area by inserting it in a > > preview inset (Insert>Preview). > > > > However, since version 3.1.0 it does not work anymore, in the sense > > that the preview is not generated. As this feature is working correctly > > on all other platforms, investigating a bit evidenced that downgrading > > the dll to version 3.0.7 solves the issue. > > > > I am attaching an example document demonstrating the issue. The latex > > source used for instant preview is generated in the lyx temporary > > directory (/tmp/lyx_tmpdir./) but latex is never run on it > > to generate the images. As lyx launches latex in a forked process, this > > has to be a fork problem, but no error is issued. The forked process > > seems to never run, simply. > > > > > > Testing on 2.3.4.2-2, it seems that the file is processed: > > from lyxpreviewE14071.log > > This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Cygwin) > (preloaded > format=latex 2020.4.22) 28 MAY 2020 19:21 > > > ! LaTeX Error: File `qtree.sty' not found. > > > the file seems in texlive-collection-humanities Thanks for checking. This is weird. I tried it on 2 different computers and it is not processed. I see the lyxpreview*.tex but no lyxpreview*.log. After closing the document I see on the terminal the message "ForkedProcess::kill(0)", meaning that lyx thinks the preview process is still running and tries to kill it. -- Enrico -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue with lyx and recent dll
On 28.05.2020 19:35, Marco Atzeri wrote: On 28.05.2020 12:50, Enrico Forestieri wrote: Hi, when activating instant preview in Tools>Preferences>Display, one can preview a latex snippet in the lyx work area by inserting it in a preview inset (Insert>Preview). However, since version 3.1.0 it does not work anymore, in the sense that the preview is not generated. As this feature is working correctly on all other platforms, investigating a bit evidenced that downgrading the dll to version 3.0.7 solves the issue. I am attaching an example document demonstrating the issue. The latex source used for instant preview is generated in the lyx temporary directory (/tmp/lyx_tmpdir./) but latex is never run on it to generate the images. As lyx launches latex in a forked process, this has to be a fork problem, but no error is issued. The forked process seems to never run, simply. Testing on 2.3.4.2-2, it seems that the file is processed: from lyxpreviewE14071.log This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Cygwin) (preloaded format=latex 2020.4.22) 28 MAY 2020 19:21 ! LaTeX Error: File `qtree.sty' not found. the file seems in texlive-collection-humanities after installing also another package texlive-collection-pstricks I was able to have an instant preview can you check if the test 2.3.4.2-2 solve the issue also for you ? Than I can promote it to stable Regards Marco -- 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: Seems like a bug with mkfifo -m
On 5/28/2020 1:31 PM, yoshi kakbudto wrote: you say 'ls' is a problem source. Then i have to be more specific with the problem to not miss any other possible problems around it. My use case is this: I have an ssh rsa keys dynamically loaded in environment variables. Those variables then expaned and piped to the named pipe and then the pipe instantly read by ssh-add. I know there could be other ways to ssh-add from environment, but its just our specifics. So the actual commands looks like this: $ mkfifo -m 0600 somefifo # The KEY contains ssh rsa private key data $ echo $KEY > somefifo | ssh-add somefifo @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Permissions 0644 for 'somefifo' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Sorry, I shouldn't have said the problem was with ls. The problem was actually with stat, and it's fixed now. You should be able to test it the next time Corinna creates a snapshot. 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: Seems like a bug with mkfifo -m
On 5/28/2020 11:28 AM, Ken Brown via Cygwin wrote: On 5/28/2020 10:52 AM, Corinna Vinschen wrote: On May 28 09:16, Ken Brown via Cygwin wrote: On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote: Hi, all When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions. in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600: cygcheck.exe -V cygcheck (cygwin) 3.1.4 $ umask 0077 $ touch somefile; ls -l somefile -rw--- 1 admin absent 0 may 26 18:15 somefile $ mkfifo -m 0600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo $ chmod 600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo In old-good cygwin 2.x the command works as expected: $ cygcheck.exe -V cygcheck (cygwin) 2.9.0 $ umask 0022 $ mkfifo -m 0600 somefifo; ls -l somefifo prw--- 1 builduser Domain Users 0 May 26 18:21 somefifo Thanks for the report. The problem isn't with mkfifo, it's with the permission information reported by ls. I did a bisection of the Cygwin development repo and found that the regression was introduced by the following commit: commit f36262d56ac78f04de147746ce4a85c6155e4a23 Author: Corinna Vinschen Date: Wed Jan 29 15:14:05 2020 +0100 Cygwin: stat: fix st_mode of fifos I'll take a look if Corinna doesn't get to it first. Not sure what I was thinking at the time. I recall having observed something funny, but the patch was apparently wrong. Just revert it at your discretion, Ken. I remember we had an IRC discussion about it, but I can't remember what the issue was. I'll look a little more closely before reverting. OK, it turned out that part of that patch needed to be reverted. It's done now. 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: Issue with lyx and recent dll
On 28.05.2020 12:50, Enrico Forestieri wrote: Hi, when activating instant preview in Tools>Preferences>Display, one can preview a latex snippet in the lyx work area by inserting it in a preview inset (Insert>Preview). However, since version 3.1.0 it does not work anymore, in the sense that the preview is not generated. As this feature is working correctly on all other platforms, investigating a bit evidenced that downgrading the dll to version 3.0.7 solves the issue. I am attaching an example document demonstrating the issue. The latex source used for instant preview is generated in the lyx temporary directory (/tmp/lyx_tmpdir./) but latex is never run on it to generate the images. As lyx launches latex in a forked process, this has to be a fork problem, but no error is issued. The forked process seems to never run, simply. Testing on 2.3.4.2-2, it seems that the file is processed: from lyxpreviewE14071.log This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Cygwin) (preloaded format=latex 2020.4.22) 28 MAY 2020 19:21 ! LaTeX Error: File `qtree.sty' not found. the file seems in texlive-collection-humanities -- 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: Seems like a bug with mkfifo -m
On 5/28/2020 10:52 AM, Corinna Vinschen wrote: On May 28 09:16, Ken Brown via Cygwin wrote: On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote: Hi, all When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions. in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600: cygcheck.exe -V cygcheck (cygwin) 3.1.4 $ umask 0077 $ touch somefile; ls -l somefile -rw--- 1 admin absent 0 may 26 18:15 somefile $ mkfifo -m 0600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo $ chmod 600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo In old-good cygwin 2.x the command works as expected: $ cygcheck.exe -V cygcheck (cygwin) 2.9.0 $ umask 0022 $ mkfifo -m 0600 somefifo; ls -l somefifo prw--- 1 builduser Domain Users 0 May 26 18:21 somefifo Thanks for the report. The problem isn't with mkfifo, it's with the permission information reported by ls. I did a bisection of the Cygwin development repo and found that the regression was introduced by the following commit: commit f36262d56ac78f04de147746ce4a85c6155e4a23 Author: Corinna Vinschen Date: Wed Jan 29 15:14:05 2020 +0100 Cygwin: stat: fix st_mode of fifos I'll take a look if Corinna doesn't get to it first. Not sure what I was thinking at the time. I recall having observed something funny, but the patch was apparently wrong. Just revert it at your discretion, Ken. I remember we had an IRC discussion about it, but I can't remember what the issue was. I'll look a little more closely before reverting. 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: Seems like a bug with mkfifo -m
On May 28 09:16, Ken Brown via Cygwin wrote: > On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote: > > Hi, all > > > > When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe > > with no user and group permissions. > > > > in the latest cygwin the above command creates device with 0644 > > permissions. And i cant drop it to 0600: > > > > cygcheck.exe -V > > cygcheck (cygwin) 3.1.4 > > > > $ umask 0077 > > $ touch somefile; ls -l somefile > > -rw--- 1 admin absent 0 may 26 18:15 somefile > > > > $ mkfifo -m 0600 somefifo; ls -l somefifo > > prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo > > > > $ chmod 600 somefifo; ls -l somefifo > > prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo > > > > > > > > In old-good cygwin 2.x the command works as expected: > > > > $ cygcheck.exe -V > > cygcheck (cygwin) 2.9.0 > > > > $ umask > > 0022 > > > > $ mkfifo -m 0600 somefifo; ls -l somefifo > > prw--- 1 builduser Domain Users 0 May 26 18:21 somefifo > > Thanks for the report. The problem isn't with mkfifo, it's with the > permission information reported by ls. I did a bisection of the Cygwin > development repo and found that the regression was introduced by the > following commit: > > commit f36262d56ac78f04de147746ce4a85c6155e4a23 > Author: Corinna Vinschen > Date: Wed Jan 29 15:14:05 2020 +0100 > > Cygwin: stat: fix st_mode of fifos > > I'll take a look if Corinna doesn't get to it first. Not sure what I was thinking at the time. I recall having observed something funny, but the patch was apparently wrong. Just revert it at your discretion, Ken. Corinna -- Corinna Vinschen Cygwin Maintainer -- 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: [PATCH] Cygwin: pty: Prevent meaningless ResizePseudoConsole() calls.
On May 28 22:49, Takashi Yano via Cygwin-patches wrote:
> - This patch prevents to call ResizePseudoConsole() unless the pty
> is resized.
> ---
> winsup/cygwin/fhandler_tty.cc | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index f29a2c214..b091765b3 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -2615,18 +2615,18 @@ fhandler_pty_master::ioctl (unsigned int cmd, void
> *arg)
>*(struct winsize *) arg = get_ttyp ()->winsize;
>break;
> case TIOCSWINSZ:
> - /* FIXME: Pseudo console can be accessed via its handle
> - only in the process which created it. What else can we do? */
> - if (get_pseudo_console () && get_ttyp ()->master_pid == myself->pid)
> - {
> - COORD size;
> - size.X = ((struct winsize *) arg)->ws_col;
> - size.Y = ((struct winsize *) arg)->ws_row;
> - ResizePseudoConsole (get_pseudo_console (), size);
> - }
>if (get_ttyp ()->winsize.ws_row != ((struct winsize *) arg)->ws_row
> || get_ttyp ()->winsize.ws_col != ((struct winsize *) arg)->ws_col)
> {
> + /* FIXME: Pseudo console can be accessed via its handle
> + only in the process which created it. What else can we do? */
> + if (get_pseudo_console () && get_ttyp ()->master_pid == myself->pid)
> + {
> + COORD size;
> + size.X = ((struct winsize *) arg)->ws_col;
> + size.Y = ((struct winsize *) arg)->ws_row;
> + ResizePseudoConsole (get_pseudo_console (), size);
> + }
> get_ttyp ()->winsize = *(struct winsize *) arg;
> get_ttyp ()->kill_pgrp (SIGWINCH);
> }
> --
> 2.26.2
Pushed.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
email --verbose returns version info
Shorter version: /bin/email --verbose ... returns version info about the installed binary: email - By Dean Jones; Version 3.2.3-git Longer version: I've been using email(1) since Feb 2019 or so from my office Windows desktop to send e-mail messages from a bash script that are generated from SQL queries using fisql(FreeTDS). Messages are sent through the smtp.office365.com SMTP relay using my staff University credentials. This has "just worked" until it stopped working (due to an unknown authentication error) last Monday (18 May 2020). In trying to diagnose this new problem, I thought "--verbose" might give me some insight into how/where the SMTP transaction is failing when email(1) negotiates a connection with smtp.office365.com. Alas, "--verbose" or "-v" simply causes email(1) to report its version, as noted above, and exit immediately. Having a look at the current github source for email.c, I see that both -V (verbose) and -v (version) options are defined in the source version dated May 17, 2019 (https://github.com/deanproxy/eMail/blob/master/src/email.c). Is there any chance that the Cygwin maintainers could flag email(1) to be updated from the current github source (still marked in VERSION as 3.2.3-git) ? Thank you. -- Gary E. Rafe, PhD | +1 419.699.1181 -- 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: Which rsync version is current?
On Wed, May 27, 2020 at 8:58 PM Marco Atzeri wrote: > specially as 3.1.3 was NOT building under cygwin > https://bugzilla.samba.org/show_bug.cgi?id=14365 ...and that would be why 3.1.3 hasn't been available for Cygwin. Thanks. For the benefit of others: In that bug report, Wayne Davison (rsync maintainer) says that this problem is resolved in the upcoming rsync 3.2.0 release. Thanks Bill -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: pty: Prevent meaningless ResizePseudoConsole() calls.
- This patch prevents to call ResizePseudoConsole() unless the pty
is resized.
---
winsup/cygwin/fhandler_tty.cc | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index f29a2c214..b091765b3 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -2615,18 +2615,18 @@ fhandler_pty_master::ioctl (unsigned int cmd, void *arg)
*(struct winsize *) arg = get_ttyp ()->winsize;
break;
case TIOCSWINSZ:
- /* FIXME: Pseudo console can be accessed via its handle
-only in the process which created it. What else can we do? */
- if (get_pseudo_console () && get_ttyp ()->master_pid == myself->pid)
- {
- COORD size;
- size.X = ((struct winsize *) arg)->ws_col;
- size.Y = ((struct winsize *) arg)->ws_row;
- ResizePseudoConsole (get_pseudo_console (), size);
- }
if (get_ttyp ()->winsize.ws_row != ((struct winsize *) arg)->ws_row
|| get_ttyp ()->winsize.ws_col != ((struct winsize *) arg)->ws_col)
{
+ /* FIXME: Pseudo console can be accessed via its handle
+only in the process which created it. What else can we do? */
+ if (get_pseudo_console () && get_ttyp ()->master_pid == myself->pid)
+ {
+ COORD size;
+ size.X = ((struct winsize *) arg)->ws_col;
+ size.Y = ((struct winsize *) arg)->ws_row;
+ ResizePseudoConsole (get_pseudo_console (), size);
+ }
get_ttyp ()->winsize = *(struct winsize *) arg;
get_ttyp ()->kill_pgrp (SIGWINCH);
}
--
2.26.2
Re: Seems like a bug with mkfifo -m
On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote: Hi, all When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions. in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600: cygcheck.exe -V cygcheck (cygwin) 3.1.4 $ umask 0077 $ touch somefile; ls -l somefile -rw--- 1 admin absent 0 may 26 18:15 somefile $ mkfifo -m 0600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo $ chmod 600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo In old-good cygwin 2.x the command works as expected: $ cygcheck.exe -V cygcheck (cygwin) 2.9.0 $ umask 0022 $ mkfifo -m 0600 somefifo; ls -l somefifo prw--- 1 builduser Domain Users 0 May 26 18:21 somefifo Thanks for the report. The problem isn't with mkfifo, it's with the permission information reported by ls. I did a bisection of the Cygwin development repo and found that the regression was introduced by the following commit: commit f36262d56ac78f04de147746ce4a85c6155e4a23 Author: Corinna Vinschen Date: Wed Jan 29 15:14:05 2020 +0100 Cygwin: stat: fix st_mode of fifos I'll take a look if Corinna doesn't get to it first. 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: Cygwin issue
> Cygwin issue Please use descriptive mail subjects. It's really too bothersome to follow issues otherwise. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin issue
Hi Team, We have used Cygwin 1.7 version for sftp connection and configured for 3 interfaces and connected through Pub keys in production server .This setup is done by 2014. Now we are working on interface migrations and installed 3.1.4 (32bit and 64 bit) also , but both time interface team not able to connect without password. everytime it has asked the password., even though we have placed the pub keys. We have created .ssh folder in Cygwin root folder and inside .ssh , created authorized keys and provided permission (.ssh - 700, authorized keys 640) also but it did not help.we have used windows 2016 64 bit server Currently we have faced two issue. 1.One interface team not able to connect through pub keys asked for password 2. Another interface team faced permission denied error debug1: cipher_init: aes128-ctr from source CPACF, used in non-FIPS mode debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interacti debug1: Next authentication method: publickey debug1: Offering RSA public key: /export/home/CA7/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interacti debug1: No more authentication methods to try. FOTS1373 Permission denied (publickey,password,keyboard-interactive). Ý92.349¨ Connection closed Can you please help for this. Thanks, Bala -- 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 repositories for cygwin packaging - please test
On Wed, May 27, 2020 at 11:27:49PM +0100, Jon Turney wrote: > Currently, many packages will fail to build correctly due to: > > (iii) resource limits imposed by AppVeyor's free service which is used to > perform the actual builds, or Azure Devops may worth a try. s
Re: Updating glib2.0
1. It's probably unrealistic to expect someone to adopt all the GNOME components. If such a person existed, I think we would have heard from him/her by now. Ideally that person would have some ties into the upstream development community as well. It might be worth asking there directly if anybody has any points of contact already (I don't). 2. I'm willing to adopt various components on an as-needed basis. For example, since I want to update gimp and it needs an updated glib2.0, I'm willing to adopt the latter and update it to its latest release. I've just started working on it and discovered that it needs an updated gtk-doc, so I'll plan on adopting that too. I think the current way of adopting as needed and then immediately letting it fall into orphaned status again is better than doing nothing, but eventually we'll run into troublöe with that model. -- Achim. (on the road :-)
Issue with lyx and recent dll
Hi,
when activating instant preview in Tools>Preferences>Display, one can
preview a latex snippet in the lyx work area by inserting it in a
preview inset (Insert>Preview).
However, since version 3.1.0 it does not work anymore, in the sense
that the preview is not generated. As this feature is working correctly
on all other platforms, investigating a bit evidenced that downgrading
the dll to version 3.0.7 solves the issue.
I am attaching an example document demonstrating the issue. The latex
source used for instant preview is generated in the lyx temporary
directory (/tmp/lyx_tmpdir./) but latex is never run on it
to generate the images. As lyx launches latex in a forked process, this
has to be a fork problem, but no error is issued. The forked process
seems to never run, simply.
--
Enrico
#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin /systemlyxdir/examples/
\textclass article
\begin_preamble
\usepackage{etex}
\usepackage[all, knot]{xy}
\xyoption{arc}
\usepackage{qtree}
\usepackage{tipa}
\usepackage{pstricks}
\usepackage{pst-plot}
\usepackage{rotating}
\usepackage{tikz}
\usetikzlibrary{scopes}
\end_preamble
\use_default_options false
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "lmodern" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype false
\use_dash_ligatures false
\graphics default
\default_output_format pdf
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 0
\use_minted 0
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\is_math_indent 0
\math_numbering_side default
\quotes_style english
\dynamic_quotes 0
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict true
\end_header
\begin_body
\begin_layout Section
Introduction
\end_layout
\begin_layout Standard
In order to properly typeset the document and have instant preview working,
the following packages have to be installed:
\end_layout
\begin_layout LyX-Code
xy, qtree, tipa, pstricks, pst-plot, rotating, tikz, pgf, etex
\end_layout
\begin_layout Standard
Due to the use of postscript specials in Section
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:PSTricks"
\end_inset
, only the Postscript or PDF (ps2pdf) output formats will correctly render
the included images.
However, the PDF (Xe\SpecialChar TeX
) output seems to also work, while trying to typeset
the document with
\family typewriter
pdflatex
\family default
or
\family typewriter
pdflualatex
\family default
will generate errors.
\end_layout
\begin_layout Section
Diagrams by XY(-pic)
\end_layout
\begin_layout Standard
Few examples of diagrams were taken from Aaron Landa's archive of xy-pic
examples, see
\begin_inset Flex URL
status collapsed
\begin_layout Plain Layout
https://www.ctan.org/tex-archive/macros/generic/diagrams/xypic/doc/xyguide.pdf
\end_layout
\end_inset
.
\end_layout
\begin_layout Description
Braid
\end_layout
\begin_layout Standard
\begin_inset Preview
\begin_layout Standard
\begin_inset ERT
status collapsed
\begin_layout Plain Layout
\backslash
xy
\end_layout
\begin_layout Plain Layout
(5,10)*{}; (-10,-10)*{} **
\backslash
crv{(6,-2)&(-12,4)}
\end_layout
\begin_layout Plain Layout
\backslash
POS?(.25)*{
\backslash
hole}="x"
\backslash
POS?(.45)*{
\backslash
hole}="y"
\backslash
POS?(.6)*{
\backslash
hole}="z";
\end_layout
\begin_layout Plain Layout
"y"+(0,-1); (2,-10)*{} **
\backslash
crv{}
\backslash
POS?(.2)*{
\backslash
hole}="M";
\end_layout
\begin_layout Plain Layout
(-10,10)*{}; "z" **
\backslash
crv{(-9,0)};
\end_layout
\begin_layout Plain Layout
"z"; "M" **
\backslash
crv{};
\end_layout
\begin_layout Plain Layout
"M"; "x" **
\backslash
crv{(5,0)};
\end_layout
\begin_layout Plain Layout
"x"; "y" **
\backslash
crv{(0,7) & (-5,6)};
\end_layout
\begin_layout Plain Layout
\backslash
endxy
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Description
Knots
\end_layout
opam package should depend on ocaml-compiler-libs
opam assumes that OCaml installed by the "OS" package manager is "complete" (i.e. is the same as "make install" from the OCaml sources), which is a problem when "OS" package managers split upstream ocaml and don't install the ocaml-compiler-libs package by default. Please could either the opam or ocaml package be updated to depend on ocaml-compiler-libs. Fixes https://github.com/ocaml/opam-repository/issues/16457. Debian/Ubuntu and Fedora both also have ocaml-compiler-libs packages, but it's installed by their ocaml package as well. Arch chooses not to do this, having packages like ocaml-findlib expressly depending on ocaml-compilerlibs and so also has its opam package depend on ocaml-compilerlibs. As both an upstream OCaml and opam maintainer, I don't mind which package has the dependency, but if opam is installed, please can any system-installed ocaml definitely be "complete"! Many thanks, David -- 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
Seems like a bug with mkfifo -m
Hi, all When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions. in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600: cygcheck.exe -V cygcheck (cygwin) 3.1.4 $ umask 0077 $ touch somefile; ls -l somefile -rw--- 1 admin absent 0 may 26 18:15 somefile $ mkfifo -m 0600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo $ chmod 600 somefifo; ls -l somefifo prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo In old-good cygwin 2.x the command works as expected: $ cygcheck.exe -V cygcheck (cygwin) 2.9.0 $ umask 0022 $ mkfifo -m 0600 somefifo; ls -l somefifo prw--- 1 builduser Domain Users 0 May 26 18:21 somefifo I've also questioned the topic at https://superuser.com/questions/1555204/cygwin-3-x-mkfifo-m0600-creates-named-pipe-with-0644-permissions best regards, Yoshi kakbudto -- 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: [PATCH] Cygwin: pty: Fix a bug in free_attached_console().
On May 28 12:43, Takashi Yano via Cygwin-patches wrote:
> - After commit 7659ff0f5afd751f42485f2684c799c5f37b0fb9, nohup does
> not work as expected. This patch fixes the issue.
>
> Addresses:
> https://cygwin.com/pipermail/cygwin-developers/2020-May/011885.html
> ---
> winsup/cygwin/fhandler_tty.cc | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index df08dd20a..f29a2c214 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -188,7 +188,10 @@ set_ishybrid_and_switch_to_pcon (HANDLE h)
> inline void
> fhandler_pty_slave::free_attached_console ()
> {
> - if (freeconsole_on_close && get_minor () == pcon_attached_to)
> + bool attached = get_ttyp () ?
> +fhandler_console::get_console_process_id (get_helper_process_id (), true)
> +: (get_minor () == pcon_attached_to);
> + if (freeconsole_on_close && attached)
> {
>FreeConsole ();
>pcon_attached_to = -1;
> --
> 2.26.2
Pushed.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
