<delroth>
note that the patch actually comes directly from the PHP bug tracker (the report you linked to)... with a trivial s/configure.ac/configure.in/ for 7.1 support
<samueldr>
right, and this is why the patch is local instead of being fetched, right?
<delroth>
for 7.1 yes. for 7.2 you could make it fetched, but it didn't seem worth the trouble and asymmetry
<delroth>
but I can change that if you prefer :)
<samueldr>
ah, no worries there
<delroth>
can I get an ofborg trigger build php71 php72 / test elk owncloud? :)
<samueldr>
on it
<delroth>
ty!
<ekleog>
delroth: looks great, thanks!
<samueldr>
generally, it is preferred to split commits for updates, eg. php71: 7.1.x -> 7.1.y and php72: 7.2.x -> 7.2.y; ofborg will automatically trigger on 'em (once you're a known user to it) https://github.com/NixOS/ofborg
<delroth>
ahh, I kept that from the original PR, I'll keep it in mind for next time
<samueldr>
though, would it be too much (I guess not) to ask to split the darwin fix from the update(s) in multiple commits?
<delroth>
I could, probably
<samueldr>
though, both in one PR is fine
<delroth>
the patches should apply to the old version too
<delroth>
let me give it a shot
<samueldr>
(I mean, one PR updating both php 7.1 and 7.2 in two commits is plenty fine)
<delroth>
oh also I forgot an obsolete comment, I'll fix that at the same time
<zimbatm>
this resonates quite a lot given the recent events
<zimbatm>
(to me)
<gchristensen>
"Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way?" :$
<arianvp>
Speaking of
<arianvp>
How is the proposal proposal proposal going?
<{^_^}>
rfcs#36 (by globin, 4 days ago, open): Improving the RFC process
<arianvp>
Yeh
init_6 has quit [Ping timeout: 250 seconds]
<arianvp>
Cool! I'll have a look
<srhb>
/urlselect
<srhb>
Woops
<gchristensen>
what does that magic trick do?
<srhb>
Show that despite my years I've not learned how to type. (it opens a buffer in the top of my window where I can scroll through recent links and select one to open)
<gchristensen>
neat
<globin>
still have to incorporate most of the discussion though
<arianvp>
What are "flakes"? I saw it pop up in the discussion about the minimal NixOS modules RFC
<bennofs[m]>
namely, that it coerces the locale to UTF-8
<qyliss^work>
Also, how would people feel about me having access to ofborg Darwin builds? I've been fixing a fair bit of Darwin stuff, and it's a little annoying to have OfBorg pass on Linux on my PRs immediately, but then have to wait for some kind soul to come along and repeat those builds for Darwin.
<qyliss^work>
(I'm alyssais on GitHub)
<qyliss^work>
Maybe gchristensen is the person I need to convince here?
<qyliss^work>
I've got incoming work that builds LibreOffice and diffoscope on Darwin too, that might need to go through a few build cycles.
<qyliss^work>
(LibreOffice is building locally for me now but needs some clean up)
<bennofs[m]>
how long does libreoffice build take? I remember i started it once but have up after some days?
<gchristensen>
it is a bit of a challenge, qyliss^work, because of the insufficient sandboxing on macos
<qyliss^work>
Yeah, I understand
<qyliss^work>
bennofs[m]: a long time, but not days
<gchristensen>
I have this dreamy idea of having the macos vm ofborg runs in on my mac reboot after each build... but that is slow
<qyliss^work>
a few hours
<gchristensen>
(it starts with a fresh disk image on each reboot)
<bennofs[m]>
what's the problem with sandboxing on darwin? is it fundamentally hard or just not implemented?
<gchristensen>
we can't turn on the full sandbox because it breaks builds which depend on frameworks on the host, so less sandboxing is implemented by default
<bennofs[m]>
so nix doesn't clear env vars when building?
<LnL>
bennofs[m]: pure builds work, but a significant amount of packages depend on impure stuff so it's not desirable to enable and it's not trivial to fix that
<LnL>
qyliss^work: no objections, feel free to make a pr
<zimbatm>
qyliss^work: would it help if I gave you access to a mac remote builder?
<domenkozar>
anyonek knows if ExecStartPost in systemd is ran before service is considered "active"
<domenkozar>
ah nevermind
<domenkozar>
wrong rabbit hole
pxc has joined #nixos-dev
bennofs[m] has quit [Remote host closed the connection]
roberth has quit [Read error: Connection reset by peer]
dtz has quit [Remote host closed the connection]
florianjacob has quit [Remote host closed the connection]
sphalerit has quit [Write error: Connection reset by peer]
yegortimoshenko has quit [Remote host closed the connection]
timokau[m] has quit [Read error: Connection reset by peer]
thefloweringash has quit [Remote host closed the connection]
Ericson2314 has quit [Read error: Connection reset by peer]
florianjacob has joined #nixos-dev
hedning has quit [Quit: hedning]
hedning has joined #nixos-dev
<qyliss^work>
zimbatm: I have a Mac that's running most of the time anyway, so I'm okay for build capacity (although a machine that can run 24/7 would of course be helpful). The issue I'm currently having is the need for other people to ask for OfBorg builds before PRs can be merged, because PRs don't exactly often get merged without OfBorg having checked them on all three platforms.
Ericson2314 has joined #nixos-dev
roberth has joined #nixos-dev
timokau[m] has joined #nixos-dev
bennofs[m] has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
thefloweringash has joined #nixos-dev
sphalerit has joined #nixos-dev
dtz has joined #nixos-dev
<aminechikhaoui>
niksnut I'm doing a nix build --builders '<builder>' --option cores 32, but I don't think the cores option is being propagated to the build, is there anyway to verify if it's working ?
thefloweringash has quit [Read error: Connection reset by peer]
timokau[m] has quit [Remote host closed the connection]
bennofs[m] has quit [Remote host closed the connection]
florianjacob has quit [Remote host closed the connection]
roberth has quit [Read error: Connection reset by peer]
sphalerit has quit [Read error: Connection reset by peer]
dtz has quit [Remote host closed the connection]
yegortimoshenko has quit [Write error: Connection reset by peer]
Ericson2314 has quit [Read error: Connection reset by peer]
Lisanna has quit [Remote host closed the connection]
<niksnut>
aminechikhaoui: no, I don't think --cores is supposed to be propagated to builders because that's local configuration
<gchristensen>
I'm aware of builds taking a "long time" on packet-epyc-1 and I'll be restarting them in the morning -- I want to give eelco a chance to inspect them first :)
florianjacob has joined #nixos-dev
<aminechikhaoui>
hm ok so I'll need to make that in the nix config of the target machine
thefloweringash has joined #nixos-dev
dtz has joined #nixos-dev
Ericson2314 has joined #nixos-dev
bennofs[m] has joined #nixos-dev
sphalerit has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
roberth has joined #nixos-dev
timokau[m] has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
pie__ has joined #nixos-dev
<tilpner>
Hey, do you think the reaction to a PR exposing nixpkgsFun would be more along "maybe, if you really need it", or "what the hell are you doing, exposing our implementation details"?
<tilpner>
://
<gchristensen>
I think we probably shouldn't ...
<tilpner>
nixpkgs uses it for e.g. pkgsCross
<tilpner>
And now I can't do my own pkgsCross at all, because nixpkgsFun is not exposed
<tilpner>
That does not match other design priorities of nixpkgs, as I've observed them
<gchristensen>
oh, hrm, I'm probably confused
<bennofs[m]>
tilpner: maybe do it like __splicedPackages in splice.nix, expose it with double underscores 🙂
<tilpner>
I guess that's part of the problem, I would prefer it to not be a unstable implementation detail that could change at any time
<tilpner>
The function isn't very interesting, there's not a lot to change about it
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-dev
<worldofpeace>
Is this update better for staging #51140? It will fix a chunk of builds that were failing.
<gchristensen>
500+ is the typical # these days, but we might even ho higher later -- like 1000+
<worldofpeace>
Also asking because lots of python things take the route to staging I've noticed.
<LnL>
I think a bunch of packages should be stripped down a bit, lots of packages have most "features" enabled by default increasing the dependency tree significantly
<gchristensen>
LnL: that is such a complicated thing, starts making sense how debian packages are compiled with tons of stuff and then most of it becomes run-time optional
<qyliss^work>
IIRC it's a pain to use options to packages installed imperatively too, right?
<qyliss^work>
(Although discouraging imperative package use at all is a good thing IMO)
<LnL>
that's part of the problem yes
<LnL>
but rebuilding the world for manpages in 1 package isn't a good thing either
<gchristensen>
yeah
<infinisil>
LnL: I always wanted two separate nixpkgs builds: A minimal one and a full one. Maybe full by default, and the minimal one could be under `pkgs.minimal` (so hydra builds it). We could use a `isMinimal = false;` in toplevel, which packages can then add to their args to condition on it.
<infinisil>
Would probably be too much for hydra though
<LnL>
not sure but eg. minimal for callPackage vs full for nix-env would might already cover most cases
<worldofpeace>
I agree that a conservative chopping of these 'features' where applicable could bring improvement and be actionable.
<LnL>
and also means rebuilding 1 vs many, even if it's not cached
pxc has quit [Quit: WeeChat 2.3]
pie_ has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
hedning has quit [Ping timeout: 252 seconds]
pxc has joined #nixos-dev
hedning has joined #nixos-dev
init_6 has joined #nixos-dev
<ekleog>
*idea* meta.shouldNotBeInstalled = bool | { message = string; } ; that we could set for things that should not be put in environment.systemPackages / installed via nix-env / used in nix-shell, eg. python library derivations, suid applications, etc.
<ekleog>
and nix (or nixos for environment.systemPackages) would yell if trying to install those
<ekleog>
any opinions?
<makefu>
ekleog: libraries can be used without any problems in nix-shell though. additionally it should be possible to discover if a package can be installed by checking the bin/ folder, no?
<infinisil>
makefu: installing doesn't always mean binaries though
<infinisil>
E.g. there's zsh packages which put stuff in /share/zsh/...
<gchristensen>
this is a reaction to fusion8..'s fubar'd system after putting sudo in systemPackages
<samueldr>
would the order of PATH help?
<ekleog>
makefu: good point about libraries, some libraries can be used in nix-shell and not installed (like C libraries)… so I guess we'd need a different setting for nix-shell and nix-env|environment.systemPackages
<samueldr>
except sudo, what is risky to put in systemPackages?
<samueldr>
sudo's case could be helped by not exposing it?
<ekleog>
python libraries, lots of C libraries (not really risky, but it won't work as expected)
<srhb>
Any complaints if I merge this into staging-next? Since it's a bunch of rebuilds I'd like to get it done sooner rather than later, it shouldn't land in master without it: https://github.com/NixOS/nixpkgs/pull/51107
<{^_^}>
#51107 (by srhb, 12 hours ago, open): valgrind: Apply upstream patch for Makefile race in coregrind
<gchristensen>
maybe someone can help fusion8... get sorted? I can't think clearly :/
<LnL>
what's wrong with sudo?
<gchristensen>
they installed sudo with systemPackages and now everything seems fubared
<LnL>
howso?
<gchristensen>
check their messages in #nixos
<LnL>
sudo is in systemPackages by default, or atleast on my system