Failure building standalone
![](https://secure.gravatar.com/avatar/018bd5c575dea7380cf18968f26e5b07.jpg?s=120&d=mm&r=g)
I tried building the standalone but ran into a snag. Here is the error message display when I ran "first-setup.sh": ---------------- sh ./first-setup.sh --modules=all --engine=luatex --context=current receiving incremental file list rsync: change_dir "/setup/cygwin" (in minimals) failed: No such file or directory (2) sent 4 bytes received 8 bytes 3.43 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1508) [Receiver=3.0.7] mtxrun | unknown script './bin/mtx-update.lua' ---------------- I take this to mean it can't change to Context's /setup/bin The ... setup/cygwin directories are in my local build directory is in /usr/local/context and not located off of root / Is this because the cygwin build is out-of-date or not supported anymore? Regards
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Thu, Jun 20, 2013 at 3:18 PM,
I tried building the standalone but ran into a snag.
Here is the error message display when I ran "first-setup.sh": ----------------
sh ./first-setup.sh --modules=all --engine=luatex --context=current receiving incremental file list rsync: change_dir "/setup/cygwin" (in minimals) failed: No such file or directory (2)
sent 4 bytes received 8 bytes 3.43 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1508) [Receiver=3.0.7]
mtxrun | unknown script './bin/mtx-update.lua'
----------------
I take this to mean it can't change to Context's /setup/bin
It can change to http://minimals.contextgarden.net/setup/cygwin (or rather: it's rsync equivalent). Someone started providing the binaries, but later gave up. However, recent posts seem to suggest that normal windows binaries should work as well.
The ... setup/cygwin directories are in my local build directory is in /usr/local/context and not located off of root /
Is this because the cygwin build is out-of-date or not supported anymore?
It's kind of not-supported because nobody was willing to inspect how to build the binaries, but a few days ago I got reports that it should work. Can you please try to fetch first-setup.sh once more and try again? Mojca
![](https://secure.gravatar.com/avatar/018bd5c575dea7380cf18968f26e5b07.jpg?s=120&d=mm&r=g)
Thanks Mojca. Re-running the command today got me a little further. Thank you.
The problem encounted now is:
--------------------------------
sh ./first-setup.sh --modules=all --engine=luatex --context=current
receiving incremental file list
sent 64 bytes received 322 bytes 85.78 bytes/sec
total size is 10993585 speedup is 28480.79
env: mtxrun: Permission denied
--------------------------------
I explicity set the permissions to allow me execute access, but script fails toward the end.
But, it looks lke the sh script itself is chaning the perameters. Or else my setup is intentionally tricking me.
Mojca Miklavec
On Thu, Jun 20, 2013 at 3:18 PM,
wrote: I tried building the standalone but ran into a snag.
Here is the error message display when I ran "first-setup.sh": ----------------
sh ./first-setup.sh --modules=all --engine=luatex --context=current receiving incremental file list rsync: change_dir "/setup/cygwin" (in minimals) failed: No such file or directory (2)
sent 4 bytes received 8 bytes 3.43 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1508) [Receiver=3.0.7]
mtxrun | unknown script './bin/mtx-update.lua'
----------------
I take this to mean it can't change to Context's /setup/bin
It can change to http://minimals.contextgarden.net/setup/cygwin (or rather: it's rsync equivalent).
Someone started providing the binaries, but later gave up.
However, recent posts seem to suggest that normal windows binaries should work as well.
The ... setup/cygwin directories are in my local build directory is in /usr/local/context and not located off of root /
Is this because the cygwin build is out-of-date or not supported anymore?
It's kind of not-supported because nobody was willing to inspect how to build the binaries, but a few days ago I got reports that it should work.
Can you please try to fetch first-setup.sh once more and try again?
Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Thu, Jun 20, 2013 at 6:39 PM,
Thanks Mojca. Re-running the command today got me a little further. Thank you.
The problem encounted now is:
-------------------------------- sh ./first-setup.sh --modules=all --engine=luatex --context=current receiving incremental file list
sent 64 bytes received 322 bytes 85.78 bytes/sec total size is 10993585 speedup is 28480.79 env: mtxrun: Permission denied
--------------------------------
I explicity set the permissions to allow me execute access, but script fails toward the end. But, it looks lke the sh script itself is chaning the perameters. Or else my setup is intentionally tricking me.
Unless you comment out the part of first-setup.sh which syncs ./bin/mtxrun.exe, the file is going to be overwritten each time and the file on server wasn't executable (because it usually doesn't make any difference for windows users anyway). I fixed the executable bits on server. Please try again. (But please note that when we user rsync as provided by rsync in past, binaries were broken even if the executable bit was set on the server. We had to use "set cygwin nontsec" or something like this to overcome the problem, or run chmod after each sync. I hope that you won't be bitten by this, but we were.) Mojca
![](https://secure.gravatar.com/avatar/2108b4611c915035ac4d553468360111.jpg?s=120&d=mm&r=g)
Hi All, Mojca,
please excuse my ignorance of the inner workings of windows, but
would it not be possible to have the permissions corrected by the first-setup.sh
script after the rsync?
regards
Keith.
Am 21.06.2013 um 07:56 schrieb Mojca Miklavec
On Thu, Jun 20, 2013 at 6:39 PM,
wrote: Thanks Mojca. Re-running the command today got me a little further. Thank you.
The problem encounted now is:
-------------------------------- sh ./first-setup.sh --modules=all --engine=luatex --context=current receiving incremental file list
sent 64 bytes received 322 bytes 85.78 bytes/sec total size is 10993585 speedup is 28480.79 env: mtxrun: Permission denied
--------------------------------
I explicity set the permissions to allow me execute access, but script fails toward the end. But, it looks lke the sh script itself is chaning the perameters. Or else my setup is intentionally tricking me.
Unless you comment out the part of first-setup.sh which syncs ./bin/mtxrun.exe, the file is going to be overwritten each time and the file on server wasn't executable (because it usually doesn't make any difference for windows users anyway).
I fixed the executable bits on server. Please try again.
(But please note that when we user rsync as provided by rsync in past, binaries were broken even if the executable bit was set on the server. We had to use "set cygwin nontsec" or something like this to overcome the problem, or run chmod after each sync. I hope that you won't be bitten by this, but we were.)
Mojca
![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On Fri, Jun 21, 2013 at 9:54 AM, Keith J. Schultz wrote:
Hi All, Mojca,
please excuse my ignorance of the inner workings of windows, but would it not be possible to have the permissions corrected by the first-setup.sh script after the rsync?
(I'm not sure to which part you were replying.) Sure it could, but it's way better if the original file on the server already has the right permissions, else rsync will keep reverting the change, over and over again. (We are talking about using cygwin directly now.) The problems that we had on native windows (using cygwin's rsync only) was that even with proper permissions on the server, cygwin did something very bad/weird with permissions on the client's side, so the resulting binaries were completely useless. Of course, running chmod helped, but that's a weird cure because it has to be repeated after each sync. Each sync "fixes" (= destroys) permissions again. Using the weird nontsec setting solved the problem, even though I still believe that that could be considered a bug in rsync or its port to Windows. Mojca
![](https://secure.gravatar.com/avatar/2108b4611c915035ac4d553468360111.jpg?s=120&d=mm&r=g)
Hi Mojca,
I agree with you fully. It was just a thought.
The problem is most likely a bug in the port.
I had figured that first-setup.sh should be run anyway
using chmod should do the trick. In other words for cygwin
first-setup.sh cleans up what has gone wrong during transfer.
regards
Keith.
Am 21.06.2013 um 11:16 schrieb Mojca Miklavec
On Fri, Jun 21, 2013 at 9:54 AM, Keith J. Schultz wrote:
Hi All, Mojca,
please excuse my ignorance of the inner workings of windows, but would it not be possible to have the permissions corrected by the first-setup.sh script after the rsync?
(I'm not sure to which part you were replying.)
Sure it could, but it's way better if the original file on the server already has the right permissions, else rsync will keep reverting the change, over and over again. (We are talking about using cygwin directly now.)
The problems that we had on native windows (using cygwin's rsync only) was that even with proper permissions on the server, cygwin did something very bad/weird with permissions on the client's side, so the resulting binaries were completely useless. Of course, running chmod helped, but that's a weird cure because it has to be repeated after each sync. Each sync "fixes" (= destroys) permissions again. Using the weird nontsec setting solved the problem, even though I still believe that that could be considered a bug in rsync or its port to Windows.
participants (3)
-
hwitloc@gmail.com
-
Keith J. Schultz
-
Mojca Miklavec