<Ericson2314>
which is contained on that branch of mine, but broken out for clarity
<Ericson2314>
but I've pushed what i did on the meson, will leave you to it and go back to working on my other branches
<p01ar>
aye will do in a sec
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
<p01ar>
Ericson2314, got libstore building
<p01ar>
next up is libfetchers
<Ericson2314>
great!
drakonis has quit [Quit: WeeChat 2.8]
<p01ar>
Ericson2314, have you got libfetchers to compile yet?
<Ericson2314>
compile, though perhaps not link
<Ericson2314>
don't think there was any tricks to it
drakonis has joined #nixos-dev
<p01ar>
getting some werid errors
<p01ar>
lmao the errors are happening inside the c++11 std lib
<p01ar>
erm ok
<p01ar>
sure
<p01ar>
seems legit
<p01ar>
Ericson2314, ok so i rebuilt the build dir and now its fine
<p01ar>
errrrrrrrrm
<p01ar>
riiiiiiiiight
<p01ar>
ninja can you not ple
<p01ar>
ase
<p01ar>
alright thats libfetchers down
bennofs_ has joined #nixos-dev
bennofs has quit [Ping timeout: 258 seconds]
justan0theruser has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
_ris has quit [Ping timeout: 272 seconds]
cole-h has quit [Quit: Goodbye]
_ris has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
justanotheruser 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
<ashkitten>
why doesn't buildPythonApplication set PYTHONPATH?
<ashkitten>
feels strange to need to add a wrapper manually with `--prefix PYTHONPATH : "$PYTHONPATH"`
<ashkitten>
also kinda strange that $PYTHONPATH there has every path duplicated twice
FRidh has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
nix-build has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
__monty__ has joined #nixos-dev
<NinjaTrappeur>
In the NixOS VM tests, is there a particular reason to keep the VM stateDir (/tmp/vm-state-xxx) after a run? I feel like I'm missing some context here.
<JJJollyjim>
So often it'll be run in the nixos sandbox
<JJJollyjim>
* nix sandbox
<NinjaTrappeur>
Not when you try to run the test interactively
<JJJollyjim>
Yes, it should probably be changed imo?
<JJJollyjim>
Or at least a new random directory should be created
<JJJollyjim>
With mktemp or something
<NinjaTrappeur>
Yeah, I started to write a patch before realizing I might be breaking something by missing some context :)
<NinjaTrappeur>
niksnut ^
* srk
got bitten by that recently, its fine but a message/warning like 'Re-using state from /tmp/vm-state' would be nice
<{^_^}>
#90663 (by NinjaTrappeur, 9 seconds ago, open): test-driver.py: randomize VM tmp state dir name
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<jtojnar>
ashkitten IIRC PYTHONPATH is bad
<jtojnar>
and buildPythonApplication does the proper thing for Python executables
<jtojnar>
just not for ELFs
alp has joined #nixos-dev
<urkk>
Is there a way to add a custom env var with wrapCCWith before calling the compiler? I don't see anything similar in nix-support
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<niksnut>
NinjaTrappeur: yes, it's so you can keep state across VM runs
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
alp has quit [Remote host closed the connection]
<NinjaTrappeur>
I am experiencing some issues with this persistant state. I still didn't get the root cause, but most of my systemd services turned out being disabled at the VM boot, regardless of the nixos config applied to this VM test. I lost almost a full day on that particular issue.
<NinjaTrappeur>
Looks like I'm not the only one getting bitten by this.
<NinjaTrappeur>
Which kind of state are we expecting to keep across reboots?
<eyJhb>
niksnut: not the right channel, I am sure. But curious as to how many of the other authors of the authors of paper `NixOS: A Purely Functional Linux Distribution` are still working on NixOS? (Andres and Nicolas)
alp has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<lewo>
NinjaTrappeur: I also wasted a lot of time on this. Based on my experience with NixOS tests, I really think the current behavior should not be the default one.
<Valodim>
planned to have a nixosdevandchill session this evening, perhaps I'll swing by then 8)
<nbp>
around yes, still working on NixOS, not really
<ghuntley>
Valodim: hell yeah
asymmetric has quit [Remote host closed the connection]
asymmetric has joined #nixos-dev
<eyJhb>
Running NixOS then nbp ?
evils has quit [Ping timeout: 246 seconds]
<nbp>
eyJhb: definitely!
<nbp>
My objective was to empower others to do the work for me :P
<eyJhb>
Ahh, I have seen that is quite successfull so far! But I bet you cannot avoid getting your hands dirty as well in these Nix expressions at times :p
asymmetric has quit [Quit: Peace.]
asymmetric has joined #nixos-dev
evils has joined #nixos-dev
<Mic92>
ghuntley: when it is 8 in the internet?
<nbp>
eyJhb: You guessed well … but not anything worth sharing.
<ghuntley>
it's always 8 somewhere on the intrernet Mic92
<Mic92>
ghuntley: yeah, so when is the jitsi nixosdevandchill thing?
rajivr has quit [Quit: Connection closed for inactivity]
<Valodim>
I'd aim for ~three and a half hours from now
<ghuntley>
let's do it for 3 and a half hours from now?
<Valodim>
sounds good!
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
FRidh has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<gchristensen>
domenkozar[m]: do you have useful links for creating a github action for other people to use?
<domenkozar[m]>
other people to use - in what way?
<gchristensen>
like I want to create a github action to run shellcheck on all a project's shell scripts (for example) which somebody could easily add to their project
<gchristensen>
exactly, for publishing an action to the marketplace
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-dev
<gchristensen>
I guess these are the words I was looking for to search for
<gchristensen>
thanks, domenkozar[m]
<domenkozar[m]>
ah yeah, each actions needs to be released to marketplace
FRidh has quit [Quit: Konversation terminated!]
<gchristensen>
I think I might make a lot of them
drakonis_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
<manveru>
niksnut: is there some way to do `nix eval .#nixosConfigurations --expr 'configs: __attrNames configs'` to get the names of nixos configurations? or is `nix eval --json --impure --expr '__attrNames (getFlake (toString ./.)).nixosConfigurations'` the best way?
<domenkozar[m]>
I think all the bots we're building would be better done via github actions
drakonis has quit [Ping timeout: 246 seconds]
cole-h has joined #nixos-dev
<gchristensen>
yeah, then we'd just need to run a worker on powerful enough hw for the big ones
orivej has joined #nixos-dev
<niksnut>
manveru: 'nix flake show' shows the NixOS configurations
<srk>
domenkozar[m]: I feel like it leads to bit too much "vendor" lock-in :(
<manveru>
niksnut: yeah, but no json output :|
<niksnut>
yeah we should add a --json flag
<domenkozar[m]>
srk: vendor lock-in is not an argument on it's own :)
<gchristensen>
right now CI is vendor-locked to ofborg which is vendor-locked to github and a couple of people brave enough to maintain it
<srk>
domenkozar[m]: true, I have few other reasons to be vary of github
<gchristensen>
same
<domenkozar[m]>
yeah, it's much more likely for gchristensen to be a millionare than github doing something really bad to us
<domenkozar[m]>
so having a better vendor locked-in base makes less risk than having to burn out our small team
<domenkozar[m]>
we developers vary of everything, but you have to juggle all the risks
<srk>
yup
<srk>
gchristensen: I'm slowly progressing with hosting platform independent CI built on top of post-receive hooks, queues and nix
drakonis has joined #nixos-dev
<gchristensen>
cool
<domenkozar[m]>
heh, there seems to be a general rule that everyone should write a CI in Nix
<srk>
well it makes stuff way easier :)
drakonis_ has quit [Ping timeout: 260 seconds]
<cransom>
many moons ago, i was at a cloudbees talk where they extolled the virtues of docker in docker in docker to make your CI experience smooth. our jenkins already ran a nix-shell to pull in depends and it looked way less cumbersome.
justanotheruser has quit [Ping timeout: 272 seconds]
<niksnut>
manveru: I've just added a flag to 'nix eval': nix eval nix#checks.x86_64-linux --apply builtins.attrNames
janneke has joined #nixos-dev
<manveru>
niksnut: oh awesome :D
justanotheruser has joined #nixos-dev
<manveru>
really digging flakes so far
<manveru>
only issue i have atm is that nixpkgs-unstable nixFlakes cannot parse the nix flake anymore because of it being version 7... really hope the lock format will stabilize in a bit
<manveru>
but it's also cool that you can just pass `rev=xxx` from the commandline and get a nix that builds fine
<manveru>
and the `nixpkgs.lib.nixosSystem` makes it easy to build a `nixos-rebuild` that can run with any nix version :)
orivej has quit [Quit: No Ping reply in 180 seconds.]
<manveru>
niksnut: what i don't quite understand is why `nixosConfigurations` isn't scoped to a `system` attribute like `devShell` or `packages` is ... given that you always have to pass a system anyway
orivej has joined #nixos-dev
<niksnut>
because a NixOS configuration generally targets a specific system
<manveru>
that is true...
<manveru>
just makes it a bit awkward to specify my overlays twice
<manveru>
which means instead of `getFlake` it's `__getFlake` now
<manveru>
and i'm really not sure i understand the reasoning
<niksnut>
manveru: you shouldn't use __* but builtins.*
<cole-h>
Is `__*` shorthand for `builtins.*`?
<manveru>
cole-h: just open a nix repl and hit tab :)
<manveru>
afaik it's a quirk of the parser... but not sure
<niksnut>
cole-h: the "__" is more a shorthand for "internal" :-)
<cole-h>
Ah, OK. Is it part of the parser (like manveru said) that also puts it in `builtins.*`?
<p01ar>
ayy
alp has joined #nixos-dev
<cole-h>
How much RAM does Nix need to build?
johnny101 has joined #nixos-dev
<manveru>
all of it
<p01ar>
i have 16 did fine on 8
<manveru>
depends on what you want to build :)
<manveru>
building a small NixOS works fine with 2-4GB if i remember right
<cole-h>
I meant Nix itself :P Trying the VM with 4G to see how that goes
<cole-h>
With 1G it got killed at one point
<manveru>
ah :)
aminechikhaoui0 has joined #nixos-dev
<p01ar>
is the current nix build working?
<p01ar>
using the native master branch on arch linux and getting libc errors
<samueldr>
cole-h: disabling the manual build helps for a nixos rebuild
<samueldr>
cole-h: the manual build has to eval all nixos options
<cole-h>
(Note: I am only building Nix-proper, not NixOS or Nixpkgs)
<cole-h>
:P
<cole-h>
Huh
<samueldr>
oh!
<cole-h>
Now THAT is really strange...
adisbladi has joined #nixos-dev
stew_ has joined #nixos-dev
asymmetric_ has joined #nixos-dev
<cole-h>
I was building this in an Arch VM because before I switched to NixOS, I had trouble hacking on Nix because linking to thinks would fail (https://github.com/NixOS/nix/issues/3376) and I wanted to see if I could reproduce
<{^_^}>
nix#3376 (by blitz, 16 weeks ago, open): Build broken in nix-shell due to linker errors
<cole-h>
I can't...
<cole-h>
So it was likely just a crufty system (:
urkk_ has joined #nixos-dev
<p01ar>
its not a linking error
<p01ar>
its a compilation errror
<p01ar>
coming from tuple
<p01ar>
er
cptchaos83_ has joined #nixos-dev
<p01ar>
usr/include/c++/10.1.0/tuple:1691:70: error: no matching function for call to ‘std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, long int, nix::fetchers::Explicit<bool> >::variant(long long unsigned int)’
<samueldr>
the most we can get by with using musl, the better it is, but upstream projects *are* going to be many roadblocks
terrorjack has quit [Ping timeout: 246 seconds]
<samueldr>
building *a* nix-built OS with musl libc is possible, getting *NixOS* built with musl libc, unrealistic, though it would be appreciated I guess
<infinisil>
Can glibc and musl be mixed?
dmj` has quit [Ping timeout: 240 seconds]
<infinisil>
So e.g. have musl by default but use glibc where it's not possible
thoughtpolice has quit [Ping timeout: 265 seconds]
<samueldr>
as long as there is no linking I think, so e.g. you can run pkgsStatic.hello on your libc system
<niksnut>
infinisil: the problem is that then you end up with a *bigger* system closure
<niksnut>
which btw was why we got rid of alt-libcs in our initrd
<domenkozar[m]>
no you don't, since programs compiled with musl are really smaller compared to glibc
<domenkozar[m]>
niksnut: actually linking with musl would save a ton of closure
<niksnut>
since a mix of dietlibc, klibc and statically linked glibc is bigger than 1 dynamically linked glibc
<samueldr>
yes you do if you end up having to bring most of the same closure-but-with-musl with it
<samueldr>
I reduced the mobile nixos closure size by dropping musl
<samueldr>
because I was forced to have glibc anyway
<samueldr>
when you don't mix, I figure that yes, you can have smaller closures
<niksnut>
right
<domenkozar[m]>
samueldr: did you dynamically link using musl?
<domenkozar[m]>
how many packages used musl?
raboof has quit [Ping timeout: 240 seconds]
zimbatm has quit [Ping timeout: 246 seconds]
<domenkozar[m]>
what you said is not enough to judge the size :)
<samueldr>
I don't remember how many, but it was a handful, statically though, but that also implies stripping
chrisaw has quit [Ping timeout: 260 seconds]
<samueldr>
and only ~10% difference in total size, which is 800KiB, but still, in my case it mattered
davidtwco has quit [Ping timeout: 240 seconds]
<domenkozar[m]>
musl static executables are smaller than glibc dynamic ones
<domenkozar[m]>
so at some point it pays off
<samueldr>
I didn't have any success dynamically linking with musl libc
<samueldr>
(but it was probably me not doing it right)
<domenkozar[m]>
well with Nix there's not much point anyway :)
<samueldr>
hm?
<samueldr>
as long as the big deps forcibly rely on glibc, in my limited cases it seems it will not be worth it, but that's it, the balance of it all hinges on being able to have the full stack built with musl libc
raboof has joined #nixos-dev
<domenkozar[m]>
closure size will go down significantly, specially with dead code elimination that you can't do dynamically
<domenkozar[m]>
but it would be interesting what's the impact on a whole system like NixOS
<domenkozar[m]>
when duplicated stuff would still add up
<infinisil>
We might want to introduce a simple switch like `system.useMusl = true`
chrisaw has joined #nixos-dev
<Ericson2314>
is there a way to get the VMs from a VM test?
<domenkozar[m]>
Ericson2314: what for?
<domenkozar[m]>
I had a patch that you can get into VM duing NixOS tests
<Ericson2314>
debugging what I did wrong :D
<domenkozar[m]>
but it was reverted
<Ericson2314>
:(
<domenkozar[m]>
but it works :D
<Ericson2314>
or you mean within the tests at run time?
<samueldr>
domenkozar[m]: I don't think we disagree, but just re-stating the crux of my thoughts: as long as it's a system mixed with glibc, when the goal is to reduce the closure size, it's likely not to matter enough
<domenkozar[m]>
Ericson2314: while the test is running, you just need to put a long sleep in there
justanotheruser has quit [Ping timeout: 258 seconds]
<worldofpeace>
lol, I should've cc'd you
<cole-h>
Jokes aside, good job! Slowly, we shall infect the rest of the software ecosystem >:D
<timokau[m]>
Embrace, extend, strive for excellence!
<jtojnar>
worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 170
rajivr has joined #nixos-dev
<worldofpeace>
thx Jan Tojnar cole-h timokau
<infinisil>
It's a bit unfortunate that there's no standard way in nixpkgs to use Nix files from upstream repos
<infinisil>
yet
<cole-h>
Flakes 🤗
<infinisil>
So, the upstream repos flake could depend on nixpkgs and nixpkgs' flake could depend on upstream/
<infinisil>
?
<worldofpeace>
yep, I told their team about that. I could then just have all the packaging in their repo's
<worldofpeace>
that would be cool with flake
<infinisil>
Neat
<infinisil>
And I guess each side pins the other one
<infinisil>
So upstream pins nixpkgs and nixpkgs pins upstream
<worldofpeace>
kinda like how red hat has alot of their rpm's in upstream repo's, though I'm not sure there function to those aside from integration testing