Re: cygport test has zero exit status on failures
Jason Pyeron writes: > If I have a CI build for *.cygport - is it expected to have > conditional logic based on which package is being processed? Not necessarily, I understand you were talking about default behaviour and how the current default doesn't match your / your CI's expectation. To reiterate, you can already do what you want by defining your own src_test function and this behaviour becomes part of the package definition then. > I thought was the purpose of the cygport file [1] was to contain only > the compiling, testing, and installation instructions, just like > portage [2]. I consider cygport its own thing by now that is not actively synchronized to what portage ends up doing. > In any case the all or all-test does not execute the test step, so the > customization of the src_test does not impact the default behaviors. That's beside the point. We were only talking about the test behaviours or at least I was, anyway. Now again, if you do that in the cygport file you mix that expectation of getting a return value (that really comes from the way you run cygport in the CI and determine the test status) with the package definition. If you force that to satisfy your CI requirements, you also break the flow for folks who (as an example) rather do cygport $p finish prep compile inst test pkg because a test fail would now error out before getting to the packaging step. Which is why I was musing that your preference in how to treat a test fail should really be injected from the run-time environment rather than the package definition. Once that mechanism is in place I can also start writing my own src_test functions that switch their behaviour depending on that setting so that these package definitions would work in either environment. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
[ANNOUNCEMENT] Updated: ncview-2.1.8-1
Version 2.1.8-1 of ncview is available in the Cygwin distribution. CHANGES Rebuilt for updated library dependencies DESCRIPTION Ncview is a visual browser for netCDF format files. Typically you would use ncview to get a quick and easy, push-button look at your netCDF files. You can view simple movies of the data, view along various dimensions, take a look at the actual data values, change color maps, invert the data, etc HOMEPAGE http://meteora.ucsd.edu/~pierce/ncview_home_page.html Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: ncview-2.1.8-1
Version 2.1.8-1 of ncview is available in the Cygwin distribution. CHANGES Rebuilt for updated library dependencies DESCRIPTION Ncview is a visual browser for netCDF format files. Typically you would use ncview to get a quick and easy, push-button look at your netCDF files. You can view simple movies of the data, view along various dimensions, take a look at the actual data values, change color maps, invert the data, etc HOMEPAGE http://meteora.ucsd.edu/~pierce/ncview_home_page.html Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
sshd high cpu load
To Cygwin, I am running cygwin openssh as a windows service. I have been doing so for many years with out issue. Recently, I have been running into an issue where it maxes out my cpu on any version newer than 8.4p1-1. The solution is to downgrade to 8.4p1-1. My server machine is a dell t330 running windows 10. I am not a business despite using business grade hardware.I have tried both 20h2 and 21h1 but no luck. There are no users signed in when the issues occur and occurs within minutes of booting up. The only change from the default config is I have it running on a nonstandard port. Any advice is welcome as I really would like to upgrade to a newer version. 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
public key Jason Pyeron
Name: Jason Pyeron BEGIN SSH2 PUBLIC KEY Comment: "2048-bit RSA for use with Cygwin publishing" B3NzaC1yc2EBIwAAAQEA+TM6VXYM0eSxZdJ20jKcEDsCiZG6e0TZQs07VtXWq0 rmm1xn0tPQoQqBKmKqqUGlsdhh3cXDWYYP7yWMgT+zIsR7ch5g3SKzmgO/Z+HUSpkKAPm2 I5HAY9G6Rz2mP2YrxRIliD1w2t0g/0bZOqGV/7G/TXOOlPsRITG3jEnvbJVUwHL/e/kBJx Wz+zkJJlGAzuzTa+nAGRBJB1qUA3JUNzwOdXea2wOwh5pObxebI/ZA1pwFqiOGRr1JPiyB IOqxgLpMV/NwMg/oyuJPko99c2mXIyy4cGWKhN0C/m+TH1O1CSpG+prifEXNhs6GIle1N4 jvlsUtY4yv7OXEA5CLLQ== END SSH2 PUBLIC KEY Take 2, first one was HTML by accident. # ssh cyg...@cygwin.com alive Connecting to cygwin.com... The authenticity of host 'cygwin.com (8.43.85.97)' can't be established. RSA key fingerprint is 1d:1e:46:7f:4d:73:8d:10:20:c3:4c:5a:34:14:44:23. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cygwin.com,8.43.85.97' (RSA) to the list of known hosts. Permission denied (publickey).
Package install check missing usr/lib/...def file
Hi folks, Trying to update libidn2, but both arch get: >>> Checking packages for unexpected, missing or duplicate files *** Warning: Packages are missing files: -usr/lib/libidn2-0.def *** ERROR: Packages are missing files: $ l libidn2-2.3.1-1.x86_64/**/*.def libidn2-2.3.1-1.x86_64/build/lib/libidn2-0.def libidn2-2.3.1-1.x86_64/inst/usr/lib/libidn2-0.def Is the fix just to add into src_install: rm $B/lib/*.def as I see no other def files under usr/lib? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: gengetopt missing in x86 package search and x86 setup.ini
On 2021-05-18 10:05, Marco Atzeri via Cygwin-apps wrote: On 18.05.2021 15:47, Brian Inglis wrote: Needed dependency for libidn build missing from x86. It seems Rafel has missed to note the need to build for both architectures. Ping Rafel Amer - need x86 gengetopt build please! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
RE: cygport test has zero exit status on failures
> -Original Message- > From: Achim Gratz > Sent: Tuesday, May 18, 2021 4:16 PM > > Jason Pyeron writes: > > If I put it in ~/.config/cygport.conf it will impact all packages, not > > just the "one". The only place it is limited to applicable package is > > in the package.cygport file, or am I missing something? > > You can always override these settings when starting a build on a CI > (either by changing the config file or just remove/set more environment > variables), but the point was that the cygport file should not lock in a > specific behaviour, but rather allow the environment to determine it. Having trouble groking the conceptual design. If I have a CI build for *.cygport - is it expected to have conditional logic based on which package is being processed? I thought was the purpose of the cygport file [1] was to contain only the compiling, testing, and installation instructions, just like portage [2]. In any case the all or all-test does not execute the test step, so the customization of the src_test does not impact the default behaviors. As an example you can look at my CI builds [3] to see the sequence: 1. ensure dependencies are installed on build host 2. cygport file.cygport download 3. cygport file.cygport all-test 4. cygport file.cygport test 5. archive artifacts The same build host is used (serially) for other builds. -Jason 1: /usr/share/doc/cygport/README §2 2: https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html 3: https://www.pdinc.us/ci/job/oss-cygwin-pdfgrep/job/cygwin-cygport-2.1.2/3/
Re: preventing setup from forking
On Tue, 18 May 2021 at 10:13, Marco Atzeri via Cygwin wrote: > > On 17.05.2021 23:12, Jason Pyeron wrote: > >> -Original Message- > >> From: Jon Turney > >> Sent: Monday, May 17, 2021 4:41 PM > >> > > > > > My real issue was the user was not an admin - doh! > > that could be due to "setup" in the program name. > > It is one of the "security" ideas of MS I believe it's nothing to do with the program name, and everything to do with how the UAC permissions work: if you run the setup program with the -B argument so it won't check it's running with Administrator permissions, or run it from a parent process that already has Administrator permissions, you'll get the behaviour you might expect. If you run it without -B and from an unelevated context, then the installer will elevate to Administrator before it does anything else, and that means the calling context -- cmd or anything else -- won't get any feedback from the installer, so it returns straight away. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygport test has zero exit status on failures
Jason Pyeron writes: > If I put it in ~/.config/cygport.conf it will impact all packages, not > just the "one". The only place it is limited to applicable package is > in the package.cygport file, or am I missing something? You can always override these settings when starting a build on a CI (either by changing the config file or just remove/set more environment variables), but the point was that the cygport file should not lock in a specific behaviour, but rather allow the environment to determine it. 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
Re: realpath issue with native[strict] symlinks
Sorry ,forgot subject On Tue, 18 May 2021, Jeremy Drake wrote: > > Sorry, but there's only this or that, not both. Either we revert the > > entire change, including the native shortcut stuff, or we do it > > completely and fully, including handling virtual drives as symlinks. > > I had success with just the following change (of course comments would > also need to be updated): > > diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc > index 4ebaf4dc6..53534b8b6 100644 > --- a/winsup/cygwin/path.cc > +++ b/winsup/cygwin/path.cc > @@ -3670,8 +3670,7 @@ restart: > somewhere else, thus, it's a symlink in POSIX speak. */ > if (upath.Length == 14) /* \??\X:\ */ > { > - fileattr &= ~FILE_ATTRIBUTE_DIRECTORY; > - path_flags |= PATH_SYMLINK; > + goto file_not_symlink; > } > /* For final paths differing in inner path components return > length as negative value. This informs path_conv::check > > Treating mapped/subst drives as though they were not symlinks, without > messing with intermedate symlinks. > -- Worst Response To A Crisis, 1985: From a readers' Q and A column in TV GUIDE: "If we get involved in a nuclear war, would the electromagnetic pulses from exploding bombs damage my videotapes?" -- 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
[no subject]
> Sorry, but there's only this or that, not both. Either we revert the > entire change, including the native shortcut stuff, or we do it > completely and fully, including handling virtual drives as symlinks. I had success with just the following change (of course comments would also need to be updated): diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index 4ebaf4dc6..53534b8b6 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -3670,8 +3670,7 @@ restart: somewhere else, thus, it's a symlink in POSIX speak. */ if (upath.Length == 14) /* \??\X:\ */ { - fileattr &= ~FILE_ATTRIBUTE_DIRECTORY; - path_flags |= PATH_SYMLINK; + goto file_not_symlink; } /* For final paths differing in inner path components return length as negative value. This informs path_conv::check Treating mapped/subst drives as though they were not symlinks, without messing with intermedate symlinks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] ghostscript 9.54.0-1 (TEST)
On 4/12/2021 2:50 PM, Ken Brown via Cygwin-announce via Cygwin wrote: The following packages have been uploaded to the Cygwin distribution as test releases: * ghostscript-9.54.0-1 * libgs9-9.54.0-1 * libgs-devel-9.54.0-1 This has now been promoted from test to current. 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: Outdated git-review package
On 18.05.2021 13:22, Oledzki, Maciej (Nokia - PL/Wroclaw) via Cygwin wrote: Hi, Latest git-review package available in Cygwin repository is old (1.26.0-1) and is not supported by recent Gerrit Code Review (3.2.7 and newer). It would be great if more recent version of git-review was available. git-review-2.1.0-1 has been uploaded, please test and let us know The new version is working with python 3.8 while the previous one was using python 2.7 Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: pdfgrep [ITA]
> -Original Message- > From: Achim Gratz > Sent: Tuesday, May 18, 2021 1:13 PM > > Jason Pyeron writes: > > I am assuming that I should not include cygport in the build > > requires. > > Yes, we currently assume cygport and its transitive dependencies to be > available for a cygport based package. The build requires should enable > the CI to build the package correctly. Yeah, doing the CI thing here right now. Been having fun getting Jenkins to use multibranch to build both x64 and x86 in the one pipeline. stage("32bit") { // "." needs to be in the user's path env var for this hack... dir("c:\\cygwin.jenkins\\bin\\") { //replace nohup with the correct cygwin home's version bat """ ln -vf nohup.exe c:/Users/jenkins/ """ //Jenkins does a nohup sh -xe ..., sh ''' . /etc/profile export TMP="$(cygpath -ua "${WORKSPACE_TMP}")" export TEMP="${TMP}" cd "$(cygpath -ua "${WORKSPACE}")" #now goes your script...
RE: cygport test has zero exit status on failures
> -Original Message- > From: ASSI > Sent: Tuesday, May 18, 2021 12:37 AM > > Jason Pyeron writes: > > What is the historic rationale behind the "OR true" after the make > > check? > > Not historic for the most part, I'd say. Cygport can also do > cross-builds of packages and in those cases the tests will seldomly work > (at all or at least partly) unless upstream walked the extra mile. > Also, due to ATWIL syndrome and other factors, Cygwin is often not Which is why I want the tests to fail - so it causes patches to be created... and pushed upstream. > explicitly considered a target platform or (even then) treated wrongly > in different ways, so even when building natively you will encounter > your fair share of spurious test fails. > > > It seems silly to have to redefine src_test() as { > > cd ${B} > > make check > > }, just to have a failure exit code if the test fail. > > It would be equally silly the other way around in a different set of > circumstances. But yes, making this configurable might be useful, but > this should then be done in the local configuration, not in the cygport > file. If I put it in ~/.config/cygport.conf it will impact all packages, not just the "one". The only place it is limited to applicable package is in the package.cygport file, or am I missing something? e.g. $ cat pdfgrep.cygport NAME="pdfgrep" VERSION=2.1.2 RELEASE=1 CATEGORY="Text" SUMMARY="Command-line utility for searching text in PDFs" DESCRIPTION="Pdfgrep is a tool to search text in PDF files. It works much like grep, with one distinction: it operates on pages and not on lines." HOMEPAGE="https://pdfgrep.org/; SRC_URI="https://pdfgrep.org/download/pdfgrep-${VERSION}.tar.gz; # git format-patch --stdout v2.1.2..cygwin-2.1.2 > v2.1.2..cygwin-2.1.2.patch PATCH_URI="v2.1.2..cygwin-2.1.2.patch" BUILD_REQUIRES="asciidoc gcc-g++ libpoppler-cpp-devel libgcrypt-devel libpcre-devel dejagnu texlive-collection-latex" src_test() { cd ${B} make check }
[RFC] FAST_CWD warnings on ARM64 insider preview
I have been trying out x86_64 msys2 (a fork of cygwin) on Windows insider preview builds on ARM64, which added support for x86_64 emulation. I was getting the notorious FAST_CWD warnings, which were interfering with MINGW CMake. Last night late, I went looking at the cause, and found some code that attempted to disable FAST_CWD warnings, but only on i686, and trying to look at GetNativeSystemInfo, which was lying. I quickly put together this patch, and it seems to work. Note I did this late at night, with no real regard to investigating or matching code style. This patch is currently more in an RFC state, if the approach looks OK, and I'd be grateful for any pointers on getting it into shape for evental acceptance. Thanks, JeremyFrom 346dfb78fc5522d5d7288571d635303c69a5270a Mon Sep 17 00:00:00 2001 From: Jeremy Drake Date: Tue, 18 May 2021 00:48:52 -0700 Subject: [PATCH] cygwin: suppress FAST_CWD warnings on ARM64. The old check was insufficient: new insider preview builds of Windows allow running x86_64 process on ARM64. The IsWow64Process2 function seems to be the intended way to figure this situation out. --- winsup/cygwin/path.cc | 30 ++ 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index dd7048486..5c4adcd49 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -4708,29 +4708,19 @@ find_fast_cwd () { bool warn = 1; -#ifndef __x86_64__ - #ifndef PROCESSOR_ARCHITECTURE_ARM64 - #define PROCESSOR_ARCHITECTURE_ARM64 12 - #endif +#ifndef IMAGE_FILE_MACHINE_ARM64 +#define IMAGE_FILE_MACHINE_ARM64 0xAA64 +#endif - SYSTEM_INFO si; + USHORT procmachine, nativemachine; /* Check if we're running in WOW64 on ARM64. Skip the warning as long as -there's no solution for finding the FAST_CWD pointer on that system. - -2018-07-12: Apparently current ARM64 WOW64 has a bug: -It's GetNativeSystemInfo returns PROCESSOR_ARCHITECTURE_INTEL in -wProcessorArchitecture. Since that's an invalid value (a 32 bit -host system hosting a 32 bit emulator for itself?) we can use this -value as an indicator to skip the message as well. */ - if (wincap.is_wow64 ()) - { - GetNativeSystemInfo (); - if (si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_ARM64 - || si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_INTEL) - warn = 0; - } -#endif /* !__x86_64__ */ +there's no solution for finding the FAST_CWD pointer on that system. */ + + typedef BOOL (WINAPI * IsWow64Process2_t)(HANDLE hProcess, USHORT *pProcessMachine, USHORT *pNativeMachine); + IsWow64Process2_t pfnIsWow64Process2 = (IsWow64Process2_t)GetProcAddress(GetModuleHandle("kernel32.dll"), "IsWow64Process2"); + if (pfnIsWow64Process2 && pfnIsWow64Process2(GetCurrentProcess(), , ) && nativemachine == IMAGE_FILE_MACHINE_ARM64) + warn = 0; if (warn) small_printf ("Cygwin WARNING:\n" -- 2.31.1.windows.1
Re: Fwd: outdated git-review version
Hi Marco, I would greatly appreciate you adopting and updating this package. I no longer use it in my day job. Regards, David On 5/18/2021 9:49 AM, Marco Atzeri via Cygwin-apps wrote: David, It seems this package is still python 2.7 one. If you want I can take over and adapt to python 3.8 Forwarded Message Subject: outdated git-review version Date: Tue, 18 May 2021 11:50:38 + From: Rutkowska, Anna (Nokia - PL/Wroclaw) Hi, Latest available git-review package is 1.26 which currently cases following problem $ git review remote: error: branch refs/publish/master: remote: If you are using git-review, update to at least git-review 1.27. Could you make 1.27 or 1.28 available? Best regards, Anna Rutkowska - Regards Marco -- David Rothenberger daver...@acm.org Badges? We don't need no stinking badges.
Re: pdfgrep [ITA]
Jason Pyeron writes: > I am assuming that I should not include cygport in the build > requires. Yes, we currently assume cygport and its transitive dependencies to be available for a cygport based package. The build requires should enable the CI to build the package correctly. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
[ANNOUNCEMENT] Updated: guile-3.0.7-1
Version 3.0.7-1 of guile3.0 libguile3.0-devel libguile3.0_1 have been uploaded for cygwin. CYGWIN NOTE "guile" package has been obsoleted The package postinstallation script uses alternatives(8) to install a symlink for /usr/bin/{guile,guild,guile-config} programs. CHANGES Latest upstream bugfix releases. https://www.gnu.org/software/guile/news/gnu-guile-307-released.html DESCRIPTION Guile is an implementation of the Scheme programming language, supporting the Revised5 and most of the Revised6 language reports, as well as many SRFIs. Guile is designed to help programmers create flexible applications that can be extended by users or other programmers with plug-ins, modules, or scripts. HOMEPAGE https://www.gnu.org/software/guile/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: guile-3.0.7-1
Version 3.0.7-1 of guile3.0 libguile3.0-devel libguile3.0_1 have been uploaded for cygwin. CYGWIN NOTE "guile" package has been obsoleted The package postinstallation script uses alternatives(8) to install a symlink for /usr/bin/{guile,guild,guile-config} programs. CHANGES Latest upstream bugfix releases. https://www.gnu.org/software/guile/news/gnu-guile-307-released.html DESCRIPTION Guile is an implementation of the Scheme programming language, supporting the Revised5 and most of the Revised6 language reports, as well as many SRFIs. Guile is designed to help programmers create flexible applications that can be extended by users or other programmers with plug-ins, modules, or scripts. HOMEPAGE https://www.gnu.org/software/guile/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
Fwd: outdated git-review version
David, It seems this package is still python 2.7 one. If you want I can take over and adapt to python 3.8 Forwarded Message Subject: outdated git-review version Date: Tue, 18 May 2021 11:50:38 + From: Rutkowska, Anna (Nokia - PL/Wroclaw) Hi, Latest available git-review package is 1.26 which currently cases following problem $ git review remote: error: branch refs/publish/master: remote: If you are using git-review, update to at least git-review 1.27. Could you make 1.27 or 1.28 available? Best regards, Anna Rutkowska - Regards Marco
Re: gengetopt missing in x86 package search and x86 setup.ini
On 18.05.2021 15:47, Brian Inglis wrote: Needed dependency for libidn build missing from x86. It seems Rafel has missed to note the need to build for both architectures.
gengetopt missing in x86 package search and x86 setup.ini
Needed dependency for libidn build missing from x86. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
outdated git-review version
Hi, Latest available git-review package is 1.26 which currently cases following problem $ git review remote: error: branch refs/publish/master: remote: If you are using git-review, update to at least git-review 1.27. Could you make 1.27 or 1.28 available? Best regards, Anna Rutkowska -- 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
Outdated git-review package
Hi, Latest git-review package available in Cygwin repository is old (1.26.0-1) and is not supported by recent Gerrit Code Review (3.2.7 and newer). It would be great if more recent version of git-review was available. -- Best regards, Maciej Olędzki -- 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: preventing setup from forking
On 17.05.2021 23:12, Jason Pyeron wrote: -Original Message- From: Jon Turney Sent: Monday, May 17, 2021 4:41 PM My real issue was the user was not an admin - doh! that could be due to "setup" in the program name. It is one of the "security" ideas of MS Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: pdfgrep [ITA]
On 17.05.2021 21:59, Jason Pyeron wrote: -Original Message- From: Marco Atzeri Sent: Sunday, May 9, 2021 3:55 PM General suggestion: - add BUILD_REQUIRES="libpcre-devel libgcrypt-devel libpoppler-cpp-devel" the test suite seems to need tcl so you may need to add more packages I am assuming that I should not include cygport in the build requires. These are the packages I install to build: asciidoc gcc-g++ libpoppler-cpp-devel libgcrypt-devel libpcre-devel dejagnu texlive-collection-latex cygport -Jason I am almost sure that also gcc-g++ is assumed to be present Dejagnu pulls tcl, so that is covered: $ cygcheck-dep -S -q -R dejagnu dejagnu: recursively requires ( bash coreutils cygwin expect libattr1 libgmp10 libiconv2 libintl8 libncursesw10 libreadline7 sed tcl terminfo terminfo-extra tzcode tzdata zlib0 )
[ANNOUNCEMENT] rebase 4.5.0-1
The following packages have been uploaded to the Cygwin distribution: * rebase-4.5.0-1 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. What's new: - Introduce --merge-files (-M) flag. The --merge-files flag is to update the database for new files, without performing a rebase. The file names provided should have been rebased using the --oblivious flag just before. - Introduce --high-entropy-va (-e) flag. This flag allows for setting, clearing, and displaying the value of the "high entropy va" dll characteristics flag, which is required to indicate that a DLL is 64 bit ASLR clean. - The --verbose option now prints a reason why rebase is necessary. - Some errors causing an unnecessary rebase are fixed. - Add a --with-posix-shell configure flag to use other shells than dash to be used as default shell in scripts. This is only interesting when building rebase for non-Cygwin distros. -- 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
rebase 4.5.0-1
The following packages have been uploaded to the Cygwin distribution: * rebase-4.5.0-1 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. What's new: - Introduce --merge-files (-M) flag. The --merge-files flag is to update the database for new files, without performing a rebase. The file names provided should have been rebased using the --oblivious flag just before. - Introduce --high-entropy-va (-e) flag. This flag allows for setting, clearing, and displaying the value of the "high entropy va" dll characteristics flag, which is required to indicate that a DLL is 64 bit ASLR clean. - The --verbose option now prints a reason why rebase is necessary. - Some errors causing an unnecessary rebase are fixed. - Add a --with-posix-shell configure flag to use other shells than dash to be used as default shell in scripts. This is only interesting when building rebase for non-Cygwin distros.
Re: [PATCH] Add support for high-entropy-va flag to peflags.
On May 17 12:15, Jeremy Drake via Cygwin-patches wrote: > On Mon, 17 May 2021, Corinna Vinschen wrote: > > > Hi Jeremy, > > > > Thanks for the patch, but I have two nits: > > > > - The patch doesn't apply cleanly with `git am'. Please check again. > > Probably got mangled in the mail. Attached this time. > > > > > - I would prefer a massively reduced patch size, by *not* changing > > indentation on otherwise unaffected lines. > > > > Done Thank you. Pushed. I'll upload a rebase 4.5.0 release to the Cygwin distro today. Thanks, Corinna