_0mp changed the topic of #freebsd-nix to: Adding Nix to FreeBSD ports | https://github.com/0mp/freebsd-ports-nix | https://logs.nix.samueldr.com/freebsd-nix
<Ericson2314> qyliss: hi what's up?
<qyliss> Hi!
<Ericson2314> oh i guess that was something from yesterday
<Ericson2314> is someone working on freebsd cross?
<qyliss> I can summarise and save you all the logs reading
<Ericson2314> or just native impure?
<qyliss> I was working on native impure
<qyliss> (although I'd be interesting in expanding to native pure once we get it working a bit more)
<qyliss> I merged the native impure PR the other day, and also fixed Nix so that it can actually build
<Ericson2314> qyliss: oh nice!
<qyliss> but the problem I have encountered is going to cause us problems for FreeBSD in all forms
<Ericson2314> oh it was red but manual merge
<qyliss> yeah
<qyliss> I wish GitHub would recognise a Merges: trailer or something
<qyliss> specifically, Nixpkgs produces the triple x86_64-unknown-freebsd
<qyliss> but the canonical one is e.g. x86_64-unknown-freebsd12.2
<qyliss> because the ABI changes between versions
<Ericson2314> qyliss: oh we had a hack in in there for darwin or something else like that
<qyliss> oh really?
<qyliss> I couldn't figure out how we could possibly make this work without either making builtins.currentSystem include the ABI version, or readFile-ing /etc/os-release
<qyliss> (tbh I feel that builtins.currentSystem should include the ABI version on FreeBSD, although maybe there's a good reason for it not to I haven't thought of)
<Ericson2314> eh i don't see why it shouldn't
<Ericson2314> I am looking for the version hack
<qyliss> me neither, but Nix deliberately removes anything that looks like an ABI version so I figured there must be some motivation
<qyliss> how does ABI versioning work on Darwin? Is it backwards-compatible?
<Ericson2314> i don't really know
<qyliss> the only real problem I have with the ABI version in currentSystem idea is that I'd need to get it past Eelco
<qyliss> whereas in Nixpkgs I suspect we can do whatever we want for FreeBSD and nobody will care
<Ericson2314> OK that right there
<Ericson2314> 0 comments oops
<Ericson2314> but I am pretty sure it is to support arbitrary version junk at the end
<Ericson2314> except it's Matt's fault not mine :D:D
<qyliss> Hmm, so this would work for cases when the config string was manually specified
<qyliss> but not when it's inferred from builtins.currentSystem, right?
<Ericson2314> qyliss: i think the same logic is used either way?
<Ericson2314> that works for the longer `config` or shorter `system`
<qyliss> right, but if the default value of system doesn't have the number, that doesn't help
<qyliss> there's no reasonable way for Nixpkgs to figure it out (even impurely) if Nix doesn't provide it, in the default case
<Ericson2314> qyliss: because the `builtins.currentSystem` thing, right?
<qyliss> yeah
<Ericson2314> I'm just saying add a freebsd case there
<Ericson2314> and then nixpkgs is ready for the nix change
<qyliss> right, you're ahead of me
<Ericson2314> and then Eelco should have fewer reasons to be opposed
<qyliss> I hadn't even thought of what would be required in Nixpkgs
<Ericson2314> if mac minis grew on trees, we should probably do it for darwin too haha
<qyliss> it's also curious to me that we have uname.release, but that it's always null because we have to way to fill it in
<qyliss> I suppose with this we'd be able to fill it in for FreeBSD
<qyliss> (assuming that uname -r always corresponds to the ABI version, which I have not checked)
<Ericson2314> oh i remember some talk of uname stuff
<Ericson2314> didn't realize it landed
<qyliss> ages ago IIRC
<qyliss> that was Matt too
<qyliss> I'm wondering why it's stripped at all
<qyliss> is it just a pragmatic choice, because Mac minis don't grow on trees as you say?
<Ericson2314> i guess so
<Ericson2314> or just having a number made other things more difficult
<Ericson2314> as darwin predates all the lib platform stuff
<qyliss> I guess the alternative would be that we just try to force ahead with an unusual ABI-less FreeBSD triple
<qyliss> because I guess the only reason this is really such a big issue for me right now is that I'm using the system compiler rather than a Nix-built one
<Ericson2314> well, I think it would be nice to do the "right thing"
<Ericson2314> whatever that is
<Ericson2314> for FreeBSD
<qyliss> yeah
<Ericson2314> Darwin is rather more encumbered and a pain to keep up with whatever Apple's latest whim is in any event
<qyliss> my instinct here that is that the right thing is to use the same triple that FreeBSD itself uses
<qyliss> it would be nice to hear from one of the FreeBSD experts in the channel on that point
<Ericson2314> sounds good to me
<qyliss> Ericson2314: I wonder why it strips the GNU ABI version though
<Ericson2314> in any event, I think matching their tools to a fault will keep them happier
<qyliss> consistency? pragmatism again?
<Ericson2314> qyliss: in parse.nix?
<qyliss> no, in the autoconf I linked
<qyliss> it gives gnu0.3 as an example of something that should be stripped, in the comment
<Ericson2314> oh checking
<Ericson2314> ohhh
<Ericson2314> I bet the thought with the configure.ac was "well, the exact OS version might be different at runtime"
<Ericson2314> and I think there is a good argument for that
<qyliss> ahh
<qyliss> yes that's true
<Ericson2314> I might continue to do that, but then have `builtin.currentSystem` to the right impurity at run time
<Ericson2314> anywhere where the ABI is stable enough
<qyliss> can you expand on what you mean by that?
<Ericson2314> and I am pretty sure with FreeBSD it is stable enough for old binaries to continue to work, even if with macOS it might not be
<qyliss> that didn't parse for me and i'm a bit tired-
<qyliss> oh wait I understand I think
<qyliss> you're saying that because rebuilding everything on upgrade is not SOP on FreeBSD, we should not include ABI version at configure time?
<Ericson2314> build time: freebsd -> run time: freebsd14 or whatever
<qyliss> yeah
<Ericson2314> qyliss: not sure what SOP is, but yeah :)
<qyliss> standard operating proceduce
<Ericson2314> ah
<qyliss> hmm, that's a trickier change in Nix but I could probably work it out
<qyliss> we could expand that to Darwin too for correctness, and then strip it off again in Nixpkgs so as not to upset anything
<qyliss> but at that point that's definitely me fantasizing about what I'll be able to get into Nix
<thefloweringash> iiuc, freebsd does generally require rebuilding everything on upgrade: https://docs.freebsd.org/en/books/handbook/updating-upgrading-freebsdupdate.html#freebsdupdate-portsrebuild
<thefloweringash> if I run `pkg info pkg`, I see an explicit abi in the package architecture: "Architecture : FreeBSD:12:amd64"
<_0mp> yes, packages have to be upgraded on major updates, e.g., 12.2->13.0
<_0mp> also, FreeBSD community does its best to guarantee that you can use the same packages when doing an upgrade within a major release, e.g., 12.2->12.3
<_0mp> (we had a couple of problems though with that for some packages with kernel modules: we didn't have enough testing put in place to detect a change in ABI between 12.1->12.2)
<qyliss> okay, thank you for the explanation
<qyliss> I think it's all or nothing for us, since building for FreeBSD 12.2 with an x86_64-unknown-freebsd12 triple would be just as non-standard as building with x86_64-unknown-freebsd
<qyliss> so that still sounds like using x86_64-unknown-freebsd12.2 would be the way to go
<_0mp> I believe you should go for x86_64-unknown-freebsd12 and expect freebsd not to break its promises
bapt has joined #freebsd-nix
<bapt> I heard some people here have question about the ABI ?
<_0mp> \o/ thanks bapt, I'm happy that my call for help was heard :D
<_0mp> logs are available here BTW: https://logs.nix.samueldr.com/freebsd-nix
<bapt> ABI is stable within a major branch: backward compatible
<bapt> the only exception is kernel modules, which is the same issue as on linux so
<bapt> regarding major version is is quite stable as well as long as you don't drop the COMPAT${N-X} option from the kernel
<bapt> meaning a binary built on freebsd 10 runs perfectly on freebsd 13
<bapt> and COMPAT${N-X} option are in by default
<bapt> so my take is it should be x86_64-unknown-freebsd12
<qyliss> okay, thank you
<_0mp> :)))
<qyliss> that causes us a bit of pain, because it means if we bootstrap from FreeBSD's binaries, things will think they're cross-compiling
<qyliss> (because FreeBSD's compiler is x86_64-unknown-freebsd12.2
<qyliss> )
<bapt> ah ;)
<qyliss> but if there's a good reason to go for 12 anyway, we can probably work with it
<qyliss> Why does the FreeBSD compiler use 12.2 and not 12?
<qyliss> Because of kernel modules?
<bapt> history
<qyliss> okay
<qyliss> and you don't think it would be a problem for us to break with that history?
<bapt> but the fact it is name 12.2 does not make a huge difference does it ?
<qyliss> it does, because we if pass -target x86_64-unknown-freebsd12 things will think they're cross-compiling
<qyliss> and then C++ breaks
<qyliss> to work around that we will probably have to build a C++ compiler earlier in the bootstrap process, and just hack around that issue for building our own compiler itself
<bapt> why does C++ breaks ?
<qyliss> Unsure, but I'm guessing it's because it sees that the FreeBSD libc++ is for a different ABI version
<bapt> this is weird
<bapt> in the freebsd ports tree we have a mechanism to build with an external toolchain where the target is x86_64-unknown-freebsd12 and it works just fine
<bapt> including with C++
<bapt> I did that part (long ago) so if I see the errors I can probably give hints
<qyliss> I don't have the time to try it out again right now but can post the errors later
<bapt> sure
<bapt> I ll try to stick here for a while ;)
<_0mp> fantastic! thanks, bapt
<Mic92> What is the current recommendations for CI for freebsd, when it comes to integration into nixpkgs?
<Mic92> I don't think we have funding for machines for this right now, but maybe in future.
<bapt> cirrus-ci works great
<bapt> you can run on any image available on gcp with cirrus-ci
<Mic92> qyliss: one way to bootstrap freebsd, would be to use the nix-community cache (1TB) and cirrus to build at least stdenv.
<Mic92> That would make testing easier.
<Mic92> otherwise there is a hen and egg problem.
<Mic92> There is also a nix community hydra, but I don't think we would have a builder for that right now
<abbe> λ nix-build '<nixpkgs>' -A stdenv => /nix/store/i8hb9c2l6npwk16risy1n3qp3gazsyvn-stdenv-freebsd-boot-3 still builds :)
adisbladis has quit [Quit: ZNC 1.8.2 - https://znc.in]
adisbladis has joined #freebsd-nix