<moet>
they aren't removed when i do nix-collect-garbage, and i have boot.loader.systemd-boot.configurationLimit set to 10
<pennae>
remove old collections, or `nix-collect-garbage -d` (if getting rid of all but the current is fine)
<moet>
pennae: i'd rather not get rid of all but the current, but i just ran `nix-collect-garbage --delete-older-than 30d` and the above situation is the result
<moet>
does this mean i've actually run `rebuild switch` 150 times in the last 30 days? lol...
<pennae>
could be? tends to happen a lot :D
<moet>
if i were to do `nixos-rebuild test` would that prevent creating these gc-roots?
elvishjerricco has quit [Remote host closed the connection]
elvishjerricco has joined #nixos
<moet>
i did `nix-collect-garbage --delete-older-than 2d` now and nothing was deleted
<aaronjanse>
I think you need `sudo` to delete system stuff
<moet>
oh dang.. aaronjanse you're right.. i thought nix-collect-garbage would just handle that via the nix-daemon
<pennae>
ah, just assumed you'd be running gc as root too
proofofkeags has quit [Ping timeout: 240 seconds]
<moet>
i don't run anything as root if i don't have to... the nix-store --gc and nix-collect-garbage commands don't advertise that they could delete more if given additional permissions in their CLI output
<moet>
`61461 store paths deleted, 112444.60 MiB freed` i'm saved!
<pennae>
deleting generations of other users would be a very bad thing to do though :<
Qwerky has joined #nixos
<pennae>
maybe it'll let you do that if you're in trustedUsers. haven't tried
<moet>
pennae: sure, i just mean that the commands should maybe indicate that some things which would have been deleted were in run by root couldn't be deleted..
<moet>
the manpage for `nix-store --gc` doesn't mention needing root perms to delete anything
<moet>
same with nix-collect-garbage
<aaronjanse>
Yeah in general I'd like to see a lot more helpful info from that
<aaronjanse>
Such as listing which roots are the largest and how to delete them
<aaronjanse>
Maybe that exists and I just don't know about it
<radvendii>
so i'm trying to cross-compile openssl for windows using MinGW, and it's trying to build coreutils (presumably as a dependency). when i look at the package though, coreutils is only used if the openssl version is >=1.1.1, which it's not.
<radvendii>
it's build 1.0.2, which is special-cased in for MinGW, presumably for this reason (or something like it)
<radvendii>
anyone know why it would still be trying to pull in coreutils?
<simpson>
YaoiFangirl420[m: The channel list isn't complete; it's just where the bot happens to be.
<simpson>
For packaging requests,
<simpson>
*just go for it.
okanua has joined #nixos
<radvendii>
okay i solved my coreutils conundrum, it's coming from perl
<radvendii>
seems like we should be able to build perl for windows. it depends on coreutils dafka when we *are* cross-compiling, very strange...
<PhantomFutaba>
🤔 Can I write inputs.A.inputs.B.inputs.C.follows = "C'" (C' is declared as a input flake) in flake.nix ?
Wulfsta has joined #nixos
<Wulfsta>
I have a VPS to which I had the provider add both an additional ipv4 and ipv6, I am trying to add the ipv6 address to the interface on my machine and am seeing a `dadfailed tentative`
<Wulfsta>
Anyone know what might be the cause?
<Wulfsta>
these addresses are added using networking.interfaces.<interface>.ipv6.addresses = [ ... ]
ddellacosta has joined #nixos
<Wulfsta>
I would hazard a guess that dadfailed means it's a problem on their end with the switch, but am not sure
okanua has left #nixos [#nixos]
ddellacosta has quit [Ping timeout: 240 seconds]
okanua has joined #nixos
<radvendii>
this is strange. if i configure cross-compilation to windows, and then access pkgsStatic.stdenv, it has buildPlatform.isWindows == true
moet has joined #nixos
<radvendii>
even though i'm definitively not building on windows
<jgt>
I am unable to download one specific store path. I've tried from my laptop, and also from an EC2 machine on AWS. No dice in either case. I'm trying `nix-store --realize /nix/store/jrjg838gd6svd8chiv8gkwbm235fnsik-nodejs-12.18.4` but it just hangs.
PhantomFutaba has joined #nixos
<jgt>
Running `nix-shell -p nodejs` works without issue, although it gives me a different nodejs version, and thus, a different store path.
<apo>
Wulfsta: just set any vhost's default to true and its listen address to the correct value, the name doesn't matter
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<matthewcroughan>
Can a derivation/package change system services?
<matthewcroughan>
There's a package that needs to change the default value of a service in the OS, how can this be done? Through a flake perhaps?
<colemickens>
suddenly I can't evaluate an aarch64 drvPath on x86_64-linux? :/
<MysteriousSilver>
hi! Trying to make zsh my default shell, why doesn't `users.defaultUserShell = "pkgs.zsh"` work? It returns the error message: The option value `users.defaultUserShell' in `/etc/nixos/configuration.nix' is not of type `path or package'. I have installed zsh
o1lo01ol1o has joined #nixos
mayhew` has joined #nixos
mayhew has quit [Ping timeout: 265 seconds]
philr has joined #nixos
berberman_ has joined #nixos
berberman has quit [Ping timeout: 276 seconds]
jgt has joined #nixos
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<{^_^}>
[nixpkgs] @lukegb merged pull request #107604 → nixos/exim: Make queue runner interval configurable and reduce it to 5m by default → https://github.com/NixOS/nixpkgs/pull/107604
<XgF>
kaligule: you can add pkgs.home-manager to your environment.systemPackages, though it may be a little older. Theres also a Home Manager nixos module but that might couple things more than you like
<kaligule>
XgF: Thanks. What do you mean by "more than you like"?
<XgF>
kaligule: the nixos module approach means your nixos configuration.nix and home-manager config get tightly integrated. I like keeping them moderately separate because e.g. I use my HM config across machines, and even on macOS
<raboof>
I want to run a php application in a container, so with apach/nginx, php, the app itself, and some configuration and extra tools.
<raboof>
sounds like it'd be useful to use the nixos module, so I'd use nixos-generators rather than the nixpkgs dockerTools, does that sound reasonable?
<simpson>
raboof: It sounds like it's not going to work like you want. NixOS configuration is for systemd, but your container would not be set up that way.
<raboof>
simpson: I wouldn't mind terribly to have systemd in the container, but it would be neater without, yeah :). also just noticed nixos-generators doesn't have a docker backend anyway ;)
uznog has joined #nixos
<simpson>
systemd isn't available in our containers, AIUI.
<gchristensen>
docker is intended to contain a single service that runs, so maybe you'd have like a php-fpm for your php app and a container with nginx fronting it
<gchristensen>
so you let go of the module system because you're not managing >1 service, and leave service management to the container runner
ahmed_elgabri has quit [Ping timeout: 260 seconds]
<pennae>
... that reminds, we wanted to fix nixos containers not stopping properly on system shutdown
<raboof>
right, so I'd create a derivation with a start script that references apache/nginx and its configuration, php module, the app repo etc, and use that as the `content` of `pkgs.dockerTools.buildImage` then it'll put the closure of that content in the docker image and I can invoke it from the `Cmd`?
<simpson>
Sounds about right.
<simpson>
And yeah, as gchristensen says, big professional deployments will usually separate the Web frontend (nginx/etc.) from PHP workers, letting them scale independently. At least one practical reason to do this: You'll want to kill PHP-FPM containers if they stop responding to health checks, but nginx containers won't do that nearly as often.
<gchristensen>
raboof: in almost every case you can and should completely ignore the "content" parameter
<gchristensen>
just Cmd = pkgs.writeScript "start" ''${yourapp}/bin/start -c ${configfile}'';
respawn_ has quit [Read error: Connection reset by peer]
supercoven has quit [Read error: Connection reset by peer]
waleee-cl has joined #nixos
supercoven has joined #nixos
respawn_ has joined #nixos
<radvendii>
is there a way to force `nix build` to actually build it, as opposed to using the cache? I added --show-trace and now all I'm getting is "cached failure of attribute"
<lukegb>
Are you using flakes?
<radvendii>
yes
<radvendii>
oh, and --rebuild doesn't help, i still get the same message
cole-h has joined #nixos
jgt has quit [Remote host closed the connection]
ahmedelgabri has joined #nixos
<radvendii>
oh. just adding whitespace made it rebuild. i thought it was using the same kind of caching the nix store does
jgt has joined #nixos
stree has joined #nixos
jmeredith has joined #nixos
haijuno has quit [Ping timeout: 250 seconds]
cfricke has quit [Ping timeout: 245 seconds]
<siraben>
radvendii: strange that --rebuild didn't help
<pennae>
kind of confused by the nixos-containers situation. what is the state of those? (because we remember someone saying they're in a bit of a state, there's a PR open about restart being a bit broken, we've found that shutting down the host will kill machined and dbus before the actual containers so they'll always timeout on stop and be force-killed)
<pennae>
at least the latter should be easy enough to fix by after = bindsTo = [ machined dbus ]
<pennae>
but is it even worth taking up review time with that?
respawn_ has quit [Quit: Leaving]
<pie_>
grahamc[m]: you do this kind of stuff, terraform / terranix is good? I've never done any cloud stuff
dupon1 has quit [Ping timeout: 260 seconds]
emilsp has quit [Quit: bai]
<pie_>
pennae i have no idea what the situation is but i use them with extra-container so im happy about any improvements >_>
dupon1 has joined #nixos
tomberek has joined #nixos
<bqv>
Is there (even close to) any answer to the problem of ifd derivations being gc'd?
<lunik1>
what is the best way to create a module for a service that expects a writable config file?
<cole-h>
Why does it need to be writable?
ahmed_elgabri has joined #nixos
<lunik1>
there's a webui to manage the settings, and to perform initial set-up
<bqv>
pie_: DigitalKiwi: so the current solution summed up is "append the list of eval-time deps to your final output's deps"
<pie_>
bqv: which is what i would have guessed as the workaround. ive no idea how to do it but it sounds like it should probably work
<pie_>
and it also sounds reasonable?
<bqv>
Which isn't unreasonable, I've just been keen to avoid that if possible cause I use ifd way too much
<bqv>
Yeah
<pie_>
i mean, how else could it work
<DigitalKiwi>
bqv: i'm not sure if it's the same cause of the problem or even the same solution is applicable
<bqv>
True
ahmedelgabri has quit [Ping timeout: 250 seconds]
<pie_>
no really though,how else couuld it work?
<lunik1>
also I believe the config file is also occasionally migrated to new schema versions
<bqv>
I was expecting there to be by now some way to convince nix to root them as theyre used, or at least to list them somehow so you could do that manually after build
<pie_>
lunik1: you might have some luck searching for precedent in nixpkgs issues/prs. I guess if you _want_ mutability, you would perhaps generate the config via nix and then copy the config to a mutable location
<pie_>
clever: didnt you do something involving rooting ifds at osme point
<pie_>
or something about dumping import during eval
<pie_>
you could use importscope to wrap import statements to trace their argument during eval, not sure if that helps (you can probably get something from multiple -v to nix as well?). I don't actually know offhand how youd tell how something is an ifd root
<DigitalKiwi>
that's why i don't make PRs anymore someone else already does it before i start
<pennae>
still not sure whether binding do machined and dbus is actually *correct*, it just *works*
<pennae>
for one it might promote systemd updates to container restarts
<pennae>
eh, will just retest everything and open a thing. then it's for y'all to decide :>
<DigitalKiwi>
it's a very good solution so long as it doesn't get popular
<pennae>
considering that the stop script is `machinectl stop` i just don't see what else would do, other than maybe stopping in a completely different way
ahmed_elgabri has quit [Ping timeout: 250 seconds]
pushqrdx has quit [Remote host closed the connection]
Lord_of_Life_ has joined #nixos
thblt has joined #nixos
Lord_of_Life has quit [Ping timeout: 268 seconds]
devhell has joined #nixos
devhell has quit [Client Quit]
<andi->
took me a while to realize you typoed there
<andi->
pie_: ^
snajpa has joined #nixos
ddellacosta has joined #nixos
Lord_of_Life_ is now known as Lord_of_Life
<scott>
graalvm11-ce contains binaries named `ruby` and `node`, among other things, and i'm wondering how to deal with this if i want to put graalvm11-ce on my path (via home-manager packages, for example)
<scott>
i'm not sure how it works, because 1) if i have node and graal, i get the node binary, but if i have just graal i get its `node`, and 2) if i have ruby and graal, it actually fails with a "collision between" message
sss has joined #nixos
<{^_^}>
[nixpkgs] @risicle opened pull request #120616 → qemu: patches: use correct CVE numbers for CVE-2021-20221 & CVE-2021-20181 → https://github.com/NixOS/nixpkgs/pull/120616
<pie_>
andi- oh pff
<lukegb>
scott: if you only want the non-conflicting things, you can use lowPrio
<pennae>
nixos tests are not fast
<scott>
lukegb: thanks
tlaxkit has quit [Quit: Konversation terminated!]
<scott>
i'm generally interested in selecting a subset of binaries from a lot of different packages for my PATH, but if that's not a thing that exists yet, i'll just make it myself. `lowPrio` is a good fix for now
<scott>
well, selecting a subset + renaming some. it shouldn't be too hard, i think
<scott>
it's not really important now, but it's mysterious to me why node overrides graalvm11-ce silently but ruby and graalcm11-ce directly conflict
<matthewcroughan>
simpson: I read over that a bit, for me I think the "maintainer" status should be lax, as it currently is.
<matthewcroughan>
For example, try going to #lineageos and seeing how friendly they are towards contributions.
<matthewcroughan>
They basically "don't want your crap code". More or less.
<matthewcroughan>
Nix, being functional, being as error resilient as it is, means we can accept lower quality submissions, in my opinion.
dev_mohe has joined #nixos
<simpson>
Not unreasonable. All code is bad, after all, and nobody should have to maintain any code, especially code that Somebody Else has placed before them like a free puppy.
<matthewcroughan>
The worst that can happen is that we change the defaults for the worse, or increase the closure size. NixOS services are obviously more important and require more thought.
<matthewcroughan>
That's why my node-red submission hasn't been accepted, because I haven't made a NixOS test for it yet.
<matthewcroughan>
I suggested that this was an issue in #nixos-dev but got disagreement. So maybe I'm wrong. It may be the case that the coq ecosystem is just that difficult inherantly.
<simpson>
I'm not really sure what that means. At the end of the day, all package descriptions unroll to a very flat layout. The complexity is wholly within the ways that we structure code to make it *more* maintainable, not less maintainable.
<matthewcroughan>
simpson: would you like to see?
<matthewcroughan>
Do you want the red pill, or the blue pill?
<simpson>
I want contributors to own the means of production.
hiro98 has quit [Remote host closed the connection]
dev_mohe has quit [Quit: dev_mohe]
kaliumxyz has joined #nixos
moet has quit [Ping timeout: 246 seconds]
mjlbach is now known as aterius
aterius is now known as mjblach
mjblach is now known as mjlbach
<remexre>
anyone know how to get rustdoc w/ crate2nix? don't see anything about it on the issue tracker, can't find anything in nixpkgs that does it
<matthewcroughan>
Can you tell me if you think the tl;dr is what we think overrides should look like?
<matthewcroughan>
trial and error, hard to read, etc.
<matthewcroughan>
I would edit the part where I said they removed the src attribute, because that is not accurate. They are just passing it around and inheriting it.
<simpson>
matthewcroughan: TBH it sounds like this is more of a documentation issue than an API issue? If it's an API limitation, then generalize and allow for the versions to be passed in, I suppose.
<matthewcroughan>
It's a really complex package.
cfricke has joined #nixos
<matthewcroughan>
simpson: documentation, possibly. But why does the coq ecosystem need to do it in this way in the first place?
<matthewcroughan>
Why can't it be like every other package?
<matthewcroughan>
Is coq really this broken in the background that we need to make such a complex derivation?
<matthewcroughan>
Or is coq complex for a good reason, that requires this derivation to be this complex?
<simpson>
I didn't know that there was such a thing as "every other package", TBH. I think that whenever there's a boundary between languages, then the code near the boundary ends up looking like both languages.
<matthewcroughan>
simpson: well, I've found that pretty much every package I've used has an SRC attribute.
<matthewcroughan>
Overriding this attribute is easy, therefore, since it's conventional.
<simpson>
Also yes, most ecosystems never imagined that packages might be treated as capabilities. Look how many languages don't know about capability-safety or even memory-safety.
xkapastel has quit [Quit: Connection closed for inactivity]
<simpson>
I think that the original question is begged. I don't see any problems, just code which could be clearly changed to suit whatever desires one might have.
<matthewcroughan>
Sure, everything is that way.
<matthewcroughan>
There is no package in nixpkgs, and never will be, where what you have just stated won't be the case.
<matthewcroughan>
Nix is the language that allows your statement to be true.
<matthewcroughan>
To me, src is like a standard attribute. There is no such thing of course. But I expect to be able to override it the same way for any package. Coq stands out from the rest.
<matthewcroughan>
Src is something you shouldn't touch in the coq package, whereas with most other packages in nixpkgs you touch it all the time.
work_ has quit [Quit: Connection closed for inactivity]
<matthewcroughan>
So, to me, it seems needlessly complex. But maybe it's necessary complexity. I do not know how to determine whether it is necessary or not though.
<simpson>
Sure. And so we come to the nebulous "we"; what changes do "we" actually want to make to Coq?
<pennae>
hah. nixos containers won't shut down cleanly when stopped while starting (within a startup short window) because systemd seems to ignore its own shutdown signals
<stepcut>
I ran `nixos-rebuild switch` and for good measure `nixos-rebuild boot`. But when I reboot, grub seems to default to generation 18 instead of generation 22 -- even though /boot/loader/loader.conf has `default nixos-generation-22`. Is there a workaround?
ddellacosta has quit [Remote host closed the connection]
<stepcut>
I am a 7 hour drive from the machine, so I can not select the correct grub entry at boot time
<infinisil>
pie_: "Note, the shebang line doesn't use eval-config, so imports dont get evaled, etc., you must deep merge this in, it'snot a module"
<infinisil>
That might be the problem :)
<pie_>
did i just outsmart myselff
<immae>
stepcut: is 18 the first of the list?
<infinisil>
Just try it as a normal module first
pcarrier has joined #nixos
<stepcut>
immae: which list? What is displayed when grub boots? I don't think so
<pie_>
infinisil: what thats supposed to mean is that when its called by the shebang, it has to be deep merged in because doing it without eval-cnfig meant imports wont get evaluated etc
<immae>
stepcut: you could look at the content of the file to figure out
<pie_>
infinisil: however unconditional deep merging means that i "need" to put it in passthru to not create more boilerplate, so that it doesnt error about unknown .shebang options
<stepcut>
immae: what file? from what I can tell all the entries are files listed in /boot/loader/entries/
<pie_>
the "this is not a module" part shouldnt be an issue , because the deep merge happens on the attrset of the thing that _is_ a module
<pie_>
infinisil: does that make sense?
<pie_>
i did have a variant of htis that works, now im just trying to factor it a bit
<stepcut>
I'm going to backup
<stepcut>
I seem to have this in my configuration.nix,
<immae>
stepcut: I’m not familiar with /boot/loader/loader.conf, I’m trying to figure out why it choses 18 rather than, say, 3 or 12
<DigitalKiwi>
19:06 matthewcroughan: Actually, the worst thing we can do in Nixpkgs is make the derivations so complex that overriding them is really hard :D <-- i don't know if that is or is not the worst thing but the reality is that unfortunately the rules of the game aren't as simple as "don't do the worst thing and we'll be fine" sometimes and a problem for some is a feature for others, there's always the chance of 'death by thousad cuts', and sometimes j
<DigitalKiwi>
ust one paper cut gets infected and gangrenous, etc...
<stepcut>
immae: I seem to be using systemd-boot EFI boot loader -- not grub I guess
Lord_of_Life_ has joined #nixos
<DigitalKiwi>
simpson++ this is for having to read that gibberish lol
<{^_^}>
simpson's karma got increased to 50
<immae>
stepcut: do you have other files in /boot ? that would help figuring out if other boot manager did take over (like grub as you suggested)
<immae>
(or in /efi, if you have other unexpected .img files)
<stepcut>
immae: I have these directories in boot, 7c6be82f5e8448bfa02d78db49b7b9c6 EFI loader, the first one is empty
<simpson>
DigitalKiwi: It's all good. Like, I could *guess* at why some folks want to use nixpkgs in certain ways, but it's way easier for folks to explain themselves.
jonringer has quit [Remote host closed the connection]
<DigitalKiwi>
earlier when i said that i don't make PRs anymore because someone else already does it first; that is a thing that does happen sometimes but at least 80% of the reason i haven't been doing PRs as much as i used to has been because (noticed at least) since december nixos-unstable/nixos master/nix-daemon have made it nearly impossible to nixos-rebuild ... or even just build... without causing my computer to crash
<pennae>
we had that not too long ago because an nvme had a bug in its powersave code, taking the system down when linux decides to put it to sleep for a bit :/
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<DigitalKiwi>
possibly yes but it happens on multiple varying spec/model/manufacturer computers
<DigitalKiwi>
it's not just one problem either, some kernels i'd boot and not have wifi ;p
zupo has joined #nixos
<matthewcroughan>
DigitalKiwi: It's all about community yeah.
<matthewcroughan>
This is subjective.
<matthewcroughan>
An OS is a community project. In my view, this is one of the best communities I've ever been a part of.
<matthewcroughan>
It is grassroots, it is constantly critical of itself, it is wanting to show the world a better way of doing things. It is polite.
<{^_^}>
[cabal2nix] @villesokk opened pull request #489 → Improve error message when the source URI is a directory that doesn't contain a .cabal file → https://github.com/NixOS/cabal2nix/pull/489
<matthewcroughan>
It is helping upstream.
<matthewcroughan>
Do you not believe that Flakes lower the burden?
<matthewcroughan>
Nixpkgs will become nothing more than what we want to be integrated behavior in NixOS. Integrated behavior meaning ease of use when using packages.
<matthewcroughan>
Nixpkgs can't do everything, because of the bottleneck of maintainership. If we want things to be fresh, the way to do that is to have a registry of flakes.
griff__ has joined #nixos
<DigitalKiwi>
i spent at least 3 days straight and several more days/weeks git bisecting a plasma bug that couldn't even find the right commit because of staging
<matthewcroughan>
Just like Docker, to be honest. The upstream projects would maintain their own flake like they maintain Dockerfiles. Maybe having a flake.nix in an upstream project and putting a PR into nixpkgs' inputs, means that hydra will build your flake and offer it to the world.
maralorn has quit [Quit: issued !quit command]
<matthewcroughan>
DigitalKiwi: Do you think this would happen with any other piece of software than plasma?
<matthewcroughan>
I'm biased in thinking that the underlying software sometimes makes things harder.
<matthewcroughan>
I may not have fully understood your concerns, sorry.
stree has joined #nixos
<stepcut>
immae: running, `bootctl status` shows that generation 18 is being selected as the default -- now to figure out why
<matthewcroughan>
Well maybe we need to make a catalogue of these small cuts.
<matthewcroughan>
And basically address them, by complaining about them in little federated communities.
<matthewcroughan>
I mean, if tweag complained about something, it'd be addressed.
<clever>
bqv: rebased
<immae>
stepcut: ok that means you can at least workaround it by setting it manually to 22 if necessary, right?
<matthewcroughan>
if nlnet complained, it'd be addressed, if a user in IRC complains it has less weight, so we need communities that aren't this one to form and start complaining.
<stepcut>
immae: fingers crossed, I tried `bootctl set-oneshot nixos-generation-22`, now time to reboot and see if it comes back :)
<matthewcroughan>
I guess that's how we die though, because then changes that cause problems can't be made, for fear of upsetting those userbases.
<bqv>
clever: thank you! <3
<matthewcroughan>
Kind of what happens with Yocto/Bitbake to be honest.
<immae>
stepcut: ok :)
<pennae>
we certainly don't want to step on anyone's toes by doing things :/
ddellacosta has joined #nixos
<matthewcroughan>
Ah politics :P
<matthewcroughan>
Everything is reproducible at the end of the day.
<matthewcroughan>
These issues effect contribution, not usage.
<matthewcroughan>
DigitalKiwi: I'd love to read your critiques, if you could make a forum post about it, or maybe you already have, lend me a link to it.
<matthewcroughan>
having trouble reading up in my irc client, for your stuff.
<DigitalKiwi>
i like some of it and other things have been a real pita
<stepcut>
immae: worked!
<immae>
stepcut: cool
<immae>
but that’s not a permanent solution :D
<immae>
can you say on which nixpkgs channel/commit you are?
ahmed_elgabri has joined #nixos
<stepcut>
immae: no.. `set-default` would make it stickier -- but then when I have generation 23, it'll be a problem. But maybe there is someway to clear that default stuff and get it to look at the loader.conf value instead. But that is something I'll worry about next time I am physically near the machine
<immae>
ok as you want :)
<DigitalKiwi>
anyway a lot of it's just like not even anyone's fault really and i'm just incredibly good at finding everything that's broken ;P
<immae>
stepcut: One thing you can check: when you do a nixos-rebuild switch, check that you have a "updating systemd-boot from 22 to 23" message
<immae>
(or if you remember seing that message from the last run)
<stepcut>
immae: I may be on nixos-20.09 channel. I'd have to do some more digging to be sure
<immae>
(cat /etc/os-release will tell you everything about that)
<stepcut>
immae: the install is 20.03 -- but that may not be what nixos-rebuild is pointing to
<{^_^}>
[nixpkgs] @Ma27 pushed commit from @TredwellGit to release-20.09 « wireshark: 3.4.4 -> 3.4.5 »: https://git.io/JO54G
<immae>
ok
<immae>
stepcut: if next time you do a nixos-rebuild you don’t see the message I quoted above, that probably means that some of your configuration (partially) overrode the boot loader from systemd to some other thing
<DigitalKiwi>
and sometimes the universe just decides to send everything it can at you and for a lot of people it's just been one of those years for obvious reasons but i'm an over under achiever and i had a head start https://twitter.com/ArchKiwi/status/1249988795568656390?s=20
<clever>
bqv: it was this, but names have since been assigned
<bqv>
Figured so
<catern>
as a specific example it would be cool if, say, adding texinfo to list of packages in the profile, would cause the profile to be built with a populated share/info/dir
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
bqv: pushed
<catern>
I'm sure there are other examples of things where merely symlinking everything together into the profile isn't sufficient, how is that dealt with usually?
<bqv>
Awesome!
griff__ has quit [Quit: griff__]
rubm has joined #nixos
<dupon1>
Hi, I notice a really weird behavior from NixOS with NAT, it sends source packet to next hop without any translation, next hop router receives a packet from the private network. Formerly NAT was done by a VM (which worked well) and is now done by host/hypervisor and is totally broken :|
<catern>
this example depends on using declarative package management: https://nixos.org/manual/nixpkgs/unstable/#sec-gnu-info-setup is there a way to make it work with imperative package management? I'd need to run that small script after each package installation, but how can I do that?
<clever>
catern: that shell script needs a copy of a shell
<clever>
catern: that shell needs a copy of nixpkgs
<clever>
catern: nix-channel uses nix-env -i to install nixpkgs
<clever>
now what?
<catern>
Nix already itself depends on /bin/sh tho I think?
<clever>
thats an impurity though
stepcut has quit []
<catern>
how is that any more impure than Nix depending on curl?
<catern>
libcurl rather
<gchristensen>
\
<gchristensen>
/bin/sh is not necessarily present in the build environment
<clever>
catern: files downloaded with curl are fixed-output, and nix enforces that they have the expected hash
<catern>
gchristensen: okay, fair enough, but what I really mean I guess is that Nix can bring along anything it wants as a "builtin", and it does that for curl
<gchristensen>
yup!
<gchristensen>
and one of the things it brought along as a builtin is buildenv :)
<catern>
mmmm I don't know, I still feel like there should be a way to avoid writing this in C++...
<gchristensen>
maybe rust
<catern>
or Rust :)
<gchristensen>
C, then?
<gchristensen>
I'm not keen on Nix itself carrying a dependency on a shell and coreutils
<catern>
but I guess there's a big difference between exposing curl directly and implementing fetchurl
<catern>
using curl
<catern>
exposing curl directly as, basically, part of the Nix language would hugely grow the spec for the Nix language
<catern>
I guess I can believe that there is no way to implement this in a Nix expression without hugely growing the interface of Nix
<catern>
and I'm guess it was already ported away from Perl once :)
<catern>
guessing
<gchristensen>
in generalyl the nix expression language doesn't have much semantics w.r.t. what happens during a build, and merging build outputs is pretty firmly "whats up in the build"
<catern>
right, makes sense
supercoven_ has joined #nixos
supercoven_ has quit [Max SendQ exceeded]
<catern>
so anyway I guess this is yet another reason why nix-env is bad
<catern>
it's very hard to extend this...
supercoven_ has joined #nixos
<catern>
it would be interesting if there was some way that the user could configure what builtins:buildenv runs though
<gchristensen>
having setup hooks that run as the user outside of a sandbox would be spooky, that isn't what you meant, right?
<catern>
and if Nixpkgs could somehow just configure that y default
<catern>
gchristensen: no no, definitely I mean inside the sandbox as part of the build
<catern>
(when I say badness of nix-env I'm thinking of things like "nix-env -i")
pushqrdx has joined #nixos
<catern>
hm, I really can't believe that info is the only thing that would benefit from a postBuild step after all the installed packages are symlinked into place...
<catern>
mandb would also benefit I suppose, from the same category
<pie_>
do you _know_ its being evaluated? half the time it seems like things arent being evaluated, the problem is that they arent being evaluated
ddellacosta has joined #nixos
<pie_>
dupon1: what is lib.imports?
<dupon1>
ah, hum… I wanted to import the nginx file but the plain imports was failing
<catern>
there sure are a lot of pull request messages in this channel these days
<catern>
should that bot be turned off?
Guest46971 has quit []
r0bby has joined #nixos
<colemickens>
I seem to have lost the ability to eval drvs for other systems recently. Or something else changed and is misleading me?
ddellacosta has quit [Ping timeout: 252 seconds]
<{^_^}>
[nixpkgs] @jtojnar pushed to gnome-40 « gnome-latex: fix build with tepl 6 »: https://git.io/JO5oH
<DigitalKiwi>
19:18 simpson: I didn't know that there was such a thing as "every other package", TBH. I think that whenever there's a boundary between languages,
<DigitalKiwi>
i have multiple electron apps that are packaged differently lol
<pie_>
infinisil: https://bpa.st/DVVA the config = {...}: ... is supposed to override the attrs you can see there , but it doesn't actually work. I tried a variant of that overrideSubmod that you can see there but that didnt work either, how can I do this?
<pie_>
im assuming part of the problem is that the config = isnt an attrsof or anytihng, so im not sure how that can be made to wokr
<infinisil>
pie_: I'm kind of too tired right now. But just in general I think you need to provide more context and a complete picture when you ask for help. Currently it's impossible to follow what you're trying to do
<pie_>
sure.
<pie_>
guess i need to debug some more to ask more clearly
<infinisil>
I feel like you're skipping ahead many steps in your head without mentioning them, and we only get a sample of your thoughts every minute
<pie_>
infinisil: but frm what you say this seems like it should work
<infinisil>
Yeah I think so, but then again, I don't know what "bad" config you're speaking of, what extra-container is, what this has to do with the system path, what the original unrefactored source is
<infinisil>
All things you mentioned without explaining them!