Re: [NTG-context] Build for Alpine Linux
On 04/17/2018 05:25 PM, Arthur Reutenauer wrote: I can’t test musl support, but the new code should avoid the problem Thomas experienced. Best, Arthur I haven't had any trouble so far but need to test with another computer, tonight. Thomas ___ 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
On Fri, 13 Apr 2018, Henning Hraban Ramm wrote: Am 2018-04-13 um 13:42 schrieb Henri Menke : Exactly. We have that. And most bits and pieces are in place to allow that, except for the problem with mtxrun not being able to determine the platform correctly. Actually, the musl detection only has to be peformed for downloading binaries. Once those binaries are installed, they behave exactly like the linux-64 binaries. I would suggest to simply drop musl binaries in the texmf-linux-64 folder as well. (Who has ConTeXt for multiple platforms on their computer anyway?) That would render all the funny business of calling ldd in mtxrun superfluous. Probably only a few people need different binaries, but think of e.g. - universities etc. that provide a (SMB/DAV) shared installation on a server - dual-boot computers (Windows/Linux or OSX/Windows) that use a shared installation But the question is for multiple libc runtimes in linux. So, I think that simply installing the musl and glibc in the same directory is ok. Aditya ___ 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
Am 2018-04-13 um 13:42 schrieb Henri Menke : >> Exactly. We have that. And most bits and pieces are in place to allow >> that, except for the problem with mtxrun not being able to determine >> the platform correctly. > > Actually, the musl detection only has to be peformed for downloading > binaries. Once those binaries are installed, they behave exactly like > the linux-64 binaries. I would suggest to simply drop musl binaries in > the texmf-linux-64 folder as well. (Who has ConTeXt for multiple > platforms on their computer anyway?) That would render all the funny > business of calling ldd in mtxrun superfluous. Probably only a few people need different binaries, but think of e.g. - universities etc. that provide a (SMB/DAV) shared installation on a server - dual-boot computers (Windows/Linux or OSX/Windows) that use a shared installation Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net GPG Key ID 1C9B22FD ___ 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
On 4/13/2018 1:14 PM, Mojca Miklavec wrote:
On 11 April 2018 at 22:37, Hans Hagen wrote:
On 4/11/2018 10:08 PM, Brian Hunt wrote:
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
This was entirely my fault which has been fixed in the meantime.
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)
Exactly. We have that. And most bits and pieces are in place to allow
that, except for the problem with mtxrun not being able to determine
the platform correctly.
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
how about this one
function resolvers.platform(t,k)
local architecture = os.getenv("HOSTTYPE") or resultof("uname
-m") or ""
local platform = os.getenv("MTX_PLATFORM")
local musl = find(os.selfdir or "","linuxmusl")
if platform ~= "" then
-- we're done
elseif find(architecture,"x86_64",1,true) then
platform = musl and "linuxmusl" or "linux-64"
elseif find(architecture,"ppc",1,true) then
platform = "linux-ppc"
else
platform = musl and "linuxmusl" or "linux"
end
os.setenv("MTX_PLATFORM",platform)
os.platform = platform
return platform
end
assuming that the user or setuptex sets the path right this will cover
runtime
that still leaves an issue for the initial mtx-update but that one can
set MTX_PLATFORM=linuxmusl
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
-
___
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
On 04/13/2018 11:14 PM, Mojca Miklavec wrote:
> On 11 April 2018 at 22:37, Hans Hagen wrote:
>> On 4/11/2018 10:08 PM, Brian Hunt wrote:
>>
>>> 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
>
> This was entirely my fault which has been fixed in the meantime.
>
>> 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)
>
> Exactly. We have that. And most bits and pieces are in place to allow
> that, except for the problem with mtxrun not being able to determine
> the platform correctly.
Actually, the musl detection only has to be peformed for downloading
binaries. Once those binaries are installed, they behave exactly like
the linux-64 binaries. I would suggest to simply drop musl binaries in
the texmf-linux-64 folder as well. (Who has ConTeXt for multiple
platforms on their computer anyway?) That would render all the funny
business of calling ldd in mtxrun superfluous.
>
>>> 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
>
> Hans, we don't really need this code for the sake of minimals
> themselves, it is part of ConTeXt code that needs it and fails.
>
> The problem is that even if I properly detect the platform upfront,
> your code (mtx-update) will refuse to respect the setting. When
> calling
> ./bin/mtxrun --script ./bin/mtx-update.lua --force --update --make
> --context=beta --platform=linuxmusl-64 --texroot="/some/path"
> from musl linux, the mtx-update will insist in always installing and
> using linux-64 binaries even if they don't work, no matter what else
> we try.
>
> I still believe that a string like "x86_64-linuxmusl" is something
> that luatex itself should be able to return when asked about what
> platform it is running on (what platform it has been compiled for).
> We've discussed this with Taco many years ago, but this has never been
> implemented.
>
> 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
> ___
>
___
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
On 11 April 2018 at 22:37, Hans Hagen wrote:
> On 4/11/2018 10:08 PM, Brian Hunt wrote:
>
>> 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
This was entirely my fault which has been fixed in the meantime.
> 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)
Exactly. We have that. And most bits and pieces are in place to allow
that, except for the problem with mtxrun not being able to determine
the platform correctly.
>> 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
Hans, we don't really need this code for the sake of minimals
themselves, it is part of ConTeXt code that needs it and fails.
The problem is that even if I properly detect the platform upfront,
your code (mtx-update) will refuse to respect the setting. When
calling
./bin/mtxrun --script ./bin/mtx-update.lua --force --update --make
--context=beta --platform=linuxmusl-64 --texroot="/some/path"
from musl linux, the mtx-update will insist in always installing and
using linux-64 binaries even if they don't work, no matter what else
we try.
I still believe that a string like "x86_64-linuxmusl" is something
that luatex itself should be able to return when asked about what
platform it is running on (what platform it has been compiled for).
We've discussed this with Taco many years ago, but this has never been
implemented.
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
___
Re: [NTG-context] Build for Alpine Linux
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 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
> > 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 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.*
_
Re: [NTG-context] Build for Alpine Linux
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
> 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
> __
> _
___
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
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 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 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
author
Re: [NTG-context] Build for Alpine Linux
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
-
___
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
On Wed, 11 Apr 2018, Brian Hunt wrote: 6. `context` is unable to locate `mtx-context.lua`. Some tracker output sheds some light: Have you run luatools --generate Aditya ___ 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
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 'false'
resolvers
Re: [NTG-context] Build for Alpine Linux
> 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 * 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
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 ___
Re: [NTG-context] Build for Alpine Linux
On Tue, 10 Apr 2018 11:05:12 + Brian Hunt wrote: > 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 Doesn't *everybody* use zsh? ;-) ___ 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
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
> 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
> 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 ___
Re: [NTG-context] Build for Alpine Linux
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 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 would be nice to have some sort of “official” LuaTeX mirror on GitHub > for > that. Nevertheless, it might be worthwhile to check the '.travis.yml' I > posted > above into the LuaTeX SVN. > > > > > > > > > Has anyone run ConTeXt on Alpine? > > At the moment it should work if you install TeX Live 2018 pretest with > > the ConTeXt scheme or if you fiddle a bit with the installation (you > > need to hardcode the platform name in first-setup.s
Re: [NTG-context] Build for Alpine Linux
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 would be nice to have some sort of “official” LuaTeX mirror on GitHub for that. Nevertheless, it might be worthwhile to check the '.travis.yml' I posted above into the LuaTeX SVN. > > > > > Has anyone run ConTeXt on Alpine? > At the moment it should work if you install TeX Live 2018 pretest with > the ConTeXt scheme or if you fiddle a bit with the installation (you > need to hardcode the platform name in first-setup.sh and then still > some minor things might still go wrong, not sure). But in fact very > little is required to fix the remaining issues. > > Can you please remind us to pick this up again in a couple of days? > > In the meantime, if you are willing to do some more extensive testing > of patches (see full thread linked above) on both musl & non-musl > linuxes, in various shells etc., as well as perhaps come up with a > patch for mtxrun, that might help. > > 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 ___
Re: [NTG-context] Build for Alpine Linux
On Mon, Apr 09, 2018 at 09:26:35AM +1200, Henri Menke wrote: > This only blows up on Zsh. I will contact the "config.guess" maintainer (from > where I stole that snippet). The unescaped caret is only a problem on zsh with EXTENDED_GLOB activated, but the effect of grep -q is problematic, and not using -E with a regexp is strange, for code that’s supposed to be highly portable. 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 ___
Re: [NTG-context] Build for Alpine Linux
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). This only blows up on Zsh. I will contact the "config.guess" maintainer (from where I stole that snippet). > > 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. > > > > > Has anyone run ConTeXt on Alpine? > At the moment it should work if you install TeX Live 2018 pretest with > the ConTeXt scheme or if you fiddle a bit with the installation (you > need to hardcode the platform name in first-setup.sh and then still > some minor things might still go wrong, not sure). But in fact very > little is required to fix the remaining issues. > > Can you please remind us to pick this up again in a couple of days? > > In the meantime, if you are willing to do some more extensive testing > of patches (see full thread linked above) on both musl & non-musl > linuxes, in various shells etc., as well as perhaps come up with a > patch for mtxrun, that might help. > > 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 ___
Re: [NTG-context] Build for Alpine Linux
On Sun, Apr 08, 2018 at 10:50:16PM +0200, Mojca Miklavec wrote: > I need to finish "parsing" > https://mailman.ntg.nl/pipermail/ntg-context/2018/091123.html I was wondering if anyone had paid attention to that :-) I realise the explanation is a bit long, but there were many details and I thought it was interesting to document the situation. In summary: 1. The flow of the current test is corect, making the GNU libc the default 2. The string ^musl should be escaped, for example with single quotes 3. grep -q has a confusing behaviour and should be replaced by grep >/dev/null 4. (Not in the long explanation) grep -E is recommended when using regexps That is to say: if command -v ldd >/dev/null && ldd --version 2>&1 | grep -E '^musl' >/dev/null then libc=musl else libc=glic end 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 ___
Re: [NTG-context] Build for Alpine Linux
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. > Has anyone run ConTeXt on Alpine? At the moment it should work if you install TeX Live 2018 pretest with the ConTeXt scheme or if you fiddle a bit with the installation (you need to hardcode the platform name in first-setup.sh and then still some minor things might still go wrong, not sure). But in fact very little is required to fix the remaining issues. Can you please remind us to pick this up again in a couple of days? In the meantime, if you are willing to do some more extensive testing of patches (see full thread linked above) on both musl & non-musl linuxes, in various shells etc., as well as perhaps come up with a patch for mtxrun, that might help. 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 ___
[NTG-context] Build for Alpine Linux
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 ___
