worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ https://discourse.nixos.org/t/nixos-20-09-release/9668 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.09 RMs: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
<bpye> I realise this may be bad etiquette but I'm not sure if this is a nix bug as there seems to be no reason for this behaviour - https://gist.github.com/benpye/097e728cbcb0d830527ff7187241f313 - specifically a remote build fails and the only error output I get is 'not an absolute path: 'K'' which appears to be the following check
<bpye> if anyone could take a look at the log - perhaps there is some switch to get more info about the error that I don't know...
<bpye> https://github.com/NixOS/nix/blob/4638bcfb2cfb74cb5029c0da0af38bb7ca4b4a6f/src/libutil/util.cc#L114 - however I don't get any context for this error (ie. where 'K' has come from). I've tried removing the bits of my flake that look like they are failing but that doesn't appear to help, it just changes the derivation that breaks... I would appreciate
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
ris has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 246 seconds]
rajivr has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.1]
zhaofeng has quit [Ping timeout: 265 seconds]
cole-h has quit [Ping timeout: 240 seconds]
jonringer has quit [Ping timeout: 258 seconds]
zhaofeng has joined #nixos-dev
pmy has quit [Ping timeout: 240 seconds]
pmy has joined #nixos-dev
evils has joined #nixos-dev
<ehmry> bpye: I've seen this, but only when using the aarch64 community builder
marek has joined #nixos-dev
marek has quit [Changing host]
orivej has joined #nixos-dev
ris has joined #nixos-dev
bgamari has quit [Ping timeout: 258 seconds]
bgamari has joined #nixos-dev
<ekleog> can anyone give me some feedback on https://github.com/Ekleog/nixpkgs-check/ ? I'm writing it to get rid of the PR checklist, currently it would allow to cut it down to 4 boxes + “run nixpkgs-check and paste the output” and I'm hoping to do a few other changes to keep porting the boxes to get that number to 0 as well as add checks that aren't currently in the checklist (like “do desktop
<ekleog> files work?”), but I'd love some early feedback if possible :)
cole-h has joined #nixos-dev
jonringer has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
dongcarl has quit [Ping timeout: 265 seconds]
<tomberek> ekleog: i'll take a look
rajivr has quit [Quit: Connection closed for inactivity]
capisce_ has quit [Ping timeout: 240 seconds]
<ekleog> cool, thank you :)
<tomberek> anyone familiar with the recent advances in content-addressed store? I'd like to start using it, and have a use-case conceptually, but not sure what is available/working. Can one label a derivation as CA, or must one use `nix store make-content-addressable`?
<ris> is the "has: port to stable" label intended to go *on* the actual port to stable PR or on the master PR which "has" the "port to stable"?
<sterni> ris: on the pr which has been ported, it is the other state to needs: port to stable
<ris> sterni: perfect thanks
__monty__ has joined #nixos-dev
<supersandro2000> I am a bit concerned that people are totally fine with self merging PRs on 4 hour notice that touch 316 files. https://github.com/NixOS/nixpkgs/pull/117892
<{^_^}> #117892 (by 7c6f434c, 4 hours ago, merged): quicklispPackages: update, sbcl: 2.0.8 -> 2.1.2, and related stuff
<sterni> sounds like it was prepared and tested extensively beforehand
<sterni> may not be ideal, but not that dramatic
jonringer has quit [Ping timeout: 276 seconds]
<samueldr> 7c6f434c is the quicklisp/SBCL maintainer, and 316 files is a poor metric on generated files
<samueldr> I guess, reading the comment thread, the question is why were generated files changed manually to quote characters?
<sterni> I'd suspect it was changed in the generator
<samueldr> if you look at the history of one of the files, it's that the generator wasn't "fixed"
<supersandro2000> It was a treewide change
<sterni> double quoted strings remove the need for some escaping maybe it was just easier to use that and the change was applied to all generated strings
<supersandro2000> the generator should be changed to use " for single line strings
<samueldr> supersandro2000: "should" why?
<sterni> a treewide change is not the law
<sterni> also it wasn't really given much discussion at the time
<sterni> for example I learned of it after the fact
<sterni> there *is* a use for '' single line strings
<supersandro2000> samueldr: single line strings should use " not ''
<samueldr> supersandro2000: why?
<samueldr> how did you reach this conclusion?
<samueldr> where is the policy stating so?
<supersandro2000> idk, its just like this
<samueldr> is it?
<samueldr> because that's the first I've heard about it now
<samueldr> and it seems pretty arbitrary
<samueldr> I mean, there may be a reason to do so
<sterni> I bet 7c6f434c wasn't ask if they were okay with the treewide change affecting lispPackages
<samueldr> but at the time, no policy, no reason AFAICT
<supersandro2000> if a policy decided it, it would still arbitary
<samueldr> but backed
<samueldr> right now it's only a "headcanon" thing in some contributors and/or commiter's heads
<supersandro2000> yeah there is nothing in the docs
<supersandro2000> not like I read them complete
<supersandro2000> but you are using " for single line strings all the time, too. So not like it some outlandish rule.
<samueldr> hm?
<supersandro2000> its very common pattern to use " for single strings
<supersandro2000> just adapted that
<samueldr> but as long as there is no policy nor reason to stop using double-quoted-strings in single-line strings, I don't see it as a reason to either treewide change those or ask changes
<samueldr> and doubly so here since it touched generated files
<sterni> also even *if* there was a policy for not using a feature of the nix expression language it shouldn't necessarily apply to auto generated files
<supersandro2000> if something is in the tree people will copy it for new packages with the argument that they found it somewhere
<sterni> that is a different topic
<supersandro2000> unquoted urls are also not allowed even in generated files
<supersandro2000> maybe we should except generated files from treewide changes
<supersandro2000> siraben: maybe something to not for further changes to avoid the lisp files
<samueldr> yes, generated files shouldn't be touched in treewide changes
<sterni> and look there was a RFC and an official policy was established https://github.com/NixOS/rfcs/pull/45
<{^_^}> rfcs#45 (by 7c6f434c, 1 year ago, merged): [RFC 0045] Deprecating unquoted URL syntax
<samueldr> and sending fixes for styles to generators can also be done
<supersandro2000> samueldr: but how do you know those files are generated if you don't know it?
<samueldr> uh, maybe it doesn't specify it as much as I thought
<samueldr> but I do think it should be prefixed to each generated expressions
<samueldr> otherwise it's easy not to realize
<samueldr> by convention, a human and machine readable common prefix for such files could be helpful I guess
<samueldr> prefix, preface, prologue, whatever
__monty__ has quit [Quit: leaving]
cjb has joined #nixos-dev
cjb is now known as Guest29442
Guest29442 is now known as cjbayliss
cjbayliss is now known as cjb
<supersandro2000> samueldr: or we just collect them in a file so people at least know this
<supersandro2000> and that txt readme should be moved to docs/language-frameworks and be converted to markdown
<samueldr> most generated files I know of already state so at the top of the file
<supersandro2000> yeah they are not
<supersandro2000> also I am not touch that pile of braces
<supersandro2000> *touching
<sterni> well that may just be your problem then :p
<supersandro2000> yeah whatever
<supersandro2000> lisp in nixpkgs could get some spring clean
m1cr0man has joined #nixos-dev
<ekleog> how long 'till we get recursive-nix or anything with the same end-result, and can get rid of generated files altogether?
* ekleog hopes
<bpye> ehmry: I wonder if there is something weird with aarch64 then, this is also an aarch64 VM that I have running
justanotheruser has quit [Ping timeout: 250 seconds]
cole-h has joined #nixos-dev
<gchristensen> it'd be cool if our ISOs didn't depend on their entir eclosure
<samueldr> yes
<samueldr> but the plaintext of the iso contains store paths
<samueldr> unless we start compressing the iso output, which gets inconvenient for other reasons, I'm not sure what could be done
<samueldr> well, maybe the squashfs can be compressed in some way to help
<gchristensen> what if you could declare your build output a dead end
<gchristensen> and nix would ignore run time dependencies
<samueldr> hmm... final product?
<samueldr> dead end has negative connotations in my mind
<samueldr> would be cool, but at the same time, a footgun because of how the runtime dependencies *could* be in the store or not, and that'd make the result act differently
<gchristensen> yeah
<gchristensen> in the past I have used openssl to encrypt and then decrypt in another drv to break the connection
<samueldr> if the plaintext is still in the output, doesn't that re-do the connection on decrypt?
<samueldr> I might be assuming Nix scans for /nix/store paths
<gchristensen> nix does scan for it, but only looks for hash parts it knows went as inputs' runtime closure iirc
<gchristensen> either it didn't work and I just thought it did, or no, the two being separate builds seemed to break it
<samueldr> I never tried it, I had something similar in mind (but with much less strong encryption)
<samueldr> but I had in my mind that nix scanned the output
<samueldr> (I actually was thinking something as simple as XOR)
<gchristensen> yeah that'd be fine
<gchristensen> but I don't know how to xor in bash, and I do know how to openssl :) of course, you still have a problem for the openssl derivation.
evils has quit [Ping timeout: 240 seconds]
<samueldr> though, whether nix scans or not still leaves the previously mentioned footgun in
<gchristensen> these 1051 paths will be fetched (3479.12 MiB download, 7082.04 MiB unpacked): ... all to fetch the .iso :)
<gchristensen> hmm it looks like the nixos-unstable gnome iso doesn't start gnome
<gchristensen> oh a corrupt squashfs ... hmm... maybe my fault