MichaelRaskin has quit [Ping timeout: 260 seconds]
viric has quit [Read error: Connection reset by peer]
viric has joined #nixos-dev
orivej has joined #nixos-dev
mbrgm has quit [Ping timeout: 276 seconds]
Mic92 has quit [Quit: WeeChat 2.0]
Mic92 has joined #nixos-dev
mbrgm has joined #nixos-dev
orivej has quit [Ping timeout: 255 seconds]
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 255 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
ckauhaus has joined #nixos-dev
<MoreTea>
zimbatm: shlevy: I started that in Go, but would prefer to implement it in Rust. It's IMHO way easier to write systems software in that language.
FRidh has quit [Remote host closed the connection]
FRidh has joined #nixos-dev
romildo has quit [Quit: Leaving]
FRidh has quit [Ping timeout: 248 seconds]
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #nixos-dev
asdasdas has joined #nixos-dev
<asdasdas>
have anyone problem with no languages in kde regional settings?
<gchristensen>
asdasdas: sorry, #nixos is really the place for that sort of question
<asdasdas>
gchristensen: thanks
asdasdas has left #nixos-dev [#nixos-dev]
<gchristensen>
GlennS: is the commit message not sufficient?
<GlennS>
gchristensen: I didn't think so. Do you mean that it is saying the reversion is happening *because* that test needs to happen first?
<gchristensen>
I believe so, yes
<GlennS>
ok
<GlennS>
that makes sense
<GlennS>
just a misreading on my part
<gchristensen>
no worries, and I may not be fully understanding it either. maybe ikwildrpepper is around to help
<Mic92>
python packaging in nixpkgs still sucks.
<Mic92>
You try to fix one package and end up adding 5 new packages and updating 10 other ones. And everything more or less manually.
<gchristensen>
it is very challenging :(
<Mic92>
it even nodejs with is thousands of thousands little packages is easier to handle
<Mic92>
*its
<gchristensen>
only because of the automation that exists, and produces multi-MB files of dependency pins
<Mic92>
There exists several approaches to automate this for python, but we don't use them in nixpkgs.
<contrapumpkin>
niksnut: still trying to come up with a sensible way to test fixed-output derivations with existing building blocks
<contrapumpkin>
if I use a diverted store, then I have to rebuild a bunch of non-fixed dependencies of fixed-output derivations
<contrapumpkin>
I want to be able to say "don't use substitutes on FO derivations, but all the others are fair game"
<yegortimoshenko>
gchristensen: ping
<gchristensen>
hi :) (cc globin )
<yegortimoshenko>
so, first off, i hope you would agree with me including this patch into the tree
<yegortimoshenko>
i've explained my point in detail: any link to it is ephemeral
<yegortimoshenko>
even if i change how i treat the patch, previous nixpkgs versions would break.
<globin>
yegortimoshenko: see my comment on the PR, too
<makefu>
Mic92: i know that feel bro ... tried to update a single derivation, ended up with almost 30 commits for different packages and still not done (*cough*openstack*cough*) problem was that the current policy to update packages also requires to move old pythonPackages derivations to separate folders. i gave up in the end
<copumpkin>
niksnut: hmm, judging by the code I didn't expect it to, but it seems to be substituting with a progress bar in my simple test
<copumpkin>
like I have a stupid nix subcommand that inherits InstallablesCommand
<copumpkin>
and I pass in nixpkgs.rustc and it seems to be downloading rustc
<copumpkin>
oh never mind
<copumpkin>
I had accidentally left a call to `toBuildables` in there oto
<copumpkin>
which does seem to try to build all of them
ckauhaus has quit [Quit: Leaving.]
<niksnut>
hm, that function should be renamed
<copumpkin>
yeah :)
<copumpkin>
niksnut: is there a more elegant way to figure out if a .drv is fixed-output from within nix than grepping for outputHash? :P
<copumpkin>
aha, ->isFixedOutput()
<copumpkin>
is it sensible for me to computeFSClosure on the buildable's drvPath, then readDerivation (which might fail if the closure includes non-drvs)?
<copumpkin>
or is there a way to avoid going through the filesystem so explicitly?
<niksnut>
yeah that's fine
<niksnut>
actually Store::derivationFromPath is better
<copumpkin>
oh
<copumpkin>
is there a better way than try/catch?
<copumpkin>
since some of the paths won't be valid drvs
<copumpkin>
ooh, isDerivation
<copumpkin>
excellent
ma27 has quit [Ping timeout: 256 seconds]
<copumpkin>
niksnut: should bmCheck do something to make the existing store path writeable to the builder?
<copumpkin>
whenever I try to use --check or bmCheck, I get an error about permission denied on the output path
pie___ is now known as pie_
JosW has joined #nixos-dev
JosW has quit [Quit: Konversation terminated!]
stqism has quit [Quit: Like 3 fire emojis lit rn 🔥🔥🔥]