worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ https://discourse.nixos.org/t/nixos-20-03-release/6785 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
evils has quit [Quit: Lost terminal]
evils has joined #nixos-dev
evils has quit [Client Quit]
evils has joined #nixos-dev
evils has quit [Client Quit]
evils has joined #nixos-dev
evils has quit [Client Quit]
evils has joined #nixos-dev
<abathur> doh
ris has quit [Ping timeout: 265 seconds]
tom39291 has quit [Quit: WeeChat 2.7.1]
tom39291 has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
tom39291 has quit [Quit: WeeChat 2.7.1]
tom39291 has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
ixxie has joined #nixos-dev
<Mic92> qyliss: niksnut worldofpeace tilpner any objections for opening the FCP for https://github.com/NixOS/rfcs/pull/55 ?
<{^_^}> rfcs#55 (by tilpner, 31 weeks ago, open): [RFC-0055] Retire inactive nixpkgs committers
<Mic92> gchristensen: ^
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
orivej_ has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 256 seconds]
avn has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
avn has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej_ has quit [Ping timeout: 258 seconds]
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
avn has quit [Ping timeout: 260 seconds]
avn has joined #nixos-dev
janneke_ has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
janneke has quit [Ping timeout: 260 seconds]
janneke_ is now known as janneke
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
__monty__ has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
ixxie has quit [Ping timeout: 256 seconds]
avn has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
ixxie has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
avn has joined #nixos-dev
nschoe has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
ris has joined #nixos-dev
ixxie has quit [Quit: Lost terminal]
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-dev
<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
<ehmry> clever: when is that a bad thing?
<clever> depends on what your doing
<{^_^}> #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
<{^_^}> #42838 (by teto, 1 year ago, merged): [RFC] add ability to merge structured configs
<pie_> via mention of merge_config.sh in https://github.com/NixOS/nixpkgs/pull/41393
<{^_^}> #41393 (by teto, 1 year ago, closed): [RFC] linux: translate config to structured config
<clever> pie_: ive also been having trouble (havent confirmed exactly what) with getting rpi-open-firmware to boot with a nix built kernel
<{^_^}> #41103 (by teto, 1 year ago, closed): Meta issue about kernel features dependencies
<pie_> i dont suppose teto is on irc
<worldofpeace> Mic92: yeah, the points there that I was going to make anyways got addressed by you. FCP sounds good
<sphalerite> clever: LD_PRELOAD a library that replaces execve to clear the LD_PRELOAD variable :D
<sphalerite> clever: libburnafterreading
<clever> sphalerite: i have considered a change to libredirect, to make it decrement a var on every execve
<clever> sphalerite: and then to unset itself when it hits 0
<clever> as-in, remove all libredirect related vars
<eyJhb> Would it be okay to close a issue as this? https://github.com/NixOS/nixpkgs/issues/51212 cli, gui and there is even a module for the server part
<{^_^}> #51212 (by Wolfereign, 1 year ago, open): Package Request: Bitwarden Client (GUI & CLI) & Server
* eyJhb wants to test his powers
<srhb> eyJhb: Take note that bitwarden_rs is different from the official server implementation.
<eyJhb> srhb: damn..
<eyJhb> Weird that we have _rs but not the official
<eyJhb> Left a reply then
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
teto has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
<JJJollyjim> The official is a somewhat painful .NET app iirc
<JJJollyjim> And needs MS SQL
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 260 seconds]
teto has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
cole-h has joined #nixos-dev
__monty_1 has joined #nixos-dev
__monty_1 has quit [Client Quit]
<qyliss> Mic92: sounds good to me
<prusnak> has it been already decided whether "unstable" belongs to ${pname} or into ${version}?
<prusnak> grep says: 112x pname, 331x version
<prusnak> ^ cc jtojnar
<cole-h> I see most going to version nowadays (and prefer it there myself)
<prusnak> i am trying to figure out the discussion in https://github.com/NixOS/nixpkgs/issues/68531 but I don't see the outcome :-/
<{^_^}> #68531 (by jtojnar, 35 weeks ago, closed): Incorrect packages names or versions according to repology
<jtojnar> prusnak no consensus yet
<jtojnar> recently I suggested we might want to put unstable after the date: https://github.com/NixOS/nixpkgs/pull/86430#issuecomment-622981031
<jtojnar> prusnak that specific issue was not resolved but it was closed for inactivity and possibly being out of date
<prusnak> thanks; i opened https://github.com/NixOS/nixpkgs/pull/88023 which splits name into pname+version ; it's easy to work from there to whatever option is preferred
<{^_^}> #88023 (by prusnak, 2 minutes ago, open): treewide: split name into pname/version for unstable packages
<gchristensen> fyi: ofborg is down temporarily for some network maintenance
<clever> Ericson2314: i'm a bit confused as to how buildPackages things are even supposed to build/work
<clever> Ericson2314: the rustc derivation has $CC pointing to the host compiler, and the target compiler is not even in $PATH
<clever> Ericson2314: so how is it meant to build libs for the target?
<clever> Ericson2314: adding target libs to buildInputs doesnt fix the target compiler, which i had to fish out of $configureFlags
<roberth> hi, I'm trying to move staging-20.03 forward. Could someone resume the aborted builds? https://hydra.nixos.org/eval/1587880/restart-aborted
<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
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
<{^_^}> firing: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
alp has joined #nixos-dev
drakonis has joined #nixos-dev
cole-h_ has joined #nixos-dev
cole-h_ has quit [Client Quit]
teto has joined #nixos-dev
alp has quit [Ping timeout: 240 seconds]
teto has quit [Quit: WeeChat 2.8]
alp has joined #nixos-dev
cole-h_ has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 272 seconds]
<Ericson2314> clever: yea I think it just gets the tools by absolute path from the configure flags and config toml files
cole-h_ has quit [Quit: Goodbye]
<clever> Ericson2314: then how would the cross gcc get its LDFLAGS set right for -L stuff?
<Ericson2314> clever: good question :)
<clever> that is the problem i need to solve to fix rustc
<Ericson2314> Did you try adding the deps to I guess make the depsBuildBuild and I guess make the depsBuildTarget?
<Ericson2314> see what GHC does, for example
<Ericson2314> where I was careful to add them for just that reason
<clever> haskell-modules/generic-builder.nix: depsBuildBuild = [ nativeGhc ];
<clever> Ericson2314: that one appears to almost exclusively be host tools
<clever> ghc/8.6.5.nix: depsBuildTarget = toolsForTarget;
<clever> ah, that one looks better
<Ericson2314> yup!
<Ericson2314> oh I bet I can make it less conditional now with pkgsBuildTarget
<Ericson2314> if I didn't do that already
<Ericson2314> ah I did do that already
<clever> but, that doesnt work if i only put in the libs
<clever> i think we need the setup hook from the cross gcc
<clever> set=target.x86_64-pc-windows-gnu.linker=/nix/store/bynh22svkyy6v6rwvaycn88g8lw3dzsn-x86_64-w64-mingw32-stage-final-gcc-debug-wrapper-9.3.0/bin/x86_64-w64-mingw32-cc
<clever> so this attr has to go into depsBuildTarget
<clever> 86 "${setTarget}.linker=${ccForTarget}"
<clever> 68 ccForTarget = "${pkgsBuildTarget.targetPackages.stdenv.cc}/bin/${pkgsBuildTarget.targetPackages.stdenv.cc.targetPrefix}cc";
<clever> pkgsBuildTarget.targetPackages.stdenv.cc then
<clever> NIX_TARGET_LDFLAGS has now magically appeared
<clever> and manually invoking the cross gcc with -lpthreads works
<clever> Ericson2314: in another 40 mins, we will know if that worked
teto has joined #nixos-dev
nschoe has quit [Quit: No Ping reply in 180 seconds.]
<Ericson2314> clever: yes yeah getting in all the stdenv.cc will get those setup hooks
nschoe has joined #nixos-dev
<clever> and now that its in that attr, its likely in $PATH, so configureFlags shouldnt need absolute paths
<clever> which means we could maybe clean this up further
<Ericson2314> clever: :)
<clever> = note: /nix/store/h4bkk5lqfh80xsp64c1wsfag5p5qiigv-x86_64-w64-mingw32-binutils-2.31.1/bin/x86_64-w64-mingw32-ld: cannot find -lpthread
<clever> Ericson2314: exact same error!
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<colemickens> can anyone help me adapt msteen's suggestion here? https://github.com/msteen/nix-prefetch/issues/6
<{^_^}> msteen/nix-prefetch#6 (by colemickens, 4 days ago, open): Calculate cargoSha256?
<colemickens> I'm not quite sure how to use this in my overlay for a rust package's cargoSha256
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
<colemickens> newvendorSha256="$(nix-prefetch '{ sha256 }: i3status-rust.cargoDeps.overrideAttrs (_: { cargoSha256 = sha256; })')"
alp has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
primeos has quit [Quit: WeeChat 2.8]
orivej_ has quit [Ping timeout: 265 seconds]
<Ericson2314> clever: ahhhh!
<Ericson2314> :(
<clever> Ericson2314: yeah, its weird, when i run wait a sec
<clever> i ran the cc, from cc-wrapper
<clever> why does the error show bare binutils?
<clever> --set=target.x86_64-pc-windows-gnu.linker=/nix/store/bynh22svkyy6v6rwvaycn88g8lw3dzsn-x86_64-w64-mingw32-stage-final-gcc-debug-wrapper-9.3.0/bin/x86_64-w64-mingw32-cc
<clever> that is a cc-wrapper...
<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?
<{^_^}> firing: BuildsStuckOverTwoDays: https://status.nixos.org/prometheus/alerts
<Ericson2314> clever: I agree completely!
<Ericson2314> we do this for LLVM now, thank god
<Ericson2314> but rustc nobody as yet picked about it's bootstrap
<Profpatsch> lol, https://channels.nixos.org
<Profpatsch> gives me a spinning ajaxload.gif
<gchristensen> yeah it uses the s3 api to load
<Profpatsch> doesn’t load for me
<Profpatsch> ah, now it did
<Profpatsch> but takes quite a while
<Profpatsch> Is there a new, better way of getting the current git revision of channels?
<qyliss> github api?
<qyliss> or just git?
<samueldr> that still works
<Profpatsch> which still works, but I’m unable to find the 20.09 git-revision link
<samueldr> though you need to follow the redirects
<Profpatsch> err, 20.03
<samueldr> heh
<samueldr> am I missing something?
<Profpatsch> hm, now I see it
<Profpatsch> When it loads you can find it
<Profpatsch> But mostly spinning icon
<Profpatsch> Error [object Object]
<ekleog> you need to enable javascript
<samueldr> (and xhrs)
<Profpatsch> It’s enabled
<ekleog> (to nix-channels.s3.amazonaws.com)
<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
<ekleog> out of curiosity, when you try to open eg. https://releases.nixos.org/nixos/17.03-small/nixos-17.03.1954.2c1838ab99b ; do you get a successful answer or a timeout error?
<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
alp has quit [Ping timeout: 272 seconds]