<hyperfekt>
i think i'm done with making maintainer scripts for hackage-packages.nix, and it was much easier than i thought it would be???
<cole-h>
🎉
<hyperfekt>
does anyone know if the stackage recommendations are updated manually or automatically?
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
ixxie has quit [Ping timeout: 246 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 256 seconds]
ixxie has joined #nixos-dev
teto has quit [Ping timeout: 260 seconds]
ixxie has quit [Ping timeout: 256 seconds]
ixxie has joined #nixos-dev
LnL has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
ixxie has quit [Ping timeout: 260 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Remote host closed the connection]
ixxie has joined #nixos-dev
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
alp has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
nschoe has quit [Quit: No Ping reply in 180 seconds.]
nschoe has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
FRidh has joined #nixos-dev
teto has joined #nixos-dev
__monty__ has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
ixxie has quit [Ping timeout: 264 seconds]
ixxie has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
drakonis has quit [Quit: WeeChat 2.8]
<NinjaTrappeur>
emily: true, that being said, I'm not 100% sure this is a desirable behaviour. It can be reopened, but as it is, we're not even able to triage the open PRs, I'm not sure we'll even notice a closed PR unless the OP gets voicy about it.
<NinjaTrappeur>
But yeah, I get it's a technical limitation.
alp has joined #nixos-dev
_e has joined #nixos-dev
ris has joined #nixos-dev
ris has quit [Ping timeout: 272 seconds]
<bennofs[m]>
Why does status.nixos.org/grafana not have instance metrics for the "hydra" machine (or did I look in the wrong place)? That's the one the evaluator runs on, right?
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
<globin>
/buffer 11
<globin>
%)
<bennofs[m]>
Ah, seems that's on Per-Instance Metrics and not on Instance Metrics
<LnL>
based on hydra-org-configurations I think you're looking for ceres
<bennofs[m]>
Ah, "hydra" is actually not the evaluator, but an old machine that used to be evaluator
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
ixxie has quit [Ping timeout: 246 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 272 seconds]
ixxie has joined #nixos-dev
<Mic92>
I think about adding a policy that limits the number of lines/bytes we allow per packages. We have all these node-packages.nix files laying around.
<Mic92>
I am currently retrofitting them into nixpkgs/pkgs/development/node-packages.
<FRidh>
think that could really be a nlnet funded microgrant, like the nixpkgs updater
alp has quit [Ping timeout: 272 seconds]
<Mic92>
FRidh: that make sense. However we should not try to mirror complete npm. It's simply too much data.
<FRidh>
Mic92: definitely not. The idea is to include only what is needed by the applications
<FRidh>
mirror completely was something that I recally some of us tried before, and things got huge. Although it is interesting to see now where this new nix-python tool goes
<LnL>
hackage2nix does that IIRC
<Mic92>
well the haskell ecosystem is much smaller
<LnL>
there's something which gathers all of the hackage metadata in a repository and then the tool uses this data to generate the package set
<Mic92>
LnL: who decides what goes in nixpkgs?
<LnL>
having these kind of metadata repositories which could be used as the data source for tools sounds like an interesting idea
<Mic92>
This exists for python now as well.
<Mic92>
Rust upstream also has one.
<LnL>
well for haskell it's everything blessed by a stack lts I think
<LnL>
I know of the cargo metadata but what's this python thing you speak of?
<bennofs[m]>
anyone with hydra knowledge here? How can it happen that a job like this times out: https://hydra.nixos.org/build/118037675 tagged is a really small package, and normally builds in <1 min
<bennofs[m]>
i already tried to look at instance metrics during the time of that build, but I could not spot anything strange
<LnL>
probably just something with the builder or the connection to it
<m1cr0man>
Hey folks if I am backporting docs to 20.03 what branch do I create the PR onto?
<emily>
release-20.03
<m1cr0man>
Thanks :)
alp has joined #nixos-dev
ixxie has quit [Ping timeout: 265 seconds]
ixxie has joined #nixos-dev
ixxie has quit [Ping timeout: 260 seconds]
ixxie has joined #nixos-dev
<bennofs[m]>
LnL: oh, if the connection between the master and the builder is interrupted, will that show as a timeout in hydra ui?
<julm>
TIL, systemd-cgls - Recursively show control group contents
teto has quit [Ping timeout: 260 seconds]
<infinisil>
Neat
obadz has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
teto has joined #nixos-dev
orivej has joined #nixos-dev
ixxie has quit [Ping timeout: 260 seconds]
ixxie has joined #nixos-dev
<bennofs[m]>
gchristensen, LnL: that leaves me wondering then: what things could happen to a builder that won't show up in instance metrics but cause a build to stall for 2 hours?
<gchristensen>
bennofs[m]: a good question. a few times I've seen an instance be basically be dead, but alive enough for openssh to continue saying "yep I'm here"
<bennofs[m]>
but instance metrics also track load average, which should rise in that case?
<gchristensen>
it was too dead to report metrics
<bennofs[m]>
oh
<MichaelRaskin>
In principle, AFAIU, something going to D (uninterruptible sleep) could stall without creating loadavg
<nbp>
it is not related to Nix, but how to properly store secrets in a Git repo.
<nbp>
however, if we want to build content with secret inside, we might have to share the content with the building machine, thus knowing where data is going to be built when producing the derivation.
<bennofs[m]>
what mechanism does hydra use for distributing the builds to build machines? Is that a build hook?
<bennofs[m]>
oh wait, it has it's own queue right?
<LnL>
--option builders
<clever>
bennofs[m]: internally, hydra will read the same /etc/nix/machines config, but it will connect directly to the builders and bypass nix-daemon
<clever>
bennofs[m]: when a build is done, it will also connect to nix-daemon over a unix socket, and copy the closure from builder->local
<clever>
which acts more like nix-copy-closure, as far as nix-daemon is concerned
justanotheruser has quit [Ping timeout: 272 seconds]
cole-h has joined #nixos-dev
<bennofs[m]>
clever: ok. in hydra.nixos.org, that builder -> local copy is builder -> s3? or does it still go through a local disk on the host that runs the queue-runner?
<clever>
bennofs[m]: when s3 is configured, hydra will do builder->s3 instead, and skip localhost
<clever>
only build inputs (the nixpkgs src) and IFD (not allowed on hydra.nixos), plus anything built on localhost (may not be enabled)
<clever>
would go to localhost
<bennofs[m]>
does hydra sometimes abort jobs automatically? I often come across builds where a step has been aborted but then built again later. Or are aborted jobs not cached?
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
<bennofs[m]>
ah, aborted can happen if some error occurs during building, such as a network error as well. And it looks like aborted builds are not cached
<bennofs[m]>
which makes sense
* gchristensen
would absolutely kill for a profiler / debugger right now
<bennofs[m]>
Nix lang profiler/debugger?
<gchristensen>
yeah
<clever>
some profiling can be done with env vars and -vvvvv
<clever>
but there are limits to what it can do
<gchristensen>
yeah, that could work maybe a little bit, but something ... better ... would be really nice
alp has quit [Remote host closed the connection]
ris has joined #nixos-dev
alp has joined #nixos-dev
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
<jtojnar>
worldofpeace: I would just put `dependency('g-s-d')` in the meson file but not use it anywhere
<cole-h>
worldofpeace: Should #83805 be closed now?
<{^_^}>
hydra#743 (by Ma27, 6 days ago, open): Add a filter for maintainers in the jobset-eval view
clever has quit [Ping timeout: 265 seconds]
clever has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<ajs124>
Anyone got any insight on how I could have triggered this: "i386 architecture of input file `zlib/adler32.o' is incompatible with i386:x86-64 output" in the i686 syslinux (uefi) build?
ixxie has quit [Ping timeout: 260 seconds]
MichaelRaskin has quit [Ping timeout: 256 seconds]
ixxie has joined #nixos-dev
<clever>
ajs124: it sounds like your mixing arches, how did you get the zlib?
<ajs124>
clever: I'm not sure how any of that happened. #86846 is the relevant issue, for some more background.
<ajs124>
It's probably a zlib patched to run inside a bootloader.
MichaelRaskin has joined #nixos-dev
<clever>
ajs124: next thing id do, is bisect nixpkgs to find the problem, was it caused by changing the src of syslinux?
<ajs124>
clever: their default makefile tries to build efi64 on i686
<clever>
ajs124: when nix is doing a 32bit build, it usually gives you a 32bit only compiler
<samueldr>
there was a recent change to syslinux to allow uefi building
<ajs124>
I'd say their Makefiles are broken. I mean, they barely have EFI support, tbh.
<ajs124>
samueldr: yes, I did that ^^
<samueldr>
is it what is causing the blockage?
<ajs124>
yup, sorry.
<ajs124>
didn't test on i686
<samueldr>
alrighty, :) no need to figure out who did that now :D
<clever>
id just disable uefi support in the build then?
<samueldr>
does syslinux support uefi on 32 bit?
<ajs124>
efi32 builds, actually.
<ajs124>
I can post the patch I put in the issue as a PR. I haven't actually booted anything with that, though. Not sure if I have any 32bit EFI devices, in the first place.