[PATCH] Cygwin: pty: Fix a bug in free_attached_console().
- 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
Re: [ANNOUNCEMENT] Updated: python-wx-3.0.2.0-5
On 27.05.2020 23:58, Massimiliano Alvioli via Cygwin wrote: Hi, Version 3.0.2.0-5 of "python2-wx" has been uploaded. python2-wx is the Python 2 version of the cross-platform GUI toolkit, wxPython. I have a related question - I am stuck with an old version of some software I use (compiled) in Cygwin, GRASS GIS, because the latest version (actually the last two versions) only work with python 3. Is there any chance that some time soon wxPyhton will be made to work with python 3 in Cygwin? Or maybe it's me that doesn't know how to make it work. Massi -- Hi Massi. we are (slowly) working on making Python 3.x (likely 3.8) the next default Python and than we should be able to rebuild all packages for Python3 The main reason of the slow progress is that the old maintainer Yaakov is a skilled professional programmer https://sourceware.org/pipermail/cygwin-apps/2020-March/039877.html while the current maintainer (myself) is only an average amateur programmer (my real life profession is in Power Electronics) that is learning the tricks and difficulties of python packaging https://sourceware.org/pipermail/cygwin-apps/2020-May/040127.html https://sourceware.org/pipermail/cygwin-apps/2020-May/040107.html 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: Which rsync version is current?
On 27.05.2020 22:19, Ken Brown via Cygwin wrote: [Adding the rsync maintainer to the Cc in case he wants to add something.] On 5/27/2020 3:34 PM, Bill Stewart wrote: On Wed, May 27, 2020 at 1:20 PM Andrey Repin wrote: What I am saying is that the Setup program says the installed version is 3.1.3+20200429+gitf7746d0-1. The version number shown by setup indicates that the maintainer built the package from a snapshot of the upstream git repository rather than from a stable release. The maintainer chose this version number, presumably to indicate that the snapshot was made on 2020-04-29 after git commit f7746d0. the main reason to put the date in the version is to assure that subsequent releases from git repository will be considered higher by setup and offered as "New" package Using only the git tag you can not reach the scope these are the latest commits on the Rsync code and we can not say from the tag alone which is the latest $ git log --oneline |head 8809f65b A couple minor tweaks. 5710d2fe Simplify the capabilities array. bcb0a24a Convert NEWS & OLDNEWS into .md files. 96ed96da Fix the parsing of the --version capabilities. 8ad2ca9a Install yodl for the CI builds. 23a37eca Get indent right. 47bae3ab Improve output of capabilities in --version list. dff9dd56 Remove xxhash from capabilities list. 7182508a Fix a couple deb names. cb0fe9e1 Improve CI setup. I see the maintainer have tested his choice of f7746d0 and he saw no reason to pack the older 3.1.3 specially as 3.1.3 was NOT building under cygwin https://bugzilla.samba.org/show_bug.cgi?id=14365 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: diff --horizon-lines=lines
Thanks EM.I did go through the post, I understood the concept/theory, but I am unable to do a practical demo of it. Do you have a sample file set for demo or can you suggest something? On Thu, May 28, 2020 at 8:10 AM Eliot Moss wrote: > > On 5/27/2020 10:27 PM, m@d m0nk via Cygwin wrote: > > Hello All, > > > > I am trying to understand the practical use of "--horizon-lines=lines" > > option in the diff utility. > > > > Can i get some pointers on two sample files which can demonstrate the > > use of --horizon-lines=lines > > > > I understood the theory / definition from the info / man file. > > However, I am unable to reproduce the scenario. > > > > Request some pointers. > > This stackexchange post may give some insight (it did for me): > > https://unix.stackexchange.com/questions/158097/diff-horizon-lines-lines-explained > > Regards - EM -- __| madm0nk |__ th3 sib3rian m0nk -- -- 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: diff --horizon-lines=lines
On 5/27/2020 10:27 PM, m@d m0nk via Cygwin wrote: Hello All, I am trying to understand the practical use of "--horizon-lines=lines" option in the diff utility. Can i get some pointers on two sample files which can demonstrate the use of --horizon-lines=lines I understood the theory / definition from the info / man file. However, I am unable to reproduce the scenario. Request some pointers. This stackexchange post may give some insight (it did for me): https://unix.stackexchange.com/questions/158097/diff-horizon-lines-lines-explained Regards - EM -- 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
diff --horizon-lines=lines
Hello All, I am trying to understand the practical use of "--horizon-lines=lines" option in the diff utility. Can i get some pointers on two sample files which can demonstrate the use of --horizon-lines=lines I understood the theory / definition from the info / man file. However, I am unable to reproduce the scenario. Request some pointers. -- __| madm0nk |__ th3 sib3rian m0nk -- -- 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 04/08/2019 21:08, Jon Turney wrote: To remedy this lack, using the same ssh key you use for sftp package upload, package maintainers can now also push to git repositories, like so: Package maintainers may have noticed that the output from pushing to these git repositories now includes a line like: "remote: scallywag: build nnn queued" This is a *prototype* of a system to automatically build the packages, where the results appear (some time later) at [1] (URL subject to change) [1] https://cygwin.com/cgi-bin2/jobs.cgi Currently, many packages will fail to build correctly due to: (i) missing or insufficient 'BUILD_REQUIRES', (ii) missing prerequisites implied by an 'inherit' (a bug in this system), (iii) resource limits imposed by AppVeyor's free service which is used to perform the actual builds, or (iv) other bugs in this system. At this stage, this is only probably useful for verifying that BUILD_REQUIRES is correct. (Note that a successful build doesn't always mean that you have reproduced your build: You'll need to check the configuration step output and/or dependencies of the produced packages are the same. Consider explicitly enabling the functionality you are expecting in the options to the configure script , if it supports that (e.g. CYGCONF_ARGS, etc.), to avoid it potentially silently turning off in future, if it's requirements change) To allow experimentation without messing up the version history unnecessarily: - All package repositories allow the maintainer(s) to create, push, rewind and delete a branch named 'playground'. - An additional package repository called 'playground' exists, that all maintainers can do anything to.
Re: [ANNOUNCEMENT] Updated: python-wx-3.0.2.0-5
Hi, > Version 3.0.2.0-5 of "python2-wx" has been uploaded. > python2-wx is the Python 2 version of the cross-platform GUI toolkit, > wxPython. I have a related question - I am stuck with an old version of some software I use (compiled) in Cygwin, GRASS GIS, because the latest version (actually the last two versions) only work with python 3. Is there any chance that some time soon wxPyhton will be made to work with python 3 in Cygwin? Or maybe it's me that doesn't know how to make it work. Massi -- 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 2:19 PM Ken Brown wrote: > The latest stable release, 3.1.3, is two years old. I'm sure Jari had good > reasons for wanting to make a more recent version available. Right; except that 3.1.3 is not available for Cygwin (despite its age) - at least, it doesn't appear as an option in the Cygwin Setup tool. Presumably a new version of rsync will be available for Cygwin "real soon now". I'm going to stick with 3.1.2 for now. 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
Re: Help needed with gobject-introspection
On 5/24/2020 11:56 AM, Jon Turney wrote: So, yeah, this is a meson bug, which I will work on (if this command ends up in the build.ninja, it's executed by ninja with 'sh -c', but if it ends up in a pickle, it's executed by meson with execve()) It looks like I've bumped into a variation of this bug. While attempting to build the documentation for the latest glib2.0 release, I got the following: FAILED: docs/reference/gobject/gobject-decl.txt /usr/bin/meson --internal exe --unpickle /home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin/meson-private/meson_exe_meson_1ed2fbe217cac49ae4affd274e0d4a729085a002.dat ['/usr/bin/meson', '--internal', 'gtkdoc', '--sourcedir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3', '--builddir=/home/kbrown/src/cygpackages/glib2.0/glib2.0-2.64.3-1.x86_64/src/glib-2.64.3/x86_64-pc-cygwin', '--subdir=docs/reference/gobject', '--headerdirs=gobject', '--mainfile=gobject-docs.xml', '--modulename=gobject', '-- [...] /docs/reference/gobject/tut_tools.xml', '--cc=gcc', '--ld=gcc', '--cflags=-I@BUILD_ROOT@/gobject -I../gobject -pthread -I@BUILD_ROOT@/. -I../. -I@BUILD_ROOT@/glib -I../glib -I@BUILD_ROOT@/docs/reference/gobject/. -I../docs [...] So @BUILD_ROOT@ didn't get replaced by the build root after pickling and unpickling. Needless to say, this produced errors like: cc1: error: @BUILD_ROOT@/glib: No such file or directory [-Werror=missing-include-dirs] I can give you a precise recipe for reproducing this bug if it would help your debugging. Ken
Re: Which rsync version is current?
[Adding the rsync maintainer to the Cc in case he wants to add something.] On 5/27/2020 3:34 PM, Bill Stewart wrote: On Wed, May 27, 2020 at 1:20 PM Andrey Repin wrote: When I run rsync --version, I see this: rsync version 3.2.0dev protocol version 31 However the Cygwin Setup program says that my rsync is current and is listed as this version: 3.1.3+20200429+gitf7746d0-1 rsync.samba.org says the current version is 3.1.3. So...what's actually the latest? What's the difference between these? Run `which rsync` to see which one is responding to you. 3.2-dev is likely a snapshot from ongoing development branch. `which rsync` outputs /usr/bin/rsync as expected. What I am saying is that the Setup program says the installed version is 3.1.3+20200429+gitf7746d0-1. The version number shown by setup indicates that the maintainer built the package from a snapshot of the upstream git repository rather than from a stable release. The maintainer chose this version number, presumably to indicate that the snapshot was made on 2020-04-29 after git commit f7746d0. For that installed version, `rsync --version` says the version is 3.2.0dev That version number is determined by the upstream rsync developers, and it indicates that the build is based on a snapshot of the development branch for a future 3.2.0 release. (This is what Andrey was saying.) The latest stable release, 3.1.3, is two years old. I'm sure Jari had good reasons for wanting to make a more recent version available. 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: Which rsync version is current?
Greetings, Bill Stewart! > When I run rsync --version, I see this: > rsync version 3.2.0dev protocol version 31 > However the Cygwin Setup program says that my rsync is current and is > listed as this version: > 3.1.3+20200429+gitf7746d0-1 Ok, I think I have a better explanation. https://git.samba.org/?p=rsync.git;a=commit;h=f7746d0 > rsync.samba.org says the current version is 3.1.3. > So...what's actually the latest? What's the difference between these? 3.1.3, but Cygwin release is a tad bit ahead of it. -- With best regards, Andrey Repin Wednesday, May 27, 2020 22:26:56 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
Re: Which rsync version is current?
On Wed, May 27, 2020 at 1:20 PM Andrey Repin wrote: > > When I run rsync --version, I see this: > > > > rsync version 3.2.0dev protocol version 31 > > > > However the Cygwin Setup program says that my rsync is current and is > > listed as this version: > > > > 3.1.3+20200429+gitf7746d0-1 > > > > rsync.samba.org says the current version is 3.1.3. > > > > So...what's actually the latest? What's the difference between these? > > Run `which rsync` to see which one is responding to you. > > 3.2-dev is likely a snapshot from ongoing development branch. `which rsync` outputs /usr/bin/rsync as expected. What I am saying is that the Setup program says the installed version is 3.1.3+20200429+gitf7746d0-1. For that installed version, `rsync --version` says the version is 3.2.0dev Thus it seems that "3.1.3+20200429+gitf7746d0-1" is really identical to "3.2.0dev". Is this statement correct? If this statement is indeed correct, I would say that this is confusing (at the least) and that Setup or the rsync source code (or both) should be updated to reflect the correct version number. 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
Re: Which rsync version is current?
Greetings, Bill Stewart! > When I run rsync --version, I see this: > rsync version 3.2.0dev protocol version 31 > However the Cygwin Setup program says that my rsync is current and is > listed as this version: > 3.1.3+20200429+gitf7746d0-1 > rsync.samba.org says the current version is 3.1.3. > So...what's actually the latest? What's the difference between these? Run `which rsync` to see which one is responding to you. 3.2-dev is likely a snapshot from ongoing development branch. -- With best regards, Andrey Repin Wednesday, May 27, 2020 22:11:18 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
Which rsync version is current?
When I run rsync --version, I see this: rsync version 3.2.0dev protocol version 31 However the Cygwin Setup program says that my rsync is current and is listed as this version: 3.1.3+20200429+gitf7746d0-1 rsync.samba.org says the current version is 3.1.3. So...what's actually the latest? What's the difference between these? 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
openssh 8.3p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-8.3p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Upstream announcement: -- Announce: OpenSSH 8.3 released OpenSSH 8.3 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice = It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release. This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs. The better alternatives include: * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them. * The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5. * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7. To check whether a server is using the weak ssh-rsa public key algorithm, for host authentication, try to connect to it after removing the ssh-rsa algorithm from ssh(1)'s allowed list: ssh -oHostKeyAlgorithms=-ssh-rsa user@host If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded. A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms. Users may consider enabling this option manually. Vendors of devices that implement the SSH protocol should ensure that they support the new signature algorithms for RSA keys. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf Security * scp(1): when receiving files, scp(1) could be become desynchronised if a utimes(2) system call failed. This could allow file contents to be interpreted as file metadata and thereby permit an adversary to craft a file system that, when copied with scp(1) in a configuration that caused utimes(2) to fail (e.g. under a SELinux policy or syscall sandbox), transferred different file names and contents to the actual file system layout. Exploitation of this is not likely as utimes(2) does not fail under normal circumstances. Successful exploitation is not silent - the output of scp(1) would show transfer errors followed by the actual file(s) that were received. Finally, filenames returned from the peer are (since openssh-8.0) matched against the user's requested destination, thereby disallowing a successful exploit from writing files outside the user's selected target glob (or directory, in the case of a recursive transfer). This ensures that this attack can achieve no more than a hostile peer is already able to achieve within the scp protocol. Potentially-incompatible changes This release includes a number of changes that may affect existing configurations: * sftp(1): reject an argument of "-1" in the same way as ssh(1) and scp(1) do instead of accepting and silently ignoring it. Changes since OpenSSH 8.2 = The focus of this release is bug fixing. New Features * sshd(8): make IgnoreRhosts a tri-state option: "yes" to ignore rhosts/shosts, "no" allow rhosts/shosts or (new) "shosts-only" to allow .shosts files but not .rhosts. * sshd(8): allow the IgnoreRhosts directive to appear anywhere in a sshd_config, not just before any Match blocks; bz3148 * ssh(1): add %TOKEN percent expansion for the LocalFoward and RemoteForward keywords when used for Unix domain socket forwarding. bz#3014 * all: allow loading public keys from the unencrypted envelope of a private key file if no corresponding public key file is present. * ssh(1), sshd(8): prefer to use chacha20 from libcrypto where possible
[ANNOUNCEMENT] openssh 8.3p1-1
The following packages have been uploaded to the Cygwin distribution: * openssh-8.3p1-1 OpenSSH is a program for logging into a remote machine and for executing commands on a remote machine. It can replace rlogin and rsh, providing encrypted communication between two machines. Upstream announcement: -- Announce: OpenSSH 8.3 released OpenSSH 8.3 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: https://www.openssh.com/donations.html Future deprecation notice = It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release. This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs. The better alternatives include: * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them. * The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5. * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7. To check whether a server is using the weak ssh-rsa public key algorithm, for host authentication, try to connect to it after removing the ssh-rsa algorithm from ssh(1)'s allowed list: ssh -oHostKeyAlgorithms=-ssh-rsa user@host If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded. A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms. Users may consider enabling this option manually. Vendors of devices that implement the SSH protocol should ensure that they support the new signature algorithms for RSA keys. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf Security * scp(1): when receiving files, scp(1) could be become desynchronised if a utimes(2) system call failed. This could allow file contents to be interpreted as file metadata and thereby permit an adversary to craft a file system that, when copied with scp(1) in a configuration that caused utimes(2) to fail (e.g. under a SELinux policy or syscall sandbox), transferred different file names and contents to the actual file system layout. Exploitation of this is not likely as utimes(2) does not fail under normal circumstances. Successful exploitation is not silent - the output of scp(1) would show transfer errors followed by the actual file(s) that were received. Finally, filenames returned from the peer are (since openssh-8.0) matched against the user's requested destination, thereby disallowing a successful exploit from writing files outside the user's selected target glob (or directory, in the case of a recursive transfer). This ensures that this attack can achieve no more than a hostile peer is already able to achieve within the scp protocol. Potentially-incompatible changes This release includes a number of changes that may affect existing configurations: * sftp(1): reject an argument of "-1" in the same way as ssh(1) and scp(1) do instead of accepting and silently ignoring it. Changes since OpenSSH 8.2 = The focus of this release is bug fixing. New Features * sshd(8): make IgnoreRhosts a tri-state option: "yes" to ignore rhosts/shosts, "no" allow rhosts/shosts or (new) "shosts-only" to allow .shosts files but not .rhosts. * sshd(8): allow the IgnoreRhosts directive to appear anywhere in a sshd_config, not just before any Match blocks; bz3148 * ssh(1): add %TOKEN percent expansion for the LocalFoward and RemoteForward keywords when used for Unix domain socket forwarding. bz#3014 * all: allow loading public keys from the unencrypted envelope of a private key file if no corresponding public key file is present. * ssh(1), sshd(8): prefer to use chacha20 from libcrypto where possible
Re: Updating glib2.0
On 5/23/2020 2:08 PM, Ken Brown via Cygwin-apps wrote: On 5/22/2020 7:18 PM, Ken Brown via Cygwin-apps wrote: I've been planning to adopt gimp and some related build dependencies. My reason is that I use gimp and would like to see it kept up to date. I thought I had all the prerequisites I needed. But when I built gimp, I discovered that it used two functions, g_set_weak_pointer and g_date_time_new_from_iso8601, that were introduced in glib-2.56. [gimp's configure.ac says that it only requires glib 2.54.2, but this seems to be wrong. Cygwin's glib is at 2.54.3. Fedora's is at 2.64.3, which is the latest upstream release.] I'd appreciate some advice about how to proceed. I'm not interested in adopting all of GNOME, and it probably doesn't make sense for different components of GNOME to be adopted by different people. A short-term solution (from my personal POV) would be for me to do a non-maintainer update of glib to 2.56, assuming that's doable without messing up other GNOME components. A better solution (again from my personal POV) would be for someone to adopt GNOME and update it to its latest release. To focus the discussion a little better, I've built and installed glib2.0-2.56.4. My cygport file and patches are attached. I can now build gimp-2.10.18, and it seems to run fine in limited testing. Sorry to keep replying to myself, but I have some further thoughts. 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. 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. 3. I don't use the GNOME desktop environment, so I am not going to adopt packages like gnome-session, gnome-flashback, etc., which I can't easily test. If no one objects, I'll continue sending ITAs and updating individual GNOME components as I need them. Ken
Re: pdfjam in texlive-collection-binextra-20200406-1 doesn't work
On 5/27/2020 9:35 AM, Lemures Lemniscati via Cygwin wrote: Hi ! pdfjam in texlive-collection-binextra-20200406-1 doesn't work. Even a simple invocation such as pdfjam a.pdf hangs while waiting for input from stdin. pdfjam 3.03 in TeX Live 2020 have got a major update since TeX Live 2019. There was a new challenge to make pdfjam work with MiKTeX on Windows through Cygwin. But it introduced a bug that make pdfjam fail to work with pure Cygwin TeX Live packages. This is a situation. I made a pull-request to fix 10+ days ago, but it is not merged yet, and still I don't know whether it will be accepted or not: https://github.com/DavidFirth/pdfjam/pull/22 So, here, I attach a file to replace /usr/share/texmf-dist/scripts/pdfjam/pdfjam for convenience. Thanks. I'll keep an eye on the PR. It it doesn't get merged within the next few weeks, I'll just apply your patch locally and make a new release. 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
pdfjam in texlive-collection-binextra-20200406-1 doesn't work
Hi ! pdfjam in texlive-collection-binextra-20200406-1 doesn't work. Even a simple invocation such as pdfjam a.pdf hangs while waiting for input from stdin. pdfjam 3.03 in TeX Live 2020 have got a major update since TeX Live 2019. There was a new challenge to make pdfjam work with MiKTeX on Windows through Cygwin. But it introduced a bug that make pdfjam fail to work with pure Cygwin TeX Live packages. This is a situation. I made a pull-request to fix 10+ days ago, but it is not merged yet, and still I don't know whether it will be accepted or not: https://github.com/DavidFirth/pdfjam/pull/22 So, here, I attach a file to replace /usr/share/texmf-dist/scripts/pdfjam/pdfjam for convenience. -- Lem pdfjam 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
Strange 120 second wait with sshd on domain controller
I'm experincing a strange issue on domain controller where I have cygwin and sshd service installed. This is a Windows 2019 server. There is older domain controller on the same domain that handles all FSMO roles and it does not have this issue (different Windows and cygwin versions though). Replication between servers seems to work fine. Rdp connectivity to servers is stable and shows no network issues. Cygwin sshd installation is very basic, only thing changed is the sshd port number. I'm using the exact same installation packages and configuration on other non-dc servers and they do not have this issue. When I try to login via ssh locally, everything works almost fine. I type in the command and get password prompt immediately, enter password. Then I get the "Last login:" row, but prompt appears only 120+ seconds later. Usually around 124 seconds. When I try to ssh in remotely, I get this. No password prompt, but strangely 120+ seconds wait before it tells me that authentication failed. 2020-05-27 15:15:02 debug1: SSH2_MSG_SERVICE_ACCEPT received 2020-05-27 15:15:02 debug1: Authentications that can continue: publickey,password,keyboard-interactive 2020-05-27 15:15:02 debug1: Next authentication method: publickey 2020-05-27 15:15:02 debug1: Offering RSA public key: /home/pojanisu/.ssh/id_rsa 2020-05-27 15:17:08 Authentication failed. Windows event log does not seem to help much. I have this in application log while sshd set to debug logging level. After that nothing and no relevant failures in security log either. 2020-05-27 15:15:02 sshd: PID 5559: debug1: temporarily_use_uid: 1049076/1049089 (e=18/18) And now the really strange part. Sometimes this works just fine without any waits. I have not been able to figure out whether it's after reboot or some other mysterious events. But then hour later I'm back to this no remote login at all and 120 seconds wait before prompt locally. Since this is a new server, I went and undid the DC part, removed the whole virtual server and redid everything from scratch. The second installation has exactly the same issue. Any ideas would be very welcome. Pasi -- 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 install blurry on high dpi Windows 10
Hi, My office laptop is Windows 10 with a high DPI display. I found that the installer is blurry, especially inside the window. The title of the window is clear. Is this something that has been reported before? If nobody has reported it, then I would like to report the issue here. Attached is the screenshot of the installer to show clear title with blurry content. Thank you. -- Sharuzzaman Ahmat Raslan -- 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
