Re: advice about setting up the eigen library for use with cygwin g++
Hi, On Thu, Dec 4, 2014 at 10:43 PM, LMH wrote: > Hello, > > As stated, I am writing a few tools with cygwin g++. (snip) > Eigen is a header only kind of thing, so my understanding is that all I > need to do is to unpack the src somewhere add the location to the > include path. > > I was thinking of putting Eigen in, > > /cygdrive/c/cygwin/lib/eigen/ If you use Cygwin tools, you shouldn't use paths like "/cygdrive/c/cygwin/lib". The way to refer to that directory is /lib (unless your Cygwin is installed somewhere other than C:\cygwin). > > and using, > > g++ -I /cygdrive/c/cygwin/lib/eigen/ > /lib is not really for headers. It mostly contains binaries. A canonical place for a header-only library would be /usr/local/include/eigen Doesn't eigen supply a makefile with an "install" target? Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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] Cygwin's git says "error: failed to read delta-pack base object"
On Thu, Dec 4, 2014 at 10:27 PM, Dave Lindbergh wrote: > I'm still stumped. You should have stood closer to the wicket :) Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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 AD integration home/shell changes
On Dec 5 08:07, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> >> > Here's what you get: > >> >> > >> >> I finally realized, what was tingling me all this time. > >> >> The implicit fallback mechanics. I'd rather want to have explicit > >> >> declaration > >> >> and a failure message in case something isn't right. Much easier to fix > >> >> system > >> >> issues, when the system tell you about them. > >> > >> > The fallback mechanism is pretty much required to have a sane default > >> > which works for home users without having to change nsswitch.conf at > >> > all. Also, not everybody will want error messages rather than some sane > >> > fallback (for any given value of "sane"), while if you don't want a sane > >> > fallback, you can easily create an unsane fallback to help you maintain > >> > your solution, e.g. > >> > >> > db_home: cygwin /invalid/read-only-path > >> > >> Why not set defaults (in case of db_home) to > >> > >> db_home: cygwin desc /home/%U > >> > >> and remove fallback? > >> It just not seems right - creating workarounds to implement straight > >> behavior. > > > It's not a workaround from my POV to provide a fallback. Creating a > > workable passwd entry is important. If I implement it as you suggest > > above, I would still provide the typical "set home to the root dir" > > default. Sure, that might be an option. > > If you mean "complain and set home to the root", then I'm happy with this > solution. No complain. You still seem to have a problem to understand that this is underlying functionality under a couple of system calls generating passwd entries for arbitrary accounts. It's *not* necessarily the current account. A user visible complaint for every unconfigured account enumerated via getpwent is quite over the top. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp__3eHMVIll.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Dec 5 08:28, Andrey Repin wrote: > >> On Nov 11 12:14, Corinna Vinschen wrote: > >> The new stuff is still missing documentation, [...] > > > If you're wondering why I didn't create a test release yet, it's all > > about this dreaded documentation. > > > Did I mention already how much I hate writing documentation? Yes? > > Whatever. I really hate writing documentation! It's infinitely worse > > than writing the code. > > Every 10 lines of documentation I write for my projects make me want to > rewrite at least one line of the code. Because it feels stupid now, that I've > explained, how it works. Unfortunately you *have* to explain configuration. > > I'd appreciate if those not shy to install developer snapshots would > > give this stuff a try in the meantime. > > I think I'm about to make a script to install snapshots, at this rate it seems > the right thing to do. > Is there a direct way to query for the latest snapshot? The snapshots always have a date attached to the filename. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp10HogRgcak.pgp Description: PGP signature
tzset error
Hello! I run Cygwin Terminal and the first line I see the error: tzset: can not find matching POSIX timezone for Windows timezone "Belarus Standard Time" Installed all the latest updates. Windows 7. Windows Time Zone: (UTC+03:00) Minsk. Thanks. -- 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] Cygwin's git says "error: failed to read delta-pack base object"
On Dec 4 22:42, Adam Dinwoodie wrote: > On Thu, Dec 04, 2014 at 04:27:51PM -0500, Dave Lindbergh wrote: > > You are more than welcome to read the strace output if that'll give > > you a clue (it doesn't give me one). All 1.7 MBytes of it are at > > http://nerdfever.com/files/strace.txt > > > > (That comes from "strace git clone > > https://github.com/nerdfever/pic32mx-bmf >strace.txt") > > > > I'm still stumped. > > Okay, I'm looking through this trace in the hope of finding something. > The below looks suspicious, but I'm not sufficiently familiar with > either Git or Cygwin internals to know (a) whether this is a problem at > all or (b) if it is a problem, whether it's a symptom of an earlier > problem I haven't spotted on my brief skim. > > 616 12330609 [main] git 2348 unlink_nt: Trying to delete > \??\Z:\pic32mx-bmf\.git\objects\30, isdir = 1 > 3190 12333799 [main] git 2348 unlink_nt: Setting delete disposition on > \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 > 6362 12340161 [main] git 2348 unlink_nt: Try-to-bin > \??\Z:\pic32mx-bmf\.git\objects\30 > 24341 12364502 [main] git 2348 try_to_bin: > \??\Z:\pic32mx-bmf\.git\objects\30, return bin_status 3 > 645 12365147 [main] git 2348 unlink_nt: Try > \??\Z:\pic32mx-bmf\.git\objects\30 again > 12250 12377397 [main] git 2348 unlink_nt: Setting delete disposition on > \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 > 22680 12400077 [main] git 2348 unlink_nt: Try > \??\Z:\pic32mx-bmf\.git\objects\30 again > 8487 12408564 [main] git 2348 unlink_nt: Setting delete disposition on > \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 > 1903 12410467 [main] git 2348 unlink_nt: Try > \??\Z:\pic32mx-bmf\.git\objects\30 again > First a sharing violation (not visible in the above snippet), then directory not empty. This seems to be the result of an earlier problem. What I found in the strace is this: - Create file Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ - open file, write something, close file. - link (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ, Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4) succeeds. - unlink (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ) succeeds - Trying to open Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4 but the file doesn't exist and NtCreateFile fails with status 0xC034, STATUS_OBJECT_NAME_NOT_FOUND --> ENOENT. - Subsequent unlink (Z:\pic32mx-bmf\.git\objects\30) fails with a STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY. - git seems to be prepared for such a case, the parent process calls opendir/readdir on the directory. Enumerating the files in Z:\pic32mx-bmf\.git\objects\30 shows the entries ".", ".." and "0bdeb2fd209d24afb865584da10b78aa8fefc4". - Then git calls lstat on the file, which results in NtOpenFile returning status STATUS_OBJECT_NAME_NOT_FOUND again. - From a POSIX POV this means "somebody else" deleted the file, so the dir is empty now. Git tries to delete the directory again, which again results in STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY and, internally, a sharing violation which disallows to move the directory out of the way. This looks suspiciously like a bug in the remote filesystem. Link succeeded, so there are two links to the same file in the directory. Unlinking link 1 succeeds, so there's still one link to the file in the directory, but link 2 is inaccessible as if the file has been deleted completely. Thus, a full POSIX git on this drive is broken. Can you please run /usr/lib/csih/getVolInfo /cygdrive/z and paste the output here? Maybe I can workaround this in the next Cygwin version. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4OooA8p6xN.pgp Description: PGP signature
Re: tzset error
On Dec 5 14:32, r...@inbox.ru wrote: > Hello! > > I run Cygwin Terminal and the first line I see the error: > > tzset: can not find matching POSIX timezone for Windows timezone "Belarus > Standard Time" > > Installed all the latest updates. > Windows 7. Windows Time Zone: (UTC+03:00) Minsk. Oh. Sorry about that. Cygwin's tzset is using the conversion list Windows timezone to POSIX timezone from http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html There is no "Belarus Standard Time". The only matching timezone in this list is "Kaliningrad Standard Time" with region "BY". However, it seems that the XML conversion list from the same site (http://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml) is in a much better (==newer) shape. [...time passes...] I updated tzset now and added a script to the Cygwin repo which allows easier updating this info once in a while. I created new developer snapshots on https://cygwin.com/snapshots/ Please give the new tzset from cygwin-inst-20141205.tar.xz for your architecture a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWcVRmpL3Hr.pgp Description: PGP signature
Re: src/winsup/utils ChangeLog Makefile.in tzset.c ...
On 5 December 2014 at 14:41, wrote: > * tzmap-from-unicode.org: New script to create tzmap.h. Here is an untested idea. Change line 62 of the script from echo "} tzmap[] =" to echo "} const tzmap[] =" -- VZ -- 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: src/winsup/utils ChangeLog Makefile.in tzset.c ...
On Dec 5 15:02, Václav Zeman wrote: > On 5 December 2014 at 14:41, wrote: > > * tzmap-from-unicode.org: New script to create tzmap.h. > > Here is an untested idea. Change line 62 of the script from > > echo "} tzmap[] =" > > to > > echo "} const tzmap[] =" Patch applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpt1j7JtMoRW.pgp Description: PGP signature
fork::abort starting emacs-X11
I get errors: 0 [main] emacs-X11 6552 child_info_fork::abort: C:\cygwin\bin\cyggnutls-28.dll: Loaded to different address: parent(0x171) != child(0x13) when I start emacs after a PC reboot. I also notice that none of my dired buffers are recalled. FWIW I have " (desktop-save-mode 1)" in my .emacs file. I shut Cygwin down and started emacs with -Q option, but when I tried to create a dired Buffer it gave the fork error again. Rebaseall procedure works to fix the fork issue - until the next reboot. cygcheck.out Description: cygcheck.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: Cipher Issue while Connecting from AIX
I recommend you also try -vv and -vvv, which provide increasing levels of debug output. With past SSH problems, it has helped me. From the man page of ssh: -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Mul‐ tiple -v options increase the verbosity. The maximum is 3. On Thu, Dec 4, 2014 at 10:15 PM, Yair Zaretski wrote: > Hi All, > > I have an AIX machine which is trying to connect to an SSH server I’ve setup > through Cygwin on a Win 2008 Server. > The connection is unsuccessful due to unmatched key exchange algorithms. > > As far as I can tell, both the AIX machine and the Cygwin SSH server have at > least a few SSH cipher algorithms in common. > However, even setting a specific cipher on the AIX side (via "ssh -c > cipher-type" command) does not work. > > Connection from any Linux server to the AIX and to the Cygwin SSH are > successful. > In addition, connecting from the Cygwin to the AIX is successful. > > I’d appreciate any help here. > Please see below the output of “ssh -v windows-server” command on the AIX > server: > > [aix-host] # ssh -v windows-server > OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6l 04 Nov 2003 > debug1: Reading configuration data /usr/local/etc/ssh_config > debug1: Connecting to windows-server [windows-server-ip] port 22. > debug1: Connection established. > debug1: identity file /home/user/.ssh/identity type -1 > debug1: identity file /home/user/.ssh/id_rsa type 1 > debug1: identity file /home/user/.ssh/id_dsa type 2 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7 > debug1: match: OpenSSH_6.7 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.8p1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-sha1 none > debug1: kex: client->server aes128-ctr hmac-sha1 none > no kex alg > [aix-host] # > > Thanks. > Yair Zaretski > > > -- > 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 > -- 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: fork::abort starting emacs-X11
On 12/5/2014 9:56 AM, Rockefeller, Harry wrote: I get errors: 0 [main] emacs-X11 6552 child_info_fork::abort: C:\cygwin\bin\cyggnutls-28.dll: Loaded to different address: parent(0x171) != child(0x13) when I start emacs after a PC reboot. I also notice that none of my dired buffers are recalled. FWIW I have " (desktop-save-mode 1)" in my .emacs file. I shut Cygwin down and started emacs with -Q option, but when I tried to create a dired Buffer it gave the fork error again. Rebaseall procedure works to fix the fork issue - until the next reboot. I have no idea what could cause fork problems to disappear after rebaseall and then reappear after a reboot. Maybe someone else can help. I did try to reproduce the problem and couldn't (on both 32-bit and 64-bit Cygwin). Here's what I tried: 1. Reboot. 2. Start the X server using the Start Menu shortcut provided by the latest xinit package, with no ~/.startxwinrc. 3. In the resulting xterm, 'emacs -Q&'. 4. 'C-x d' to list the home directory. 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: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
On Fri, Dec 5, 2014 at 6:35 AM, Corinna Vinschen wrote: > > ... > > This looks suspiciously like a bug in the remote filesystem. Link > succeeded, so there are two links to the same file in the directory. > Unlinking link 1 succeeds, so there's still one link to the file in the > directory, but link 2 is inaccessible as if the file has been deleted > completely. Thus, a full POSIX git on this drive is broken. > > Can you please run > > /usr/lib/csih/getVolInfo /cygdrive/z > > and paste the output here? Maybe I can workaround this in the next > Cygwin version. Here you go: $ /usr/lib/csih/getVolInfo /cygdrive/Z Device Type: 7 Characteristics: 10 Volume Name: <> Serial Number : 1646121781 Max Filenamelength : 255 Filesystemname : Flags : c700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Thanks for looking into this. FWIW, @Kai on StackExchange has been able to reproduce the problem. See last comment here: http://stackoverflow.com/questions/27156413/how-to-configure-cygwin-git-for-two-factor-authentication-at-github-com/27176547?noredirect=1#comment43088817_27176547 -- 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
"Bug" in setup-x86.exe command line
Hello, I use the latest version of the installer setup-x86.exe version 2.852 I think that the command line installer has some king of "bug". The following line doesn't download the bash package: setup-x86.exe --download --site http://mirrors.kernel.org/sourceware/cygwin --quiet-mode --no-shortcuts --local-package-dir c:\testdir --packages bash Instead the following line does it (csih package): setup-x86.exe --download --site http://mirrors.kernel.org/sourceware/cygwin --quiet-mode --no-shortcuts --local-package-dir c:\testdir --packages csih I don't understand what is happening. I attache the log files: they seem ok, but in fact the bash package is never downloaded. Thanks a lot for your time. setup.log Description: Binary data setup.log.full Description: Binary data setup_csih.log Description: Binary data setup_csih.log.full 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: advice about setting up the eigen library for use with cygwin g++
Csaba Raduly wrote:
> Hi,
>
> On Thu, Dec 4, 2014 at 10:43 PM, LMH wrote:
>> Hello,
>>
>> As stated, I am writing a few tools with cygwin g++.
> (snip)
>> Eigen is a header only kind of thing, so my understanding is that all I
>> need to do is to unpack the src somewhere add the location to the
>> include path.
>>
>> I was thinking of putting Eigen in,
>>
>> /cygdrive/c/cygwin/lib/eigen/
>
> If you use Cygwin tools, you shouldn't use paths like
> "/cygdrive/c/cygwin/lib". The way to refer to
> that directory is /lib (unless your Cygwin is installed somewhere
> other than C:\cygwin).
>
>>
>> and using,
>>
>> g++ -I /cygdrive/c/cygwin/lib/eigen/
>>
>
> /lib is not really for headers. It mostly contains binaries. A
> canonical place for a header-only library would be
> /usr/local/include/eigen
>
> Doesn't eigen supply a makefile with an "install" target?
>
> Csaba
>
Hello Csaba,
Thanks for the information. I will take your advice and unpack Eigen in
/usr/local/include/eigen instead of in /lib and drop the /cygdrive/c/
from the include path.
As I mentioned in an earlier post, Eigen is not a compiled library,
meaning there is no binary file. As I understand it, you are just
supposed to use the src code and header files as is, like you would use
any other .cpp and .h files in your build. The main difference is that
the files are not located in your trunk src directory.
Yaakov Selkowitz mentioned that Eigen is available through ports. I have
never used ports, so I'm not sure what the difference is. Is there a
difference in the way the Eigen code gets linked to my app if I install
Eigen through ports?
According to the Eigen page, Eigen isn't installed in the formal sense,
like you would install boost through the cygwin package manager. You
just put the Eigen folder somewhere and add the top level to the include
path. When you write your src, you add includes for the header files you
want and compile/link as normal.
"If you just want to use Eigen, you can use the header files right away.
There is no binary library to link to, and no configured header file.
Eigen is a pure template library defined in the headers."
This is a sample program from the getting started page,
## my_program.cpp ##
#include
#include
using Eigen::MatrixXd;
int main() {
MatrixXd m(2,2);
m(0,0) = 3;
m(1,0) = 2.5;
m(0,1) = -1;
m(1,1) = m(1,0) + m(0,1);
std::cout << m << std::endl;
}
g++ -I /path/to/eigen/ my_program.cpp -o my_program
According to the same page, if you have the Eigen folder, or a symlink
to the Eigen folder, in /usr/local/include/, you don't need to use -I.
So I guess I still need to figure out if this is going to work as I
understand it and if there is some advantage to installing Eigen through
ports instead of just unpacking it.
LMH
--
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
Unexpected messages from sshd with 2014-12-05 snapshot
I have two local accounts. When I ssh from one to the other (i.e., ssh user2@localhost while logged in as user1), I get many messages like the following: 0 [main] sshd 3420 build_env: remove: ALLUSERSPROFILE=C:\ProgramData 1411 [main] sshd 3420 build_env: remove: COMPUTERNAME=XXX 1475 [main] sshd 3420 build_env: remove: ComSpec=C:\windows\system32\cmd.exe 1524 [main] sshd 3420 build_env: remove: OS=Windows_NT [...] This is with today's snapshot. I haven't checked earlier snapshots yet, but I could do that if it would help. 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
[ANNOUNCEMENT] Updated: tzcode-2014j-1: Time Zone Database
Hi A new version of 'tzcode' has been uploaded to a server near you. o Update to latest upstream release o Build for cygwin 1.7.33 with gcc-4.8.3 tzcode NEWS: * Sorry no changelog available. You have to do the diff yourself. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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" in setup-x86.exe command line
On 12/5/2014 12:47 PM, Kizito Porta Balanyà wrote: Hello, I use the latest version of the installer setup-x86.exe version 2.852 I think that the command line installer has some king of "bug". The following line doesn't download the bash package: setup-x86.exe --download --site http://mirrors.kernel.org/sourceware/cygwin --quiet-mode --no-shortcuts --local-package-dir c:\testdir --packages bash Instead the following line does it (csih package): setup-x86.exe --download --site http://mirrors.kernel.org/sourceware/cygwin --quiet-mode --no-shortcuts --local-package-dir c:\testdir --packages csih I don't understand what is happening. I attache the log files: they seem ok, but in fact the bash package is never downloaded. You may be misunderstanding what the --download option is supposed to do. I think it's supposed to cause setup to behave as though you had checked the "Download Without Installing" option in an interactive session. So it should download whatever packages have been selected for installation. In your first run, the only package selected was bash, which was already installed, so setup had nothing to do. In the second run, I assume that you didn't already have csih installed, so setup downloaded it for later install. 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: Odd behavior with some Unicode characters
On 12/5/2014 2:54 PM, Benjamin Ryzman wrote: Dear Ken, I am just starting using your Emacs package on Cygwin and I find an odd behavior for some of the Unicode characters and the default fontset. Please find attached the screen shot which shows a striking difference between your build and the one from Chris Zheng (http://emacsbinw64.sourceforge.net/). Both are 64bit builds targeting Windows. Unfortunately your build is unable to display some of the Unicode chars by default. It seems the default fontset is missing some character specific definition, or your build is unable to detect fonts which implement the -*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1 emacs font spec. Is there a way to add the missing parts? Please send questions about Cygwin packages to the Cygwin mailing list, not directly to maintainers. I'm copying you on this reply in case you're not yet reading the list. What you're reporting seems to be the same issue as this: https://cygwin.com/ml/cygwin/2014-09/msg00052.html I'm afraid that I don't know any more about it now than I did in my last reply in that thread: https://cygwin.com/ml/cygwin/2014-09/msg00194.html It would be great if someone could fix this, but I don't have the expertise to do it. 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: Cygwin AD integration home/shell changes
Greetings, Corinna Vinschen! >> >> >> > Here's what you get: >> >> >> >> >> >> I finally realized, what was tingling me all this time. >> >> >> The implicit fallback mechanics. I'd rather want to have explicit >> >> >> declaration >> >> >> and a failure message in case something isn't right. Much easier to >> >> >> fix system >> >> >> issues, when the system tell you about them. >> >> >> >> > The fallback mechanism is pretty much required to have a sane default >> >> > which works for home users without having to change nsswitch.conf at >> >> > all. Also, not everybody will want error messages rather than some sane >> >> > fallback (for any given value of "sane"), while if you don't want a sane >> >> > fallback, you can easily create an unsane fallback to help you maintain >> >> > your solution, e.g. >> >> >> >> > db_home: cygwin /invalid/read-only-path >> >> >> >> Why not set defaults (in case of db_home) to >> >> >> >> db_home: cygwin desc /home/%U >> >> >> >> and remove fallback? >> >> It just not seems right - creating workarounds to implement straight >> >> behavior. >> >> > It's not a workaround from my POV to provide a fallback. Creating a >> > workable passwd entry is important. If I implement it as you suggest >> > above, I would still provide the typical "set home to the root dir" >> > default. Sure, that might be an option. >> >> If you mean "complain and set home to the root", then I'm happy with this >> solution. > No complain. You still seem to have a problem to understand that this > is underlying functionality under a couple of system calls generating > passwd entries for arbitrary accounts. > It's *not* necessarily the current account. A user visible complaint for > every unconfigured account enumerated via getpwent is quite over the top. No, I perfectly understand it. The sooner I get slapped in the face with a printout of my incorrect and intolerable settings, the better. I do understand, that the settings MUST provide at least one sensible result. Assuming we get sensible defaults, this will not be an issue for majority of people. However, for those, who wish to alter the setting, it is better, if they get a slap this instant, if the setting is not quite right, rather than if they discover issue after a long time is passed. Issues with core configuration should not be masked by obscure defaults. IMHO. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, <21:41> 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: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! >> > I'd appreciate if those not shy to install developer snapshots would >> > give this stuff a try in the meantime. >> >> I think I'm about to make a script to install snapshots, at this rate it >> seems >> the right thing to do. >> Is there a direct way to query for the latest snapshot? > The snapshots always have a date attached to the filename. I mean, if there's a way to know, what is the latest available snapshot? If I want to write a script, that fetch [and install] one. I can parse the /snapshots/ page, of course, but this is the least desirable choice. For multiple reasons. I would like to have a single point, that could refer to the very latest snapshot. Even if it is something like /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to actual latest snapshot, that'd be quite enough. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, <23:12> 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: tzset error
Corinna Vinschen cygwin.com> writes: > On Dec 5 14:32, rl76 inbox.ru wrote: >> I run Cygwin Terminal and the first line I see the error: >> tzset: can not find matching POSIX timezone for Windows timezone "Belarus >> Standard Time" >> Installed all the latest updates. >> Windows 7. Windows Time Zone: (UTC+03:00) Minsk. > There is no "Belarus Standard Time". The only matching timezone in > this list is "Kaliningrad Standard Time" with region "BY". Belarus Standard Time was dropped in Dec 2011 Win DST update and replaced by Kaliningrad Standard time “(UTC+03:00) Kaliningrad, Minsk”, reverted in Aug 2014 Russian time zone updates, which restored Belarus +3:00 Minsk and readded Kaliningrad +2:00 (RTZ 1). Check your local Windows TZ selector dropdown or the registry. The changes already appeared in tz 2014f August release. -- 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
