AlwaysLivid has quit [Remote host closed the connection]
<rnhmjoj>
is there a trick to avoid circular dependencies between two derivations? both must contain a symlink to each other, but attempting to evaluate the outPath of one results in an infinite recursion
<siraben>
/nix/store/rqfgki7ck1bxqhk3hd7wziqhahjadfbj-binutils-2.35.1/bin/ld: closeout.c:(.text+0xc2): undefined reference to `error'
<siraben>
/nix/store/rqfgki7ck1bxqhk3hd7wziqhahjadfbj-binutils-2.35.1/bin/ld: ./lib/libhello.a(xalloc-die.o): in function `xalloc_die':
AlwaysLivid has quit [Ping timeout: 268 seconds]
<siraben>
all the produced images seem to be around 32/33 MB in size
<sterni>
pkgsMusl.hello :p
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
<andi->
Can I tell nix to never subtitute fixed output derivations from the binary cache?
<andi->
*substitute
AlwaysLivid has joined #nixos-dev
<regnat[m]1>
<andi- "Can I tell nix to never subtitut"> If it's just for temporary testing, you can probably override `mkDerivation` to add `allowSubstitute = false` to every fixed-output derivation
<regnat[m]1>
(That wouldn't work for FO derivations that bypass `mkDerivation`, but I don't think there's a lot of these)
<andi->
I actually want to so that I re-fetch all the go & rust module FoD hacks instead of just using whatever might have been produced on hydra.
<gchristensen>
we should probably handle this `console` parameter much earlier, right?
<puck>
the kernel does something with console=[..] too, i believe
<andi->
gchristensen: what makes you think that we have to do that? Before stage2 we just let the kernel do its thing
<puck>
not entirely correct
<puck>
the stage1 shell uses the console parameter
<andi->
oh?
<puck>
i'm not sure why this doesn't just use /dev/console though
<andi->
yeah
AlwaysLivid has quit [Remote host closed the connection]
<andi->
maybe that isn't a thing yet / wasn't a thing back when that was written? (in terms of the device node being created not the general existence)
<puck>
still, why not mknod it? this has been since 2.1.71
<gchristensen>
gosh we are so lucky to have so many people who know whats up with things.
andi^ has joined #nixos-dev
andi- has quit [Ping timeout: 260 seconds]
__monty__ has quit [Quit: leaving]
<gchristensen>
Regnat[m]1: thanks for your review, it is really nice to get a good review so quickly!
jlotoski-znc is now known as jlotoski-p71
jlotoski-p71 is now known as jlotoski-znc
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<regnat[m]1>
gchristensen: I think I should thank you for providing me with a good way to procrastinate without feeling guilty about id 😉
<gchristensen>
:D
<gchristensen>
Regnat[m]1: I wonder if there is a problem of rewriting the host-key file many times even when it already exists?
<regnat[m]1>
Mh… That's probably not a problem in practice because I think we never run more than two ssh commands, and always sequentially. But in theory that could be indeed
<gchristensen>
what if you're sending 1,000 builds to the same remote at the same time?
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
rj has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<regnat[m]1>
I have to say I'm a bit confused as to what happens… I think each Nix process only uses one ssh connection to the same host (because it only happens when it instantiates the store, which happens only once), but I'm not that sure actually
<regnat[m]1>
(So yeah, maybe worth making sure that opening 1000 connections to the same host doesn't have a race condition. Just in case)
<siraben>
Lol I was being too clever, thanks supersandro2000, sterni, pkgsMusl.hello worked
<siraben>
I just didn't like the idea of importing a package set in my overlay: http://ix.io/2QOU
<{^_^}>
#94228 (by nagisa, 30 weeks ago, open): musl: Trivial binaries built with musl will fault on nixos
<sterni>
siraben: as far as I understood it the gcc stdenv just screws with musl-gcc and you end up with the wrong ld-linux.so etc.
<sterni>
so you need to use the pkgsMusl stdenv
<siraben>
How do I archive up the result symlink so I can distribute it?
<siraben>
sterni: dang
<siraben>
nvm found it at `/nix/store/kiv1srribivn9v7d5qnwv7j3i4sc2nmw-docker-image-nix-hello-musl.tar.gz`
<sterni>
readlink is your friend on nixos
<eyJhb>
^ it really is
<sterni>
or realpath, depending on taste
<sterni>
what's the difference anyways
mkaito has joined #nixos-dev
mkaito has quit [Client Quit]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
AlwaysLivid has quit [Ping timeout: 268 seconds]
<abathur>
domenkozar[m]: I rebased nix#4289 since nix#4549 just got merged, but just realized it only runs on push and not PR; what sort of workflow are you imagining for running them against PRs?
<domenkozar[m]>
abathur: you can create your our cachix binary cache
<domenkozar[m]>
it's not the best one, but it works :)
<domenkozar[m]>
I'm open to other ideas
<abathur>
I guess it's really two questions :)
<abathur>
since they aren't running on PR, my main curiosity was the process you imagine when a nix committer wants to test the installer changes in a PR
<abathur>
and whether that's a manual step I need to bug someone about, or whether you imagined another piece of automation closing that gap :)
<domenkozar[m]>
For now we should document how it's tested - by creating your own cache
<domenkozar[m]>
going forward we could add more automation - for example parse comment and trigger installer build
<abathur>
do you know if there's a way to override the CACHIX_NAME without having to tack something like https://github.com/abathur/nix/commit/bdbaaa531519fd6f69b10046a18482897f164854 onto each PR that needs it? would it make sense to convert that into a secret so the instructions can just say to add two secrets at the repo level and they'll stay set unless you delete your fork?
andi^ is now known as andi-
cole-h has joined #nixos-dev
<cole-h>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 142
xwvvvvwx has quit [Read error: Connection reset by peer]
xwvvvvwx has joined #nixos-dev
<gchristensen>
I've got a remote builder, and when I build remotely I'm getting an error: hash mismatch importing path '/nix/store/<<hashhash>>-pkgname-dev'; wanted: sha256:xxxxxxxx got: sha256:yyyyyyyy ... anyone know what the thing to do here is?
<gchristensen>
looks like you don't care about the field at all, so it should work :)
<ajs124>
Maybe somewhere else in the file we do, but AFAICT it queries the API for any more information.
<gchristensen>
ajs124: do you run with that wizeman patch? I don't feel like I can evaluate it
<ajs124>
we run with the following hydra PRs: 689, 717, 836 and 832 (that's the one, right?) on top of 4e05acc471fa658ba019a477e62c27c7f8632e84 against nix 21830cb0447f2ad3d436a8b9df43222a787bb80e
<ajs124>
ah, and we disable restrictedEval, because I forgot
<ajs124>
PR 832 was added by me on Nov 23, with the comment "add another patch, for good measure". Maybe we were experiencing this error? Who knows, because I certainly forgot.
rajivr has quit [Quit: Connection closed for inactivity]
<worldofpeace>
anyone know if it's possible to do like `environment.etc."plymouth/themes".source` and `environment.etc."plymouth/themes/yadda/yadda".source` without a permission denied error?
<domenkozar[m]>
abathur: it didn't push: Pushing is disabled as signing key nor auth token are set.
<abathur>
at least, the secret, but let me look back at it; I do see that in the post cachix phase now
<samueldr>
ah, I re-read that bit and see that it was explained well
<cole-h>
worldofpeace: I was under the assumption that environment.etc created dirs recursively
<cole-h>
oh wait
<cole-h>
I see -- plymouth/themes is a symlink (presumably to the store), and plymouth/themes/yadda/yadda would be a symlink inside plymouth/themes
<abathur>
domenkozar[m]: ah, I was just dumbly consulting cachix docs and using auth token without noticing only signing key is used in the workflow
<domenkozar[m]>
yeah that's a bit confusing :/
<immae>
worldofpeace: you could create a plymouth-theme derivation that combines what you want to put in plymouth/themes and plymouth/themes/yadda/yadda, and use that as the new source for environment.etc."plymouth/themes".source ?
evanjs has quit [Ping timeout: 265 seconds]
evanjs has joined #nixos-dev
<worldofpeace>
immae: hmm, wait maybe I had that stashed
<worldofpeace>
sounds about correct, but I was also under the assumption as cole-h mentioned that it would just "do that"
orivej has quit [Ping timeout: 260 seconds]
<gchristensen>
ajs124: coming back to that PR a few minutes later I think I get it
<gchristensen>
addToStore won't read from source2 if it has the path already, meaning it'd say "Send me path X" remote would say "Here's path X"... but the receiver wouldn't read it, then on the next output it'd say "please send me path Y" and now it is reading path X's data
<gchristensen>
is that right?
<worldofpeace>
samueldr: I looked into those fedora grub patches a bit more, and essentially they've changed just about everything with grub2 to make it work nicely for the user. so I'd have to recreate the patches and avoid... fedora patching temptation.
<samueldr>
all three are shipping bajillion of patches to grub that should be upstream
<samueldr>
oh, ubuntu too
<samueldr>
and I'm sure other distros too
<samueldr>
when I was looking at grub more in-depth (before I got side-tracked into aarch64 and phones things) I was contemplating documenting the differences between distros
<ajs124>
gchristensen: I'm not sure either, tbh.
<worldofpeace>
samueldr: that as a wiki would be excellent. Though, fedora seems to experiment on grub very frequently so that might be hard to keep up-to-date. From reading the comments it seems a lot of what those patches are is "something upstream would never accept".
<samueldr>
yeah
<gchristensen>
ajs124: I wonder if there is a really cheap way to create a remote builder in a hydra test
<infinisil>
gchristensen: Using the local machine doesn't work?
<infinisil>
(faking it as a remote one)
<gchristensen>
they need to run inside a nix sandbox
<ajs124>
gchristensen: maybe as a virtual machine? using regular nixos vm testing stuff?
<gchristensen>
it is just so heavy :(
orivej has joined #nixos-dev
BaughnLogBot_ has joined #nixos-dev
nyanotech has joined #nixos-dev
jonringer_ has joined #nixos-dev
infinisi1 has joined #nixos-dev
pinpox2 has joined #nixos-dev
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
Shados has quit [Quit: No Ping reply in 180 seconds.]
{^_^} has quit [Remote host closed the connection]
V has quit [Remote host closed the connection]
atriq has joined #nixos-dev
risson_ has joined #nixos-dev
jpo_ has joined #nixos-dev
edef has joined #nixos-dev
lovesegfault has joined #nixos-dev
lopsided98 has joined #nixos-dev
asymmetric_ has joined #nixos-dev
edef is now known as Guest63305
Guest63305 has quit [Killed (rothfuss.freenode.net (Nickname regained by services))]