Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Vít Novotný
    @witiko:matrix.org
    [m]
    Not a problem. It may not make sense to pursue this now if your pipelines are already full and your target audience are CI services, but I will dump what I know into the issue and we'll see. Worst-case scenario: we will have a pretty good tutorial for whoever wants to build their own texlive images on strange architectures.
    Paulo Cereda
    @cereda:matrix.org
    [m]
    Let's see how it goes. :) I always have a cheerful attitude. :)
    3 replies
    Paulo Cereda
    @cereda:matrix.org
    [m]
    hmenke: you are the best ❤️
    Vít Novotný
    @witiko:matrix.org
    [m]
    hmenke: Hello, I remember citing your TUGboat paper about using LPEG to build parsers in Lua(TeX). Great work. 🙂 It seems I will be citing you again when I get to write a follow-up article about adding Docker support to the Markdown LaTeX package.
    Paulo Cereda
    @cereda:matrix.org
    [m]
    Thanks!
    hmenke
    @hmenke:matrix.org
    [m]
    Is there an easy way to see what SVN revision the texlive:latest image is on?
    Without downloading the entire image and spawning a shell.
    1 reply
    Paulo Cereda
    @cereda:matrix.org
    [m]
    Thanks, Ben!
    hmenke
    @hmenke:matrix.org
    [m]
    It would be really useful to have image tags for different schemes (islandoftex/images/texlive#11)
    One very efficient way of doing this is to have a Docker file that does
    RUN tlmgr install scheme-minimal
    RUN tlmgr install scheme-medium
    ...
    RUN tlmgr install scheme-full
    1 reply
    Because each of these is incremental you can just tag the individual layers and have perfect reuse.
    Unfortunately this also means that build time for the Docker image will increase by a lot because tlmgr is slow.
    1 reply
    Ben Frank: I've seen that but to be quite honest, I think this is unreasonable.
    You just have to update the Debian base image once in a while.
    3 replies
    Otherwise you're distributing possibly insecure packages.
    hmenke
    @hmenke:matrix.org
    [m]
    The only other solution I can think of would be to install TeX Live outside of the Docker container, then start FROM scratch and copy the TeX Live tree inside. Then layer the Debian image on top of that.
    Also users can just run tlmgr update inside of their local copy.
    1 reply
    hmenke
    @hmenke:matrix.org
    [m]
    --- a/Dockerfile.latest
    +++ b/Dockerfile.latest
    @@ -45,7 +45,7 @@ RUN echo "Building with documentation: $DOCFILES" && \
       # actually install TeX Live
       cd install-tl* && \
       # choose complete installation
    -  echo "selected_scheme scheme-full" > install.profile && \
    +  echo "selected_scheme scheme-infraonly" > install.profile && \
       # … but disable documentation and source files when asked to stay slim
       if [ "$DOCFILES" = "no" ]; then echo "tlpdbopt_install_docfiles 0" >> install.profile && \
         echo "BUILD: Disabling documentation files"; fi && \
    @@ -60,6 +60,12 @@ RUN echo "Building with documentation: $DOCFILES" && \
       # add all relevant binaries to the PATH
       $(find /usr/local/texlive -name tlmgr) path add
    
    +RUN tlmgr install scheme-minimal
    +RUN tlmgr install scheme-basic
    +RUN tlmgr install scheme-small
    +RUN tlmgr install scheme-medium
    +RUN tlmgr install scheme-full
    +
     RUN \
       # test the installation
       latex --version && printf '\n' && \
    1 reply
    This is what I have in mind.
    1 reply
    The schemes context, gust, and tetex can be ignored I think.
    The scheme-gust is specific to GUST I guess and users of ConTeXt are anyway much better off using the ConTeXt beta images.
    tetex doesn't exist anymore (it was the predecessor of TeX Live) but if necessary this scheme would go between medium and full.
    Vít Novotný
    @witiko:matrix.org
    [m]
    Hello. When can we expect TL2021-historic images on GitLab and DockerHub?
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    Thank you, Ben Frank , much appreciated.
    Vít Novotný
    @witiko:matrix.org
    [m]
    Are there any updates on the TL2021-historic images, Ben Frank ?
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    Ben Frank: I see. The issue is the disk space available on the runners, then?
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    I see. That's an annoyance to be sure! Have you tried passing --force-rm and --no-build-cache to docker build?
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    It makes docker build more aggressive about the layers it keeps when building. Please, let me know if it helps. 🙂
    Ben Frank
    @benfrank:matrix.org
    [m]
    Unfortunately, it does not work. GL runners are simply not suited anymore. I now built the image locally and will push it from here. But only for TL2021-historic (no doc, no src).
    Vít Novotný
    @witiko:matrix.org
    [m]
    I would be happy to discuss why it does not work and how we could make it work, but perhaps in a separate thread, so that we don't spam others?
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    That is unfortunate, but also much appreciated. I will create a TL2021 release of witiko/markdown right away.
    Paulo Cereda
    @cereda:matrix.org
    [m]
    Hi friends, I just want to say thank you to Ben and Vít for taking the time to look at the Docker images! ❤️
    Vít Novotný
    @witiko:matrix.org
    [m]
    :point_up: Edit: That is unfortunate, but also much appreciated. I will create a TL2021 release of witiko/markdown right away.
    https://github.com/Witiko/markdown/actions/runs/2289199925
    berkas1
    @berkas1:matrix.org
    [m]
    Hi guys, do you have someone to host gitlab runner already or not? If you don't, I could provide a VM on my desktop (VM params: 4 cores, 16GB ram, 60gb nvme) right now to build what is needed. I know it is a bad solution (since it would be up only 18 hours per day), but this is the quickest help I can offer...
    1 reply
    hmenke
    @hmenke:matrix.org
    [m]
    I've recently read on the TeX Live list that you are having problems with being time-limited by GitLab CI for building the images. Have you considered inverting the build for the historic images? Since the entire TeX Live tree is frozen for them it would make sense to “install” TeX Live (potentially in portable mode) outside of Docker into a directory, then start FROM scratch, copy that directory into the image and only as a last step layer the operating system on top. The initial layer containing nothing but the historic TeX Live will be perfectly deterministic (by virtue of being frozen) so you get perfect layer reuse and OS updates on top can be done in a matter of seconds.
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    hmenke: The original issue was that we did not have our own runners, which prevented any action outside Docker.
    At the moment, we have a couple of runners and mounting a mirror of CTAN is indeed one of the options on the table.
    However, it's less reproducible than doing it inside docker, so that's that. Also does not scale as well to more runners.
    Ben Frank
    @benfrank:matrix.org
    [m]
    If anyone is interested: https://hub.docker.com/r/texlive/texlive/tags, the TL<YEAR>-historic-tree* tags are those that contain only the TeX Live trees (for Linux x86-64). We have not publicly announced the names yet but probably they will stay as is.
    Vít Novotný
    @witiko:matrix.org
    [m]
    Apparently, we have everything in place. With !22 merged, it's just a matter of carving out a couple of hours to make an MR.
    1 reply
    Vít Novotný
    @witiko:matrix.org
    [m]
    Ah, the light begins to shine.
    It still seems to me that incremental updates are a more pressing issue from the standpoint of a user.
    Ben Frank
    @benfrank:matrix.org
    [m]
    Yes, but incremental updates combined with incremental split into schemes would be very bad layering resulting in explosion of pulled image size.
    I guess incremental updates are quite a strong argument for the independent scheme images. Probably users will not switch that often between schemes so it probably makes sense.
    Vít Novotný
    @witiko:matrix.org
    [m]
    It would seem that way. We cannot be incremental both across time and across schemes.
    And it seems to me that most users will be pulling a single scheme repeatedly.
    So each scheme would be its own set of layers corresponding to incremental updates in time, independent on other schemes.
    What we could do is this: we could build the root image for each year from the smaller schemes.
    3 replies