Re: xpdf relocation error
Dear Mark: However, after simple "rebase -i cygXt-6.dll" xpdf still cannot start. What one had to do for my system is rebase -b 0xf730 cygXt-6.dll This rebasement does not seem to survive updates or reinstalls. I know that rebasement is difficult, but still, could you, perhaps, solve it in a more long-term way? Thanks in advance, Jaakov -- 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: The font "TeX Gyre Termes" cannot be found.
On 5/13/2016 9:26 PM, Jaakov Jaakov wrote:
(/usr/share/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
Invalid fontname `TeX Gyre Termes', contains ' '
!
! fontspec error: "font-not-found"
! ! The font "TeX Gyre Termes" cannot be found.
! ! See the fontspec documentation for further information.
! ! For immediate help type H .
!...
l.9
\setromanfont[Ligatures=TeX]{TeX Gyre Termes}
?
]
executing fc-cache -f won't help. Any way to repair the system?
Did you run /usr/bin/texlive-enable-fontconfig? (See the release
announcement for TeX Live 2015 or /usr/share/doc/texlive/README.Cygwin.)
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: Possible issue with newest version of git (v 2.8) under Cygwin
On Tue, May 10, 2016 at 09:59:50AM -0400, andrew stern wrote: > >I'm not sure I understand what you're seeing: if your repository is > >already set up with core.filemode set to false, Git won't check the > >executable flag on the files. What leads you to think the speed > >slow-down is related to checking whether the file is executable? > > >If setting cygexec makes a noticable speed difference even with > >core.filemode false, I can only conclude the problem is somewhere > >below Git and related to how the Cygwin DLL provides file access. > > >FWIW, having just checked the Cygwin user guide's fstab > >instructions[0], the noacl setting should be ignored on NFS > >filesystems; if you're seeing that make a difference, that looks like > >a bug. > > I tried a clone and pull both with the noacl and without the noacl. In > my experiment without the noacl it was much faster when doing pulls > after someone else checked in changes. I located on the web a > reference to noacl being slow when doing a stat under cygwin and > figured if I prevent reading each file it might be faster so I went to > my noacl directory and did a pull of their changes after adding the > cygexec flag after the noacl flag. Instead of being tens of minutes > it was just a bit over a minute and a half. To be absolutely clear: if you mount an NFS share with noacl set, you get a noticable speed increase versus not setting noacl? > Although the repository > is on a NFS drive the local file system is NTFS and I see it spending > lots of time doing the update on the merge even though it is just a > couple of files that have changed. I'm still trying to figure out > what exactly is going on and how best to deal with the permissioning > issue that we are now experiencing. After discussions we would rather > have it slow then have bad permission problems but I'd rather not have > either issue. Am I correct in understanding you have multiple users trying to access the same shared Git working repository? I'm aware it's a workaround rather than an actual solution, but I'd expect you'd have better luck with each having a separate working copy on your local machine rather than sharing a common working copy. > If I leave off the noacl and do a clone followed by a push and pull we > end up with the following error in the Windows security tab: > The permissions on file.cpp are incorrectly ordered, which may cause > some entries to be ineffective. Yes, I've seen that before; it's a problem with the underlying cygwind1.dll rather than a problem with Git. I believe the consensus from people on this list who know more about Windows permissions than me is that the warning is actually benign and can be ignored. -- 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: Possible issue with newest version of git (v 2.8) under Cygwin
On 5/14/2016 8:03 AM, Adam Dinwoodie wrote: If I leave off the noacl and do a clone followed by a push and pull we >end up with the following error in the Windows security tab: > The permissions on file.cpp are incorrectly ordered, which may cause >some entries to be ineffective. Yes, I've seen that before; it's a problem with the underlying cygwind1.dll rather than a problem with Git. I believe the consensus from people on this list who know more about Windows permissions than me is that the warning is actually benign and can be ignored. As I read the Cygwin documentation, the problem is that windows permissions and POSIX permissions don't line up very well. In order to faithfully reproduce POSIX permissions, Cygwin uses legal but non-standard ordering of ACEs. Windows' security tab thinks this is a problem, but it really isn't. To quote from the documentation here: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files: Unfortunately the security tab in the file properties dialog of the Windows Explorer insists to rearrange the order of the ACEs to canonical order before you can read them. Thank God, the sort order remains unchanged if one presses the Cancel button. But don't even *think* of pressing OK... So it would seem the problem as such lies with Windows' security tab. -- 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: xpdf relocation error
On 5/14/2016 6:56 AM, Jaakov Jaakov wrote: This rebasement does not seem to survive updates or reinstalls. I know that rebasement is difficult, but still, could you, perhaps, solve it in a more long-term way? As was pointed out in the first post on this subject (https://www.cygwin.com/ml/cygwin/2016-04/msg00365.html), simply rebuilding from source with the current gcc seems to fix the problem. I've also verified this. I assume the xpdf maintainer, Volker Zell, will rebuild it when he has a chance. In the meantime, are you able to build it yourself? If not, I can provide a binary for you. 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
