* cransom
double takes when he sees foreman in the wild with no ruby.
<samueldr>
there's ruby
<samueldr>
right there
<samueldr>
in foreman
<samueldr>
to be frank, I never have used foreman beforehand (didn't have a need to) but was reminded of its existence and thought it fitted the bill for starting and stopping services together
<samueldr>
and it is *hard* to search for such tools as the terms are too generic
<samueldr>
ah, hopefully this works on macOS, but it is untested
eadwu has quit [Quit: WeeChat 2.3]
pie__ has joined #nixos-dev
lassulus_ has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.3]
lassulus has quit [Ping timeout: 246 seconds]
lassulus_ is now known as lassulus
pie___ has quit [Ping timeout: 240 seconds]
<clever>
domenkozar: is your haskell NAR implementation on github?
<clever>
domenkozar: parsing a nar stream into a tree, which i just remembered is already implemented in narfuse
<domenkozar>
that's in hnix-store-core
<clever>
domenkozar: thanks
<domenkozar>
yw
bgamari has quit [Ping timeout: 252 seconds]
aminechi1haoui has joined #nixos-dev
MP2E has quit [Remote host closed the connection]
<arianvp>
Is there any information about the NixOS cache and how it's hosted and maintained?
<arianvp>
Like, I wonder if any integrity checks ever get run on it. And how often
<arianvp>
There must be _some_ bitrot in those 10 years of builds
__Sander__ has joined #nixos-dev
hpoussin has joined #nixos-dev
init_6 has joined #nixos-dev
<LnL>
s3 takes care of that
<gchristensen>
arianvp: is that a sufficient answer?
<LnL>
objects are stored with parity on the backed and should get repaired by the service
<gchristensen>
with 11 9's of durability
<hpoussin>
hello, i'm trying to send a patch (git format-patch + git send-email) to nixos1+dev-patches@discoursemail.com, but it comes back with "email issue: no content". how to handle that?
hpoussin has quit [Ping timeout: 256 seconds]
init_6 has quit [Remote host closed the connection]
<ekleog>
hpoussin: you may have better luck sending the question to nixos1+meta@discoursemail.come (if I remember correctly the syntax for the Meta category over there) -- then, worst case you can just send the patch by pasting it directly in the body of the mail instead of with `git send-email`, I don't know whether discourse supports `git send-email`
<Synthetica>
zimbatm: Would you mind preparing a new release for yarn2nix? I'm specifically looking for the behaviour introduced in 12de02f
hedning has quit [Quit: hedning]
hpoussin has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 245 seconds]
aminechi1haoui has quit [Remote host closed the connection]
obadz has quit [Quit: WeeChat 2.3]
orivej has joined #nixos-dev
<Synthetica>
zimbatm: Also, is there a reason the source code for yarn2nix is duplicated in the nixpkgs repo?
<globin>
Synthetica: otherwise it would need IFD
<Synthetica>
IFD?
<globin>
import from derivation
<gchristensen>
,IFD
<globin>
it uses nix code from yarn2nix
<{^_^}>
import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2. This is a problem because it requires evaluating some, building some, and then evaluating the build result.
<domenkozar>
Mic92: in addition to. If nbp accepts.
<{^_^}>
#54548 (by mrVanDalo, 18 minutes ago, open): rustc: mark compileprocess as timeconsuming
obadz has joined #nixos-dev
<gchristensen>
guess not, Mic92 :)
<Mic92>
gchristensen: I thought about that. For rustc I would only put new releases into staging to see if they break things, but 3k of rebuilds should be still ok for master.
<Mic92>
gchristensen: I wonder it is possible to put requiredSystemFeature in passthru or is this an value interpreted by the derivation itself?
<Mic92>
This would avoid rebuilds
<gchristensen>
fair enough
<gchristensen>
it needs to be in the derivation, because that is what Nix looks at
asymmetric has quit [Ping timeout: 268 seconds]
ixxie has joined #nixos-dev
worldofpeace has joined #nixos-dev
<timokau[m]>
"3k of rebuilds should be still ok for master" really? Then where do we draw the line? I have no real idea of how fast hydra churns through builds
<timokau[m]>
I guess its hard to compare 3k basically-just-copy-to-$out python builds with 1 chromium build
<timokau[m]>
But rust packages tend to take time no?
<gchristensen>
"where's the line" is unclear, indeed
<timokau[m]>
I like that you can usually develop from master with a couple of minutes rebuilds tops
<timokau[m]>
Probably not the case if you're packaging a rust package and have to rebuild the whole tree first, except if hydra builds those fairly quickly
<timokau[m]>
But then again I've never packaged a rust package, so I have no real stake in the matter ¯\_(ツ)_/¯
<samueldr>
would it make sense to have an API endpoint for hydra that would return an expected time for a build of "job X and its dependents" based on Y previous builds?
<timokau[m]>
It would be nice if nix could save that information in general
<samueldr>
sure, build times vary wildly depending on combination of factors, but it might help with a ballpark estimate
<timokau[m]>
But especially nice if you could query it from hydra
<timokau[m]>
It doesn't vary in orders of magnitude though, that should be fine
<timokau[m]>
As long as you can reliably tell the difference between chromium and a handful of python packages
<samueldr>
gchristensen: that's only self, not self+dependents, right?
<gchristensen>
right
<timokau[m]>
Whats up with the spike in build time? Random variation?
<Synthetica>
Maybe build it into ofborg? That way you can get it for PR's, instead of needing a new hydra build
<samueldr>
wasn't it in december when the aarch64 node was replaced due to it being wonky?
<gchristensen>
yeah, and also is when big-parallel started meaning something for aarch64
<samueldr>
right
<timokau[m]>
What *is* the meaning of big parallel? Aren't all our aarch64 build happening on some ridiculous 1337-core packet machine?
<samueldr>
Synthetica: I think ofborg isn't meant to hold historical values, and it won't build *everything*, thus historical data would be flawed, while hydra is probably going to hold more relevant historical data. Additionally, ofborg builds timeout at 1h, so it wouldn't really have significant data on big trees
<gchristensen>
jobs get 1 (iirc) core on aarch64 machines, timokau[m]
<gchristensen>
with big-parallel, they get 45
<samueldr>
and finally, I don't know if there's enough metadata kept to split "jobs" in a build, I think there isn't
<timokau[m]>
Ah so its not a matter of which machine they'll be build on, but how much jobs they'll be allocated
<Synthetica>
(Oh, you could have ofborg ping use that Hydra endpoint of course)
<timokau[m]>
samueldr: That'd be solved by building that into nix though
<timokau[m]>
I do `time nix-build` some time and I always wish I could just ask nix after the fact
<samueldr>
timokau[m]: if the builds complete, so ofborg having a 1h timeout would still leave unknown data
<{^_^}>
#54548 (by mrVanDalo, 1 hour ago, merged): rustc: mark compileprocess as timeconsuming
<samueldr>
I think all the data is already in hydra, mainly lacking reporting
<timokau[m]>
Yeah I meant the "enough metadata" part. Agree that this would be better in hydra than ofborg, though hydra hacking is a bit more involved than ofborg hacking (at least for me)
<samueldr>
it won't solve having to deal with perl and C++ if it isn't your lot, but I just made something to help getting a ready-to-hack-on instance https://github.com/samueldr/hydra-in-a-bag/
pie_ has joined #nixos-dev
pie__ has quit [Ping timeout: 250 seconds]
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 268 seconds]
<timokau[m]>
I saw that, looks very neat!
pie___ has joined #nixos-dev
<timokau[m]>
Language and time are the main blockers though. Looks like you at least significantly cut down on (2) :)
<gchristensen>
I think I'll make ofborg's build steps report as "<attribute> on <architecture>" instead of "nix-build -A teamspeak_server --argstr system aarch64-linux" any opinions?
<timokau[m]>
+1, currently the whole string usually is too long to display (leaving out the most interesting part)
<Synthetica>
Maybe keep the old name as some sort of comment? Honestly not sure what is available in github checks
pie__ has quit [Ping timeout: 245 seconds]
<samueldr>
gchristensen: make the command used available somewhere, for easier repro (if possible), but do make the step name more user friendly
<gchristensen>
maybe a follow-up PR :)
pie_ has joined #nixos-dev
ixxie has quit [Remote host closed the connection]
pie___ has quit [Ping timeout: 240 seconds]
pie__ has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
<Mic92>
I would propose @etu as maintainer.
<gchristensen>
+1
<infinisil>
+1
<Mic92>
I will sent an email
pie__ has quit [Ping timeout: 240 seconds]
<worldofpeace>
+1
pie_ has joined #nixos-dev
<Mic92>
oh man enigmail is such a pain to use
<gchristensen>
horrible
worldofpeace has quit [Remote host closed the connection]
<infinisil>
This is actually the first time I notice that there's a "Checks" tab on the top, I always just got there from clicking on the checks thing at the bottom of the main pr page