<samueldr>
>> If this option is set, ‘device’ is interpreted as the path of a swapfile that will be created automatically with the indicated size (in megabytes).
jackdk has joined #nixos
<{^_^}>
[nixpkgs] @mnacamura opened pull request #48026 → nixos/fish: use 'escapeShellArg' for shell aliases → https://git.io/fxspX
georges-duperon has quit [Quit: Leaving]
<samueldr>
sir_guy_carleton: ^
<sir_guy_carleton>
okay, thanks; will nixos-generate-config recogize it if i manual create it, like swap parition?
<samueldr>
hmm
<samueldr>
I don't know
<jackdk>
I just upgraded to 18.09 and my nm-applet now shows "no entry" sorta-signs instead of its icons. Is there a missing icon package I need to add to configuration.nix or something?
<{^_^}>
[nixpkgs] @peterhoeg pushed to master « xdiff: 4.0.1.2017062 -> 5.0b1 - version bump only »: https://git.io/fxGe5
<Shados>
I should refactor it at some point... wasn't obvious to me initially how to group certain bits of data, but taking a look with fresh eyes it is. Right now it's got some wonky flows of data >.>.
<worldofpeace>
ahh, sometimes it's make it work now or nothing I guess :P
<Shados>
It's more that it was one of three things I was working on over a weekend, and by the time I had something working it was 2am Monday... didn't even get around to committing the changes for a day or two :p. And then the next weekend I was distracted by something new and shiny, thus beginning the cycle anew.
slack1256 has quit [Remote host closed the connection]
silver has quit [Read error: Connection reset by peer]
Taneb has quit [Quit: I seem to have stopped.]
<worldofpeace>
hah, totally can relate there. Next week you it can be like 'what was I even doing anyway?' :D
<samueldr>
rule of thumb: busybox is always never the package you want
<samueldr>
jackdk: ,locate bin searches only for tools `$out/bin`, and I'm not 100% certain, but I believe it anchors start and end
<jackdk>
good to know
<samueldr>
yes, especially in a case like this one :D
<samueldr>
,locate 9
<{^_^}>
Found in packages: shogun, povray, eccodes, inferno, ncurses6, singular, grib-api, pltScheme, plan9port, factor-lang, rocksndiamonds, javaPackages.junit_4_12, javaPackages.mavenHello_1_1
<samueldr>
,locate bin 9
<{^_^}>
Found in packages: plan9port
* samueldr
is surprised at the lack of `9`
<worldofpeace>
How are large prs usually reviewed in nixpkgs?
<samueldr>
there is more than one definition to large
<samueldr>
a one line change can be a large change semantically
<samueldr>
while a thousand line change can be minimal!
<samueldr>
and AFAICT, each "large" PR is handled differently
<worldofpeace>
I guess somewhere in between then
<worldofpeace>
explicit definition would be an addition of a 'large' "package set"
<samueldr>
I guess we'll know when you open the PR :)
<worldofpeace>
trying to coy here :)
<worldofpeace>
* be
sir_guy_carleton has quit [Quit: WeeChat 2.0]
<samueldr>
please barge head-on
<worldofpeace>
I'm basically done with elementary and I'm going to pr on their release date. Basically i'm trying to make reviewers happy? (other than jtojnar he's done enough :P )
<samueldr>
:D
<samueldr>
I didn't want to pull it out from you, but I had gut feeling it was elementary related
<samueldr>
you've had a couple PRs reviewed AFAIK
<samueldr>
so it'll probably be like that, but more nits and picks :)
<worldofpeace>
That's my focus until its merged :P
<samueldr>
(meanwhile I'm trying back windowmaker)
rprije has joined #nixos
<rprije>
Hi. I have a #!/usr/bin/env nix-shell #! nix-shell -i runghc -p "haskellPackages.ghcWithPackages (pkgs: [pkgs.turtle])" shebang. Whenever garbage is collected, turtle goes with it and gets reinstalled all over again upon next invocation of my script. How can I ensure runghc script runtime dependencies like this aren't garbage collected?
<worldofpeace>
samueldr: I just hope I haven't skewed my reputation to a one sided interest (telling from your assumption) :D
<samueldr>
nah, I just remember a bunch of stuff said on IRC
<samueldr>
and I was waiting patiently for an eventual elementary PR from you since you showed interest ages ago :)
<worldofpeace>
plus you do host the logs for the irc
<samueldr>
I could host them and never read IRC :)
<worldofpeace>
the packaging was a lot more complex than I thought it would be
<worldofpeace>
though I only used nix for like 4 months prior so that might be why
pointfourone has quit [Remote host closed the connection]
pointfourone has joined #nixos
<{^_^}>
[nixpkgs] @pvgoran opened pull request #48031 → openssh: fix tunnel forwarding broken in 7.7p1 → https://git.io/fxGJN
<{^_^}>
[nixpkgs] @peterhoeg opened pull request #48032 → gcalcli: use python3 i/o python2 so we can drop our overrides → https://git.io/fxGJh
<Shados>
rprije: You'll need to add a garbage collector root containing the things you're using. Check the nix-store man page listings for options --add-root and --indirect, IIRC they're also usable with nix-shell. I'm not sure what a good way of managing the produced gc roots would be for nix-shell shebang scripts, I pretty much only use it for persisting nix-shell environments.
mayhewluke has quit [Ping timeout: 252 seconds]
mayhewluke has joined #nixos
<switchy>
I've built nix with a custom prefix since I don't have root access to write /nix. this seemed to be working alright (didn't really do much) until I upgraded nix -- nix-env -iA nixpkgs.nix, now it has forgotten my prefix. did I mess up? I guess I can roll back by setting the NIX_*_DIR env vars
[Leary] has quit [Remote host closed the connection]
Rusty1 has quit [Quit: Konversation terminated!]
astronavt has joined #nixos
b has quit [Quit: Lost terminal]
<{^_^}>
[nixpkgs] @colemickens opened pull request #48033 → WIP: konqueror: init at 18.08 → https://git.io/fxGUK
revtintin has joined #nixos
jtojnar has quit [Ping timeout: 252 seconds]
vandenoever has quit [Ping timeout: 246 seconds]
rprije has quit [Ping timeout: 244 seconds]
rsa has joined #nixos
<Myrl-saki>
What's the proper way to override a Nix output with a directory?
<Myrl-saki>
`overridePackages = _: { bar = /nix/store/...; }` should work, but might break some packages which expected a set.
<Myrl-saki>
`overridePackages = _: { bar.out = /nix/store/...; }` should also work, but I'm guessing it's not going to play nicely with successive overrides.
<{^_^}>
[nixpkgs] @xeji pushed commit from @bgamari to release-18.09 « qpdf: Drop CVE-2018-9918.patch (#47935) »: https://git.io/fxGIK
<sphalerit>
Myrl-saki: I don't see how that would help avoiding rebuilds..?
Lears has joined #nixos
<sphalerit>
Myrl-saki: if you mean rebuilds of the derivation itself, you could just make a trivial derivation for it like runCommandNoCC "name" {} "ln -s ${./yourdir} $out"
<sphalerit>
colemickens: that gets you the nixos set, if you want the toplevel system DRV, get the "system" attr from it
siers has joined #nixos
orivej has quit [Ping timeout: 252 seconds]
Ariakenom has quit [Quit: Leaving]
Lears has quit [Remote host closed the connection]
goibhniu has joined #nixos
hyper_ch has quit [Remote host closed the connection]
Itkovian has joined #nixos
hyper_ch has joined #nixos
<colemickens>
I got something similar working
<colemickens>
I have multiple let statements that refer to the system configs.
<colemickens>
I'm embarrassingly now just having a hard time getting it to build all of them. What do I put in the output? If I make another "let result = {}" object, it still doesn't lazy evaluate.
<Myrl-saki>
sphalerit: It's kinda like enforced derivation locking.
<Myrl-saki>
Wait, it *is*.
<sphalerite>
colemickens: just make the top-level expression a set { system1 = (import <nixpkgs/nixos> {configuration = …;}).system; system2 = (import <nixpkgs/nixos> {configuration = …};}).system; }
<Myrl-saki>
sphalerit: Also, that doesn't exactly work except for very trivial cases, because you'd lose /nix/store dependencies.
<Myrl-saki>
(the runCommandNoCC)
<sphalerite>
Myrl-saki: the same would apply if you overrode the outPath
<Myrl-saki>
sphalerite: Kinda.
<Myrl-saki>
sphalerite: I was thinking of overriding the outPath with a /nix/store/... directory, so it would just refuse to build if it doesn't exist.
<sphalerite>
if you want to pin a package to a specific version, why not just use normal nixpkgs pinning for it?
<Myrl-saki>
sphalerite: Because dependencies.
<Myrl-saki>
Oh wait.
<Myrl-saki>
Pinning nixpkgs.
<Myrl-saki>
Yeah, that should also work.
<sphalerite>
that's the usual approach :)
<Myrl-saki>
sphalerite: Another use case for this though is distribution of proprietory software built on Nix.
astronavt_ has joined #nixos
<sphalerite>
eww :p
nD5Xjz has joined #nixos
<Myrl-saki>
sphalerite: I know, but still. :P
astronavt has quit [Disconnected by services]
astronavt_ is now known as astronavt
Itkovian has quit [Read error: Connection reset by peer]
Taneb has joined #nixos
Itkovian has joined #nixos
Ariakenom has joined #nixos
Lears has quit [Remote host closed the connection]
<colemickens>
okay, and hopefully the last question for a while...
<colemickens>
I want to parameterize the systemconfig so that I can invoke it and specify a different patch
<colemickens>
I know to do ``imports = [ ./file.nix { patch = patches.foo } ];`` but I can't figure out how to specify patch as an arg/option in file.nix
<Myrl-saki>
colemickens: `{ patch }:`
Itkovian has quit [Read error: Connection reset by peer]
<colemickens>
so like { config, lib, pkgs, trackpadPatch ? null, ... }: at the top?
<Myrl-saki>
colemickens: Oh, no.
<Myrl-saki>
colemickens: That's technically correct, but the defacto standard in Nixpkgs's module system is to pass it through `config.foo.bar = ...;`
Lears has joined #nixos
<colemickens>
Myrl-saki: even if this is just part of my own personal nixos configuration.nix ?
<colemickens>
I do use mkOption etc in the modules I'm working on
<sphalerite>
I was too lazy to fully specify the types for my custom module so I just did options.mine = lib.mkOption { type = lib.types.attrs; };
<sphalerite>
:p
<adamt>
Hiya. Any particular reason the gdm module sets services.xserver.displayManager.lightdm.enable = false in 18.09?!?!?
<Myrl-saki>
sphalerite: No comment. :C
<sphalerite>
adamt: because lightdm is the default display manager and if someone wants to use gdm they probably don't want to use the default DM
<sphalerite>
adamt: this wasn't the case in 18.03 because the default was slim there (so gdm disabled slim instead)
<colemickens>
Myrl-saki: does that make it usable in the `imports = [ ./file.nix { option = val; } ];` way? or is that wrong to do as well in this case?
alex`` has quit [Ping timeout: 264 seconds]
<sphalerite>
Myrl-saki: that makes it possible to do imports = [./file.nix]; foo.bar = baz;
Tucky has joined #nixos
<sphalerite>
err colemickens ^
<adamt>
sphalerite: So because lightdm is default, the gdm module disables lightdm? That makes no sense.
<sphalerite>
adamt: why not?
ThatDocsLady has joined #nixos
<adamt>
sphalerite: I didn't enable GDM. Why does it mess with lightdm? And if lightdm is default, why doesn't the module enable lightdm instead of disable it?
<adamt>
No matter what I would call it a pretty broken upgrade experience that my config is broken because a piece of software I enabled in 17.09/18.03 is now enabled by default :p
<adamt>
To clarify, the error I get is: error: The option `services.xserver.displayManager.lightdm.enable' has conflicting definitions, in `/etc/nixos/nixpkgs/nixos/modules/services/x11/display-managers/gdm.nix' and `/etc/nixos/configuration.nix'.
<Myrl-saki>
I'm not the only one who uses a local nixpkgs checkout huh? :D
<adamt>
Myrl-saki: That's the only way to go :p
Itkovian_ has joined #nixos
<sphalerite>
adamt: it should be conditional on gdm being enabled.
<sphalerite>
adamt: enabling gnome enables gdm by default, are you using gnome?
<sphalerite>
adamt: you could try using nixos-option services.xserver.displayManager.gdm.enable to see why it's enabled
alex`` has joined #nixos
jasongrossman has joined #nixos
mayhewluke has quit [Ping timeout: 252 seconds]
kyren has joined #nixos
mayhewluke has joined #nixos
obadz has joined #nixos
<adamt>
sphalerite: Yes, I've enabled gnome3, but don't use it as a desktop. So maybe enabling gnome shouldn't enable gdm.
<sphalerite>
adamt: it enables it by default. You can always put services.xserver.displayManager.gdm.enable = false;
<adamt>
At least I think it's kinda unfortunate that it works as it does now.
<srhb>
I think the behaviour is right and proper, but it should have had a release note.
<adamt>
srhb: Yes, it should have. :-)
<srhb>
More than "The default display manager is now LightDM. To use SLiM set services.xserver.displayManager.slim.enable to true.
<srhb>
at least.
johanot has joined #nixos
brejoc has joined #nixos
<srhb>
However, I certainly go into the upgrade process expecting to have to make changes to my config according to the errors served to me by nixos-rebuild. I think that's a feature that allows us to make relatively large-scale changes safely.
<adamt>
I honestly think it's one of these cases where the module system is used in a way that's a bit too magical, and one might honestly ask why we both have desktopManager-options and displayManager-options, when they now interfere in that way.
<srhb>
adamt: Do you think that of all modules that enable/disable other modules?
<srhb>
While the error messages could be clearer, I think that it's a great use of the module system, that gives you an error up-front that causes you to ensure you have consistent settings before even continuing.
<adamt>
srhb: No, but why do we even have desktopManager-settings -- what's the difference from just using a gnome3 pkg?
<srhb>
adamt: For instance, it enables gdm and disables lightdm ;)
<adamt>
srhb: Yeah, really clever. :P
<srhb>
adamt: I mean, the whole point is to do things that installing a package cannot do easily.
<srhb>
I guess the question is why you have it enabled if you're not using it.
<adamt>
srhb: I use lots of gnome tools, but currently trying to figure out what exactly the module is installing.
<adamt>
Basically looking for a gnome3 meta package that just gives me tools like nautilus, the pdf viewer, etc.
<sphalerite>
I personally would expect the gnome module to just enable the gnome session and put any pieces strictly necessary for gnome to work in place
<sphalerite>
but I don't think gdm ist strictly necessary for gnome to work
<srhb>
adamt: OK. In that case, yeah, you probably do NOT want the module, most it does is enable a ton of gnome meta services and dependents.
<srhb>
sphalerite: No, it isn't, and it's also only mkDefault'ed tru
<srhb>
true*
<adamt>
sphalerite: Thank you for being better at articulating my point.
<srhb>
I can totally see that POV, but it isn't what the gnome3 DM module is.
<adamt>
is *now*.
<srhb>
Right.
<srhb>
Also before, though.
<srhb>
It was just not visible because the settings it sets weren't conflicting with yours.
<adamt>
No. Not before.
<adamt>
Right. Good point.
<srhb>
For instance, if you'd had services.accounts-daemon.enable = false; before, you'd have the same error.
<jasongrossman>
That's interesting. I should probably also be using gnome3.corePackages.
<srhb>
Ah, so I see.
<adamt>
But I don't want to use a package that looks like end users shouldn't depend on
<kyren>
I have kind of a vague beginner question, I was going to split my configuration.nix into modules and I'm wondering exactly how configuration in each of the modules is merged, I can't find where the documentation talks about how this merging works
<srhb>
adamt: Why not? If it goes away, you'll get an error. :P
<jasongrossman>
I suspect adamt's problem is fairly widespread.
<jasongrossman>
So the undiscoverability of gnome3.corePackages might be a problem.
<srhb>
kyren: It's explained fairly well in the NixOS manual, though not extensively.
<kyren>
it appears attribute sets are recursively merged, but what about things like allowedTCPPorts
<srhb>
kyren: Basically each option type has its own merging rules.
<sphalerite>
kyren: it depends on the option types
<kyren>
oh okay I must just have missed it, I'll check again
<jasongrossman>
I find I can't add gnome3.corePackages to environment.SystemPackages.
<kyren>
yeah, it's definitely in the manual and I just hadn't read the right parts yet
<srhb>
jasongrossman: It's a list.
<srhb>
(I think)
<srhb>
kyren: Getting the exact merge rules for each type probably is easiest from the source though, once you have the overall concept down :)
<kyren>
but just to make sure I understand, conflicting options in different modules is supposed to be an error right?
<srhb>
kyren: (That is, lib/types.nix)
<jasongrossman>
Yeah, it's a very nice list, and I use it already. There's some problem with gnome3.corePackages specifically. Like maybe it doesn't exist? It's not something I need fixed for my own use, but I think adamt has a good point about this being a problem.
<srhb>
kyren: Depends on the type whether it's a conflict, but yes.
<srhb>
kyren: For instance, types.bool
<srhb>
jasongrossman: pkgs.gnome3.corePackages ?
<srhb>
jasongrossman: It certainly exists, but it would be easier to figure out what the problem is if you relay the error message. :)
<kyren>
srhb: types.bool is an example of one that is not merged and will conflict, right?
<srhb>
kyren: Not quite. its merge rule is mergeEqualOption, meaning that it'll happilly merge values of true or false, but if there are both true and false, it'll conflict.
<kyren>
ohhhhh okay yeah that makes complete sense
<kyren>
okay, this is vastly vastly less brittle than I was worrying it was
<hyper_ch2>
hmmm, in the PR site on github there's a second line for every PR like #48035 opened 2 hours ago by sjau 1 of 9 --> what does that 1 of 9 mean?
<jasongrossman>
srhb: I don't HAVE a problem, except trying to work out what the best answer to adamt's problem is.
<srhb>
kyren: It's very powerful :)
<kyren>
thanks very much, sorry for not finding that before
<adamt>
jasongrossman: I just tested installing it with nix-env, which seemed to work, so it should work in the systemPackages list as well.
<srhb>
jasongrossman: Okay, maybe I misunderstood, I thought you were saying you couldn't add it to systemPackages and I was trying to diagnose that, whether for you or adamt.
<jasongrossman>
srhb: You were absolutely right. My fault for not explaining. But if adamt's happy then I'm happy.
<adamt>
I just feel dirty installing a package that isn't user visible.
<jasongrossman>
^
<srhb>
adamt: I wouldn't feel very dirty about that.
<adamt>
I'm not really happy, I think either solutions is pretty hacky, but I suppose it is what it is.
<srhb>
I also wouldn't install such a huge metapackage, but opinions, man... :P
<adamt>
srhb: No, but you're also keeping better track of what happens in master/unstable compared to normal end users. :P
<srhb>
Probably yes.
<jasongrossman>
Well let's see whether we hear other complaints about display managers, because that was the cause of adamt's problem, I think?
<{^_^}>
[nixpkgs] @peterhoeg opened pull request #48036 → nixos darkhttpd: module to enable darkhttpd → https://git.io/fxGs6
<adamt>
srhb: Compared to the storage wasted in my /nix/store for building hosts, gnome isn't really huge. :P
<jasongrossman>
(Personally I was using GDM anyway.)
<srhb>
adamt: I believe you :-P
<srhb>
But I think my main point was that it's perceived "user-non-visibility" is really a limitation of the package list generator.
<srhb>
It's just a list of "packages" -- that doesn't scare me.
<srhb>
At least, insofar as none of the individual packages scare me :-P
<{^_^}>
[nixpkgs] @7c6f434c pushed to master « boehmgc: reinstate 7.6.6, use for asymptote »: https://git.io/fxGsS
<srhb>
jasongrossman: fwiw I'm all for bettering the UX here. But I think that using services.gnome3.enable as a metapackage for "gimme all the gnome3 packages, but not gnome3" is a mistake. We might want to advertise that better, if it's common. :)
<srhb>
That said I do not use gnome3, so I might be completely underestimating how common that perception is.
<adamt>
srhb: So what happens if a user wants to enable both gnome and kde and swap between them? I take it they both wants to enable their specific display manager
<srhb>
adamt: I'm actually not sure! They might conflict. :)
<adamt>
If that's the case it's broken :P
<adamt>
regarding broken, i can't add 'gnome3.corePackages' to systemPackages. It gives me this error: 'error: cannot coerce a list to a string, at /etc/nixos/nixpkgs/lib/strings.nix:504:15'.
<srhb>
adamt: It's a list, as said earlier.
<srhb>
adamt: ++ gnome3.corePackages;
<Arahael>
Why wouldn't gnome3 include gnome3?
<adamt>
srhb: So nix-env is magical and just installs a list?
<srhb>
adamt: Yes. It also traverses attrsets.
<srhb>
plasma5 and gnome3 do conflict, indeed.
<jasongrossman>
srhb: "I think that
<jasongrossman>
using services.gnome3.enable as a metapackage for "gimme all the gnome3
<jasongrossman>
better, if it's common. :)" - right.
<jasongrossman>
packages, but not gnome3" is a mistake. We might want to advertise that
<adamt>
I don't like it. Anyways, ++ gnome3.corePackages work. *finger's crossed*
<adamt>
jasongrossman: careful with pasting, you might get klined, just ask srhb :p
<srhb>
:(
<kyren>
okay, I have one more vague question, but this time it's more asking for advice, suppose I had a small number of physical machines and I wanted to manage their configuration together with version control, and possibly have the option of doing nixos-rebuild on the vastly more powerful of the three, is this setup something that I should be considering e.g. nixops for or is that too heavyweight and is there an easier way?
<srhb>
And I will agree that it's a less than ideal situation (re. plasma5 and gnome3) but calling it "broken" is just a bit harsh. Clearly it's not a super common use case, and the time investment versus functionality is up for debate.
lingeeal has joined #nixos
<adamt>
Anyways, if enabling plasma5 and gnome3 also conflicts, I personally think that's a good reason for the desktopManager settings not to mess with the displayManager ones.
<srhb>
Arguably, yes.
<lingeeal>
hi when doing 'nix-shell --pure ....' I cannot do 'cabal repl' later in that shell.
<srhb>
kyren: You can use NixOps for that, a lot of people do that, but you don't technically need it. We already have the ability to build arbitrary machines without it.
<kyren>
I'm aware of nixos-rebuild with remote targets, I'm more looking for like.. what you would do in that situation
<jasongrossman>
Just for information: gnome3 and plasma5 don't conflict - they can both be enabled - as long as at most one of them is set as default.
<srhb>
kyren: Opinions differ.. I mostly use NixOps when I need its provisioning magics (create all these resources in AWS, for instance) and pure nix/nixos when I do not.
<kyren>
one repo for all three machines and symlink /etc/nixos/configuration.nix? do I put hardware-configuration.nix into version control? that kind of thing
<kyren>
srhb yeah that's kind of the impression I got, there's no provisioning so it seemed overkill
<ldlework>
nixops for 3 machines sounds ideal
<ldlework>
it is actually very simple for that number of machines
<ldlework>
doing it in nixops lets you reconstitute whatever these three machines are in the case of failure or any other case
<srhb>
jasongrossman: Ah, thanks.
<kyren>
there's also the question of auto-updating, if I ever make large configuration changes and do remote deploys, I would be worried about turning on auto update and having it revert something, I guess the two are just not compatible
<srhb>
kyren: Yeah, I'd not auto-update.
<srhb>
kyren: I know of people who use NixOps to provision their local machine even.
<kyren>
huh, interesting
<kyren>
I might just try it to see
<srhb>
Definitely advisable. Try both. :)
<jasongrossman>
srhb: That's interesting. Am I missing some interesting reason for using NixOps locally?
<adamt>
srhb: Other distributions I've used stick to the default DM until somebody explicitly changes it, so that installing gnome+kde at the same time doesn't become a problem. Yes, calling the design in nixos broken might be harsh, but it's unexpected at least. I'll leave it as this so I can try rebooting into 18.09 :p
<adamt>
And the package browser thingy not picking it up gnome3.corePackages is also annoying. :P
<kyren>
okay, related question and this is the last one, if you manage a remote machine and always do remote nixos-rebuild, is it allowed / advisable to like.. remove /etc/nixos entirely so that you don't have a phantom bad / old configuration on that machine
<srhb>
adamt: Right, I totally get your point and I agree that we could/should improve this. I'm just a little leery about calling something that clearly works for many people outright broken, also because it's a bit of a demotivating exclamation, when it could be put better and more accurately. :-P That said, sorry you had upgrade woes. I'll consider making a PR to at least adjust the release notes, if that's even
<srhb>
possible at this point.
patrl has joined #nixos
<srhb>
kyren: NixOps does exactly this to prevent "accidents"
<jasongrossman>
kyren: That's a great question because it lets us boast about the most fantastic thing about NixOS, which is that its deployments are always reproducible, so having cruft lying around can never be a problem. (Unless something's broken, admittedly.)
<srhb>
kyren: Because accidents like that often mean "oops, no connectivity, gotta get the car..."
<kyren>
jasongrossman: yeah sure, but what srhb said, I wouldn't want to be in the wrong machine and accidentally do a local nixos-rebuild and break networking completely
<srhb>
I personally use something similar to Bas Van Dijks/Lumiguide's automatic rollback service
<jasongrossman>
kyren: Absolutely. No problem if you want to delete stuff as a matter of belt and braces.
<kyren>
so okay if a machine becomes managed by NixOps it will purposefully remove /etc/nixos, that seems wise
<srhb>
After a rebuild of a remote system, I must access it within an hour and touch a certain file, or it will roll back automatically to the last generation.
<jasongrossman>
srhb: That is nice.
<{^_^}>
[nixpkgs] @peterhoeg opened pull request #48037 → fbv: init at 1.0b → https://git.io/fxGZk
<srhb>
jasongrossman: I wish I could say this was a pre-emptive thing, but... Been there, done that. :-P
<jasongrossman>
Oh dear!
<srhb>
Yeah, nothing more terrifying than losing ssh...
lingeeal has quit [Remote host closed the connection]
<Myrl-saki>
srhb: Had to do something like that, but the file must be touched in order to not shut down the system. The file is also part of nixops keys, so it's effectively a shutdown countdown. :)
<srhb>
Myrl-saki: Ah :)
<Myrl-saki>
Gets reset every deploy.
<srhb>
Someone really ought to package this up as a module.
<srhb>
Seems like a common thing.
<Myrl-saki>
srhb: Seems to only make sense in the context of nixops though.
<Myrl-saki>
Is there modules in nixpkgs that is nixops only?
<adamt>
Myrl-saki: Nah, it makes sense for all systems just like nixops
<kyren>
so I'm repeating myself but just to make sure I understand because I can't find this in the docs online, NixOps DOES remove local configuration when deploying to a native nixos machine, correct? Also, it does NOT do any sanity checking like making sure that the machine is reachable and doing a rollback if it is not contacted, but there are other packages that can fill in that part?
<Taneb>
kyren: on the remote machine there is no copy of the configuration
<kyren>
and if there was one it's removed to avoid confusion right
<adamt>
Why would it remove a file that probably doesn't exist in the first place?
<Taneb>
Actually, I have no idea about nixos native, but I imagine that that's the case
<kyren>
well, I mean nixos had to get there to begin with
<adamt>
i don't think nixops would remove the file, but that's just a guess.
<adamt>
kyren: Yes, and you can install nixos without /etc/nixos/configuration.nix
<ikwildrpepper>
nixops doesn't remove files, unless it is part of the system configuration that you want deployed
<ikwildrpepper>
so basically anything in /etc/nixos is not used and thus ignored
<kyren>
it's not a big deal I can just remove it myself, I'm not asking to like narrow down the precise exact behavior of nixops as much as I am to get a sense of what is best practice and what is and isn't necessary, like if removing /etc/nixos/configuration.nix causes something to fail if it's missing, but yeah I understand now that it doesn't and it's just really the "default" system configuration location
<adamt>
kyren: Installing nixos is basically copying files to /nix/store and activating a configuration. /etc/nixos/configuration.nix + nixos-rebuild is just one way of doing that.
<kyren>
right that makes sense, so install nixos on remote machine, use nixops to deploy to it, log in and remove /etc/nixos because it's no longer the single source of truth (if you're paranoid), also if I wasn't using nixops and just did remote deploys only that may also be a wise idea
<adamt>
kyren: It's not really a default system configuration file, more like an input to nixos-rebuild, which incidentally is a very common tool for managing the machine. :-)
<kyren>
is it correct to say it's the default location for the system configuration? you can use other files with nixos-rebuild right?
<kyren>
oh maybe you can't and I misunderstood something
betaboon has joined #nixos
<srhb>
kyren: echo $NIX_PATH
<srhb>
kyren: You'll probably see nixos-config=/etc/nixos/configuration.nix
<ikwildrpepper>
kyren: you actually can using NIXOS_CONFIG env. var or via nix path
<ikwildrpepper>
as srhb mentions
<{^_^}>
[nixpkgs] @peti pushed 2 commits to haskell-updates: https://git.io/fxGZh
<kyren>
ohhhhhhhh okay
<adamt>
But looking at man nixos-rebuild, it doesn't actually mention using another file than /etc/nixos/configuration.nix
<adamt>
Oh. Nmv.
<adamt>
I was looking for a flag like -f, didn't see the ENV vars section.
<srhb>
fwiw that manual page isn't quite complete..
<kyren>
is that the "right" way to build a configuration and deploy it to a remote machine, NIXOS_CONFIG=some/path/configuration.nix nixos-rebuild --target-host mycoolmachine?
<kyren>
I mean other than like letting nixops do it
<srhb>
kyren: It's one way. I tend to do it a bit more manually, building the closure locally and copying it over.
<kyren>
sorry, I said that was my last question and it was all lies
<srhb>
kyren: (Which is essentially what --target-host does)
<adamt>
kyren: I don't think there's a limit to how many questions you're allowed to ask here. :P
<srhb>
Indeed ;-)
<kyren>
that's great to hear :D
<srhb>
We even allow people to not know the number of questions in advance! It's like anarchy!
<{^_^}>
[nixpkgs] @peti pushed 2 commits to haskell-updates: https://git.io/fxGnL
adamt has quit [Quit: WeeChat 2.0]
lassulus has quit [Remote host closed the connection]
<kyren>
so I could write a script that looks in a git project and uses nixos-rebuild to deploy to several remote machines, I could do the same thing more manually by building closures and copying them over and then activating them, or I could just use nixops and it would just do that for me, and also /etc/nixos is effectively "my directory to do whatever I want with" and the reason /etc/nixos/configuration.nix is important is simply because there's an environment
<kyren>
variable that tells nixos-rebuild to look there and not something more magical
<srhb>
kyren: There also exists a ton of "like-NixOps"-tools out there. The system is extremely flexible, as you might expect when you're suddenly able to have a primitive that is just "build this OTHER system locally, and copy it to foo"
<kyren>
is it common to have some kind of automatic security update solution with remote deploys like nixops? do people auto remote-deploy security updates?
<srhb>
kyren: I don't think NixOps is usually paired with any kind of automatic updates.
<kyren>
yeah I saw some, like krops and nix-deploy, but I didn't fully understand the differences at the time I think and I was still a bit confused
<srhb>
Normally in NixOps setupts, the remote machine doesn't even know its own source configuration, so doing anything automatically is a bit hard.
<srhb>
kyren: As opposed to eg. krops which iirc (I only looked at it briefly) copies the actual configuration over.
<kyren>
yeah, I think that's actually the crux of what I was having difficulty like.. planning out
<srhb>
imho there's less need for up-front planning when you're just a rebuild away from changing everything. :-)
<kyren>
I mean, this is all small potatoes so it's not like if I don't have automatic security updates I'm gonna get you know immediately destroyed or something, it's just something I've always done
* srhb
nods
<srhb>
And it's certainly desirable
<srhb>
I guess that's one point for krops right there. :)
<srhb>
I also know of at least three non-released, in-house NixOps alternatives. So I think we haven't really landed on the "one solution to rule them all"
<kyren>
I COULD also write a script to copy configuration to /etc/nixos and do remote building, which I guess is what e.g. krops does, I think I understand the situation a lot better now
<kyren>
yeah it seems like MVP nixos remote deploys is like... not a hugely complicated thing
<srhb>
Indeed.
<kyren>
I mean it's built into nixos-rebuild already
<srhb>
Literally copying a system closure and running activate on it :P
<kyren>
gotcha, this has all been extremely incredibly helpful, thank you all so much
<srhb>
kyren: You're welcome. Hope you have fun with it. :)
<kyren>
I've spent the last two weeks falling in love with nixos :D
<{^_^}>
[nixpkgs] @Vskilet closed pull request #47868 → nixos/nextcloud : added options to customize the listening address/port → https://git.io/fxmnK
adamt has joined #nixos
<{^_^}>
[nixpkgs] @ttuegel opened pull request #48042 → Fix local path to release notes in error message → https://git.io/fxG4S
kiloreux has quit [Ping timeout: 260 seconds]
<{^_^}>
[nixpkgs] @rbvermaa pushed to release-18.09 « Fix build for rPackages.units »: https://git.io/fxGBC
orivej has joined #nixos
<{^_^}>
[nixpkgs] @rbvermaa pushed to master « Fix build for rPackages.units »: https://git.io/fxGB4
arianvp has quit [Quit: WeeChat 2.2]
talyz has quit [Ping timeout: 245 seconds]
talyz has joined #nixos
<adamt>
Why is it there's no link to the nixos manual on the banner on nixos.org? :P
kiloreux has joined #nixos
<infinisil>
adamt: Yeah lol, I asked about this like a year ago, I guess nobody bothered with it still
<adamt>
infinisil: Yeah, I remember it being asked here before
<adamt>
It infuriates me that it's so hard to find
<adamt>
Oh, meh, the manual only mentions fonts once, so no help there with font issues. :P
iyzsong has joined #nixos
NickHu has joined #nixos
<NickHu>
Hi, I'm trying to fix nixos on a system with a possibly corrupt store
<NickHu>
I'm chrooted in, but when I try to rebuild it gives me errors 'while setting up the build environment: executing '..../bin/bash': Permission denied'
<NickHu>
Running the bash binary in question works fine
<NickHu>
When I chrooted in, I set PATH and NIX_PKGS, maybe I missed a couple environment variables?
<clever>
NickHu: did the disk get mounted with noexec?
adamt has quit [Quit: WeeChat 2.2]
<NickHu>
I bind-mounted it actually
<NickHu>
I have a separate partition for nix store
<NickHu>
I did a nix-store --verify --check-contents --repair and it ran for a while and presumably did something
<NickHu>
strangely running nixos-rebuild with --show-trace seems to do the same thing as without, perhaps because it detects I'm inside a chroot?
<clever>
--show-trace only helps for nix expression level bugs
carlosdagos has quit [Quit: Connection closed for inactivity]
<clever>
try -vvvv
betaboon has quit [Quit: WeeChat 2.0]
<NickHu>
clever: seems to give the same error and no informative information
<layus>
zimbatm, Did you forget a textbox in the food restriction questionnaire. There seems to be no way to enter allergies despite the text.
<layus>
(not that I need it personnaly, but you may want to know it)
<zimbatm>
layus: thanks, fixed!
<layus>
;-)
<d1rewolf>
guys, if I were to switch from nixos to ubuntu or debian, but then use nix as a package manager, what portions of my configs would work?
<gchristensen>
none of the configuration.nix would work
<elvishjerricco>
home-manager *might* work though. I know it can put files in your home directory, but I dunno for sure if it does systemd user services correctly.
<d1rewolf>
ok, so environment.systemPackages won't work either?
<srhb>
d1rewolf: No. Essentially all your get for "environment management" is nix-env (and what can be built with that for your user)
<elvishjerricco>
It'd be sweet for someone to do for systemd linuxes what nix-darwin does for darwin
<d1rewolf>
srhb: ah....I see. ok, so not really declarative any more, just imperative nix-env -i
<srhb>
d1rewolf: Yes. Although as mentioned, home-manager might alleviate some of that.
<d1rewolf>
srhb: yeah, not using that atm
<srhb>
d1rewolf: Everything you've got in /etc/nixos is lost. Everything else, you get to keep.
* d1rewolf
nods
<d1rewolf>
k, thanks
Streetwalrus has joined #nixos
waleee has joined #nixos
<d1rewolf>
so I have a need for chefdk. the version packaged for nixos is old. if i wish to update this, is the appropriate way to fork nixpkgs github, change it in my fork, and do a pull request?
<etu>
d1rewolf: Yeah, sounds about right
<etu>
d1rewolf: I'm using chefdk without realizing that it's old :D
<d1rewolf>
etu: interesting. do you get an error when running chef -v?
waleee has quit [Quit: WeeChat 2.2]
<etu>
d1rewolf: yes I do, some exec thingy. It prints two versions first though: Chef Development Kit Version: 2.4.17 and chef-client version: 13.6.4
<{^_^}>
[nixpkgs] @schneefux opened pull request #48044 → Use fetchFromGitHub instead of fetchurl → https://git.io/fxG6e
<d1rewolf>
etu: I wish everything would compile single binaries like golang. the world would be a better (perhaps more bloated) place :)
ryantrinkle has quit [Ping timeout: 246 seconds]
<avn>
d1rewolf: chefdk is a ruby, so bundix should be able process Bundle.lock and build expression for you.
<etu>
d1rewolf: Can't get more bloated than "compiling and bundle chromium" ;)
<avn>
etu: chromium rebuild is stunning ;) And it depends on everything in system.
<d1rewolf>
avn: hmmm...bundix is new to me. i'll take a look at that. thanks ;)
<manveru>
d1rewolf: also use bundlerApp instead of bundlerEnv for it, since it should only expose executables
waleee has joined #nixos
xenog has joined #nixos
<avn>
d1rewolf: chefdk btw is bundix backed, so should be easy to upgrade
<d1rewolf>
avn: where would I go to learn the appropriate way to do this?
<manveru>
ah, we already have a package :)
<apeyroux>
hello, I can't attach an ip failover (internet) to a nixos-container. I tried it with a bridge but I can't. Is that possible?
<manveru>
d1rewolf: i can maybe do that for you if you don't want to
<manveru>
don't use chef myself, but should only take a few minutes
<d1rewolf>
manveru: that'd be nice....but I'd also like to learn how ;)
<manveru>
well, take a look at the current package, fix the version number, get the Gemfile for that version, run `bundix -l`, and that should do it
<manveru>
the package even has instructions :)
<avn>
manveru: thanks. It bebetter, I know about bundix, but never tried use it myself ;)
pointfourone has left #nixos ["Leaving"]
<manveru>
only thing i wanted to fix is that it's using bundlerApp so it doesn't put all other dependency binaries into $PATH
pointfourone has joined #nixos
pointfourone has left #nixos ["Leaving"]
<d1rewolf>
manveru: hmm....I'll let you do that if you wish ;)
<d1rewolf>
but only if you have time
<avn>
d1rewolf: commonly you need update Gemfile{,.lock} and run bundix for regenerate gemset.nix, then commit everything. But I home manveru explain stuff better ;)
<waleee>
is there anyone else that had fontconfig and "unable to set locale" errors when upgrading to 18.09?
<{^_^}>
[nixpkgs] @thefloweringash opened pull request #48047 → gnome3.mutter: fix crash on startup with nvidia drivers → https://git.io/fxGMQ
<manveru>
i had to fiddle with the Gemfile/Gemfile.lock manually to get it to build, and never used chef, so no clue if it's working... but the help shows up
<kiloreux_>
It gives me an error that it doesn't exist (since I use that dependency inside postFixup step).
<clever>
kiloreux_: can you pastebin the entire nix-build output?
<kiloreux_>
alright, I will trigger rebuild and paste it.
xenog has quit [Quit: Leaving]
waleee has joined #nixos
lorilan has joined #nixos
<{^_^}>
[nixpkgs] @jb55 opened pull request #48048 → rapidcheck: init at git-20180927 → https://git.io/fxG5B
<d1rewolf>
manveru: i will give it a try. thanks!
endformationage has joined #nixos
<lorilan>
Hi I have a question regardings r/w authorization. I use nix to operate a scala/sbt build. Each nix derivation makes an sbt build. sbt does a lot of things on startup and it caches this result. I tried to make a derivation that just create this cache and share it amongst other derivation. However it seems that it requires write access on some of these files. Is there a way to copy the result of a derivation and change the group of the copied file to
<lorilan>
nixbld ?
<manveru>
lorilan: sounds like something an overlay fs could do?
<manveru>
i mean, you can of course copy the result of your cache derivation into your current build and chown/chmod it, that's definitely simpler :)
<lorilan>
@manveru, what is an overlay fs ? the problem with the 'simple' chown/chmod solution is that the previous derivation result is owned by root:root and the user building the current derivation is nixbldX. I don't think that making nixbldXs sudoers is a good idea. So I wondered if there is already a solution for this kind of problem provided by nix
<manveru>
well, you cannot write into the nix store anyway
<manveru>
if you copy something that doesn't belong to you the new user/group will be your own
<manveru>
or if you have a nixpkgs clone already, add it as another remote
<d1rewolf>
manveru: k. thx
<manveru>
should save you some space and downloading time :)
<nyanloutre[m]>
Hello, I would like to add a string to the end of an option already defined elsewhere. If I just set it normally it goes at the top, do you know how to resolve this ?
<nyanloutre[m]>
Is there a way to give more or less priority ?
<lorilan>
manveru, yes now that you've said it, I realize my question is kind of odd. I've added a ls to see the copy and indeed they are created as nixbuildX:nixbld. Afterwards I still have an a permission error, but it originates from the jvm
ryantrinkle has joined #nixos
<manveru>
maybe some of the cache has hardcoded paths
<lorilan>
(this the original error that mislead me to the wrong diagnostic)
<lorilan>
I don't think so, the error is "java.io.FileNotFoundException: /tmp/nix-build-mics-build.drv-4/mics-build/.sbt/boot/sbt.boot.lock (Permission denied)" and the ls performed previously does show me this file
<manveru>
i'd just `chmod 0777 -R /tmp/nix-build-mics*` and see if that works :)
jabranham has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
<gchristensen>
hrm the 18.09 installer seems to start nano in delete-whole-word mode
jabranham has joined #nixos
<hyper_ch2>
weird, I upgraded my homeserver today to latest master and after running nixos-rebuild switch - which passed without issues, I couldn't use zfs commands anymore... zfs list gave weird errors... after reboot, all was fine
hyper_ch2 has quit [Quit: Page closed]
<{^_^}>
[nixpkgs] @Zimmi48 opened pull request #48053 → Remove old OCaml versions. →
<ryantm_>
Is there a way to get the default value of a NixOS module system option?
<gchristensen>
programatically?
<ryantm_>
gchristensen: Yes.
<tilpner>
> nixos.options.environment.etc.default
<{^_^}>
{ }
<ryantm_>
nixos.options.system.stateVersion
<ryantm_>
> nixos.options.system.stateVersion
<{^_^}>
{ _type = "option"; declarations = <CODE>; default = <CODE>; definitions = <CODE>; description = "Every once in a while, a new NixOS release may change\nconfiguration defaults in a way incompatible wi...
<jabranham>
In the nixpkgs manual, it says in the texlive section, "some apps aren't packaged/tested yet (asymptote, biber, etc.);" but biber appears to be packaged
<lingeeal>
it's the only package I need from unstable channel
oida has joined #nixos
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<avn>
jabranham: texlive is generated, big part of it tested because it used by other packages to build docs. But is near to impossible test all texlive.
Itkovian has joined #nixos
<jabranham>
avn: shouldn't the part about "not packaged yet" be removed though?
<elvishjerricco>
lingeeal: Would you rather have another channel for nixos-unstable, or would you rather it just always try the latest one whenever you do nixos-rebuild?
<elvishjerricco>
If you just add it as another channel, you can do `environment.systemPackages = let unstable = import <nixpkgs-unstable> {}; in [unstable.google-chrome];`
<elvishjerricco>
Otherwise you need to replace `<nixpkgs-unstable>` with the suitable expression for fetching the source of the version you want
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<greymalkin>
I'm running into a "No uhc found" while building a derivation on the default haskell packages (with the only change being transformers = transformers_0_5_5_0) am I missing something? 'transformers' doesn't even seem to be included in the derivation.
<greymalkin>
The error appears to be happening trying to build doctest.
<avn>
jabranham: idk. I sometimes found that texlive.combined.schema-full is simpler, than collect more compact setup for my day-by-day latex.
<greymalkin>
(I'm on 18.03, btw)
astronavt has quit [Quit: Leaving]
<elvishjerricco>
greymalkin: "No uhc found" is one of several unimportant messages that Setup.hs spits out. It can be ignored. The issue is something else. Can you pastebin the whole log?
<greymalkin>
Welp, now I have to figure out how to get it to depend only on 0.5.5.0.
<elvishjerricco>
greymalkin: That's unfortunately kinda tough. `transformers` is a core package, so it's shipped with GHC. Any other core package that depends on it (like mtl, in 8.4 or later) will depend on the original core version, not your overridden nix version. It's a frustrating breakage of our nice overriding pattern in nixpkgs
<greymalkin>
elvishjerricco: Yeah, I know. Unfortunately, transformers <= 0.5.5.0 has space leaks -- which I'm pretty sure I'm running into based on https://lpaste.net/4180356222555258880
Itkovian has joined #nixos
<greymalkin>
BUT it's rather hard to tell until I can get an environment with the right stuff in it, and I have so many other dependencies in this project that ghcHEAD just doesn't cut it.
<elvishjerricco>
greymalkin: If it's reasonable, you could try updating to GHC 8.4, which is in 18.03 (or just updating to 18.09 to get the haskell package set that's more curated for 8.4)
<greymalkin>
I tried ghc843 earlier today, ran into problems through SQLite-simple.
<greymalkin>
I'll give 18.09 a try (speaking of which, it might be nice to have the current NixOS/nixpkgs version on their respective homepages)
<{^_^}>
[nixpkgs] @7c6f434c pushed to master « asymptote: apply upstream patch for compatibility with a newer boehmgc »: https://git.io/fxZCu
<elvishjerricco>
greymalkin: Alternatively, you can maybe try to disable that error on the doctest package? It seems incidental to me, not like an actual issue in that case (doctest depending on GHC to run ghci, which depends on the core version of transformers)
<elvishjerricco>
Not sure if there's a flag to disable that error. Wouldn't be too hard to add one to nixpkgs though
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/fxZCD
<exarkun1>
anyone have any idea how to get nginx to successfully verify upstream ssl certificates when running as a proxy? I tried `proxy_ssl_trusted_certificate ${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt;` in the extraConfig but it doesn't appear to make a difference.
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/fxZ4O
<{^_^}>
[nixpkgs] @matthewbauer merged pull request #44511 → soulseekqt : refactoring appimage manipulation to be more generic. → https://git.io/fNXos
<{^_^}>
[nixpkgs] @matthewbauer pushed 2 commits to master: https://git.io/fxZ4G
<Acou_Bass>
not sure
luigy has joined #nixos
<greymalkin>
Yay! 18.09 has transformers-0.5.5.0 ... also, there's still a legacy transformers_0_5_5_0 derivation which conflicts with the default and should probably be removed.
<cransom>
i'm on a nix 2.1.3 machine, running a (it's 2.1.2) nix copy /path --to ssh-ng://othermachine and it's stalling for no reason i can discern. has anyone seen that or have any debugging tips?
<arianvp>
coffee and beer donations always welcome
lord| has quit [Ping timeout: 268 seconds]
dfranke has joined #nixos
<Jarcode>
hey, I maintain a program that has a "--copy-config" parameter to copy & symlink files from /etc/xdg to ~/.config. I noticed the NixOS package for it wraps this parameter in its own script for some reason, citing the 'garbage collector' breaking the symlinks.
trevorriles has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<{^_^}>
[nixpkgs] @WilliButz opened pull request #48075 → codimd: update patch and fix test → https://git.io/fxZaw
lord| has joined #nixos
<jabranham>
If I copy/paste the overlay example from the nixpkgs manual (in "defining overlays") to ~/.config/nixpkgs/overlays.nix any nix-env command results in "error: value is a function while a list was expected, at <long path to nixos/pkgs/top-level/stage.nix>". Am I missing something obvious?
<Jarcode>
not sure why this is needed, or how I could facilitate a cleaner solution for Nix in my package
<arianvp>
jabranham: there's two modus operandi for nixpkgs overlays
<arianvp>
either an overlays.nix which is a list of overlays... i.e. : [ (self: super: ..) (self: super: ...) ] etc
<cransom>
hrm. and my nix copy failure appears to be some io throttling on my host. i could strace the `nix-daemon --serve` process and nearly read the files as they went by. so. someone replaced my disk with pudding. carry on.
<{^_^}>
[nixpkgs] @joncojonathan opened pull request #48076 → CONTRIBUTING.md: add clarification on periods in commit messages → https://git.io/fxZaM
<arianvp>
or a folder named overlays/ with multiple overlay files inside
<arianvp>
overlays/overlay_a.nix with a funciton inside. and overlays/overlay_b.nix with a function inside. etc
trevorriles has joined #nixos
<arianvp>
if you copy the xample to ~/.config/nixpkgs/overlays/my-example.nix it should work
<arianvp>
instead of to overlays.nix
earldouglas has joined #nixos
<jabranham>
arianvp: Yup, that works. Thanks! I see now that this is documented in the previous section. I just read too quickly and missed that part.
<earldouglas>
For the first time, I want to use nix on a multi-user system (yay). How does user2 set up their ~/.nix-profile dir, after nix is installed by user1?
<elvishjerricco>
earldouglas: Well first you'll need to convert your Nix installation to a multi-user install
<elvishjerricco>
Anyone know the fast path to doing that part?
<symphorien>
Jarcode: which package is it ?
<earldouglas>
Got it -- I see the relevant section in the manual.
dfranke has quit [Ping timeout: 245 seconds]
dfranke has joined #nixos
GiGa has quit [Quit: Leaving]
<elvishjerricco>
earldouglas: I'd probably just `nix copy --all --to file://$(pwd)/store-backup`, completely nuke the current install, `sh <(curl https://nixos.org/nix/install) --daemon`, then `nix copy --all --from file://$(pwd)/store-backup`
<elvishjerricco>
But I don't know how you then give other users the right nix profile.
<earldouglas>
Fortunately I'm starting from scratch, so I don't need to back up the current installation.
<elvishjerricco>
earldouglas: Ah, then yea passing `--daemon` to the installer is pretty much it, until you need to use Nix from another user
ogle has joined #nixos
<ogle>
Is there a way to enumerate all of the shared objects on my system similar to `ldconfig -p`?
alex`` has joined #nixos
<ogle>
Currently mesos depends on ldconfig for gpu support, and trying to find an alternative
sir_guy_carleton has quit [Disconnected by services]
nckx has joined #nixos
sir_guy_carleton has joined #nixos
<sir_guy_carleton>
hello; i'm having a bizare problem with jpegs from a external ntfs hard drive
grp has quit [Quit: box shutting down...]
<sir_guy_carleton>
images get corrupted when i use nixos to look at them, with 'unexpected end of data segment errors' and the like, with scrambled images when use feh or gwenview to look at them
<sir_guy_carleton>
yet they are perfectly fine in ubuntu and windows 10
<sir_guy_carleton>
also if transfer them to a usb, some of the same images seem fine as well.
<sir_guy_carleton>
any ideas of what could causing this?
siers has quit [Ping timeout: 245 seconds]
Itkovian has joined #nixos
jasongrossman has joined #nixos
astronavt has joined #nixos
<d1rewolf>
manveru: sorry, ended up having a fire at work. I will try yours as soon as possible. I really appreciate your help
<lassulus>
sir_guy_carleton: are you using ntfs-3g?
astronavt has quit [Max SendQ exceeded]
<sir_guy_carleton>
lassulus: i don't know. just the defaults. how can i tell?
astronavt has joined #nixos
<lassulus>
mount (without arguments) should show it
<lassulus>
but if it's the default I guess not
<lassulus>
do you have some kind of automount?
random_yanek has quit [Ping timeout: 252 seconds]
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
<sir_guy_carleton>
well, i the problem arose copying with dolphin, which i believes auto-mounts
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
__monty__ has quit [Quit: leaving]
<lassulus>
alright, maybe it is enough if you add ntfs3g to environment.systemPackages
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
<lassulus>
and then restart some stuff
<lassulus>
maybe try it first manually, to see if it even fixes the problem
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
<sir_guy_carleton>
maybe, looking at the drive now (mounting with bashmount) it seems fine now, lol
random_yanek has joined #nixos
random_yanek has quit [Max SendQ exceeded]
<erasmas>
I'm getting "path '/nix/store...' is required, but there is no substituter that can build it" when installing packages from one channel but not another. installing both as root
<erasmas>
what kinds of issues would cause that error?
<sir_guy_carleton>
i trying copying to the proper user directory later, see if it works; if not, i'll follow your suggestions, thanks
<ericnoan>
I am looking into getting into Nixos, what would you recommend a newcomer read or learn to get up-to-date on Nixos? I have noticed that the base changes rapidly because there are so many contributors
<Jarcode>
symphorien: oh, I see, the GLava installation path might change between updates, right?
<symphorien>
Yes: /nix/store/some-hash
<Jarcode>
symphorien: and yeah at the moment DESTDIR is respected as an alternative install location, but the binary will still try to read from the paths as if DESTDIR=/
<Jarcode>
which AFAIK is what it's supposed to do
<symphorien>
Also when copying don't copy the mode, the installed files are read only
<sir_guy_carleton>
so why does nix search hid some libraries?
ryantrinkle has quit [Ping timeout: 252 seconds]
Itkovian has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgamari has joined #nixos
Rusty1 has joined #nixos
<jasongrossman>
sir_guy_carleton: Because someone or someones was worried that they'd swamp search results.
<Jarcode>
symphorien: yeah that's mostly covered, I'm just not sure how to facilitate easier building on Nix, DESTDIR is an install/uninstall macro
<jasongrossman>
For example, since there are so many Haskell packages, there might be (at any time) a Haskell package called say firefox-h, and that would appear in the results from nix search firefox.
<symphorien>
Sed the source code ?
<Jarcode>
symphorien: maybe if /etc/xdg/glava was symlinked to /nix/store/some-hash-that-holds-glava-destdir/etc/xdg/glava
<Jarcode>
would that work?
<symphorien>
Well the point of nix is to isolate things by not having global mutable state
* Jarcode
sighs
<symphorien>
I can have two non interfering versions of glava
<symphorien>
If they both want acess to /etc/xdg I can't
<Jarcode>
symphorien: without symlinks I can imagine that kind of practise would be a nightmare
<symphorien>
On a more pragmatic note, it is impossible to do this when using nix not on nixos
<Jarcode>
symphorien: what would be a better approach: providing another macro to build (not just install) from DESTDIR, or using relative paths in the executable (ie. <glava executable>/../../etc/xdg/glava)?
<symphorien>
Jarcode: you can use the C preprocessor to take DESTDIR into account, maybe
<Jarcode>
symphorien: the last option sounds hacky and would have issues with symlinks.
<Jarcode>
oh yeah, I can do that, but that's not what DESTDIR is supposed to be
<Jarcode>
symphorien: normal autohell configuration would have ./configure --prefix, I guess I can add `PREFIX=...`
alex`` has quit [Ping timeout: 244 seconds]
<Ashy>
hmm, how do you use rust on nixos?
bgamari has quit [Remote host closed the connection]
<Ashy>
$ nix-shell -p rustPlatform
<Ashy>
error: cannot coerce a set to a string, at /nix/store/pd7cf8pnslrwjdracbvvvk39k6411a0y-nixos-18.09.783.299814b385d/nixos/pkgs/stdenv/generic/make-derivation.nix:177:11
<symphorien>
Well I leave you to the aesthetic choices, I must go