by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Simon Cozens
    @simoncozens
    The package name is repl, but that's apparently what we test for:
    checking for required Lua library repl... not found
    configure: error: cannot find Lua library repl - install from luarocks package luarepl
    Caleb Maclennan
    @alerque
    You're welcome to push to my repo / branch for that PR by the way, I just thought I'd get things started.
    Simon Cozens
    @simoncozens
    That's the only one failing, strangely, so setting up the luarocks path must be working.
    And I've now reproduced it locally. Let me see.
    Caleb Maclennan
    @alerque
    Good luck, you have a leg up on me there since I have no operational Mac.
    Simon Cozens
    @simoncozens
    OK, I am confused. You're using --with-system-luarocks but you are also installing the luarocks into /usr/local/Cellar/sile/0.10.0_1/libexec/vendor//share/lua/
    I thought --with-system-luarocks meant "use the normal Lua installation paths".
    Caleb Maclennan
    @alerque
    That is the system Lua rocks path in this case, no? Basically the Formula is setup to pretend there is a system install of the rocks but runs the whole thing on an island to itself.
    It does. --without-system-luarocks would cause the make process to fetch and bundle them all with SILE without telling brew anything about them.
    Here brew is stepping in and giving a sort of sand boxed system path so it can handle the downloading, checksumming, etc. itself rather than fetching the deps at build time.
    Simon Cozens
    @simoncozens
    Let me do a debugging build.
    OK, think I got it.
    I could check out your entire homebrew repo and post a patch to it in half an hour when it's done, or you could replace line 102 of sile.rb with
        ENV["LUA_PATH"] = "#{luapath}/share/lua/5.3/?.lua;#{luapath}/share/lua/5.3/?/init.lua;#{luapath}/share/lua/5.3/lxp/?.lua"
    Caleb Maclennan
    @alerque
    Pushed.
    You could have also just added my repo as a remote to your existing clone and you wouldn't have to wait half an hour ;-)
    Simon Cozens
    @simoncozens
    Oh, yeah, I forgot homebrew worked like that. :-)
    Caleb Maclennan
    @alerque
    Do the various brew ... commands from Homebrew's PR checklist pan out for you? If so I'll check them off.
    Simon Cozens
    @simoncozens
    I'm working on it.
    We don't pull in the std rock but still require it in configure. I'll add it to the formula.
    Caleb Maclennan
    @alerque
    Oh that's an oops that affects everybody!
    Simon Cozens
    @simoncozens
    Do we require it in the codebase at all or just in configure?
    Caleb Maclennan
    @alerque
    Actually we do have it in the rockspec, so most people will get it. It's not in my Arch Linux deps though.
    Simon Cozens
    @simoncozens
    Ah, ./core/sile.lua:std = require("std")
    So people doing --without-system-luarocks will get it auto-installed, and people doing the --with-system-luarocks thing will be told what to do to install it. Inconvenient but not awful.
    Caleb Maclennan
    @alerque
    That loads it, but the "stdlib == 41.2.2-1" in sile-dev-1.rockspec is what actually triggers it to be installed when --without-system-luarocks is in action.
    Yes, but that's the case for all the Luarocks if they choose to provide them themselves.
    Simon Cozens
    @simoncozens
    Right.
    Caleb Maclennan
    @alerque
    Hence why it's mostly up to packagers to include them all. And I missed it not just putting together that Formula but Arch and Void too.
    Simon Cozens
    @simoncozens
    OK, off we go again. This time the formula built for me.
    Caleb Maclennan
    @alerque
    No I didn't, it's there in Arch....holdover from before. It should have been in the Homebrew Formula already too, 0.9.x needed it too!
    brew test / brew audit?
    Simon Cozens
    @simoncozens
    Audit was happy. test is being silly:
    $ brew test sile -v
    Error: Testing requires the latest version of sile
    Caleb Maclennan
    @alerque
    What does that even mean?
    That's after an install? It doesn't understand semver?
    Simon Cozens
    @simoncozens
    Got it. It's getting its idea of "latest version" from the installed formula (/usr/local/Cellar/...), whereas I was hacking on your formula in another place, so it thought that latest was still 0.9.1.
    Copy in your formula and tests pass. Check all the boxes!
    Caleb Maclennan
    @alerque
    Docker images are coming along nicely. SILE is going to be a cake walk; CaSILE is going to be a bit more troublesome because ⓐ it has graphics stuff for covers that have huge dependency chains like xorg (I'll probably start with a stripped down version just for doing book interiors and gradually upgrades its capabilities) and ⓑ my hackery on Pandoc is in bad shape and not upstreamed. I guess I'm going to have to brush up on my Haskell.
    Simon Cozens
    @simoncozens
    Very nice.
    Caleb Maclennan
    @alerque
    Nevermind. Its' not coming along nicely, it works. I just passed an XML file to a docker run command and got a PDF back!
    I'm not going to push the images to Docker Hub just yet because I haven't cleaned up and stripped down the image and it currently has a lot of install and compile artifacts I can remove and leave just the working sile behind.
    Simon Cozens
    @simoncozens
    Wait, you got CaSILE on there as well (in six minutes?)
    Caleb Maclennan
    @alerque
    No, just sile.
    Simon Cozens
    @simoncozens
    Ah OK. :-)
    Caleb Maclennan
    @alerque
    And I'm out of time to finish off the cleanup and it's really hard to downsize what is in images later. I'll clean it up before pushing images, but you can try it out yourself.
    Clone the repo, run make sile, wait for it to assemble the image (takes a while), then:
    docker run -it --volume "$(pwd):/data" --user $(id -u):$(id -g) siletypesetter/sile:v0.10.0 input.sil
    Caleb Maclennan
    @alerque
    Really that was all the work on the build system and deps for v0.10.0 paying off, it would not have been so easy if the distro packaging wasn't so hashed over.
    Caleb Maclennan
    @alerque

    Docker builds off of master are fully automatic and working now.

    $ docker run -it siletypesetter/sile:master --version
    SILE v0.10.0.r31-g8474b80

    Docker seems to fetch remote images on run if they don't exist locally, but not refresh them on run. You explicitly update to the latest with docker pull siletypesetter/sile:master. But of course you can use tagged versions like v0.10.0 and latest (for the last build tag) too in place of master.

    I'd love to make the docker builds a required check on PRs, but the build time is too much for me right now. Builds take ~20-22 minutes, but the queue is often backlogged and jobs often don't even start for over half an hour, so I think we'll just have to settle for whatever their status is when they come in. Mostly if the regular tests pass unless you messed with the install functions, added dependencies, or similar they shouldn't break.
    Caleb Maclennan
    @alerque
    Actually there is hope for the build times. I've been working on the image and the system dependencies, which forces it to rebuild the base image a lot. Changes just to sile don't even come into place until after a base image is setup, and it looks like that part might end up being relatively fast (~10 min range), so we'll have to see. For now it's just optional.
    Now, back to Haskel for Pandoc so I can setup CaSILE.