phreedom_ has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
copumpkin has quit [Read error: Connection reset by peer]
copumpkin has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 244 seconds]
lassulus_ is now known as lassulus
sir_guy_carleton has quit [Quit: WeeChat 2.0]
<infinisil>
I'm gonna go to bed now, but I'll just mention that https://github.com/NixOS/nixpkgs/commit/76a713bd299f was a dependent of cmake, so a whole lot will need to be rebuilt on master, and this probably should've gone to staging instead. No idea if that would be a reason for a revert
<infinisil>
(As a result probably almost all ofborg builds will fail with a timeout)
pie_ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
<teto1>
How would you go about modifying cc-wrapper.sh without having to rebuild everything (just to test changes before merging those back into the original cc-wrapper) ?
Drakonis has quit [Remote host closed the connection]
<peti>
domenkozar: What is going to happen with https://hydra.nixos.org/jobset/nixpkgs/haskell-updates now? We're regularly building thousands of packages that we know won't suceeed. That doesn't seem like a good idea?
vcunat has joined #nixos-dev
aminechikhaoui has quit [Ping timeout: 260 seconds]
<domenkozar>
peti: yeah I've been meaning to take a look at how to generate disabled lines
<peti>
domenkozar: Would you like me to do it?
<domenkozar>
peti: that would be appreciated :)
<peti>
domenkozar: OK. :-)
orivej has joined #nixos-dev
<jtojnar>
pie_: keybinder is gtk2 version, keybinder3 is gtk3 version
<pie_>
jtojnar, ah, didnt see that
<jtojnar>
pie_: though, for some reason keybinder has gtk3 dependency too
<jtojnar>
but the outputs are still different keybinder.pc (gtk2) vs keybinder-3.0.pc (gtk3)
<jtojnar>
pie_: though we should probably merge them into a single expression – the packages should just differ by passing either gtk2 or gtk3
<jtojnar>
pie_: oh, nevermind, the source codes are different too
<Mic92>
He mainly seemed be mainly involved with sage. FRidh might have an opinion on that.
aminechikhaoui has joined #nixos-dev
<domenkozar>
I'd appreciat if we define some guidelines here
<domenkozar>
I'm getting more and more folks asking me for access :)
ekleog has quit [Quit: WeeChat 2.0]
ekleog has joined #nixos-dev
pie_ has quit [Ping timeout: 260 seconds]
Sigyn has quit [Quit: People always have such a hard time believing that robots could do bad things.]
Sigyn has joined #nixos-dev
<thoughtpolice>
Is there any place where discussion of closure size increases should be put up? Discourse?
<thoughtpolice>
Normally, I think it'd be down to "Good intentions/will of the maintainer", and probably wouldn't ask. But this is for PostgreSQL -- and the dependency is LLVM (at runtime) and Clang (at build time). Given postgres is part of the -small channels, this bit of bloat is probably worth discussion?
<thoughtpolice>
(This is regarding the JIT stuff I was muttering about this weekend in here. The good news is, I fixed all of those problems and it's much nicer now. But the bloat is still ~130mb to -> ~410mb, which affects the binary outputs only. Maybe that's not a problem for server-based systems, but the build dependency is a bit large...)
<samueldr>
thoughtpolice: can it be opted-out?
<thoughtpolice>
Yes, everything is controlled by a single conditional currently. Although, I don't think overriding it is very convenient.
<samueldr>
but yeah, I guess the discourse is as good as any place to share your concerns, this and the PR with the changes?
<thoughtpolice>
I didn't really intend for the conditional to be overridden, FWIW. It's more of a useful thing for my branch.
<thoughtpolice>
samueldr: It's tied up in my Postgres branch, for now. But I don't think I'm going to ship the beta expressions as part of that, just leave the actual support in, since it can be discussed separately.
<samueldr>
and it's not as if this was an increase for the base system, it's probably much easier to swallow in that case
<thoughtpolice>
samueldr: Yes, also the actual increase is only about ~300mb, and it doesn't affect any libpq clients, just the literal postgres binaries. I'd guess the actual *build time* dependency is more problematic than the runtime one. Though maybe it wouldn't actually hurt the turnaround on -small, too much.
<thoughtpolice>
LLVM might even be in the closure of the -small channels already, though I'm not sure how to check that easily at the moment...
<Dezgeg>
I think QEMU with graphical support includes mesa somewhere which needs LLVM anyway
<thoughtpolice>
samueldr: But yeah, since this implies a rebuild of Postgres + all extensions it can support, ideally I'd like it to be on-all-the-time to avoid misses for users.
<thoughtpolice>
Dezgeg: ah, good to know. Though, MESA tends to use a fixed version of LLVM, so maybe it would dupe it anyway...
<thoughtpolice>
(Maybe it uses the default `llvmPackages` expression now? I'm not sure)
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
pie_ has joined #nixos-dev
sorear has quit [Ping timeout: 240 seconds]
fpletz has quit [Ping timeout: 240 seconds]
teto1 has quit [Ping timeout: 240 seconds]
Profpatsch has quit [Ping timeout: 240 seconds]
sphalerite has quit [Ping timeout: 240 seconds]
Florian[m] has quit [Ping timeout: 240 seconds]
flokli has quit [Ping timeout: 240 seconds]
fadenb has quit [Ping timeout: 240 seconds]
NinjaTrappeur has quit [Ping timeout: 240 seconds]
sphalerite_ has joined #nixos-dev
<samueldr>
anyone here using `boot.initrd.luks.yubikeySupport`? asking because of a PR potentially touching this code has had no tests for yubikey hardware