Sourceware infrastructure updates for Q1 2024
Sourceware infrastructure community updates for Q1 2024 A summary of news about Sourceware, the Free Software hosting project for core toolchain and developer tools, from the last 3 months. - Sourceware now has an official donation page - StarFive VisionFive-2 RISC-V boards for builder.sourceware.org - server2 and server3 disk drive updates - Upgrading project websites from CVS to GIT - Sourceware @ Fosdem - Security policy updates for a CVE system out of control - Summer of Code = Sourceware now has an official donation page Sourceware is a Free Software hosting project for core toolchain and developer tools. Sourceware is maintained by volunteers. Hardware and bandwidth is provided by sponsors. Sourceware is a Software Freedom Conservancy member project. Conservancy handles all non-profit administrivia for Sourceware. Thanks to the Conservancy we already have collected enough money for an emergency hardware replacement fund. In case one of our hardware partners would suddenly and unexpectedly drop support we can now simply buy new hardware. And we now also have an official donation page to help fund accelerating tasks the community feels most useful. https://sourceware.org/donate.html = StarFive VisionFive-2 RISC-V boards for builder.sourceware.org StarFive has donated 4 VisionFive-2 risc-v boards with 8GB, 4-core JH7110 supporting the RV64GC ISA for the CI running on builder.sourceware.org. Which has allowed us to setup CI (and try) builders for various projects: annobin, binutils(+try), bzip2, debugedit, dwz, elfutils(+try), glibc, poke and libabigail(+try). Please contact the builder project if you want to help out with the CI services. https://sourceware.org/mailman/listinfo/buildbot = server2 and server3 disk drive updates One of the drives in server2 broke down. It was part of a 10 drive raid6 setup, which can take 2 bad disks before full failure. We also have a full mirror on server3, which has a similar raid6 setup. We ordered 3 new disks, one as replacement for the bad disk and a spare for server2 and server3 in case of future drive failures. The drive has been replaced and everything is running smoothly. We have a fund for replacing hardware when needed. But if you want to help out keeping everything running smoothly you can donate on our new donation page https://sourceware.org/donate.html = Upgrading project websites from CVS to GIT. Various projects were still creating their project homepages from CVS. We upgraded both glibc and binutils to have a public git htdocs repository now to which the whole community can contribute. https://sourceware.org/cgit/binutils-htdocs/ https://sourceware.org/cgit/glibc-htdocs/ Please contact us if you want to upgrade how you publish your projects homepage. https://sourceware.org/mission.html#organization = Sourceware @ Fosdem 2024 started strong with various Sourceware core toolchain and developer tool projects presenting at Fosdem. If you missed the in person meetings, most talks have video recordings: https://fosdem.org/2024/schedule/track/gcc/ https://fosdem.org/2024/schedule/track/debuggers-and-analysis/ https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/ Various Sourceware volunteers, overseers and project leadership committee members also met informally with FSF/GNU and SFC admins to coordinate cross free software infrastructure administration matters. And if you like to organize an online virtual mini-BoF around some topic or project then the Conservancy BBB server is available for all Sourceware projects. You can create your own account at https://bbb.sfconservancy.org/b/signup which we can then activate for you. Note: Anyone is able to join a meeting, accounts are only required to create new meetings. = Security policy updates for a CVE system out of control The Common Vulnerabilities and Exposures (CVE) system seems broken and has been issuing more and more questionable advisories. Various Sourceware hosted projects have been writing security policies to help users know which bugs might have security implications. https://sourceware.org/cgit/elfutils/tree/SECURITY https://sourceware.org/cgit/binutils-gdb/tree/binutils/SECURITY.txt https://gcc.gnu.org/cgit/gcc/tree/SECURITY.txt The glibc project even setup their own security mailinglist and CNA (CVE Numbering Authority) publishing their own advisories: https://sourceware.org/glibc/security.html https://sourceware.org/cgit/glibc/tree/advisories If you need any help adding infrastructure services for your security projects, please reach out: https://sourceware.org/mission.html#organization = Summer of Code Some Sourceware hosted projects will take part in Summer of Code 2024. If you are interested in participating please see https://gcc.gnu.org/wiki/SummerOfCode https://www.gnu.org/software/soc-projects/ideas
Sourceware infrastructure updates for Q4 2023
Sourceware infrastructure community updates for Q4 2023 - 6 months with the Software Freedom Conservancy - Sourceware @ Fosdem - OSUOSL provides extra larger arm64 and x86_64 buildbot servers - No more From rewriting for patches mailinglists = 6 months with the Software Freedom Conservancy Sourceware thanks Conservancy for their support and urges the community to support Conservancy. Sourceware has only been a Software Freedom Conservancy member project for just 6 months. But the story started a long time ago and a lot has happened in that time: https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/ We hope the community will support the Software Freedom Conservancy 2023 Fundraiser and become a Conservancy Sustainer https://sfconservancy.org/sustainer = Sourceware @ Fosdem Various Sourceware projects will be present at Fosdem plus some overseers and of course Conservancy staff. Get your talk submissions in before end of the week (December 1st) to these developer rooms: Debuggers and Analysis tools gdb, libabigail, systemtap, valgrind, binutils, elfutils, gnupoke, cgen https://inbox.sourceware.org/6a2e8cbf-0d63-24e7-e3c2-c3d286e2e...@redhat.com/ GCC compiler devroom gcc, binutils, glibc, newlib https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.ca...@redhat.com/ And if you like to organize an online virtual mini-BoF around some topic or project then the @conservancy BBB server is available for all Sourceware projects. https://inbox.sourceware.org/9ca90cd013675a960d47ee09fa4403f69405e9f2.ca...@klomp.org/ = OSUOSL provides extra larger arm64 and x86_64 buildbot servers There have been complaints about overloaded builders. So OSUOSL have provided us with another arm64 and x86_64 server. The new servers do the larger gcc and glibc builds so the other builders can do quicker (smaller) CI builds without having to wait on the big jobs. This also frees up the other container builders to do more automated jobs like the recently added autotools generated files checker for gcc, binutils and gdb: https://inbox.sourceware.org/20231115194803.gw31...@gnu.wildebeest.org/ Please contact the builder project build...@sourceware.org if you want to run some automated jobs on https://builder.sourceware.org/ = No more From rewriting for patches mailinglists Because of dkim, strict dmarc policies and an old mailman setup Sourceware mailinglists used From rewriting. No more! We upgraded mailman, gave up subject prefixes, mail footers, html stripping and reply-to mangling. After the libc-alpha and gcc-patches mailinglist tests to avoid From rewriting worked out nicely we enabled the same settings to some other mailinglists. The gcc patches lists for libstdc++, libgccjit, fortran and gcc-rust. And for those projects that use patchwork, newlib, elfutils, libabigail and gdb. This hopefully makes mailing patches and using git am on them a bit nicer. Outgoing sourceware email now also includes ARC headers. https://en.wikipedia.org/wiki/Authenticated_Received_Chain Feedback on whether this helps email delivery appreciated. Please contact overseers if you would like the new setting for any other Sourceware mailinglist. Thanks to the FSF tech-team for walking us through their setup for lists.gnu.org -- 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
Sourceware infrastructure updates Q1 2023
Sourceware infrastructure community updates for Q1 2023. = New cgit setup gitweb has been working out pretty nicely for many years, but cgit is cgit is nicer looking, has easier to understand URLs and is much faster. The first experimental setup can be found here: https://cygwin.com/cgit/ https://gcc.gnu.org/cgit/ https://sourceware.org/cgit/ Thanks to Jon Turney for the cygwin work. If this works out, we would like to deploy a script written by Arsen Arsenović to switch the main /git/ to cgit while keeping all old gitweb URLs working. See https://sourceware.org/bugzilla/show_bug.cgi?id=29769 = New sparc builder for builder.sourceware.org Thanks to the Gentoo Foundation and OSUOSL [*] there is now a large (and small) gentoo-sparc worker: https://builder.sourceware.org/buildbot/#/workers/35 https://builder.sourceware.org/buildbot/#/workers/36 Please contact the buildbot mailinglis if you want to do specific builds on it: https://sourceware.org/mailman/listinfo/buildbot = AI comes to the bunsen test results It isn't a large language model chatbot, but probably more useful. https://builder.sourceware.org/testruns/ will now predict what it believes the the dejagnu test results should be. It will give a score for what it expected a result to be. e.g for a new FAIL it could say: mispredicted PASS 81% which means in 81% of similar test runs that test PASSed. So you can concentrate on those FAILing tests that have a high PASSing score. For more info see: https://inbox.sourceware.org/buildbot/20230206160507.ga31...@redhat.com/ = openssh update produces misleading invalid key length warning Connecting to sourceware through ssh with a newer openssh or crypto policy might produce a misleading warning about the key length being too short: Bad server host key: Invalid key length Please don't try to replace your ssh key, there is nothing wrong with it. The issue is that you might have an old server key in your ~/.ssh/known_hosts file. Simply remove it and reconnect to get the new server key: ssh-keygen -R sourceware.org ssh-keygen -R cygwin.com ssh-keygen -R gcc.gnu.org See also https://bugzilla.redhat.com/show_bug.cgi?id=2164016 = inbox.sourceware.org and '/' in Message-ID Those using public-inbox might have noticed that when a Message-ID contains a slash character '/' it is not always correctly encoded or decoded as %2F in the inbox.sourceware.org path URLs. If you are using a newer mutt as email client then you might want to make sure that your Message-ID doesn't contain any characters that might need URL encoding. For mutt 2.2 you might want to set the following in your ~/.muttrc to produce a uuid-like Message-ID as other email clients do: set message_id_format="<%x%x%x%x-%x%x-%x%x-%x%x-%x%x%x%x%x%x@%f>" For older mutt, and some more background, see: https://people.kernel.org/monsieuricon/fix-your-mutt = Happy hacking And as always please feel free join the overseers mailinglist https://sourceware.org/mailman/listinfo/overseers file infrastructure issues in bugzilla https://sourceware.org/bugzilla/describecomponents.cgi?product=sourceware or join us in #overseers on irc.libera.chat [*] But specifically Sam James. We should also thank the following other individuals and organisations for maintaining and/or providing hardware for builder.sourceware.org Brno University, Dan Horák, Marist University, Thomas Fitzsimmons, Mark Wielaard, Frank Eigler, IBM, Carl Love, The Works on Arm initiative, Christophe Lyon, and Red Hat -- 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: Retry / Continue dialog appearing frequently in setup for dll updates
> "ssh-pageant.sh" -k > gpgconf --kill gpg-agent dirmngr scdaemon > sh -c "for svc in $( cygrunsrv --list | grep -v cygserver ) cygserver; do net > stop "^"$svc^""; done" > > Restarting after setup is goin gthe other way around, except GPG services > (they are restarted by themselves as needed). > > > -- > With best regards, > Andrey Repin > Thursday, August 4, 2022 13:19:56 > > Sorry for my terrible english... > Thank you, Andrey! -- 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: Retry / Continue dialog appearing frequently in setup for dll updates
Greetings, Keith Christian! > Hi Ken, > Yes, I attempt to shut down all cygwin processes as we all have done > over the past many years of enjoying Cygwin. > I opened a terminal as Administrator to shut down cygsshd and exim as > shown below but it did not work. > What could be wrong here? I am surprised that cygrunsrv was unable to > stop the two processes, even as Administrator. > cygrunsrv -L > cygsshd > exim > cygrunsrv -E cygsshd > cygrunsrv -L > cygsshd > exim > cygrunsrv -E exim > cygrunsrv -L > cygsshd > exim "ssh-pageant.sh" -k gpgconf --kill gpg-agent dirmngr scdaemon sh -c "for svc in $( cygrunsrv --list | grep -v cygserver ) cygserver; do net stop "^"$svc^""; done" Restarting after setup is goin gthe other way around, except GPG services (they are restarted by themselves as needed). -- With best regards, Andrey Repin Thursday, August 4, 2022 13:19: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: Retry / Continue dialog appearing frequently in setup for dll updates
On 31/07/2022 17:53, Keith Christian wrote: Hi Jon, What did I just ask you not to do? And then you go and do it! Sigh. Ok, may I know what the procedure is to suggest enhancements? Please explain what makes you think that it's going to be something other than "send an email to the list", like every other cygwin question/comment/suggestion/bug report... On Sun, Jul 31, 2022 at 9:07 AM Jon Turney wrote: On 31/07/2022 12:36, Keith Christian wrote: (I'll send these ideas to the setup maintainer in a separate email.) Please don't. (I don't want to give anyone the idea that is an acceptable thing to do.) You might also like to review [1]. [1] https://cygwin.com/#support -- 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: Retry / Continue dialog appearing frequently in setup for dll updates
Hi Ken, Yes, I attempt to shut down all cygwin processes as we all have done over the past many years of enjoying Cygwin. I opened a terminal as Administrator to shut down cygsshd and exim as shown below but it did not work. What could be wrong here? I am surprised that cygrunsrv was unable to stop the two processes, even as Administrator. cygrunsrv -L cygsshd exim cygrunsrv -E cygsshd cygrunsrv -L cygsshd exim cygrunsrv -E exim cygrunsrv -L cygsshd exim -- 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: Retry / Continue dialog appearing frequently in setup for dll updates
On 7/31/2022 7:36 AM, Keith Christian wrote: On two different Windows 10 machines, I see the Retry/Continue dialog on numerous cygwin .dll files. These are the only cygwin processes extant while setup is running: [...] Setup might benefit from the "Continue" option having a checkbox or separate button such as "Continue for all remaining" so that "Continue" wouldn't require the user to click "Continue" endlessly until all dll's are installed. The standard advice is to shut down *all* Cygwin processes before running setup. I don't see why we would want to make it easier for users to disregard that advice. I could see only coreutils 8.32, no coreutils 9 versions, even with choosing Full, Test, etc. in setup. Choose the "Full" or "Up To Date" view, search for coreutils, and click the arrow at the right of the "New" column. You should see "9.0-1 (Test)" as one of the available versions. 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: Retry / Continue dialog appearing frequently in setup for dll updates
On 31/07/2022 12:36, Keith Christian wrote: (I'll send these ideas to the setup maintainer in a separate email.) Please don't. (I don't want to give anyone the idea that is an acceptable thing to do.) -- 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
Retry / Continue dialog appearing frequently in setup for dll updates
On two different Windows 10 machines, I see the Retry/Continue dialog on numerous cygwin .dll files. These are the only cygwin processes extant while setup is running: == C:\Users\keith>tasklist /v | findstr /c:ssh sshd.exe 5656 Services 0 6,996 K Unknown N/A 0:00:00 N/A C:\Users\keith>tasklist /v | findstr /c:cyg /i cygrunsrv.exe 3416 Services 0 6,236 K Unknown N/A 0:00:00 N/A cygrunsrv.exe 3432 Services 0 6,308 K Unknown N/A 0:00:00 N/A setup-x86_64.exe 11092 Console1 282,596 K Running 10029233\keith 0:03:40 1% - Cygwin Setup == Setup version is 9.19, Windows version is 10.0.19044 N/A Build 19044. Setup might benefit from the "Continue" option having a checkbox or separate button such as "Continue for all remaining" so that "Continue" wouldn't require the user to click "Continue" endlessly until all dll's are installed. Displaying the version of setup in the main setup screen would also be a nice feature. Are "Retry" and "Continue" actions recorded in the setup.log files? If not, this might be another enhancement. (I'll send these ideas to the setup maintainer in a separate email.)P If there is some sort of permission issue on this system, what commands are recommended to troubleshoot and fix them? I downloaded the latest setup yesterday specifically to see what versions of coreutils were available. I could see only coreutils 8.32, no coreutils 9 versions, even with choosing Full, Test, etc. in setup. Thanks! -- 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: Emacs crashing after M-x compile after Cygwin updates
Bruce Mardle via Cygwin writes: > Hi, all. I've been happily compiling simple C programs under Emacs > (emacs-w32) under Cygwin. Yesterday I wanted to install > libedit-dev. While I was doing that, setup...exe marked a few dozen > other packages for upgrades. I didn't notice which. You can still find that out today by looking at /var/log/setup.log and (for the immediately prevuious run of setup.exe) in much more detail in /var/log/setup.log.full -- so do not start setup.exe again in case you think there might be something you need to check in detail before copying that file someplace safe. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Emacs crashing after M-x compile after Cygwin updates
On Mon, 4 Apr 2022 13:08:27 + (UTC) Bruce Mardle wrote: > Hi, all. > I've been happily compiling simple C programs under Emacs (emacs-w32) under > Cygwin. Yesterday I wanted to install libedit-dev. While I was doing that, > setup...exe marked a few dozen other packages for upgrades. I didn't notice > which. Now, if I `emacs hello.c` and M-x compile gcc -o hello hello.c the > compilation works... but then, a few seconds later, Emacs SEGVs. emacs-nox > does the same but without the delay. > I've tried Emacs versions 27.2-1, 28.0.60-1.f7e6c199bf, and 27.1. Then, in > case it was gcc doing something naughty, I changed that from version 11.2.0 > to 10.2.0-1. Same problem all the way. Running gcc from the terminal emulator > works (but then I don't get to use Emacs' M-x ` and the like). > I'm using 64-bit Windows 7 Pro [blush]. Is it still supposed to work on that? > I don't seem to have a problem with a laptop running Windows 10. > `uname -r` returns 3.3.4(0.341/5/3). > I've spent a few hours looking at the mailing list archives (probably > incompetently) and Googling, without success. Perhaps this is the same issue with: https://cygwin.com/pipermail/cygwin/2022-March/251162.html which is already fixed in cygwin git head. https://cygwin.com/pipermail/cygwin-patches/2022q1/011865.html -- 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
Emacs crashing after M-x compile after Cygwin updates
Hi, all. I've been happily compiling simple C programs under Emacs (emacs-w32) under Cygwin. Yesterday I wanted to install libedit-dev. While I was doing that, setup...exe marked a few dozen other packages for upgrades. I didn't notice which. Now, if I `emacs hello.c` and M-x compile gcc -o hello hello.c the compilation works... but then, a few seconds later, Emacs SEGVs. emacs-nox does the same but without the delay. I've tried Emacs versions 27.2-1, 28.0.60-1.f7e6c199bf, and 27.1. Then, in case it was gcc doing something naughty, I changed that from version 11.2.0 to 10.2.0-1. Same problem all the way. Running gcc from the terminal emulator works (but then I don't get to use Emacs' M-x ` and the like). I'm using 64-bit Windows 7 Pro [blush]. Is it still supposed to work on that? I don't seem to have a problem with a laptop running Windows 10. `uname -r` returns 3.3.4(0.341/5/3). I've spent a few hours looking at the mailing list archives (probably incompetently) and Googling, without success. -- 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: Request for updates to packages itcl 4.1.1, itk 4.1.0, iwidgets 4.1.1
Op vr 29 okt. 2021 om 17:13 schreef Claudius Schnörr: > if cygwin was updated to these package versions: itcl 4.1.1, itk 4.1.0, > iwidgets 4.1.1 > the package git://sourceware.org/git/insight.git, a very good > GUI-frontend to gdb, would be available on cygwin again. > > Attached are the cygport files with necessary modifications the > maintainer of insight provided. These are no patches but might be > helpful for cygwin packagers by comparing them to the original ones. > > When upgrades to these packages are available I can check whether > insight can be built on cygwin. Thank you for your interest. Itcl/Itk 4.2.2 is close to being released, just as Tcl/Tk 8.6.12. So you can expect new versions in a few weeks from now. Regards, Jan Nijtmans -- 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
Request for updates to packages itcl 4.1.1, itk 4.1.0, iwidgets 4.1.1
Hello,
if cygwin was updated to these package versions: itcl 4.1.1, itk 4.1.0,
iwidgets 4.1.1
the package git://sourceware.org/git/insight.git, a very good
GUI-frontend to gdb, would be available on cygwin again.
Attached are the cygport files with necessary modifications the
maintainer of insight provided. These are no patches but might be
helpful for cygwin packagers by comparing them to the original ones.
When upgrades to these packages are available I can check whether
insight can be built on cygwin.
I hope this helps. Thank you for your help,
Claudius
inherit tcl
NAME="tcl-itcl"
VERSION=4.1.1
RELEASE=1
CATEGORY="Tcl"
SUMMARY="Object-Oriented extensions for Tcl"
DESCRIPTION="[incr Tcl] is an object-oriented extension of the Tcl language.
It was created to support more structured programming in Tcl. [incr Tcl]
introduces the notion of objects. Among other things, [incr Tcl] can be
used to create new widgets that look and work like the usual Tk widgets,
but are written entirely at the Tcl language level (C code is optional)."
HOMEPAGE="http://incrtcl.sourceforge.net/";
SRC_URI="https://downloads.sourceforge.net/incrtcl/itcl${VERSION}.tar.gz";
SRC_DIR="itcl${VERSION}"
PKG_NAMES="${NAME} ${NAME}-devel"
tcl_itcl_REQUIRES="tcl"
tcl_itcl_CONTENTS="
usr/bin/libitcl${VERSION}.dll
usr/lib/itcl${VERSION}/itcl*.tcl
usr/lib/itcl${VERSION}/pkgIndex.tcl
usr/share/doc/${NAME}/
usr/share/man/mann/
"
tcl_itcl_devel_REQUIRES="tcl-devel"
tcl_itcl_devel_CONTENTS="
usr/include/itcl*.h
usr/lib/itcl${VERSION}/itclConfig.sh
usr/lib/itcl${VERSION}/libitcl${VERSION}.dll.a
usr/lib/itcl${VERSION}/libitclstub${VERSION}.a
"
#DISTCLEANFILES="aclocal.m4"
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf
cygmake SHLIB_LD="\$(CC) -shared -Wl,--out-implib,\$@.a"
}
src_install() {
cd ${B}
cyginstall
insinto /usr/lib/itcl${VERSION}
doins libitcl${VERSION}.dll.a
mv ${D}/usr/lib/itcl${VERSION}/libitcl${VERSION}.dll ${D}/usr/bin
sed -i -e "s|\"\(libitcl${VERSION}.dll\)\"|.. .. bin \1|"
${D}/usr/lib/itcl${VERSION}/pkgIndex.tcl
}
inherit tcl
NAME="tcl-itk"
VERSION=4.1.0
RELEASE=1
CATEGORY="Tcl"
SUMMARY="Object-Oriented extensions for Tk"
DESCRIPTION="[incr Tcl] is an object-oriented extension of the Tcl language.
It was created to support more structured programming in Tcl. [incr Tcl]
introduces the notion of objects. Among other things, [incr Tcl] can be
used to create new widgets that look and work like the usual Tk widgets,
but are written entirely at the Tcl language level (C code is optional)."
HOMEPAGE="http://incrtcl.sourceforge.net/";
SRC_URI="mirror://sourceforge/incrtcl/itk${VERSION}.tar.gz"
SRC_DIR="itk${VERSION}"
PKG_NAMES="${NAME} ${NAME}-devel"
tcl_itk_REQUIRES="tcl tcl-itcl tcl-tk"
tcl_itk_CONTENTS="
usr/bin/libitk${VERSION}.dll
usr/lib/itk${VERSION}/*.itk
usr/lib/itk${VERSION}/*.tcl
usr/lib/itk${VERSION}/tclIndex
usr/share/man/mann/
"
tcl_itk_devel_REQUIRES="tcl-devel tcl-tk-devel tcl-itcl-devel"
tcl_itk_devel_CONTENTS="
usr/include/itk*.h
usr/lib/itk${VERSION}/libitk${VERSION}.dll.a
"
#DISTCLEANFILES="aclocal.m4"
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf --with-itcl=/usr/lib/itcl4.1.1
cygmake SHLIB_LD="\$(CC) -shared -Wl,--out-implib,\$@.a"
}
src_install() {
cd ${B}
cyginstall
insinto /usr/lib/itk${VERSION}
doins libitk${VERSION}.dll.a
mv ${D}/usr/lib/itk${VERSION}/libitk${VERSION}.dll ${D}/usr/bin
sed -i -e "s|\"\(libitk${VERSION}.dll\)\"|.. .. bin \1|"
${D}/usr/lib/itk${VERSION}/pkgIndex.tcl
}
ORIG_PN="iwidgets"
inherit tcl
NAME="tcl-iwidgets"
VERSION=4.1.1
RELEASE=1
CATEGORY="Tcl"
SUMMARY="Tcl/Tk widget set"
DESCRIPTION="[incr Widgets] is an object-oriented mega-widget set which
extends Tcl/Tk and is based on [incr Tcl] and [incr Tk]. This set of
mega-widgets delivers many new, general purpose widgets like option menus,
comboboxes, selection boxes, and various dialogs whose couterparts are found
in Motif and Windows."
HOMEPAGE="http://incrtcl.sourceforge.net/";
SRC_URI="http://downloads.sourceforge.net/sourceforge/incrtcl/%5BIncr%20Widgets%5D/iwidgets-${VERSION}.tar.gz";
SRC_DIR="iwidgets-${VERSION}"
PATCH_URI="
http://src.fedoraproject.org/rpms/iwidgets/raw/f33/f/iwidgets-calls.patch
http://src.fedoraproject.org/rpms/iwidgets/raw/f33/f/iwidgets4.0.1-wish85.diff
"
ARCH=noarch
#DISTCLEANFILES="aclocal.m4"
src_compile() {
find . -name CVS | xargs -r rm -rf
sed -e 's|\@itcl_VERSION\@|4.0|g'\
-e "s|\@PACKAGE_VERSION\@|${VERSION}|g" \
< ${S}/iwidgets.tcl.in > ${B}/iwidgets.tcl
sed -e 's|\@itcl_VERSION\@|4.0|g' \
-e "s|\@PACKAGE_VERSION\@|${VERSION}|g" \
< ${S}/pkgIndex.tcl.in
Re: Request package updates for Poppler, Subversion and Git
I made do with windows git 2.26 - unfortunately it does not play well with cygwin git My first attempt at windows git worktree add produced: "Working tree has modifications. Cannot add." Very surprising since it was a fresh clone - but using cygwin git Turns out the error is from a git diff-index HEAD at https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L617 windows git diff-index showed two kinds of false positives 1. new files: :100644 100644 b5ae85651031085a9dc89f584d235e48f0502837 M LICENSE this is fixed with windows git update-index LICENSE 2. file permissions change :100755 100644 ae8fb75816f99be89c0171fb5b287149f52c19be ae8fb75816f99be89c0171fb 5b287149f52c19be M googletest/ci/build-linux-bazel.sh this is fixed with windows git config core.filemode false Bit easier is insuring the repo was cloned with windows git in the first place - but it's good to know where the two versions don't agree I can't say which version is at fault for the inconsistency On Sunday, April 12, 2020, 09:17:32 AM EDT, Steven Penny wrote: > Will git contrib/subtree be in the next release? It's not in the latest > version 2.21.0-1. https://stackoverflow.com/questions/27109525/install-git-subtree-with-cygwin -- 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: Request package updates for Poppler, Subversion and Git
> Will git contrib/subtree be in the next release? It's not in the latest > version 2.21.0-1. https://stackoverflow.com/questions/27109525/install-git-subtree-with-cygwin -- 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: Request package updates for Poppler, Subversion and Git
Will git contrib/subtree be in the next release? It's not in the latest version 2.21.0-1. -- 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: Cygwin/X XWinrc menu no longer launches after recent updates
On 3/3/2020 8:12 PM, Roland Roberts wrote: On 3/3/2020 7:59 AM, Takashi Yano wrote: On Tue, 03 Mar 2020 12:40:17 + "Henry S. Thompson" wrote: Takashi Yano writes: This bug was already fixed in current git head. Current git head for Cygwin? Or mintty? I mean cygwin. Because I have another box, and now see that the bug does _not_ occur with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is with Cygwin 3.1.4 _and_ mintty 3.1.4. In my environment, your problem does not occur even with cygwin 3.1.4 and mintty 3.1.4. So I am not sure what is the real cause. Well, for me it *does* happen with cygwin 3.1.4 and mintty 3.1.4. I tried rolling back just mintty to 3.1.0 and it still happened. Then I rolled both of them back and it no longer happens, at least on one of my systems where I am *not* running sshd. Now to go try the other one For me, it is sufficient to roll back just cygwin to 3.1.0. The mintty version does not matter at all. roland "--Problem reports: http://cygwin.com/problems.htmlFAQ: http://cygwin.com/faq/Documentation: http://cygwin.com/docs.htmlUnsubscribe info: http://cygwin.com/ml/#unsubscribe-simple";
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Brian Inglis writes:
> On 2020-03-03 15:02, Henry S. Thompson wrote:
>> cygcheck output attached, just in case...
>>
>> Per previous message, had to interrupt id, which was hanging, which
>> produced
>>
>> garbled output from "id" command - no uid= found
And yes, I inadvertently left out the 'cmd' line in the previous message.
> ...
> that can be affected by {HKLM,HKCU}/Software/Microsoft/Command Processor/
> registry entries e.g.:
>
> $ regtool list -v
> /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command\ Processor
> ...
> $ regtool list -v
> /proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Command\ Processor/
> Autorun (REG_EXPAND_SZ) = "@chcp 65001 >nul"
> ...
> runs chcp 65001 at cmd startup, but could also do much more and different.
Thanks, but mine are the same as yours, except _no_ Autorun in either
case, so I don't _think_ that's a possible source of the problem...
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 15:02, Henry S. Thompson wrote:
> cygcheck output attached, just in case...
>
> Per previous message, had to interrupt id, which was hanging, which
> produced
>
> garbled output from "id" command - no uid= found
>
> while cygcheck carried on...
> and then hung with Process Explorer showing
>
> bash.exe
> bash.exe
> cygcheck.exe
>cmd.exe
> cygrunsrv.exe
As cygcheck is a Windows msvcrt.dll program, not a Cygwin cygwin1.dll program,
it uses Windows popen which runs commands under $COMSPEC rather than $SHELL, and
that can be affected by {HKLM,HKCU}/Software/Microsoft/Command Processor/
registry entries e.g.:
$ regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command\
Processor/
DefaultColor (REG_DWORD) = 0x (0)
EnableExtensions (REG_DWORD) = 0x0001 (1)
CompletionChar (REG_DWORD) = 0x0040 (64)
PathCompletionChar (REG_DWORD) = 0x0040 (64)
$ regtool list -v /proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Command\
Processor/
Autorun (REG_EXPAND_SZ) = "@chcp 65001 >nul"
CompletionChar (REG_DWORD) = 0x0009 (9)
DefaultColor (REG_DWORD) = 0x (0)
EnableExtensions (REG_DWORD) = 0x0001 (1)
PathCompletionChar (REG_DWORD) = 0x0009 (9)
runs chcp 65001 at cmd startup, but could also do much more and different.
--
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.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 3/3/2020 7:59 AM, Takashi Yano wrote: On Tue, 03 Mar 2020 12:40:17 + "Henry S. Thompson" wrote: Takashi Yano writes: This bug was already fixed in current git head. Current git head for Cygwin? Or mintty? I mean cygwin. Because I have another box, and now see that the bug does _not_ occur with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is with Cygwin 3.1.4 _and_ mintty 3.1.4. In my environment, your problem does not occur even with cygwin 3.1.4 and mintty 3.1.4. So I am not sure what is the real cause. Well, for me it *does* happen with cygwin 3.1.4 and mintty 3.1.4. I tried rolling back just mintty to 3.1.0 and it still happened. Then I rolled both of them back and it no longer happens, at least on one of my systems where I am *not* running sshd. Now to go try the other one roland -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Brian Inglis writes: >> 2) There are some hints that cygrunsrv/cygserver might be implicated. >> Two cygchecks on one of my machines (which did run to completion) >> differ in that the one taken while XWin had started successfully >> differed from the other in that all my Cygwin services (cron, >> cygserver, sshd, and exim) were stopped, >> In the other, a case of XWin hang, they were all running. >> >> On my other system after several fails in a row, I stopped all my >> services and XWin launched successfully. >> >> Grasping at straws here, but I have one machine sitting in a hung state, >> and other debugging ideas welcome... > > XWin startup takes different paths depending on whether you have sshd > running or not. Ah, interesting. > I also have cygserver defined with max supported threads, as I have > cron jobs which need them. I can often get multiwindow X to launch > from mintty with sshd disabled, after deleting: > $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- > srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= > ... Just stopping sshd didn't do it, I did eventually have to kill all 4 of my services (cron, cygserver, exim, sshd). But, I only did one trial after stopping each one, starting with sshd, so this isn't definitive... ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 10:21, Henry S. Thompson wrote: > Takashi Yano writes: > >> On Tue, 03 Mar 2020 12:40:17 + >> "Henry S. Thompson" wrote: >>> Takashi Yano writes: This bug was already fixed in current git head. >>> >>> Current git head for Cygwin? Or mintty? >> >> I mean cygwin. > > OK, this is now getting very weird. As at least one other person > reported, the problem is intermittent, with both my systems, both on > 3.1.4 Cygwin and 3.1.4 mintty. > > Two further shots in the dark: > > 1) I tried to run cygcheck -s while there was an XWin + sh hang, as > previously reported. It hung also. Process Explorer shows > > bash.exe > bash.exe > cygcheck.exe >id.exe > > I can use strace to attach to it, and it is indeed > [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being > created and exiting happily, last two lines are > > thread nnn created > _cygtls::remove: wait 0 > > Mystery > > So, try connecting strace to the hung sh process... > > [Nothing :-[ > > Connecting to it with gdb shows various threads, but ^C doesn't > achieve anything. > > 2) There are some hints that cygrunsrv/cygserver might be implicated. > Two cygchecks on one of my machines (which did run to completion) > differ in that the one taken while XWin had started successfully > differed from the other in that all my Cygwin services (cron, > cygserver, sshd, and exim) were stopped, > In the other, a case of XWin hang, they were all running. > > On my other system after several fails in a row, I stopped all my > services and XWin launched successfully. > > Grasping at straws here, but I have one machine sitting in a hung state, > and other debugging ideas welcome... XWin startup takes different paths depending on whether you have sshd running or not. I also have cygserver defined with max supported threads, as I have cron jobs which need them. I can often get multiwindow X to launch from mintty with sshd disabled, after deleting: $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- -r--r--r-- 1 11 Mar 2 00:20 /tmp/.X0-lock srwxrwxrwx 1 0 Mar 2 14:27 /tmp/dbus-5P1mCxSjEA= srwxrwxrwx 1 0 Mar 2 00:20 /tmp/dbus-JEIRS3qks6= srwxrwxrwx 1 0 Mar 2 12:34 /tmp/dbus-K5HWAHFshg= srwxrwxrwx 1 0 Mar 3 10:34 /tmp/dbus-pvf4OTaHDu= srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= srwxrwxrwx 1 0 Mar 2 14:01 /tmp/dbus-TFjEzRHU4c= srwxrwxrwx 1 0 Mar 2 14:26 /tmp/dbus-VsXRfGI5GT= srwxrwxrwx 1 0 Mar 2 12:37 /tmp/dbus-Zo1S6Q5MSG= srw--- 1 0 Mar 2 00:20 /tmp/fam-$USER/fam-= /tmp/.X11-unix: total 1.0K srw-rw-rw- 1 0 Mar 2 00:20 X0= -rw--- 1 0 Mar 2 00:20 X0.lock -- 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. -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 10:21, Henry S. Thompson wrote: > Takashi Yano writes: > >> On Tue, 03 Mar 2020 12:40:17 + >> "Henry S. Thompson" wrote: >>> Takashi Yano writes: This bug was already fixed in current git head. >>> >>> Current git head for Cygwin? Or mintty? >> >> I mean cygwin. > > OK, this is now getting very weird. As at least one other person > reported, the problem is intermittent, with both my systems, both on > 3.1.4 Cygwin and 3.1.4 mintty. > > Two further shots in the dark: > > 1) I tried to run cygcheck -s while there was an XWin + sh hang, as > previously reported. It hung also. Process Explorer shows > > bash.exe > bash.exe > cygcheck.exe >id.exe > > I can use strace to attach to it, and it is indeed > [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being > created and exiting happily, last two lines are > > thread nnn created > _cygtls::remove: wait 0 > > Mystery > > So, try connecting strace to the hung sh process... > > [Nothing :-[ > > Connecting to it with gdb shows various threads, but ^C doesn't > achieve anything. > > 2) There are some hints that cygrunsrv/cygserver might be implicated. > Two cygchecks on one of my machines (which did run to completion) > differ in that the one taken while XWin had started successfully > differed from the other in that all my Cygwin services (cron, > cygserver, sshd, and exim) were stopped, > In the other, a case of XWin hang, they were all running. > > On my other system after several fails in a row, I stopped all my > services and XWin launched successfully. > > Grasping at straws here, but I have one machine sitting in a hung state, > and other debugging ideas welcome... XWin startup takes different paths depending on whether you have sshd running or not. I also have cygserver defined with max supported threads, as I have cron jobs which need them. I can often get multiwindow X to launch from mintty with sshd disabled, after deleting: $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- -r--r--r-- 1 11 Mar 2 00:20 /tmp/.X0-lock srwxrwxrwx 1 0 Mar 2 14:27 /tmp/dbus-5P1mCxSjEA= srwxrwxrwx 1 0 Mar 2 00:20 /tmp/dbus-JEIRS3qks6= srwxrwxrwx 1 0 Mar 2 12:34 /tmp/dbus-K5HWAHFshg= srwxrwxrwx 1 0 Mar 3 10:34 /tmp/dbus-pvf4OTaHDu= srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= srwxrwxrwx 1 0 Mar 2 14:01 /tmp/dbus-TFjEzRHU4c= srwxrwxrwx 1 0 Mar 2 14:26 /tmp/dbus-VsXRfGI5GT= srwxrwxrwx 1 0 Mar 2 12:37 /tmp/dbus-Zo1S6Q5MSG= srw--- 1 0 Mar 2 00:20 /tmp/fam-$USER/fam-= /tmp/.X11-unix: total 1.0K srw-rw-rw- 1 0 Mar 2 00:20 X0= -rw--- 1 0 Mar 2 00:20 X0.lock -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > On Tue, 03 Mar 2020 12:40:17 + > "Henry S. Thompson" wrote: >> Takashi Yano writes: >> > This bug was already fixed in current git head. >> >> Current git head for Cygwin? Or mintty? > > I mean cygwin. OK, this is now getting very weird. As at least one other person reported, the problem is intermittent, with both my systems, both on 3.1.4 Cygwin and 3.1.4 mintty. Two further shots in the dark: 1) I tried to run cygcheck -s while there was an XWin + sh hang, as previously reported. It hung also. Process Explorer shows bash.exe bash.exe cygcheck.exe id.exe I can use strace to attach to it, and it is indeed [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being created and exiting happily, last two lines are thread nnn created _cygtls::remove: wait 0 Mystery So, try connecting strace to the hung sh process... [Nothing :-[ Connecting to it with gdb shows various threads, but ^C doesn't achieve anything. 2) There are some hints that cygrunsrv/cygserver might be implicated. Two cygchecks on one of my machines (which did run to completion) differ in that the one taken while XWin had started successfully differed from the other in that all my Cygwin services (cron, cygserver, sshd, and exim) were stopped, In the other, a case of XWin hang, they were all running. On my other system after several fails in a row, I stopped all my services and XWin launched successfully. Grasping at straws here, but I have one machine sitting in a hung state, and other debugging ideas welcome... ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 03 Mar 2020 12:40:17 + "Henry S. Thompson" wrote: > Takashi Yano writes: > > This bug was already fixed in current git head. > > Current git head for Cygwin? Or mintty? I mean cygwin. > Because I have another box, and now see that the bug does _not_ occur > with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is > with Cygwin 3.1.4 _and_ mintty 3.1.4. In my environment, your problem does not occur even with cygwin 3.1.4 and mintty 3.1.4. So I am not sure what is the real cause. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > On Tue, 03 Mar 2020 12:18:44 + > "Henry S. Thompson" wrote: >> Takashi Yano writes: >> >> > Does reverting cygwin1.dll to 3.1.2 help? >> >> In my case, yes it does. The resulting view from pstree is >> >> `-sh,1614 /usr/bin/startxwin >> `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... >> |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 >> `-sh,1652 /home/ht/.Xclients >> |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients >> `-xterm,1665 -geometry +0+60 -ls >> `-bash,1666 >> `-sh,1684 /home/ht/bin/goE -Y >> `-ssh,1685 ecclerig.inf.ed.ac.uk -Y >> >> Compare this to the 3.1.4 result: >> >> `-sh,2027 /usr/bin/startxwin >> `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow >> -auth ... >> |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 >> `-sh,2065 > > Then, this may be caused by the same bug as > https://www.cygwin.com/ml/cygwin/2020-02/msg00197.html > > This bug was already fixed in current git head. Current git head for Cygwin? Or mintty? Because I have another box, and now see that the bug does _not_ occur with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is with Cygwin 3.1.4 _and_ mintty 3.1.4. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 03 Mar 2020 12:18:44 + "Henry S. Thompson" wrote: > Takashi Yano writes: > > > Does reverting cygwin1.dll to 3.1.2 help? > > In my case, yes it does. The resulting view from pstree is > > `-sh,1614 /usr/bin/startxwin > `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... > |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 > `-sh,1652 /home/ht/.Xclients > |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients > `-xterm,1665 -geometry +0+60 -ls > `-bash,1666 > `-sh,1684 /home/ht/bin/goE -Y > `-ssh,1685 ecclerig.inf.ed.ac.uk -Y > > Compare this to the 3.1.4 result: > > `-sh,2027 /usr/bin/startxwin > `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth > ... > |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 > `-sh,2065 Then, this may be caused by the same bug as https://www.cygwin.com/ml/cygwin/2020-02/msg00197.html This bug was already fixed in current git head. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > Does reverting cygwin1.dll to 3.1.2 help? In my case, yes it does. The resulting view from pstree is `-sh,1614 /usr/bin/startxwin `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 `-sh,1652 /home/ht/.Xclients |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients `-xterm,1665 -geometry +0+60 -ls `-bash,1666 `-sh,1684 /home/ht/bin/goE -Y `-ssh,1685 ecclerig.inf.ed.ac.uk -Y Compare this to the 3.1.4 result: `-sh,2027 /usr/bin/startxwin `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth ... |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 `-sh,2065 ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 3 Mar 2020 00:14:12 -0500 Roland Roberts wrote: > I only noticed this in the last week or so, and assumed I'd messed up > something with Windows 10 permission, which is still a possibility. My > first attempt to "fix" this was to reinstall pretty much everything in > Cygwin that was part of X11 or Base. And that seemed to fix > things...until I rebooted Windows. > > There are no errors in the logs, not stackdumps, nothign to indicate > anything is not working. The X log is below. You'll notice it says > > "executing '/bin/mintty', pid 3152" > > but that window never opens. If I start a shell directly via my desktop > shortcut, which has this as it's target > > C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - > > I can see that there is no PID 3152. Does reverting cygwin1.dll to 3.1.2 help? -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin/X XWinrc menu no longer launches after recent updates
I only noticed this in the last week or so, and assumed I'd messed up
something with Windows 10 permission, which is still a possibility. My
first attempt to "fix" this was to reinstall pretty much everything in
Cygwin that was part of X11 or Base. And that seemed to fix
things...until I rebooted Windows.
There are no errors in the logs, not stackdumps, nothign to indicate
anything is not working. The X log is below. You'll notice it says
"executing '/bin/mintty', pid 3152"
but that window never opens. If I start a shell directly via my desktop
shortcut, which has this as it's target
C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -
I can see that there is no PID 3152.
My .XWinrc is this:
.XWinrc
menu root {
"Cygwin Terminal" exec "/bin/mintty -e /bin/bash"
Emacs exec "/bin/emacs"
xterm exec "/bin/xterm"
notepad exec notepad
SEPARATOR
FAQEXEC "cygstart
http://x.cygwin.com/docs/faq/cygwin-x-faq.html";
"User's Guide" EXEC "cygstart
http://x.cygwin.com/docs/ug/cygwin-x-ug.html";
SEPARATOR
"View logfile" EXEC "xterm -title $XWINLOGFILE -e less +F $XWINLOGFILE"
SEPARATOR
"Reload .XWinrc"RELOAD
SEParATOR
}
RootMenu root
and my .startxwinrc is
.startxwinrc
if [ -f $HOME/.Xdefaults ]; then
xrdb -merge $HOME/.Xdefaults &
fi
sleep infinity
I'm lost on what might be causing this. One thing that I *did* change,
though that was over a month ago, was to add the Cygwin sshd service. On
the off-chance that that was the issue, I disabled it and rebooted to
get a clean start. No joy, I still can't launch from the .XWinrc menu.
The log entry makes it clear that it is seen and is trying.
Oh, and from a mintty shell, if I set DISPLAY=:0.0 when X is running, I
*can* launch other X apps.
2041 roland> cat XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18363 flamsteed 3.1.4-340.x86_64 2020-02-19 08:49 UTC
x86_64
OS: Windows 10 [Windows NT 10.0 build 18363] (Win64)
Package: version 1.20.5-3 built 2019-09-06
XWin was started with the following command line:
/usr/bin/XWin :0 -multiwindow -auth
/home/roland/.serverauth.2909
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 2560 h 1440
winInitializeScreenDefaults - native DPI x 96 y 96
[ 734.546] (II) xorg.conf is not supported
[ 734.546] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for
more information
[ 734.546] LoadPreferences: Loading /home/roland/.XWinrc
[ 734.562] winDetectSupportedEngines - RemoteSession: no
[ 734.625] winDetectSupportedEngines - DirectDraw4 installed, allowing
ShadowDDNL
[ 734.625] winDetectSupportedEngines - Returning, supported engines
0005
[ 734.625] winSetEngine - Multi Window or Rootless => ShadowGDI
[ 734.625] winScreenInit - Using Windows display depth of 32 bits per
pixel
[ 734.625] winAllocateFBShadowGDI - Creating DIB with width: 3760
height: 1920 depth: 32
[ 734.625] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[ 734.625] winInitVisualsShadowGDI - Masks 00ff ff00 00ff
BPRGB 8 d 24 bpp 32
[ 734.625] MIT-SHM extension disabled due to lack of kernel support
[ 734.625] XFree86-Bigfont extension local-client optimization
disabled due to lack of shared memory support in the kernel
[ 734.640] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[ 735.171] (II) AIGLX: Testing pixelFormatIndex 5
[ 735.265] GL_VERSION: 4.6.0 NVIDIA 425.91
[ 735.265] GL_VENDOR: NVIDIA Corporation
[ 735.265] GL_RENDERER:Quadro K1000M/PCIe/SSE2
[ 735.265] (II) GLX: enabled GLX_SGI_make_current_read
[ 735.265] (II) GLX: enabled GLX_SGI_swap_control
[ 735.265] (II) GLX: enabled GLX_MESA_swap_control
[ 735.265] (II) GLX: enabled GLX_SGIX_pbuffer
[ 735.265] (II) GLX: enabled GLX_ARB_multisample
[ 735.265] (II) GLX: enabled GLX_SGIS_multisample
[ 735.265] (II) GLX: enabled GLX_ARB_fbconfig_float
[ 735.265] (II) GLX: enabled GLX_EXT_fbconfig_packed_float
[ 735.265] (II) GLX: enabled GLX_ARB_create_context
[ 735.265] (II) GLX: enabled GLX_ARB_create_context_profile
[ 735.265] (II) GLX: enabled GLX_ARB_create_context_robustness
[ 735.265] (II) GLX: enabled GLX_EXT_create_context_es2_profile
[ 735.265] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 735.265] (II) 1182 pixel formats reported by
wglGetPixelFormatAttribivARB
[ 735.296] (II) 1146 fbConfigs
[ 735.296] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel
type, 36 unaccelerated
[ 735.296] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[ 735.562] winPointerWarpCursor - Discarding first warp: 1880 960
[ 735.562] (--) 5 mouse buttons found
[ 735.562] (--) Setting autorepeat to delay=500, rate=31
[ 735.562] (--) Windows keyboard layout: "0409" (0409) "US",
type 7
[ 735.562] (--) Found matching XKB configuration "English (USA)"
[ 7
Re: Cygwin-X shortcut no longer works after recent updates
On 2/28/20 8:21 AM, Brian Inglis wrote: > Hi folks, > > After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the > Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, although > I > can start Cygwin-X by running startxwin from a mintty window. > >>From the shortcut, the shell is invoked to run startxwin normally, two copies >>of > xinit fork, and Xwin runs and displays the start tray Xserver icon, but my > mintty terminal and the xwin-xdg-menu clients don't start. I think I am seeing the same problem. Here are a few observations. 1) The issue happens often, but not always, when starting with the Windows shortcut. Currently, I am retrying a few times until the startup works. I have been unable to reproduce the issue starting startxwin from a mintty window. 2) XWin always seems to start fine. 3) If the issue comes up, I am always seeing the following hanging process tree. 3969 cons0S 0:00 \_ xinit ... 3970 cons0S 0:00 \_ /usr/bin/XWin ... 3974 ?Ss 0:00 \_ /usr/bin/sh In Windows, this looks like so. C:\cygwin64\bin\xinit.exe \_ C:\cygwin64\bin\xinit.exe \_ C:\cygwin64\bin\sh.exe C:\cygwin64\bin\XWin.exe Currently, I am killing the defunct sh, which seems to properly clean up everything, and try again. Ron -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin-X shortcut no longer works after recent updates
Jon Turney writes: > On 28/02/2020 07:21, Brian Inglis wrote: >> Hi folks, >> >> After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the >> Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, >> although I >> can start Cygwin-X by running startxwin from a mintty window. Ditto. > Two copies of xinit suggests to me that it is getting stuck somewhere > in the cygwin fork/exec of /etc/X11/xinit/startxwinrc (which in turn > starts ~/.startxwinrc if it exists) to start clients. A bit more detail, from pstree -Aap: |-sh,2027 /usr/bin/startxwin | `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth ... | |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 | `-sh,2065 >> My .startxwinrc is a copy of /etc/X11/xinit/startxwinrc with addition of the >> minnty terminal startup in bg before leaving xwin-xdg-menu running in fg. Mine was just a two-liner, changing it to none or /etc/X11/xint/startxwinrc has no effect. Aha. A similar problem occurs with xemacs when launched from a shortcut with command H:\C64\bin\run.exe -p /home/ht/bin:/usr/local/bin:/usr/bin /usr/local/bin/xemacs-21.5-b34.exe The common denominator is clearer run.exe -- does that give anyone a useful clue? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin-X shortcut no longer works after recent updates
On 28/02/2020 07:21, Brian Inglis wrote: Hi folks, After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, although I can start Cygwin-X by running startxwin from a mintty window. From the shortcut, the shell is invoked to run startxwin normally, two copies of xinit fork, and Xwin runs and displays the start tray Xserver icon, but my mintty terminal and the xwin-xdg-menu clients don't start. Two copies of xinit suggests to me that it is getting stuck somewhere in the cygwin fork/exec of /etc/X11/xinit/startxwinrc (which in turn starts ~/.startxwinrc if it exists) to start clients. On exiting the X server, the processes are left running and have to be killed off. There are sockets and lock files, which are left around after termination: $ llgo /tmp/.X11-unix/X0* srw-rw-rw- 1 0 Feb 27 23:11 /tmp/.X11-unix/X0= -rw--- 1 0 Feb 27 23:11 /tmp/.X11-unix/X0.lock The server log /var/log/xwin/XWin.0.log looks normal, and nothing shows in ~/.xsession-errors. My .startxwinrc is a copy of /etc/X11/xinit/startxwinrc with addition of the minnty terminal startup in bg before leaving xwin-xdg-menu running in fg. The shortcut and processes when started normally look like: C:\...\cygwin64\bin\run.exe --quote /bin/sh -l -c "cd; exec /usr/bin/startxwin" /bin/sh /usr/bin/startxwin \_ xinit /home/$USER/.startxwinrc -- /usr/bin/XWin ... [as below] \_ /usr/bin/XWin :0 -multiwindow -auth /home/$USER/.serverauth.$PGID I have checked the man pages and the Cygwin-X docs for hints about things to check and try with little success. Hints and suggestions about possible problems and problem solving approaches would be appreciated. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin-X shortcut no longer works after recent updates
Hi folks, After the recent upgrades to cygwin 3.1.4, perl, etc. I have found that the Cygwin-X Startup, Start Menu, and Task Bar shortcuts no longer work, although I can start Cygwin-X by running startxwin from a mintty window. >From the shortcut, the shell is invoked to run startxwin normally, two copies >of xinit fork, and Xwin runs and displays the start tray Xserver icon, but my mintty terminal and the xwin-xdg-menu clients don't start. On exiting the X server, the processes are left running and have to be killed off. There are sockets and lock files, which are left around after termination: $ llgo /tmp/.X11-unix/X0* srw-rw-rw- 1 0 Feb 27 23:11 /tmp/.X11-unix/X0= -rw--- 1 0 Feb 27 23:11 /tmp/.X11-unix/X0.lock The server log /var/log/xwin/XWin.0.log looks normal, and nothing shows in ~/.xsession-errors. My .startxwinrc is a copy of /etc/X11/xinit/startxwinrc with addition of the minnty terminal startup in bg before leaving xwin-xdg-menu running in fg. The shortcut and processes when started normally look like: C:\...\cygwin64\bin\run.exe --quote /bin/sh -l -c "cd; exec /usr/bin/startxwin" /bin/sh /usr/bin/startxwin \_ xinit /home/$USER/.startxwinrc -- /usr/bin/XWin ... [as below] \_ /usr/bin/XWin :0 -multiwindow -auth /home/$USER/.serverauth.$PGID I have checked the man pages and the Cygwin-X docs for hints about things to check and try with little success. Hints and suggestions about possible problems and problem solving approaches would be appreciated. -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
Thanks for your help. It is probably better to wait for next perl 5.30.1 release that should be available soon. Next package that I am not able to build by myself concerns poppler package as lot of library dependencies are not resolved. -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
Adam Dinwoodie writes: >> Git isn't affected because it sets up @INC itself and doesn't have >> architecture-specific modules. > > I'd therefore been assuming that I didn't need to worry about syncing > a Git release with the Perl update; have I misunderstood what's going > on here? I haven't looked at the new Git version in detail, but it's probably the still true, given that it loses some more dependencies on Perl with each release rather than picking up new ones. What I was getting at with that remark is that the existing Git doesn't stop working when updating Perl, not how a future version (which I haven't yet seen) behaves. Also as discussed before it would really be better if the packaging was done without these nested Perl modules since it they can used as an interface to Git which the Perl as installed doesn't know about since it isn't in the usual search path. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
Hi Achim, On Sun, 22 Dec 2019 at 17:50, Achim Gratz wrote: > > Am 22.12.2019 um 13:50 schrieb Adam Dinwoodie: > > Acknowledged for Git. I'll try and get a new release out before the new > > year. > > Keep in mind you will then have to re-do it just after the new year for > the Perl update. Just realised I hadn't replied to this, sorry! On the apps list, on the topic of package updates for the Perl switch, you said > Git isn't affected because it sets up @INC itself and doesn't have > architecture-specific modules. I'd therefore been assuming that I didn't need to worry about syncing a Git release with the Perl update; have I misunderstood what's going on here? Adam PS: I am once again battling a bunch of test failures, as I prefer to not release a Git build with undiagnosed failures in the test suite when it's the official Cygwin distribution. I'm slowly working my way through the problems, but there is ongoing progress on getting a new release out. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
On Sun, 22 Dec 2019 18:50:34 +0100, Achim Gratz wrote: > Keep in mind you will then have to re-do it just after the new year for > the Perl update. Not necessarily. I know people have disagreed with this in the past, but I have looked at this again and it seems that not all distros require Perl with a Git install. For example Fedora "git-core" only requires: Requires: less Requires: openssh-clients Requires: zlib >= 1.2 https://apps.fedoraproject.org/packages/git/sources/spec Some notable scripts would not work, like "git add --interactive", but Cygwin could have a "git" and "git-core" to deal with that. Personally I have installed Git without Perl for some years without issue. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
Am 22.12.2019 um 13:50 schrieb Adam Dinwoodie: Acknowledged for Git. I'll try and get a new release out before the new year. Keep in mind you will then have to re-do it just after the new year for the Perl update. -- Achim. (on the road :-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
On Fri, 20 Dec 2019 at 15:21, Kptain wrote: > > Hi all, > > I don't know who are the maintainer(s), > but it would be great if these packages could be updated: > > - latest versions are: > > . Git 2.24.1 > . Subversion 1.13.0 > . Poppler 0.83 > > > It'd be great if it could be refreshed in Cygwin. Acknowledged for Git. I'll try and get a new release out before the new year. Adam -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
On Fri, 20 Dec 2019 17:20:26 +0100, Marco Atzeri wrote: > The other two are maintained by Yaakov, that seems at the moment > a bit busy with other activities. No, they arent: https://cygwin.com/packages/summary/git.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request package updates for Poppler, Subversion and Git
Am 20.12.2019 um 16:38 schrieb Kptain: Hi all, I don't know who are the maintainer(s), but it would be great if these packages could be updated: - latest versions are: . Git 2.24.1 . Subversion 1.13.0 . Poppler 0.83 It'd be great if it could be refreshed in Cygwin. Thanks in advance, Stephan the maintainer is reported on the package summary: https://cygwin.com/packages/summary/subversion.html For subversion David was looking for someone to adopt it https://cygwin.com/ml/cygwin-apps/2019-11/msg8.html may be you are interested ? See for detail https://cygwin.com/packaging-contributors-guide.html The other two are maintained by Yaakov, that seems at the moment a bit busy with other activities. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Request package updates for Poppler, Subversion and Git
Hi all, I don't know who are the maintainer(s), but it would be great if these packages could be updated: - latest versions are: . Git 2.24.1 . Subversion 1.13.0 . Poppler 0.83 It'd be great if it could be refreshed in Cygwin. Thanks in advance, Stephan -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python pip/setuptools/virtualenv/wheel updates
The following packages have been uploaded to the Cygwin distribution: * python27-pip-19.2.3-1 * python35-pip-19.2.3-1 * python36-pip-19.2.3-1 * python38-pip-19.2.3-1 * python37-pip-19.2.3-1 * python-pip-wheel-19.2.3-1 * python27-setuptools-41.2.0-1 * python35-setuptools-41.2.0-1 * python36-setuptools-41.2.0-1 * python37-setuptools-41.2.0-1 * python38-setuptools-41.2.0-1 * python-setuptools-wheel-41.2.0-1 * python27-virtualenv-16.7.5-1 * python35-virtualenv-16.7.5-1 * python36-virtualenv-16.7.5-1 * python37-virtualenv-16.7.5-1 * python38-virtualenv-16.7.5-1 * python27-wheel-0.33.6-1 * python35-wheel-0.33.6-1 * python36-wheel-0.33.6-1 * python37-wheel-0.33.6-1 * python38-wheel-0.33.6-1 * python-wheel-wheel-0.33.6-1 This is an update to the latest versions of these Python packages. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
On 13/09/2019 19:53, Andrey Repin wrote: > Greetings, Hamish MB! > >> On 13/09/2019 01:41, Andrey Repin wrote: >>> Greetings, Hamish MB! >>> >>> Please no top-posting in this channel. >>> Note: I've just realised this only happens when 3D acceleration is enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a Cygwin bug. Thoughts? >>> What video mode did you select for your system? >>> Which driver (standard or improved) did you install? >>> >> Thanks for letting me know about the top-posting. I'll see if my email >> client has a setting to disable that by default. >> I'm using the "VBoxSVGA" mode, but I also tried the "VBoxVGA" mode. I'm >> using the standard 3D driver, not the experimental one that supports >> Aero because that didn't work well for me. > I've found "experimental" one working quite well for the last decade. > 128MB+ Video RAM, enabled 3D acceleration… There's minor issues with canvas > redraw of some apps, but nothing crash-level. Yeah, it did that for me too, but I guess I find it more annoying :) It seems after the latest update to Virtualbox and the guest additions, this is now working again. If it stops, I'll reply again, but I reckon this was probably a problem with Virtualbox. Hamish -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
Greetings, Hamish MB! > On 13/09/2019 01:41, Andrey Repin wrote: >> Greetings, Hamish MB! >> >> Please no top-posting in this channel. >> >>> Note: I've just realised this only happens when 3D acceleration is >>> enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a >>> Cygwin bug. Thoughts? >> What video mode did you select for your system? >> Which driver (standard or improved) did you install? >> > Thanks for letting me know about the top-posting. I'll see if my email > client has a setting to disable that by default. > I'm using the "VBoxSVGA" mode, but I also tried the "VBoxVGA" mode. I'm > using the standard 3D driver, not the experimental one that supports > Aero because that didn't work well for me. I've found "experimental" one working quite well for the last decade. 128MB+ Video RAM, enabled 3D acceleration… There's minor issues with canvas redraw of some apps, but nothing crash-level. -- With best regards, Andrey Repin Friday, September 13, 2019 21:51:02 Sorry for my terrible english...
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
On 13/09/2019 01:41, Andrey Repin wrote: > Greetings, Hamish MB! > > Please no top-posting in this channel. > >> Note: I've just realised this only happens when 3D acceleration is >> enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a >> Cygwin bug. Thoughts? > What video mode did you select for your system? > Which driver (standard or improved) did you install? > Thanks for letting me know about the top-posting. I'll see if my email client has a setting to disable that by default. I'm using the "VBoxSVGA" mode, but I also tried the "VBoxVGA" mode. I'm using the standard 3D driver, not the experimental one that supports Aero because that didn't work well for me. Hamish
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
Greetings, Hamish MB! Please no top-posting in this channel. > Note: I've just realised this only happens when 3D acceleration is > enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a > Cygwin bug. Thoughts? What video mode did you select for your system? Which driver (standard or improved) did you install? -- With best regards, Andrey Repin Friday, September 13, 2019 3:40:36 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
Note: I've just realised this only happens when 3D acceleration is enabled in VirtualBox, hence this may be a VirtualBox bug, rather than a Cygwin bug. Thoughts? Hamish On 12/09/2019 12:33, Hamish McIntyre-Bhatty wrote: > Okay, so after the latest set of updates, this still seems to happen. > Attached is the XWin.0.log file. I am running this in Virtualbox, so it > is possible that this issue has something to do with that? > > Hamish > > On 07/09/2019 19:50, Hamish McIntyre-Bhatty wrote: >> I was starting with "startxwin &" in the Cygwin terminal. Is this the >> wrong way to do it? >> >> I'll try that soon and get back to you. >> >> This was before the latest set of updates to Xorg and the openGL >> libraries, so it could be that it had something to do with the missing >> libEGL dependency - I will try again now, and hopefully it will work >> :). If it's any help, I'm running Cygwin on Windows 7. >> >> Hamish >> >> On 07/09/2019 16:11, Jon Turney wrote: >>> On 05/09/2019 11:28, Hamish MB wrote: >>>> libraries. Additionally, the xwin server refuses to start if more than >>>> one display is present, for reasons I don't understand. >>> That is unusual. >>> >>> I assume you are trying to start via the start menu shortcut? >>> >>> Does starting it as 'XWin -multiwindow' work? >>> >>> If not, can you provide the /var/log/xwin/XWin.0.log? >>> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
Okay, so after the latest set of updates, this still seems to happen. Attached is the XWin.0.log file. I am running this in Virtualbox, so it is possible that this issue has something to do with that? Hamish On 07/09/2019 19:50, Hamish McIntyre-Bhatty wrote: > I was starting with "startxwin &" in the Cygwin terminal. Is this the > wrong way to do it? > > I'll try that soon and get back to you. > > This was before the latest set of updates to Xorg and the openGL > libraries, so it could be that it had something to do with the missing > libEGL dependency - I will try again now, and hopefully it will work > :). If it's any help, I'm running Cygwin on Windows 7. > > Hamish > > On 07/09/2019 16:11, Jon Turney wrote: >> On 05/09/2019 11:28, Hamish MB wrote: >>> libraries. Additionally, the xwin server refuses to start if more than >>> one display is present, for reasons I don't understand. >> >> That is unusual. >> >> I assume you are trying to start via the start menu shortcut? >> >> Does starting it as 'XWin -multiwindow' work? >> >> If not, can you provide the /var/log/xwin/XWin.0.log? >> Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.20.4.0 OS: CYGWIN_NT-6.1-7601 Hamish-PC 3.0.7-338.x86_64 2019-04-30 18:08 UTC x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.20.4-1 built 2019-03-15 XWin was started with the following command line: XWin -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 920 winInitializeScreenDefaults - native DPI x 96 y 96 [ 392.984] (II) xorg.conf is not supported [ 392.984] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 392.984] LoadPreferences: /home/Hamish/.XWinrc not found [ 392.984] LoadPreferences: Loading /etc/X11/system.XWinrc [ 392.984] LoadPreferences: Done parsing the configuration file... [ 392.984] winDetectSupportedEngines - RemoteSession: no [ 393.000] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 393.000] winDetectSupportedEngines - Returning, supported engines 0005 [ 393.000] winSetEngine - Multi Window or Rootless => ShadowGDI [ 393.000] winScreenInit - Using Windows display depth of 24 bits per pixel [ 393.000] winScreenInit - Monitors do not all have same pixel format / display depth. [ 393.000] winScreenInit - Performance may suffer off primary display. [ 393.015] winQueryRGBBitsAndMasks - GetDeviceCaps (BITSPIXEL) returned 24 for the screen. Using default 24bpp masks. [ 393.015] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 986 depth: 24 [ 393.015] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 393.015] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 24 [ 393.015] winFinishScreenInitFB - fbFinishScreenInit failed [ 393.015] winScreenInit - winFinishScreenInit () failed [ 393.015] (EE) Fatal server error: [ 393.015] (EE) InitOutput - Couldn't add screen 0(EE) [ 393.015] (EE) Server terminated with error (1). Closing log file. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
I was starting with "startxwin &" in the Cygwin terminal. Is this the wrong way to do it? I'll try that soon and get back to you. This was before the latest set of updates to Xorg and the openGL libraries, so it could be that it had something to do with the missing libEGL dependency - I will try again now, and hopefully it will work :). If it's any help, I'm running Cygwin on Windows 7. Hamish On 07/09/2019 16:11, Jon Turney wrote: > On 05/09/2019 11:28, Hamish MB wrote: >> libraries. Additionally, the xwin server refuses to start if more than >> one display is present, for reasons I don't understand. > > That is unusual. > > I assume you are trying to start via the start menu shortcut? > > Does starting it as 'XWin -multiwindow' work? > > If not, can you provide the /var/log/xwin/XWin.0.log? >
Re: Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
On 05/09/2019 11:28, Hamish MB wrote: libraries. Additionally, the xwin server refuses to start if more than one display is present, for reasons I don't understand. That is unusual. I assume you are trying to start via the start menu shortcut? Does starting it as 'XWin -multiwindow' work? If not, can you provide the /var/log/xwin/XWin.0.log? -- Jon Turney Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Issues with multiple displays and openGL libraries after latest updates to X, GL, and Mesa
Hello, After installing the latest updates to cygwin, including the new X server, openGL libraries, and mesa, I'm having issues with a configure script that was previously working. It no longer finds the openGL libraries. Additionally, the xwin server refuses to start if more than one display is present, for reasons I don't understand. If it's of any use, the package I'm trying to build is wxWidgets 3.0.4, in the hope of eventually getting it and wxPython 4 into the cygwin package repositories. This happens on both the 32-bit and 64-bit versions of Cygwin. Does anyone have any idea why this could be happening? Hamish
Re: SSHD Service shuts down after a while after latest library updates
On Sun, May 12, 2019 at 8:31 AM L A Walsh wrote: > This has been a feature of Windows since win98. Not officially, mind > you, but any scheduled task in windows would eventually become > unscheduled and stop running with out any notification. I've never seen this behavior on any Windows machine (a scheduled task becoming unscheduled by itself), but in any case, this is irrelevant to the current question because scheduled tasks are not the same as Windows services (daemons). What we need to know is what is happening that would cause the service to stop running. As a test, you can stop the service (if it's not stopped already), and do the following: 1. Open Cygwin shell as administrator (right-click, "Run as administrator") 2. Run: cd /usr/sbin 3. Run: sshd -d -d -d This will run the service "interactively" and you can see what error occurs. Bill -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSHD Service shuts down after a while after latest library updates
On 5/12/2019 6:35 AM, Enrico.Bertram wrote: > \ > > The service is configured to start automatically and does so on each reboot. > The event viewer does not show any event (for example the "stopped" on > normal shutdowns) - the service is just in shut down state every now and > then and I have to manually start it again. > This has been a feature of Windows since win98. Not officially, mind you, but any scheduled task in windows would eventually become unscheduled and stop running with out any notification. The only way I found to get round this is by having a job login from a reliable server (like linux) multiple times/hour with a control login that attempts to remain logged in so that problems can be solved by the already logged in process. For the first time since Win98, I'm starting to get error reports when there are problems as well as notifications if there was a problem resetting my basic state. I may have to extend my monitoring and corrections since some are more involved, but sadly it was the only way I found out how to get prompt errors when things stopped working because Windows philosophy is to not report things in hope that the problem or need for the report will go away. Part of this stems from, for example in tools to regulate resources given to programs, only servers are allowed to do so, with the regulating software not running on Windows. There are some unsatisfactory third party options (Process Lasso) that do things like keep processes running or restart if they die -- things that the Windows service manager claims to do, but not always work. Windows on my machine hasn't been able to start the system log function for about 2-3 years -- with MS having no clue and only recommendation being to upgrade to win10. I have a few problem the MS was unable to solve for more than 3 years with similar outcomes. Very often the problems aren't fixed, but appear to be so because some do not trigger frequently. So if you want reliable debug and monitoring, use another OS like linux to monitor the flakey windows. (my 2 cents) Linda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SSHD Service shuts down after a while after latest library updates
I want to report an issue I see after updating the libraries to the latest versions. Some of them were security related (CA Certificates, crypto policies,...) Unfortunately I do not remember, which exact ones and if that may be a hint. OS: Win10 1809, Build 17763.475 Issue: CYGWIN sshd service shuts down after a while (~couple of hours) The service is configured to start automatically and does so on each reboot. The event viewer does not show any event (for example the "stopped" on normal shutdowns) - the service is just in shut down state every now and then and I have to manually start it again. Logging is unchanged until now in the sshd_config, and uses default settings: #SyslogFacility AUTH #LogLevel INFO Are there any hints on extended log settings to be able analyse further? Thanks, Enrico Bertram. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Japanese Official New Era Date Package Updates May Be Needed Tomorrow
On 2019-04-30 12:13, Corinna Vinschen wrote: > On Apr 30 18:26, Corinna Vinschen wrote: >> On Apr 30 07:00, Brian Inglis wrote: >>> Subpackages for sqlite3 and mingw may need updated from the latest ICU >>> release. >>> Packages unicode-cldr-emoji-annotation, unicode-ucd, and fonts used in >>> Japanese, >>> may also need updated as below. >>> Not sure if any GUI date or locale packages need updated. >>> >>> Add new Windows Era if you are on W10 1809, and maybe W7 and earlier, if >>> still >>> unpatched: >>> >>> HKLM_SYS_CCS_Control_Nls_Calendars_Japanese_Eras.reg >>> 8< -- >8 >>> Windows Registry Editor Version 5.00 >>> >>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] >>> "2019 05 01"="令和_㋿_Reiwa_R" >>> 8< -- >8 >>> >>> New era name gengo 令和/㋿/Reiwa/R announced Mar 31 goes into effect May 1 >>> R1.5.1 令和元年; H31.5.1 is an R1 bug; see >> >> The Cygwin era info is in Cygwin itself to be compatible with glibc, not >> fetched from Windows, . I have a patch in the loop to update Cygwin >> with the new era data, but a new Cygwin version may have to wait until >> June, sorry. > > No, it's ok, I'll release 3.0.7 today. Thanks - you beat the W10 1809 release channel update: https://support.microsoft.com/en-hk/help/4495667/windows-10-update-kb4495667 which includes the Era changes: https://support.microsoft.com/en-hk/help/4469068/summary-of-new-japanese-era-updates-kb4469068 -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Ruby module updates
The following packages have been uploaded to the Cygwin distribution: * ruby-crass-1.0.4-1 * ruby-crass-doc-1.0.4-1 * ruby-curses-1.2.7-1 * ruby-curses-doc-1.2.7-1 * ruby-dbus-0.14.1-1 * ruby-dbus-doc-0.14.1-1 * ruby-gettext-3.2.9-1 * ruby-gettext-doc-3.2.9-1 * ruby-hitimes-1.3.1-1 * ruby-hitimes-doc-1.3.1-1 * ruby-hoe-3.17.2-1 * ruby-hoe-doc-3.17.2-1 * ruby-hpricot-0.8.6-6 * ruby-hpricot-doc-0.8.6-6 * ruby-racc-1.4.14-3 * ruby-racc-doc-1.4.14-3 * ruby-rake-compiler-1.0.7-1 * ruby-rake-compiler-doc-1.0.7-1 * ruby-redis-3.3.5-1 * ruby-syck-1.4.0-1 * ruby-syck-doc-1.4.0-1 * ruby-timers-4.3.0-1 * ruby-timers-doc-4.3.0-1 * ruby-treetop-1.6.10-1 * ruby-treetop-doc-1.6.10-1 * ruby-yajl-1.4.1-1 * ruby-yajl-doc-1.4.1-1 * ruby-zoom-0.5.0-3 * ruby-zoom-doc-0.5.0-3 These Ruby module packages have been updated or rebuilt for Ruby 2.6. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Lua module updates
The following packages have been uploaded to the Cygwin distribution: * lua-crypto-0.3.2-3 * lua-crypto-devel-0.3.2-3 * lua-json-1.3.4-1 * lua-ldap-1.1.0-3 * lua-lfs-1.7.0.2-1 * lua-lgi-0.9.2-1 * lua-logging-1.3.0-2 * lua-lpeg-1.0.2-1 * lua-luadoc-3.0.1-2 * lua-lxp-1.3.0-2 * lua-socket-3.0-0.2.rc1 These Lua module packages have been updated or rebuilt for Lua 5.3. Please note that lua-bit is no longer built, as Lua 5.3 contains that functionality builtin. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Japanese Official New Era Date Package Updates May Be Needed Tomorrow
On Apr 30 18:26, Corinna Vinschen wrote: > On Apr 30 07:00, Brian Inglis wrote: > > Subpackages for sqlite3 and mingw may need updated from the latest ICU > > release. > > Packages unicode-cldr-emoji-annotation, unicode-ucd, and fonts used in > > Japanese, > > may also need updated as below. > > Not sure if any GUI date or locale packages need updated. > > > > Add new Windows Era if you are on W10 1809, and maybe W7 and earlier, if > > still > > unpatched: > > > > HKLM_SYS_CCS_Control_Nls_Calendars_Japanese_Eras.reg > > 8< -- >8 > > Windows Registry Editor Version 5.00 > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] > > "2019 05 01"="令和_㋿_Reiwa_R" > > 8< -- >8 > > > > New era name gengo 令和/㋿/Reiwa/R announced Mar 31 goes into effect May 1 > > R1.5.1 令和元年; H31.5.1 is an R1 bug; see > > The Cygwin era info is in Cygwin itself to be compatible with glibc, not > fetched from Windows, . I have a patch in the loop to update Cygwin > with the new era data, but a new Cygwin version may have to wait until > June, sorry. No, it's ok, I'll release 3.0.7 today. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Japanese Official New Era Date Package Updates May Be Needed Tomorrow
On Apr 30 07:00, Brian Inglis wrote: > Subpackages for sqlite3 and mingw may need updated from the latest ICU > release. > Packages unicode-cldr-emoji-annotation, unicode-ucd, and fonts used in > Japanese, > may also need updated as below. > Not sure if any GUI date or locale packages need updated. > > Add new Windows Era if you are on W10 1809, and maybe W7 and earlier, if still > unpatched: > > HKLM_SYS_CCS_Control_Nls_Calendars_Japanese_Eras.reg > 8< -- >8 > Windows Registry Editor Version 5.00 > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] > "2019 05 01"="令和_㋿_Reiwa_R" > 8< -- >8 > > New era name gengo 令和/㋿/Reiwa/R announced Mar 31 goes into effect May 1 > R1.5.1 令和元年; H31.5.1 is an R1 bug; see The Cygwin era info is in Cygwin itself to be compatible with glibc, not fetched from Windows, . I have a patch in the loop to update Cygwin with the new era data, but a new Cygwin version may have to wait until June, sorry. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Japanese Official New Era Date Package Updates May Be Needed Tomorrow
Subpackages for sqlite3 and mingw may need updated from the latest ICU release. Packages unicode-cldr-emoji-annotation, unicode-ucd, and fonts used in Japanese, may also need updated as below. Not sure if any GUI date or locale packages need updated. Add new Windows Era if you are on W10 1809, and maybe W7 and earlier, if still unpatched: HKLM_SYS_CCS_Control_Nls_Calendars_Japanese_Eras.reg 8< -- >8 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] "2019 05 01"="令和_㋿_Reiwa_R" 8< -- >8 New era name gengo 令和/㋿/Reiwa/R announced Mar 31 goes into effect May 1 R1.5.1 令和元年; H31.5.1 is an R1 bug; see https://en.wikipedia.org/wiki/Reiwa https://en.wikipedia.org/wiki/Japanese_era_name with support in CLDR 35.1, ICU 64.2, Unicode 12.1: http://cldr.unicode.org/index/downloads/cldr-35#TOC-V35.1 http://site.icu-project.org/download/64 https://www.unicode.org/Public/12.1.0/ucd/ -- 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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python module updates
The following packages have been uploaded to the Cygwin distribution: * python27-ipython-5.8.0-1 * python27-prompt_toolkit-1.0.15-1 * python27-scandir-1.10.0-1 * python27-simplegeneric-0.8.1-4 * python27-wcwidth-0.1.7-1 * python36-ipython-5.8.0-1 * python36-prompt_toolkit-1.0.15-1 * python36-simplegeneric-0.8.1-4 * python36-wcwidth-0.1.7-1 * python37-ipython-5.8.0-1 * python37-prompt_toolkit-1.0.15-1 * python37-simplegeneric-0.8.1-4 * python37-wcwidth-0.1.7-1 These releases update or add various Python module components, and include 3.7 builds in preparation for that becoming the default version. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python module updates
The following packages have been uploaded to the Cygwin distribution: * python27-automat-0.7.0-1 * python27-clang-5.0.2-1 * python27-futures-3.2.0-1 * python27-hyperlink-18.0.0-1 * python27-incremental-17.5.0-1 * python27-rdflib-4.2.2-2 * python27-twisted-18.9.0-1 * python36-automat-0.7.0-1 * python36-clang-5.0.2-1 * python36-hyperlink-18.0.0-1 * python36-incremental-17.5.0-1 * python36-rdflib-4.2.2-2 * python36-twisted-18.9.0-1 * python37-automat-0.7.0-1 * python37-clang-5.0.2-1 * python37-hyperlink-18.0.0-1 * python37-incremental-17.5.0-1 * python37-rdflib-4.2.2-2 * python37-twisted-18.9.0-1 These releases update or add various Python module components, and include 3.7 builds in preparation for that becoming the default version. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python module updates
Hello, Ruby package has not been updated for so long time. Wonder if it will be updated. Thanks On Fri, Mar 29, 2019 at 7:19 PM Yaakov Selkowitz wrote: > The following packages have been uploaded to the Cygwin distribution: > > * python27-bsddb3-6.2.6-1 > * python27-constantly-15.1.0-2 > * python27-dropbox-9.3.0-1 > * python27-enchant-1.6.11-2 > * python27-httplib2-0.11.3-1 > * python27-ipython_genutils-0.2.0-1 > * python27-isodate-0.6.0-1 > * python27-lockfile-0.12.2-2 > * python27-mako-1.0.8-1 > * python27-musicbrainzngs-0.6-2 > * python27-pathlib2-2.3.3-1 > * python27-pickleshare-0.7.5-1 > * python27-pyatspi-2.26.0-2 > * python27-pygame-1.9.4-1 > * python27-pylast-2.4.0-1 > * python27-reportlab-3.5.16-1 > * python27-service_identity-18.1.0-1 > * python27-traitlets-4.3.2-2 > * python27-unidecode-1.0.23-1 > * python27-xdg-0.26-1 > * python27-zope.interface-4.6.0-1 > * python36-bsddb3-6.2.6-1 > * python36-constantly-15.1.0-2 > * python36-dropbox-9.3.0-1 > * python36-enchant-1.6.11-2 > * python36-httplib2-0.11.3-1 > * python36-ipython_genutils-0.2.0-1 > * python36-isodate-0.6.0-1 > * python36-lockfile-0.12.2-2 > * python36-mako-1.0.8-1 > * python36-musicbrainzngs-0.6-2 > * python36-pathlib2-2.3.3-1 > * python36-pickleshare-0.7.5-1 > * python36-pyatspi-2.26.0-2 > * python36-pygame-1.9.4-1 > * python36-pylast-2.4.0-1 > * python36-reportlab-3.5.16-1 > * python36-service_identity-18.1.0-1 > * python36-traitlets-4.3.2-2 > * python36-unidecode-1.0.23-1 > * python36-xdg-0.26-1 > * python36-zope.interface-4.6.0-1 > * python37-bsddb3-6.2.6-1 > * python37-constantly-15.1.0-2 > * python37-dropbox-9.3.0-1 > * python37-enchant-1.6.11-2 > * python37-httplib2-0.11.3-1 > * python37-ipython_genutils-0.2.0-1 > * python37-isodate-0.6.0-1 > * python37-lockfile-0.12.2-2 > * python37-mako-1.0.8-1 > * python37-musicbrainzngs-0.6-2 > * python37-pathlib2-2.3.3-1 > * python37-pickleshare-0.7.5-1 > * python37-pyatspi-2.26.0-2 > * python37-pygame-1.9.4-1 > * python37-pylast-2.4.0-1 > * python37-reportlab-3.5.16-1 > * python37-service_identity-18.1.0-1 > * python37-traitlets-4.3.2-2 > * python37-unidecode-1.0.23-1 > * python37-xdg-0.26-1 > * python37-zope.interface-4.6.0-1 > > These releases update various Python module components, and add 3.7 > builds in preparation for that becoming the default version. > > -- > Yaakov > > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python module updates
The following packages have been uploaded to the Cygwin distribution: * python27-bsddb3-6.2.6-1 * python27-constantly-15.1.0-2 * python27-dropbox-9.3.0-1 * python27-enchant-1.6.11-2 * python27-httplib2-0.11.3-1 * python27-ipython_genutils-0.2.0-1 * python27-isodate-0.6.0-1 * python27-lockfile-0.12.2-2 * python27-mako-1.0.8-1 * python27-musicbrainzngs-0.6-2 * python27-pathlib2-2.3.3-1 * python27-pickleshare-0.7.5-1 * python27-pyatspi-2.26.0-2 * python27-pygame-1.9.4-1 * python27-pylast-2.4.0-1 * python27-reportlab-3.5.16-1 * python27-service_identity-18.1.0-1 * python27-traitlets-4.3.2-2 * python27-unidecode-1.0.23-1 * python27-xdg-0.26-1 * python27-zope.interface-4.6.0-1 * python36-bsddb3-6.2.6-1 * python36-constantly-15.1.0-2 * python36-dropbox-9.3.0-1 * python36-enchant-1.6.11-2 * python36-httplib2-0.11.3-1 * python36-ipython_genutils-0.2.0-1 * python36-isodate-0.6.0-1 * python36-lockfile-0.12.2-2 * python36-mako-1.0.8-1 * python36-musicbrainzngs-0.6-2 * python36-pathlib2-2.3.3-1 * python36-pickleshare-0.7.5-1 * python36-pyatspi-2.26.0-2 * python36-pygame-1.9.4-1 * python36-pylast-2.4.0-1 * python36-reportlab-3.5.16-1 * python36-service_identity-18.1.0-1 * python36-traitlets-4.3.2-2 * python36-unidecode-1.0.23-1 * python36-xdg-0.26-1 * python36-zope.interface-4.6.0-1 * python37-bsddb3-6.2.6-1 * python37-constantly-15.1.0-2 * python37-dropbox-9.3.0-1 * python37-enchant-1.6.11-2 * python37-httplib2-0.11.3-1 * python37-ipython_genutils-0.2.0-1 * python37-isodate-0.6.0-1 * python37-lockfile-0.12.2-2 * python37-mako-1.0.8-1 * python37-musicbrainzngs-0.6-2 * python37-pathlib2-2.3.3-1 * python37-pickleshare-0.7.5-1 * python37-pyatspi-2.26.0-2 * python37-pygame-1.9.4-1 * python37-pylast-2.4.0-1 * python37-reportlab-3.5.16-1 * python37-service_identity-18.1.0-1 * python37-traitlets-4.3.2-2 * python37-unidecode-1.0.23-1 * python37-xdg-0.26-1 * python37-zope.interface-4.6.0-1 These releases update various Python module components, and add 3.7 builds in preparation for that becoming the default version. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python module updates
The following packages have been uploaded to the Cygwin distribution: * python27-bs4-4.7.1-1 * python27-bugzilla-2.2.0-1 * python27-cairo-1.14.1-1 * python27-dbus-1.2.8-1 * python27-decorator-4.4.0-1 * python27-gi-3.26.1-2 * python27-html5lib-1.0.1-1 * python27-mutagen-1.42.0-1 * python27-numpy-1.16.2-1 * python27-pbr-5.1.3-1 * python27-pexpect-4.6.0-1 * python27-ptyprocess-0.6.0-1 * python27-pyasn1-0.4.5-1 * python27-pyasn1-modules-0.2.4-1 * python27-rsa-4.0-1 * python27-webencodings-0.5.1-2 * python36-bs4-4.7.1-1 * python36-bugzilla-2.2.0-1 * python36-cairo-1.14.1-1 * python36-dbus-1.2.8-1 * python36-decorator-4.4.0-1 * python36-gi-3.26.1-2 * python36-html5lib-1.0.1-1 * python36-mutagen-1.42.0-1 * python36-numpy-1.16.2-1 * python36-pbr-5.1.3-1 * python36-pexpect-4.6.0-1 * python36-ptyprocess-0.6.0-1 * python36-pyasn1-0.4.5-1 * python36-pyasn1-modules-0.2.4-1 * python36-rsa-4.0-1 * python36-webencodings-0.5.1-2 * python37-bs4-4.7.1-1 * python37-bugzilla-2.2.0-1 * python37-cairo-1.14.1-1 * python37-dbus-1.2.8-1 * python37-decorator-4.4.0-1 * python37-gi-3.26.1-2 * python37-html5lib-1.0.1-1 * python37-mutagen-1.42.0-1 * python37-numpy-1.16.2-1 * python37-pbr-5.1.3-1 * python37-pexpect-4.6.0-1 * python37-ptyprocess-0.6.0-1 * python37-pyasn1-0.4.5-1 * python37-pyasn1-modules-0.2.4-1 * python37-rsa-4.0-1 * python37-webencodings-0.5.1-2 * bugzilla-cli-2.2.0-1 * mutagen-utils-1.42.0-1 These releases update various Python module components to their latest version, and add 3.7 builds in preparation for that becoming the default version. The command-line utilities from python-bugzilla and python-mutagen were broken out into their own subpackages. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Python module updates
The following packages have been uploaded to the Cygwin distribution: * python27-alabaster-0.7.12-1 * python27-appdirs-1.4.3-2 * python27-asn1crypto-0.24.0-1 * python27-attrs-19.1.0-1 * python27-babel-2.6.0-1 * python27-certifi-2018.10.15-1 * python27-cffi-1.12.2-1 * python27-chardet-3.0.4-1 * python27-crypto-2.6.1-2 * python27-cryptography-2.6.1-1 * python27-cython-0.29.6-1 * python27-docutils-0.14-1 * python27-enum34-1.1.6-2 * python27-idna-2.8-1 * python27-imagesize-1.1.0-1 * python27-imaging-5.4.1-1 * python27-imaging-tk-5.4.1-1 * python27-ipaddress-1.0.22-1 * python27-jinja2-2.10-1 * python27-lxml-4.3.2-1 * python27-markupsafe-1.1.1-1 * python27-olefile-0.46-1 * python27-openssl-19.0.0-1 * python27-packaging-19.0-1 * python27-ply-3.11-1 * python27-pycparser-2.19-1 * python27-pygments-2.3.1-1 * python27-pyparsing-2.3.1-1 * python27-pytz-2018.9-2 * python27-requests-2.21.0-1 * python27-simplejson-3.16.0-1 * python27-six-1.12.0-1 * python27-snowballstemmer-1.2.1-2 * python27-sphinx-1.8.5-1 * python27-sphinxcontrib-websupport-1.1.0-1 * python27-sphinx_rtd_theme-0.4.3-1 * python27-sqlalchemy-1.3.1-1 * python27-typing-3.6.6-1 * python27-urllib3-1.24.1-1 * python27-whoosh-2.7.4-2 * python27-yaml-3.13-1 * python36-alabaster-0.7.12-1 * python36-appdirs-1.4.3-2 * python36-asn1crypto-0.24.0-1 * python36-attrs-19.1.0-1 * python36-babel-2.6.0-1 * python36-certifi-2018.10.15-1 * python36-cffi-1.12.2-1 * python36-chardet-3.0.4-1 * python36-crypto-2.6.1-2 * python36-cryptography-2.6.1-1 * python36-cython-0.29.6-1 * python36-docutils-0.14-1 * python36-idna-2.8-1 * python36-imagesize-1.1.0-1 * python36-imaging-5.4.1-1 * python36-imaging-tk-5.4.1-1 * python36-jinja2-2.10-1 * python36-lxml-4.3.2-1 * python36-markupsafe-1.1.1-1 * python36-olefile-0.46-1 * python36-openssl-19.0.0-1 * python36-packaging-19.0-1 * python36-ply-3.11-1 * python36-pycparser-2.19-1 * python36-pygments-2.3.1-1 * python36-pyparsing-2.3.1-1 * python36-pytz-2018.9-2 * python36-requests-2.21.0-1 * python36-simplejson-3.16.0-1 * python36-six-1.12.0-1 * python36-snowballstemmer-1.2.1-2 * python36-sphinx-1.8.5-1 * python36-sphinxcontrib-websupport-1.1.0-1 * python36-sphinx_rtd_theme-0.4.3-1 * python36-sqlalchemy-1.3.1-1 * python36-urllib3-1.24.1-1 * python36-whoosh-2.7.4-2 * python36-yaml-3.13-1 * python37-alabaster-0.7.12-1 * python37-appdirs-1.4.3-2 * python37-asn1crypto-0.24.0-1 * python37-attrs-19.1.0-1 * python37-babel-2.6.0-1 * python37-certifi-2018.10.15-1 * python37-cffi-1.12.2-1 * python37-chardet-3.0.4-1 * python37-crypto-2.6.1-2 * python37-cryptography-2.6.1-1 * python37-cython-0.29.6-1 * python37-docutils-0.14-1 * python37-idna-2.8-1 * python37-imagesize-1.1.0-1 * python37-imaging-5.4.1-1 * python37-imaging-tk-5.4.1-1 * python37-jinja2-2.10-1 * python37-lxml-4.3.2-1 * python37-markupsafe-1.1.1-1 * python37-olefile-0.46-1 * python37-openssl-19.0.0-1 * python37-packaging-19.0-1 * python37-ply-3.11-1 * python37-pycparser-2.19-1 * python37-pygments-2.3.1-1 * python37-pyparsing-2.3.1-1 * python37-pytz-2018.9-2 * python37-requests-2.21.0-1 * python37-simplejson-3.16.0-1 * python37-six-1.12.0-1 * python37-snowballstemmer-1.2.1-2 * python37-sphinx-1.8.5-1 * python37-sphinxcontrib-websupport-1.1.0-1 * python37-sphinx_rtd_theme-0.4.3-1 * python37-sqlalchemy-1.3.1-1 * python37-urllib3-1.24.1-1 * python37-whoosh-2.7.4-2 * python37-yaml-3.13-1 These releases update various Python module components to their latest version, and add 3.7 builds as the first stage in preparation for that becoming the default version. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin API Reference web pages missing recent AIO updates
On Nov 14 02:08, Mark Geisert wrote: > I'm pretty sure I updated the web page source XML to move the aio_* and > lio_* system interfaces from the "NOT implemented" page to the SUSv4 page. > But the updates aren't shown when browsing > https://cygwin.com/cygwin-api/std-notimpl.html and > https://cygwin.com/cygwin-api/compatibility.html#std-susv4. > > Was there another development step that I missed? Nope, your patch was well done. I forgot to update the website docs when uploading the packages. I pushed the doc changes now. Thanks for the heads-up, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Cygwin API Reference web pages missing recent AIO updates
I'm pretty sure I updated the web page source XML to move the aio_* and lio_* system interfaces from the "NOT implemented" page to the SUSv4 page. But the updates aren't shown when browsing https://cygwin.com/cygwin-api/std-notimpl.html and https://cygwin.com/cygwin-api/compatibility.html#std-susv4. Was there another development step that I missed? Thanks, Mark Geisert -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: dll load / rebase issue after 5/24 windows updates
On 5/24/2018 3:50 PM, Brien Oberstein wrote: Greetings, I installed the lastest windows updates on Win2k16 server and now I'm getting the fork/rebase issue. I tried running rebase-trigger / setup.exe multiple times and also reinstalling the libintl8 but the problem persists. Next step to troubleshoot? Hi Brien, You can try a "rebase-trigger full" If you are using a 32 bit version you should move to 64bit as these address are very low: > [main] bash 4220 child_info_fork::abort: > C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: > parent(0x1E) != child(0x1A) Finally as reported on > Problem reports: http://cygwin.com/problems.html you should provide us the cygcheck.out Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
dll load / rebase issue after 5/24 windows updates
Greetings, I installed the lastest windows updates on Win2k16 server and now I'm getting the fork/rebase issue. I tried running rebase-trigger / setup.exe multiple times and also reinstalling the libintl8 but the problem persists. Next step to troubleshoot? Thanks 3 [main] bash 4220 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x1A) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 5916 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 2380 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 5864 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x15) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 1184 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 4228 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 1984 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 2620 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x72) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 992 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x1A) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 3316 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 1116 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 2552 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x1A) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 2984 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x76) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 5896 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x1A) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 1228 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x1A) bash: fork: retry: Resource temporarily unavailable 0 [main] bash 5116 child_info_fork::abort: C:\appz\cygwin\bin\cygintl-8.dll: Loaded to different address: parent(0x1E) != child(0x72) bash: fork: retry: Resource temporarily unavailable -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Pidgin protocol plugin updates
The following packages have been uploaded to the Cygwin distribution: * pidgin-facebook-0.9.5-1 * pidgin-funyahoo-plusplus-0-0.4.20180214git * pidgin-skypeweb-1.4-1 These are the latest releases of the third-party protocol plugins for Pidgin 2.13.0. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
🔥 DigitalSignage.com | latest release and updates...
DigitalSignage.com | latest releases and updates... - Faster RSS speed support with full screen scrolling messages - Increase in max font size - Support for Weather local for internationalization - Support for short and long Weather textual elements - Update to Google Play now with Android SignagePlayer 6.0.200 - SignagePlayer optimization with respect to mediaTOUCH tablet - Effects & Transitions execute on same layer and support masks - HTML component with staticTexture now renders at GPU level - Improvements in offline playback & better offline content caching See digitalsignage.com for more info -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
🔥 DigitalSignage.com | latest release and updates...
DigitalSignage.com | latest releases and updates... - Faster RSS speed support with full screen scrolling messages - Increase in max font size - Support for Weather local for internationalization - Support for short and long Weather textual elements - Update to Google Play now with Android SignagePlayer 6.0.200 - SignagePlayer optimization with respect to mediaTOUCH tablet - Effects & Transitions execute on same layer and support masks - HTML component with staticTexture now renders at GPU level - Improvements in offline playback & better offline content caching See digitalsignage.com for more info -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Exim - fatal with latest updates
With the latest v2.833 updates (x64). Exim will not start and has fatal stop and makes panic log entry: 2017-12-24 02:07:45 fork failed for TLS check I rolled back to about 2 months prior version, and restored operations. Sorry - no further info on the troublesome module. -- Regards -- Ross Hemingway -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tcl / tcl-tk updates - two links going nowhere
On 02/11/2017 13:46, Fergus wrote: The recent updates tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1 have induced two links /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh that lead nowhere. Is there a fix? Thank you. Fergus install tcl-devel and tcl-tk-devel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tcl / tcl-tk updates - two links going nowhere
> The recent updates > tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1 > have induced two links > /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh > /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh > that lead nowhere. Is there a fix? The two missing t*Config.sh files can be obtained by decompressing tcl-devel-8.6.6-1.tar.xz tcl-tk-devel-8.6.6-1.tar.xz (These two files were not part of the original downloaded update. Should they have been?) Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
tcl / tcl-tk updates - two links going nowhere
The recent updates tcl-8.6.6-1 ; tcl-tix-8.4.3-3 ; tcl-tk-8.6.6-1 have induced two links /lib/tcl8.6/tclConfig.sh -> ../tclConfig.sh /lib/tk8.6/tkConfig.sh -> ../tkConfig.sh that lead nowhere. Is there a fix? Thank you. Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] MATE Desktop 1.18 updates
The following packages have been uploaded to the Cygwin distribution: * atril-1.18.1-1 * caja-1.18.4-1 * caja-python-1.18.1-1 * engrampa-1.18.2-1 * eom-1.18.2-1 * libmateweather-1.18.1-1 * marco-1.18.1-1 * mate-control-center-1.18.2-1 * mate-dictionary-1.18.2-1 * mate-disk-usage-analyzer-1.18.2-1 * mate-font-viewer-1.18.2-1 * mate-media-1.18.1-1 * mate-panel-1.18.4-1 * mate-screenshot-1.18.2-1 * mate-search-tool-1.18.2-1 * mate-session-manager-1.18.1-1 * mate-system-log-1.18.2-1 * mate-terminal-1.18.1-1 * pluma-1.18.2-1 The MATE Desktop Environment is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors for Linux and other Unix-like operating systems. These are the latest stable bugfix releases for the MATE Desktop. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Gott Code updates
The following packages have been uploaded to the Cygwin distribution: * connectagram-1.2.5-1 * cutemaze-1.2.1-1 * focuswriter-1.6.7-1 * gottet-1.1.4-1 * hexalate-1.1.1-1 * kapow-1.5.3-1 * novprog-3.1.2-1 * peg-e-1.2.3-1 * simsu-1.3.4-1 * tanglet-1.5.0-1 * tetzle-2.1.1-1 * xfce4-whiskermenu-plugin-1.7.3-1 This is an update to the latest versions of the Gott Code games and applications. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] X.Org updates
The following packages have been uploaded to the Cygwin distribution: * libX11_6-1.6.5-1 * libX11-devel-1.6.5-1 * libX11-doc-1.6.5-1 * libX11-xcb1-1.6.5-1 * libX11-xcb-devel-1.6.5-1 * libXi6-1.7.9-1 * libXi-devel-1.7.9-1 * sessreg-1.1.1-1 * xauth-1.0.10-1 * xconsole-1.0.7-1 * xkbcomp-1.4.0-1 * xkbcomp-devel-1.4.0-1 * xkeyboard-config-2.21-1 * xkeyboard-config-devel-2.21-1 These are updates to the latest X.Org modular releases. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] GNOME 3.22 updates
The following packages have been uploaded to the Cygwin distribution: * frogr-1.3-1 * glib2.0-openssl-2.50.3-1 * gnome-commander-1.6.4-1 * gtk-vnc-0.7.1-1 * gtk3-3.22.15-1 * pango1.0-1.40.6-1 * vte2.91-0.46.2-1 * mingw64-i686-gtk-vnc-0.7.1-1 * mingw64-i686-gtk3-3.22.15-1 * mingw64-i686-pango1.0-1.40.6-1 * mingw64-x86_64-gtk-vnc-0.7.1-1 * mingw64-x86_64-gtk3-3.22.15-1 * mingw64-x86_64-pango1.0-1.40.6-1 These updates represent the latest bugfix releases to the GNOME 3.22 package set. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] MinGW GNOME 3.22 updates
The following packages have been uploaded to the Cygwin distribution: * mingw64-i686-glibmm2.4-2.50.1-1 * mingw64-i686-gnome-themes-standard-3.22.3-1 * mingw64-i686-goffice0.10-0.10.34-1 * mingw64-i686-libgdata-0.17.8-1 * mingw64-i686-librsvg2-2.40.17-1 * mingw64-i686-pango1.0-1.40.5-1 * mingw64-x86_64-glibmm2.4-2.50.1-1 * mingw64-x86_64-gnome-themes-standard-3.22.3-1 * mingw64-x86_64-goffice0.10-0.10.34-1 * mingw64-x86_64-libgdata-0.17.8-1 * mingw64-x86_64-librsvg2-2.40.17-1 * mingw64-x86_64-pango1.0-1.40.5-1 These updates represent the latest bugfix releases to the GNOME 3.22 package set for MinGW. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] GNOME 3.22 updates
The following packages have been uploaded to the Cygwin distribution: * eog-plugins-3.16.6-1 * glib2.0-openssl-2.50.2-1 * glibmm2.4-2.50.1-1 * gnome-calendar-3.22.5-1 * gnome-directory-thumbnailer-0.1.9-1 * gnome-recipes-1.0.8-1 * gnome-themes-standard-3.22.3-1 * gnumeric-1.12.34-1 * goffice0.10-0.10.34-1 * gucharmap-9.0.3-1 * gvfs-1.30.4-1 * hitori-3.22.3-1 * libgdata-0.17.8-1 * librsvg2-2.40.17-1 * pango1.0-1.40.5-1 * vala-0.34.8-1 These updates represent the latest bugfix releases to the GNOME 3.22 package set. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash shell gets aborts under latest Windows 10 updates as of 4/2/17
Greetings, Fran Litterio! > On 5/5/2017 7:30 AM, Andrey Repin wrote: >>> You can rebase all the DLLs as follows: >> >> That's not how to do it. >> >> 1. Run >> >>rebase-trigger full >> >> 2. Shutdown all Cygwin processes. >> 3. Run setup utility to the end. > Thanks, Andrey. I have seen those instructions, but the rebaseall > command itself says this when run in Bash: > $ rebaseall > rebaseall: only ash or dash processes are allowed during rebasing > Exit all Cygwin processes and stop all Cygwin services. > Execute ash (or dash) from Start/Run... or a cmd or command window. > Execute '/bin/rebaseall' from ash (or dash). > Is there evidence that the instructions displayed by rebaseall are > incorrect? Is it possible that the setup utility simply runs rebaseall? No, documentation of the utility is correct, but process you described is obsolete. rebaseall was integrated into setup for a long time now. -- With best regards, Andrey Repin Friday, May 5, 2017 15:28:48 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash shell gets aborts under latest Windows 10 updates as of 4/2/17
On 5/5/2017 7:30 AM, Andrey Repin wrote: You can rebase all the DLLs as follows: That's not how to do it. 1. Run rebase-trigger full 2. Shutdown all Cygwin processes. 3. Run setup utility to the end. Thanks, Andrey. I have seen those instructions, but the rebaseall command itself says this when run in Bash: $ rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). Is there evidence that the instructions displayed by rebaseall are incorrect? Is it possible that the setup utility simply runs rebaseall? -- Fran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash shell gets aborts under latest Windows 10 updates as of 4/2/17
Greetings, Fran Litterio! > You can rebase all the DLLs as follows: That's not how to do it. 1. Run rebase-trigger full 2. Shutdown all Cygwin processes. 3. Run setup utility to the end. -- With best regards, Andrey Repin Friday, May 5, 2017 14:28:08 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash shell gets aborts under latest Windows 10 updates as of 4/2/17
On 4/2/2017 2:53 PM, gavin bowlby via cygwin wrote: I see the following when trying to open a Cygwin bash shell on my Win10 PC after applying updates today, 4/2/2017; I didn't see this before the latest Win10 update: 0 [main] bash 11884 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE8) -bash: fork: retry: No child processes I believe this is a classic case where rebasing is required. See https://stackoverflow.com/questions/33125842/what-does-rebaseall-in-cygwin-do for details. Sometimes the problem can be fixed by rebooting and starting a Cygwin app (e.g., Bash) very soon after boot (so that the DLLs get loaded at their preferred addressed), but that is a temporary workaround. You can rebase all the DLLs as follows: - Terminate _all_ Cygwin apps (don't forget about daemons like sshd). - Open a Command Prompt. - Run "ash" (a shell included with Cygwin). Do not run "bash". - Enter command "rebaseall". - I usually follow this with a reboot, but that may not be necessary. Hope this helps. -- Fran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash shell gets aborts under latest Windows 10 updates as of 4/2/17
All: I reinstalled Cygwin on my Win10 PC, and now the problem has disappeared. Regards, Gavin Bowlby On Sunday, April 2, 2017 11:53 AM, gavin bowlby wrote: All: I see the following when trying to open a Cygwin bash shell on my Win10 PC after applying updates today, 4/2/2017; I didn't see this before the latest Win10 update: 0 [main] bash 11884 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE8) -bash: fork: retry: No child processes 1 [main] bash 11908 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE8) -bash: fork: retry: No child processes 0 [main] bash 11928 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE6) -bash: fork: retry: No child processes 2 [main] bash 11964 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xF3) -bash: fork: retry: No child processes 0 [main] bash 12008 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE5) -bash: fork: Resource temporarily unavailable Any command issued from the Cygwin bash shell gives output similar to what's shown above. I rebooted my PC after applying the updates. I haven't tried additional reboots yet. Here's the list of Win10 updates that were just applied: (some of these updates are probably don't-care) Windows Malicious Software Removal Tool for Windows 8, 8.1, 10 and Windows Server 2012, 2012 R2, 2016 x64 Edition - March 2017 (KB890830) Security Update for Lync 2010 X64 (KB4010299) Update for Windows 10 Version 1607 for x64-based Systems (KB4013418) Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4013429) Security Update for Adobe Flash Player for Windows 10 Version 1607 (for x64-based Systems) (KB4014329) Security Update for Microsoft Silverlight (KB4013867) I'm attaching a cygcheck.out file, collected from a Windows command prompt with cygcheck -s -v -r because I can't bring up a Cygwin command shell. Regards, Gavin Bowlby -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
bash shell gets aborts under latest Windows 10 updates as of 4/2/17
All: I see the following when trying to open a Cygwin bash shell on my Win10 PC after applying updates today, 4/2/2017; I didn't see this before the latest Win10 update: 0 [main] bash 11884 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE8) -bash: fork: retry: No child processes 1 [main] bash 11908 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE8) -bash: fork: retry: No child processes 0 [main] bash 11928 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE6) -bash: fork: retry: No child processes 2 [main] bash 11964 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xF3) -bash: fork: retry: No child processes 0 [main] bash 12008 child_info_fork::abort: C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0xFA) != child(0xE5) -bash: fork: Resource temporarily unavailable Any command issued from the Cygwin bash shell gives output similar to what's shown above. I rebooted my PC after applying the updates. I haven't tried additional reboots yet. Here's the list of Win10 updates that were just applied: (some of these updates are probably don't-care) Windows Malicious Software Removal Tool for Windows 8, 8.1, 10 and Windows Server 2012, 2012 R2, 2016 x64 Edition - March 2017 (KB890830) Security Update for Lync 2010 X64 (KB4010299) Update for Windows 10 Version 1607 for x64-based Systems (KB4013418) Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4013429) Security Update for Adobe Flash Player for Windows 10 Version 1607 (for x64-based Systems) (KB4014329) Security Update for Microsoft Silverlight (KB4013867) I'm attaching a cygcheck.out file, collected from a Windows command prompt with cygcheck -s -v -r because I can't bring up a Cygwin command shell. Regards, Gavin Bowlby cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup-x86_64 and Cygwin 64 Latest Updates - Packages NOT Upgraded
On 2017-04-01 04:13, Achim Gratz wrote: > Brian Inglis writes: >> @ libproj9 >> version: 4.9.2-1 >> @ libslang2 >> version: 2.3.1a-1 >> @ perl-Carp >> version: 1.38-1 >> >> Are dependencies only auto-updated when the manually picked >> packages that depend on them are? > > No, but the last two packages need manual updating because setup > considers the version on disk newer than the one offered. At least > for perl-Carp there was a version override in place when upstream > changed their numbering scheme. Done that and uninstalled libproj9 as it is still in requires: for [prev] releases with libproj12 for current releases, except for libgeotiff2 which only shows libproj9 not libproj12. > I think in this case the -f/--force-current option to setup would > pick up the correct version also. > >> Could these packages now be orphans if their original manually >> picked parent packages changed their dependencies? > > Well, probably the easiest way to see if they're orphan packages is > by using the -o/--delete-orphans option to setup and check on the > Pending page which packages it wants to remove. Thanks Achim, I was unsure how safe that would be, but I will do that as long as I know it shows on Pending. Should run on 32 as well as it has been around for 5 years in current setup. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup-x86_64 and Cygwin 64 Latest Updates - Packages NOT Upgraded
Brian Inglis writes: > @ libproj9 > version: 4.9.2-1 > @ libslang2 > version: 2.3.1a-1 > @ perl-Carp > version: 1.38-1 > > Are dependencies only auto-updated when the manually > picked packages that depend on them are? No, but the last two packages need manual updating because setup considers the version on disk newer than the one offered. At least for perl-Carp there was a version override in place when upstream changed their numbering scheme. I think in this case the -f/--force-current option to setup would pick up the correct version also. > Could these packages now be orphans if their original manually > picked parent packages changed their dependencies? Well, probably the easiest way to see if they're orphan packages is by using the -o/--delete-orphans option to setup and check on the Pending page which packages it wants to remove. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup-x86_64 and Cygwin 64 Latest Updates - Packages NOT Upgraded
On 2017-03-31 15:18, Marco Atzeri wrote:
> On 31/03/2017 23:03, Brian Inglis wrote:
>> Just updated to latest Setup-x86_64 and Cygwin 64 packages.
>>
>> Cross-checking setup and installed releases I find installed:
>>
>> $ egrep '^(libproj9|libslang2|perl-Carp)\s' /etc/setup/installed.db
>> libproj9 libproj9-4.9.3-1.tar.bz2 0
>> libslang2 libslang2-2.3.1pre17-1.tar.bz2 0
>> perl-Carp perl-Carp-1.3301-2.tar.bz2 0
>>
>> but setup.ini shows:
>>
>> $ awk '/^@ (libproj9|libslang2|perl-Carp)$/,/^version:\s/' \
>> `apt cache`/mirror/$HOSTTYPE/setup.ini | \
>> egrep '^(@|version:)\s'
>> @ libproj9
>> version: 4.9.2-1
>> @ libslang2
>> version: 2.3.1a-1
>> @ perl-Carp
>> version: 1.38-1
>
> on 64 bit libproj9 version seems only 4.9.2-1 for X86_64.
> I will look whats happened.
>
> for libslang2 you need to force update as
> libslang2-2.3.1pre17-1 > 2.3.1a-1
>
> An improvement on revision (0.x instead of 1) was done to avoid this
> pitfall, but in this case it was too late.
Going a bit more generic I see:
$ egrep '^(libproj|libslang|perl-Carp)' /etc/setup/installed.db
libproj12 libproj12-4.9.3-2.tar.bz2 0
libproj9 libproj9-4.9.3-1.tar.bz2 0
libslang2 libslang2-2.3.1pre17-1.tar.bz2 0
perl-Carp perl-Carp-1.3301-2.tar.bz2 0
$ awk '/^@ (libproj|libslang|perl-Carp)/,/^version:\s/' \
`apt cache`/mirror/$HOSTTYPE/setup.ini | \
egrep '^(@|version:)\s'
@ libproj-devel
version: 4.9.3-2
@ libproj12
version: 4.9.3-2
@ libproj9
version: 4.9.2-1
@ libslang-devel
version: 2.3.1a-1
@ libslang2
version: 2.3.1a-1
@ perl-Carp
version: 1.38-1
$ awk '/^@ proj$/,/^requires:\s/' `apt cache`/mirror/$HOSTTYPE/setup.ini
@ proj
sdesc: "The PROJ Cartographic Projections Software"
ldesc: "Cartographic projection library and utilities"
category: Graphics Libs
requires: cygwin libproj12 libproj9
$ ls -golrt `apt
cache`/mirror/$HOSTTYPE/release/{proj/libproj,slang/libslang,perl-Carp}* \
/etc/setup/{libproj,libslang,perl-Carp}*
-rw-r--r-- 1 132 Aug 26 2015 /etc/setup/perl-Carp.lst.gz
-rw-r--r-- 1 43 Oct 19 2015 /etc/setup/libslang2.lst.gz
-rw-r--r-- 1 43 Oct 4 00:01 /etc/setup/libproj9.lst.gz
-rw-r--r-- 1 43 Jan 13 15:12 /etc/setup/libproj12.lst.gz
'C:/usr/local/cygwin64/var/cache/setup/packages/mirror/x86_64/release/perl-Carp':
total 44K
-rw-r--r-- 1 17K Apr 4 2015 perl-Carp-1.3301-2.tar.xz
-rw-r--r-- 1 17K Aug 26 2015 perl-Carp-1.36-2.tar.xz
'C:/usr/local/cygwin64/var/cache/setup/packages/mirror/x86_64/release/slang/libslang2':
total 248K
-rw-r--r-- 1 247K Oct 19 2015 libslang2-2.3.1pre17-1.tar.xz
'C:/usr/local/cygwin64/var/cache/setup/packages/mirror/x86_64/release/proj/libproj9':
total 132K
-rw-r--r-- 1 128K Oct 4 00:01 libproj9-4.9.3-1.tar.xz
'C:/usr/local/cygwin64/var/cache/setup/packages/mirror/x86_64/release/proj/libproj12':
total 128K
-rw-r--r-- 1 128K Jan 13 15:12 libproj12-4.9.3-2.tar.xz
https://cygwin.com/ml/cygwin/2016-11/msg00125.html python-gdal
So it looks like libproj9 -> libproj12 leaving libproj9 still in
requires for [prev], and perl-Carp may have been another version
number, or setup upgrade run problem perhaps?
>> Are dependencies only auto-updated when the manually picked
>> packages that depend on them are?
>>
>> Could these packages now be orphans if their original manually
>> picked parent packages changed their dependencies?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup-x86_64 and Cygwin 64 Latest Updates - Packages NOT Upgraded
On 31/03/2017 23:03, Brian Inglis wrote: Just updated to latest Setup-x86_64 and Cygwin 64 packages. Cross-checking setup and installed releases I find installed: $ egrep '^(libproj9|libslang2|perl-Carp)\s' /etc/setup/installed.db libproj9 libproj9-4.9.3-1.tar.bz2 0 libslang2 libslang2-2.3.1pre17-1.tar.bz2 0 perl-Carp perl-Carp-1.3301-2.tar.bz2 0 but setup.ini shows: $ awk '/^@ (libproj9|libslang2|perl-Carp)$/,/^version:\s/' \ `apt cache`/mirror/$HOSTTYPE/setup.ini | \ egrep '^(@|version:)\s' @ libproj9 version: 4.9.2-1 @ libslang2 version: 2.3.1a-1 @ perl-Carp version: 1.38-1 on 64 bit libproj9 version seems only 4.9.2-1 for X86_64. I will look whats happened. for libslang2 you need to force update as libslang2-2.3.1pre17-1 > 2.3.1a-1 An improvement on revision (0.x instead of 1) was done to avoid this pitfall, but in this case it was too late. Are dependencies only auto-updated when the manually picked packages that depend on them are? Could these packages now be orphans if their original manually picked parent packages changed their dependencies? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Setup-x86_64 and Cygwin 64 Latest Updates - Packages NOT Upgraded
Just updated to latest Setup-x86_64 and Cygwin 64 packages. Cross-checking setup and installed releases I find installed: $ egrep '^(libproj9|libslang2|perl-Carp)\s' /etc/setup/installed.db libproj9 libproj9-4.9.3-1.tar.bz2 0 libslang2 libslang2-2.3.1pre17-1.tar.bz2 0 perl-Carp perl-Carp-1.3301-2.tar.bz2 0 but setup.ini shows: $ awk '/^@ (libproj9|libslang2|perl-Carp)$/,/^version:\s/' \ `apt cache`/mirror/$HOSTTYPE/setup.ini | \ egrep '^(@|version:)\s' @ libproj9 version: 4.9.2-1 @ libslang2 version: 2.3.1a-1 @ perl-Carp version: 1.38-1 Are dependencies only auto-updated when the manually picked packages that depend on them are? Could these packages now be orphans if their original manually picked parent packages changed their dependencies? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 3-line Emacs window after Gnome updates
On 3/24/2017 7:50 AM, Ken Brown wrote: On 3/23/2017 5:27 PM, Yaakov Selkowitz wrote: Which btw is just wrong; they should have used the gtk_check_version function instead of the GTK_CHECK_VERSION macro. In any case, try rebuilding emacs with libgtk3-devel 3.22. Thanks, Yaakov. I think your diagnosis is correct, and rebuilding fixed the problem. I've uploaded a new release. And I've reported the problem upstream: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23144#78 Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 3-line Emacs window after Gnome updates
On 3/23/2017 5:27 PM, Yaakov Selkowitz wrote: On 2017-03-23 16:02, Ken Brown wrote: Do you have an emacs.geometry setting in your ~/.Xresources? Or any kind of size setting in your emacs initialization files? If not, I guess emacs or X11 has a default. I'll look into the 3-line window and see if I can figure out what's going on. This might be related: http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25.1&id=9ca5dbf947a7421d37b3e2d2bc6b8d2c9218bc65 Which btw is just wrong; they should have used the gtk_check_version function instead of the GTK_CHECK_VERSION macro. In any case, try rebuilding emacs with libgtk3-devel 3.22. Thanks, Yaakov. I think your diagnosis is correct, and rebuilding fixed the problem. I've uploaded a new release. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
