<andi->
I am working on updating firefox to 58.0.1.. mainly due to the recently announced security issue within firefox. Since I've never touched firefox before I'd appreciate any input on https://github.com/NixOS/nixpkgs/pull/34436 . Trying to port that same patch to stable now.
<andi->
gchristensen: good idea, I'll do that as followup of 58.0.1 bump. It will be yet another rebuild but we'll have clear separation of concenerns with those changes (& PRs)
<gchristensen>
good idea
<fpletz>
niksnut: thanks
<fpletz>
andi-: +1
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<domenkozar>
hmm
{^_^} has quit [Remote host closed the connection]
<domenkozar>
still can't get headphones to work with pulseaudio
<Sonarpulse>
so February is the tentative plan too?
ma27 has joined #nixos-dev
<niksnut>
yes
<gchristensen>
peti: please PM me if you're around and available :) I'd love about 5-10 minutes of your time
<Sonarpulse>
niksnut: \o/
<gchristensen>
ofborg is incorrectly marking PRs as failing, I'm working on triage and a resolution. sorry
<Sonarpulse>
gchristensen: lmk what the fix ends up being
<Sonarpulse>
as I am soon going to change release-lib a bit
<gchristensen>
ok
<gchristensen>
so the problem seems to stem from me setting supportedSystems to [ "x86_64-linux" ] for eval, which was probably not correct for the instantiations
<gchristensen>
(definitely not correct ;))
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
<Sonarpulse>
gchristensen: hmm I would have thought that would be fine for x86_64-linux builds at aleast
<gchristensen>
it is for build, but not eval-time
<gchristensen>
ie: the checks that run on every PR check across all platforms we support
<catern>
hmm, I was thinking of adding logging to the nix-daemon, but I had a couple concerns. 1: Should the nix-daemon log in plain text or in some structured format? 2: Should the logging be implemented by nix-daemon itself, or by a separate tool that snoops on nix-daemon communications and summarizes them?
<catern>
3: If the nix-daemon logs in plain text to stderr, how do we differentiate different users and sessions which might be interleaved?
<samueldr>
would it be relevant to change how the daemon treats build logs? is there a way to keep them more truthful with regards to how the build process themselves logs to stdout/stderr?
<niksnut>
gchristensen: heh
michaelpj_ has joined #nixos-dev
<catern>
samueldr: hmm, I actually have no idea how the build logs stuff works :) is there any docs about it?
<catern>
more specifically I don't know how Hydra build logs work
<catern>
does it work by connecting to the Nix daemon and reading the STDERR_NEXT messages like the normal Nix client does?
<catern>
if that's how it works, then no, I think it's fine as it is
<samueldr>
I have next to no idea how nix works internally :(
<catern>
ah, heh :)
<catern>
samueldr: well, what's your concern about how the daemon treats build logs?
<catern>
internally I believe it just merges stdout and stderr into the same stream (or possibly just passes the same pipe to the build process for both stdout and stderr) and then sends that single stream to the client
<catern>
which seems fine
<catern>
since it's just for debugging anyway
<samueldr>
from what gchristensen said when working on the log thing for ofborg, let's say that `make` outputs one line to stdout, then the other to stderr, there is no way to know on which output the line was sent, as the nix daemon logs them both at the same location
<catern>
ah, sure
<catern>
is that... a problem?
<samueldr>
(though, outputs are *not* line oriented things)
<samueldr>
it's metadata about the build log that may have a meaning
<catern>
sure, but it's ultimately just debugging output
<catern>
so if there's no concrete use case, I don't see why it would need to be changed
<samueldr>
it's highly dependent of the thing being built though, but when reading a huge log, if it was possible to highlight stderr vs. stdout, it could (and could also not) be helpful
<catern>
ah
<samueldr>
the idea being that it is truthful to what the build process did
<catern>
well, it's not impossible
<catern>
the Nix protocol (from my understanding of it) could support sending separate messages for stdout and stderr logs
<samueldr>
I personally had the question months ago too when I wanted to look at what my builders were doing without ssh-ing into the machine that started the build, when doing a remote build
<catern>
(and it wouldn't be that hard)
<samueldr>
oh, neat
<catern>
so I guess the question is, would a daemon-level functionality for logging make this unnecessary?
<catern>
hmmm... no, I don't think so
<samueldr>
it probably depends where lies the responsibility of consuming the build logs I guess
<catern>
in a multi-user system, the daemon's logs would probably be private
<catern>
likewise in a multi-host system where there's a single central daemon for multiple servers
<catern>
it's more functional to have the debug logs be part of the Nix protocol as they currently are
<catern>
if the debug logs weren't already part of the Nix protocol, maybe it would be up for debate whether some other out-of-band channel should be provided for debug logs, and maybe that out-of-band channel could be integrated with a daemon-level logging functionality. but since debug logs *are* part of the Nix protocol currently...
<samueldr>
I may also be misunderstanding what was asked, my query was about the build output of a build, and not the log of nix code itself
<catern>
right
<catern>
yes, that's my understanding of your query
<catern>
niksnut: btw, if we are planning on releasing 2.0 soon, could you merge https://github.com/NixOS/nix/pull/1801 before that? that would be very very helpful for evolving Nix functionality without waiting for a new release
<catern>
so I want to make sure I don't have to wait another couple years to get it into a release :)
<niksnut>
done
<gchristensen>
catern: can you send a PR adding docs for that?
<catern>
gchristensen: yes, will do
<gchristensen>
thanks
<gchristensen>
!
<catern>
(thank you for reminding me actually, there is also a comment that lists the different NIX_REMOTE values which I meant to update)