Re: Base 64-bit Cygwin now requires Perl? (indent DONE)
2014-11-01 21:16 Corinna Vinschen : | | > > indent | > | > Not sure this is needed either. | | Removed on sourceware. | | Jari, can you please keep track of this change? Uploaded new x64 *-2 without texinfo dependency. Thanks. Jari pgpz25O3CUgov.pgp Description: PGP signature
Different (and wrong) timezones reported by both strftime(3) and date(1)
Hello,
I've run into an issue of both strftime(3) and date(1) reporting
different (and wrong) timezones. I'm in the MSK timezone (switched
from +0400 to +0300 on 10/26/14). However, as of today, 11/2/14, the
following simple program
#include
#include
int main()
{
char buf[128];
time_t tt = time(NULL);
tm* lt = localtime(&tt);
strftime(&buf[0], 128, "%H:%M:%S%z\n", lt);
printf("%s\n", buf);
return 0;
}
outputs "14:10:00+0330". Both time and timezone here are wrong (it
should be "13:10:00+0300" instead, and Moscow is never in the "+0330"
timezone).
Running "date +'%H:%M:%S%z'" at the same time produces
"14:10:00+0400", which is better, since Moscow was in the "+0400"
timezone a week ago, but it still should be "13:10:00+0300" as in the
example above).
Curiously enough, `unset`ting the TZ environment variable fixes both
of these issues.
Anyway, I hope somebody will be able to fix this issue anytime.
Thanks,
Egor.
--
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: texinfo-5.2-3
Ken Brown wrote: ...but the command 'makeinfo --pdf' won't work unless you install texinfo-tex Before the splitting I had installed the texinfo package and it did not require any TeXLive packages. Now If I try to install also texinfo-tex package, setup wants to install also texlive packages which I don't need. Indeed I already have TexLive installed as monolithic distribution from TeXLive site. It looks as if we have exchanged Perl with TeXLive... Ciao, Angelo. -- 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/deficiency in zip: non-ascii chars in file names work, but fail in directory names
Doug Henderson wrote: "You need to add the -r option to recurse into directories:" You are 100% correct; my oversight. Actually, it was a copy and paste error: the real code that I want to test does use -r, but when I tried to adapt that code to a simpler format for my email, I accidentally dropped the -r. The code that I really want to test fails with a different error, so you solved a mystery that was really bugging me: why the console code in my email behaved differently from the test code I really care about. I returned to analysing my real test code more carefully, and I still see a problem with cygwin's unzip: it fails to extract zip files with unicode names that are produced by OTHER programs (i.e. some other program besides cygwin zip). In particular, one part of my test code creates a zip archive using Java (ZipOutputStream and ZipEntry), and then confirms that the archive can be extracted and exactly reproduced by multiple other means. The first extraction method is to again use Java (ZipFile and ZipEntry); this works perfectly, as it should. The second extraction method is to use cygwin's unzip; this fails: IT MANGLES THE NAMES. In particular: 1) the directory should be åØâéñ (\u00E5\u00D8\u00E2\u00E9\u00F1) 2) the file should be 㐀丁龦豈侮_file#2_length2048.txt (first 5 chars \u3400\u4E01\u9FA6\uF900\uFA30) but what cygwin unzip actually produces during extraction is 1) the directory is +++++ 2) the file is ڥǴ_file#2_length2048.txt To rule out Java as being non-standard, I manually took the zip archive it produced and extracted it using the latest 7-zip (9.20), which worked perfectly (the directory and file names came out exact). To further verify, I also temporarily installed the latest WinZip (19.0 build 11293) and once again, it extracted Java's zip file with non-ASCII names perfectly. If anyone wants to verify these claims, I am attaching the zip file produced by Java (and extractable by 7zip and WinZip, but NOT by cygwin unzip) to this email. [UPDATE: my original email yesterday had this attachment, but I do not see it showing up on the mailing list. I take it that cygwin mailing lists auto reject emails with attachments?] So, I reckon that cygwin unzip is the odd man out. Oh, when I try to view this zip file using Windows 7's integrated zip viewed in Windows Explorer, it displays mangled directory and file names that are something different still from what cygwin unzip produced. This link https://www.jam-software.com/treesize/online_manual/EN/unicode_zip_files.html claims that Windows 7 does not really support unicode names, so this is perhaps expected. Also, I found that this inter-program compatibility is limited to cygwin unzip: cygwin zip seems to produce archives involving unicode names that other programs can extract just fine. I did some web research, and the most relevant link that I could find about cygwin unzip and unicode is this old announcement from 2009: https://cygwin.com/ml/cygwin-announce/2009-08/msg6.html That announcement contains this ominous text: Currently, on Windows the UTF-8 handling is limited to the character subset contained in the configured non-unicode "system code page". Is it possible that the deficiency mentioned above has simply not been fixed in the last 5 years? -- 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: texinfo-5.2-3
On 11/2/2014 8:30 AM, Angelo Graziosi wrote: Ken Brown wrote: ...but the command 'makeinfo --pdf' won't work unless you install texinfo-tex Before the splitting I had installed the texinfo package and it did not require any TeXLive packages. That was because I had decided not to require texlive, since so much of the functionality of texinfo was usable without it. But it was still the case with the old packaging that 'makeinfo --pdf' wouldn't work without a TeX installation. Now If I try to install also texinfo-tex package, setup wants to install also texlive packages which I don't need. The whole point of texinfo-tex is that it contains those programs from the old texinfo package that are useless without TeX. So naturally texinfo-tex requires texlive. Indeed I already have TexLive installed as monolithic distribution from TeXLive site. That's a completely different issue, not really related to texinfo. If there are Cygwin packages that require TeX in order to function, I think maintainers have to make them depend on texlive. Users who choose to install TeX from another source will find this annoying, but I don't see what I can do about that. Some Linux distros have mechanisms for dealing with this situation; I don't remember the details, but somehow it's possible to declare that you have installed something equivalent to a given package. But Cygwin's setup doesn't provide this feature. It looks as if we have exchanged Perl with TeXLive... Not really. The issue with Perl was that it was included in a *default* Cygwin installation. 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: Setup 2.774 texlive postinstall takes 10+ hours
On 10/30/2014 6:27 PM, Don MacDougall wrote: So, why the postinst scripts failed to run before, now becomes an academic matter for me. Nevertheless, let me point out for the sake of the archives that the answer was contained in one of your earlier messages: On 10/24/2014 3:11 AM, Don MacDougall wrote: > Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. >7 [main] perl 8088 child_info_fork::abort: unable to remap Fcntl.dll > to same address as parent (0x2E) - try running rebaseall The problem is that many of the texlive postinstall scripts run perl scripts, and these failed as above because rebaseall needed to be run. I guess this problem will occur whenever perl and texlive are installed simultaneously. I'm not sure what the solution is. Would it be hard to tweak setup.exe so that it runs the autorebase postinstall script before running any others? Or would this be a bad idea for other reasons? 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: Different (and wrong) timezones reported by both strftime(3) and date(1)
Egor Tensin gmail.com> writes: > I've run into an issue of both strftime(3) and date(1) reporting > different (and wrong) timezones. I'm in the MSK timezone (switched > from +0400 to +0300 on 10/26/14). Wow - tzcode release is ancient - 2013c from April 2013 - went up to 2013i last year and current is 2014i. Okay if you live in NA or EU, but not the rest of the world, where DST changes on political whims, often on short notice. As this package is part of base, any chance of getting it updated with similar frequency to ca-certs, or splitting tzdata into a separate package which can be easily and frequently updated? -- 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
