v1.7
Aloha, We are currently using v1.7 but it is no longer DADMS supported. Would it be possible to get a vendor support statement email so that we may continue using this version? Thanks, Anne smime.p7s Description: S/MIME cryptographic signature
Re: [ANNOUNCEMENT] Updated: units 2.14-1
On 2017-05-22 12:38, Ian Lambert wrote: > On May 22, 2017 2:09:35 PM EDT, Brian Inglis wrote: >> On 2017-05-21 23:45, Brian Inglis wrote: >>> On 2017-04-27 13:20, Brian Inglis wrote: * units-2.14-1 The Units program converts quantities >> Timegenie.com cert has been renewed for another 3 months until >> August 19 and redeployed, so certs are valid and will no longer >> produce errors. > In /var/log/setup.log.full I see: > Error connecting to currency server. not known> > Running /usr/bin/units_cur or /etc/postinstall/zp_units_cur.sh I get > Error connecting to currency server. HTTP Error 407: Proxy Authentication > Required > I'm behind a proxy requiring username, password, and restrictions on > user-agents... I'll take handling that, cert issue, and config issue upthread, upstream for discussion, follow up on cygwin-apps, and report back here, or provide a package update. -- 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: [ANNOUNCEMENT] Updated: units 2.14-1
On 2017-05-22 12:08, Achim Gratz wrote: > Brian Inglis writes: >> Currency exchange rates are updated on every run of setup by a permanent >> postinstall script >> /etc/postinstall/zp_units_cur.sh >> running >> /usr/bin/units_cur > > Can you please make that configurable by some file in /var/lib/units > that will prevent the perpetual postinstall script from even forking if > the user decides that this should not be updated? I'll take handling that, cert issue, and a proxy issue later in the thread, upstream for discussion and follow up on apps. -- 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: Composer segfault on multiple configurations
On 18/05/2017 08:42, Sky Diver wrote: I may compile php from cygports Just in case Sky Diver or anyone else is interested in compiling php from Cygports, here are some simple steps to do so. It's not really difficult and most of the time it takes up is downloading the packages and compiling php. You'll probably want to do the compilation step during a lunch break or something. If you just want to get a patched php running, just skip to the steps below. But I'm also putting putting these instructions out here in case anyone wants to do some testing. The php devs asked for confirmation that (a) the bug exists and (b) this patch actually fixes it, before committing the patch. The devs ask this as they have had problems setting up a dev environment for php. So they are unable recreate this bug or test the patch themselves. This is why I feel any Cygwin-specific patches for php should, for the moment be submitted to Cygwin rather than going to php. To recreate the bug, create a 4096 bytes php file. $ for i in $(seq 4096); do echo; done > test.php Then execute it. $ php test.php This should immediately segfault. You can also test it through apache as there are two ways this bug can occur, through the php cli and through the apache php module. That is why the patch is against two different points in the source. By running apache in debug mode, you can see when the segfault occurs. $ /usr/sbin/apachectl -X Steps = 1. Install the php source from cygwin Install php from the Cygwin installer as normal, except check the Src checkbox as well as the Bin checkbox. 2. cd into the source directory $ cd /usr/src/php-7.0.19-1.src 3. Copy the attachments over in that directory - dependencies - php-7.0.19-page-size.patch - php-cygport-page-size.patch 5. Install the dependencies There are 59 packages required to build php with cygport, listed in the attachment "dependencies". You'll probably use the command line for this rather than manually pick out the packages by hand in Cygwin's setup. You can either use setup's command line -P option or apt-cyg. I used apt-cyg, so for me I run: $ xargs apt-cyg install < dependencies It will take a while to download all these packages. 4. Patch the cygport file $ patch < php-cygport-page-size.patch 6. Prepare the source for compilation $ cygport php.cygport prep 7. Compile php $ cygport php.cygport compile Depending on your cpu, this will take a significant amount of time. 8. Install your compiled php into a staging directory $ cygport php.cygport install 9. Copy the files over from staging into root $ rsync -varlI php-7.0.19-1.x86_64/inst/. / 10. Rebase the dlls in cygwin $ rebase-trigger full Exit all Cygwin processes, command line and services. Run Cygwin's setup to actually perform the rebase. If you rerun "php test.php" you now should get 4096 newlines instead of a segfault. Should the patch miss php 7.0.20 or whatever the next version of php is for Cygwin, you can rerun the steps and just change the path names in steps 2 and 9. But hopefully the path will be merged in by then. diff --git a/Zend/zend_stream.c b/Zend/zend_stream.c index 3fd7fa0..f5b9bea 100644 --- a/Zend/zend_stream.c +++ b/Zend/zend_stream.c @@ -30,7 +30,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif diff --git a/main/main.c b/main/main.c index 01ed3a6..0909309 100644 --- a/main/main.c +++ b/main/main.c @@ -96,7 +96,11 @@ # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN__ +#define REAL_PAGE_SIZE 4096 +# else #define REAL_PAGE_SIZE sysconf(_SC_PAGESIZE); +# endif # elif defined(_SC_PAGE_SIZE) #define REAL_PAGE_SIZE sysconf(_SC_PAGE_SIZE); # endif --- php.cygport 2017-05-14 09:27:04.0 +0100 +++ php-new.cygport 2017-05-20 18:18:45.937823600 +0100 @@ -35,6 +35,7 @@ 5.6.6-fix-libtoolize.patch 5.6.9-apache2handler-zts.patch 7.0.17-pcre-jit-off.patch + php-7.0.19-page-size.patch " DIFF_EXCLUDES="aclocal.m4 configure generated_lists libtool.m4 lt*.m4 ltmain.sh php_config.h.in php_version.h tests" apache2-devel c-client cygport libaspell-devel libattr-devel libcroco0.6-devel libcurl-devel libedit-devel libenchant-devel libfam-devel libffi-devel libgd-devel libgdbm-devel libglapi-devel libgnutls-devel libgs-devel libgtk2.0-devel libgts-devel libguile1.8-devel libguile2.0-devel libgvc-devel libhunspell-devel libicu-devel libidn2-devel libisl-devel libjasper-devel libkrb5-devel libLASi-devel liblcms-devel libllvm-devel liblzo2-devel libmcrypt-devel libming-devel libmpc-devel libmpfr-devel libnghttp2-devel libnss-devel libonig-devel libopenjp2-devel libopenjpeg-devel libpng12-devel libpoppler-devel libpq-devel libpsl-devel libreadline-dev
Re: [ANNOUNCEMENT] Updated: units 2.14-1
On May 22, 2017 2:09:35 PM EDT, Brian Inglis wrote: >On 2017-05-21 23:45, Brian Inglis wrote: >> On 2017-04-27 13:20, Brian Inglis wrote: >>> * units-2.14-1 >>> >>> The Units program converts quantities > >Timegenie.com cert has been renewed for another 3 months until August >19 >and redeployed, so certs are valid and will no longer produce errors. FYI, In /var/log/setup.log.full I see: Error connecting to currency server. Running /usr/bin/units_cur or /etc/postinstall/zp_units_cur.sh I get Error connecting to currency server. HTTP Error 407: Proxy Authentication Required I'm behind a proxy requiring username, password, and restrictions on user-agents... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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: [ANNOUNCEMENT] Updated: units 2.14-1
On 2017-05-21 23:45, Brian Inglis wrote:
> On 2017-04-27 13:20, Brian Inglis wrote:
>> * units-2.14-1
>>
>> The Units program converts quantities expressed in various scales to
>> their equivalents in other scales. The units program can handle
>> multiplicative scale changes as well as nonlinear conversions such as
>> Fahrenheit to Celsius or wire gauge. Units comes with an annotated,
>> extendable database defining over two thousand units.
>>
>> This is an update to the latest upstream release, which now supports
>> longer input expressions (e.g. a sum of more than 100 units), control
>> characters treated as white space to avoid producing errors about
>> invalid UTF-8, and includes 2980 units, 109 prefixes, and 96 nonlinear
>> units.
Timegenie.com cert has been renewed for another 3 months until August 19
and redeployed, so certs are valid and will no longer produce errors.
> Currency exchange rates are updated on every run of setup by a permanent
> postinstall script
> /etc/postinstall/zp_units_cur.sh
> running
> /usr/bin/units_cur
> to access
> https://rss.timegenie.com
> which uses HSTS to enforce https access, and whose security certificate
> has expired, so runs will fail with message:
> Error connecting to currency server. CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)>
>
> If this causes you problems, please temporarily rename the current
> update script /usr/bin/units_cur and replace by the attached, or replace
> the line between the first try: and except ...: by the following lines:
> [the first line is a comment, the remainder are indented two spaces]
>
> #
> http://stackoverflow.com/questions/36600583/python-3-urllib-ignore-ssl-certificate-verification
> import ssl
> ctx = ssl.create_default_context()
> ctx.check_hostname = False
> ctx.verify_mode = ssl.CERT_NONE
> currencies =
> ET.parse(urllib.request.urlopen('https://rss.timegenie.com/forex.xml',context=ctx)).findall('data')
>
> to ignore the security certificate expiry until it is renewed (hopefully
> by sometime Tuesday after the holiday): when the security certificate
> has been renewed, I will follow up here to let everyone know.
--
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: [ANNOUNCEMENT] Updated: units 2.14-1
Brian Inglis writes: > Currency exchange rates are updated on every run of setup by a permanent > postinstall script > /etc/postinstall/zp_units_cur.sh > running > /usr/bin/units_cur Can you please make that configurable by some file in /var/lib/units that will prevent the perpetual postinstall script from even forking if the user decides that this should not be updated? 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 -- 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: ANSI colors not showing by default
On Mon, May 22, 2017 at 1:49 PM, Richard H Lee wrote: > It appears you needs to install the php-posix package to get termcap info. Wow Richard, another hit on the nail's head. Impressive. That did the trick. Thank you very much! -- 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: Bug? wcsxfrm causing memory corruption
On Sun, May 21, 2017 at 6:23 AM, Duncan Roe wrote:
> On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote:
>> Greetings--
>>
>> In the process of fixing the Python test suite on Cygwin I ran across
>> one test that was consistently causing segfaults later on, not
>> directly local to that test. The test involves wcsxfrm so that's
>> where I focused my attention.
>>
>> The attached test demonstrates the bug. Given an output buffer of N
>> wide characters, wcsxfrm will cause bytes beyond the destination size
>> to be reversed. I believe it might actually be a bug in the underlying
>> LCMapStringW workhorse (this is on Windows 10; have not tested other
>> versions).
>>
>> According to its docs [1], the cchDest argument (size of the
>> destination buffer) is treated as a *byte* count when using
>> LCMAP_SORTKEY. However, for the purposes of applying the
>> LCMAP_BYTEREV transformation it seems to be treating the output size
>> (in bytes) as character count. So in the example I give, where the
>> output sort key is 7 bytes (including the null terminator), it swaps
>> *14* bytes--the bytes including the sort key as well as the next 7
>> adjacent bytes. This is obviously a problem if the destination buffer
>> is allocated out of some larger memory pool.
>>
>> This definitely has to be a bug, right? Or at least very poorly
>> documented on MS's part. A workaround would either be to not use
>> LCMAP_BYTEREV and just swap the bytes manually, or in a second call to
>> LCMapStringW with LCMAP_BYTEREV and the correct character count...
>>
>> Thanks,
>> Erik
>>
>>
>> [1]
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd318700(v=vs.85).aspx
>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> #define SIZE 32
>>
>>
>> void fill_bytes(uint8_t *a, int n) {
>> int idx;
>> for (idx=0; idx> a[idx] = idx;
>> }
>> }
>>
>>
>> void print_bytes(uint8_t *a, int n) {
>> int idx;
>> for (idx=0; idx> printf("0x%02x ", ((uint8_t*)a)[idx]);
>> if ((idx + 1) % 8 == 0) printf("\n");
>> }
>> }
>>
>> int main(void) {
>> wchar_t *a, *b;
>> uint8_t *aa;
>> size_t ret;
>> LCID collate_lcid;
>> int idx;
>> collate_lcid = 1033;
>> b = L"b";
>> a = (wchar_t*) malloc(SIZE);
>> aa = (uint8_t*) a;
>>
>> setlocale(LC_ALL, "en_US.UTF-8");
>>
>> printf("using wcsxfrm:\n");
>> fill_bytes(aa, SIZE);
>> printf("before:\n");
>> print_bytes(aa, SIZE);
>> ret = wcsxfrm(a, b, 4);
>> printf("after (%d):\n", ret);
>> print_bytes(aa, SIZE);
>>
>> printf("\nusing LCMapStringW directly:\n");
>> fill_bytes(aa, SIZE);
>> printf("before:\n");
>> print_bytes(aa, SIZE);
>>
>> ret = LCMapStringW(collate_lcid, LCMAP_SORTKEY | LCMAP_BYTEREV, b, -1,
>> a, 8);
>> printf("after (%d):\n", ret);
>> print_bytes(aa, SIZE);
>>
>> printf("\nwithout LCMAP_BYTEREV:\n");
>> fill_bytes(aa, SIZE);
>> printf("before:\n");
>> print_bytes(aa, SIZE);
>>
>> ret = LCMapStringW(collate_lcid, LCMAP_SORTKEY, b, -1, a, 8);
>> printf("after (%d):\n", ret);
>> print_bytes(aa, SIZE);
>> free(a);
>>
>> return 0;
>> }
>
> Hi Erik,
>
> I get
>
> using wcsxfrm:
> before:
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
> 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
> after (3):
> 0x09 0x0e 0x01 0x01 0x01 0x01 0x00 0x00
> 0x09 0x08 0x0b 0x0a 0x0d 0x0c 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
>
> using LCMapStringW directly:
> before:
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
> 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
> after (7):
> 0x09 0x0e 0x01 0x01 0x01 0x01 0x07 0x00
> 0x09 0x08 0x0b 0x0a 0x0d 0x0c 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
>
> without LCMAP_BYTEREV:
> before:
> 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07
> 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
> after (7):
> 0x0e 0x09 0x01 0x01 0x01 0x01 0x00 0x07
> 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
> 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17
> 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f
Yes, that's the same. Thanks for giving it a try--I should have
included example output in my original message.
You can see in the last case that without LCMAP_BYTEREV it writes the sequence
0x0e 0x09 0x01 0x01 0x01 0x01 0x00
with a terminating 0x00. Bytes after that remain unchanged. In the
other two examples *with* LCMAP_BYTEREV, the terminating 0x00 gets
swapped with the 0x07 after it, but this documented and expected
behavior of LCMapStringW, and is already accounted for in Cygwin's
wcsxfrm. What is undocumented, and unexpected, is that it also byte
swaps 3 more byte pairs after the a
Re: xwin-xdg-menu terminal not picking up my environment
On 21/05/2017 18:18, peter...@sdf.org wrote: The xwin-xdg-menu's terminal does not seem to pick up the environment variables I have set in my home directory when I use it's terminal to run a non-x program from /bin. i.e. I added Midnight Commander to the xwin-xdg-menu (using alacarte) seting /bin/mc as the executable and check the "run in terminal?" box. I prefer to use joe or nano as the editor in mc and have turned off mc's internal editor which picks up the editor in the "EDITOR" environment variable which I set in ~/.bashrc (I also tried setting it in ~/.bash_profile and ~/.profile). Mc comes up with vi (which is the default in mc if no "EDITOR" environment variable is set). I can run an XTerm from the xwin-xdg-menu and then launch mc from that and it honors the "EDITOR" environment variable. By the way if I shell out (Ctrl-O) from mc and execute "env" the "EDITOR" variable shows up in the list. Weird. So where does xwin-xdg-menu's terminal get it's environment from? xwin-xdg-menu shouldn't be doing anything to the environment, and especially not based on if it's running a terminal... If you're starting it from the start menu item, it inherits the environment from the login shell which that uses to run startxwin, and the processes it starts inherit that environment in turn. The behaviour of bash in this area is complex (see the section "INVOCATION" in the man page), but I suspect that any other non-interactive shells in the ancestry of the mc process won't have run startup scripts. So, if you've made a change to bash startup files, you'd need to restart xwin-xdg-menu to see a change. -- 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: ANSI colors not showing by default
On 21/05/2017 21:45, Sky Diver wrote: Lately I noticed that colors are not showing by default in some situations. The most apparent case is when running composer. The latest composer version on "Bash on Ubuntu on Windows" console, and even when running it via a mintty shell looks just fine. But from cygwin the output is monochrome. It appears you needs to install the php-posix package to get termcap info. https://serverfault.com/questions/591105/centos-colors-in-php-cli-applications#comment-698025 -- 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
