<gchristensen>
when evaluation fails, GrahamcOfBorg now posts a link to the output of the step that failed. for an example, see https://github.com/NixOS/nixpkgs/pull/31835 click "Details" next to "grahamcofborg-eval-package-list"
orivej has quit [(Ping timeout: 248 seconds)]
mbrgm has quit [(Ping timeout: 240 seconds)]
LnL has quit [(Quit: exit 1)]
mbrgm has joined joined #nixos-dev
LnL has joined joined #nixos-dev
gchristensen is now known as fix`
fix` is now known as gchristensen
<Profpatsch>
domenkozar: It’s a bit of bash I added
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
vcunat has joined joined #nixos-dev
goibhniu1 has joined joined #nixos-dev
goibhniu has quit [(Ping timeout: 240 seconds)]
FRidh has joined joined #nixos-dev
<aminechikhaoui>
niksnut: curious why *.narinfo is implemented as objects in s3 binary cache vs object metadata
<aminechikhaoui>
for instance I would guess operations like sign-paths/check path existence would be much faster if it didn't have to download/upload actual objects
<aminechikhaoui>
and just modified objects metadata
<niksnut>
I don't think a HEAD request is much faster than a GET request
<niksnut>
also object metadata needs to be attached to an object, so you need the object anyway
<aminechikhaoui>
hm maybe yeah, didn't actually compare HEAD vs GET for s3 objects :-)
<aminechikhaoui>
just assumed HEAD is faster
<niksnut>
also we actually do HEAD requests
<aminechikhaoui>
niksnut: one more question is -r needed for nix sign-paths ?
<aminechikhaoui>
or deprecated like for nix copy
<niksnut>
I think it's needed
<aminechikhaoui>
well although if I use --all it doesn't matter
Jackneill has joined joined #nixos-dev
ma27 has joined joined #nixos-dev
<Profpatsch>
niksnut: Would you oppose to exposing the nixos/lib/testing.nix functions via `lib.testing` or moving them to build-support?
<Profpatsch>
They are completely independent of nixOS, right? Any nix builder can run them.
<Profpatsch>
not sure if they make sense in the lib namespace, putting them in pkgs feels like polluting the namespace even more with non-package symbols.
<Profpatsch>
Kind of dislike that build-support functions are put directly into pkgs, taking potential package names.
<niksnut>
they're actually pretty NixOS specific
<gchristensen>
any linux builder can build them, but they can only run nixos systems
<Profpatsch>
gchristensen: What do you mean by run?
<gchristensen>
the system inside the test is nixos
<Profpatsch>
They are „run“ when built, are they not?
<gchristensen>
yeah
<Profpatsch>
But the system inside the qemu is nixos, I see.
<Profpatsch>
It also re-imports ../.. (aka nixpkgs); wonder if that can be integrated without a reimport?
MichaelRaskin has joined joined #nixos-dev
goibhniu1 is now known as goibhniu
<gchristensen>
does anyone here not have permission to call grahamcofborg, and would like permission to call it? I'm looking to expand the list of trusted users
<hedning[m]>
I'm looking into the possibility of offering attribute completions for stuff like `nix eval -f channel:17.09 pa...` if the channel is cached.
<hedning[m]>
Is there a simple way to resolve an url to the corrosponding link in `~/.cache/nix/tarballs`? (re-implementing the logic in bash doesn't seem very promising)
<copumpkin>
is it legit for me to cherry-pick a commit to 17.09?
<copumpkin>
it's just a package fix that inadvertently broke darwin
<gchristensen>
sure, `git cherry-pick -x`
* gchristensen
almost said `cpToRelease` before realizing that is only an alias he has locally
<copumpkin>
:)
<copumpkin>
man I was out of date
<gchristensen>
one day I was trying to backport something, but PRs were moving too fast and every time I'd push my cherry-pick, my local copy was behind origin/release-xx.xx, so I automated it to be faster :)
<copumpkin>
I thought -x was the default
<copumpkin>
the man page points out that it used to be but isn't anymore :)
ma27 has quit [(Ping timeout: 240 seconds)]
<LnL>
I've backported a bunch of darwin fixes already
<LnL>
if we can't do that we shouldn't have a darwin channel :)
<vcunat>
+1
<copumpkin>
o/
<copumpkin>
orivej: does one pronounce your name with a Y like "yes" or a Y like "java"? or something else?
<copumpkin>
erm, J :")
<orivej>
like "yes"
<copumpkin>
cool, thanks
<copumpkin>
just figured I should be mentally pronouncing it properly :P
JosW has joined joined #nixos-dev
jtojnar has quit [(Quit: jtojnar)]
orivej has quit [(Ping timeout: 258 seconds)]
<gchristensen>
niksnut: does nix 1.12 come hard-coded with a key for cache.nixos.org?
<LnL>
I think so, but setting public keys now overwrites the default instead of appending extra keys
<Sonarpulse>
my nixborg build for that seems to have stalled?
<globin>
Sonarpulse: restarted hydra-queue-runner
<Sonarpulse>
globin: thanks!
<globin>
Sonarpulse: ping me or fpletz in this case, read it just by chance %)
<Sonarpulse>
globin: sure
<Sonarpulse>
seems obvious in hindsite :)
<Sonarpulse>
*hindsight
<niksnut>
github is complaining about potential security vulnerabilities in Gemlock files in the nixpkgs repo
<niksnut>
'These dependencies have been defined in nixpkgs‘s manifest files, such as pkgs/applications/misc/pt/Gemfile, pkgs/applications/misc/pt/Gemfile.lock, and pkgs/applications/misc/gollum/Gemfile'
<niksnut>
why do we have those anyway?
<copumpkin>
that's how bundlerEnv works
<copumpkin>
it doesn't feel like it should need them
<copumpkin>
maybe it was just accidental that they got required and a minor tweak could remove them
ma27 has joined joined #nixos-dev
<copumpkin>
at the same time, the issues are probably real
<copumpkin>
they probably got locked to old versions a while ago and nobody updates them very regularly
Sonarpulse has quit [(Ping timeout: 258 seconds)]
JosW has quit [(Ping timeout: 255 seconds)]
<copumpkin>
FRidh: you around? I'm seeing an annoying warning printed to stdout (!) from urllib3 on release-17.09: /nix/store/1gk18fb4bv8jcfm56zxrwzllwsaspshf-python2.7-urllib3-1.22/lib/python2.7/site-packages/urllib3/contrib/pyopenssl.py:46: DeprecationWarning: OpenSSL.rand is deprecated - you should use os.urandom instead
<copumpkin>
import OpenSSL.SSL
<copumpkin>
it's like a 3rd-level transitive dependency of the thing I'm using but I guess it spits out the warning the moment you import it
goibhniu has quit [(Ping timeout: 258 seconds)]
<Mic92>
I would say, open an issue for Gemfiles with security issues.
<copumpkin>
niksnut: is there a way to run a nix-build with a force rebuild on fixed-output derivations?
<copumpkin>
I guess I can do the grep outputHash on the .drvs like in that recipe for downloading all fixed output hashes
<LnL>
using --check also works for fixed output drvs
<copumpkin>
yeah, I just need to list them all, which I guess I can do with nix-store -q --requisites and grep outputHash
<LnL>
or do you want the entire chain?
<copumpkin>
yeah
<copumpkin>
mostly to catch FO hashes that someone forgot to update
<copumpkin>
and to make sure they're actually deterministic
<clever>
that reminds me of a weird bug i once saw, every time a user fixed the hash to match what nix claimed, a new hash came up
<clever>
turns out, that was the hash of a 404 page, including a timestamp, but the http server returned it under code 200
<copumpkin>
did it depend on a path reference with a result link in it?
<copumpkin>
oh lol
<LnL>
I'm getting unable to open SSH connection to 'ssh://foo' since the latest nixUnstable bump
<clever>
and because nix doesnt keep the initial failed download, it has to download it a second time and get the previous hash
<clever>
there was a "recent" change to nix-prefetch-url, where such failed downloads, get renamed based on their actual hash
<clever>
so if you fix the nix expression, it will use the previous output it was calling a failure
<clever>
then it only has to download once
<LnL>
did something change?
<clever>
that nix-prefetch thing was a new feature
<clever>
rather then throwing out the "invalid" version, it keeps it, as if you had downloaded it under the right hash (at a new path)
<clever>
so if you ask for it again with the right hash, it already has it
<copumpkin>
do those bad hashes get GC'd?
<copumpkin>
worst-case scenario is a nondeterministic 50GB download
<clever>
there is nothing rooting those bad ones, so a normal gc will delete them
<clever>
and i think you need to give nix a special flag to enable that
<clever>
also handy, even without that flag, nix keeps all failed builds (normal and fixed-output) in /nix/store after the failure (and they arent marked as valid)
<clever>
so you can just read the partial result
<copumpkin>
oh I see
<copumpkin>
they end up in the store as fixed-output derivations with the correct hash?
<copumpkin>
that's cute
<clever>
yeah
<clever>
a GC will get those invalid outputs first, then move on to valid and lacking roots