hanwen / go-fuse

FUSE bindings for Go
Other
2.05k stars 328 forks source link

Fails to build on FreeBSD #85

Closed jbeich closed 8 years ago

jbeich commented 8 years ago

(Not a PR due to CLA -> Google Account -> failed signup over Tor.)

$ go get github.com/hanwen/go-fuse/fuse
.go/src/github.com/hanwen/go-fuse/fuse/types.go:351: undefined: Attr

and lots of similar errors can be fixed by copying from:

.go/src/github.com/hanwen/go-fuse/fuse/server.go:96: undefined: unmount
.go/src/github.com/hanwen/go-fuse/fuse/server.go:181: undefined: mount

FreeBSD uses libfuse but not fusermount binary. Instead, the library calls mount_fusefs(8) with special argument obtained via open("/dev/fuse", ...). Playing with syscall.Dup() was enough for mounting to succeed but any VFS operation still hangs.

Regular users only need to sysctl vfs.usermount=1 before mount/umount.

.go/src/github.com/hanwen/go-fuse/fuse/types.go:24: undefined: syscall.ENODATA

NetBSD folks had an interesting discussion. OS X may unintentionally use ENODATA for unionfs here despite it's never returned.

http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&i=ENODATA http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&i=ENOATTR

$ go get github.com/hanwen/go-fuse/zipfs
.go/src/github.com/hanwen/go-fuse/fuse/nodefs/files.go:96: cannot use loopbackFile literal (type *loopbackFile) as type File in return argument:
        *loopbackFile does not implement File (missing Allocate method)
.go/src/github.com/hanwen/go-fuse/fuse/nodefs/syscall.go:11: undefined: syscall.SYS_UTIMENSAT
hanwen commented 8 years ago

I don't have a freebsd machine, so I won't be apply this.

I need a CLA for accepting changes; sorry.

hanwen commented 8 years ago

Please reopen when you have a patch and have signed the CLA.

rnkn commented 5 years ago

What is the best way around this CLA problem?

If the issue is that the CLA is hosted on the Google platform, would it be best to move it to a non-Google platform to allow regular non-Google-people to contribute? Or (and I suspect more likely) if the CLA itself is the issue, can this be given some further consideration, and failing that, can the project be forked and remove the requirement for a CLA?

hanwen commented 5 years ago

The CLA can be signed by anybody, provided their employer is OK with it. It does not require someone to be "Google-people".

The link you point to is written from the perspective of a well-willing contributor, but unfortunately contributors (or their employers) are not always well-willing. The CLA protects us against these people.

See https://opensource.google.com/docs/cla/policy/ for an in-depth discussion of what the CLA is. and why we require it. The case book (https://google.github.io/opencasebook/) has further legal analysis of the relevant topics, which you may find interesting.

It goes without saying that you are free to fork this project and go crazy (within the terms of the license) with it.

rnkn commented 5 years ago

The CLA can be signed by anybody, provided their employer is OK with it. It does not require someone to be "Google-people".

I tried following the link but it requires a Google account sign in. Only Google-people may pass. Resistence is futile. etc. etc. Luckily I made it back alive.

The link you point to is written from the perspective of a well-willing contributor, but unfortunately contributors (or their employers) are not always well-willing. The CLA protects us against these people.

This is probably just theoretical, because from the looks of above, the issue @jbeich has is not the CLA per se but access to it. Could you maybe have a Google form/spreadsheet thing for people (both Google and normal) to fill out?

See https://opensource.google.com/docs/cla/policy/ for an in-depth discussion of what the CLA is. and why we require it. The case book (https://google.github.io/opencasebook/) has further legal analysis of the relevant topics, which you may find interesting.

That CLA looks like it's for contributing to Google's code... but https://github.com/hanwen/go-fuse#disclaimer says go-fuse is not Google code....?

My only interest is really just that go-fuse work on BSD....

hanwen commented 5 years ago

It is likely that a Google Form would also require you to sign in with a google account. .

If you are concerned about privacy implications of using a Google account, you could use an incognito tab to create an account. Then again, if you are concerned about privacy, you should probably not record your name and email address in a version control log that is public and retained indefinitely in the first place.

hanwen commented 5 years ago

regarding https://github.com/hanwen/go-fuse#disclaimer

go-fuse is written by me, and I work for Google, which makes it copyrighted by Google. It is not a Google product, in the sense that it has no dedicated staffing.

rfjakob commented 5 years ago

says go-fuse is not Google code....?

AFAIK go-fuse is produced in part on Google company time. The disadvantage is that it must use Google's legal framework. The advantage is that go-fuse exists.

I'm pretty okay with that tradeoff.

rnkn commented 5 years ago

If you are concerned about privacy implications of using a Google account, you could use an incognito tab to create an account. Then again, if you are concerned about privacy, you should probably not record your name and email address in a version control log that is public and retained indefinitely in the first place.

It's more for the OP wishing to contribute.

hanwen commented 5 years ago

Is @jbeich in Iran, Syria, North Korea which would preclude them having a google account? If no, I suggest they switch off TOR for signing the CLA.

rnkn commented 5 years ago

Is @jbeich in Iran, Syria, North Korea which would preclude them having a google account? If no, I suggest they switch off TOR for signing the CLA.

Hahah so the only legit reason not to have a Google account is if you're living in Syria.... I have no idea what the story is, but I'm sure they have their reasons.

We're not programs Gerty, we're people.

rfjakob commented 5 years ago

I'm not sure this discussion is leading anywhere. It will certainly not lead to google changing their legal framework.

rnkn commented 5 years ago

Just trying to find a pragmatic solution/middle-ground.