madjar has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
drakonis has joined #nixos-dev
lovesegfault has joined #nixos-dev
drakonis has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.7.1]
cole-h has quit [Quit: WeeChat 2.7.1]
cole-h has joined #nixos-dev
orivej has quit [Ping timeout: 255 seconds]
bhipple has quit [Ping timeout: 272 seconds]
cole-h has quit [Ping timeout: 260 seconds]
_ris has quit [Ping timeout: 246 seconds]
<genesis>
derivation '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' may not be deterministic: output '/nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12' differs
<genesis>
error: build of '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' failed
<genesis>
i'm testing gcc breakage that would be the explanation of jack client not working anymore
<genesis>
i did : nix-build . --check -A samplv1 , i imagine i should have lauch it as root.
<domenkozar[m]>
/run/current-system/sw/bin/vim: /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6: version `GLIBC_2.30' not found (required by /nix/store/2n66ha7fnk87jr0yq6ihnl8czwa7iknw-systemd-243.4-lib/lib/libsystemd.so.0)
<domenkozar[m]>
/run/current-system/sw/bin/vim: /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6: version `GLIBC_2.28' not found (required by /nix/store/2n66ha7fnk87jr0yq6ihnl8czwa7iknw-systemd-243.4-lib/lib/libsystemd.so.0)
<domenkozar[m]>
that doesn't look good
<genesis>
how to really force with nix-build and ignore output differ ? i need to fix instruction to let people try to fix jack client and close bug
<genesis>
some nix-store --delete but i'm not an expert here.
puck has quit [Ping timeout: 272 seconds]
puck has joined #nixos-dev
roberth has quit [Quit: Idle for 30+ days]
<genesis>
i quite fix all jack bugs.
<infinisil>
genesis: remove the `result` symlink (not needed if nix-build was called with --no-out-link), then `nix-store --delete $path-out-pointed-to`
<infinisil>
path-out-pointed-to can be gotten by assigning `out=$(realpath result)` beforehand
<infinisil>
Or with `nix-store -q --binding out $(nix-instantiate -A foo)`
<infinisil>
genesis: Although why would a rebuild of the same derivation suddenly work? Because Nix only gives that output differ error if the same derivation (this means the exact same build steps) produces something different
<infinisil>
If something truly was fixed with some derivation, the build steps would differ
<genesis>
because it links to another libstdc++
<genesis>
i donno
<infinisil>
A libstdc++ outside of /nix/store?
<genesis>
no
<infinisil>
If it's a libstdc++ provided by Nix, the derivation should differ for a different libstdc++
<infinisil>
Oh, I'm not sure what that comment means with "rebuild" exactly, because a rebuild of NixOS by itself shouldn't change much, only an upgrade + rebuild should
<infinisil>
But doing a `nix-build --check` or similar again certainly is not it
<genesis>
i'd change the derivation to force it to build
<genesis>
and build with nix-env, that's why i ask to understand how fix instruction in the wiki to have a real rebuild.
<genesis>
btw i think people have to force update more the rebuild, to have the cache rebuilded package.
<__monty__>
genesis: infinisil is right if something was built with a different gcc version the hashes would most certainly differ.
vcunat has joined #nixos-dev
orivej has joined #nixos-dev
<genesis>
__monty__ : sure and it differs, that the goal :D
<__monty__>
If it differs there can't be a need to delete something from the store.
<genesis>
error: build of '/nix/store/n2anawi4ix9c0fkscqa2jpfvz97sdyny-samplv1-0.9.12.drv' failed <- i think it failed because for the same derivation it produice different output
<__monty__>
Then the derivation's broken, no?
<genesis>
no i rebuild it changing something useless
<__monty__>
What do you mean? If it's the same derivation how can it be different?
<genesis>
but the bug is to mix user and system content, user synth software like samplv1 who have been compiled with different libjack2 will not be able to connect
<genesis>
due to ABI breakage and don't find the right symbol
<__monty__>
Oh, I think I see the problem. If the expression you want to rebuild properly depends on the other expression you changed then it shouldn't result in the same hash.
<genesis>
check is not the right option imao to do that.
<genesis>
so question is still , How_can_I_force_a_rebuild_from_source_even_without_modifying_the_nix_expression.
<jtojnar>
I still do not understand why would you need to force the rebuild
<jtojnar>
If you change libstdc++, you are modifying the expression
<__monty__>
jtojnar: I think the confusion is they believe the expression they want to rebuild is unchanged, because they didn't touch it but only a dependency of it.
<__monty__>
genesis: The problem is the expression you're trying to rebuild is depending on the old version of the dependency you changed rather than the new one.
<jtojnar>
--check is used if the package is bit-for-bit reproducible
<jtojnar>
But it does not matter for regular usage of it is not
<jtojnar>
s/used if/used to check if/
<genesis>
i'm confusing, it seems i'm not able to explain a simple breakage that need recompile jack clients against same gcc toolchain and need no modification in the derivation
<__monty__>
Guess I was wrong then. Sounds like it really is a non-deterministic expression.
<__monty__>
genesis: GCC is an input of expressions, through stdenv, if it changes the derivation *does* change.
<genesis>
i agree with that
<__monty__>
Then why don't you see your claim makes no sense? "no modification in the derivation"
<genesis>
because i speak of the nix expression i guess
<__monty__>
The weird thing is that `--check` tries to compare a build of something to the cached version (afaiu). And you *are* getting different outputs for the same hash. So the expression must be non-deterministic.
<genesis>
it seems to be yes.
<genesis>
i can diff the check directory and cache one to see the diff
<__monty__>
And, afaiu, that could be a problem. Some non-determinism is harmless but it could prevent something from being cacheable.
<genesis>
Files /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12/share/man/man1/samplv1.fr.1.gz and /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12.check/share/man/man1/samplv1.fr.1.gz differ
<genesis>
Files /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12/share/man/man1/samplv1.1.gz and /nix/store/40bvnmm91jycnbj9fyxjibn55n29jhs4-samplv1-0.9.12.check/share/man/man1/samplv1.1.gz differ
<jtojnar>
Well if you change the derivation, the package will get rebuild. Nix does not care whether your touched the expression or not, just what it evaluates to
<__monty__>
jtojnar: Yes, but if the derivation were changed the hashes would differ no? And --check is reporting different output for the same hash?
<jtojnar>
And most non-determinism should not matter, it is often just timestamps in the manual pages
<jtojnar>
Yes, the hashes are computed from the result of the evaluation IIRC
<genesis>
if i don't touch the expression, i've to find how to rebuild it without it takes from cache
<jtojnar>
Well it will always take it from the cache if it evaluates to the same hash
<__monty__>
jtojnar: It sounds to me like the non-determinism matters in this case because with a trivial change to the expression, to change the hash, genesis is saying it works. While the cached version doesn't work.
<genesis>
jtojnar : if stdenv has changed, it shouldn't
<genesis>
no i don't say that __monty__ , i say since i'm not able to rebuild without change the expression, i did change it and so it changed the derivation
<genesis>
and fix the issue.
<jtojnar>
If stdenv has changed, it will evaluate to a different derivation and thus a different hash
<jtojnar>
And will need to be built if the hash is missing from cache
<__monty__>
genesis: Why are you passing `--check` actually?
<genesis>
so mixing different clients /Server compiled against differents libjack2 make them incompatible
<genesis>
i think that's the issue.
<pie_[bnc]>
genesis: oh hi im deliciouslytyped
<genesis>
hi pie_[bnc] :)
<genesis>
i'm still working on pie_[bnc] , i think i get the main issue on jack, and explain why some people have working setup for some stuff and not for other
<__monty__>
genesis: Ok, and how do you expect to fix that problem? You can't force a user to use the system channel.
<pie_[bnc]>
genesis: good luck. it wasnt clear to me from your github comment what the problem is. things need to be compiled with a new version of gcc?
<pie_[bnc]>
hm <__monty__> jtojnar: It sounds to me like the non-determinism matters in this case because with a trivial change to the expression, to change the hash, genesis is saying it works. While the cached version doesn't work.
<pie_[bnc]>
ill have to go back and read the scroll at some point..
<__monty__>
pie_[bnc]: I was mistaken the diff genesis shared shows that it's probably just differing timestamps in manpages.
<genesis>
i say my nixos cache version of a client like zynaddsubfx is not compatible with my jackdbus depending on my own cadence expression
<genesis>
but the nixpkgs zynaddsubfx works
bhipple has joined #nixos-dev
<pie_[bnc]>
I wonder if this stuff works in a build-vm
<pie_[bnc]>
might be possible to make a full repro
<pie_[bnc]>
(probably unnecessary)
evils has quit [Ping timeout: 265 seconds]
<genesis>
i'll update my comment and i think the nixos update will fix things __monty__
<genesis>
since if i understand, all is rebuild against same stuff.
<genesis>
pie_[bnc] : if you have an example of something not working, you can make some test.
bhipple has quit [Remote host closed the connection]
<genesis>
i just tested with yoshimi, same things, it works .
<infinisil>
Idea: Let's enable debugging symbols and coredumps and other debugging things for unstable, allowing easy debugging of all kinds of things. Turned off on stable then
<gchristensen>
could be nice
<jtojnar>
Core dumps are enabled, are not they?
<gchristensen>
one thing about separate debugging symbols is the channel update tooling has to take an explicit step for them afaik, and that tooling is probably not up to the task of all of the packages having separate debug symbols all of a sudden
<infinisil>
Oh, yeah seems to be the case jtojnar
<gchristensen>
yeah coredumps are definitely enabled
<infinisil>
Oh yeah and the IFD experiment above still makes GC collect the I'd D's
<{^_^}>
nix#719 (by wizeman, 4 years ago, open): Nix garbage collects too much
<gchristensen>
I always wanted to have lorri implement this part, but we've not gotten there. the idea of lorri is to experiment with these ideas and implement / backport / improve Nix as much as possible in the end.
<infinisil>
Can somebody with nix permission bits change the title of that issue to e.g. "Nix GC collects derivations used for IFD"?
<infinisil>
gchristensen: Nice, that would be awesome
<gchristensen>
yesterday while playing with my `exactSource` function, I was thinking about differentiating data variables from function variables with camelCase vs. snake_case
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<domenkozar[m]>
haskell all the things!
* domenkozar[m]
ducks
<gchristensen>
I get the impression domenkozar[m]'s Matrix gateway may be delayed :)
<domenkozar[m]>
heh
<gchristensen>
that or I'm not understanding what your Haskell comment was about :x
<domenkozar[m]>
as haskell enforces that naming differentiation
<gchristensen>
ah cool
<gchristensen>
I didn't know that
<domenkozar[m]>
well, only the first char case, but still noone would be Camel_Casing
<gchristensen>
oh you just wait
<gchristensen>
:P
<domenkozar[m]>
there's always someone isn't it :D
<emily>
domenkozar: hm? there's no convention for function vs. non-function typed variables in haskell
<emily>
the function is for types/"meta level things" vs. data, which isn't what gchristensen meant (afaict?)
<emily>
I think gchristensen means some_string, someFunction
<emily>
which personally just seems like a regression to me in a higher-order functional language
<domenkozar[m]>
I understand those inputs as newtypes with a constructor, but then since there are no static types it's hard to compare much
Willi_Butz has quit [Remote host closed the connection]
WilliButz has joined #nixos-dev
<emily>
fair enough
<infinisil>
> isn't = x: ! x
<{^_^}>
isn't defined
<infinisil>
> isn't true
<{^_^}>
false
<infinisil>
> yesn't = select [ false true ]
<{^_^}>
yesn't defined
<infinisil>
> yesn't
<{^_^}>
false
<emily>
;w;
<emily>
i didn't know nix allowed apostrophes too
<gchristensen>
infinisil: no
<infinisil>
gchristensen: Hm you make a point, yesn't isn't just yes or no, it's a quantum state between the two. I shall commence to implement a quantum computer simulation in Nix
<gchristensen>
now you're cooking :D
<infinisil>
:D
<Profpatsch>
gchristensen: do it like all fp programmers that have reached Nirvana and call your functions f g h, your arguments x y z and your type variables a b and c: )
<Profpatsch>
if it’s a list, xs is the way to go :P
<gchristensen>
lol
<emily>
hey the s suffix for lists is a legitimately good convention that I miss in other languages :p
<emily>
at the limit haskell naming conventions turn into a kind of pseudo hungarian notation
<emily>
it's cursed but convenient
<gchristensen>
naming things is an affordance to people anyway
<vcunat>
gchristensen: 20.03-small is stuck for a week but Hydra has been looking fine all the time. Generally, is there a way how I/someone can help with that?
<vcunat>
I poked around https://status.nixos.org/ (grafana, prometheus), but I could find nothing useful for this situation.
<vcunat>
It's nothing that needs an "immediate" fix, I think.
<gchristensen>
there was an issue with the revCount calculation being improper and needing fixing, causing a "back-in-time" issue. I'll take a look in a few minutes -- but I'm hoping it is that?
<vcunat>
But I see this occasionally happening, and it might be nice if there are ways people can help with the more common blockers.
<gchristensen>
it'll take some back-end work, but we can do it!
<emily>
I might take a look at it... I'm a bit allergic to both js ecosystem dev and ANSI terminal codes though
<emily>
the latter from too much experience
<gchristensen>
alas
<gchristensen>
it would be a GREAT improvement.
<emily>
setting up a pty to even get stuff to give you colours can be a bit fussy I think
<gchristensen>
Nix handles that automatically
<gchristensen>
ofborg explicitly strips them out because the log viewer doesn't handle them
<samueldr>
gchristensen: if the bytes are not munged before being sent over the queue, it's probably trivial enough to do
<samueldr>
oh
<gchristensen>
easy enough to fix
<thefloweringash>
samueldr: it’s a minor I’m incompatibility in fetchpatch. You should be able to reproduce by removing the FOD from the store and trying to recreate it with nix-build
<thefloweringash>
Uh, s/I’m //
<thefloweringash>
The hash is still equivalent at the nix layer, so if you build with the base32 hash and then revert to the sri hash it will still be available to build Firefox.
<gchristensen>
that is ... interesting ...
<gchristensen>
maybe, then, nix should internally normalize it
<thefloweringash>
I’m not sure you can. Hmm. It passes through fetchpatch before nix gets a chance to see it.
<gchristensen>
right
<samueldr>
thefloweringash: I never built with the base32 hash... and built using nix-build... though I did build with a 52i0 tofu
<samueldr>
or let me rephrase, I used a base32 tofu hash, nix gave me an SRI hash
<thefloweringash>
I think that’s sufficient to sidestep the issue. FOD builds with hash mismatches produce valid store paths under the correct hash. (Right?)
<gchristensen>
vcunat: updated, thanks
<samueldr>
I think so
<aminechikhaoui>
gchristensen pong
<gchristensen>
aminechikhaoui: I had a question for you, but I think I managed to answer it just acouple minutes ago:) thanks
<samueldr>
what I don't know is which hash representation is used, and why
<aminechikhaoui>
:-)
<vcunat>
gchristensen: thanks :-)
<gchristensen>
thank you, and thank niksnut :)
cole-h has joined #nixos-dev
<thoughtpolice>
Curious, but is there any ETA on Nix 2.4? Wondering if there's anything still planned or if things are just cooking like usual, just wanted to try recursive nix but was just thinking out loud...
drakonis has joined #nixos-dev
ixxie has joined #nixos-dev
psyanticy has joined #nixos-dev
mkg20001 has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 240 seconds]
bennofs[m] has quit [Ping timeout: 240 seconds]
Nyanloutre[m] has quit [Ping timeout: 256 seconds]
dtz has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
mkg20001 has joined #nixos-dev
madjar has quit [Quit: Connection closed for inactivity]
Nyanloutre[m] has joined #nixos-dev
bennofs[m] has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7.1]
vcunat has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-dev
_ris has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
lovesegfault has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
evils has joined #nixos-dev
<cole-h>
Posted this in #nixos, but figured it might be better suited here