<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...
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
<{^_^}>
#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
<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