justanotheruser has quit [Ping timeout: 240 seconds]
das_j has quit [Remote host closed the connection]
Scriptkiddi1 has quit [Remote host closed the connection]
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
johnny101m has quit [Quit: -a- IRC for Android 2.1.55]
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
drakonis1 has quit [Quit: WeeChat 2.6]
justanotheruser has joined #nixos-dev
phreedom has quit [Ping timeout: 260 seconds]
phreedom has joined #nixos-dev
Taneb has quit [*.net *.split]
fadenb has quit [*.net *.split]
fadenb has joined #nixos-dev
Taneb has joined #nixos-dev
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
sphalerite has quit [Remote host closed the connection]
sphalerite has joined #nixos-dev
sphalerite has quit [Client Quit]
sphalerite has joined #nixos-dev
sphalerite has quit [Client Quit]
sphalerite has joined #nixos-dev
Jackneilll has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
psyanticy has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 276 seconds]
tilpner_ is now known as tilpner
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
__monty__ has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 268 seconds]
drakonis1 has joined #nixos-dev
cjpbirkbeck has joined #nixos-dev
<niksnut>
urgh, I just noticed somebody added jormungandr to nixpkgs
<niksnut>
that's a good example of nixos bloat
<niksnut>
it's not even released upstream yet, so why add it to nixpkgs
<gchristensen>
heh
<gchristensen>
yeah
<niksnut>
also it uses buildRustPackage and anything using buildRustPackage should be banned from Nixpkgs</controversial>
<gchristensen>
agreed
* infinisil
goes to check the module
<infinisil>
Hehe it's gone!
<gchristensen>
poof
<niksnut>
I feel the vast majority of nixos/modules/services should be moved out of the nixpkgs repo
<niksnut>
or at the very least, removed from module-list.nix so it doesn't slow everybody down
<gchristensen>
agreed. I look forward to flakes to reduce the feeling of needing to have it in nixos-core
<infinisil>
Maybe we could have a core modules list and a contrib list. Core contains well supported ones, contrib less refined/important ones
<infinisil>
And only core is included by default
<gchristensen>
of course it makes for a much nastier integration problem
<infinisil>
Tbh I think it's possible to change the module so it doesn't need to load all modules, only requiring changes on the module declaration site
<infinisil>
(Not userfacing)
<infinisil>
I wanna give this a try when I have time
<FRidh>
adisbladis: I am not familiar with those modules, but if it can replace IFD then I think we should definitely do that.
<adisbladis>
FRidh: Go modules is the new-ish package management for Go (the working name was vgo, hence the name vgo2nix)
<adisbladis>
Go modules themselves has nothing to do with IFD
<FRidh>
adisbladis: I meant if it replaces a current solution that was using IFD
<adisbladis>
Oh, and I misspoke, I didn't mean IFD, I mean FOD
<FRidh>
oh
<adisbladis>
buildGoModule is abusing FOD (just like buildRustPackage)
<Taneb>
FOD?
<FRidh>
fixed-output derivation
<Taneb>
Right
<adisbladis>
And TBH I'm really worried about that... I've had issues with go modules producing different hashes on different OSes (in my early experimentation windows produced different hashes)
<gchristensen>
I've had problems with go modules producing different hashes on the same os
<gchristensen>
and same computer
<adisbladis>
:O
<adisbladis>
Impressive
<gchristensen>
much regret
<gchristensen>
do ungrounded cables exist in the eu and uk?
<Taneb>
In the UK, there are cables which have a plastic "ground" pin
<Taneb>
gchristensen: there needs to be a physical pin for earth because a lot of sockets have shutters that only open for line and neutral when the earth pin enteres
<Taneb>
niksnut: I don't know how to replicate that build locally, how do I do an i686-linux build?
<gchristensen>
--system i686-linux
<Taneb>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 171
<Taneb>
Hmm, I'm not getting the error I was expecting to get, "builder for '/nix/store/y2d5zrkg5nsifx11vq8h8dd6jmdiqhqf-remove-references-to.drv' failed due to signal 31 (Bad system call)"
pie_ has joined #nixos-dev
<niksnut>
try nix-build release.nix -A binaryTarball.i686-linux
<niksnut>
I'm not sure --system works
<gchristensen>
ah
<FRidh>
Ericson2314: globin: Hydra now does the bash-no-undef-vars, gcc-9 and structured-attrs branches next to the regular jobs. I don't know how often they get updated but it seems a bit much.
<Ericson2314>
FRidh: Sorry, I will be able to retire the bash-no-unef vars very soon
<Ericson2314>
also FWIW all are manual eval
<FRidh>
okay
<Ericson2314>
FRidh: if you don't mind potentially numerous but easy to fix problems on staging
<Ericson2314>
I can merge round 2 of the set -u stuff right now
<FRidh>
andi-: this is a recurring issue on hydra. Restart the failing job until it works.
<gchristensen>
:(
<gchristensen>
maybe it can be fixed
<andi->
darwin… (╯° °）╯︵ ┻━┻)
<globin>
FRidh: I try to only start bigger evals during ~afternoon/night UTC
<LnL>
the CF thing?
<globin>
FRidh: and gcc9 is nearly done too afaik
<LnL>
I have spent a bunch of time on that and only have a pretty horrible solution right now :/
<gchristensen>
let's patch qemu to just fix the memory access problem
<LnL>
it's not qemu I think
<gchristensen>
yeah but all our macos builds are running in qemu :P
<globin>
FRidh: and feel free to just bump staging/release/unstable etc to top
<andi->
How do I obtain super powers to move staging jobs to the top? I remeber the gcc8 PRs eating all the resources when we wanted to get some security patches released to stable…
<LnL>
gchristensen: I was able to reproduce on hardware
<gchristensen>
andi-: do you have an account?
<andi->
gchristensen: yes
<gchristensen>
I think you can already bump jobs, can you not?
<globin>
andi-: in an eval can you not "actions" -> "bump builds to front of queue"?
<FRidh>
globin: you need additional permissions for that. I can't do that either.
<globin>
hmm interesting I didn't know I had more privileges than other hydra users
<gchristensen>
anyone want to send a PR for that privilege? :)
<gchristensen>
would it be bad to change overlays from `self: super:` to `{self, super}:`?
<gchristensen>
with a backwards-compat shim of course
<qyliss>
why?
<samueldr>
yeah, would it be good to change the overlays from self: super to {self, super}?
<samueldr>
(I can see at least one good reason)
<gchristensen>
what is your good reason, samueldr ? :})
<samueldr>
waiting to see if you have it already in your list :)
<gchristensen>
people have a tough time remembering which comes first (why is super after self?) and so have to look it up constantly. another thing is the names are actually not very good or descriptive of when you'd use one or the other
<qyliss>
I've always found self and super to be quite clear, but maybe I've been doing it wrong all along! Can you share an example?
<samueldr>
yeah, you have the reason
<samueldr>
people get the order wrong
<samueldr>
people _do_ get the order wrong
<gchristensen>
no, I think you're just more in-tune and Nix experienced
<qyliss>
maybe
<gchristensen>
but it hurts to sit with people who struggle through overlays because of these two things
<qyliss>
Yeah
<qyliss>
I guess one thing you'd lose is ability to destructure, which I've never done but could see happening
<qyliss>
You can't have nested destructuring, right?
<gchristensen>
not sure, sounds spooky to do that anyway :P
<qyliss>
I always do overrideAttrs in that style
<qyliss>
I find it much nicer than having to write oldAttrs everywhere
<gchristensen>
nice
<gchristensen>
good tip
<qyliss>
Have thought about PRing to change the docs for that
<qyliss>
Because it's how I teach people to do it as well
<qyliss>
It also lets you set default values all in one place
<FRidh>
I think it was agreed already that the naming is unfortunate, and that can easily be changed. Going to { .. } is going to cause trouble, because people might then use `{ self, super, foo ? "bar" }: ` where foo may actually come from super/self
<samueldr>
sadly, "overlayFullyApplied" is not really friendly to use, but I think describes it well enough to understand why it fails
<FRidh>
pkgs: previous: I think pkgs' is nice if we start considering subsets and want to move to the left. So, e.g. in pythonPackages pkgs'.openssl would correspond to the current pkgs.openssl
<globin>
samueldr: is that slang for other and own? ;)
<qyliss>
I wonder if we just need a better way of explaining self and super? I think they're quite good names once you understand what the overlay is doing.
<globin>
sry was just joking :|
<gchristensen>
lol
<samueldr>
globin: was thinking you were, but didn't know for sure if you missed the explanation :)
<qyliss>
It maps to a model of inheritance that people might well already be familiar with.
justanotheruser has quit [Ping timeout: 240 seconds]
<gchristensen>
qyliss: final and parent?
<qyliss>
It's not really "final" if this overlay is the middle one
<gchristensen>
yeah but self refers to the final version I think
<FRidh>
yes
<qyliss>
oh it does?
<qyliss>
well there you go
<samueldr>
ooh, I like final
<gchristensen>
bingo
<qyliss>
told you i'd been doing it wrong all along :P
<samueldr>
s/parent/previous ?
* gchristensen
closes the java book
<qyliss>
I like final, then
<qyliss>
Much better name than self
<gchristensen>
what does java usle to refer to the parent implementation?
<qyliss>
super
<samueldr>
not necessarily parent in a hierarchical sense
<gchristensen>
crap
<qyliss>
I like super
<samueldr>
super isn't bad
<qyliss>
final: super: could work
<qyliss>
maybe?
<Taneb>
final: current: ?
<infinisil>
last: supper:
<gchristensen>
lol
<samueldr>
Taneb: current: doesn't include the *current* overlay
<qyliss>
Taneb: current would imply the overlay you're currently defining is included
<Taneb>
Hmm, I suppose
<samueldr>
(and can't be `current: super: ` since it would also include all the other overlays, so not current either)
<qyliss>
final: outer: ?
<qyliss>
actually i'm confused already by that one
<gchristensen>
maybe super is the best choice
<qyliss>
I think it might be
<gchristensen>
cool, done, let's do it
<gchristensen>
:P
<samueldr>
probably; superset of overlays already applied
<Taneb>
I don't really like having one time based (final) and one heirarchy based (super)
<infinisil>
final can also considered hierarchy based
<infinisil>
Like final class
<samueldr>
>> coming at the end of a series.
<Taneb>
I also don't like Java :P
<qyliss>
Yeah final isn't time based, it's sequence based
<adisbladis>
I sort of like `pkgs: super: `
<qyliss>
But super is also a pkgs
<adisbladis>
Yes, but a "special" one
<qyliss>
I think I'd expect pkgs to refer to unmodified nixpkgs, if anything
<adisbladis>
Ok, fair enough :)
<infinisil>
How about pkgs: recursionBreaker:
<gchristensen>
hehehe
<FRidh>
ha
<adisbladis>
`pkgs: reReReReReRecursionBreaker:`
<adisbladis>
Moar memes
<qyliss>
We could all try out final: super: when teaching people for a bit
<qyliss>
And report back
<gchristensen>
I'm asking some people now
<qyliss>
fixpoint: accumulator:
<qyliss>
:P
<gchristensen>
normalBrain: galaxyBrain
<qyliss>
that should be the other way round, surely? :P
<adisbladis>
qyliss: Yay, explaining fixpoints :P
<qyliss>
nixpkgs is normal brain, the awesome stuff i'm adding is galaxy brain
<adisbladis>
qyliss: The meme is often in reverse :)
<gchristensen>
ah yes the thicc version of perfect
<gchristensen>
I need to stop twitter :')
<adisbladis>
protec: atacc:
<infinisil>
I think we're getting somewhere!
<gchristensen>
okay so I see the point about using foo: bar: style functions, in means we can have way more fun confusing our team mates
<infinisil>
Let's write a nixfuscator that replaces all variable names with random gibberish
<gchristensen>
preferrably in such a way thta mkaes no change to hashes
<infinisil>
Let's compress nixpkgs for distribution with this hehe
<infinisil>
Like the javascript minimizer stuff
<Taneb>
Hmm, if we can implement Lempel-Ziv or something in Nix...
asymmetric has quit [Ping timeout: 240 seconds]
<gchristensen>
don't give infinisil ideas, Taneb
* infinisil
looks up Lempel-Ziv
justanotheruser has joined #nixos-dev
<Taneb>
>:3
<infinisil>
How about replaxing nixpkgs default.nix with an IFD from a derivation that unpacks a targz next to it containing the compressed rest of nixpkgs :P
<Taneb>
infinisil: I was trying to avoid the IFD by implementing gzip in nix
<infinisil>
Ohh!
<qyliss>
It occurred to me recently that a sufficiently evil person could build a proprietary package set, where they only shared drvs, and an attribute set that imported them
<gchristensen>
have you seen the channel hydra can produce, qyliss?
<qyliss>
no?
<infinisil>
qyliss: How would that work?
<qyliss>
infinisil: Not sure what you mean. I compile all my packages to drvs, and distribute just the derivations.
<gchristensen>
it is bogus derivations with outPath set (iirc) so you get no expressions
<infinisil>
qyliss: But how could the nix attrset look like? Because i don't know of a way to create derivations from paths directly
<qyliss>
infinisil: you wouldn't need to create them? you'd have created them through nix-instantiate
<infinisil>
How can nix code import this though?
<qyliss>
IFD
<gchristensen>
nix can import a drv
<infinisil>
Wait so the drv would contain the nix code to build the things?
<gchristensen>
but you don't need to share a drv to distribute a proprietary package set
<qyliss>
infinisil: no, the drv would be a drv
<qyliss>
a normal one
<infinisil>
Then why ifd? Ifd is to evaluate nix code from drvs
<qyliss>
not necessarily
* infinisil
doesn't get it
<gchristensen>
for qyliss's original concept, no need for drvs. I know of some people using import of `.drv` files to get easy access to nixpkgs packages without evaluating nixpkgs
<infinisil>
Huh so just `foo = import /nix/store/....drv;` works?
<gchristensen>
yeah
<infinisil>
Ahh i see, didn't know that
<infinisil>
Wondering if this can be called ifd though, because usually ifd means importing from a derivation result, whereas this rather importing a derivation itself