<clever>
niksnut: when you use GC_atfork_child in hydra, the child proc disables parallel marking, on the assumption that the child is short-lived and wont be doing much heap stuff
<clever>
niksnut: i could see that potentially having a negative impact on the performance
<ehmry>
why our binaries use rpath when we could hardcode libraries as absolute paths?
<clever>
ehmry: if you hardcode the lib, then you cant override it later with LD_LIBRARY_PATH
<{^_^}>
#24844 (by lheckemann, 3 years ago, open): Link to libraries through absolute paths?
<sphalerite>
clever: LD_PRELOAD will still work
<clever>
sphalerite: yeah, but that gets more ugly, and leaks into child procs harder
<clever>
sphalerite: the very first bug i looked into with nix (before i even installed nixos), is that libredirect LD_PRELOAD will hard-break chromium
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<ehmry>
LnL: thanks, now I have a lot to read
orivej has joined #nixos-dev
avn has quit [Read error: Connection reset by peer]
avn has joined #nixos-dev
__monty__ has quit [Quit: leaving]
__monty__ has joined #nixos-dev
<pie_>
so it turns out our kernel extraconfig method is kind of bad;
<pie_>
<tmsp> our configs are meant for the latter
<pie_>
<tmsp> I think the error is because of the differences between the nixos config generator, and scripts/merge_config.sh from the kernel itself
<pie_>
<tmsp> with the nixos script the kernel will ask for every option, including the dependency
<pie_>
<tmsp> it will enable all dependencies for the options that should be merged automatically
<pie_>
<tmsp> if nixos doesn't know about that dependency, it will answer with the default
<pie_>
<tmsp> which is "n" in most cases
<pie_>
havent gotten to looking for existing issues/prs yet but i think this would be good to redo
<gchristensen>
roberth: do you have a hydra account?
<roberth>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 296
<LnL>
is the staging release branch still active? stuff generally just goes to the release directly AFAIK
<roberth>
LnL: doesn't seem very active but I had a backport that required many rebuilds
nschoe has joined #nixos-dev
<cole-h>
Yeah, I think staging-<release> is still used, but only for the newest release I believe
<LnL>
so do security updates, but since the influx of changes in the release are very limited it's generally not worth jumping through the extra hoops there
<gchristensen>
I typically agree with that -- contributions to the release branch are much less and less likely to break, and therefore requirens the staging branch's behavior a bit less
<LnL>
exactly, or at least they should be
<LnL>
and if there's enough reason to backport something impactful, its should go through staging -> master first at which point the fallout should be pretty clear
<MichaelRaskin>
For some values of clear — there are things that are more impactful when backporting because of older versions
<Ericson2314>
clever hmm? You mean why is it using a C compiler for a linker?
<clever>
Ericson2314: no, i was thinking the linker was set to a naked un-wrapped ld
<clever>
but ive confirmed its a wrapped cc, which should just work
<clever>
Ericson2314: something i kind of want to see done, llvm and rust can support multiple targets, so why not just build rust for EVERYTHING at once, and then just share that one rust for every cross target?
<Profpatsch>
It just randomly fails every second try or so
<Profpatsch>
granted I might have some slight package loss
<Profpatsch>
but it would be sad if that means http directory listings stop working
<ekleog>
just tried C-F5 like 10 times without failure :)
<ekleog>
all the times it loads in less than a second
<Profpatsch>
ekleog: Well, not for me
<lovesegfault>
ekleog: did you get your jetson?
<Profpatsch>
If this already doesn’t work on a German connection, will it work for some even less developed countries?
<ekleog>
lovesegfault: we're on #nixos-dev here :p
<lovesegfault>
ekleog: I am talking about porting NixOS to it, so it fits!
<ekleog>
Profpatsch: I'd be curious what your traceroute to S3 is, because maybe it's an S3 outage?
<qyliss>
Works for me on Telekom in Germany.
<qyliss>
But I have previously had trouble reaching S3
<Profpatsch>
ekleog: my provider is dropping packets.
<Profpatsch>
But that really shouldn’t influence static listings :(
<ekleog>
well, HTTP should be resilient to dropped packets
<MichaelRaskin>
Seems to work from Kabel Deutschland
__monty__ has quit [Quit: nn]
<ekleog>
so either your provider drops enough packets that it's going over a presumably high timeout, or there's something really wrong with either the network or the way the ajax loads (eg. a too low timeout?)
<Profpatsch>
why would there be a timeout
<Profpatsch>
it’s a static listing, why is this not plain http
<ekleog>
even plain http has a timeout
<ekleog>
my guess as to why it's not plain http would be, s3's api doesn't provide a simple way to do it, and deploying non-static webpages is hard
<ekleog>
s/doesn't provide/probably &/
<qyliss>
quite a shame really
<qyliss>
used to just be able to drop in php for this sort of thing
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<Profpatsch>
I realize I’m being unfair here, it’s probably a lot easier to set up this way.
<ekleog>
I'd agree with you that the way the world is kind of sucks, though :p
<Profpatsch>
But if it’s critical infra, we should be really careful if we want to encourage people that are not on connections where they can expect stable latency/paket delivery
<Profpatsch>
for example, if you are on satellite connection, or on some wifi-based DSL in the himalayas
<Profpatsch>
Like quite some people in northern India are
<Profpatsch>
I’m getting the page after like 5 secondb
<Profpatsch>
*s
<Profpatsch>
But the provider might be more stable now.
<samueldr>
the "final" releases page is a static html asset, it shouldn't have issues like an ajax loading spinner
<samueldr>
but the buckets listing (those with s3:// at the top) I believe there's not much that can be done
<ekleog>
does it reproducibly reproduce, or does it fail as often as the channels.nixos.org webpage? a XHR is just an HTTP request after all, so the only reason I could think that would make it fail more often than a static http page would be a timeout set lower
<samueldr>
other than reverting to the previous behaviour, which was to not have anything accessible
<ekleog>
samueldr: one potential idea might be to have the xhr code auto-retry on timeout? (maybe logging out a message or something) -- this would avoid having to successfully load two http requests in a row
<samueldr>
I guess so, I don't know who produces that page
<samueldr>
I don't see it in the org's things on github
<ekleog>
no idea either :/
primeos has joined #nixos-dev
drakonis_ has quit [Ping timeout: 260 seconds]
drakonis_ has joined #nixos-dev
<abathur>
I can only assume page doesn't have an IRC client that notifies them of mentions
<cole-h>
lol
<abathur>
I've seen it highlighted hundreds of times, and never seen them speak
<abathur>
and, after searching 'nick:page' in the samueldr logs for the most-popular channels, am not sure they've said anything here in the past 2 years