<vika_nezrimaya>
Its task is to solve precisely the problem of bootstrapping a computing environment from scratch, having only a computer. Ever heard of it?
<bqv>
/nix/store/j8vysakw78bpgngba32hfwwikqda9yx2-bash-4.4-p23/bin/bash: symbol lookup error: /nix/store/c2rlh7xa8fcgg7qz8pl76ipvvb172c6k-glibc-2.30/lib/libpthr...
<vika_nezrimaya>
sounds like someone needs a repairperson to come to their /nix/store
<bqv>
i don't think it's broken
<bqv>
i haven't updated glibc
<bqv>
and everything else works
astylian has quit [Remote host closed the connection]
<vika_nezrimaya>
then how is this possible?
<bqv>
that's why it's a weird bug
LnL has joined #nixos
LnL- has quit [Ping timeout: 240 seconds]
LnL is now known as Guest21243
<bqv>
symbol lookup error: /nix/store/c2rlh7xa8fcgg7qz8pl76ipvvb172c6k-glibc-2.30/lib/libpthread.so.0: undefined symbol: __nanosleep_nocancel, version GLIBC_PRIVATE
<bqv>
full thing
<vika_nezrimaya>
this is not possible
<vika_nezrimaya>
this. is not. possible
<vika_nezrimaya>
try `nix-store --repair`, it might really help you
<vika_nezrimaya>
it helped me when I was encountering weird low-level bugs
<bqv>
someone else had it
<vika_nezrimaya>
this is impossible
<bqv>
did verify path
<bqv>
ti's file
<bqv>
this isn't a broken store path...
<bqv>
and it's quite possible, cause it's happening :p
<vika_nezrimaya>
this kind of stuff should be caught when compiling!!! >.< an undefined symbol? That's just impossible with Nix!
<vika_nezrimaya>
Unless of course there's something fishy going on when actually linking
<vika_nezrimaya>
I don't really fully understand how exactly the linking process works but I think this kind of error should be popping when linking, yet it doesn't
<vika_nezrimaya>
Which is why I thought it's impossible at first
<bqv>
still a bug
<bqv>
if it's caused by something unhandled by nixpkgs, that makes it a bug
<vika_nezrimaya>
because how the heck does it load a different glibc (which is the only way to cause an undefined symbol error) if it isn't even supposed to know about its existence since hashes are supposed to protect from this exact thing?!
<vika_nezrimaya>
that's why I thought it's impossible, it's a bug in the meta-system itself
<vika_nezrimaya>
The whole concept of isolated builds is violated
ambro718 has quit [Ping timeout: 265 seconds]
<vika_nezrimaya>
Sorry my brain's a bit weird right now
<bqv>
yeah, i dunno, theoretical perfection is great and all but if i can't run my containers that's an issue :p
<vika_nezrimaya>
my brain is always weird though
<vika_nezrimaya>
bqv: well, for me this theoretical perfection was always real perfection, and I can't imagine my life without NixOS now
<bqv>
welp, that fixed it
<bqv>
for anyone reading irc logs in the future:
<bqv>
_nanosleep_nocancel -> `doas mv /var/lib/containers/matrix/etc/ld-nix.so.preload /var/lib/containers/matrix/etc/ld-nix.so.preload.off` fixed it for me
<danderson>
What's a good place to keep up with nix news? Blocked on corporate deployment of nixos until nix flakes and fancy new nixops things happen, but never know where to check.
buggymcbugfix has quit [Ping timeout: 244 seconds]
<bqv>
here? :p
<danderson>
well, it feels rude to show up every couple months and go "YO IS EVERYTHING FIXED YET"
<danderson>
so I'm trying to optimize :P
<bqv>
huh, that's been my tactic
<zangi>
Enzime: that's <nixpkgs/nixos>, it is separate from <nixpkgs> which provides packages, <nixpkgs/nixos> is for `/etc/nixos/configuration.nix`
<zangi>
Enzime: probably `cd /nix/var/nix/profiles/per-user/root/channels/nixos/nixos` and then use the release.nix, e.g. `nix-instantiate -E 'with import ./release.nix {}; tests.firefox`
<infinisil>
danderson: Why are you blocked on that?
<infinisil>
Enzime: The test files in nixpkgs/nixos/tests can be run with just `nix-build <the-file>.nix`
<danderson>
infinisil: nixops 2.0: non-error-prone shared state across many users. flakes: removing the risk that someone will push entirely wrong stuff to prod because of local channels being wonky.
<Enzime>
infinisil: oh nice, doesn't work with `nix build` though
<danderson>
I want to replace all our prod machines with nixos, but failure has a high cost. I also don't have infinite tries to introduce nix in the company, so if the initial operator experience sucks, that'll hurt my chances a lot.
<infinisil>
danderson: You can already get evaluation purity with --pure-eval, no need to wait for flakes
<zangi>
Enzime: like infinisil said, you can use nix-build, but you can also use nix-instantiate to produce the .drv and then realise the .drv with `nix-store -r /path/to.drv`
dramforever has joined #nixos
<infinisil>
danderson: Not sure what you mean by the nixops thing though, got a link?
<zangi>
Enzime: for `nix build` you can use `nix build -f release.nix tests.firefox`
Pidgeotto has joined #nixos
Pidgeotto has quit [Excess Flood]
Pidgeotto has joined #nixos
Pidgeotto has quit [Excess Flood]
<danderson>
infinisil: not sure I understand how to use expressions from nixpkgs and NUR using pure eval, but will take a look
<dramforever>
A bit of hardware problem: I have a Dell Inspiron 7590 (not XPS) and the audio doesn't seem to be working well. On kernel 5.4 the speaker is fine but I see no microphone, and on 5.7 I see lots of devices but they don't seem to do anything.
<infinisil>
danderson: Alternatively you could just use something other than nixops
<danderson>
infinisil: I did consider that, yeah. But nixops 2.0 seems to be very close to what I want, so it seems a shame to use morph or whatever and have to break everything in future
<danderson>
I did write my own amazing redo+shell scripts deployer for my home infra, but I don't want to inflict that on my coworkers
<dramforever>
I found some stuff but the variety of things to do just overwhelmed me, and I'm not sure... I wonder if there's anything better to do like actually diagnosing the problem instead of blindly applying everything
<infinisil>
danderson: Is morph or <something else> not close to what you want?
<danderson>
infinisil: morph doesn't have management outside of nixos (e.g. provisioning VMs, networks, terraform integration). I don't think I looked at any others beyond that
<danderson>
morph would be okay, but it would be a 50% solution for what we need. And to get to 100% I'd have to tear it all up and replace it with nixops 2.0
<infinisil>
Hm yeah I don't think any others support provisioning (yet)
<danderson>
yup. And maybe that's kinda okay. At $previous_job we used terraform and ansible separately
<danderson>
and I just trained people to run terraform first, then ansible
<danderson>
so I could do the same here. "run terraform to build the infra, then run morph to configure it"
<danderson>
("and also nixos-infect for the clouds that don't natively support nixos, and...")
<infinisil>
I think it would be great if there was a project just focused on getting a NixOS system on providers
<danderson>
infinisil: yeah, but that's hard unfortunately. For example DigitalOcean has ridiculous constraints on custom images.
<danderson>
you can import a custom nixos image and boot VMs with it... But if you do, you're not allowed to enable IPv6 on those VMs (???)
<infinisil>
danderson: Actually, nixpkgs has a builtin digitalocean image builder
<infinisil>
That sounds more like a bug than anything else
<danderson>
so instead you have to create an ubuntu VM from the standard DO image, nixos-infect it, snapshot that VM to a VM image, then create new VMs from that snapshot
<danderson>
it's really stupid, but it's "by design" (I know someone who used to work at DO)
<danderson>
there's some magic required to make ipv6 work on their networks, and for some reason they implemented it by only allowing "blessed" images to use ipv6
<danderson>
even though it's just "you need to configure ipv6 manually" basically
<infinisil>
Huh damn
<danderson>
anyway, that was just some random example :) I agree that it would be nice to have universal support for nixos on cloud providers
<danderson>
(it's extra stupid because if you nixos-infect a "blessed" image, then ipv6 works fine - but you have to start from a VM image that has the magic "can use IPv6" bit set)
<{^_^}>
[nixpkgs] @jonringer pushed commit from @r-ryantm to master « pmd: 6.25.0 -> 6.26.0 »: https://git.io/JUeIq
Supersonic112 has joined #nixos
<infinisil>
danderson: Btw, not that I'd recommend it or anything, but I'm also experimenting with my own deployment system, and I intend to add all kinds of features to it :) https://github.com/Infinisil/nixus
<Enzime>
zangi: infinisil: figured it out now, thanks
<danderson>
infinisil: heh, noted
cole-h has joined #nixos
<danderson>
if nixops 2.0 is stalled, maybe I'll give up and use terraform+<something>, so that's useful data
<{^_^}>
[nixpkgs] @jonringer pushed commit from @r-ryantm to master « arc-theme: 20200513 -> 20200819 »: https://git.io/JUeI6
<Church->
infinisil: Reminds me, we may soon have first class support for nixOS at prgmr.com
<Church->
After enough bothering of the owner hehe
<Church->
Which would be nice, fairly consistent offerings there
<infinisil>
Neat!
<Church->
Ya ya
<Church->
infinisil: Been hacking up python based expect stuff to interact with their serial console over ssh to configure a netboot nixOS image so far.
<siraben>
Do the channels update from time to time?
<siraben>
As if I ran nix-channel --update
<lassulus>
if you run nixos-rebuild switch --upgrade
<lassulus>
but otherwise: no
nekochen has quit [Ping timeout: 240 seconds]
<lassulus>
afaik
<siraben>
Ok
<NobbZ[m]>
There is also an auto update setting in config.nix, I'm not sure if that will only cause toots channels to update or users channels as well...
das-g[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
acidpointer[m] has quit [Quit: Idle for 30+ days]
<joesventek>
I'm trying to get hg-evolve working with mercurial. I installed `python38Packages.hg-evolve` as well as `mercurial`. Unfortunately `hg` can't find the evolve extension.
Aljosha[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
davegallant[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
mattock[m] has quit [Quit: Idle for 30+ days]
grahamc[m] has quit [Quit: Idle for 30+ days]
guelosk[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
joey_tribbiianii has quit [Quit: Idle for 30+ days]
<joesventek>
Is there anything I'm missing?
joschi has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
Addison[m] has quit [Quit: Idle for 30+ days]
lwbcdt[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
onny[m] has quit [Quit: Idle for 30+ days]
Philipp[m]2 has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
regivanx[m] has quit [Quit: Idle for 30+ days]
scratch171[m] has quit [Quit: Idle for 30+ days]
<joesventek>
Any hints on how to debug this?
sghir_med[m] has quit [Quit: Idle for 30+ days]
shider[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
sneknek[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
spazzpp2[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
ice7[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
yochai[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
MichaelRaskin has joined #nixos
zoickx[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
Soarin[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
ehmry[m]1 has quit [Quit: Idle for 30+ days]
AberDerBart[m] has left #nixos ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
j0hax[m]1 has quit [Quit: Idle for 30+ days]
Jan-HenrikBruhn[ has quit [Quit: Idle for 30+ days]
<avaq>
Hi all! I just tried out nixos-infect on a DI droplet I had just created, and after completing succesfully, I am now locked out of the system. :D -- The documentation on the nixos-infect repository is very minimal. Should I have provided some "optional" configuration to ensure I'm not locked out? eg. enabling sshd?
<infinisil>
avaq: Check out the ip routes and stuff in the console
<lassulus>
was just an idea, but if ping is not working it should be a networking issue
<infinisil>
avaq: Like, ping example.com, ip route, ifconfig
Dr8128 has joined #nixos
<avaq>
infinisil, I can't log into the web console, because I never set up a root password. I provisioned with an SSH key.
<infinisil>
Oh, sounds like a reset then!
<avaq>
Ok :p
<infinisil>
Can't fix a machine you don't have access to
<avaq>
I suppose that's true
turion has joined #nixos
<infinisil>
I suggest always setting a root password because of this
<avaq>
Lesson learned
<infinisil>
avaq: Alternatively you could use the digital ocean image builder in nixpkgs
<infinisil>
Makes getting NixOS running a breeze
<avaq>
Oh?
<avaq>
I'm trying to get a nixops-deploy-targettable droplet up and running via the shortest possible route.
LnL has quit [Ping timeout: 240 seconds]
<infinisil>
avaq: Include { imports = [ <nixpkgs/nixos/modules/virtualisation/digital-ocean-image.nix> ]; } in a default.nix file, then `nix-build '<nixpkgs/nixos>' --arg configuration ./default.nix -A config.system.build.digitalOceanImage` to build the image
<infinisil>
Then upload it via digitaloceans custom image uploader
<infinisil>
And then easily create as many droplets as you need :)
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
<avaq>
Cool! I'll give it a go!
<infinisil>
Oh and I guess you want to include your ssh keys in the default.nix
Nafai has quit [Ping timeout: 256 seconds]
<infinisil>
Though I think that may be handled automatically too if you give the ssh keys in the interface
<infinisil>
Yeah
<infinisil>
So that default.nix should probably be enough to get it to start
FRidh has joined #nixos
<avaq>
I have to create a new droplet to upload the custom image, right?
<avaq_>
infinisil, it worked, and I can ssh into it - thanks! :D
<infinisil>
AD
<infinisil>
:D
<infinisil>
avaq_: And I think for nixops or anything else, you also just need to add the same file to `imports` in configuration.nix
<infinisil>
Not entirely sure about that, haven't tried it
<avaq_>
I copied what I found on the machine in /etc/nixos/configuration.nix into my nixops config for this target. That should do it, right?
<infinisil>
Ah yeah that should work too
<nature>
nixops seems to use root to connect via ssh, is there a way to use the unpriviledged nixos user ? Or will it messes with the way nixos handles the config changes ?
<infinisil>
Hm though I'm just noticing that it doesn't set stateVersion
<{^_^}>
[nixpkgs] @turboMaCk opened pull request #95986 → services.imwheel: sleep 3s before restarting → https://git.io/JUv3n
Nafai has joined #nixos
<infinisil>
avaq_: Maybe add a `system.stateVersion = "<release you installed from>"` as well to prevent future breakages
<avaq_>
I did that :)
<infinisil>
Nice :)
Rusty1 has joined #nixos
<nature>
is it even recommended to change that behaviour ?
<{^_^}>
nixops#1270 (by adisbladis, 20 weeks ago, merged): Add support for non-root deployments
<nature>
Thanks
zangi has quit [Ping timeout: 265 seconds]
LnL- has joined #nixos
LnL- has joined #nixos
LnL- has quit [Changing host]
marcusr has quit [Remote host closed the connection]
zangi has joined #nixos
marcusr has joined #nixos
<avaq_>
infinisil, nixops deployment went smooth; I added it as a new machine to an existing code base of nix machines I manage, so it instantly gets all the goodies that I care to share between all machines. This is great! :D
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fendor has quit [Quit: Leaving]
<{^_^}>
[nixpkgs] @rnhmjoj opened pull request #95988 → nixos/release-notes: mention GRUB password support → https://git.io/JUvsp
<chus1818>
Hi! I was trying to include https://github.com/tweag/jupyterWith in my nixos but as I am new to nix I'm struggling a bit. I thought it'd be a matter of adding the specs on the "Using as an overlay" section of the readme to my configuration.nix, but it's clearly not the way.
CMCDragonkai1 has joined #nixos
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<neonfuz2>
Hey so I'm trying to add python to a build, is this an okay way to do it?
<neonfuz2>
is this correct? or is there some way to add python3 to the path during build so I don't need to do this? I thought because it did /usr/bin/env it would look in path, but during nix-build it fails saying invalid interpreter /usr/bin/env or something like that
<nij>
Does anyone know the default putty's rgb code of its color palette :D ?
<__monty__>
neonfuz2: Looks ok. Though make sure the programs are python 3 compatible. "python" is always supposed to point to a python2 interpreter.
<__monty__>
neonfuz2: One of the default phases should take care of something like this though I think.
<neonfuz2>
I'm not a python programmer but the print statements had parentheses, isn't that python 3?
<__monty__>
Not necessarily. It hints at a python 3 compatible style though.
<neonfuz2>
well python3 seems to work, I could try python2
<neonfuz2>
is python2 preferable for some reason
<__monty__>
Only if the code isn't py3-compatible.
<{^_^}>
[nixpkgs] @Lassulus merged pull request #89353 → stage-1: retry mounting ZFS root a few times → https://git.io/Jfiyv
<__monty__>
chus1818: Ok, so I'd do `nixpkgs.overlays = let jupyterWithPath = blah; in [ the three overlays ]; and then you should be able to use nixpkgs.jupyterWith elsewhere.
avaq has quit [Ping timeout: 258 seconds]
Darkmatter66 has joined #nixos
<neonfuz2>
<__monty__ "Only if the code isn't py3-compa"> just tested it, python 2 works, I'll just use 'python' instead of 'python3'
<chus1818>
__monty__: It seems to have been able to successfully build it thanks! But when I try to add it to environment.systemPackages it fails with: The option value `environment.systemPackages.[definition 4-entry 8]' in `/etc/nixos/configuration.nix' is not of type `package'.
arjen-jonathan has joined #nixos
<__monty__>
chus1818: Are you specifying "jupyterWith" as a package? It's a nix function, you can't make it available on the command-line or whatever.
<{^_^}>
[nixpkgs] @risicle opened pull request #95990 → [20.03] nghttp2: add patch for CVE-2020-11080 → https://git.io/JUvZT
CMCDragonkai1 has quit [Ping timeout: 265 seconds]
<chus1818>
__monty__: I see. What I wanted to achieve was to reproduce the same behaviour I get when I run a nix-shell with the config defined on the first snippet of the REAME, in which I get access to `jupyter` on the command line, without going through the nix-shell
mallox has joined #nixos
mallox has quit [Client Quit]
arjen-jonathan has quit [Ping timeout: 272 seconds]
<__monty__>
Hmm, try using `(jupyterWith.jupyterlabWith { kernels = [ (jupyter.kernels.iPythonWith { name = "python"; packages = p: with p; [ numpy ]; }) ]; }).env as a package.
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
<__monty__>
Using some lets like in the example wouldn't be a bad idea.
<chus1818>
__monty__: Almost, but unfortunately I'm getting: building '/nix/store/ilb2q7938kxc47yia1yxjxl0ly9n7vk6-jupyterlab-shell.drv'... nobuildPhase - This derivation is not meant to be built, aborting
<turion>
I have a shell.nix for my local haskell project. How do I properly override the packages in there such that I can select both the correct version (not the one from nixpkgs) and disable the test suite?
<evelyn>
There are a bunch of paths that don't get removed with nix-collect-garbage -d, despite no user env or system packages listing the packages in question. How can I see what depends on these paths?
Mateon1 has quit [Ping timeout: 265 seconds]
<evelyn>
E.g. I have 2 versions of KeePassXC which I don't want on my system, and I can't work out how to remove them.
leo60228 has quit [Ping timeout: 256 seconds]
<sphalerite>
evelyn: you can use nix-store -q --roots on a path to see which GC roots reference them
sedx\_` has quit [Ping timeout: 258 seconds]
<evelyn>
I get something like '{lsof} -> /nix/store/yfayacg6ycggv0yxs5pppsawn6yap6p5-keepassxc-2.5.4'
hiro99 has quit [Remote host closed the connection]
johnny5 has joined #nixos
johnnyfive has quit [Ping timeout: 240 seconds]
Mateon1 has joined #nixos
<maralorn>
turion: can you maybe show your shell.nix? In principle you write an overlay that you apply via pkgs.haskellPackages.extend (self: super: { your-package = pkgs.haskell.lib.dontCheck super.your-package} )
<maralorn>
turion: To get other versions of packages you can a) hope that the package exists already in nixpkgs as package_0_1_0 or you use the "callHackage" and "callHackageDirect" functions.
<turion>
It's a tad messy, sorry about that. I'm experimenting around a lot and some experiments still float around
<turion>
The basic idea is to pin GLFW-b to an older version, and to compile gloss with a particular flag that makes it have that version of GLFW-b as a dependency
<maralorn>
turion: Oh, I might have led you astray before.
<maralorn>
turion: does the ${compiler}.override stuff work in principle?
<maralorn>
If it does, just do "GLFW-b = self.callHackageDirect <the GLFW-b version you want>" in there.
<maralorn>
And for the particular flag, you might not need to set it because I think cabal will automatically use the first setting of flags it can find that result in a working build plan.
<maralorn>
If you still need to override you can use haskell.lib.enableCabalFlag
<{^_^}>
[nixpkgs] @cpcloud opened pull request #96001 → tensorflow-lite: init at v2.0.0 → https://git.io/JUvWh
fendor has joined #nixos
<turion>
maralorn: I have something like what you propose with callHackageDirect, but it doesn't get picked up correctly
<turion>
My trouble is to understand in which places I need to apply what function
<maralorn>
turion: How so?
<maralorn>
turion: Yeah, it's a bit messy.
<turion>
maralorn: If I uncomment line 47 where I'm adding the hackageDirect version (and possibly do one or two other tweaks), I'm getting "dependency "GLFW-b-1.4.8.4-8Qf0sy8uEhXIlnN8rfaGOJ" doesn't exist"
<turion>
(When I try to open a shell)
<turion>
By that I'm assuming that I somehow didn't pass GLFW-b properly as a dependency to gloss
<turion>
Which might be because it didn't get the flags which make it have GLFW-b as a dependency in the first place
<maralorn>
turion: I think in general, when you use foo.callHackageDirect the dependencies are taken from foo. So I think it would be better to use self.callHackageDirect instead of haskellPackages.callHackageDirect in your overrides function.
johnnyfive has quit [Quit: I quit now.]
johnnyfive has joined #nixos
Dr8128 has quit [Ping timeout: 265 seconds]
<turion>
maralorn: Good point. I'll try that as well
<turion>
I'm sometimes fuzzy about super vs. self there
<turion>
I guess in that case using self won't lead to an infinite recursion
<maralorn>
turion: Well the rule is easy: Always use self when it works, if not use super. The tough part is knowing when it will create a recursion. But in general everything of the form "foo = someFunc self.foo" will create a recursion.
<turion>
Makes sense
<turion>
And since my dependency tree won't be circular, it's no problem to to use self for package overrides
<turion>
maralorn: I'm doing something wrong with dontCheck though. It always tries to execute the GLFW-b test suite.
<maralorn>
turion: If you use self at the right places you can probably also get rid of overriding those buildInput lists.
<maralorn>
turion: essence-of-live-coding and deps.
<turion>
I just supply the versions there because I'm releasing them faster than stackage/nixpkgs snapshots
<maralorn>
turion: Btw, regarding your comment for http-client. nixpkgs always uses the version from the latest stackage LTS release. When that happens the newest hackage version also exists but with the name. foo_version. So in this case you can get rid of callHackageDirect and just use http-client_0_7_1.
<turion>
maralorn: I believe now I'm already much further. I just pushed a version that incorporates some of your help
<nature>
I am currently setting up nixos on my raspberry pi 4 (which is a machine that requires bios to boot afaik) and when running nixos-rebuild switch I have a grub error related to an EFI directory
<sedx\_`>
But now I am writing you not to associate with anyone who claims to be a believer who is sexually immoral or greedy, an idolater or verbally abusive, a drunkard or a swindler. Do not even eat with such a person.
sedx\_` has quit [Quit: Nor cheats (swindlers and thieves), nor greedy graspers, nor drunkards, nor foulmouthed revilers and slanderers, nor extortioners and robbers will inherit or have any share in the kingdom of God. https://bit.ly/33tb5lx]
<infinisil>
How terrible is this idea: Require everybody opening a PR to first review 2 other PRs
davidv7_ has quit [Ping timeout: 265 seconds]
<simpson>
Is that the bottleneck? If so, then it's worth considering.
sangoma has quit [Ping timeout: 258 seconds]
<nature>
does anybody know anything about this error: `/nix/store/bd78qrcgnlg7djfsfnnswx3xxq8fwbhn-grub-2.04/sbin/grub-install: error: cannot find EFI directory.` ?
<{^_^}>
[nixpkgs] @baloo opened pull request #96011 → audit: fixup support for static build → https://git.io/JUvBQ
<bqv>
Yikes
<infinisil>
simpson: It might not be a bottleneck, but it would help the mergers
<bqv>
Evangelists in #nixos
<infinisil>
And it might naturally decrease the amount of PRs over time
<infinisil>
At equilibrium, every PR would have 2 reviews then on average
philr has quit [Ping timeout: 240 seconds]
<bqv>
Seems more like plain old barrier to entry. Reviewing isn't really the issue, it's getting noticed and/or merged
<simpson>
infinisil: Or maybe it'll cause PRs to not be opened. Which is fine IMO and still helps your metrics, but might not serve your ultimate goals.
<cole-h>
infinisil: An interesting idea, but what about people who are extremely new to the NixOS ecosystem?
<{^_^}>
[nixpkgs] @Lassulus merged pull request #87553 → nixos/monit: Allow splitting the config in multiple files → https://git.io/JfW7p
<{^_^}>
[nixpkgs] @baloo opened pull request #96012 → pciutils: fixup musl support → https://git.io/JUvBb
<cole-h>
e.g. people who have no idea how to properly review a PR, or are updating their own package despite not really using Nix/NixOS
<MichaelRaskin>
Scaling curve!
<infinisil>
bqv: Reviews help though, even with getting noticed (PR is higher up in activity, gets comments, pings people, etc.)
<infinisil>
cole-h: That might have a positive effect of them getting more into the code base
<infinisil>
(or it might not!)
<MichaelRaskin>
(start at zero, climb up to double the number of one's PRs over time, at some point it makes sense just to give commit access already anyway)
<lassulus>
I hope someday maintainers can update packages they maintain without waiting for someone with the merge bit
<maralorn>
Well we could try to introduce some currency, that you can by earn reviewing and can spend by doing reviews?^^ I think opening a PR should be free, especially for people who don‘t have the knowledge to do reviews.
<cole-h>
lassulus: Some day, we'll get there.
<infinisil>
Oh I don't like the idea of a currency hah
<lassulus>
Also I think package bumps should be automatically merged if no one complains after like 3 months
<infinisil>
maralorn: Should opening a PR be free though?
<{^_^}>
[nixpkgs] @baloo opened pull request #96014 → lvm2: support static comilation → https://git.io/JUvRJ
<infinisil>
We currently have the problem of too many open PR's and too little reviewers
<cole-h>
infinisil: While I like the idea, I don't think it's worth it if there's any non-zero chance of the user just saying "Screw this, I'm out"
<infinisil>
reviewers and mergers
<cole-h>
lassulus: Low-impact bumps, at least.
<infinisil>
cole-h: I've seen a couple people saying that from our current state of PRs often being in limbo though
<cole-h>
lassulus: I'd hate to see something like systemd get an autobump (idk if ry*ntm has a blacklist for those kinds of packages), then automerged 3 months later breaking literally everything :P
<lassulus>
well it would just break on unstable
<cole-h>
Which could have been avoided by not merging it in the first place
<lassulus>
well not updating software is not a solution
<MichaelRaskin>
Well, systemd of all things _does_ have NixOS tests that happily break
<cole-h>
infinisil: Fair. But I'd rather get more newbies than turning them away just because they have to do two tedious tasks
<lassulus>
nixpkgs review needs more gameification
<nature>
Is there any way to specify the platform for grub 2 ?
<infinisil>
But then again, having them review other PR's would be a great learning exercise to get the hang of nixpkgs
<infinisil>
And it would encourage us to improve the materials for learning that
<lassulus>
I feel by making reviews mandatory the quality of reviews would deteriorate
<infinisil>
Reviewing other PRs can be as simple as just building the package and running it
<{^_^}>
[nixpkgs] @baloo opened pull request #96016 → libselinux: fixup musl support → https://git.io/JUvRE
<MichaelRaskin>
The question is what we actually need of reviews
<infinisil>
I feel like this would almost need a "trustworthiness score", where reviews by newer people get checked by more settled ones
<MichaelRaskin>
Hopefully one day NixOS-container-inside-nix-build gets merged…
<MichaelRaskin>
There are clearly _different facets_ to review
<cole-h>
I feel like that would put more of a load on the well-adjusted contributors
<hexa->
lassulus: awaiting your rfc for more gamification :D
<cole-h>
infinisil: Now, instead of them reviewing PRs on their own, they're reviewing reviews of PRs
sangoma has joined #nixos
<cole-h>
It's a tough problem.
<{^_^}>
[nixpkgs] @baloo opened pull request #96017 → guile: fixup musl support → https://git.io/JUvRg
<infinisil>
Hm yeah
cosimone has joined #nixos
<{^_^}>
[nixpkgs] @baloo opened pull request #96018 → glib: fixup musl support → https://git.io/JUvRV
<MichaelRaskin>
Like, there is a question «does it build» (possibly eventually fully automatable? or not), there is a question «does it work» (will cheaper NixOS container tests instead of horribly bloated NixOS VM tests make test coverage competitive with what people test during «launch&click at random»?)
<MichaelRaskin>
There is a question «does not seem to sneak in stuff that should not be sneaked in»
<MichaelRaskin>
There is a question «follows the current convenitions» (that nobody actually have reached full consensus on, by the way)
<lassulus>
hexa-: I think just having a daily leaderboard by: reviewed pkgs, openened PRs, removed lines of code would be a good start
<lassulus>
or have points lose value after time :D
<cole-h>
lassulus: What about closed (as in resolved/fixed) issues, as well?
<lassulus>
sure, add all the stats
<hexa->
hmm, nixpkgs integration for habitica
sangoma has quit [Read error: Connection reset by peer]
<infinisil>
Maybe we just need more and better CI
<lassulus>
also we should maybe track unmaintained packages somehow..
<infinisil>
And more NixOS tests
<lassulus>
more tests is always nice
<hexa->
+1
<MichaelRaskin>
We need lighter NixOS tests
<infinisil>
Especially faster CI would be nice
LnL has quit [Quit: exit 1]
<hexa->
MichaelRaskin: lighter as in container based?
<lassulus>
faster than ofborg or faster than hydra?
cosimone has quit [Quit: Quit.]
<infinisil>
lassulus: Both are pretty slow, so yes
LnL has joined #nixos
<{^_^}>
[nixpkgs] @baloo opened pull request #96019 → qemu: adds tpm support → https://git.io/JUvRH
<bqv>
Unstable is kindt treated like a stable channel. If instead there was an actual testing channel, and people were much less apprehensive about merging stuff into it, it could periodically get merged into "unstable"
<cole-h>
😬
<MichaelRaskin>
Container based, or forget full init and full VMs and do the barebones for testing packages or something
<bqv>
Outsource the testing to people who care
<lassulus>
well we have a testing channel
<bqv>
lassulus: staging?
<lassulus>
yes
<lassulus>
staging it was
<lassulus>
but I guess there is a difference
<bqv>
has other purposes, really
fendor has quit [Remote host closed the connection]
<MichaelRaskin>
Because my LibreOffice test that got rejected for duplicating too much functionality ran faster than an empty boot NixOS VM test
<MichaelRaskin>
staging tries to fix builds of a ton of stuff with some bump
<{^_^}>
[nixpkgs] @baloo opened pull request #96020 → unbound: disable lto on static builds → https://git.io/JUvRb
<MichaelRaskin>
Which makes it again careful about changes, although in a different way
<MichaelRaskin>
But yeah, would be nice to have a branch with policy «non-malicioius / code looks fine / builds (and tests not broken)» → merge
<maralorn>
infinisil: The currency idea was not very serious. But I think just discouraging PRs is not the way to go. We need to find a way to deal with those.
<bqv>
Like, if the issue is mergers are peevish cause they don't want to break things, have a place where the expectation is that things will break, and outsource actual testing to the userbase reckless enough to use it
<MichaelRaskin>
Discourage PRs until people who say there are too many committers give up
<bqv>
Of which I can basically guarantee there will be plenty
LnL has quit [Ping timeout: 258 seconds]
<lassulus>
maybe we should also split the packageset someday, some baseset with packages needed for install, basic usage and an extra? set for everything else
shibboleth has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
LnL has joined #nixos
<infinisil>
MichaelRaskin: s/many/little ?
<MichaelRaskin>
lassulus: that makes glibc bumps worse
<lassulus>
I'm always unhappy if a PR adds a 5000 lines lock file converted to nix
<MichaelRaskin>
infinisil: there are people who think there are _too many_ committers
<infinisil>
wat
<infinisil>
Well, I guess there are a bunch of inactive ones
<infinisil>
But I don't think there's too many active committers
<infinisil>
And don't know why anybody would think otherwise
<lassulus>
maybe commit bits should be set inactive after an incativity period?
<MichaelRaskin>
They think there are too many semi-active committers to be able to understand who one has to trust
<MichaelRaskin>
infinisil: I can try to look up some of the discussions where this opinion came up, if you think it is worth a moderate amount of effort
<lassulus>
so sad to see the list of inactive maintainers
<infinisil>
MichaelRaskin: Nah I'm good :)
averell has joined #nixos
<MichaelRaskin>
Actually the list of retired committers is pretty short
<infinisil>
lassulus: Eh, people move on to different things, it's a natural thing
<MichaelRaskin>
People like me who do _some_ stuff but less than back in a day — that's a larger group, sure
<MichaelRaskin>
I mean, actively malicious ones would be risky
<bqv>
That would be why we still have mergers :p
<MichaelRaskin>
infinisil: well, you can run system core from unstable still
<bqv>
As a model, it works for other distros
<MichaelRaskin>
Also, there is sometimes such a things as upstream data-loss bugs (although our review process is not up to catching these)
ramses[m] has joined #nixos
sangoma has joined #nixos
<bqv>
If its been it testing for a while, its probably safe
LnL has quit [Quit: exit 1]
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
<infinisil>
MichaelRaskin: Oh what if we had tests that fetched the previous releases versions of things and did a migration
<bqv>
Better wait for that, than someone to take pity and finally merge it
<infinisil>
We could do that easily with IFD
<MichaelRaskin>
I have a feeling any major branch restructuring will be blocked by the need for flake-based break-up of monorepo to crash and burn first
<bqv>
MichaelRaskin: well thats a spicy debate to be had
<MichaelRaskin>
infinisil: it's not always immediately obvious on migration
<MichaelRaskin>
I mean, or succeed, but no unrelated progress on repository structure will be made until one of the outcomes actually happens
leo60228 has quit [Ping timeout: 265 seconds]
LnL- has joined #nixos
LnL- has joined #nixos
LnL- has quit [Changing host]
<MichaelRaskin>
A bit like manual structure discussions being unlikely until all this format migration stuff settles to some outcome
<superbaloo>
how is ofborg triggered?
<superbaloo>
I submitted a couple PR, some of them are picked up for tests, some others not
<kini>
I want to make a PR that will go into the 20.03 channel. What should the target branch be? nixos-20.03, release-20.03, or staging-20.03? I think staging is for things that cause a lot of rebuilds, but I'm not sure the difference between nixos-20.03 and release-20.03
turlando has quit [Ping timeout: 265 seconds]
sangoma has quit [Read error: Connection reset by peer]
<maralorn>
kini: nixos-20.03
mallox has quit [Quit: WeeChat 2.9]
<maralorn>
release-20.03 is automatically advanced when the corresponding channel has passed tests and got bumped to a new commit.
mallox has joined #nixos
<cole-h>
maralorn: Other way around
<lassulus>
I think its the other way around
<cole-h>
nixos-20.03 is automatically advanced, release-20.03 is the branch PRs should target
<maralorn>
Nice
<{^_^}>
[nixpkgs] @danieldk opened pull request #96025 → postgresqlPackages.age: init at 0.2.0 → https://git.io/JUvEk
eoli3n_ has quit [Remote host closed the connection]
<maralorn>
Just claim something wrong on the internet and suddenly you get very good input.
<maralorn>
;-)
<cole-h>
:D
<kini>
Ah, thanks all. I tried searching github for PRs targeted to each branch, and I found open ones on both. I guess the open ones on nixos-20.03 need to be retargeted then (there are much fewer of them, admittedly).
<maralorn>
I normally just look into the git log and look which one is more advanced.
<lassulus>
I though it was impossible to target against nixos-20.03?
<lassulus>
wonder what happens when I try to merge on of those
<{^_^}>
[nixpkgs] @baloo closed pull request #96011 → audit: fixup support for static build → https://git.io/JUvBQ
<alexarice[m]>
on the getting more reviewers problem, would it help if there was more clarification on what is an easy pr to review, I think it is probably quite daunting to try and review things as someone who is new to the system, but if there was some flag that said "you literally need to run `nix review`" it might encourage more reviewing
<alexarice[m]>
Would also mean that more experienced reviewers would know where their time is best spent
<lassulus>
IMHO the amount of reviews is not the problem, the people who can merge is the bottleneck. I don't think I would work faster if every PR had like 3 reviews
<alexarice[m]>
I guess, the merger will still have to try it out themself usually I guess
mallox has quit [Client Quit]
mallox has joined #nixos
<MichaelRaskin>
That should be fought
mallox has quit [Client Quit]
<MichaelRaskin>
(when I randomly decide to go merge something, I read the code for myself, but I am very trusting to people who say they tried and it runs)
<lassulus>
well my usecase is to run nixpkgs-review on it, then I have it in a nix-shell anyway and I can try it out. But most of the time a successful build is enough for me to merge it
<lassulus>
and the diff doesn't look suspicious
<MichaelRaskin>
I have old enough setup not to build things with nice diff and clean ofborg report
<kini>
Do committers all have uniform access to merge to all branches, and to merge PRs that touch any file? It might be easier to give more people merge permissions if the permissions could be restricted in some way.
<alexarice[m]>
kini: I think a system like this is wanted but hard to implement
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
<alexarice[m]>
I have found it can be hard to get small leaf packages merged, when it feels like it wouldn't even matter that much if it broke
<kini>
I think it's possible to restrict based on target branches, but restricting based on touched files would be much harder, given github's feature set (at least the last time I looked into such things)
<alexarice[m]>
kini: There was some suggestion about maintainers being able to merge updates for packages they maintain
AmandaC has quit [Remote host closed the connection]
<kini>
Also considering that most PRs probably touch pkgs/top-level/all-packages.nix, and people could easily screw up the whole repo by doing something careless on that file, maybe restricting by touched files is not that useful...
<alexarice[m]>
kini: I guess updates don't touch `all-packages` though, and a lot of PRs are literally just bumping a version number and hash
<kini>
oh, that's true.
Amanda has joined #nixos
<MichaelRaskin>
Well, breaking all-packages.nix is typically caught by ofborg…
<alexarice[m]>
Would argue all new packages should be looked over anyway
<kini>
Some projects that have a github bot (like our ofborg) give that bot merge permissions and implement more complicated permissions logic in that bot. (I think rustlang does this?)
kveroneau has joined #nixos
<kini>
alexarice[m]: good point
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
sangoma has joined #nixos
<kveroneau>
Hey, trying out NixOS for the first time, giving it a try through KVM, and when I try to switch the resolution to 1920x1080, it temporarily changes, then just reverts back to 1024x768. This doesn't happen with other distros running in KVM, is there a service or something running that might be causing it to revert back to 1024x768?
<kveroneau>
I tried to change it both through the KDE System Settings program as well as through "xrandr -s 1920x1080", it goes up to 1920x1080, then just reverts back to 1024x768 after a second or so.
<kveroneau>
I checked if the distro uses Wayland by default, but it seems to be going through X.org, so these resolution changing method should "just work".
<kveroneau>
Also, doesn't seem to be related to some sort of guest agent software for KVM, as resizing the SPICE client window doesn't auto-resize the resolution in NixOS. It will be much more useful at a higher resolution. Any help here would be great!
laubster has joined #nixos
<kveroneau>
Hmm, there's something I am reading called "autorandr", could that be causing it to revert back to 1024x768?
<kveroneau>
Figured it out, I killed the kscreen_backend process, it was for some reason enforcing a constant resolution of 1024x768. Now I can finally explore NixOS and see what it's all about. I am most curious about the unqiue filesystem hierarchy.
<kveroneau>
Okay, well that's not good. I installed the NixOS ISO which includes KDE, when running the LiveCD, Firefox was available, and thus the manual was openable. However, after the installation, it doesn't seem like the system has a browser installed, not even Konqueror which usually ships with KDE. How do you go about installing Firefox in order to read the HTML manual from the Plasma menu?
<kini>
Note to self / posterity: don't retarget PRs from master to a nixos release branch, because since you can't do that atomically at the same time as pushing a rebased branch, so github automatically adds all code owners of anything that differs between master and the release branch as reviewers to your PR 🤯
<kini>
guess I should have just created a new PR... geez
<lassulus>
kveroneau: you can add firefox to environment.systemPackages in you configuration,nix
<lassulus>
or temporarily inside a nix-shell with `nixs-shell -p firefox`
leo60228 has joined #nixos
orivej has quit [Ping timeout: 240 seconds]
<lassulus>
`nix-shell -p firefox` ^
<samueldr>
kini: use `git merge-base` and rebase on that
<samueldr>
force push first, which should be a no-op, and then you can change
orivej has joined #nixos
<kini>
samueldr: Ah, that's a good idea, didn't think of that. Thanks! I'll keep that in mind.
<kini>
so it'll be like, 1) rebase on the merge base 2) force push 3) retarget the PR 4) rebase on the release branch 5) force push again
* samueldr
re-read the problem
<kveroneau>
lassulus, thank you, that worked. The website mentioned to install packages using "nix-env -i ...", but that oddly just took a lot of CPU, and the kernel ends up killing the process for whatever reason.
<samueldr>
if it was to target a release-yy.mm branch, it probably wouldn't work
<samueldr>
kini: I had in mind master vs. staging
<samueldr>
the rebases would probably end up not working fine
<samueldr>
so yeah, new PR and closing the older one :(
<samueldr>
(or rebasing a dummy commit, pushing, switching, then re-doing the actual change)
<lassulus>
kveroneau: well nix-env -i is quite inefficient, nix-env -iA is more preferred since it gets the packages by attribute path. Maybe the website should be fixed to discourage using nix-env -i
<kini>
samueldr: Really? I think it should work fine even with a release branch. What problem do you foresee?
<samueldr>
hugely divergent history :)
endformationage has joined #nixos
<kini>
I mean, there may be merge conflicts during the rebase, but that's unavoidable. There would probably be merge conflicts when rebasing directly onto the release branch anyway.
<samueldr>
your rebased changes probably won't apply cleanly
<samueldr>
yeah
<samueldr>
exactly :)
<samueldr>
more work than none
<kini>
I think it's no more work than what you would have to do either way -- even if you open an entirely new PR, if you started with some work you'd done on master, you'd have to fix those conflicts in order to redo your work on the release branch. Unless you just started over and redid your changes from scratch...
<MichaelRaskin>
Well, you can force-push the initial commit of the repo, switch, then force-push whatever you would like to apply to release branch
<samueldr>
though, kini, just checking first, you do know that it's extremely rare to make changes on release branches without first going through master and cherry-picking changes, right?
<MichaelRaskin>
You don't need the same branch for force-push, after all
<kini>
samueldr: I did not know that. The PR is #94301, I figured maybe it made more sense to target it to the release branch since it is a backport of an upstream change from a version we may be getting into master soon-ish anyway
<samueldr>
yes, changes going through the release branches have to have an equivalent change in unstable
<samueldr>
the "equivalent change" here *could* have been the upgrade to plasma 5.20, and then maintainers of plasma would share their opinion about backporting the specific change
<kini>
lol, pushing the merge base closed it. But at least it didn't add dozens of reviewers... next I'll rebase on master and push again, and then I guess I'll have to manually reopen the PR
<kini>
no, this won't work, since it won't let me retarget the PR now that it's closed
Hirmes[m] has joined #nixos
<kini>
OK, I guess at this point the only thing to do is open a new PR. D'oh.
slack1256 has quit [Ping timeout: 258 seconds]
LnL| has quit [Ping timeout: 240 seconds]
<{^_^}>
[nixpkgs] @bbigras opened pull request #96026 → nixos/manual: fix typo in man-nixos-enter.xml → https://git.io/JUvzV
<MichaelRaskin>
I mean, you probably can force-push a completely no-op commit, reopen, retarget, push the real thing…
<MichaelRaskin>
But sure, no worth it.
FRidh has quit [Quit: Konversation terminated!]
<kini>
Good idea, but yeah, at this point I'm afraid that all those reviewers are getting emails every time I do anything with this PR, lol
<kini>
even though I removed them as reviewers, I'm not sure how github's email-sending logic works
<MichaelRaskin>
Good question
<MichaelRaskin>
No idea, as I am subscribed to the repo (I skim the thread titles only, obviously)
<MichaelRaskin>
But yeah, I think at some point GitHub said that I am participating in some issue and search showed no realistic visible candidates for a reason…
<kini>
The whole repo!? How many emails are you getting per second? :P
<MichaelRaskin>
Not _that_ much
<MichaelRaskin>
But maybe one a minute, that might be
<manveru>
is there a way to build a drv when i only know its path but it's not on the local machine but in a cache?
<MichaelRaskin>
nix-store -r seems to try to substitute the drv's, too
leo60228 has quit [Ping timeout: 256 seconds]
<manveru>
oh, that's beautiful :D
<MichaelRaskin>
Did it actually work out?
<manveru>
well, it's pulling stuff :)
<MichaelRaskin>
Cool
<manveru>
needed the out path, not the drv though
<manveru>
but no problem in this case
<{^_^}>
[nixpkgs] @kini opened pull request #96027 → powerdevil: backport fix for debug log spam → https://git.io/JUvzF
<kini>
^ reopened
<MichaelRaskin>
By out path it's easy
<MichaelRaskin>
By I think you can even do it by drv path
<manveru>
it really doesn't matter, i actually prefer out
<M0-[m]>
Is there any way to configure NixOS with flakes so that I can have everything based on stable by default (`nixosConfigurations.<host> = <stable input>.lib.nixosSystem {...}`) but also have access to the unstable repo as an input?
<ris>
is there any tool that will tell me whether two outputs are "identical"? i think a package has an unnecessary dependency - it builds fine without it, but i don't feel i can be sure unless i can check it doesn't affect the output. of course it's a little trickier than just binary equality, because the different outputs could contain self-references which would be for different hashes
LnL- has quit [Ping timeout: 240 seconds]
LnL- has joined #nixos
LnL- has joined #nixos
LnL- has quit [Changing host]
<Extends>
M0-[m]: to access packages from unstable you can create an overlay (check the wiki page of the flakes to see how it's done)
<simpson>
ris: By definition, I'd imagine that this is not a well-founded desire. If the package's tests still pass, then it's probably fine; reach out to the package maintainer if you're not sure, or open a PR and see what they say.
<M0-[m]>
<ris "is there any tool that will tell"> I thought with nix you just look at the hashes
<ris>
simpson: you're assuming the package has a maintainer ;)
<M0-[m]>
Extends: thanks
<simpson>
ris++ Last person to touch it now owns it. Congratulations on becoming a package maintainer!
<{^_^}>
ris's karma got increased to 5
<ris>
mothaf...
fendor has joined #nixos
arjen-jonathan has joined #nixos
<ris>
M0-[m]: the hashes won't be the same - that's the point - they have different build inputs, but it's a possibility that they could produce an effectively identical output
<simpson>
ris: I'd work backwards: If adding an input doesn't alter any of the output artifacts, then the input can't possibly have been used. This is counterfactual reasoning.
<M0-[m]>
ris: doesn't that defeat the whole purpose of hashes? I didn't realize practically speaking that collisions were something to worry about in nix
<ris>
M0-[m]: no, package hashes are based on _input_ parameters, not their outputs
<energizer>
hopefully that'll change soon
<{^_^}>
[nixpkgs] @matthewbauer pushed 0 commits to cuda11: https://git.io/JUv2X
<ris>
simpson: mmmmnot necessarily, there are plenty of build tools that will build features opportunistically - "oh, can't find tool foo, won't build support for bar"
<{^_^}>
nix#296 (by Mathnerd314, 6 years ago, open): Intensional store model
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
<{^_^}>
[nixpkgs] @cpcloud opened pull request #96028 → picamera: init at 1.13 → https://git.io/JUv25
andreas303 has quit [Remote host closed the connection]
laubster has quit [Remote host closed the connection]
<ris>
energizer: reading that issue, it doesn't seem like there's much "soon" about it
<simpson>
ris: I can't imagine how that would affect things in the indicated way. Suppose foo only builds bar support when libbar is present; then, whether libbar is an input should affect the outputs, right? Or maybe I'm not understanding.
cole-h has quit [Quit: Goodbye]
andreas303 has joined #nixos
<energizer>
ris: idk, i find the nix development process pretty opaque
<leonardp>
i'm trying to install nixos.python37Packages.pelican which is marked broken
<leonardp>
i have { nixpkgs.config.allowBroken = true; } set
<ris>
simpson: i'm just trying not to assume too much about the build tool's behaviour - build tools are crazy. i'm assuming in that example that foo is some utility needed to be able to build bar support
<ris>
:shrug:
<leonardp>
some tests seem to be failing
<leonardp>
shouldn't allowBroken ignore that and install it regardless?
duckonomy has quit [Disconnected by services]
leo60228 has joined #nixos
duckonomy has joined #nixos
<simpson>
ris: I'm not trying to assume anything else, just thinking in a blackbox manner. Although now I'm starting to wonder if you've got an actual case in mind, or are wondering about a more general policy.
work_ has joined #nixos
<ris>
simpson: actual case - pythonPackages.kazoo has openjdk8
<ris>
doesn't appear necessary and is huge
<ris>
but from a blackbox perspective, it's definitely possible. build process checks for existence of foo, then does either A or B
<Null_A[m]>
I tried discord, discord-ptb and discord-canary always get the same
zupo has quit [Ping timeout: 258 seconds]
LnL has joined #nixos
LnL has quit [Changing host]
LnL has joined #nixos
<Yaniel>
Null_A[m]: is your channel up to date
<Null_A[m]>
oh right, thanks
zupo has joined #nixos
fendor_ has joined #nixos
fendor has quit [Ping timeout: 258 seconds]
ericmoritz has joined #nixos
ericmoritz has quit [Remote host closed the connection]
alexherbo2 has quit [Ping timeout: 240 seconds]
cosimone has quit [Quit: Quit.]
fendor_ has quit [Ping timeout: 240 seconds]
Dr8128 has joined #nixos
LnL- has joined #nixos
LnL- has joined #nixos
LnL- has quit [Changing host]
<simpson>
ris: I can't get the test suite to run, but I did read Kazoo's source. They only use Java in the tests, and their docs pride themselves on being pure-Python. https://bpa.st/SXRA should shrink the closure.
LnL has quit [Ping timeout: 240 seconds]
<ris>
ahisee this was a package put together before we were encouraging checkInputs
<ris>
but i think it isn't even used in the tests - i removed it completely with no effect
<ris>
and i was more interested in removing build deps
shibboleth has quit [Quit: shibboleth]
fnorddd has joined #nixos
<fnorddd>
Hello,
rajivr has quit [Quit: Connection closed for inactivity]
<fnorddd>
I have no man pages ( man man = man: no manual entry for 'man')nixos-option documentation.man.enable is true
<fnorddd>
nix-channel --help => sh: nroff: command not found
<turion>
maralorn: I've been meaning to update the nixpkgs manual on these things, but two things keep me from doing it: 1. When I need it most, I'm busy doing something else (in this case, preparing a tutorial for tomorrow) 2. I don't understand many of the finer points
<maralorn>
turion: I can‘t help with 1, but please hit me up if you have troubles with 2. I certainly don‘t know everything about haskellPackages but I took a pretty deep dive in the past months.
evelyn has left #nixos ["Guidheam ort droch bhreitheanas nuair thig ort latha na fìrinn."]
iqubic has joined #nixos
<tokudan>
__red__, I don't have experience with python packages, but did you use one of the provided nix pythonPackages.* or did you manually install it? for manual installation, that's basically expected
<__red__>
I used manual - alas
<__red__>
after further review, I think the issue is that it comes down in "wheel" form
<__red__>
so I guess I need to determine how to build all these things from sources
<__red__>
and not all of the packages appear to have sources
<__red__>
so... I duno what to do
<__red__>
I'll keep fighting I guess
<tokudan>
no idea what a "wheel" form is... if it's a precompiled form then yes, that's the problem
<__red__>
it is
mananamenos has joined #nixos
LnL has joined #nixos
<__red__>
annoyingly
<__red__>
I'm following the instructions in the nixos manual
luna has joined #nixos
<__red__>
but I dno't think there's a clean way to save ths
<__red__>
this
metreo has quit [Quit: Leaving.]
<tokudan>
which part of the nixos manual?
<__red__>
in the python area - talking about using venv
<iqubic>
How are dictionaries (for things like aspell and hunspell) managed on NixOS? I have a program I'm running via steam-run, and it's looking for a dictionary in one of the follwing locations: `/usr/dict/words', `/usr/share/dict/words', `/usr/share/dict/british-english', `/usr/share/dict/american-english'. Sadly, on NixOS, those files are not present. In fact, neither `/usr/dict' or `/usr/share' exist.
<{^_^}>
[nixpkgs] @tobim opened pull request #96037 → python38Packages.coloredlogs: disable tests on darwin → https://git.io/JUvrj
Dr8128 has quit [Ping timeout: 240 seconds]
<tokudan>
__red__, i cannot find venv anywhere in the nixos manual. usually when you use packages, you also do not install libraries, you just tell nix the actual program you need
<iqubic>
This program also lets me pass in my own dictionary file with the -d flag, but 1. I don't know how to pass in command line args with steam-run, and 2. I don't know where the right dictionary file is.
<__red__>
I'll keep fighting the good fight I guess
<mananamenos>
hi, i build a project with `nix-build --attr exe`. Now I want to stick this build to ExecStart in systemd service in my configuration.nix. Should I write ExecStart=${nix-build --attr exe} or something different?
<mananamenos>
im trying to put this in my configuration.nix `ExecStart = nix-build /home/mananamenos/demo-project/default.nix --attr exe;` but it does not work (nix-build is undefined) :/ How do I have to write this? :/
<{^_^}>
[nixpkgs] @koslambrou opened pull request #96038 → hdt: init at 1.3.3 → https://git.io/JUvoa
<{^_^}>
[nixpkgs] @primeos pushed commit from @doronbehar to master « nheko: dirty fix to #94942 (#95060) »: https://git.io/JUvoQ
euandreh has quit [Remote host closed the connection]
<luna>
Hey, I'm finding that nixpkgs.qt5.qtbase uses version 5.14, but the version in protonmail-bridge/default (I guess) needs to be 5.13. Is there a way to set that up?
LnL has quit [Client Quit]
LnL has joined #nixos
euandreh has joined #nixos
<luna>
Oh, actually it is calling the wrong one, so I don't know if 14 works.
<mananamenos>
Hayden[m], I' trying like this: ExecStart = ''${nix-build /home/mananamenos/demo-project/default.nix --attr exe}''; However, im getting undefined variable nix-build
<mananamenos>
i can go to demo-project folder, execute `nix-build default.nix --attr exe` and then have `ExecStart = /home/mananamenos/demo-project/result/bin/demo-project`. But I want this to be defined in configuration.nix so the build is triggered automatically when i do `nixos-rebuild switch`
<lunaa>
Is anyone familiar with how to determine what version of qt is installed?
dbmikus has quit [Ping timeout: 265 seconds]
lunaa has quit [Disconnected by services]
benschza_ has joined #nixos
lunatera has joined #nixos
benschza has quit [Ping timeout: 260 seconds]
metreo has joined #nixos
dbmikus has joined #nixos
LnL has quit [Quit: exit 1]
LnL has joined #nixos
LnL has quit [Changing host]
LnL has joined #nixos
metreo has quit [Client Quit]
<nature>
Trying to use nixops to manage a rpi4 from my laptop and I have an error concerning a package that is not supported by 'x86_64-linux'
<nature>
Maybe I don't understand how nixops is supposed to work, but to me it seemed that you write in your machine configuration the same as you would in configuration.nix on the host directly
<nature>
Am I missing something ?
dbmikus has quit [Ping timeout: 240 seconds]
turion has quit [Ping timeout: 272 seconds]
lunatera has quit [Quit: Leaving]
<infinisil>
nature: That's right, but there's one difference: nixops evaluates and builds the systems on your local machine by default, which won't have the same architecture as the rpi4
<{^_^}>
[nixpkgs] @MilesBreslin opened pull request #96039 → evscript: Init at git-47f86f0 → https://git.io/JUvKD
<infinisil>
rebuilding on the rpi4 itself worked because it defaulted to its own arch
<infinisil>
nature: So I believe you need to set `nixpkgs.localSystem = "<the rpi4 arch>"` to make this explicit
cosimone has quit [Quit: Quit.]
siel has quit [Remote host closed the connection]
user_0x58 has quit [Ping timeout: 258 seconds]
kahiru has quit [Read error: Connection reset by peer]
dbmikus has joined #nixos
kahiru has joined #nixos
LnL has quit [Quit: exit 1]
LnL has joined #nixos
LnL has joined #nixos
LnL has quit [Changing host]
zebrag has joined #nixos
inkbottle has quit [Ping timeout: 258 seconds]
work_ has quit [Quit: Connection closed for inactivity]
ShaRose has quit [Quit: I appear to have left for some reason.]
<nature>
infinisil: would this possibly have unforseen consequences then (like failing to build if a package needs compilation) ? Is nixops the right tool for such a setup ?
<iqubic>
So I want to use steam-run to run the program "qxw", which I have a binary of in ~. But I also want to pass the '-d' flag to it. How do I do that?
<jtojnar>
Leira try passing --show-trace to nixos-rebuild to see what is using such an old dependency