Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kon Tsaki
    @laerus
    oh right
    Paul Colomiets
    @tailhook
    In the meantime we can change the link, if it's hanging somewhere...
    Kon Tsaki
    @laerus
    seems like an old issue rtfd/readthedocs.org#3059 :(
    Karel Wintersky
    @KarelWintersky
    Hi, All. How to compile Vagga at gentoo using rust docker container?
    error: environment variable `VAGGA_VERSION` not defined
      --> src/config/config.rs:56:26
    fails here.
    (можно отвечать на русском ;) )
    Karel Wintersky
    @KarelWintersky
    Solved.
    docker run --rm --user "$(id -u)":"$(id -g)" -e VAGGA_VERSION=v0.8.1-19-g372bded -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust cargo build --release
    Lloyd Konneker
    @bootchk
    • !Sh 'git clone --recurse-submodules git://github.com/flathub/org.gimp.GIMP' seems to create a directory org.gimp.GIMP at the top i.e. in parent directory of vagga.yaml, i.e. not in the container. That seems bad. I suppose I can do the recursion myself.
    Paul Colomiets
    @tailhook
    @bootchk, I've already answered on a github, but basically, just cd into a specific directory in the container (we don't forbid mutating working directory, as it would crash a lot of tools out of the box)
    Michael Pankov
    @mkpankov
    hey, from the docs I got the impression that I can build a container with vagga and run it with docker.
    is it correct? how do I do it?
    Paul Colomiets
    @tailhook
    @mkpankov, yes. You should be able to do something like vagga _pack_image CONTAINER_NAME > image.tar; docker import image.tar (or ADD image.tar / in Dockerfile)
    Michael Pankov
    @mkpankov
    thanks, not a docker user so it was really a riddle
    Michael Pankov
    @mkpankov
    hey
    I have several repos where I want to use vagga, currently I've put vagga.yaml in first one. now I've discovered I need to share parts of vagga.yaml between repos (i.e. definition of Rust container). how should I do that?
    I've read about YAML includes and mixins, I can't quite put it together. both of them are restricted to including stuff from sub-directories. why?
    Paul Colomiets
    @tailhook
    @mkpankov, this is a a security measure. So that when you run vagga xxx from a foreign project it can't stole your ssh keys or similar. You can share configs either but putting them in git submodule (and updating manually), or you can mount --bind a subdirectory into several places. Or you can use external-volumes to overcome that limiation (although, it would require configuring them for every user).
    Michael Pankov
    @mkpankov
    thanks for quick reply. to me that seems like a lot of overhead for something I'd like to have out-of-the-box. I mean, submodules are hell and mounting something manually when the purpose of vagga is to avoid doing that... what is your opinion on something that could be built-in?
    or, maybe I should just write a "root" vagga.yaml and move everything there? so that project repos don't contain one and come just as source repositories
    context is, I have repos of two rust tools, one of which runs the other, so they are almost always used together
    Paul Colomiets
    @tailhook
    Technically you can, if you like it.
    I usually install one tool in the second's vagga.yaml as a normal package (e.g. cargo install)
    And then if I want debug something very coupled I use mount --bind or just copy thing in ad hoc way.
    Alternatively, you can also make a command which fetches mixin remotely before the first start.
    Michael Pankov
    @mkpankov
    my tools are proprietary and we currently don't run our registry, so I can't cargo install
    I guess I'd like something of "best practice" advice (even better if it's in the docs)

    Alternatively, you can also make a command which fetches mixin remotely before the first start.

    that's interesting

    that way I can share my include/mixin w/o access to parent directory, could work, I think
    btw, are symlinks followed? If I ln -s ../include.yaml include.yaml?
    Paul Colomiets
    @tailhook
    No, that would kill whole security :)
    Michael Pankov
    @mkpankov
    yeah, thought so)
    Paul Colomiets
    @tailhook

    I'd like something of "best practice" advice

    I usually recommend as independent repos as possible, i.e. that you can vagga run in any one. And use git submodules for thing that can't be fetched from package repos. The big advantage of submodules that you can always mount --bind on top. Not sure it's anywhere in the docs.

    Michael Pankov
    @mkpankov
    what do you mean by "mount --bind on top"? like, why would I need it
    (sorry if it's stupid question, I'm a novice with containers)
    Paul Colomiets
    @tailhook
    I.e you have ./proj1 and ./proj2. And also ./proj1/proj2 is a git submodule. Sometimes you edited ./proj2 and want to try it inside ./proj1: cd proj1; mount --bind ../proj2 proj2 and you have it.
    https://medium.com/@paulcolomiets/announcing-vagga-0-7-1-85b9a9e84f2a
    Section "mixins" describes how to "generate" mixin (in your case 'generating' might be just fetching somewhere)
    Michael Pankov
    @mkpankov
    thanks, will try that
    Michael Pankov
    @mkpankov
    a side question: are you actively developing vagga currently?
    Paul Colomiets
    @tailhook
    @mkpankov, I don't have time recently, so we definitely have some technical debt (i.e. need to release a stable). But this is a thing that I'm using every day more that any other command-line tool (for obvious reasons :) ). And there are other people like me (hard to count). So I don't consider project abandoned. And I'm looking forward to spent more time on it.
    Michael Pankov
    @mkpankov
    hey. in case you have advices on how to debug this, I'd appreciate it
    tailhook/vagga#519
    Paul Colomiets
    @tailhook
    @mkpankov Answered in github issue. Hopefully, that is helpful
    Richard Gomes
    @frgomes
    Hello everyone. My first post here. I'm happy to find an alternative to Docker, to a certain extent. :-)
    Richard Gomes
    @frgomes
    I've tried to build from sources, following the instructions from vagga.readthedocs.org, employing tag v0.8.1 but I've got compilation errors.
    Am I doing anything wrong, please?
    #!/bin/bash
    
    sudo apt install musl-tools -y
    
    git clone https://github.com/tailhook/vagga
    cd vagga/
    git checkout v0.8.1
    rustup target add x86_64-unknown-linux-musl
    cargo build --target x86_64-unknown-linux-musl
    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Debian
    Description:    Debian GNU/Linux 10 (buster)
    Release:        10
    Codename:       buster
    
    $ uname -a
    Linux lua 5.3.0-0.bpo.2-amd64 #1 SMP Debian 5.3.9-2~bpo10+1 (2019-11-13) x86_64 GNU/Linux
    Richard Gomes
    @frgomes
    error: environment variable `VAGGA_VERSION` not defined
      --> src/config/config.rs:56:26
       |
    56 |         .current_version(env!("VAGGA_VERSION").to_string()))
       |                          ^^^^^^^^^^^^^^^^^^^^^
    
    error: environment variable `VAGGA_VERSION` not defined
      --> src/launcher/mod.rs:94:19
       |
    94 |             Print(env!("VAGGA_VERSION").to_string()),
    The documentation does not mention anything about VAGGA_VERSION, as far as I read. And I didn't read much... just jumped to Installation and followed instructions.
    Richard Gomes
    @frgomes
    OK.
    VAGGA_VERSION=$(git describe) cargo build --target x86_64-unknown-linux-musl
    Lloyd Konneker
    @bootchk
    I am building GIMP (in C language) using meson build, with the build directory in the project directory (/work/_build). If I build in a vagga command, at the install phase I get "Read-only file system: '/usr/local/lib/x86_64-linux-gnu/libgimpbase-3.0.so.0.0.7'". If I build GIMP during container build, it builds the 'all' target (everything), because it thinks the compiler at /usr/bin/x86...gnu-c-10 is newer than a previous build, I suppose because vagga touches all the symbolic links in the container before actually building GIMP. I think I have a fundamental ignorance of how to use containers to set up a development environment for building a C program. Is there an example? I want all the tools and dependencies in a container, but to be able to hack at the GIMP source, build quickly i.e. incrementally, and install in the container (not corrupt my host machine.)
    Paul Colomiets
    @tailhook
    @bootchk to test installation you can use write-mode: transient-hard-link-copy. But it's generally not common case to test installation via vagga on every build.
    Lloyd Konneker
    @bootchk
    I will explore your suggestion, but now I am wondering whether "Read-only file sytem" error should occur. The internet says the file system is probably corrupted. And since its a container in userspace, vagga does not change the permissions? Or does vagga make a container read-only? To clarify, I just have a vagga command to open a shell in the container, and try to build in a /work directory, but install into the container.
    Lloyd Konneker
    @bootchk
    I tried you suggestion, and it seems to work at least the command does not fail. And now I understand that a container is immutable. Let me explain my use case. I develop (small contributions to) the GIMP app. It has many dependencies, some of which are nightly library versions which must be built, e.g. babl and gegl. I also want to test on many distributions and versions, e.g. Ubuntu 21.04, Arch, etc. So I want a scripted container of all the dependencies so that I am sure that is is correct and not polluted. But GIMP is C and needs to be installed. It seems like most of your other use cases are for interpreted scripts that do not install. But GIMP needs to be installed to the standard place in the container (at least I don't want to mess with INSTALL_DIR variables.) If for any reason a container seems corrupted (say by an install) vagga makes it easy to delete the container and reconstruct it (as you say "vagga _build --force") Vagga seems great, thank you so very much for sharing.