Running tup in a non-nfs directory on this machine fails with: $ tup Initializing .tup in /var/droundy/deft .tup repository initialized. [ tup ] [0.091s] Scanning filesystem... [ tup ] [0.231s] Reading in new environment variables... [ tup ] [0.323s] Parsing Tupfiles... .tup/mnt: Permission denied [ ETA~=??? Remaining=78 ] 0% *** tup: 1 job failed.
I'm not sure what's up with that. It doesn't leave the fuse filesystem mounted in this directory, however, so that at least is better, as it means at least I can delete the .tup directory afterwards. I'm hesitant to adopt a build system that is this finicky. I'm confident I can get it working one way or another (after all, tup works on my laptop), but having a build system that fails at all is bad, and when it fails in confusing ways that lead to un-removable directories, that's worse. David On Friday, October 31, 2014 9:57:08 AM UTC-7, David Roundy wrote: > > I am currently getting the error: > > $ tup > Initializing .tup in /home/droundy/Sync/projects/deft > .tup repository initialized. > [ tup ] [0.150s] Scanning filesystem... > [ tup ] [0.679s] Reading in new environment variables... > [ tup ] [0.797s] Parsing Tupfiles... > .tup/mnt: Permission denied > [ ETA~=??? Remaining=81 > ] 0% > *** tup: 1 job failed. > fusermount: failed to chdir to /home/droundy/Sync/projects/deft/.tup: > Permission denied > tup error: Unable to unmount the fuse file-system on .tup/mnt (return code > = 256). You may have to unmount this manually as root: umount -f .tup/mnt > > To see the mount: > > $ mount | grep tup > tup on /home/droundy/Sync/projects/deft/.tup/mnt type fuse.tup > (rw,nosuid,nodev,relatime,user_id=1137,group_id=100) > > Any attempt to use root to umount fails because this directory is not > world-readable and lives on my NFS-mounted home directory, which is mounted > with rootsquash. (As is the only sane option.) > > David > > On Friday, October 31, 2014 6:26:04 AM UTC-7, Freddie Chopin wrote: >> >> On 10/31/2014 02:02 PM, David Roundy wrote: >> > I've just been struggling with fuse errors on my work computer, where >> > I wasn't originally a member of the fuse group, and I'm working on >> > nfs... I still haven't figured out which of these caused the most >> > errors, but things still aren't working. I expect that if tup is >> > packaged by Debian, many of these pains will go away. >> > >> > However, I got to wondering if ptrace might serve. If all you need is >> > to trace syscalls, I think this could work on Linux anyhow. The >> > downside is that you'd need to make tup understand all system calls >> > that would affect files. The plus side would be that it would be much >> > simpler and more robust in operation, since you wouldn't have to mount >> > and unmount a fake filesystem, and it would work with statically >> > linked executables (including ones that don't use libc). The downside >> > is that you might not be able to lie about readdir's results to >> > convince executables that generated files don't exist. >> > >> > Anyhow, just a few thoughts, after an hour or so of fruitless attempts >> > to make tup work. >> > >> > David >> >> Here is a post by Mike about different dependency tracking options - >> there's also a chapter about ptrace(). >> >> >> http://gittup.org/blog/2014/05/7-clobber-builds-part-2---fixing-missing-dependencies/ >> >> >> What problems do you have? I've recently switched to Linux and I've >> probably faced the same issues as you did, so maybe I'll be able to >> help. I'm using Arch, so things may be a bit different. >> >> Regards, >> FCh >> > -- -- 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.
