<kiwiirc>
with systemd-networkd integration, flakes, etc it looks like nix is solving its big shortcomings. cool that the project isn't standing still
<gchristensen>
we haven't stood still much in 17 years :)
<JJJollyjim>
It's pretty exciting to see everything moving
<JJJollyjim>
Jesus 17 years?
<kiwiirc>
well i really appreciate the honesty to admit shortcomings and with a positive attitude to just make it better
<JJJollyjim>
Nix is only 4 years younger than me
<JJJollyjim>
It feels so new
<kiwiirc>
lots of projects turn hard ego and it just ruins stuff
<gchristensen>
Nix started in March 2003
<JJJollyjim>
But I guess it became a lot more well known recently
<JJJollyjim>
domenkozar: fwiw, the reason I've never considered using cachix is that I live in new zealand where latency is a big deal, and there's no documentation on where stuff is hosted
<JJJollyjim>
(it's not satellite internet or anything, it's just speed of light issues)
<JJJollyjim>
A lot of derivations would be faster to build locally than to check a European server for a narinfo
<JJJollyjim>
(rtt≈350ms)
<gchristensen>
it is hosted in S3 at least
<gchristensen>
but I guess that is too vague
cole-h has quit [Quit: Goodbye]
<JJJollyjim>
Yeah
<JJJollyjim>
s3 guarantees that it won't be Great (within NZ), but it can be Okay (Australia)
<JJJollyjim>
But it could also be Europe at which point it's awful
<JJJollyjim>
New Zealand's internet infrastructure is fantastic, unfortunately Australia's isn't
<JJJollyjim>
So AWS charges extra for bandwidth in AU regions
<JJJollyjim>
Which affects us too
<JJJollyjim>
Azure is the first major cloud provider to announce a region here, but they haven't started building it
<JJJollyjim>
(my former employer also has a really nice 3-region openstack)
FRidh has joined #nixos-dev
alp has joined #nixos-dev
drakonis_ has quit [Ping timeout: 256 seconds]
drakonis_ has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<domenkozar[m]>
Jamie: it's served by cloudflare all around the world, did you do some measurements?
alp has joined #nixos-dev
<JJJollyjim>
nah hadn't tested
<JJJollyjim>
presumably the backing store is still far away though?
<JJJollyjim>
so if i ask about a hash for the first time, cloudflare will ask the backing store?
<JJJollyjim>
(to be clear i'm not a likely high-paying customer and you shouldn't put any effort in to making things better for me :P)
__monty__ has joined #nixos-dev
Jackneill has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
<domenkozar[m]>
well I want to clear up if there are any problems with its access
<domenkozar[m]>
Jamie: yes, cloudflare will ask the backing store and serve that via their backbone, which won't be the same as being in the same region, but should be within reasonable ms
<JJJollyjim>
ah lol didn't think to look in the httpd package
<domenkozar[m]>
there I expect median to be around 300ms, maybe 350ms
<domenkozar[m]>
(according to latency reports between east coast and NZ)
<JJJollyjim>
median 218
<domenkozar[m]>
oh wow that's pretty good
<JJJollyjim>
wildly variable though, 75th percentile is 649
<andi->
note ab doesn't actually do HTTP2
<andi->
I am just trying with h2load
<domenkozar[m]>
yeah luckily that doesn't affect Nix too much
<andi->
Yeah, multiplexing multiple requests through the same H2 connection doesn't seem to make any noteable difference. Comparing 1 request per connection vs 2 right now.
tv has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
kiwiirc was banned on #nixos-dev by gchristensen [*!68c88135@gateway/web/cgi-irc/kiwiirc.com/ip.104.200.129.53]
kiwiirc has left #nixos-dev [requested by gchristensen (kiwiirc)]
<{^_^}>
travis-ci/docs-travis-ci-com#2824 (by domenkozar, 7 seconds ago, open): nix: step down as maintainer
drakonis_ has quit [Ping timeout: 265 seconds]
<Profpatsch>
abathur: we switched to Github actions and I can confirm that they are better than Travis in probably every aspect
<Profpatsch>
easier to set up, easier to configure, better integrated into Github, and faster
<Profpatsch>
where *we* is lorri
<domenkozar[m]>
thanks Profpatsch
spacekookie has quit [Quit: **aggressive swooshing**]
drakonis_ has joined #nixos-dev
spacekookie has joined #nixos-dev
spacekookie has quit [Client Quit]
spacekookie has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<gchristensen>
domenkozar[m]: I have a proposal for something to recommend against in your nix lang doc
<aszlig>
niksnut: i'm currently trying to add nix flake support to vuizvui (https://github.com/openlab-aux/vuizvui), however i'm not sure how flakes should replace channels or let's say the way we're using them in vuizvui...
<aszlig>
niksnut: so what we do in vuizvui is that we run tests based on various machine configurations and provide per-machine channels (built by hydra), so that whenever eg. docker is broken in nixpkgs master, machines without enabled docker will still get a channel upgrade
<aszlig>
how would something like this look like when using flakes?
<aszlig>
some kind of bot that randomly tries to update several flake.lock-files and provides pull requests for each machine, which are in turn built by hydra?
<domenkozar[m]>
gchristensen: great, please open a PR :)
<gchristensen>
aww
<gchristensen>
you don't even want to discuss it...? :P
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
kfound has joined #nixos-dev
kfound has quit [Remote host closed the connection]
<domenkozar[m]>
gchristensen: oh of course I do :)
<niksnut>
aszlig: I keep forgetting that hydra still has a "channels" feature
orivej has quit [Ping timeout: 246 seconds]
<gchristensen>
it is a really good feature!
<aszlig>
niksnut: which is good :-)
<niksnut>
I was tempted to write "channels" "feature" :p
orivej has joined #nixos-dev
<aszlig>
well, otherwise implementing something like vuizvui would be pretty annoying
<gchristensen>
it is a really important feature for a lot of users
<niksnut>
I forgot about the semantics
<niksnut>
doesn't it include the latest succeeded build from a mix of evaluations
<niksnut>
?
<gchristensen>
yeah
<gchristensen>
I think it is possible to say that hydra channels just stay channels
<gchristensen>
and isn't an appropriate use case for flakes
<niksnut>
that sort of thing is pretty incompatible with flakes
<gchristensen>
yeah
<niksnut>
you can't really have a flake depending on the previous state of hydra
<aszlig>
niksnut: well, i know :-D
<aszlig>
but let's say in a flakes-only future, how would you implement something like this?
<domenkozar[m]>
gchristensen: I'm a bit jumping around since I'm packing, but do share thoughts
<niksnut>
I don't understand the use case well enough, but maybe you could have multiple jobsets in the flake (e.g. with or without docker)
<gchristensen>
domenkozar[m]: I think "..." is, largely, a mistake
<domenkozar[m]>
hmm, but wouldn't we have to then offer an alternative for nixos modules?
<gchristensen>
well, maybe not for nixos modules
<gchristensen>
but so many builder functions accept `...` instead of providing a clear API
<aszlig>
niksnut: well, essentially the same applies to nixpkgs as well, but since it's "upstream" it isn't such an issue, since all you need to do is update a branch ref
<aszlig>
like eg. nixos-20.03
<domenkozar[m]>
gchristensen: yeah it's easy to have a chain of functions with a lot of ...
<aszlig>
but for vuizvui it's "that machine configuration with the latest *tested* version of nixpkgs master"
<domenkozar[m]>
and it doesn't catch typos
<gchristensen>
domenkozar[m]: yeah, exactly, and I think the "original sin" is mkDerivation using the main attriibute set scope to set env vars, instead of a clearer API of { environment = { ... }; }
<domenkozar[m]>
gchristensen: sgtm
<gchristensen>
I was helping someone who spent like 3 days to realize a function, deep in a stack of functions, doesn't actually do anything with an argument
orivej has quit [Quit: No Ping reply in 180 seconds.]
<domenkozar[m]>
yeah and nixos could have extra attribute
<gchristensen>
yeah
<gchristensen>
exactly
orivej has joined #nixos-dev
<JJJollyjim>
Aaaaa you are giving me flashbacks to the number of times I have spelt propagatedBuildInputs as propogated
<gchristensen>
that too
<domenkozar[m]>
you can probably make a PR to nixpkgs each month with a number of those
<pie_>
i have an issue somewhere about warning users about mkderivation arguments but idk if any of them were actionable
<pie_>
at least i remember something specifically related to the phases problems
<aszlig>
JJJollyjim: haha, maybe write a linter that calculates the leavensthein distance and warn of such mistakes? :-D
<domenkozar[m]>
we don't even have a page documenting mkDerivation :D
<domenkozar[m]>
how embarrassing is that
<pie_>
what id probably do is write a makeWrapper function that does the wrapping
<gchristensen>
:)
<pie_>
which is anoyher annoyance i have
<pie_>
and then build infra for that off that
<JJJollyjim>
D: ...... :D
<pie_>
because guess what
<domenkozar[m]>
like: here's a whole ecoystem around one function, but read the source luke
<pie_>
you have to add the post and pre phases yourself when youre overriding
<pie_>
havent had any issues caused by that , nope :P
<gchristensen>
domenkozar[m]: look for examples, luke
<gchristensen>
lol
<aszlig>
domenkozar[m]: well, at least the source isn't outdated =)
<pie_>
working on nixpkgs is a big pile of mistakes youve made before and folk knowledge
<domenkozar[m]>
the good news we can fix that
<domenkozar[m]>
is*
<pie_>
right
<domenkozar[m]>
yeah there's too much tacit knowledge
<gchristensen>
domenkozar[m]++ I feel like that is my mantra
<domenkozar[m]>
I'll stop complaining now :D I think it doesn't matter what we think, but what users think
<domenkozar[m]>
and their feedback is consistent
<Valodim>
can confirm
<niksnut>
we're working on UX improvements
<pie_>
ajs124: idk, crosslink it :P
<niksnut>
by improving the nix command and maybe providing an alternative for the nix language that supports discoverability and documentation from the start
<domenkozar[m]>
niksnut: which is great!
<domenkozar[m]>
nice
<ajs124>
pie_: no u
<domenkozar[m]>
I'll meanwhile work on documentation
<LnL>
domenkozar[m]: yeah, there's some other stuff in there but it's basically only usable as reference for (some) of the stdenv attributes
<domenkozar[m]>
just to be explicit, I think everyone is doing an amazing job
<domenkozar[m]>
I'm only dissatisfied with the focus
<domenkozar[m]>
there's too much development on new fancy stuff instead of getting one thing right and working
<domenkozar[m]>
niksnut: I think getting cli out should be the focus
<domenkozar[m]>
then move on to discoverability & such
<domenkozar[m]>
2.4 is going in the other direction with experimental flags
<domenkozar[m]>
(these two are a bit orthogonal, but they do impact users quite a bit)
<domenkozar[m]>
I had a number of companies subscribe to cachix and then cancel as they switched away from Nix
<domenkozar[m]>
"cross compilation documentation was indistinguishable from magic so we used docker"
orivej has quit [Ping timeout: 246 seconds]
<Valodim>
ouch
<domenkozar[m]>
that's as honest as the feedback gets :)
<Valodim>
I'm really excited to see how flakes will affect the landscape
orivej has joined #nixos-dev
<domenkozar[m]>
yeah flakes will be great for a lot of things
<domenkozar[m]>
half of nix.dev will get vastly simplified
<Valodim>
I have some hopes that they solve many of the issues I find myself troubled explaining :)
<domenkozar[m]>
I think we mainly need to limit the scope of what to support
<domenkozar[m]>
and make those parts really good
<domenkozar[m]>
speaking of which, I should finish github actions installer artifact for nix
<pie_>
does anyone other than ericson understand the cross compile infra thoroughly
<pie_>
does _ericson_? i kind of just assume he wrote it all
<niksnut>
domenkozar[m]: btw somebody suggested turning experimental features into a warning rather than a fatal error
<niksnut>
so all that --experimental-features would do is shut up the warnings
<domenkozar[m]>
that's a great idea
<domenkozar[m]>
it delivers the message without crippling the user
joepie91 has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<hexa->
I'm wondering whether the use of meta.maintainers could be improved by informing users when that list is empty for a package they're using
<gilligan>
niksnut: yeah i also think that this sounds like a good suggestion
<hexa->
that might certainly be noisy for some libs, I know, but this would be a way to reach actual users of a package.
<pie_>
might be worth bringing up with the people that are phrasing the stale bot, if it gets anywhee
<pie_>
or well, people on the stale bot issue
<pie_>
i still think a problem is we simply dont have the developer base to keep every package with a maintainer proper, but i have no explicit basis to believe that
tazjin has left #nixos-dev [#nixos-dev]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 258 seconds]
drakonis has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
__monty__ has joined #nixos-dev
drakonis1 has quit [Ping timeout: 258 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<Ericson2314>
niksnut: did you ever consider using libfetchers for fetchurl?
drakonis1 has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 260 seconds]
<Ericson2314>
For the git stuff, I am wishing the narHash field of input was actually std::optional<FixedOutputHash>
<Ericson2314>
so basically would allow something like outputHashRecursive to decide whether to use nar or git tree hashing regardless of whether one pinned a tree hash
<Ericson2314>
but the change would be useful to master even if there was a libfetcher that would take advantage of flat hashing
<Ericson2314>
(whereas now they all fetch trees and use recursive)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<abathur>
domenkozar[m] Profpatsch a few thoughts re: travis-ci; 1. no on sole maintainership for now at least (I'm in "no" mode for a bit).
<abathur>
2. If it's being abandoned by everyone central to Nix, it needs a deprecation notice w/recommendations instead of breaking some day and not getting fixed. It's a bad look given the problems Nix is supposed to solve. It can leave people over a barrel when they're just trying to rush out a fix.
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<gchristensen>
srhb has been +o in a handful of channels for a long time, but I'm planning on extending her +o to all the nix and nixos channels later today. also, I'm planning on making all the channels share a ban list. anyone have thoughts on this?
<abathur>
the linux install became multi-user, if that could cause it
<Mic92>
abathur: thanks that would make sense
cole-h has joined #nixos-dev
<abathur>
I also cut some lines around the creation of the /nix path because installers prior to 2.3 were refusing to install because /nix already existed
<abathur>
(I think, again, because of something the multi-user installer does that single doesn't?)
<abathur>
at least, I don't recall the single user installer objecting to /nix, but I'm not sure I've ever run it with it present
<Mic92>
abathur: yes. in multi-user mode you are not a trusted nix user by default which causes this error.
<samueldr>
I think you should look at the definition of pkgsStatic
<samueldr>
I seem to remember trying to look into it and failing to make it work, but probably because I didn't spend many brain cycles on it
<FRidh>
see stage.nix and static.nix
<infinisil>
I feel like there should be something like pkgs.withStdenv { static = true; musl = true; ... }
<hoverbear>
Hmmm that'd be handy.
<infinisil>
And the pkgsMusl/pkgsStatic/etc. would just be an alias to one of those
<samueldr>
I think it's "kinda like that" but more complex in their definitions
<samueldr>
(going from memory)
<FRidh>
pkgsStatic is mostly just an overlay
<hoverbear>
Oh a withStdenv would be awesome omg
<infinisil>
Oh another related idea: Maybe aliases should not be allowed to be overridden in overlays
<hoverbear>
Okay I feel like armed with the knowledge that pkgsStatic = musl builds I am much more prepared for this challenge
<samueldr>
I'm mildly confused, autoPatchelfHook is failing with `readelf: command not found`
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
ris has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
gilligan has quit [Ping timeout: 260 seconds]
gilligan has joined #nixos-dev
spacekookie has quit [Quit: No Ping reply in 60 seconds.]
spacekookie has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<hoverbear>
Is there a tool to turn a derivation into a tarball simply?
<hoverbear>
I'm thinking like `pkgs.gimmeATarballOfIt pkgs.ripgrep`
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
julm has quit [Quit: migration shorewall -> nftables]
<gchristensen>
hoverbear: the tricky bit is pkgs.ripgrep is not a complete and valid closure, so the value is a bit limited: it depends on libunistring, libidn2, and glibc. so then there is a question as to what such a builder should do with the closure
<gchristensen>
hoverbear: this doesn't apply so much for your build since it is a fully static build with a closure of a single path (you might validate this with nix-store --query --requisites ./your-output-path) but that isn't the general case in Nixpkgs
<hoverbear>
gchristensen So could I package like, it and all it's deps into a tarball?
<hoverbear>
Like it's "closure" I guess is the right word?
<gchristensen>
I was just looking for that, yeah! nix-bunlde can do this in a principled way
<hoverbear>
Hmmm once again it's a non-`nix` file based interm step that I'd have to do outside of a nix build Q_Q
julm has joined #nixos-dev
<hoverbear>
Okay so given that, I need to figure out how to get my nix derivation to have service files etc....
<gchristensen>
I assume it doesn't inherently require that
<qyliss>
You could probably implement this sort of thing as a Nix derivation but I don't know of anybody having done that
<qyliss>
What are you trying to do with this, hoverbear?
<gchristensen>
hoverbear: if it were me, I would create a derivation whose out path looks like a mini FHS, and then `tar` that and call it a day. that means putting the service files in the normal places (other than the surprising prefix which is removed at the tar step)
__monty__ has quit [Quit: leaving]
<hoverbear>
qyliss: I'm packaging and disitributing a binary for a dozen or so platforms
alp has joined #nixos-dev
<hoverbear>
Needs to be rpm/deb/tar.gz as well as mac/windows/freebsd/nixos compatible
<hoverbear>
I was kind of under the impression "turn a nix derivation into a deb/rpm/tarball" was a very solved issue
<samueldr>
oh, for the record, I fixed my missing readelf by using `buildPackages.stdenv` rather than stdenv, as it was to patchelf a binary for the host and not the target
<samueldr>
(hi logs reader from the future!)
<hoverbear>
samueldr! I did the same thing just this morning
<qyliss>
I don't think it's solved at all, unfortunately.
<hoverbear>
Dangit
<qyliss>
It's because of having to package up all your dependencies
<hoverbear>
But nix knows all these?
<gchristensen>
this is because there isn't a principled route from a closure to a clean RPM which can coexist with other RPMs
<qyliss>
It would be a bad experience for a Debian user if they had to install hundreds of Nix packages
<gchristensen>
you would practically need one RPM per store path
<hoverbear>
Hm ok
<hoverbear>
But you said if I had a static binary it's ok?
<gchristensen>
(and then an additional RPM for linking /usr/bin/foo to /nix/store/hash-foo/bin/foo)
<qyliss>
Well then you don't need to install lots of dependencies somehow
<gchristensen>
if you have a static binary you are still providing one RPM per store path, it just so happens that you only have one store path you need to worry about -- and it doesn't refer to anything else, and so it can be relocated elsewhere
<hoverbear>
I'm fine with static packages as long as I can depend on glibc
justanotheruser has quit [Ping timeout: 265 seconds]
<hoverbear>
(We noted a 20% perf different between static glibc and musl)
<qyliss>
depend on glibc where though? the Nix glibc in /nix/store, or the Debian (etc) glibc?
<hoverbear>
The debian one
<hoverbear>
Actually ideally I could depend on any glibc over 2.17 (packaged on centos7)
<hoverbear>
Which is what I get when I just run `cargo build`
<hoverbear>
(From centos7)
<qyliss>
You could patchelf a binary built with Nix, and replace /nix/store/...-glibc-... with /usr/lib/libc.so or whatever it is
<qyliss>
But you'd have no guarantee that would be compatible with your binary.
<qyliss>
(These aren't Nix-specific problems, just ones that are more apparent to us because Nix usually solves them)
<hoverbear>
Can I make nix use glibc 2.17?
<hoverbear>
Because I know all newer glibcs are compatible with it
tokudan has quit [Remote host closed the connection]
<qyliss>
If you package it
<hoverbear>
glibc 2.17 is not packaged?
<qyliss>
I'd be very surprised
<qyliss>
How old is it?
<qyliss>
You might be able to find it packaged from an ancient Nixpkgs and import it
<gchristensen>
so gplv2+ means you can pick gpl3 I think
<hoverbear>
Hmmm
* gchristensen
is not a lawyer and this is not legal advice
<qyliss>
For GNU software it is surprisingly unclear to me from the glibc website what the license is
<gchristensen>
I'd put money on centos getting it right
<qyliss>
LGPL3 should be compatible with asl2
<hoverbear>
So I know from working at the CNCF we were Apache 2.0 and our builds were only linked against glibc and that was because it was basically impossible to statically link it
<qyliss>
It is technically very difficult to statically link glibc
<qyliss>
Which will likely preclude the legalities
<hoverbear>
Hm ok
<qyliss>
I think it's basically not possible
<qyliss>
But you could just provide libc.so in your tarball or whatever
<hoverbear>
So can we talk about how I could use my new fancy nix derivations to build centos/debian packages and tarballs? :)
<hoverbear>
qyliss: Also generally taboo
<qyliss>
It sounds like, given your constraints, the thing to do would be to package your ancient glibc, use it in the stdenv of your Nix derivation, patchelf the binary to use the libc path on the target operating system, and then create your tarball
julm has quit [Quit: migration to hardened profile]
<hoverbear>
Yeah it sounds like it.
<qyliss>
or deb or rpm or whatever
<samueldr>
could the build work against a binary blob of that glibc?
<qyliss>
Yeah you could do that too
<samueldr>
like, pick the centos glibc
<samueldr>
patchelf it (if needed?) for the build
<hoverbear>
I wonder how hard it is to package glibc...
<gchristensen>
what would it be like to build against 2.27 and run against 2.17?
<hoverbear>
gchristensen: It's only forwards compat
<qyliss>
hoverbear: using the CentOS binary as samueldr suggested is probably the way to go
<hoverbear>
This is why we used musl for a long long time
<qyliss>
You could just fetchurl the rpm and pull it out of there
<hoverbear>
Oh yes that'd be nice and slick
<hoverbear>
So I'd need to override the prebuild of my `buildRustPackage`?
<samueldr>
if the intent was to run on nixos, that'd taint the build, but there you're treating it as kind of an "ABI cheat sheet"
<qyliss>
hoverbear: I think you'd actually want to override the stdenv.
justanotheruser has joined #nixos-dev
<qyliss>
Because that's (AIUI) where libc comes from
<hoverbear>
Yeah :S It's a big bummer
<qyliss>
Pretty much all Nix stuff is built around things being Nix all the way down.
<qyliss>
Building packages for "foreign" operating systems using their libraries is sort of contrary to the model, so it's going to be a bit of a struggle. But definitely doable! And probably still nicer than not-Nix, especially once it works.
<samueldr>
qyliss: I would have thought the same, but for Nixpkgs instead of Nix
<samueldr>
Nix is not *that* opinionated compared to Nixpkgs, right?
<qyliss>
Yeah I say "Nix stuff" sort of handwavingly
<samueldr>
:)
<samueldr>
good, checking if I was missing something
<hoverbear>
Yeah I think the glibc problem is the only really big one
<samueldr>
though there's not really a non-Nixpkgs Nix "stdenv"
<hoverbear>
I can do rpm builds etc without nix if I have to
<qyliss>
samueldr: well, you can override the compiler or the linker in stdenv fairly easily
<samueldr>
yeah
<qyliss>
I imagine you could do the same with libc?
<qyliss>
Although there won't be a convenient function like overrideCC for it
julm has joined #nixos-dev
<hoverbear>
I will probably need to wrench my way through this for a few hours ...
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<qyliss>
hoverbear: having looked at it for a few minutes (so I could be way off), what I think you'd want to do is make a stdenv like:
<hoverbear>
Oh wow that's probably about 6 hours of digging for me
<hoverbear>
Thank you
<qyliss>
You'd want to put your custom glibc in there, and try to make it match the nixpkgs glibc package in terms of paths. It'll probably also require some patchelf-ing.
<qyliss>
I hope you write this up if you get it to work
<qyliss>
Then you should be able to override buildRustPackage to use that stdenv
<hoverbear>
I am trying to structure this so you would be able to drop this into any rust project, configure the build deps, and build for any cross target a rust package
<hoverbear>
Trying to read from cargo.toml etc wher eI can etc :)
<{^_^}>
nix#3444 (by yorickvP, 13 weeks ago, open): No GC root to EvalState.baseEnv
<hoverbear>
Oh no :(
<puck>
and in a very reliable way which is the worst part
<hoverbear>
qyliss: Yeah I still have that lego
<puck>
GC was a mistake
<hoverbear>
Agreed
<qyliss>
hoverbear: do you see in pkgs/development/compilers/rust/default.nix, where it takes the stdenv argument?
<hoverbear>
qyliss: Do you want a picture from then? :)
<qyliss>
Oh yeah if you've got one!
<hoverbear>
Oh I didn't look yet Iwas scrolling back to paris lol
<qyliss>
Can you email it to me? That way I'm unlikely to lose it
<qyliss>
hi@alyssa.is
<hoverbear>
Yes of course
<hoverbear>
qyliss: It'll be a gphotos link so you can just download it if you want
<qyliss>
Cool
<qyliss>
So I _think_ if you do stdenv = ... where you override rust in your makeRustPlatform call, that should do it
<qyliss>
But I'm not 100% on that because there's so much indirection
<qyliss>
Although, hmm, that would mean building Rust with your custom libc, which might not work
<hoverbear>
I think that might work...
<hoverbear>
Hmmmm
<qyliss>
Ideally rustPlatform would be overrideable, but it isn't
<hoverbear>
Yeah I'm having mixed feelings about all the rust build helpers
<qyliss>
We might want to make rustPlatform overrideable?
<qyliss>
I think I'd try hacking a lib.makeOverrideable in on line 15 of pkgs/development/compilers/rust/default.nix
<hoverbear>
Ohhh all of these ideas are good
<qyliss>
And then I think you should be able to override the result of makeRustPlatform
<puck>
niksnut: please run all tests with GC_INCREMENTAL=1
<qyliss>
If that works, we can see if we can make that change in Nixpkgs
<puck>
niksnut: err, GC_ENABLE_INCREMENTAL=1
<puck>
basically none of the tests fail
<puck>
basically none of the tests pass*
<abathur>
hit a libc issue with missing symbols building tintin on macOS and this conversation made me wonder if it'll be painfully obvious to anyone what's wrong? :] https://github.com/NixOS/nixpkgs/issues/90273
<{^_^}>
#90273 (by abathur, 1 week ago, open): tintin failing to build on darwin
<hoverbear>
qyliss: Thanks for all these ideas. I need to put this down for a bit though. Been at it all day xD
<puck>
gods my brain is mush right now after debugging a bug in what i thought was my nix code but was instead the garbage collector kicking in
<qyliss>
abathur: I had a quick look at that, and my instinct is that it'll be because Nixpkgs' Darwin stuff usually lags behind a bit
<qyliss>
10.13 is IIRC pretty recent, so we might not have those yet
<qyliss>
I believe it comes down partially to upgrades being hard and partially to Apple being slow with releasing sources?
<qyliss>
hoverbear: well, hope it helps ):
<qyliss>
*:)
<hoverbear>
qyliss: It really does =D I just need to eat nomnomnom
<qyliss>
abathur: It has been a while since I used Darwin though, so my knowledge an that might be outdated
<abathur>
qyliss: I think I noticed, at least from looking for security code a few weeks ago, at least a 6-month lag
<qyliss>
It used to be on the order of years I think
<abathur>
but I don't know how stable that is across different types of code
<qyliss>
Like, I think we'd be a couple of major releases behind?
<abathur>
but I won't pretend to understand if all of the components in that are actually up to date, or how it works, and how the developer tools releases relate