So as of today, anyone got tup running through Docker? Basically I want to get a tup workflow we have that depended on multiple dependencies (haskell, python, markdown) to run on a mounted folder on the host machine. It can be Windows/Mac. but it seems FUSE is breaking this for me.
Also I'd really wanna get tup binary instead of compiling it so I've used latest old repos... wonder if it's worth it as building it within the docker script would increase the image I'd like to keep smallest as possible. On Tuesday, June 23, 2015 at 4:51:30 PM UTC+3, Marcus Cobden wrote: > > I believe that some of the issues I encountered will be fixed in the > latest release. > > I have a docker image containing our toolchain. > I was running the tup build inside a running toolchain container, not as > part of a docker container image build. > > This will give you the build artifact, you may then use the artifact as > input to another docker image build. > This means your final image will not contain your toolchain, which is nice. > > Regards, > Marcus > > On Tuesday, 9 June 2015 19:52:29 UTC+1, Jan Plhák wrote: >> >> I have recently posted issue on github concerning this issue. I can be >> found here. <https://github.com/docker/docker/issues/13287> And there is >> another issue <https://github.com/docker/docker/issues/1916> concerning >> privileged acces in general. >> However the progress seems to be very slow. Have you found any way around >> since the time you wrote that mail? >> >> Best regards, >> Jendas >> >> On Monday, 19 January 2015 15:42:00 UTC+1, Marcus Cobden wrote: >>> >>> I've been playing around, trying to combine tup and Docker to build >>> things, I though I'd post my current progress, in case anyone's interested >>> There are two approaches, but neither of them work, I'll explain below. >>> >>> *Tup in Docker:* >>> >>> Tup requires access to /dev/fuse, so you have to run the container with >>> some extra privileges [1] (NB: due to a bug [2] you seem to have to use >>> "--privileged"). >>> Once this works, tup still fails; because docker uses cgroups to isolate >>> the PID namespace, but fuse bypasses this. >>> tup sees PIDs from within the cgroup scope, but fuse reports PIDs from >>> the kernel's scope. >>> >>> tup fuse warning: Process pid=7096, uid=1000, gid=1000 is trying to >>>> access the tup server's fuse filesystem. >>>> unique: 3, error: -1 (Operation not permitted), outsize: 16 >>>> >>> >>> There's a new "--pid" option in development [3] which should disable PID >>> isolation, which might make this approach viable. >>> >>> *Docker from Tup:* >>> >>> This approach is unsuitable because Docker is a system daemon, so what >>> tup will see is the docker client binary reading local files, and talking >>> to a server socket. >>> The docker containers may: >>> - build from uploaded content >>> - build from system-wide loaded images >>> - build from internet content >>> - mount filesystems into the container >>> >>> The above is thoroughly likely to mess up any dependency tracking, and >>> filesystem access tracking. >>> >>> [1] >>> http://docs.docker.com/reference/run/#runtime-privilege-linux-capabilities-and-lxc-configuration >>> ) >>> [2] https://github.com/docker/docker/issues/10184 >>> [3] https://github.com/docker/docker/issues/6687 >>> >>> Marcus >>> >> -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
