<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
<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
<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>
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?
<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]
<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]
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