<catern>
copumpkin: hey, did you see the idea I had above? I think it could be really useful for the monorepo case we were talking about!
<copumpkin>
gchristensen: make it say that nixpkgs-unstable updafted plzthx :)
<copumpkin>
catern: didn't sorry! on a train and nothing's working very well
alx741 has quit [(Quit: alx741)]
fikse has joined #nixos
indi_ has joined #nixos
alx741 has joined #nixos
anton__ has quit [(Ping timeout: 246 seconds)]
<gchristensen>
copumpkin: when I saw unstable I squealed with joy, then disappointmtent
erictapen has joined #nixos
<catern>
copumpkin: oh well it was just the idea of doing import-from-derivation, but doing it efficiently by having another small derivation in between which extracts out the default.nix. i.e.: source code derivation <- default.nix-generating derivation <- final built derivation
anton___ has joined #nixos
sheenobu has quit [(Quit: My Mac has gone to sleep. ZZZzzz…)]
lverns has joined #nixos
sheenobu has joined #nixos
<lverns>
where can one find documentation on what `lowPrio` does? I can't seem to find mention of it in the manual for nix, nixpkgs, or nixos.
<gchristensen>
lverns: basically it just sets meta.priority = -10 which makes nix treat it last whenever it is looking at a list of packages
<lverns>
gchristensen: got it. Thanks!
<gchristensen>
you're welcome!
erictapen has quit [(Ping timeout: 240 seconds)]
<copumpkin>
catern: hey sorry, that sounds good (I had similar ideas) but I'm on the train and nothing works so can't really have a good conversation about it. Main concern about that is that I can't extract nix import dependency information out programmatically
<catern>
ah
<catern>
fortunately for me, I can :)
<catern>
how can it be that you can't do it programmatically? doesn't your currently existing build system need to do this kind of stuff, programmatically?
Rotaerk has joined #nixos
Wizek_ has quit [(Ping timeout: 260 seconds)]
clever_ has joined #nixos
<copumpkin>
catern: if default.nix somewhere calls import foo.nix which calls import bar.nix which has a file reference to version.txt
<copumpkin>
I can't easily see that, yet all of those belong in the channel
<copumpkin>
I can copy default.nix but it doesn't give me the full picture
<copumpkin>
there's a feature I've been half-assedly working on in Nix to do this for ages
<catern>
copumpkin: oh! I see what you mean... if you have more than just the default.nix, you can't extract it programmatically
<copumpkin>
yeah
<catern>
and your feature would find the closure of files, i guess?
<catern>
sounds like a useful thing
zetok has quit [(Ping timeout: 260 seconds)]
<copumpkin>
I phrase it slightly differently there but it's a similar need
<copumpkin>
if this wifi ever loads I'll find you the PR
<scott>
anyone else use KDE5 and Spectacle (the screenshot tool)? after a semi-recent update (but i'm not sure when), the "print screen" key will no longer open Spectacle like it used to. the "Start Screenshot Tool" global shortcut is still bound to that key
zetok has joined #nixos
<scott>
Spectacle works fine if i launch it other ways
<scott>
the print screen key works fine if i bind it to a different action
<scott>
so it's the "Start Screenshot Tool" action that isn't firing properly but i don't know how to investigate
<clever>
copumpkin: i noticed a bug in bash when it was running the old RSP parser
<clever>
copumpkin: it was hammering the brk() syscall, increasing the heap by a few kb, then shrinking it asap, then increasing it again
<copumpkin>
lol
<clever_>
copumpkin: fixing that would have greatly increased the speed of that bash based parser, making it entirely userland, rather then context switching for every string concat
michas has quit [(Ping timeout: 268 seconds)]
<copumpkin>
minimal dependencies yo
<copumpkin>
probably nobody ever thought someone would try to write a parser in it
<copumpkin>
I think I'm going to write an SMT solver in bash next
<copumpkin>
sorry if my messages make no sense. My Matrix client is sending them whenever it can get this screwy wifi to speak to it
<clever_>
copumpkin: ehh, i had worse, i was ssh'd into screen+irssi yesterday, and there was 2 minute latency at times
ryanartecona has joined #nixos
<simpson>
copumpkin: Your Matrix client is really buggy; it sent a line that looked like "I'm going to write an SMT solver in bash"
<catern>
:)
<simpson>
That message made zero sense.
<clever_>
:D
<simpson>
I mean, I understand all the pieces, but it's like a Markov chain. You wouldn't, right?
<copumpkin>
throwing together a quantifier elimination for Presburger arithmetic as we speak. Turns out unquoted arguments can be quite handy in this context!
<simpson>
I don't want to watch, but I can't look away.
<copumpkin>
okay just kidding
<copumpkin>
I'm not actually going to write an SMT solver in bash
yegods has quit [(Remote host closed the connection)]
georges-duperon has quit [(Ping timeout: 260 seconds)]
<joepie91>
there, documentation duty for the evening completed :P
sheenobu has quit [(Quit: My Mac has gone to sleep. ZZZzzz…)]
darlan has joined #nixos
<gchristensen>
10s pere _link_?
<nh2>
gchristensen: such is the world of bash
<gchristensen>
how is this true
<joepie91>
Bash *is* hilariously slow
<nh2>
gchristensen: quadratic algorithms (in this case, -L and -l finding) multiplied by insanely slow constant factors
<joepie91>
basically every Bash optimization can be described as "use a special flag on a tool to sidestep a pipe"
<gchristensen>
nice
yegods has quit [(Ping timeout: 255 seconds)]
<joepie91>
see also: find | xargs rm
<gchristensen>
I mean, you use bash you get bash
astsmtl has quit [(Ping timeout: 248 seconds)]
<joepie91>
gchristensen: oh, you might have a passing interest in the small library I published today; https://www.npmjs.com/package/drv - in case you want to write some tooling that interacts with .drv files
sheenobu has joined #nixos
<copumpkin>
quick, submit to accidentallyquadratic
<gchristensen>
omg
<joepie91>
I think that approximately exhausts the set of people who might care about that library
<joepie91>
lol
<clever_>
joepie91: find also has -delete
<joepie91>
clever_: that was the 'bash optimization' I was refering to ;)
darlan has quit [(Client Quit)]
<joepie91>
hm, I think the documentation of that library is longer than the actual code in it...
<nh2>
copumpkin: well technically you'd have to submit gcc, or whatever unix compiler came up first with the idea of searching around instead of passing the files you already know about
<nh2>
I like the extremist flair of nixpks, "well we offer you 2 scripting languages, one makes it impossible to get anything right, and the other one is C++"
<nh2>
I propose to add Agda to stdenv to make the trinity complete
<nh2>
clever yes, that's where I got the topic from (I linked it from the GHC issue; fount the problem first in ghc and then asked here because I imagine nix people know that problem, and indeed sphalerite[m] pulled this up)
<clever>
ahh
lambdamu has quit [(Ping timeout: 255 seconds)]
<nh2>
somehow life has taken me the wrong path, I once was a happy child and now I think about linking regularly
<copumpkin>
I'll take Agda over the other two
<clever>
nh2: i once had to deal with ld needing over 3gig of ram to link firefox, and i was on a 32bit machine
<joepie91>
well... this is bizarre
<joepie91>
[pid 11578] execve("~/.cargo/bin/xargo", ["xargo", "build", "--target", "x86_64-testing_os"], [/* 97 vars */]) = -1 ENOENT (No such file or directory)
<joepie91>
but... that path exists?
<joepie91>
-rwxr-xr-x 1 sven users 1187720 Jul 26 02:22 /home/sven/.cargo/bin/xargo
<clever>
joepie91: what about the ld.so path?
<joepie91>
(it's executed from within `make`)
<joepie91>
clever: not sure how to interpret that question
<joepie91>
also, the executable works fine when run directly from shell
<clever>
oh, i see the problem
<clever>
~ doesnt expand in syscalls
<clever>
thats handled by bash
<joepie91>
... aha.
<joepie91>
moment.
ebzzry has quit [(Ping timeout: 246 seconds)]
<joepie91>
yep
<joepie91>
got rid of the ~, now it works
<joepie91>
thanks, clever :)
ryanartecona has quit [(Ping timeout: 248 seconds)]
ebzzry has joined #nixos
<joepie91>
slowly piecing together a working buildchain...
<NixOS_GitHub>
nixpkgs/master 3ffcbdd Graham Christensen: Merge branch 'master' into patch-3
<NixOS_GitHub>
nixpkgs/master de8b6dd Graham Christensen: Merge pull request #23750 from butterflya/patch-3...
NixOS_GitHub has left #nixos []
alpha_sh_ has joined #nixos
HappyEnte has quit [(Ping timeout: 260 seconds)]
alpha_sh has quit [(Ping timeout: 260 seconds)]
joshie has quit [(Quit: No Ping reply in 180 seconds.)]
Sigma has quit [(Ping timeout: 260 seconds)]
catch22__ has quit [(Ping timeout: 260 seconds)]
wak-work has quit [(Ping timeout: 260 seconds)]
Sigma[Mtp] has joined #nixos
HappyEnte has joined #nixos
mudri|srcf has quit [(Remote host closed the connection)]
aszlig has quit [(Remote host closed the connection)]
mudri|srcf has joined #nixos
aszlig has joined #nixos
danyc0 has quit [(Remote host closed the connection)]
Sigma[Mtp] is now known as Sigma
danyc0 has joined #nixos
ninja_in_neopren has quit [(Ping timeout: 260 seconds)]
zeus_ has quit [(Remote host closed the connection)]
wak-work has joined #nixos
<gchristensen>
here is an idea copumpkin clever_ whoever else is here :P
nil has quit [(Ping timeout: 240 seconds)]
zeus_ has joined #nixos
<gchristensen>
a "project" of "approved mass rebuilds"
nil has joined #nixos
Bane^ has quit [(Ping timeout: 260 seconds)]
oahong has quit [(Ping timeout: 260 seconds)]
<gchristensen>
assign issues to the project and if someone is "in the mood" they merge a bunch of them all at once
pbogdan has quit [(Ping timeout: 240 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] grahamc closed pull request #18731: nixos-generate-config: update default to use grub for UEFI as well (master...grub-uefi) https://git.io/viXH7
NixOS_GitHub has left #nixos []
Bane^ has joined #nixos
oahong has joined #nixos
zeus_ has quit [(Ping timeout: 276 seconds)]
pbogdan has joined #nixos
<joehh>
clever_: so hasn't quite solved it
<joehh>
building HUnit failed due to error messages changing with a profiled build
<joehh>
so added dontCheck, but that seems to give a similar error to before
<clever>
joehh: oh right, i typed an example before on how to solve that, one min
* dash
going somewhat crazy trying to tame a pile of cmake-using dependencies for use with nix...
<dash>
it would help if i'd ever used cmake before this project i guess
yegods has joined #nixos
sigmundv_ has quit [(Ping timeout: 276 seconds)]
yegods has quit [(Ping timeout: 240 seconds)]
zeus_ has quit [(Remote host closed the connection)]
zeus_ has joined #nixos
<dtzWill>
lol ya
<dtzWill>
gchristensen: or maybe they're auto-merged (after explicit approval) when Hydra is less-swamped-than-usual :)
zeus_ has quit [(Ping timeout: 246 seconds)]
<dtzWill>
shame 0xABAB didn't work out, had some good contributions
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] cstrahan pushed 1 new commit to master: https://git.io/v7ORL
<NixOS_GitHub>
nixpkgs/master cadb42f Charles Strahan: honcho: 0.6.6 -> 1.0.1
NixOS_GitHub has left #nixos []
<dtzWill>
(bummer wasn't problematic AND useless lol; anyway...)
<hyper_ch>
hmmm, nixos-unstable-small built again.... so I guess nixos-unstable will soon as well?
justan0theruser has joined #nixos
justanotheruser has quit [(Ping timeout: 258 seconds)]
justan0theruser has quit [(Client Quit)]
justanotheruser has joined #nixos
Myrl-saki has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] elitak opened pull request #27651: go: support for aarch64 via binary bootstrap (master...go-aarch64) https://git.io/v7O0o
NixOS_GitHub has left #nixos []
bennofs has joined #nixos
schoppenhauer has quit [(Ping timeout: 255 seconds)]
justelex_ has joined #nixos
ryanartecona has quit [(Quit: ryanartecona)]
schoppenhauer has joined #nixos
bennofs has quit [(Ping timeout: 255 seconds)]
beth has joined #nixos
beth is now known as Guest44122
Guest44122 is now known as bethAr
Myrl-saki has quit [(Ping timeout: 240 seconds)]
<bethAr>
Is anyone available? I need some help with Nix.
<simpson>
bethAr: Don't ask to ask, just ask.
<bethAr>
Sorry.
<bethAr>
I'm very new to Nix.
<bethAr>
I'm trying to install hsdev.
<bethAr>
It needs to be installed globally, so it is picked up by my editor.
<bethAr>
Every time it fails because of dependencies.
<bethAr>
Even though I installed the dependencies.
<bethAr>
Here is GHC's output: ... Configuring hsdev-0.2.5.0... Setup: Encountered missing dependencies: hformat ==0.3.*, simple-log ==0.9.*, text-region ==0.3.* builder for ‘/nix/store/z4lp62qncpk68kc6ifhmwd3y3l2gychd-hsdev-0.2.5.0.drv’ failed with exit code 1 error: build of ‘/nix/store/z4lp62qncpk68kc6ifhmwd3y3l2gychd-hsdev-0.2.5.0.drv’ failed /home/beth/.nix-profile/bin/nix-shell: failed to build all dependencies
<bethAr>
This is by trying to open a nix-shell with: nix-shell -p haskellPackages.hformat_0_3_0_0 -p haskellPackages.text-region_0_3_0_0 -p haskellPackages.simple-log_0_9_2 -p haskellPackages.hsdev_0_2_5
<bethAr>
Typo at the end, it should be: haskellPackages.hsdev
<simpson>
Yep, doesn't build here either, running $(nix-shell -p haskellPackages.hsdev).
<bethAr>
I was able to build it with Stack, though. Does nix ignore hformat, because it is not the default one?
deep-book-gk_ has joined #nixos
deep-book-gk_ has left #nixos []
<simpson>
No idea; I thought that versioning in haskellPackages was automatically derived from Stackage.
<bethAr>
It is odd. If I ask to install hformat, one of the depencies, without qualifying the version, it installs version 0.1.0.1, even though there is a new version available.
<bethAr>
I thought the 'default' package was always the last one.
Fare has joined #nixos
frankpf has quit [(Ping timeout: 255 seconds)]
wkennington has joined #nixos
<revoltmedia[m]>
I'm trying to get rails installed. I installed the ruby_2_2 package, and ran gem install gem install rails -v 5.1.2 got an error: zlib is missing; necessary for building libxml2 but both libxml2 and zlib are installed...
justelex_ has quit [(Ping timeout: 240 seconds)]
tvon has quit [(Quit: System is sleeping...)]
reinzelmann has joined #nixos
<bethAr>
Ok, I've posted a github issue on my problem, thanks simpson.
<adisbladis[m]>
How come allowUnfree does not apply to a package installed like this: (import "/etc/nixos/nixpkgs-mozilla/" {}).firefox-nightly-bin
<aristid>
globin: what fixed the unreliable tests? i tried to bisect the issue but got a whole list of possible offending commits
endformationage has quit [(Quit: WeeChat 1.7)]
MP2E has joined #nixos
justanotheruser has quit [(Ping timeout: 255 seconds)]
<sphalerite[m]>
adisbladis: my guess is because of the {} in there. The imported nixpkgs gets its own set of options. I'm not sure though
simendsjo has joined #nixos
ebzzry has quit [(Ping timeout: 255 seconds)]
reinzelmann has joined #nixos
<Mic92>
grahamc: yes?
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] cstrahan pushed 1 new commit to master: https://git.io/v7OrV
<NixOS_GitHub>
nixpkgs/master 4244a16 Charles Strahan: gocode: update to f1eef9a6, fix stdlib completions
NixOS_GitHub has left #nixos []
jgertm has joined #nixos
zeus_ has quit [(Remote host closed the connection)]
zeus_ has joined #nixos
frankpf has quit [(Ping timeout: 255 seconds)]
<ij>
Is the value of "pkgs.docekerTools.buildImage { … }" a string/path to the resulting docker image?
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] fpletz pushed 1 new commit to master: https://git.io/v7Oo4
<NixOS_GitHub>
nixpkgs/master 10c6df2 edef: nixos/…/swap.nix: don't create a LUKS header for randomEncryption...
NixOS_GitHub has left #nixos []
zeus_ has quit [(Ping timeout: 276 seconds)]
<srhb>
Humm. Shouldn't the bump happen now? The tests look good.
slack1256 has joined #nixos
<sphalerite[m]>
So I've installed nix with multi-user on a debian chroot, and it seems to be working mostly fine but when I try to use nix-env as a non-root user, it still tries to install stuff to the default profile. What's up with that?
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] fpletz pushed 1 new commit to master: https://git.io/v7Oop
<NixOS_GitHub>
nixpkgs/master a3e6df6 k0ral: environment.noXlibs: Disable gnome when noXLibs is set (#27567)
NixOS_GitHub has left #nixos []
<fpletz>
aristid: manual restarts :/
<adisbladis[m]>
Hmm.. Is there a simple way to do allowUnfree per package?
<srhb>
adisbladis[m]: Modifying the license? :-P
<adisbladis[m]>
srhb: I did think about doing overrides but it feels so wrong :P
taktoa has quit [(Remote host closed the connection)]
xadi has joined #nixos
<slack1256>
I phrases the question wrongly
indi__ has quit [(Remote host closed the connection)]
indi_ has joined #nixos
<slack1256>
looking at .nix_defexpr/channel_root/nixos/svn_revision tells me the commit at which nixpkgs was when setting up this channel
c74d has quit [(Ping timeout: 268 seconds)]
takle has joined #nixos
indi_ has quit [(Ping timeout: 255 seconds)]
Ivanych has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] peti pushed 13 new commits to master: https://git.io/v7O1g
<NixOS_GitHub>
nixpkgs/master e69c7f5 Peter Simons: haskell-generic-builder: include setupHaskellDepends in the generated "env" attribute...
<NixOS_GitHub>
nixpkgs/master 27ca0cb Peter Simons: haskell-generic-builder: fix syntax high-lightning in Emacs
<NixOS_GitHub>
nixpkgs/master efa3ba8 Peter Simons: haskell-diagrams-solve: disable failing test suite to fix the build
NixOS_GitHub has left #nixos []
miefda has quit [(Ping timeout: 268 seconds)]
vandenoever has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] peti pushed 1 new commit to release-17.03: https://git.io/v7O1r
<NixOS_GitHub>
nixpkgs/release-17.03 f828a86 Domen Kožar: ghc: apply a patch to fix common gold linker problem...
NixOS_GitHub has left #nixos []
<seequ>
When I use `settings.xserver.videoDrivers = [ 'nvidia' ]`, what's the name of the resulting kernel module? `LoadModule 'nvidia'` fails with 'module not found'.
thc202 has joined #nixos
<goibhniu>
seequ: the nvidia module should be loaded ... did you reboot?
<seequ>
That's when the problem shows up. X fails to start as it can't find it.
<slack1256>
isn't it nouveau the nvidia driver on linux?
<slack1256>
I mean the OSS (I haven't checked on years)
<goibhniu>
seequ: it should be: services.xserver.videoDrivers
<seequ>
goibhniu: It is, sorry.
<goibhniu>
that's indeed another option slack1256
mounty has quit [(Ping timeout: 240 seconds)]
<seequ>
nvidia-settings finds the driver when I haven't set `services.xserver.config`
<seequ>
I used it to make said config, which then fails.
<goibhniu>
ah, you shouldn't need to do that manually
<goibhniu>
maybe it's the bumblebee issue (I'm not sure what the status is on that, perhaps it's fixed)
mounty has joined #nixos
<seequ>
Is there some other way to config monitor positions and forcing full composition?
peacememories has quit [(Quit: My MacBook has gone to sleep. ZZZzzz…)]
wrl_ has joined #nixos
Olgierd has joined #nixos
nschoe has quit [(Ping timeout: 240 seconds)]
amir has quit [(Ping timeout: 240 seconds)]
wak-work has quit [(Ping timeout: 276 seconds)]
dhess has quit [(Ping timeout: 276 seconds)]
SuprDewd has quit [(Quit: No Ping reply in 180 seconds.)]
alx741 has quit [(Ping timeout: 276 seconds)]
Acou_Bass has quit [(Ping timeout: 276 seconds)]
rjsalts has quit [(Ping timeout: 276 seconds)]
ncl28_ has joined #nixos
Nazral has quit [(Ping timeout: 240 seconds)]
ncl28 has quit [(Ping timeout: 240 seconds)]
erictapen has quit [(Ping timeout: 240 seconds)]
lewo has quit [(Ping timeout: 276 seconds)]
wrl has quit [(Read error: Connection reset by peer)]
qewzee has quit [(Ping timeout: 240 seconds)]
ThatDocsLady_mtg is now known as ThatDocsLady
nschoe has joined #nixos
wak-work_ has joined #nixos
amir has joined #nixos
Olgierd has quit [(Changing host)]
Olgierd has joined #nixos
<seequ>
Can I define files that new home directories should have?
bjarki has joined #nixos
indi_ has joined #nixos
boegel has quit [(Ping timeout: 276 seconds)]
<ocharles>
Has anyone used overlays successfully with nixops? I have `machine = { pkgs, .. }: { nixpkgs.config.overlays = [ ./foo.nix ]; ... }`, yet I get a complaint that an attribute doesn't exist (it's looking up a custom package in `pkgs`).
<ocharles>
If I override nixpkgs.config.packageOverrides, then it works
indi_ has quit [(Remote host closed the connection)]
qewzee has joined #nixos
indi_ has joined #nixos
alx741 has joined #nixos
zraexy has quit [(Ping timeout: 248 seconds)]
Bane^ has quit [(Ping timeout: 260 seconds)]
lambdael has joined #nixos
Acou_Bass has joined #nixos
Fuuzetsu has quit [(Ping timeout: 240 seconds)]
rjsalts has joined #nixos
indi_ has quit [(Remote host closed the connection)]
boegel has joined #nixos
Bane^ has joined #nixos
indi_ has joined #nixos
<ocharles>
It looks to me like it's not actually evaluating those overlays, because I can also put nixpkgs.config.overlays = true, which isn't type-correct
Fuuzetsu has joined #nixos
lewo has joined #nixos
<ocharles>
Doh. nixpkgs.overlays, not nixpkgs.config.overlays
Nazral has joined #nixos
Kallegro[m] has quit [(Ping timeout: 276 seconds)]
junaidali has quit [(Read error: Connection reset by peer)]
Kallegro[m] has joined #nixos
indi_ has quit [(Remote host closed the connection)]
indi_ has joined #nixos
indi_ has quit [(Remote host closed the connection)]
junaidali has joined #nixos
MoreTea has joined #nixos
athan has quit [(Ping timeout: 255 seconds)]
revtintin has joined #nixos
<mpickering>
Is it possible to create more fine grained packaging for projects which take a long time to compile? For example, a derivation per module for Haskell projects
Neo-- has joined #nixos
<mpickering>
Is there any prior art to doing this
bennofs has joined #nixos
<ocharles>
certainly been discussed. mpickering, my approach is to tar up `dist` and upload it to S3 (impurely)
<ocharles>
I download a tar before building, and untar it if it exists, then I tar up the result if the build is sucessful
<ocharles>
poor mans caching
<mpickering>
hmm
MoreTea has quit [(Remote host closed the connection)]
<ocharles>
it works pretty well
<mpickering>
I'm building ghc (ofc) and it is painful to not cache any of the build when it fails at a late stage
<ocharles>
but yes, actually re-implementing ghc --make would go a lot further, but is a lot more work
<ocharles>
you could upload the cache on failure too, of course
<ocharles>
or expect it in a magic local location
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] edolstra pushed 1 new commit to staging: https://git.io/v7ONC
<niksnut>
it still fails on: Jul 26 09:55:36 webserver update-nixos-unstable-start[15462]: error: path ‘/nix/store/042yklr7p47rqcq56yr5s6qh0xslhlbp-llvm-4.0.1-man’ is not valid
<niksnut>
hm, I though that llvm.man issue got fixed?
<niksnut>
+t
<fpletz>
llvm.man builds fine for me on master
<fpletz>
I'll trigger another trunk-combined eval
alfie has quit [(Max SendQ exceeded)]
alfie has joined #nixos
FRidh has quit [(Ping timeout: 276 seconds)]
FRidh has joined #nixos
<globin>
niksnut: is it really running from the currently last successful eval, not that something got stuck that time the channel went back to the past?
simukis has joined #nixos
peacememories has joined #nixos
freusque has quit [(Quit: WeeChat 1.9)]
michaelpj has joined #nixos
<fpletz>
evaluation fails with: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
joehh has quit [(Read error: Connection reset by peer)]
slack1256 has quit [(Ping timeout: 255 seconds)]
yegods has joined #nixos
erictapen has joined #nixos
<LnL>
niksnut: that's still causing problems? :(
erictapen has quit [(Remote host closed the connection)]
<gchristensen>
you're welcome --usually you _can_ just nix-env -iA install stuff :)
<yegortimoshenko>
oh well, it doesn't have an ethernet port or wi-fi support... is there an easy way to list all stuff i should fetch on another machine? i can then import it via nix-prefetch-url i imagine
<yegortimoshenko>
(it's a macbook air)
<goibhniu>
yegortimoshenko: if you happen to have an android phone, you can use that for wifi
<clever_>
without the nixpkgs=, it will search for nixpkgs inside of that directory
<clever_>
rather then using that dir as nixpkgs
<pie_>
ah i did do it right, turns out i messed up another part of he command >_<
<pie_>
ok it worked, thanks
<pie_>
some things are just hard to build /tmp/arc_unpacker/src/algo/crypt/hmac.cc:39:34: error: ‘HMAC_CTX_new’ was not declared in this scope \n HMAC_CTX *ctx = HMAC_CTX_new();
<clever_>
sounds like openssl
<deltasquared>
inb4 different header versions or something
<pie_>
random place that seems to mention a similar issue. so now i need to figure out what version it wants
<deltasquared>
yep.
<deltasquared>
pie_: try openssl-1.0.x
<pie_>
oh ok the file that explains how to build it is named BUILD.md >.>
<pie_>
kinda missed that..
<pie_>
7. `openssl` 1.1.0+
<deltasquared>
x being whatever. archlinux had the same issues, some packages still stuck on the now-separate openssl-1.0
* pie_
scratches head
ThatDocsLady_lun is now known as ThatDocsLady
<deltasquared>
it looks like one of those cases where they couldn't maintain separate versions of their code for the diff APIs because they didn't isolate their own code well enough
<pie_>
oh i have openssl-1.0.2
<pie_>
that explains it
<deltasquared>
I'm just imagining my software engineering lecturer going apeshit right now
<deltasquared>
...
<deltasquared>
damnit.
* deltasquared
puts a coin into the swear box
<gchristensen>
<3 deltasquared
<deltasquared>
I'M SORRY
<gchristensen>
it is okay :P
<pie_>
oh openssl --> 1.0.2 openssl_1_1_0 is the package i need
<deltasquared>
I'm waaaay too liberal with my swearing
<deltasquared>
I'm just glad I wasn't brought up to be casually racist or something worse
<pie_>
yay nixos \o/
<deltasquared>
still though, in any "well built" version of this the code to change this wouldn't have been that large.
<deltasquared>
I'm just wondering how many calls to the openssl API are sprinkled in that code... dare I go look
Geraldus has quit [(Ping timeout: 260 seconds)]
* deltasquared
goes and looks at code
Geraldus has joined #nixos
<deltasquared>
I take it back, it does look like it's in a class already.
magnetophon has joined #nixos
<deltasquared>
considering it's crypto level code, I wouldn't even begin to pretend I could understand all the possible subtle implications of attempting to fix it
<deltasquared>
iow don't f- err, don't touch it
georges-duperon has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to master: https://git.io/v738u
<pie_>
well looks like i can build it without webp support, i might not need it righ tnow
<gchristensen>
clever_: may I PM?
<clever_>
gchristensen: sure
joehh has joined #nixos
<gchristensen>
actually, can you PM me first? :)
takle has joined #nixos
Ivanych has quit [(Ping timeout: 268 seconds)]
indi_ has quit [(Remote host closed the connection)]
drakonis has joined #nixos
<domenkozar>
peti: clever_: should we discuss multiple outputs PR?
<clever_>
i made a push yesterday, let me see if peti left a comment
<domenkozar>
I left one, I think there's some confusion around
reinhardt has quit [(Quit: Leaving)]
<peti>
clever_: I just messaged a lot of stuff to an IRC person called "clever" which, I reckon, is not you?
<clever_>
thats the desktop at my house, let me ssh to it
<clever_>
currently on the road
<dbe>
so I have a thought, maybe others have had is, but I can't find anything on it. When someone updates a package, let's say, libssl, then, since all other packages depend on the name "libssl"... any one of those packages might now fail to build. Why not use use versions in the names as well? Put the exact dependency "libssl-1.2.3-r4"?
<clever>
*waves*
<bennofs>
dbe: too hard to maintain. then you'd have to update every transitive dep as well when there are security patches etc
<dbe>
hrm... is it? you could grep and replace? and then make sure they all build?
<clever_>
nixpkgs is currently in the area where you only keep a minimal number of versions (major api changes)
<clever_>
and then each one of those will update to the latest within that api
Geraldus has quit [(Quit: Be back later ...)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to master: https://git.io/v73B0
<bennofs>
dbe: well, how's that different from that status quo? if a package fails to build, we can still have the older version (sometimes this is done in nixpkgs. but generally, we try to avoid it)
Geraldus has joined #nixos
Geraldus has quit [(Client Quit)]
<dbe>
Hmm ok. For me personally, every time I set up nix, which is about 5 times now, I get at least one package that fails to build... it's annoying
<bennofs>
dbe: but why would that not happen if we used grep & replace?
miefda has joined #nixos
Rotaerk has quit [(Quit: Leaving)]
<dbe>
I guess that, first, the change is explicit. You know you might be breaking the package when you change it. The other way, you're just updating a package... you don't know what depends on it
<dbe>
Second, it doesn't happen "all the time"... you're just doing the change if you "need to"
<clever_>
nox has a review-pr thing that tests it
<clever_>
travis runs that automatically when you open a PR
<dbe>
clever_: what
<clever_>
and in future, hydra can test everything, and just tell you what you broke
<bennofs>
dbe: hydra builds most packages and sends emails to maintainers if they fail
<dbe>
clever_: then how am I getting so many broken packages? :(
<joehh>
morning clever_ :)
<clever_>
travis has a lot of false negatives, so people ignore it
<bennofs>
dbe: a) nobody knows how to fix it b) nobody uses the package, thus nobody cares c) it is know how to fix it, but relies on some larger work that is not ready yet ?
<joehh>
evening here - still haven't got my profiling builds going :) learning lots though :)
<dbe>
oh wait, I recall that previously, I actually did manage to build some package, but it didn't run. I guess that's harder to check...
<bennofs>
keeping an old version of a library just so that one package works may be too much work (you'll now have to maintain the old version, ensure it builds as well, check it for security updates, ...)
<dbe>
ok, but the issue here is that there are too many packages...
<clever_>
hydra can check them in future
<clever_>
it is capable of building everything, for every PR
<dbe>
bennofs: hmm, but would it ever be able to fail to build, if you managed to build it once?
<bennofs>
dbe: well, you'd have to keep all transitive dependencies fixed
<dbe>
bennofs: right, yeah
Ivanych has joined #nixos
<bennofs>
dbe: which can potentially be huge amounts of work. say, you need to keep older gcc around so that an older version of a library builds so that prog foo still builds
<bennofs>
or you need to patch the older version of the lib to work with newer gcc
<dbe>
bennofs: seems OK in my head. maybe I'm not getting the scope of the problem
<bennofs>
dbe: it makes changing things harder. if you change how stdenv works, you now also have to update all these "old" versions.
<bennofs>
dbe: also, you cannot mix & match libraries compiled with different versions of gcc for example
<bennofs>
not always, at least
<bennofs>
(gcc has some ABI compat guarrantee afaik but idk what it is exactly)
<bennofs>
dbe: at this point, you can already do what you want: just note down the hash of nixpkgs when your package built successfully, and then only ever install it from that nixpkgs hash
<dbe>
bennofs: I didn't about the gcc thing, that's... interesting.
<dbe>
bennofs: hmm, yeah, that's true
<dbe>
is the gcc issue solved the way it's done today? is the builder, gcc, really a dependency of the packages, so as to be rebuilt?
<deltasquared>
dbe: different gcc flags cause different build outputs
<deltasquared>
I was going on about this myself recently.
<deltasquared>
different ABI defaults for instance causes breakages.
<dbe>
deltasquared: I thought it was, you know... an ELF file. with symbols to functions. and then that's it. If you can find the symbol, then you're basically OK.
<dbe>
of course the program might do different things, but that's hard to guarantee
<deltasquared>
dbe: the symbol matching is no guarantee the calling convention is the same
<deltasquared>
one mismatch in compiler flags and boom
<dbe>
hmm ok!
<deltasquared>
the only really safe call is to include the compiler and it's deps into the tree as well, currently that's the best we have
<deltasquared>
which kinda sucks cause it means you can't really cross compile.
<deltasquared>
well, you *can*, but you wouldn't be able to re-use cached builds for the native compiler
<deltasquared>
at which point in build times at least you're reduced to gentoo. :P
<dbe>
so the compiler is in the deps, even though most packages don't excplicitly specify it? I guess it's a dependency within stdenv then, which is why it works
<deltasquared>
I can't answer that, I haven't looked closely at nix build files yet
Sonarpulse has quit [(Ping timeout: 276 seconds)]
<dbe>
all right. well that's cool.
<clever_>
the calling convention sets things like where arguments go (in certain registers, on the stack?)
<clever_>
and also who cleans the stack up, the caller or callee
<clever_>
there is also symbol mangling, the c++ names (namespace, types, return value) get flattened down to a c level symbol name
<dbe>
I thought that was all in some standard related to the ELF format
<clever_>
so overloaded functions have different symbols
<spacefrogg>
dbe: The compiler is part of the build dependencies, but normally not of the runtime dependencies.
<dbe>
clever_: right, yes, that i've seen. But that's a layer "above" elf though.
<clever_>
the calling convention is based on the cpu mainly
<clever_>
64bit x86 has more registers, so its faster/cheaper to pass more arguments in registers
<dbe>
clever_: oh yeah, that's true...
<dbe>
well I guess I'm happy with this answer. You don't version packages because a. you have versioning of the entire nixpkgs already, b. too hard to update security, and c. differing gcc versions
<dbe>
I'm not entirely convinced that nixpkgs should care about b. Though I guess nixOS should though.
<domenkozar>
clever_: peti: have you agreed on what's the plan? :)
<domenkozar>
I'd like to hear it just to double check
<gchristensen>
dbe: nixpkgs absolutely should
<gchristensen>
whether something is running from system packages or its own packages, it is important to keep them up to date
ng0 has joined #nixos
<gchristensen>
but an even more important part is if we had many packages we'd have a maintenance nightmare
<peti>
domenkozar: We are working on it. :-)
<domenkozar>
peti: thanks :)
<spacefrogg>
dbe: With nixpkgs overlays it is too easy to maintain 'local' versions of packages to load the burden onto the general nixpkgs tree.
<domenkozar>
!m peti
<[0__0]>
You're doing good work, peti!
<domenkozar>
!m clever_
<[0__0]>
You're doing good work, clever_!
<dbe>
I didn't mean it like that. I meant like... nixos is a distribution, and it yeah, of course it should be safe.
<dbe>
And I mean, yeah, your points are very valid.
<dbe>
I guess you can't really separate the two anyway, so I'm really just rambling.
<dbe>
I'm thinking of nix as two distinct things, one as a very elaborate build system, and one as full blown package manager and repo for a distribution
<dbe>
As a very elaborate build system, you don't care so much about security, you care more about reproducability... if you get what I'm rambling about
erasmas has joined #nixos
JagaJaga has quit [(Ping timeout: 255 seconds)]
Ivanych has quit [(Ping timeout: 248 seconds)]
<spacefrogg>
dbe: But still you don't collect arbitrary stuff in a repo most of which doesn't build properly.
<hyper_ch>
ha, nixos-unstable got updated :)
<joepie91>
hyper_ch: itshappening.gif
<joepie91>
:P
<copumpkin>
niksnut, ikwildrpepper: more mac builds have been running for 15+ hours now
<copumpkin>
O
<copumpkin>
I'm assuming they're stuck again like last time?
Ivanych has joined #nixos
<copumpkin>
they also happen to be the last builds remaining in that evaluation holding it up
<dbe>
spacefrogg: right. :P that's what I'm thinking about how to achieve. The problem is that I'm getting too many failed builds.
yegods has joined #nixos
<clever>
copumpkin: i have noticed a lot of arm builds, and even a few x86 builds hanging within make, make had a zombie process as a child, and wasnt calling waitpid
<dbe>
spacefrogg: but it's a theoretical question. hypothetical. Just curious.
<spacefrogg>
dbe: I guess you would need proper descriptive powers on the packages side to describe your needs from a compiler/build-/runtime-environment. So you could track/auto-fix most of the cases.
<gchristensen>
niksnut: do you have a day or time that you're available to merge the HSTS pr?
xadi has joined #nixos
<dash>
dbe: there's a ton of elaborate build systems
<dash>
dbe: what makes nix unique is purity
<domenkozar>
!m fpletz
<[0__0]>
You're doing good work, fpletz!
<domenkozar>
!m globin
<[0__0]>
You're doing good work, globin!
<dash>
dbe: also, I don't think there's a context where it makes sense to _not_ care about security :)
<dbe>
dash: yes! that's what makes it great!
<dbe>
dash: ooh but I do!
yegods has quit [(Ping timeout: 248 seconds)]
rigelk has joined #nixos
<dbe>
spacefrogg: hmm, that's... actually probably very correct.
<dbe>
spacefrogg: which feels both like the correct way to do it and simultaneously impossible because of how much packages differ
erictapen has quit [(Ping timeout: 276 seconds)]
<spacefrogg>
dbe: Exactly my thoughts...
nh2 has quit [(Ping timeout: 276 seconds)]
<spacefrogg>
dbe: But of course, if you can gain a clear advantage by doing this for a subset of packages, others may follow.
ng0 has quit [(Quit: Alexa, when is the end of world?)]
<copumpkin>
so... let's say I want to get the meta tag of each of the dependencies of a given derivation (i.e., the stuff that would show up in the runtime closure). It feels weird hopping from store back to nix to ask for meta, but is there a sensible way to do that? Imagine for example that I want to enumerate all licenses in use
roblabla has joined #nixos
ryanartecona has joined #nixos
<dbe>
copumpkin: could potentially write a nix expression to do it.. builtins.map and builtins.typeOf
ebzzry has quit [(Ping timeout: 276 seconds)]
<copumpkin>
dbe: but a lot of things are hidden in closures
<dbe>
copumpkin: oh.
21WAAKAYW has joined #nixos
<21WAAKAYW>
[nixpkgs] peterhoeg pushed 2 new commits to master: https://git.io/v73wy
<sphalerite[m]>
Is there a small DoS vulnerability in that a malicious user could create a directory in per-user that conflicts with another user before that user has ever logged in?
<sphalerite[m]>
Thereby preventing the new user's profile dir from being created
<clever>
looks like it
<clever>
i could also give that user write to his "own" directory, and pre-install malware into his profile
<dash>
user accounts were a mistake :(
<gchristensen>
IIRC the profile startup script gets very unhappy if that happens sphalerite[m]
nh2 has joined #nixos
<copumpkin>
ikwildrpepper: any idea about the hung mac builds? they're holding up the channel update, which means that the thousands of new Nix users on macOS and a few linuxes are installing a broken nix
ebzzry has joined #nixos
<ikwildrpepper>
copumpkin: no, can't do much more than kill some ssh process to let them retry, until niksnuts figures out what is wrong
<copumpkin>
is that something I can do from the Hydra UI so I don't have to bug y'all when I see it?
<clever>
copumpkin: there is no way to stop an in-progress build
<ikwildrpepper>
no, niksnut said I could kill the ssh processes from hydra backend
<clever>
copumpkin: the abort button just hides it, and stops any further proccessing
<clever_>
killing the ssh will probably lead to an unexpected eof, and then it will try the build again
LexLeoGryfon has joined #nixos
<LnL>
copumpkin: ikwildrpepper: what version of nix do the mac builders use now?
aoweirgherg has joined #nixos
fikse has joined #nixos
goibhniu has joined #nixos
ebzzry has quit [(Ping timeout: 255 seconds)]
LexLeoGryfon is now known as justlex
erictapen has joined #nixos
erictapen has quit [(Remote host closed the connection)]
<magnicida>
i have a "shell.nix" expression that works ok when I do nix-shell on my machine but is erroring on travis, at the very end (when it has already built all packages):
<magnicida>
/nix/store/1manigbaw9s3891iwdmc52vq1r25809y-stdenv/setup: line 32: local: -n: invalid option
erictapen has joined #nixos
erictapen has quit [(Remote host closed the connection)]
erictapen has joined #nixos
<goibhniu>
I've just upgraded nixos-unstable, but plasma has no window decorations ... does that sound familiar to anyone? ... Perhaps I need to nuke some local plasma config file?
<copumpkin>
LnL: not a clue :)
<ikwildrpepper>
copumpkin: I kicked some ssh processes
ThatDocsLady has quit [(Ping timeout: 255 seconds)]
<copumpkin>
yay, no more multi-hour builds except for a GHC one which is suppsoed to take that long
<justlex>
I like static binaries!!1 anyone else here too?
ebzzry has joined #nixos
<ikwildrpepper>
copumpkin: I can probably script it for now based on some arbitrary limit
<copumpkin>
ikwildrpepper: that'd be great. Pretty sure if anything takes 8 hours something's wrong :)
<NickHu>
Is anyone around who is familiar with the haskell nix infrastructure?
<copumpkin>
Nick Hu: that's usually peti but I don't know if he's around
<NickHu>
I'd quite like to get my pr looked at to see if I'm doing things correctly
<avn>
copumpkin: Just curious, if ghc documentation can be moved to own derivation
<spacefrogg>
justlex: I like static dependencies better.
* justlex
don't wan't dependencies
* justlex
want self contained packagesbinaries without dependecy hell
<dash>
justlex: nix gives all the advantages of static linking already, though
<spacefrogg>
That doesn't exist. You just push the problem to build-time. Nix gets close to your goal, though.
<clever>
avn: i have a PR being tested, that will add split outputs to all haskellPackages
<spacefrogg>
Which is actually what makes nix and nixos so confusing to newcomers. As your dependencies are already resolved at build-time you see confusingly little of them during runtime.
<avn>
clever: I am about breaking build dependency from ghc on python + sphinx
<dash>
OK any of y'all know stuff about cmake? I am trying to package a cmake-using project and the generated Makefile mysteriously has no 'install' target in it
<dash>
what did i do wrong
<justlex>
dash: I spot a package with broken(undefined) dependency, in our Nix, Sir. that made me cringe
<dash>
justlex: time to submit a patch :D
<et4te>
with a stack dependency getting 'Jobset contains a job with an empty name.' on hydra build, even though theres a name in the default.nix
<justlex>
and I'm not the man who want to rewrite correct package-build-script in oreder to fix it, for each distro particularly. I feel like better build once static and ship it EVERYWHERE. nix is so 'good' that it can't even handle my python virtual env out of the box.
<dash>
justlex: eh, sure it can, so long as you never gc
<dash>
justlex: but pypi2nix can help you out more
earldouglas has quit [(Quit: leaving)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 2 new commits to openssl-1.1: https://git.io/v73iH
<NixOS_GitHub>
nixpkgs/openssl-1.1 faa9fbd Robin Gloster: qt4: add patch to build with openssl 1.1
<NixOS_GitHub>
nixpkgs/openssl-1.1 f8cdf31 Robin Gloster: postgresql: fix merge
NixOS_GitHub has left #nixos []
<justlex>
oh thank you, didn't even knew such tool even exist
<copumpkin>
ikwildrpepper: omg omg omg only two jobs queued
<dash>
justlex: generates a .nix file for you, so you can use nix-shell instead of virtualenv
<ikwildrpepper>
copumpkin: wasn't that also while they were hanging?
<serougjserg>
Hi! When hitting `nix-env -qa` and finding python3.5-pgcli-1.3.1, I wish to `nix-shell -p python3.5-pgcli`. When doing that I instead get "error: syntax error, unexpected INT, expecting ID or OR_KW or DOLLAR_CURLY or '"', at (string):1:74". What is this and how can one use this program in NixOS?
<copumpkin>
how do you mean? I just mean it blasted through most of the remaining jobs
<ikwildrpepper>
never mind, not paying attention ;)
<copumpkin>
and when it gets through the last two (both on mac6)
<copumpkin>
maybe gchristensen's bot will join and tell us that the nixpkgs-unstable channel updated :D
<clever_>
serougjserg: you need to use attribute names in -p
<gchristensen>
:)
miefda has quit [(Read error: Connection reset by peer)]
<LnL>
\o/
sauyon has joined #nixos
sauyon has quit [(Client Quit)]
deltasquared has quit [(Quit: segmentation fault)]
sheenobu has joined #nixos
<joepie91>
serougjserg: corresponding attribute name is python35Packages.pgcli
Fare has quit [(Ping timeout: 276 seconds)]
<LnL>
serougjserg: if you use nix-env -qaP it will include the attribute name
serougjserg has left #nixos ["ERC (IRC client for Emacs 25.1.1)"]
aoweirgherg has quit [(Quit: ERC (IRC client for Emacs 25.1.1))]
Ivanych1 has joined #nixos
<seequ>
Ooi, is there a way to remove all packages downloaded with nix-env (for the current user)
<clever>
seequ: nix-env -e i think
<seequ>
Huh.
Ivanych has quit [(Ping timeout: 255 seconds)]
<clever>
in the man page, i see that nix-env -riA nixos.hello
<clever>
will remove everything, and install hello
<clever>
so hello will be the only installed thing
<clever>
$ nix-env -e '.*' (remove everything)
<clever>
seequ: this example is also in the man page
<seequ>
Ah, I tried `-e .*` - and completely forgot that bash expands it
<bennofs>
is it possible to install a "plain" gcc on nixos, that doesn't do things like adding -fstack-protector or -Werror=format-security automatically
<bennofs>
?
<clever>
bennofs: nix-shell -p gcc.cc
<clever>
bennofs: or set hardeningDisable = "all" i think
<NixOS_GitHub>
nix/master 57b9505 Eelco Dolstra: nix search: Add a cache...
NixOS_GitHub has left #nixos []
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] abbradar pushed 5 new commits to master: https://git.io/v73MM
<NixOS_GitHub>
nixpkgs/master c3a9f59 Nikolay Amiantov: mumble_git: 2017-04-16 -> 2017-05-25
<NixOS_GitHub>
nixpkgs/master 0a7f2ac Nikolay Amiantov: boost164: init at 1.64.0
<NixOS_GitHub>
nixpkgs/master 50ed470 Nikolay Amiantov: python.pkgs.PyChromecast: init at 0.8.1
NixOS_GitHub has left #nixos []
mrcheeks has joined #nixos
ryanartecona has quit [(Ping timeout: 255 seconds)]
Filystyn has joined #nixos
Filystyn has quit [(Changing host)]
Filystyn has joined #nixos
<magnicida>
ok i found my problem, apparently that project was running using ubuntu precise on travis and nix requires trusty at least
jonte has joined #nixos
obadz has quit [(Ping timeout: 255 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] vcunat pushed 1 new commit to master: https://git.io/v73S5
<NixOS_GitHub>
nixpkgs/master ac4c567 Vladimír Čunát: pythonPackages.augeas: init at 1.0.2
NixOS_GitHub has left #nixos []
obadz has joined #nixos
Myrl-saki has quit [(Ping timeout: 240 seconds)]
<disasm>
justlex: there's no global flags to my knowledge that you could do that with.
drakonis has quit [(Remote host closed the connection)]
drakonis has joined #nixos
ebzzry has quit [(Ping timeout: 276 seconds)]
<hodapp>
with something like "nix-shell -p python35Packages.numpy python35Packages.toolz" (as in the manual), does this automatically include Python as a dependency?
<disasm>
justlex: I'm not even sure that's possible, because everythings a function, you'd have to basically pass an attribute with those global flags to every package.
<justlex>
thank you disasm
phinxy has quit [(Read error: Connection reset by peer)]
<disasm>
someone more versed in the ways of nix though can correct me if I'm wrong :)
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] vcunat pushed 1 new commit to release-17.03: https://git.io/v739H
<NixOS_GitHub>
nixpkgs/release-17.03 7cb1cf0 Vladimír Čunát: pythonPackages.augeas: init at 1.0.2...
NixOS_GitHub has left #nixos []
<justlex>
I once tried to code in asm language in new year eve, was a lot of fun, mov eax,rax ,etc
FRidh has quit [(Quit: Konversation terminated!)]
[0x4A6F] has quit [(Ping timeout: 240 seconds)]
<hodapp>
why on NYE?
<hodapp>
were you drunk? :P
samae has quit [(Ping timeout: 240 seconds)]
ison111 has joined #nixos
<dash>
hodapp: it'd be hard to get numpy without python....
<hodapp>
dash: well, for instance, it could pull in the module itself and leave me without an interpreter. I'm just making sure I understand how things work
<dash>
hodapp: pretty sure every python package propagates python itself
<hodapp>
alrighty
<dash>
huh, i could have worked harder to make that more alliterative
<justlex>
hodapp: i was just in bipolar mania stage and wanted for SPEED, so I thoutgh pure raw assembly is the way to go for SPEED UP
<hodapp>
next step: can I make Python 3.x build with OpenCV with contrib without violently exploding?
<hodapp>
OpenCV is involved, so probably no.
samae has joined #nixos
samae has quit [(Changing host)]
samae has joined #nixos
<dash>
it's nix, so the blast damage will be limited ;)
<hodapp>
yeahhhhhh, but an OpenCV-shaped crater is still a failure whether it's neatly contained or not
<hodapp>
I swear, I've had house fires that were better-behaved than this build
<dash>
i have the same feeling, i'm trying to get some cmake crap that works on centos to run under nix
<dash>
i used to not understand why it failed on nix, now i don't understand why it works on centos
<hodapp>
hah
wak-work_ has quit [(Quit: Leaving)]
<hodapp>
CMake makes me sad...
<dash>
it's a good idea
<dash>
but its syntax is worse than nix's
wak-work has joined #nixos
<hodapp>
it's a great pair of crutches for people who don't ever question why the leg is broken
georges-duperon has quit [(Ping timeout: 255 seconds)]
<dash>
ahahahahahaaaaaaa
<dash>
got it to run tests now at least
<hodapp>
worst CMake build I ever touched was probably PCL KinectFusion, and that was a build where I recall taking the better part of a work week to get it working for the first time on Windows
<dash>
you're gonna love this story
drakonis has quit [(Read error: Connection reset by peer)]
seanz has joined #nixos
seanz has quit [(Client Quit)]
<hodapp>
it used every single C++ atrocity they could find
<hodapp>
and so I was getting the sorts of compile-time errors where you see the room lights dim before it starts spitting out the error message
<dash>
the check phase was refusing to run tests because ctest was trying to run 'make install' first, and it was failing
<hodapp>
wut.
<dash>
i was baffled because this worked on centos despite there being no 'install' target in the generated makefile
<dash>
buuuuuuuuut
<dash>
on centos there _was_ an 'install' subdir in the build dir
<dash>
so 'make' was taking a dir name as an arg and then doing nothing
<dash>
brillant
<clever>
you told it to make install, and install already exists, done!
<hodapp>
wowzers
<clever>
without a .phony: install, it cant do anything more
<dash>
yep
freusque has quit [(Quit: WeeChat 1.9)]
<dash>
so "checkPhase = 'mkdir install; ctest'" fixed that
<hodapp>
part of why I'm futzing around with OpenCV is that the EmguCV build for C# bindings was such a royal mess, and at some point I realized that that was because the build was leaving around dozens of cached settings which 'make clean' and nuking the build directory was not touching
<pie_>
i dont see a package for msbuild for mono, so i suppose there isnt one?
* pie_
pokes thoughtpolice because he is listed as a maintainer for mono
<dash>
now I'm facing the problem of stuff being installed directly to the store instead of the 'install' subdir, where the tests look for it
<hodapp>
mono worked okay for me, but the big issue is that debugging was near impossible
<hodapp>
especially when I was using native libraries alongside the C#
athan has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] risicle opened pull request #27662: aws-auth: init at unstable-2017-07-24 (master...aws-auth) https://git.io/v735b
<avn>
pie_: xbuild is inside mono, real msbuild is somewhere on github, you can try build it ;)
<pie_>
yeah turns out xbuild was sufficient for what i needed,turns out i needed to nuget some dependencies for the project i was trying to build, i know nothing about c# or its ecosystem
<pie_>
msbuild didnt want to build without fiddling around
jgarr has joined #nixos
Sonarpulse has joined #nixos
<jgarr>
Is it possible with nix (package manager) to have different versions of apps launched in different shells? I guess what I'm asking is the link tree for the application system based or environment based?
<Sonarpulse>
jgarr: nix-shells?
<Sonarpulse>
nix-shell doesn't use symlink trees
<jgarr>
I'm sure if I used it for a few minutes I could easily figure this out. Just thought I'd ask first
<Sonarpulse>
(it took me quite a while to figure that out!)
<Sonarpulse>
nix-env and nix-shell work in completely unreleated ways
* jgarr
is reading the docs
<jgarr>
are you able to explain the difference?
<Sonarpulse>
jgarr: perhaps
<Sonarpulse>
nix-enb uses buildenv underneath the hood
<Sonarpulse>
envHooks add flags for headers n stuff
yegods has quit [(Ping timeout: 276 seconds)]
<symphorien>
jgarr: just lanch nix-shell -p python3.4 and nix-shell -p python3.5
<jgarr>
so in a nix environment just a specific ordered list of $PATH?
erictapen has quit [(Ping timeout: 248 seconds)]
* jgarr
is reading firefox/wrapper.nix
<sphalerite[m]>
jgarr: depends on what you mean by nix environment
<jgarr>
thinking this is very complex to define an application but maybe FF is a bad example
<sphalerite[m]>
nix-shell? What's managed by nix-env? buildEnv?
<sphalerite[m]>
Environment is an unfortunately overloaded term for niz
<sphalerite[m]>
Nix
xadi has quit [(Ping timeout: 255 seconds)]
<bennofs>
does anyone else experience errors with docker on latest nixos-unstable?
<bennofs>
: starting container process caused "exec: \"-v\": executable file not found in $PATH".
<jgarr>
I think nix terms is going to take me a while to grok. Does anyone have familiarity with red hat's software collections? I think a comparison (terminollogy and functionallity) would help someone like me. I can activate an scl in a shell which basically just prepends the PATH and LD_LIBRARY to the scl directory
<jgarr>
It's not a perfect isolation though and the standard PATH is sitll at the end of the env. So anything not found in the scl gets pulled from somewhere else in the PATH. Does nix work the same way or is it completely sealed off from PATH/host packages?
deltasquared has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 2 new commits to master: https://git.io/v73No
<NixOS_GitHub>
nixpkgs/master 2989324 Robert Scott: aws-auth: init at unstable-2017-07-24
<NixOS_GitHub>
nixpkgs/master 2780025 Robin Gloster: aws-auth: clean up
NixOS_GitHub has left #nixos []
danl1240 has joined #nixos
<jgarr>
I'm also trying to figure out differences with nix vs putting software in docker containers or appimage/flatpak/snap
<jgarr>
They all seem to solve similar problems in different ways WRT application dependencies
<joepie91>
jgarr: so the tl;dr of Nix' dependency/environment model is approximately this... 1) every package gets built in a 'sterile' environment; no system-wide libraries, no homedir, etc., only env vars set up to point at the dependencies *explicitly* defined in the build's expression, 2) after building libraries and applications (which now have dependency paths hardcoded into them), anything that's in environment.systemPackages or some other sort of user
<joepie91>
environment definition (eg. installed via nix-env) gets collected into a 'virtual environment', which is really just a folder full of symlinks to particular builds; that environment folder is what gets set in PATH and such, so that you can eg. execute binaries from your virtual env
<joepie91>
jgarr: there are more ways to produce environments; eg. you can use `nix-shell -p foo` to build a package `foo`, and then create an ad-hoc virtual environment layered on top of the 'current' environment, where that ad-hoc environment *also* points at the built `foo`
<joepie91>
jgarr: in the end, there is no global /lib directory, there is no runtime resolution of dependencies, and so on; everything is generated on build time and tied together through symlinks and minimal env var modifications
<joepie91>
jgarr: as for the difference between what Nix does, and what container-based solutions (Docker, flatpak, etc.) do; no containers are involved in Nix, unless you specify them explicitly
<copumpkin>
oh it's scheduled to be built
<jgarr>
joepie91: so environments would have to be "built" to create symlink trees but then can be switched between on a per nix-shell basis and inherited by other trees, correct?
<joepie91>
jgarr: container-based options use a traditional 'global' environment but wrap it in a box (a container) to try and make it not interact with anything else; Nix fundamentally uses a different filesystem structure to not *have* that global environment in the first place
<copumpkin>
so I assume once those question marks turn to check marks, we'll have a channel update?
<joepie91>
jgarr: (which is solving the problem at the root, as opposed to sort of sweeping it under the carpet; container-based solutions introduce a lot of unnecessary complexity and overhead)
<deltasquared>
joepie91: wrt to not having a global env to begin with, I wish I was using nixos when trying to ensure a musl build wouldn't use anything from the host.
<joepie91>
jgarr: more or less, yeah. you could theoretically 'active' any environment in any given one shell without affecting anything else
<joepie91>
activate *
<joepie91>
jgarr: including past generations of environments, too; rollbacks in NixOS are based on this approach
<joepie91>
that is, you can boot into a system that points at a different, older symlink tree
<deltasquared>
heh, who needs btrfs snapshots
<joepie91>
jgarr: however, it's worth noting that what NixOS does *just* provides dependency isolation, not runtime isolation; this is by design, but it is an important difference to be aware of when you're used to eg. Docker
<dash>
deltasquared: people with data they want to manage via snapshots, since nixos only addresses configuration :)
<jgarr>
I do feel like flatpak is trying to work backwards from a docker container and build something simpler like nix. I was just trying to understand how nix accomplishes the environments and what layer (shell vs system) they were isolated
<deltasquared>
dash: true, I guess I'd just use btrfs for /home
<deltasquared>
for example
<joepie91>
jgarr: you *can* set up containers declaratively, though, if you also need runtime isolation: https://nixos.org/nixos/manual/index.html#sec-declarative-containers (without requiring additional tooling or special config formats, just as a part of your system config)
<deltasquared>
jgarr: a shitton of symlinks, and setting the likes of PATH and LD_LIBRARY_PATH
<jgarr>
joepie91: ya, I understand that part. I'm looking at packaging isolated gui apps which are slightly harder in docker because of how much they isolate the runtime
<dash>
i made a zfs snapshot before running tagging/organization software on my mp3 collection
<dash>
that sort of thing
<joepie91>
jgarr: right. that would be the complexity I was referring to earlier :) for GUI apps, you typically just want dependency isolation, not runtime isolation
<dash>
o/` splendid isolation, I don't need no one o/`
<deltasquared>
if we really wanted runtime isolation I guess we'd need namespaces
<deltasquared>
like, the kernel feature
<joepie91>
jgarr: but yeah, the key point of NixOS (and, to a degree, Nix as a package manager) is that there's no such thing as a global environment; it doesn't follow FHS, /lib doesn't exist, and so on. *all* applications are run based on whatever virtual environment you happen to be in at the time, and *all* dependencies are explicit.
<jgarr>
joepie91: that paper is 13 years old. Is it still basically how nix packages work?
<joepie91>
jgarr: some details have changed, but it is accurate enough to understand the model
<joepie91>
(implementation details have changed, that is)
<jgarr>
thanks
<joepie91>
deltasquared: see the declarative containers thing I linked :)
<deltasquared>
oh, and possibly a setup helper daemon, because no non-privileged namespaces :/
<joepie91>
deltasquared: LXC is just kernel namespacing features really
<jgarr>
we have an internal tool we use for dependency isolation. It works very well for us but we are still required to maintain it so I was trying to think of alternatives
<FRidh>
staging is building for nothing again
<jgarr>
are there ways to "install" existing applications as nix environments? eg I have a bunch of rpms and it would be non-trivial work for me to declare them as nix packages
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] primeos pushed 1 new commit to master: https://git.io/v73xP
<NixOS_GitHub>
nixpkgs/master 40a568b Michael Weiss: android-studio-preview: 3.0.0.6 -> 3.0.0.7
NixOS_GitHub has left #nixos []
<deltasquared>
jgarr: it should be noted that being able to use nix may require changes to build processes to conform to the "purely functional" idea
* jgarr
is thinking of something similar to yum install --root /nix
<joepie91>
jgarr: I would say that Nix is worth it and definitely a good solution, *if* you are willing to invest a considerable amount of time upfront into understanding how it pieces together and how to package your own things.
<deltasquared>
who was it on here the other day trying to build openCV and finding it downloaded things in the cmake file
<joepie91>
jgarr: documentation and usability are not yet at a level where it's an overnight venture to get started with.
yegods has joined #nixos
<joepie91>
jgarr: (I'm currently in a migration of my existing hosted infrastructure to NixOS, and it's not exactly painless yet; but once it works, it *works*, and I don't really have to think about it anymore)
<joepie91>
(after having been using NixOS on my desktop for a number of months now)
<joepie91>
Nix can be used on non-NixOS as well, but you won't get eg. declarative config
<joepie91>
which means you get a lot less value from it :)
<deltasquared>
I guess the nice thing about nixos is that it can be both stable and cutting edge to a degree at the same time, all on the same system
<joepie91>
also means you can't use declarative containers, and basically anything else that needs to touch or manage the kernel
<jgarr>
right, and using just nix is what I was looking at. We are far too tied to rhel/centos
<hodapp>
FRidh: oh, I just had the build fail with Python 3.5 but I don't know
<joepie91>
jgarr: right, so Nix-on-non-NixOS is essentially limited to "just packages, nothing else"
<hodapp>
ah. yeah. same error
<gchristensen>
copumpkin: you mean for 57060860 ?
<hodapp>
damn, happens on Python 2.7 too
<jgarr>
joepie91: ya, but I think that's all I want/need at this point. Our existing solution is "just packages" too
<deltasquared>
joepie91: do the docs have anything on how nixos does the containers? is there a daemon that you can talk to via commands for instance (curious as to the security setup)
<joepie91>
jgarr: personally I'd say that if you intend to use Nix beyond a single difficult-to-manage application, but rather for your entire infrastructure, it's probably not worth it to try and use it on a RHEL system; it's not that much more effort to move to NixOS than to move to Nix-on-non-NixOS/.
<joepie91>
but the benefits of using NixOS will be much greater
fresheyeball has joined #nixos
<joepie91>
if it's just a single difficult thing you want to manage through Nix, then using it on non-NixOS is completely acceptable though
<fresheyeball>
hey
yegods_ has joined #nixos
<fresheyeball>
so I have a nix expression
<fresheyeball>
that imports another nix expression
yegods has quit [(Read error: Connection reset by peer)]
<joepie91>
jgarr: in the end most of the work is just going to be in "getting software to play nice with a pure environment" and you have to deal with that either way
<joepie91>
whether NixOS or noit
<joepie91>
not*
<fresheyeball>
and when I build the importing expression, it ALWAYS rebuilts the imported expression
<jgarr>
we have hundreds (maybe thousands) of isolated application environments in our existing tool. We build many per day but again, it's a custom tool so it's a little harder to maintain
<fresheyeball>
how can I prevent this?
<fresheyeball>
no changes have been made to the source of the imported expression
<fresheyeball>
so I feel it should just pull from the store
<joepie91>
deltasquared: docs on containers are a bit limited; however, afaik unprivileged LXC is not yet supported by Nix-specific tooling
<fresheyeball>
but it does't
<joepie91>
deltasquared: the NixOS manual contains some docs on both imperatively and declaratively managed containers, though
<deltasquared>
joepie91: I didn't mean that, I just meant what does nixos use to start the containers - I assume there's a daemon somewhere
<joepie91>
deltasquared: if you just want runtime isolation on NixOS, then declarative containers are probably what you want, and no imperative management would be needed
<joepie91>
ah. not entirely sure
<jgarr>
joepie91: thanks for the info. That helps me know where to start with comparisons
yegods has joined #nixos
<FRidh>
fresheyeball: what does the expression have for `src` , a local path?
<joepie91>
jgarr: this is a configuration set for NixOps, which is a small-ish deployment management tool built on NixOS; entry points are in networks/ and systems/ (for machine configuration and deployment configuration respectively), from there you can follow imports
<joepie91>
so far I've only set up a single custom Node.js application but it gives an idea of what it might look like with declarative configuratioin
takle has quit [(Remote host closed the connection)]
<joepie91>
jgarr: if I were to express this in a Nix-on-RHEL vs. NixOS boundary... then once you get to applications/pastebin-stream.nix you're in Nix territory
yegods_ has quit [(Ping timeout: 248 seconds)]
<joepie91>
ie. the code from thereon is what I'd need to install the application via Nix on a non-NixOS system
erictapen has joined #nixos
<radvendii>
Why doesn't nixos wrap each application in their own $PATH? Like, why is there a universal $PATH and thus cross-contamination between applications at runtime? I think nix-build with sandboxing does this, but I'm not sure why this kind of sandboxing isn't more generally applied
<simpson>
radvendii: $(nix-shell --pure)
sheenobu has quit [(Quit: My Mac has gone to sleep. ZZZzzz…)]
<joepie91>
radvendii: I don't know the specific reason, but keep in mind that sometimes applications do need to be able to access the 'user $PATH'; eg. editors with a built-in terminal. a pure $PATH is certainly not universally applicable
<radvendii>
joepie91: oh interesting. that's a good point. Or even if I want to open things I have installed using my terminal emulator...
grisher has joined #nixos
<radvendii>
simpson: Yeah, I was asking about things installed using nix-env or environment.systemPackages
<joepie91>
radvendii: that, too :)
<joepie91>
although that could be hacked around with shell inits
nschoe has quit [(Quit: Program. Terminated.)]
<joepie91>
but yeah, I don't know what the canonical reason is, but I can imagine that runtime purity isn't necessarily desirable simply because it'd break a lot of assumptions that are hard to fix
<joepie91>
and runtime contamination is a fairly limited problem in the first place
<deltasquared>
if you'd have caught me a few years ago I would have gone all entitled and claimed it was the apps fault for breaking under that model, but eh
<joepie91>
apps should attempt to be reasonable pure, sure; but there are legitimate reasons not to be
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 4 new commits to openssl-1.1: https://git.io/v73hB
<NixOS_GitHub>
nixpkgs/openssl-1.1 96cd099 Robin Gloster: treewide: fix up some mysql.connector-c fallout
<NixOS_GitHub>
nixpkgs/openssl-1.1 c953b09 Robin Gloster: php56: adapt openssl 1.1 patch to updated package
<NixOS_GitHub>
nixpkgs/openssl-1.1 cb4f29f Robin Gloster: hackrf: 2015.07.2 -> 2017.02.1
NixOS_GitHub has left #nixos []
<joepie91>
reasonably*
<joepie91>
on runtime anyway
<radvendii>
joepie91: I suppose, but it does sometimes cause problems if something like `#!/usr/bin/env python` slips through in the code, and therefore calls the runtime path version instead of the version you actually needed (say python 2 versus python 3)
<joepie91>
sometimes it just doesn't mesh with user expectations :)
<joepie91>
radvendii: that should have been fixed by patchShebangs though
<radvendii>
*angry face* then users should change their expectations! :P
<joepie91>
that is, patchShebangs is supposed to automatically patch any such remaining shebangs in build outputs
<joepie91>
or at least I think it is automatic, in the default builder
<deltasquared>
joepie91: shebangs/interps are a hard one to do without enclosing the environment in a container.
<radvendii>
joepie91: oh interesting. I think it slipped through somewhere in the qutebrowser package, which is why I was thinking about this
<radvendii>
(I already oppened an issue on github)
<clever>
joepie91: i recently discovered that patchShebangs doesnt patch the scripts behind symlinks
<joepie91>
radvendii: might be an expression bug then :)
<joepie91>
clever: as in, symlinks within the build output?
<joepie91>
deltasquared: hard in what sense?
<clever>
joepie91: in my case, a bin dir in the source, with symlinks to various #! scripts that wanted node
<radvendii>
joepie91: oh for sure, but this kind of expression bug is really hard to track down, and the runtime sandboxing would make it irrelevant. But I also get there are reasons to not want runtime sandboxing
<clever>
joepie91: i cant patch the entire bin dir
<joepie91>
(I can't believe I'm actually starting to understand NixOS well enough that I can start having concurrent IRC discussions and explanations :P)
sheenobu has joined #nixos
<joepie91>
clever: hm. have you created a ticket for that?
<joepie91>
that sounds like a bug
<clever>
joepie91: not yet
<joepie91>
(that needs a reproducible testcase)
<joepie91>
... well, I guess everything is reproducible
<amarolo_>
I am having issues using wine with nixos, I get this error: err:module:import_dll Loading library byondext.dll (which is needed by L"C:\\Program Files\\BYOND\\bin\\byondcore.dll") failed, but I am inside the directory with the right .dll's, so it doesn't makes sense that it doesn't find it
<hyper_ch>
attempting to rebuild now
<deltasquared>
that said, python's /usr/bin/env trick should work well. all you'd need in the "global" location is the env binary, it would pick up python from path
bennofs has joined #nixos
<joepie91>
deltasquared: though admittedly it'd be nice if there were a very low-friction way to put personal scripts through a build
<joepie91>
deltasquared: the sort of "you can pick this up in 5 minutes from first using Nix" way
<deltasquared>
instead of writing a nix expression and all that rigmarole ;)
<joepie91>
hyper_ch: is this in a guest or a host?
<hyper_ch>
host
<joepie91>
ok, moment
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] Ericson2314 pushed 4 new commits to staging: https://git.io/v7seK
<NixOS_GitHub>
nixpkgs/staging f6f40e3 John Ericson: stdenv-setup and misc pkgs: Revert to space-deliminated propagated-* files...
<NixOS_GitHub>
nixpkgs/staging ea7d13c John Ericson: stdenv-setup and misc hooks: Work with bash-3.4 for MacOS nix-shell...
<NixOS_GitHub>
nixpkgs/staging 820e402 John Ericson: stdenv-setup: Remove any `declare -g`...
NixOS_GitHub has left #nixos []
<gchristensen>
Sonarpulse: ping
ertes-w has quit [(Ping timeout: 260 seconds)]
<amarolo_>
any wine users?
<joepie91>
hyper_ch: hrm, no idea why that happens, sorry
<joepie91>
don't see a reason why it'd break..
<hyper_ch>
joepie91: well, recompiling now
jonte has quit [(Ping timeout: 255 seconds)]
<FRidh>
hodapp: I think the sed line should be taken as an example, not that it is mentioned literally
<hodapp>
FRidh: ahh. I'm just trying to figure out what was meant there
<FRidh>
hodapp: yes its a bit unfortunate the link refers to the master branch instead of a commit/tag of the version
<hodapp>
sadly this is also a bit of code I was hoping was working right because I need to extend it for something >_>
georges-duperon has joined #nixos
<amarolo_>
every time I try to do something slightly complicated on nixos, i run into issues with nowhere to go for answers... like where is the wiki?
<amarolo_>
do I really need to spend 30 hours learning the ins and outs of the nix language, which is not standardized anywhere, to be able to use nixos?
<radvendii>
amarolo_: and yeah, learning to work on nixos is a bit of a learning curve. I'm still very much learning myself, but it does get easier, and the community is very helpful. What's your trouble?
<bennofs>
hmm fun, if I script and then scriptreplay the docker command, the scriptreplay works fine...
<radvendii>
amarolo_: I could say "usually the problems are caused by applications cutting corners and using bad coding practices when they write their code. Exploiting things that can't be exploited on nixos, etc" and that would be true, but it's also not terribly helpful. I definitely understand the frustration with things breaking under nixos and taking hours longer to set up than it would have on ubuntu
<bennofs>
disasm: o.o reset fixes it!!! <3
<amarolo_>
radvendii: do you run wine from sort of a nix-shell? it isn't finding application specific dlls that are in the same folder as the executable
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] jb55 opened pull request #27665: jailbreak-cabal: specifically use ghc802 override in ghc821 config (master...fix/ghc821-inf-loop) https://git.io/v7sUZ
NixOS_GitHub has left #nixos []
<bennofs>
disasm: so all I need to do is to run `tset`
<bennofs>
disasm: still unfortunate that it doesn't work automatically..
<bennofs>
disasm: do you know if there is any way i can avoid having to run that?
<et4te>
guys whats the fix for /usr/bin/env: bad interpreter: No such file or directory, for chroot builds?
<et4te>
the build works locally
<radvendii>
amarolo_: I don't. My wine configuration is that I put winetricks and wineUnstable in my systemPackages, and then I use them as normal
<radvendii>
amarolo_: what error are you getting?
<clever>
et4te: run patchShebangs on the directory wit h the scripts
erictapen has quit [(Ping timeout: 248 seconds)]
<et4te>
clever: how do you do that?
<disasm>
bennofs: typically that happens to me when I do something that causes the terminal to receive a bad character, either a bad copy paste, or a cat of a file with nasty symbols etc... If that's happening from a clean terminal, I'm at a loss.
<et4te>
clever: i'm not on a nixos machine i use nix from ubuntu
<bennofs>
disasm: i have to run it inside the container
<clever>
et4te: where are the scripts with the errors?
<bennofs>
disasm: but if I run tset in the container once, everything is fine after that
<et4te>
clever: ~/js/sjcl
<et4te>
clever: it fails on configure
<clever>
et4te: is the problem happening at nix build time, or runtime, can n you gist the entire error?
<disasm>
bennofs: you could try running env in the bad state and compare it in the good state.
georges-duperon has quit [(Ping timeout: 240 seconds)]
<et4te>
clever: sure, i'll gist but it happens when hydra runs a build on the src
deltasquared has quit [(Quit: segmentation fault)]
<clever_>
et4te: thats why i always setup sandboxing on my own machines
<bennofs>
disasm: env is exactly the same before & after
<et4te>
clever_: I have useSandbox enabled though on the hydra machine
fresheyeball has quit [(Quit: WeeChat 1.7.1)]
<clever_>
et4te: yeah, it also has to be enabled in the ubuntu box where you where testing
<et4te>
clever_: ah right. the build works locally though, but yeah i should do that so that they both produce the same result
<clever_>
et4te: the problem appears to be with the configure script itself
Mercuria1Alchemi has quit [(Ping timeout: 240 seconds)]
<clever_>
et4te: so you want to do preConfigure = "patchShebangs .";
reinzelmann has joined #nixos
<radvendii>
amarolo_: I'm wondering if this is an ELF problem, which is something I've had to deal with before in the context of wine
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] peti pushed 3 new commits to master: https://git.io/v7sTp
<NixOS_GitHub>
nixpkgs/master d680c23 William Casarin: jailbreak-cabal: specifically use ghc802 override in ghc821 config...
<NixOS_GitHub>
nixpkgs/master 77e9a04 William Casarin: maintainers: update my(jb55) email
<NixOS_GitHub>
nixpkgs/master 81e998b Peter Simons: Merge pull request #27665 from jb55/fix/ghc821-inf-loop...
NixOS_GitHub has left #nixos []
<disasm>
bennofs: what about echo $TERM in bad and good states?
<bennofs>
disasm: the env is exactly the same
<disasm>
err if env is the same yeah...
<radvendii>
amarolo_: essentially, executables (and I don't know if this applies to dlls as well. that's the question) are bundled with an interpreter, and sometimes the path to that interpreter is hard-coded. which causes problems because nix stores things in weird places. The error I got with that was 'file not found' even though the file was right there
<radvendii>
amarolo_: so it sounds somewhat familiar
radvendii has left #nixos ["WeeChat 1.9"]
<et4te>
clever_: omg that actually worked
radvendii has joined #nixos
<et4te>
clever_: i have no idea what that does but awesome
<amarolo_>
yeah definately
<clever_>
et4te: it replaces #!/usr/bin/env foo, with the absolute path to foo
<clever_>
et4te: so it no longer relies on env, and it cant change what foo its using in the future
<et4te>
clever_: ah so i guess anytime i see /usr/bin/env I should patchShebangs in any sandbox env
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] abbradar pushed 2 new commits to master: https://git.io/v7sku
<NixOS_GitHub>
nixpkgs/master c3d5cfd Martin Wohlert: swap: extend randomEncryption to plainOpen and ability to select cipher
<NixOS_GitHub>
nixpkgs/master 9be26f8 Martin Wohlert: change swap.randomEncryption config option to "coercedTo" for backwards compatibility
NixOS_GitHub has left #nixos []
<clever_>
et4te: yep
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] abbradar closed pull request #25999: swap: extend randomEncryption to plainOpen and ability to select cipher (master...swap-randomEncryption-options) https://git.io/vHImj
NixOS_GitHub has left #nixos []
<clever_>
et4te: nix will also try to run it automatically on $out/bin/ during the fixupPhase (after installPhase)
<et4te>
clever_: dude thanks a lot thats the second time you solved my problem instantly
<radvendii>
amarolo_: I don't remember exactly what commands you need to run, but look into patchELF
<et4te>
clever_: ah right, so it only affects certain phases
<clever_>
et4te: the preConfigure hook i gave will fix all scripts that exist at that time, in the current dir (like configure)
<amarolo_>
radvendii: well, patching windows elfs at this point is byond my reach, i might have to find another os
<clever_>
et4te: and configure will remain fixed for the rest of the build
<amarolo_>
my point is that it isn't worth the hassle
<bennofs>
windows does not use elf
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to master: https://git.io/v7skF
<NixOS_GitHub>
nixpkgs/master 0a4c430 Antoine Eiche: docker: do not import configuration and manifest from the base image...
NixOS_GitHub has left #nixos []
<clever_>
windows uses pe32
<bennofs>
so you cannot apply patchelf to windows binaries
Ivanych1 has quit [(Quit: Leaving.)]
<et4te>
clever_: makes sense I guess to ensure that all the deps are the sandbox deps within the script?
<clever_>
et4te: yeah
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] edolstra pushed 1 new commit to master: https://git.io/v7sIe
<amarolo_>
it seems to show that it is looking in a specific folder: open("/nix/store/fbb8j3jn4iysl87i1p5rw7sis1lpn5vl-wine-2.0/bin/../lib/wine/byondext.dll.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<clever_>
look near that, it may check many places
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 1 new commit to master: https://git.io/v7sY2
<NixOS_GitHub>
nixpkgs/master 8b3e9a1 Tim Steinbach: gradle: 4.0.1 -> 4.0.2
NixOS_GitHub has left #nixos []
<joepie91>
hyper_ch: best create an issue I think...
<disasm>
if there's one thing more annoying than running strace on proprietary binaries it's running strace on windows binaries, lol :)
<hyper_ch>
joepie91: as you commanded, I obeyed :)
<joepie91>
hyper_ch: I have no idea why it's breaking, because it's using the output path and the corresponding hash... so even if eg. the extpack download failed, it should have failed on the extpack derivation, not the virtualbox build; hence why I have no idea why it breaks
<joepie91>
and I don't know enough about the virtualbox packaging to know it as a common issue
<hyper_ch>
someone else was also complaining about vbox earlier in this channel
sigmundv_ has joined #nixos
<hyper_ch>
but s/he/it was on master IIRC
<joepie91>
hyper_ch: for what it's worth, I don't bother with virtualbox anymore since I learned how to use qemu
<joepie91>
may or may not apply to your case
<joepie91>
but virtualbox has always been some degree of pain for me in the past, regardless of OS
<hyper_ch>
still couldn't figure out how to auto-adjust guests in qmeu
<joepie91>
and QEMU is just a lot nicer to deal with, on Linux :P
<joepie91>
less mysterious failures and gotchas
<disasm>
joepie91: agreed, I made the switch to qemu/virt-manager about a month ago and I don't regret it at all :)
<joepie91>
no idea about that specifically
<hyper_ch>
qemu itself is a big mystery though
<joepie91>
disasm: wellll virt-manager is a separate story
<joepie91>
libvirt is horrible
<joepie91>
:p
<joepie91>
I just interact with qemu directly
<joepie91>
the problem with libvirt is that it works great until it doesn't and then you're buried in useless uninformative error messages
ison111 has quit [(Ping timeout: 240 seconds)]
endformationage has joined #nixos
radvendii has joined #nixos
<sphalerite[m]>
Does anyone know of a way (perhaps with zfs) to make sure there's always at least X amount of space available for a particular path in the filesystem? Specifically, I've just run into an issue where my emails stopped arriving because some experiments someone else was running on the server ate up all the disk space and I'd like to avoid issues like that in the future... :D
ison111 has joined #nixos
magnicida has joined #nixos
<aristid>
gchristensen: while the nixos channel has updated, my test on the latest nixpkgs commits still say it's failing (only sometimes, but i run the test 30 times in a row)
reinzelmann has quit [(Quit: Leaving)]
colabeer has joined #nixos
tghume has quit [(Ping timeout: 255 seconds)]
<clever_>
sphalerite[m]: zfs shares the free space of every filesystem in the pool, and each filesystem can optionaly have a quota setting the upper limit on usage
<sphalerite[m]>
Yeah, but can it also have a given amount reserved for it?
<clever_>
i dont think you can directly reserve it, but a quota on everything else would do that
<LnL>
yes
sphalerite has left #nixos []
<joepie91>
sphalerite[m]: you... could make it a volume when using LVM?
<joepie91>
of its own?
<LnL>
sphalerite[m]: zfs set reservation=5G rpool/foo
<sphalerite[m]>
(do you hear that sound? that's me leaving the IRC channel in irssi! Matrix has won me over)
riclima has joined #nixos
<clever_>
LnL: ahhh, nice
<sphalerite[m]>
joepie91: zfs-on-lvm seems a bit redundant :p
<LnL>
quota does the opposite
<sphalerite[m]>
LnL: thanks
reinzelmann has joined #nixos
<joepie91>
sphalerite[m]: don't know enough about ZFS to comment on that, but I know that *some* people combine ZFS with LVM
<sphalerite[m]>
I don't know that much about zfs either (even though I use it on my main laptop)
<clever_>
my laptop is zfs on lvm on luks
<clever_>
but i would avoid zfs on zfs when possible
<joepie91>
sphalerite[m]: in fact, clever_ is one of them :)
<joepie91>
right
<joepie91>
ninja'd me there
<joepie91>
:P
<sphalerite[m]>
So what's the use of having zfs on lvm?
<clever_>
sphalerite[m]: i wanted a single luks volume, and swap, but swap on zfs is bad
<clever_>
so lvm splits the luks up, into a swap, and a zfs pool
<sphalerite[m]>
aaah ok
<LnL>
^ I just didn't configure any swap
<clever_>
3gig of ram
<gchristensen>
is there something likebuiltins.parseDrvName but to get "git-2.13.3" out of /nix/store/6q1sa7w2xbf0c162d6jdyxmhp88wdx1d-git-2.13.3 ?
<clever_>
gchristensen: do you just have that string, or a derivation that evals to that string?
<gchristensen>
I have a derivation
<clever_>
you can just .name
<gchristensen>
omg
sheenobu has quit [(Quit: My Mac has gone to sleep. ZZZzzz…)]
<gchristensen>
thank you
<LnL>
:)
<clever_>
derivations are special attribute sets
<clever_>
that can also cast to a string
<gchristensen>
nice :D
<clever_>
nix-repl> hello // { type = "dummy"; }
<clever_>
gchristensen: try eval'ing this in nix-repl
<clever_>
nix-store -r /nix/store/foo --add-root result --indirect
<clever_>
i think
justelex has joined #nixos
<thoughtpolice>
You can also just make a symlink in /nix/var/nix/gcroot? This is what I normally do actually
<thoughtpolice>
(I can never remember the command itself so I just 'readlink' the path and `ln -s`)
<dtzWill>
:o
tghume has joined #nixos
<LnL>
well that's not a temporary root
kriztw_ is now known as kriztw
<thoughtpolice>
And actually that might not work on a multi-user system, come to think of it.
<gchristensen>
yikes :)
<LnL>
I want something that gets cleaned up when the indirect is removed
jonte has quit [(Ping timeout: 240 seconds)]
Ivanych has joined #nixos
<LnL>
I was using nix-instantiate --indirect --add-root but then I need to go through evaluation twice
<dtzWill>
clever_: what version of nix causes nix-repl to do something special w/the snippet you gave? Or should it be on all? Trying on my 1.11.x version just shows the result is '{ type = "dummy"; }' which is disappointing :#
<dtzWill>
(I had to define 'hello' to something, so I did 'hello = {}' previously)
<LnL>
that's supposed to be pkgs.hello
<dtzWill>
oh :D
<LnL>
nix-repl '<nixpkgs>'
<dtzWill>
haha okay ty :)
tghume has quit [(Ping timeout: 240 seconds)]
luigy has joined #nixos
jonte has joined #nixos
<joepie91>
LnL: I believe that clever_'s solution meets that requirement
<joepie91>
or at least some version of it that he gave me a while ago
<joepie91>
can't find my notes...
<LnL>
gchristensen: already pointed me in the right direction, you can do the same with nix-store for store paths
<LnL>
^ exactly what I wanted :)
<Sonarpulse>
LnL: do you know where I can find the source for ld.dylib?
<Sonarpulse>
for debuggign this __LINKEND thing?
Cement has joined #nixos
<Sonarpulse>
copumpkin referenced it in a thread
<Sonarpulse>
so I guess its out there
magnetophon has joined #nixos
<clever>
Sonarpulse: you mean /usr/lib/dyld?
<LnL>
I think darwin.cctools
<Sonarpulse>
clever: err yes, I suppose
<Sonarpulse>
LnL: thanks
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] svanderburg pushed 1 new commit to master: https://git.io/v7sB0
<NixOS_GitHub>
nixpkgs/master 94f0a67 Sander van der Burg: disnix: 0.7.1 -> 0.7.2
NixOS_GitHub has left #nixos []
radvendii has joined #nixos
acowley_away is now known as acowley
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] svanderburg pushed 1 new commit to release-17.03: https://git.io/v7sB5
<NixOS_GitHub>
nixpkgs/release-17.03 6bf7904 Sander van der Burg: disnix: 0.7.1 -> 0.7.2...
<Sonarpulse>
which does multiple outputs on top of derivationStrict
<gchristensen>
will do :0 though I worry this is getting crazy
<LnL>
not that I know of
jonte has quit [(Ping timeout: 248 seconds)]
<hodapp>
if I have something defined in ~/.nixpkgs/config.nix, how would I do something like nix-shell -A over this?
FRidh has quit [(Quit: Konversation terminated!)]
<hodapp>
a build issue shows up only under certain custom options to OpenCV & Python, so I'm trying to get myself into a build environment where I can look at this
<qknight_>
is there a way to make stateful changes to systemd on nixos? i want to add a systemd timer and service manually and not loose it when doing an 'nixos-rebuild switch'
slack1256 has joined #nixos
<sphalerite[m]>
Now I'm wondering... Why on earth is gfortran in the build-dependency closure of my dotfiles
<hodapp>
probably something needing BLAS/LAPACK
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] nlewo opened pull request #27669: docker: create image configuration and manifest files (master...docker-push) https://git.io/v7srO
NixOS_GitHub has left #nixos []
<LnL>
qknight_: I think you can specify that it should't be restarted
mudri` has joined #nixos
mudri has quit [(Ping timeout: 240 seconds)]
cpennington has quit [(Remote host closed the connection)]
<adelbertc>
anyone here running NixOS on the 2017 X1 Carbon?
<dash>
I am
<adelbertc>
dash: how is it working?
<dash>
very good
<dash>
i haven't tried bluetooth on this one but everything else works fine
<Infinisil>
I have a problem (or maybe I'm just too inexperienced): I want to install grub onto a zfs dataset, and I don't know how I can do that with nixos
leat has quit [(Ping timeout: 255 seconds)]
<Infinisil>
Because doing boot.loader.grub.device = "/dev/zfs"; doesn't work, using the boot's mountpoint directly doesn't either, and "stick/boot" doesn't either
<yegortimoshenko>
i'm not sure, i just installed nixos with zfs as my root file system
<gchristensen>
Infinisil: I point grub to devices = [ all devices in the pool ]
<gchristensen>
Infinisil: and then add zfs to boot.supportedFilesystems
<yegortimoshenko>
btw: error: cannot download google-chrome-stable_58.0.3029.110-1_amd64.deb from any mirror
<gchristensen>
and also boot.loader.grub.zfsSupport = true
<LnL>
booting straight from zfs works?
<LnL>
thought you needed a separate boot partition
<yegortimoshenko>
it does (unless you use EFI of course)
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to openssl-1.1: https://git.io/v7sDg
<NixOS_GitHub>
nixpkgs/openssl-1.1 26dc473 Robin Gloster: supercollider, qcachegrind: default to qt 5.9
NixOS_GitHub has left #nixos []
<gchristensen>
lol, I don't do either
<Infinisil>
So i can't use EFI?
<Infinisil>
Without making a separate non-zfs partition?
<gchristensen>
I don't know about EFI, just telling you what I've done
<gchristensen>
w/out efi
<yegortimoshenko>
i thought EFI requires VFAT volume
hamishmack has joined #nixos
<yegortimoshenko>
file system*
<Infinisil>
Hmm
<gchristensen>
are you using efi Infinisil?
<Infinisil>
gchristensen: I want to, yes
<Infinisil>
It's the new better thing, I think
<gchristensen>
oh you almost certainly need a vfat partition :)
<gchristensen>
"ZFS will also create a GPT partition table own partitions when given a whole disk under illumos on x86/amd64 and on Linux. This is mainly to make booting through UEFI possible because UEFI requires a small FAT partition to be able to boot the system. The ZFS driver will be able to tell the difference between whether the pool had been given the entire disk or not via the whole_disk field in the label. "
<gchristensen>
yeah I don't think it makes a difference
<gchristensen>
the _primary_ concern of partitioning zfs on linux is if you do, you don't want to use the other partition much
<sphalerite[m]>
That doesn't matter on EFI systems. You need a FAT partition so the firmware can load the bootloader.
<yegortimoshenko>
what are supposed benefits of whole disk zfs?
leat has joined #nixos
<gchristensen>
if you don't use the other partition during normal activity, it is fine
<Infinisil>
yegortimoshenko: I don't know myself, but the man page mentioned it's recommended. I'd think there are some optimizations, and with my old laptop I want every optimization I can get
<tilpner>
Does gchristensens link show any jobs for anyone on Firefox 54?
hiratara has joined #nixos
leat has quit [(Ping timeout: 240 seconds)]
<Durgeoble>
i have a little question about nixos, if i install python and some libraries, can reply it in another machine only movin the config file?
fikse has quit [(Ping timeout: 260 seconds)]
civodul has quit [(Quit: ERC (IRC client for Emacs 25.2.1))]
<tilpner>
(Nevermind, enabling three layers of safe mode makes them visible. I'll hunt down the offending setting/addon)
ison111 has quit [(Ping timeout: 260 seconds)]
zraexy has joined #nixos
<dash>
Durgeoble: yes.
<gchristensen>
Durgeoble: yeah
magnetophon has joined #nixos
ebzzry has joined #nixos
<Durgeoble>
can also zip or copy all in portable hd for quick transfer?
fractal_ has joined #nixos
<tilpner>
(Nothing interesting, Decentraleyes prevented JQuery from loading for some reason)
tnks_ has joined #nixos
<dash>
Durgeoble: sure, but ssh is easier :)
eacameron has joined #nixos
<tnks_>
does anyone here use pypi2nix?
<tnks_>
I feel something might have changed from when I last used it.
tnks_ is now known as tnks
<dash>
tnks: i do
mjacob has joined #nixos
<tnks>
dash: cool. I have a setup.py that has an executable.
<tnks>
and I ran a simple 'pypi2nix -V 2.7', which made the requirements.nix.
<tnks>
But when I do a nix-build, I just get the python interpretter, not the wrapper script.
<tnks>
am I missing something?
<hodapp>
so... nix-shell -A foo gives me a build environment in which I may build 'foo'... but what if rather than 'foo' I want a more complicated expression, or something from my ~/.nixpkgs/config.nix?
<hodapp>
I'm trying to diagnose a build problem that comes up only when 'foo' has had some things overridden
xadi has quit [(Remote host closed the connection)]
<hodapp>
just getting 'error: value is a function while a set was expected' so I'm trying other things
<hodapp>
nix-shell -E '(with import <nixpkgs> {}; let ocv3 = pkgs.python27Packages.opencv3.override { enableContrib = true; }; in pkgs.python27.withPackages (ps: [ocv3]))' works.... except that it's just doing the build, not giving the environment to do the buiild
xadi has joined #nixos
<sphalerite[m]>
Just ocv3 should do the trick, rather than pkgs.python27.with packages etc
<sphalerite[m]>
I think
<hodapp>
oh, there we go
cwo2 has quit [(Quit: Page closed)]
leat has joined #nixos
Myrl-saki has joined #nixos
drakonis has joined #nixos
Durgeoble has quit [(Ping timeout: 240 seconds)]
hiratara has quit [(Remote host closed the connection)]
hiratara has joined #nixos
<Infinisil>
I'm currently doing `du /nix/store -d 1 | sort -nr --parallel=4 | head` just for fun
<Infinisil>
Tells me what dir in /nix/store is the biggest
<Infinisil>
Yeah nope, something went wrong there
<Infinisil>
While the top folder node-sources is pretty big with 87M, I just found gcc before with 120MB
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] MP2E pushed 1 new commit to master: https://git.io/v7sFA
<tilpner>
$ du /nix/store -hd 1 | sort -hr --parallel=4 | less is more convenient IMO
* hodapp
stabs CMake and OpenCV in the face
xadi has quit [(Remote host closed the connection)]
xadi has joined #nixos
<tilpner>
(But nothing beats ncdu)
<joehh>
awesome - never knew about sort -h option
Myrl-saki has quit [(Ping timeout: 240 seconds)]
<hodapp>
graaah, 'genericBuild' is failing really early on in nix-shell and I have no idea why
<hodapp>
"file DOWNLOAD cannot open file for write." whatever that means
<Infinisil>
tilpner: I'll have a look at ncdu
<hodapp>
CMake is utter shit at conveying the actual error that failed a build
<Infinisil>
Damn, ncdu is pretty sweet
mudri`` has joined #nixos
<hodapp>
what would be different between installing/building with nix-env/nix-build, and running nix-shell -A/-E and 'genericBuild'?
<Infinisil>
Is there a filesystem that can continuously calculate the size of folders?
<Infinisil>
Seems like something one might want to have
<hodapp>
ehh, why?
<NickHu>
Sounds like a bookkeeping nightmare
mellowmaroon has joined #nixos
mellowmaroon has quit [(Client Quit)]
<Infinisil>
hodapp: To find out what uses most space and optimize/remove those parts
mudri` has quit [(Ping timeout: 248 seconds)]
<hodapp>
Infinisil: why must one calculate it continuously to do that?
<Infinisil>
hodapp: So it doesn't need to be done everytime someone asks for it
<hodapp>
it would still need to be done everytime someone asks for it
<hodapp>
it just would also need to be done everytime no one asks for it too
<Infinisil>
E.g. I just used ncdu to calculate the size of all folders of /nix/store, but when I close it and do it again it calculates all of it again
<Infinisil>
hodapp: It could work by just adding/subtracting the size of a file everytime you create/remove a file
<Infinisil>
E.g add a file in /path/to/file, fs adds size of that file to the /path and /path/to folders
<hodapp>
or change a file
<hodapp>
or move one
<Infinisil>
hodapp: Yes
<hodapp>
you'd have to be monitoring every single filesystem operation
<Infinisil>
hodapp: That's a filesystems job already
<Infinisil>
It actually implements these
<tilpner>
All writing operations, and that's probably not a terrible performance impact. I wouldn't want it on by default, but as an option... why not?
<Dezgeg>
nope, there is no operation that causes a recursive update all the way along a directory hierarchy
<Infinisil>
tilpner: Yeah as an option. E.g. enable it for this folder or so
<nh2>
how would I best combine nix-copy-closure and some nix-store invocation to copy the entire nix store to another nixos machine?
<Infinisil>
Dezgeg: That's all in the filesystems power
<hodapp>
Infinisil: "the filesystem's job" and "within the filesystem's power" aren't even remotely the same thing
<nh2>
just `ls -1 /nix/store | xargs nix-copy-closure --to mymachine`, is that the best way?
<Infinisil>
hodapp: I just meant that that's the kind of thing a filesystem could implement
<tilpner>
You would have to settle on single definition of size though, otherwise things would break with size measurements that require following symlinks
<Infinisil>
tilpner: Yeah, maybe an option when compiling it
<hodapp>
size of a file, and size of a file on disk, are also two things that frequently aren't the same
<hodapp>
hard links, symlinks, compression, and block sizes (and more complex schemes) mess with this
indi_ has joined #nixos
<Infinisil>
True
* hodapp
types 'buildPhase' and moves things away from the nearest table so that he can prepare to flip it over
<joehh>
any way around a "FATAL: kernel too old" when trying to install nix on an old debian machine?
<joehh>
other than upgrade the machine...
<hodapp>
OpenCV is the bane of my existence. I guess I could use MATLAB or Octave for things, but I sort of hate those languages.
<joehh>
Is there a reference for what version of the kernel I need?
Neo--- has joined #nixos
<Infinisil>
joehh: Doesn't look like that's something you could get around, the warning is probably there for a reason
<joehh>
yes, though I do wonder what kernel is new enough
<Infinisil>
Oh and btw, ghc is the biggest folder in /nix/store (ignoring .links) with 1GB
<Infinisil>
And I have 5 copies of GHC..
<MP2E>
hm
<MP2E>
not surprised GHC is the biggest folder, but I am surprised there are 5 of them :o
<Infinisil>
MP2E: I'll do a GC and see if it gets rid of a few
Neo-- has quit [(Ping timeout: 248 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] grahamc pushed 1 new commit to master: https://git.io/v7sAw
<NixOS_GitHub>
nixpkgs/master 72f85b9 Graham Christensen: nixos/tahoe: fixup create-introducer, syntax regression from 90acbe5
NixOS_GitHub has left #nixos []
slack1256 has quit [(Remote host closed the connection)]
<gchristensen>
cstrahan: ^ this was a correct / valid fix, yeah? I can see no reason to not quote nodedir
<tilpner>
joehh - It appears you need "GNU/Linux 2.6.32" for the current release
<tilpner>
joehh - I got that from running file on the nix-store the Nix install script will download
<sphalerite[m]>
How can I make sure a filesystem isn't mounted anywhere anymore before I mess with it (e.g. resize2fs, remove the medium)? Particularly taking into account the case of mount namespaces
<joehh>
right - I've got 2.6.26-2-686
<gchristensen>
pSub: thank you for the idea PRs :):
<gchristensen>
pSub: I'd say just merge your own PRs if nobody reviews them within a few days
<Infinisil>
sphalerite[m]: umount works with mountpoints, and you can see through the output of `mount` to see what's mounted
<tilpner>
joehh - Looks like you'll need to upgrade. If you're really desperate you could try compiling Nix locally, that might fix it
<sphalerite[m]>
Infinisil: but only for the namespace I run it in
<sphalerite[m]>
Infinisil: I want to make sure it's not mounted in any namespaces
<Infinisil>
sphalerite[m]: I honestly have no idea about namespaces, sorry
<joehh>
I reckon I can get them to do that upgrade :)
<Infinisil>
MP2E: nix-collect-garbage didn't remove any GHC..
<tilpner>
FWIW, it also didn't delete any of my 4 ghcs :/
<tilpner>
(Which are all 8.0.2?)
<MP2E>
o.O
<cstrahan>
gchristensen: I left a comment on your commit. That argument is already quoted, so leaving the quotes on effectively double quotes it.
takle has quit [(Remote host closed the connection)]
<cstrahan>
Sure thing.
<Infinisil>
MP2E: Okay, the first one iss stuck because i once tested adding a named generation, which has been stuck there for a long time, gonna remove it now
rpifan has joined #nixos
<gchristensen>
cstrahan: so just to be super sure (so I don't make _another_ fixup commit) this is right? - tahoe create-introducer "${lib.escapeShellArg nodedir}"
<cstrahan>
gchristensen: yeah, that looks good to me.
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] grahamc pushed 1 new commit to master: https://git.io/v7sx4
<NixOS_GitHub>
nixpkgs/master d4ef5ac Graham Christensen: nixos/tahoe: fixup create-introducer, syntax regression from 90acbe5, improperly patched in 72f85b9e072
NixOS_GitHub has left #nixos []
markus1199 has joined #nixos
<gchristensen>
thanks :)
ison111 has quit [(Quit: WeeChat 1.7.1)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] Ericson2314 opened pull request #27672: Quasi-hygiene for CC-wrapper (staging...cc-wrapper-elegant) https://git.io/v7sxa
NixOS_GitHub has left #nixos []
jojo_ has quit [(Quit: WeeChat 1.7)]
markus1189 has quit [(Ping timeout: 255 seconds)]
<tilpner>
Infinisil - FWIW, they share a lot of data by hard-linking, so it's not actually 4GB (just 2.1GB here)
<sphalerite[m]>
so I ended up doing `md5sum /proc/*/mountinfo | sort | uniq -c -w 32` to see which processes have different mounts than init and then checking from there if they had the block device in question mounted anywhere
Ivanych1 has joined #nixos
fresheyeball has joined #nixos
<fresheyeball>
hey out there
<fresheyeball>
when I'm using a builder.sh
<fresheyeball>
in the mkDerivation
<tilpner>
sphalerite[m] - Any idea why Firefox appears in that result?
<fresheyeball>
I'd like to use another packages output as its source
<fresheyeball>
so I write in the buildInputs
<fresheyeball>
buildInputs = [ foo ]
<fresheyeball>
and then in the script
<fresheyeball>
cp -r ${foo} work
<fresheyeball>
but now I can't do anyting in work
<Infinisil>
sphalerite[m]: Nice to know
<fresheyeball>
because permissions
<fresheyeball>
is there a propery way to base on package on another?
<tilpner>
fresheyeball - Do you need to access the files or modify them?
<fresheyeball>
modify
Ivanych has quit [(Ping timeout: 260 seconds)]
<fresheyeball>
at first I wanted to do this
taktoa has joined #nixos
<fresheyeball>
cp -r ${foo} $out
<Infinisil>
fresheyeball: Did you cd to $sourceRoot?
<fresheyeball>
no
<taktoa>
I just had a crazy idea
<taktoa>
there should be builtins.earley
nslqqq has quit [(Ping timeout: 255 seconds)]
<fresheyeball>
why would that matter though
<Infinisil>
fresheyeball: Try cd to $sourceRoot then
<fresheyeball>
I never specified an `src = ...`
<sphalerite[m]>
tilpner: probably some sandboxing feature
<fresheyeball>
Infinisil: cd /homeless-shelter: No such file or directory
<taktoa>
"Earley parsers are appealing because they can parse all context-free languages, unlike LR parsers and LL parsers, which are more typically used in compilers but which can only handle restricted classes of languages. The Earley parser executes in cubic time in the general case"
<Infinisil>
fresheyeball: Well i'm out of ideas then
<taktoa>
but linear time for almost all LR(k) grammars
Ivanych1 has quit [(Ping timeout: 268 seconds)]
<hodapp>
looking at this OpenCV build, I'm now not sure how it ever works on anything (when it comes to Python & contrib is enabled)
<dash>
taktoa: why do you want to sneak a parser generator into nix
<Infinisil>
taktoa: What do you think this can be used for?
<hodapp>
it extracts the component of the path of every single header beginning with 'opencv2/', furthest from the right... but there are a whole mess of headers that don't have this anywhere in the path
<hodapp>
so my guess is that on every other system, it just gets an incorrect path (because it finds opencv2 someplace else in the name by coincidence) but it doesn't matter
MP2E has quit [(Quit: brb)]
<taktoa>
dash: Infinisil: well we already have builtins.match
<taktoa>
for regular expressions
<taktoa>
having the ability to run an earley parser could be really useful for input validation
<taktoa>
in nixos for example we have tons of options with type "string"
<taktoa>
what if, instead, they were specified by a BNF
erictapen has quit [(Ping timeout: 240 seconds)]
<taktoa>
and the nice thing about earley is that, although it is cubic in the worst case, you can pretty much always just try to factor your grammar into an LR(k) form such that it's linear
<Infinisil>
taktoa: So we could do stuff like writing haskell programs in nix and have nix validate them?
<taktoa>
https://github.com/vnmakarov/yaep is a C++ earley parser that claims to be able to parse 300K lines of C per second, and it only allocates 5 MB for 10K lines of C
<taktoa>
Infinisil: well, yes, though haskell has a very complicated grammar
<sphalerite[m]>
So apparently cython (build-)depends on gfortran..?
erictapen has joined #nixos
rpifan has quit [(Remote host closed the connection)]
<Infinisil>
taktoa: But what's a useful usage example? Like an option or something that would turn out to be much simple/more correct
<taktoa>
Infinisil: any extraConfig-style nixos option
<taktoa>
like there's a billion configuration languages out there; if Nix really wants to subsume them all, having proper input validation is a big feature
<taktoa>
and pretty much all of them can be specified as a BNF
<Infinisil>
taktoa: Ahh right, extraConfig is a very good example
nslqqq has joined #nixos
riclima has quit [(Ping timeout: 240 seconds)]
fresheyeball has quit [(Quit: WeeChat 1.7.1)]
<sphalerite[m]>
how do I override a python package with packageOverrides?
<sphalerite[m]>
I want the change to apply to all python versions
<gchristensen>
taktoa: I'm not sure we want to subsume them all
<sphalerite[m]>
gchristensen: it would be cool though :D
<gchristensen>
seems doomed to fail though
<sphalerite[m]>
and this wouldn't really be for subsuming them, just for validating them, no?
<gchristensen>
why bother though when we can call their linter?
<Infinisil>
taktoa: But isn't this already possible by using something like `runCommand "validate" "${pkgs.myparser}/bin/myparser ${script-derivation}"`
<taktoa>
Infinisil: not without IFD
<Infinisil>
IFD?
<sphalerite[m]>
gchristensen: because we can't acll the linter at evaluation time :p
<sphalerite[m]>
failing at evaluation time is so much cooler though!
<sphalerite[m]>
:D
<gchristensen>
sure
<taktoa>
gchristensen: a lot of configuration languages don't even have linters, though
<gchristensen>
O.O
<taktoa>
they will fail at systemd unit initialization
<gchristensen>
I don't think we should solve that by adding it to nix
<sphalerite[m]>
yeah tbh adding it upstream seems like a more sensible option
<gchristensen>
I don't want to yuck your yum
<taktoa>
you say that as if there's a huge downside to having `builtins.earley`. I can't see an argument for `builtins.match` that doesn't also apply to `builtins.earley`.
<gchristensen>
go to town :P parse config in nix, it seems really neat
<taktoa>
nix is explicitly designed in a way that makes it infeasible to write an efficient Earley parser library in pure Nix
<gchristensen>
ok, do it in C++ :)
<taktoa>
that's what I was proposing :P
mudri`` has quit [(Ping timeout: 276 seconds)]
<gchristensen>
well the limitations of builtins.match can be considered a benefit
<taktoa>
now, a decent argument against what I'm proposing is that, instead of investing effort on writing BNFs for `extraArgs`-style options, we could instead just add enough options that you don't need `extraArgs` anymore.
<taktoa>
but I would argue that writing the BNF is in many cases easier, since you can be incremental about it
<gchristensen>
we'll practically always need extraArgs
mudri`` has joined #nixos
<taktoa>
I didn't mean remove extraArgs, just make it so that the end user rarely ever needs it
<taktoa>
anyway, suppose the format of extraArgs is `key = value\nkey = value\n...`. that's a really easy BNF, depending on how specific you want to be (arbitrary keys, or just a specified set? etc)