from:"Brian Hunt"

Re: [NTG-context] Old version of luatex for alpine linux (musl)

2018-10-23 Thread Brian Hunt

> I need to find a way to trigger a build manually from time to time

This sort of automation is fairly straightforward with a Docker image on
Linux.  If you let me know the build tools & commands I can get it started
and share it for evaluation & discussion.

On Tue, 23 Oct 2018 at 09:25 Mojca Miklavec 
wrote:

> Hi,
>
> On Tue, 23 Oct 2018 at 13:37, Martin Hasoň wrote:
> >
> > Hi all,
> >
> > I want to use the last beta version of standalone ConTeXt distribution
> in alpine linux (musl). The installation was OK, but an error occurred
> while compiling the file:
>
> Eeeem, my fault, sorry. I did not update LuaTeX for musl as it comes
> from another source (at the moment we can build it on Travis, but I
> never did that so far myself).
>
> I wanted to somehow automate this. Norbert has set up an automatic
> mirror on GitHub and also set up a Travis job, but we would need a
> mechanism to push the resulting binary somewhere. Or at least I need
> to find a way to trigger a build manually from time to time. At the
> moment one needs to create a tag which is a bit strange, but ...
> (I wanted to take time and set up my own account on Travis etc., just
> never came around to do so.)
>
> If Henri has some suggestion about the most efficient way to achieve
> this ... (for the moment it would be ok if I only get the latest
> binary from trunk/master).
>
> 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://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
>
> ___

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Build for Alpine Linux

2018-04-13 Thread Brian Hunt

For those interested in reproducing the issues experienced on Alpine, I've
published an image that you should be able to start with:

$ docker run -ti brianmhunt/context-alpine:demo

(You can see the Dockerfile etc here:
https://hub.docker.com/r/brianmhunt/context-alpine/)

That image applies the TODO/workarounds previously posted (sometimes
inelegantly) and brings it to the point where I got stuck, namely luatools
and context erroring with "unknown script base.lua" and "unknown script
context.lua", respectively.


On Wed, 11 Apr 2018 at 19:14 Henri Menke <henrime...@gmail.com> wrote:

> On Wed, 2018-04-11 at 20:08 +, Brian Hunt wrote:
> > So here's what I've got for a TODO so far to get ConTeXt working on
> Alpine
> > Linux with musl (subject to item #6, mtx-context.lua not being found):
> >
> > 1. Add the musl test to first-setup.sh
> > 2. Add the same musl test to tex/setuptex
> > 3. Add texlua (and texluac?) to
> >   a. the setup rsync bin/ directories
> >   b. the tex/texmf-linuxmusl(|-ppc|-64)
> > 4. Update mtxrun
> >
> > Here's code that ought to work for detecting musl in mtxrun.  Around
> line 3721
> > of the mtxrun add:
> >
> > if find(architecture,"x86_64",1,true) then
> >   platform="linux-64"
> > elseif find(architecture,"ppc",1,true) then
> >   platform="linux-ppc"
> > else
> >   platform="linux"
> > end
> > +   if resultof("ldd --version 2>&1"):find("musl") ~= nil then
> > + platform = platform:gsub("linux", "linuxmusl")
> > +   end
> >
> > 5. Note that in tex/setuptex, there's evidently no way to get the current
> > script so one has to explicitly provide the TeX directory (appears to be
> a
> > BusyBox bug).
>
> Standard POSIX sh has no way to reliably detect sourced invocation of a
> script.
> BusyBox uses POSIX sh underneath and thus suffers from the same
> limitation. See
> StackOverflow for detail:
> https://stackoverflow.com/questions/29832037
>
> > 6. `context` is unable to locate `mtx-context.lua`.  Some tracker output
> sheds
> > some light:
> >   i. context --trackers=resolvers.expansions is identical
> >   ii. context --trackers=resolvers.details,resolvers.details differs,
> with the
> > output attached.  Note that to keep the comparison short I removed lines
> that
> > differed only because `linux` had been changed to `linuxmusl`.
> >
> > Will keep plugging away to see if I can determine why `mtx-context.lua`
> cannot
> > be found on Alpine Linux.
> >
> > Thanks for reading.
> >
> > Brian
> >
> > --
> > from the personal account of:
> > Brian M Hunt <brianmh...@gmail.com>
> > Direct: +1-289-684-4677 <(289)%20684-4677>
> > LinkedIn: https://linkedin.com/in/brianmhunt
> > This e-mail may contain information that is private, privileged,
> confidential
> > and/or exempt from disclosure. Except as per this notice no waiver of
> any kind
> > is intended by sending this e-mail, and this email is intended only for
> the
> > named recipient(s) or the subscribers of a forwarding service the email
> is
> > sent directly to and to which service you are an authorized recipient.
> Use,
> > dissemination or copying without authorization is prohibited. Please
> notify
> > the sender and destroy all copies of this e-mail if you have received
> this
> > email in error.
> >
> __
> > _
> > 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://context.aanhet.net
> > archive  : https://bitbucket.org/phg/context-mirror/commits/
> > wiki : http://contextgarden.net
> >
> __
> > _
>
> ___
> 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://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
>
> ___

-- 

*from th

Re: [NTG-context] Build for Alpine Linux

2018-04-11 Thread Brian Hunt

Aditya: I did indeed; it fails with `mtxrun  | unknown script
'base.lua' or 'mtx-base.lua'` (sorry I didn't report this).

Hans:

> if musl needs different bin then there should be a different initial
> download i think because basically we're now talking of: windows, osx,
> linux, linuxmusl (a different species)

This appears to be the case currently, as first-setup.sh calls rsync to
copy files from:
http://standalone.contextgarden.net/setup/linuxmusl-64/bin/ for linux (musl)
http://standalone.contextgarden.net/setup/linux-64/bin/ for linux (glibc)

texlua just seems to be missing from the linuxmusl-64 path; it's in the
linux-64 path. I suspect it's a build issue.

> isn't there some magic env var that tels if musl is used? do programs
> and scripts really have to jumpo through such loops

It seems there is no better way to do detection. This post seems to
summarize what I'd read elsewhere:
https://unix.stackexchange.com/questions/120380

Could one symlink `texmf-linux-64` to point to `texmf-linuxmusl-64` via
first-setup.sh?  Then mtxrun wouldn't have to do any detection.

> hm, so musl is far from a drop=in for glib or do i get it wrong

There certainly do seem to be a lot of hoops.

That said, notwithstanding the weird path issues, of the six TODO items I
mentioned, 1 & 2, and 4 require musl detection, 3 is related to the rsync
setup, 5 is a shell problem (not musl per-se).

I've no idea what's going on with the paths / problem 6 though.  It could
be musl/luatex or maybe Alpine.  My most recent insight was that the
`instance.files` are essentially empty with Alpine/musl (and so is the
cache), so they're not being read for some reason.  I've not yet isolated
where that reading happens.

Brian

On Wed, 11 Apr 2018 at 16:37 Hans Hagen <j.ha...@xs4all.nl> wrote:

> On 4/11/2018 10:08 PM, Brian Hunt wrote:
> > So here's what I've got for a TODO so far to get ConTeXt working on
> > Alpine Linux with musl (subject to item #6, mtx-context.lua not being
> > found):
> >
> > 1. Add the musl test to first-setup.sh
> > 2. Add the same musl test to tex/setuptex
>
> no problem adding a robust test there
>
> > 3. Add texlua (and texluac?) to
> >a. the setup rsync bin/ directories
> >b. the tex/texmf-linuxmusl(|-ppc|-64)
>
> we don't use texluac, don't need texlua on windows and on linux texlua
> is just a symlink
>
> if musl needs different bin then there should be a different initial
> download i think because basically we're now talking of: windows, osx,
> linux, linuxmusl (a different species)
>
> > 4. Update mtxrun
> >
> > Here's code that ought to work for detecting musl in mtxrun.  Around
> > line 3721 of the mtxrun add:
> >
> >  if find(architecture,"x86_64",1,true) then
> >platform="linux-64"
> >  elseif find(architecture,"ppc",1,true) then
> >platform="linux-ppc"
> >  else
> >platform="linux"
> >  end
> > +   if resultof("ldd --version 2>&1"):find("musl") ~= nil then
> > + platform = platform:gsub("linux", "linuxmusl")
> > +   end
>
> that's not going to happen, some system call 9each run) in order to
> determine what linux species we run ... (there are a few calls but these
> are never used becasue we use HOSTTYPE (if needed we can set one
> ourselves on these platforms)
>
> isn't there some magic env var that tels if musl is used? do programs
> and scripts really have to jumpo through such loops
>
> > 5. Note that in tex/setuptex, there's evidently no way to get the
> > current script so one has to explicitly provide the TeX directory
> > (appears to be a BusyBox bug).
> > 6. `context` is unable to locate `mtx-context.lua`.  Some tracker output
> > sheds some light:
> >i. context --trackers=resolvers.expansions is identical
> >ii. context --trackers=resolvers.details,resolvers.details differs,
> > with the output attached.  Note that to keep the comparison short I
> > removed lines that differed only because `linux` had been changed to
> > `linuxmusl`.
> >
> > Will keep plugging away to see if I can determine why `mtx-context.lua`
> > cannot be found on Alpine Linux.
> hm, so musl is far from a drop=in for glib or do i get it wrong
>
> Hans
>
> -
>Hans Hagen | PRAGMA ADE
>Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
> tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
> -
>
-- 

*from the personal acco

Re: [NTG-context] Build for Alpine Linux

2018-04-11 Thread Brian Hunt

So here's what I've got for a TODO so far to get ConTeXt working on Alpine
Linux with musl (subject to item #6, mtx-context.lua not being found):

1. Add the musl test to first-setup.sh
2. Add the same musl test to tex/setuptex
3. Add texlua (and texluac?) to
  a. the setup rsync bin/ directories
  b. the tex/texmf-linuxmusl(|-ppc|-64)
4. Update mtxrun

Here's code that ought to work for detecting musl in mtxrun.  Around line
3721 of the mtxrun add:

if find(architecture,"x86_64",1,true) then
  platform="linux-64"
elseif find(architecture,"ppc",1,true) then
  platform="linux-ppc"
else
  platform="linux"
end
+   if resultof("ldd --version 2>&1"):find("musl") ~= nil then
+ platform = platform:gsub("linux", "linuxmusl")
+   end

5. Note that in tex/setuptex, there's evidently no way to get the current
script so one has to explicitly provide the TeX directory (appears to be a
BusyBox bug).
6. `context` is unable to locate `mtx-context.lua`.  Some tracker output
sheds some light:
  i. context --trackers=resolvers.expansions is identical
  ii. context --trackers=resolvers.details,resolvers.details differs, with
the output attached.  Note that to keep the comparison short I removed
lines that differed only because `linux` had been changed to `linuxmusl`.

Will keep plugging away to see if I can determine why `mtx-context.lua`
cannot be found on Alpine Linux.

Thanks for reading.

Brian

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
WORKING (Debian 8)
 # context --trackers=resolvers.details
resolvers   | resolving | file 'mtx-context.lua' is not readable
resolvers   | resolving | checking name 'mtx-context.lua'
resolvers   | resolving | deep checking 'selfautoparent:texmf-project', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-fonts', base 
'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-local', base 
'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-modules', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-context', 
base 'mtx-context.lua', pattern 'false'
resolvers   | methods | resolving, method 'concatinators', how 'tag', tag 
'file'
resolvers   | resolving | match: variant 'file', search 
'selfautoparent:texmf-context/scripts/context/lua/mtx-context.lua', result 
'selfautoparent:texmf-context/scripts/context/lua/mtx-context.lua'
resolvers   | resolving | deep checking 'selfautoparent:texmf-linux-64', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf', base 
'mtx-context.lua', pattern 'false'
resolvers   | resolving | checking filename 'mtx-context.lua' in tree
resolvers   | resolving | using pattern '^%./$' for path '.'
resolvers   | resolving | no match to '^%./$' in hash for file 
'selfautoparent:texmf-context/scripts/context/lua/mtx-context.lua' and path 
'selfautoparent:texmf-context/scripts/context/lua/'
resolvers   | resolving | quick root scan for '.'
resolvers   | resolving | file './mtx-context.lua' is not readable
resolvers   | resolving | using pattern '^home:texmf/tex/context/.*$' for 
path 'home:texmf/tex/context//'
…

NON-WORKING (Alpine 3.7)
 # context --trackers=resolvers.details
resolvers   | resolving | file 'mtx-context.lua' is not readable
resolvers   | resolving | checking name 'mtx-context.lua'
resolvers   | resolving | deep checking 'selfautoparent:texmf-project', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-fonts', base 
'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-local', base 
'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-modules', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf-context', 
base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 
'selfautoparent:texmf-linuxmusl-64', base 'mtx-context.lua', pattern 'false'
resolvers   | resolving | deep checking 'selfautoparent:texmf', base 
'mtx-context.lua', pattern

Re: [NTG-context] Build for Alpine Linux

2018-04-11 Thread Brian Hunt

> That’s what I was saying.  But you seemed to imply that grep -F 'musl'
> was preferable to grep -E '^musl' from a portability and robustness
> point of view.

Sorry if I was unclear; `grep -F` is preferable to `fgrep` since the latter
is less portable, and `grep -F` may be preferable to `-E` because it avoids
the undesirable zsh expansion.

> > The -q is superfluous with the >/dev/null, and should be removed;
> > incidentally though, is it not harmless in this case?
>  It is not.  In Thomas’ case, using grep >/dev/null would have avoided
> a 0 exit status and thus prevented his system from being erroneously
> detected as supporting musl.

I may have misunderstood Thomas' case, where zsh expands ^musl to all
filenames not containing `musl`. For convenience, here's the sample we were
discussing, which would be a different case:

if command -v ldd >/dev/null && ldd --version 2>&1 | grep -Fq 'musl' >
/dev/null

In this case there ought to be no expansion because there is no carat and
we use `grep -F`.

Generally speaking `grep -q` can have undesirable side-effects, but I
cannot see how such would occur in this case since all the input to grep is
from the pipe, which barring a radically improbable interrupt should never
error.  I would be interested to know if I have misunderstood, though.

On Tue, 10 Apr 2018 at 16:56 Arthur Reutenauer <
arthur.reutena...@normalesup.org> wrote:

> On Tue, Apr 10, 2018 at 11:05:12AM +, Brian Hunt wrote:
> >>  The caret in itself was not the problem, only that it was not escaped
> >> for the shell.  Testing a regexp, with -E of course, is just as robust,
> >> and allows us to be more specific about what we test.
> >
> > Either is fine I am sure
>
>   That’s what I was saying.  But you seemed to imply that grep -F 'musl'
> was preferable to grep -E '^musl' from a portability and robustness
> point of view.
>
> >>  grep -E '^musl' works just as well; and as I explained, -q may return 0
> >> even if there are errors, so should be avoided.
> >
> > The -q is superfluous with the >/dev/null, and should be removed;
> > incidentally though, is it not harmless in this case?
>
>   It is not.  In Thomas’ case, using grep >/dev/null would have avoided
> a 0 exit status and thus prevented his system from being erroneously
> detected as supporting musl.
>
> Best,
>
> Arthur
>
> ___
> 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://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
>
> ___

-- 

*from the personal account of:*

*Brian M Hunt *<brianmh...@gmail.com>
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Build for Alpine Linux

2018-04-10 Thread Brian Hunt

A few more notes:

1. Missing texlua - found
The missing `texlua` from `bin/` and `tex/texmf-linuxmusl-64/bin` appears
to be a problem originating at the rsync source, notably it appears that
`texlua` is missing from these paths:

http://standalone.contextgarden.net/setup/linuxmusl-64/
http://standalone.contextgarden.net/current/bin/luatex/linuxmusl-64/bin/

The `texluac` also appears to be missing from these paths (but I have not
experienced errors that appear relating to its absence).

2. mtxrun not finding paths
Running `context` results in an error because it cannot find
`mtx-context.lua`.

I can confirm that mtx-context.lua is in an expected path with:

$ /context # find . -name mtx-context.lua
./tex/texmf-context/scripts/context/lua/mtx-context.lua

I noted mtxrun checks and sets the `platform` (`os.platform`) variable, and
will use `linux-64` by default.  When musl is being used this ought to be
`linuxmusl-64`.  Two potential solutions are:

 a. have mtxrun detect musl with a call to `ldd --version` when setting
`platform`; or
 b. symlink texmf-linux-64 -> texmf-linuxmusl-64

I tried both but `context` still cannot find `mtx-context.lua`.

The path resolution is complex and challenging to debug, and I expect the
issue may be immediately apparent to some.

I've attached a log of a call to `context` with a number of the traces
turned on, that hopefully sheds some light on the problem.

I'm happy to delve or investigate further as may be helpful, and any
assistance is appreciated.

Cheers,
Brian

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*


context-output.log
Description: Binary data
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Build for Alpine Linux

2018-04-10 Thread Brian Hunt

>  The caret in itself was not the problem, only that it was not escaped
> for the shell.  Testing a regexp, with -E of course, is just as robust,
> and allows us to be more specific about what we test.

Either is fine I am sure, but from a code maintenance and testing
perspective I'd be more concerned about a regression or misinterpretation
to an unescaped carat that breaks the detection on zsh (and perhaps
elsewhere), as opposed to anticipating a hypothetical new or different
standard C library that needs detection for an alternative build.

>  grep -E '^musl' works just as well; and as I explained, -q may return 0
even if there are errors, so should be avoided.

The -q is superfluous with the >/dev/null, and should be removed;
incidentally though, is it not harmless in this case?  Avoiding it is
probably good measure for the reason mentioned (i.e. error on directories),
but I'm not sure that such an error in grep is possible when piped from
ldd, is it?  I'm curious when such could occur.

Cheers,
Brian

On Mon, 9 Apr 2018 at 15:35 Arthur Reutenauer <
arthur.reutena...@normalesup.org> wrote:

> > A few notes:
> > a.) On some platforms fgrep has been deprecated (in favour of `grep -F`)
> so
> > it's not future-proof
>
>   I don’t think the aliases fgrep and egrep have ever been supposed to
> be portable.  POSIX has grep -F and grep -E, and that’s what we should
> use.
>
> > b.) The caret (^) passed to `grep -F` will not be interpreted as a regex,
> > since -F forces non-regexp, meaning the '^' will be interpreted literally
> > (and the string "^musl" is not in the ldd output).
>
>   The caret in itself was not the problem, only that it was not escaped
> for the shell.  Testing a regexp, with -E of course, is just as robust,
> and allows us to be more specific about what we test.
>
> > if command -v ldd >/dev/null && ldd --version 2>&1 | grep -Fq 'musl' >
> /dev/null
>
>   grep -E '^musl' works just as well; and as I explained, -q may return
> 0 even if there are errors, so should be avoided.
>
> Best,
>
> Arthur
>
> ___
> 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://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki : http://contextgarden.net
>
> ___

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Build for Alpine Linux

2018-04-09 Thread Brian Hunt

Here are a couple experimental observations.

1. Detecting musl.

-- Alpine Linux/sh --
$ ldd --version 2>&1 | grep -F musl
musl libc (x86_64)
$? = 0

-- Debian/bash --
$ ldd --version 2>&1 | grep -F musl
 (nothing; $? = 1)

-- Debian/zsh --
$ ldd --version 2>&1 | grep -F musl
(nothing; $? = 1)

A few notes:
a.) On some platforms fgrep has been deprecated (in favour of `grep -F`) so
it's not future-proof
b.) The caret (^) passed to `grep -F` will not be interpreted as a regex,
since -F forces non-regexp, meaning the '^' will be interpreted literally
(and the string "^musl" is not in the ldd output).
c.) It's likely safe to assume that the string 'musl' will only occur in
`ldd --version` where musl is installed
d.) I did not test a case Arthur described here
https://mailman.ntg.nl/pipermail/ntg-context/2018/091123.html, but the use
of -F ought to avoid the zsh EXTENDED_GLOB  problem

Based on this, a reasonably portable detection of musl in first-setup.sh
and tex/setuptex might be:

if command -v ldd >/dev/null && ldd --version 2>&1 | grep -Fq 'musl' >
/dev/null

2. Running /context/first-setup.sh the link /context/bin/texlua did not
exist and first-setup.sh fails.
Once symlinked to `luatex` in the same directory, first-setup.sh will run
rsync.

3. Similarly /context/tex/texmf-linuxmusl-64/bin/texlua does not exist, so
setuptex fails.
Once symlinked `luatex -> texlua` then setuptex can be executed (bearing in
mind `setuptex` needs to be updated with the same musl detection test as
first-setup.sh)

4. setuptex needs to be called with an explicit directory otherwise it
complains with

""/bin" is not a valid TEXROOT path.
(There is no file "/bin/texmf/tex/plain/base/plain.tex")
provide a proper tex root (like '. setuptex /something/tex')"

Running this will run setuptex variables:

$ . /context/tex/setuptex /context/tex
Setting "/context/tex" as ConTeXt root.

5. Running context exits with:
mtxrun  | unknown script 'context.lua' or 'mtx-context.lua'

That's as far as I have gotten for now, but I thought this enough to report.

6. I am happy to take direction and report, but it is also straightforward
to reproduce with Docker via the Dockerfile:

FROM python:3.6-alpine3.7
RUN apk --no-cache add rsyncWORKDIR /context

Then running docker:

$ docker build -t context .

$ docker run -ti context /bin/sh

Then in the docker container shell, run:

$ cd /context

$ wget http://minimals.contextgarden.net/setup/first-setup.sh \$ sh
./first-setup.sh --modules=all --engine=luatex

(please pardon the formatting - some copying and pasting here).

I hope this is helpful.

Cheers,
Brian

On Sun, 8 Apr 2018 at 20:52 Henri Menke <henrime...@gmail.com> wrote:

> On Sun, 2018-04-08 at 22:50 +0200, Mojca Miklavec wrote:
> > Dear Brian,
> >
> > On 8 April 2018 at 16:56, Brian Hunt wrote:
> > >
> > > Hello everyone,
> > >
> > > Per this question on tex.StackOverflow, I am having trouble getting
> ConTeXt
> > > (LuaTeX specifically) to run on Alpine Linux:
> > >
> > > https://tex.stackexchange.com/questions/425463
> > >
> > > Specifically, the build from ConTeXt standalone has a LuaTeX that
> seems not
> > > to run against the musl libc6 library.
> > We have a "nearly working" one. At least all the binaries should be
> > there, see for example:
> > http://distribution.contextgarden.net/setup/linuxmusl-64/
> >
> > There are two to three remaining problems:
> >
> > 1.) I disabled automatic musl recognition (short after enabling it)
> > after this bug report:
> > https://mailman.ntg.nl/pipermail/ntg-context/2018/091094.html
> > I need to finish "parsing"
> > https://mailman.ntg.nl/pipermail/ntg-context/2018/091123.html
> > and a few other posts in that thread and maybe make some additional
> > testing. There was some "oh no, it has to be the other way around"
> > discussion where I no longer followed and I need some more time to
> > read everything more carefully (no time for that right now).
> >
> > 2.) Most likely a patch in mtxrun is still needed (but I admit that I
> > didn't check) for proper platform recognition. The fact that we are
> > struggling in shell doesn't really help doing this part either :)
> >
> > 3.) Ideally we need to set up some automated LuaTeX builds to be able
> > to get the latest LuaTeX binaries in the future.
>
> Similar to TeX live I have set up an automated Travis CI build, which can
> deploy
> binaries to GitHub releases.
> https://github.com/hmenke/luatex/blob/master/.travis.yml
>
> However, I just forked Adam's mirror and I am not planning to keep mine
> updated.
> It wo

[NTG-context] Build for Alpine Linux

2018-04-08 Thread Brian Hunt

Hello everyone,

Per this question on tex.StackOverflow, I am having trouble getting ConTeXt
(LuaTeX specifically) to run on Alpine Linux:

https://tex.stackexchange.com/questions/425463

Specifically, the build from ConTeXt standalone has a LuaTeX that seems not
to run against the musl libc6 library.  Here are symptoms:

/context/bin # ldd luatex
/lib64/ld-linux-x86-64.so.2 (0x7fd05109c000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fd05109c000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fd05109c000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fd05109c000)
Error loading shared library ld-linux-x86-64.so.2:
No such file or directory (needed by luatex)
Error relocating luatex: __rawmemchr: symbol not found
Error relocating luatex: __isnan: symbol not found


Has anyone run ConTeXt on Alpine?

Many thanks.
Brian
-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

[NTG-context] In-Margin Title + whitespace/indent bug

2018-02-19 Thread Brian Hunt

Hi all,

I reported a curiosity on tex.stackexchange.com and a user noted that it
appears to be a bug / regression that should be reported as the issue
occurs in the latest beta (2018.02.14 22:56) but not TL2017 (2017.05.15
21:48).  You can see the details here:

https://tex.stackexchange.com/questions/415332

I trust there is adequate detail there to reproduce but please advise if
more information could assist.

Best,
Brian
-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] Old version of luatex for alpine linux (musl)

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

Re: [NTG-context] Build for Alpine Linux

[NTG-context] Build for Alpine Linux

[NTG-context] In-Margin Title + whitespace/indent bug

10 matches

Site Navigation

Mail list logo

Footer information