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
orivej has quit [Ping timeout: 260 seconds]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<hexa-> gchristensen: you dropped out of #nixos-mods
<gchristensen> thanks, hexa-
<gchristensen> samueldr: ccffd720 is a c2.large.arm, and 7bf7c136 is a mystery meat
<samueldr> mystery meat as those unique servers or mystery to both of us?
<gchristensen> the 2a5's that sphalerite just got working
<gchristensen> the unique ones we know of
<samueldr> good to know
<samueldr> is it difficult to add details about this, e.g. prefix the hashes with a type specifier?
<samueldr> good ol' hungarian notation but for hostnames?
<samueldr> currently running it in loop on the community machine to see if it's something that's somewhat reproducible on another system
<gchristensen> I can get you on a 2a5 machine if you want
<samueldr> if it doesn't in a couple iterations I guess it'll need investigation---
<samueldr> or that could help too :)
<samueldr> I wasn't sure if you were in a good place to do that
<gchristensen> I'm not Right This Minute, but I can do it in a bit :)
<samueldr> it's not a rush
<clever> Gaelan: and your stdenv.__bootPackages discovery saves the day!
cole-h has quit [Ping timeout: 272 seconds]
jonringer has quit [Ping timeout: 260 seconds]
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 272 seconds]
tilpner_ is now known as tilpner
supersandro2000 has quit [Quit: The Lounge - https://thelounge.chat]
abathur has joined #nixos-dev
supersandro2000 has joined #nixos-dev
<gchristensen> samueldr: https://github.com/samueldr.keys which of these three keys are most easy for you right now? ideally it is a file-backed key, not hardware
<samueldr> checking
<samueldr> gchristensen: the first one
<samueldr> ends with hkJ07WT
<Gaelan> clever: oh?
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix build -f . stdenv.__bootPackages.linuxHeaders --argstr system armv7l-linux --option builders 'pi@pi400 armv7l-linux,aarch64-linux /etc/nixos/keys/distro 4 1 big-parallel' --keep-going -L
<clever> Gaelan: this saves building a whole gcc, in the case when bisect has picked a good revision
<Gaelan> aha
<Gaelan> you running into https://github.com/NixOS/nixpkgs/issues/107386? I think it applies to armv7l as well
<{^_^}> #107386 (by Gaelan, 1 week ago, open): Can't build linux-headers on armv6l
<clever> Gaelan: ah, you also have that exact problem!
<clever> it segfaults for me
<Gaelan> yep
<{^_^}> #103183 (by expipiplus1, 7 weeks ago, merged): Fix GHC bootstrap in pkgsMusl and include patch for binutils/16177
<Gaelan> any C program that calls fprintf(stderr, "foo"); segfaults
<clever> ahhh
<samueldr> ran with default -j on the community box, and forced -j22 and both worked, so if it's a parallelization issue, it's harder to reproduce
<gchristensen> samueldr: save this next to that key. if it is called `id_rsa`, name it id_rsa-cert.pub: https://gsc.io/content-addressed/561c4dd13107b476c2366d1ddb12f82a4d7849376ba7ba0ad9e3b70eb17fe9df, then ssh root@147.75.55.110
<samueldr> right... it's not the default key for the machine
* samueldr looks how to configure that
<gchristensen> ssh -i ./path/to/id_rsa root@..?
<samueldr> oh, double duh
<samueldr> my mind is elsewhere
<samueldr> that wasn't what I meant, but I also was wrong
<gchristensen> ah
<samueldr> I assumed that ~/.ssh/foo.id_rsa-cert.pub wouldn't work for some reason
<samueldr> because I forgot to pass it using -i
<gchristensen> if it is called .ssh/foo, call it .ssh/foo-cert.pub
<clever> Gaelan: the puzzle then, how is it breaking fprintf?
<clever> Gaelan: is it only stderr, or also stdout?
<samueldr> gchristensen: yeah, it worked
<gchristensen> cool
<gchristensen> could make that self service almost
<Gaelan> clever: not sure.
<Gaelan> If I had to guess, it's because stderr, stdout, etc are globals, and the linker patch causes them to be put in the wrong region of memory
<clever> Gaelan: are you able to compare the `objdump -t` of the glibc, with and without the patch?
<Gaelan> it's the same glibc no?
<Gaelan> I think we're still using bootstrap tools at this point
<clever> or the binary the linker made
<Gaelan> I think I can, one sec
<clever> build the fprintf example from the ticket twice, with and without the patch
<clever> and then objdump -t both copies
<clever> binutils> unpacking source archive /nix/store/n1pp66v5mya20j0rq5mbzkak0pf6sal0-binutils-2.31.1.tar.bz2
<Gaelan> it's not in my cache at this point so it'll take a few
<clever> my cache has master built up to the failure
<clever> so i just commented out the patch...
<Gaelan> but yeah, nix-shell . -A linux-heaters [extra args], cc the program
<Gaelan> er, stdenv.__bootPackages.linuxHeaders
<clever> i think if you do stdenv.__bootPackages.stdenv.mkDerivation, you can build things
<clever> and it will build with the same env that linuxHeaders was building under
<clever> then you can just throw in a Makefile and main.c, and boom, segfault!
<gchristensen> samueldr: btw that key is only valid for 30 minutes
<samueldr> good to know
<samueldr> (I'm running the build already)
<gchristensen> you can hold the connection open or add your own from there, it'll get erased soon enough
<samueldr> good, reproduced on the first run
<abathur> is there a decent resource/rubric for when/whether sub-dependencies added only to package something else should get standalone packages and entries in all-packages?
<gchristensen> -> yes
<abathur> I could swear I've read that it's best avoided unless they're expected to provide standalone value in some form or another, but I haven't the foggiest where
<abathur> the answer is just, always add? :)
<gchristensen> samueldr: I'm heading to bed, here is a refreshed cert: https://gsc.io/content-addressed/e457a3035c2995ca40e444a8cc9a5f4a0737b52c188ca8146b15873871b682fc
<gchristensen> abathur: almost always yeah, only time to not is when it is automatically generated goop like for go/rust/node/etc
<samueldr> thanks, I also added a key to not get locked out as you suggested
<samueldr> I guess the -j1 build will take a hot minute
<abathur> basically I'm getting asked about adding resholve's deps on "oildev" and transitively on oil's own fork of some py-yajl project (for which the official fork is archived and hasn't been updated in 7 years)
<samueldr> fun! second pass at -j22 didn't fail :/
<samueldr> (I mean, --cores 22 so that the build uses make -j22)
rajivr has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
jonringer has joined #nixos-dev
<lovesegfault> why do we get so many beginners messing around with nix-env?
<lovesegfault> do the docs tell them to use it?
<abathur> basically any intro that is like
<abathur> oh, Nix is a package manager
<abathur> see, not scary
<abathur> nix-env -sadpants is just like apt-get -sadpants
<lovesegfault> :/
<lovesegfault> It's a _guaranteed_ way of finding unhappiness
<abathur> don't be scared, so easy!
<abathur> so familiar!
<abathur> just some weird unixy flags to pretend you understand!
<abathur> such comfort
<abathur> much home
<lovesegfault> :P
<lovesegfault> I think we're doing users a disservice by not plastering a warning on nix-env
<lovesegfault> it's a huge footgun
<abathur> I think it's a bit of a misfeature/footgun yeah
<abathur> I see why it's easy for a quickstart
<abathur> I'd probably prefer nix-shell?
<abathur> I think maybe part of it is that Nix isn't really taking an opinion on how to do it declaratively?
<lovesegfault> Yeah, nix-shell should be the intro tool
<lovesegfault> IMHO even using nix-shell with `-p` should be discouraged at the very first moment. writing a shell.nix file would be preferable
<lovesegfault> so they can see Nix-the-lang and Nix-the-tool
<samueldr> not discouraged no, but explained that for more than one specific tool you should write a shell.nix
<samueldr> nothing wrong with a nix-shell -p hello to run hello
<samueldr> because otherwise we'll see people complain that it's annoying to write a shell.nix to just run one thing
<samueldr> (not realizing the nuance)
<lovesegfault> samueldr: I don't mean in day-to-day usage, I use -p all the time :)
<lovesegfault> more when explaining things for the very first time
<samueldr> it's the exact moment you want to make sure they'll use -p for day to day usage instead of nix-env!
<abathur> I might be inventing this, but I feel like I recall there being some way to see nix that nix-shell -p is constructing?
<abathur> *see the nix
orivej has quit [Ping timeout: 240 seconds]
<immae> abathur: you want the nix... drv? If so you can add -v -v and search for "instantiating 'shell'" in the logs but it’s not very usable programmatically
<abathur> hmm; well the question was whether there was anything that'd show it in a pedagogically useful way... I may just be thinking of the error messages it throws when something doesn't make sense, not sure
<abathur> i.e. `nix-shell -p poo` == `with import <nixpkgs> { }; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (poo) ]; } ""`
<immae> oh
<immae> I don’t know such way
<abathur> to be able to help someone bootstrap up from what nix-shell -p is doing, to writing a shell.nix, not that the error form would be perfect for that
<abathur> just a thought yeah
<immae> If I may give a suggestion, I think nix-shell is nice for playing with nix but maybe not for understanding how things work behind the hood, there are some magical tricks happening to drop you in a shell that happens long after the "building" step that is the one important to understand
cole-h has joined #nixos-dev
<samueldr> "using nix" is an extremely loaded concept
<samueldr> do you want to manage packages? setup a development environment? package-up something?
<samueldr> do things better left untold?
orivej has joined #nixos-dev
peelz has quit [Ping timeout: 272 seconds]
kalbasit has quit [Ping timeout: 272 seconds]
jonringer has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 260 seconds]
<siraben> Not sure if anyone has done this, but the GPL only vs. GPL plus issue has popped up enough times I now have a template for requesting upstream: https://gist.github.com/siraben/ce58df016fc5ac481cf0f5995783bbd1
<siraben> With a suggestion to make it GPL plus
orivej has joined #nixos-dev
rycee has quit [Quit: Idle for 30+ days]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
__monty__ has joined #nixos-dev
<siraben> Why is Nix unstable manual already in mdbook but Nixpkgs is not? Does the docbook → md conversion have to be completed?
<siraben> ping ryantm
<gchristensen> lovesegfault: command-not-found recommends nix-env
<gchristensen> [grahamc@Petunia:~]$ jq -> The program ‘jq’ is currently not installed. You can install it by typing: nix-env -iA nixos.jq
<lovesegfault> gchristensen: yikes :(
<gchristensen> you couldfix it :) the source is in nixpkgs
<lovesegfault> I shall make a PR in the morning
<lovesegfault> if it were up to me nix-env would do like GNU parallel, make you sign a damn EULA before using it, lol
<siraben> having been a beginner not too long ago, I'm glad something as "intuitive" as nix-env existed, I used it as a sort of staging area before putting in configuration.nix then `nix-env -e '*'`
<siraben> Why does nix-prefetch-github return a differently encoded sha256 now? Is this the new preferred hash?
<ehmry> siraben: it would be, but because of backwards compatiblity only the old way should be used in nixpkgs
orivej has quit [Ping timeout: 256 seconds]
<ryantm> siraben yes, and we haven't decided what documentation system to use for nixpkgs.
<arianvp> erm on 20.09 boot.kernelModules is not working anymore for me :/
<arianvp> oddd
<arianvp> nvm pebkac =)
teto has joined #nixos-dev
supersandro2000 has quit [Quit: Ping timeout (120 seconds)]
supersandro2000 has joined #nixos-dev
orivej has joined #nixos-dev
kfound has joined #nixos-dev
kfound has quit [Remote host closed the connection]
supersandro2000 has quit [Ping timeout: 260 seconds]
supersandro2000 has joined #nixos-dev
<jtojnar> siraben: see https://github.com/NixOS/nixpkgs/projects/37 for tracking the progress
<lukegb> ehmry: if these are SRI hashes I don't think it's relevant any more
<lukegb> Because at master and 20.09 both should've shipped with a nix new enough to support them iirc
teto has quit [Ping timeout: 272 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
jonringer has joined #nixos-dev
kalbasit has joined #nixos-dev
<elvishjerricco> Continuing with my custom initrd, I'm trying to get rescue mode to work so I can actually reasonably debug stuff, but I get "sulogin: cannot open password database". I have /etc/shadow and /etc/passwd, so this is surprising
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
elvishjerricco has quit [Ping timeout: 260 seconds]
kini has quit [Read error: Connection reset by peer]
ashkitten has quit [Ping timeout: 260 seconds]
aranea has quit [Ping timeout: 260 seconds]
ashkitten has joined #nixos-dev
elvishjerricco has joined #nixos-dev
aranea has joined #nixos-dev
kini has joined #nixos-dev
peelz has joined #nixos-dev
<abathur> resholve PR has been partly reviewed but comments so far have mostly avoided the ~builder function; could use a look from someone comfortable weighing its design, implementation, and how it should be documented? https://github.com/NixOS/nixpkgs/pull/85827/files#diff-3d684ddd96525e3602c88f2f86d060a823352bebd0be0a0de43158d52a3ffd62
justanotheruser has joined #nixos-dev
kalbasit has quit [Remote host closed the connection]
kalbasit has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
<elvishjerricco> cat /proc/self/loginuid
<elvishjerricco> 4294967295
<elvishjerricco> Huh...
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
pmy_ has quit [Ping timeout: 265 seconds]
pmy_ has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
justanotheruser has quit [Quit: WeeChat 2.9]
pmy_ has quit [Ping timeout: 272 seconds]
pmy_ has joined #nixos-dev
red[evilred] has joined #nixos-dev
<red[evilred]> how does gcc / clang find the include and lib paths in a compile?
<red[evilred]> I'm finding that when I try to link against one library (ncurses) it finds it - but when I try to link against gtk, it doesn't
<red[evilred]> so trying to work out how to debug this
<red[evilred]> It's peculiar - because if I look at the compile line, the -L for neither ncurses or gtk isn't present - yet its still able to find the one for ncurses
<red[evilred]> but not gtk
<red[evilred]> so why/
<red[evilred]> ?
<abathur> my compilation knowledge is a bit thin, but I'll try to help rubber duck? :)
<abathur> do you know how whatever you're trying to compile specifies the two dependencies?
<samueldr> red[evilred]: using search paths
<samueldr> red[evilred]: nixpkgs does some massaging for default paths
<samueldr> red[evilred]: but some libraries (even outside of nix/nixpkgs) require helpers to build the compiler command-line
<samueldr> in your case, look at `pkg-config`
__monty__ has quit [Quit: leaving]