kratos: Doesn't build on FreeBSD

I overreacted (and am sorry for that) because I found the tone very rude and the points made are incorrect, clearly indicating that the poster has no idea how the software works. I have reverted the actions and am looking forward to useful and constructive ideas to resolve build issues on FreeBSD. Please be nice in open source projects, this project in particular is only maintained by me and I have little patience for trolls.

Regardless of the fact that this is some Docker module:

../../go/pkg/mod/github.com/ory/dockertest/v3@v3.6.5/docker/pkg/system/mknod.go:12:19: cannot use dev (type int) as type uint64 in argument to unix.Mknod

and it should be skipped for non-Linux in most cases the underlying C/OS call isn’t portable because the struct you are trying to read has either different types or members.

Definition of dev_t on FreeBSD: https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/sys/sys/_types.h#L113: uint64_t Definiton of dev_t on Linux: https://elixir.bootlin.com/linux/latest/source/include/linux/types.h#L13: uint32_t. Well, this isn’t going to work.

Here: https://github.com/ory/dockertest/blob/44efd604a6887f5f132e2f076307f3a1ddf471ff/docker/pkg/system/mknod.go#L11-L13

You like need to take the largest available type here. I don’t know how platform-specific code is done in Go, obviously not ifdefs. BUT since this is dockertest it does not make any sense to port it since Docker a whole uses Linux-only features. It should be skipped in the build by OS detection.

Note: I have never written Go, but ported many OSS to FreeBSD and HP-UX, found many non-portable pitfalls down the road.

If you felt in any way offended by my words I’d like to point out that this for sure was not my intention, so sorry for that.

Apology accepted, I hope you accept mine too 😃 My remarks were out of line and indeed unprofessional.

The bug is most likely resolvable via:

1. Identifying the dependency causing the build issue on FreeBSD
2. Updating the dependency using go mod replace if there is a fix for the dependency available
3. If not make a PR at the dependency resolving the issue
4. If none of the above are an option, write a replacement for said dependency

As stated before, due to the way we bootstrap tests for easy consumption, it is not possible nor desirable to strip Dockertest from the project.

And as with all open source project, collaboration is key! If this is a problem you encounter, you’re in the best position to fix it! Maintainers including myself are happy to help wherever possible

There are two ways to look at it: You are doing a good job, but we can make it better OR you are doing a shifty job, why can’t you do it right? I prefer to interpret @joh-ku’s comment explicitly as the former.

Personally for me as a developer I feel great when I know that my code runs on many platforms identically and makes millions happy. PS: I am biased because I do Maven releases and the above is true.

I overreacted (and am sorry for that) because I found the tone very rude and the points made are incorrect, clearly indicating that the poster has no idea how the software works. I have reverted the actions and am looking forward to useful and constructive ideas to resolve build issues on FreeBSD. Please be nice in open source projects, this project in particular is only maintained by me and I have little patience for trolls.

Reacting properly to harsh criticism is a virtue. Hard to achieve, granted.