ehmry changed the topic of #nixos-exotic to: NixOS exotic platforms channel | https://github.com/NixOS/nixpkgs/labels/6.topic%3A%20exotic | https://github.com/nix-community/redoxpkgs | https://git.sr.ht/~ehmry/sigil | Keep NixOS weird
simpson has joined #nixos-exotic
drakonis has joined #nixos-exotic
<drakonis> woah there.
<sterni> qyliss: what is your vision for native netbsd? I was wondering if it may be worth a try using the always cross-compile approach for the new native compilation targets we plan on introducing
<qyliss> sterni: my only vision is that it works
<sterni> fair enough
<qyliss> I'm in favour of always cross-compiling, but I do worry a little that if NetBSD is the only thing that uses it, that'll make people feel unhappy about NetBSD support overall when things don't work
<sterni> yeah that is a good question
<sterni> I was wondering if we could save ourselves work if we just had a minimal native stdenv for bootstrapping the cross stdenv
<sterni> and it would certainly be an interesting experiment
<sterni> but of course bad if stuff breaks exclusively because of cross
<qyliss> hmm, not sure what you mean by that
<sterni> basically bootstrapping the cross stdenv netbsd → netbsd directly using a minimal impure native stdenv
<sterni> although spelling this out — it sounds kind of fragile
<simpson> Unrelated topic, now that I know this exists: Has anybody set up the "devkitPro" patches for GCC? These are "devkitARM", "devkitPPC", etc. They're used for cross-compiling to game consoles.
<drakonis> its commendable that they exist, but how long would they last?
<drakonis> hasnt it bitrotted out of existence because nobody actually bothered maintaining it?
<sterni> also a lot of stuff assumes it has a pure stdenv
<qyliss> *an old
<sterni> I mean as long as it can build the pure cross stdenv we should be fine
<drakonis> this is the running risk with any of the exotic targets
<qyliss> so once the base system changes, everything is broken forever, unless you can reproduce and old impure system
<qyliss> sterni: yeah, impure native stdenv is the reason illumos/BSD support has bitrotted out of existence in Nixpkgs
<simpson> drakonis: I fear that the answer is currently down to whether it's needed to keep niksnut's work unblocked, plus a few other folks who have the time and energy to contribute.
<qyliss> yeah that too
<qyliss> drakonis: the impure stdenv was definitely a big factor, because it means you can't even go back in git history and find a version that used to work
<drakonis> i see
<sterni> but I fear that having an impure starting point for bootstrapping arbitrary cross stdenvs is a bit much too ask or too fragile
<Ericson2314> qyliss: just FYI there was a #debian-kbsd channel that was mildly helpful before
<Ericson2314> I should have checked first :D
<qyliss> the only reason anything is even happening now is that I noticed by chance that we had a broken NetBSD libc package that was intended to be cross-compiled, and so I could therefore go back to an old Nixpkgs and reproduce it, and then work from there to bring it up to date so that it would build again
<sterni> cmake doesn't even eval for example
<qyliss> if I could have reproduced a working but old Nixpkgs, I could have gone forward with other UNIX support then, and I could be years ahead with other UNIX support in Nixpkgs
<qyliss> not really
<qyliss> I'm in it!
<sterni> but not much after that
<drakonis> spurious usage of linux compatibility on both would help with this
<sterni> I think you can probably build hello on freebsd nowadays maybe
<simpson> samueldr's homelab, gchristiansen's homelab. My homelab, although I don't have anything outstanding to contribute ATM.
<qyliss> I tried many times to run old Nixpkgs on illumos and FreeBSD over the past couple of years, and failed because I couldn't provide the base system they were expecting
<drakonis> to some degree of course.
<qyliss> correct
<drakonis> i see.
<Ericson2314> oh :)
<drakonis> i've never struck me as long lived projects
<drakonis> which is 6 yeares now
<Ericson2314> not sure
<drakonis> it hasnt been available since debian 8
<qyliss> if you wanted Debian you'd run Debian
<drakonis> they've never struck me
<drakonis> yes
<Ericson2314> I think the debian one still exists?
<drakonis> rather
<qyliss> I think the problem with them is that if you're using BSD, it's because you like BSD
<qyliss> not to the same extent it did, at least
<drakonis> i'm generally curious about the lifetime of those projects to bring linux distributions to other platforms
<qyliss> but there are BSD users interested in Nix, the package manager
<drakonis> that's the whole long term issue at play
<qyliss> (it does seem like there are a few people interested in that)
<drakonis> yes indeed
<drakonis> simpson: :thejoke:
<drakonis> they're very conservative about a significant number of things and it has hurt them quite a lot on various fronts
<Ericson2314> yeah i am very much hoping nix can appeal to the BSD user's desire of integration while avoiding their general conservatism
<qyliss> if we wanted to do a full NixOS port on BSD, the interest would have to largely come from NixOS users who wanted to use a different kernel, rather than BSD users who wanted to use NixOS but couldn't leave behind the kernel
<drakonis> _0mp is the person that was leading the charge
<qyliss> NixOS on BSD feels like a very pie in the sky idea to me, but people are asking every few days about when they can use Nix on BSD
<drakonis> that'd be a good way to do it
<qyliss> I doubt there are BSD users interested in apt
<drakonis> they dragged their feet on accepting prebuilt packages and a package manager
<drakonis> probably not
<simpson> The BSD folks have told me for years that I can bring my own ports tree to their kernels and it'll be a smooth integration. nixpkgs is a ports tree, right~
<drakonis> every few days? interesting
<drakonis> it is indeed a very pie in the sky idea because a lot of packages on nixpkgs don't really consider the existence of bsds
Raito_Bezarius has quit [*.net *.split]
<drakonis> so a lot of work would have to be done to actually insert it in there
<drakonis> ah shit i see its that time of the day where matrix users get netsplis
<drakonis> netsplits now
<qyliss> no, I think Nixpkgs on BSD support is realistic too
<drakonis> its realistic with effort
<drakonis> but you should check the ports tree
<drakonis> there's quite a lot of patches there that would have to be used
<simpson> A lot of nixpkgs *does* have preliminary "oh, we support both kernels, Linux *and* BSD" sort of support, mostly because of our Darwin support.
<drakonis> and a lot of package marking as available
<qyliss> its *NixOS* that feels like ports would have little chance of living long to me
<drakonis> yes
<drakonis> and the churn in nixpkgs that would bring the pain
<drakonis> as well as supporting their init
<qyliss> drakonis: for this to work at all I think we'd be using https://github.com/InitWare/InitWare
<qyliss> I don't foresee that there'd be significant churn in Nixpkgs to make packages work on BSD
<qyliss> will it ever be a tier 1 platform? probably not. but I think we can confidently say we can get to tier 3.
<sterni> potentially bsd could be the alternative platform to test which is not darwin
<drakonis> it shouldnt ever block hydra though
aaronjanse has joined #nixos-exotic
Raito_Bezarius has joined #nixos-exotic
<sterni> and testing bsd is considerably more attainable than darwin for the average contributor
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #nixos-exotic
<qyliss> drakonis: "ever" is a bit of a strange thing to say
<drakonis> i'd like to point out that darwin is highly distant from bsd nowadays
<drakonis> hmm i see
<drakonis> i suppose it might be a strange thing to say
<qyliss> IME fixing packages for FreeBSD often fixes them for Darwin
<qyliss> the POSIX bits of Darwin are still extremely similar to FreeBSD, because Apple has no reason to change them
<qyliss> their users aren't interested in it, and when they introduce new functionality they do it through Objective C APIs rather than changing the C API
<drakonis> i see
<drakonis> btw, initware looks like something from the gaping maw of hell
<qyliss> mostly the differences are that certain APIs will just be randomly broken on Darwin because Apple doesn't care
<drakonis> i see
aaronjanse has quit [Ping timeout: 276 seconds]
<sterni> idk initware seems like a good idea (as in addressing the main criticism of systemd
<simpson> drakonis: https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md The tier design lets us not worry about how high we get in terms of support.
<drakonis> it is impressive that the netbsd folks achieved it
<qyliss> it's just one person, and I don't think they're particularly affiliated with NetBSD beyond being a user.
<simpson> Like, to block Hydra, *first* we'd have to have enough stuff working so that Hydra could plausibly build us.
<drakonis> i see
<qyliss> yeah, I'm not aiming any higher than tier 3
<drakonis> ah okay
<drakonis> that's fair
<drakonis> i forgot about the rfc
<ehmry> I've played a bit with evaluating the nixos modules for non-linux, and I don't think it would be difficult or unwelcome to make the kernel specific stuff conditional, but there would have to be changes everywhere to expose the configuration files to different init systems
<simpson> No worries, I forget too. It's so good.
<qyliss> NetBSD isn't actually currently on that list at all, but I'd say it's
<qyliss> tier 4-5 at the moment, and will be solidly tier 4 once we fix the dynamic linker path issue
<drakonis> i've been busy with work and exploring other exotic things
<qyliss> ehmry: not with initware! :P
<ehmry> yea, I would like to try it, but for now I want to spend time getting some mirageOS working
<drakonis> ohoho
<ehmry> qyliss: yea, if that works then we could make a suckless linux nixos?
<drakonis> slnos???
<drakonis> suckless church of nixos???
<qyliss> I think that name is taken
<drakonis> this place isnt logged, is it?
<qyliss> it is logged
<drakonis> i see
<drakonis> yeah found it
<ehmry> > !false
<ehmry> ok, just samuel's bot
<sterni> ehmry: have you invested any time into mirage-solo5 so far? I haven't been too motivated
<sterni> in hindsight I should've started with that because I never even had the ability to test the mirage-xen stuff so far
<ehmry> I started a mirage project that I intended to run in solo5, so I'm motivated to make it work …someday
<ehmry> mirage xen will go away eventually
<ehmry> I think they are going to move to a higher host abstraction that will take care of xen for them
Ericson2314 has joined #nixos-exotic
<ehmry> FWIF the mirage developers are cubes or freebsd users
<ehmry> *FWIW, my spelling is bad
Yakulu[m] has joined #nixos-exotic
julianst[m] has joined #nixos-exotic
thefloweringash has joined #nixos-exotic
dckc[m] has joined #nixos-exotic
<drakonis> the mirage developers are ocaml developers actually
<drakonis> there isn't much of a crossover between freebsd and mirage other than it being used as a teaching tool in cambridge
<ehmry> well hopefully this IFD RFC will make it easier to deal with ocaml
julianst[m] has quit [Ping timeout: 245 seconds]
Ericson2314 has quit [Ping timeout: 245 seconds]
thefloweringash has quit [Ping timeout: 258 seconds]
Yakulu[m] has quit [Ping timeout: 258 seconds]
dckc[m] has quit [Ping timeout: 276 seconds]
<ehmry> there is an ocaml package with a builder that only runs `ls /usr/include/linux/stddef.h` so that you can depend on linux headers being present
<ehmry> (IFD doesn't fix that though)
aaronjanse has joined #nixos-exotic
julianst[m] has joined #nixos-exotic
Ericson2314 has joined #nixos-exotic
Yakulu[m] has joined #nixos-exotic
thefloweringash has joined #nixos-exotic
<Ericson2314> :)
dckc[m] has joined #nixos-exotic
<Ericson2314> https://github.com/NixOS/nixpkgs/pull/122655 here's me making shallow changes all over the place if anyone wants to review :D
<sterni> have you seen https://github.com/NixOS/nixpkgs/pull/120790 it was in the same spirit but with a smaller scope ofc
<sterni> oh no I have to rebase it
<sterni> it seems
<Ericson2314> sterni: will take a look
<Ericson2314> sterni: oh yeah that's good
<Ericson2314> quite independent, perhaps
<Ericson2314> I was trying to just remove "silly differences" not make meaningful changes in the last one.
<Ericson2314> sterni: I'll rebase it
<Ericson2314> I think I told you to wait with my earlier output ones
<Ericson2314> and then forgot
<Ericson2314> oops