<Infinisil>
What do the people here think of backing up /nix?
<Dezgeg>
packaging the userspace part of the drivers is probably a giant pain though... but yes the lack of cpufreq in mainline is kind of a big deal
<Infinisil>
Which is almost the same as running your own local cache server actually
jtojnar has quit [(Remote host closed the connection)]
jtojnar has joined #nixos
wigust has quit [(Remote host closed the connection)]
eacameron has joined #nixos
<Infinisil>
I should actually totally back up /nix now that i think of it
<dhess>
Dezgeg: true. I'm actually only planning on using it as a compile server for aarch64, but I assume once it's working others will be interested in using the GPU.
<Drakonis[m]>
what's opinions on ostree?
fikse has quit [(Ping timeout: 240 seconds)]
<Drakonis[m]>
rfc ^
wigust has joined #nixos
endformationage has quit [(Quit: WeeChat 1.7)]
mkoenig_ has joined #nixos
<Infinisil>
Drakonis[m]: Never heard of this
eacameron has quit [(Ping timeout: 240 seconds)]
Mic92 has quit [(Ping timeout: 276 seconds)]
apeyroux_ has joined #nixos
<Infinisil>
Looks interesting
seanparsons_ has joined #nixos
mkoenig has quit [(Ping timeout: 260 seconds)]
apeyroux has quit [(Ping timeout: 260 seconds)]
seanparsons has quit [(Quit: No Ping reply in 180 seconds.)]
markus1189 has joined #nixos
<Drakonis[m]>
i know of its main developer's opinion
markus1199 has quit [(Ping timeout: 260 seconds)]
alx741 has quit [(Ping timeout: 260 seconds)]
eacameron has joined #nixos
koserge has quit [(Ping timeout: 260 seconds)]
<catern>
you know the main developer of ostree's opinion of ostree
<Drakonis[m]>
yes, lmfao
<catern>
is it positive?
<Drakonis[m]>
phone posting is awkward
<Drakonis[m]>
yes
koserge has joined #nixos
<catern>
ostree has a good approach - immutable filesystem trees and so on - but it has some bad things like still having ostrees being built from RPMs; but it's kind of unnecessary when we already have Nix IMO :)
<Infinisil>
Sounds really similar to nixos in its ideas
<catern>
it's not as radical
<Infinisil>
Yeah
<Drakonis[m]>
it inspired ostree improvements
s33se has quit [(Ping timeout: 260 seconds)]
s33se has joined #nixos
jgertm has quit [(Ping timeout: 260 seconds)]
Mic92 has joined #nixos
<Drakonis[m]>
the ostree images arent built with rpms
<Drakonis[m]>
not only
joehh has quit [(Ping timeout: 260 seconds)]
<Drakonis[m]>
they can also be layered
jgertm has joined #nixos
freusque has quit [(Ping timeout: 276 seconds)]
<Drakonis[m]>
even if nix exists, it doesnt mean the concept cant be improved
joehh has joined #nixos
* Infinisil
looks up rpm
Myrl-saki has joined #nixos
eacameron has quit [(Ping timeout: 248 seconds)]
<bennofs>
is there a cross-platform way to get the path to ld.so?
Nobabs27 has joined #nixos
<bennofs>
(cross platform = works on NixOS as well as other platforms)
eacameron has joined #nixos
<clever>
bennofs: what other platforms are you thinking of?
<bennofs>
clever: well, standard Linux distros that have ld-linux.so in /lib/ and no Nix installed
<clever>
you should still use the ld.so in nix
<bennofs>
and preferably using only standard tools, not patchelf
<clever>
otherwise, it will break things
<bennofs>
clever: I just want to run a binary explictly with $INTERPRETER binary instead of just binary, because that avoids a bug with address sanitizer
<clever>
ah, then you can probably use cat $NIX_CC/nix-support/dynamic-linker
<clever>
that variable is only set during a build that has gcc in the buildInputs
<bennofs>
in detail, address sanitizer requires some virtual memory space to be available, and using $INTERPRETER binary will load the binary using mmap thus it will end up at higher addresses and not take up the lower address space
<bennofs>
clever: well I want a solution that'll work on NixOS and other distros. Use case would be for cargo-fuzz, so it shouldn't hardcode any NixOS specific things preferably but also not just fail on NixOS
<clever>
ah
<clever>
maybe a bash if statement, if $NIX_CC is set, use it, then fall back to /lib/ld.so
<bennofs>
I don't want to contribute code that hardcodes /lib/ld-linux.so.2 that we then have to patch in NixOS :)
<bennofs>
clever: do we really want other projects to hardcode special cases for nixos? :O
<Drakonis[m]>
ostree brings those ideas to all distros, so.
eacameron has quit [(Ping timeout: 258 seconds)]
<Drakonis[m]>
dont hardcode your stuff yo
<clever>
bennofs: normall, your supposed to just run gcc, and the gcc wrapper will handle everything for you
<clever>
bennofs: so you should never have to touch the ld.so path ever
<bennofs>
perhaps I should just some rust elf library and parse the INTERP section
<bennofs>
probably the most correct & robust way
eacameron has joined #nixos
<Drakonis[m]>
catern, it does what nix does without the filesystem hacks and elf patches
jgertm has quit [(Ping timeout: 260 seconds)]
<catern>
Drakonis[m]: that's not really true
<catern>
Drakonis[m]: try looking at https://nixos.org/nix/ and tell me which of the things on the front page, ostree solves :) now admittedly ostree is cool but it's not really in the same class IMO, it's much more conservative
<Drakonis[m]>
correct me if you want
eacameron has quit [(Ping timeout: 260 seconds)]
<Infinisil>
Yeah, it doesn't seem to handle any quirks of different OS's
<Drakonis[m]>
its for linux, through and through
<Infinisil>
and packages
grantwu has joined #nixos
<catern>
versioned filesystem images are a good deployment mechanism, but you might as well build them with Nix. you can manage them with ostree, but the bulk of the work there would be done by Nix
koserge has quit [(Ping timeout: 260 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] volth opened pull request #27756: tinc: allow the daemon to write to files in /etc/tinc/${network}/hosts (master...tinc-fix) https://git.io/v7lUt
NixOS_GitHub has left #nixos []
eacameron has joined #nixos
gnuhurd has quit [(Remote host closed the connection)]
<Drakonis[m]>
it'd serve as a strong replacement to nix's generation system
<gchristensen>
I consider filesystem snapshotting to be a poor man's nix substitute
eacameron has quit [(Ping timeout: 240 seconds)]
mudri has quit [(Ping timeout: 260 seconds)]
ebzzry has joined #nixos
koserge has joined #nixos
<joepie91>
I'm a bit lost as to what OSTree would do that Nix doesn't already do, or how it would do it better
grantwu has joined #nixos
<joepie91>
the documentation is not being very informative about the technical guts, it seems
<Infinisil>
gchristensen: Considering that the nix store has no permissions, no read/write dates, filesystem snapshots are sometimes what you need
<Infinisil>
And obviously for changing data
Bradyn2000 has joined #nixos
eacameron has joined #nixos
<catern>
joepie91: it allows you to build your filesystem tree with RPM packages
<catern>
I think that's the primary benefit
<joepie91>
that's a bit vague - what does that mean?
alx741 has joined #nixos
<joepie91>
like, I understand all the words
<joepie91>
but I don't understand the semantic meaning behind the sentence
<gchristensen>
anything worth protecting shouldn't be in filesystem images in general, but injected at run time
<catern>
well... you know RPM packages install into the root filesystem. and then you just take a snapshot of the result of installing a bunch of RPM packages. and then you version those snapshots
<gchristensen>
so some sort of FS ACL isn't relevant
<gchristensen>
similarly, read dates are irrelevant in images
<catern>
(you can also call those snapshots "filesystem images")
<Drakonis[m]>
it does have package management, but it lacks the capability to build the system off a recipe, although that already exists in other forms
<clever>
gchristensen: when i was porting one of my things to nixos, i had considered making it connect into the backup framework, and having a gui to restore db snapshots
erictapen has quit [(Ping timeout: 240 seconds)]
<joepie91>
catern: that seems to have relatively little to do with RPM packages and more with FHS
<gchristensen>
sure
<clever>
gchristensen: so when nixops deploys the machine, its a fresh install, with a gui capable of restoring user-data into it
<gchristensen>
yeah that sounds really cool
<clever>
gchristensen: and it would also auto-backup all data back to that central server
jgertm has joined #nixos
<catern>
joepie91: yes, that's true, fair point
<grantwu>
catern: miao
<catern>
grantwu: hello
<joepie91>
so, as I understand it, it uses filesystem snapshots of some variety to switch between FHS trees; but in what way is that preferable over the Nix model?
<grantwu>
do the nixos-xx.xx channels work on non-nixos setups?
<gchristensen>
grantwu: they do :)
<joepie91>
it mostly just seems less flexible to me :P
<clever>
grantwu: the nixos channels wait for extra testing before they update
<clever>
grantwu: and the nixos channels wont have darwin builds of things
<clever>
nixpkgs- channels have darwin builds, but dont wait for nixos tests, so it may bork grub
<grantwu>
...I see...
<gchristensen>
grantwu: what're you looking to do?
eacameron has quit [(Ping timeout: 240 seconds)]
<clever>
the -small channels will only wait for testing, the non-small channels wait for everything to build
<catern>
Drakonis[m]: because ostree is a Red Hat thing and the only people using it currently are using it with RPM? :)
<grantwu>
I mean
<grantwu>
Yes, I know
<grantwu>
but that package, specifically the one mentioned with 3.6, was listed in nix-env -qa
<Drakonis[m]>
it can be extended to deb or nix files?
<joepie91>
catern: but you can have either pure reproducible dependencies or not have them; if you install RPM package as-is (which is going to assume a global FHS-like system) then you're already giving up on the purity / explicitness / possibly reproducability, at which point how does OSTree fulfill a similar role to Nix?
<catern>
joepie91: yes, it provides nothing in the way of reproducible dependencies
<Drakonis[m]>
nothing stops anyone from implementing the nix version
<gchristensen>
grantwu: ooh interesting!
<catern>
joepie91: it's like Docker in this way
<clever>
grantwu: nix-env -i is almost always slower, its better to use attribute paths with -iA
<joepie91>
catern: right, that was kind of my thought; it sounds more like dependency containerization than something Nix-like
<joepie91>
ie. not in the same category of things as Nix
<catern>
yeah
<grantwu>
er... okay
<grantwu>
my problem was not that it was slow, though
<clever>
grantwu: -i also causes other problems
<joepie91>
that's why I'm kind of lost about the suggestion of this in place of Nix :P
thc202 has quit [(Ping timeout: 246 seconds)]
<joepie91>
I don't see a narrative where it makes sense
<joepie91>
because they seem to be solving very different problems
<gchristensen>
clever: I think you're overwhelming a newbie :)
<bennofs>
grantwu: i think python packages are listed for all python versions, whether they are supported for the version or not
<gchristensen>
grantwu: there are actually a few things here that are going to be disappointing, but python packages when installed with nix-env aren't actually very useful because they're not in the python path. can I help you solve the problem in a different way? what are you trying to do?
gnuhurd has joined #nixos
<clever>
bennofs: hmmm, but shouldnt nix-env -qa have hidden things that fail to eval?
eacameron has quit [(Remote host closed the connection)]
kiloreux has joined #nixos
<bennofs>
clever: i
<grantwu>
gchristensen: Eheheh no, I'm quite aware of that.
<bennofs>
clever: am not sure. but yeah, probably?
<joepie91>
anyhow, time for me to go to bed
<grantwu>
This is a user facing GUI application
eacameron has joined #nixos
<Drakonis[m]>
catern, flatpak runs on it, every distro has a horse in that race
<clever>
bennofs: then how did grantwu get the name "python3.6-deluge-1.3.13" out of nix-env -qa if it doesnt install? hmmmm
<catern>
Drakonis[m]: you won't get much sympathy for flatpak here :) I consider it A Bad Idea
<bennofs>
2
<Drakonis[m]>
hah, a bad idea?
<Drakonis[m]>
how would you propose serving cross distro software?
* joepie91
considers flatpak a poorly thought out solution that is going to have significant security ramifications within the next 5 years or so
<clever>
Drakonis[m]: everybody must install nix, nix is great, all hail nix, lol
<bennofs>
clever: ah! this happens because deluge itself does not say that it only works for python2. it's caused by one of the buildinputs
<gchristensen>
clever++
<catern>
clever++
<bennofs>
clever: and the nix-env eval only checks for .name, not .buildinputs
<Infinisil>
clever: ++
<clever>
bennofs: ahh
<catern>
clever: "nix-env -qa python3.6-deluge" does indeed output "python3.6-deluge-1.3.13" on my -unstable machine too
<Drakonis[m]>
l
<Drakonis[m]>
lol
jgertm has quit [(Ping timeout: 255 seconds)]
<Infinisil>
gchristensen: Nice idea!
<joepie91>
Drakonis[m]: also, my view on this - and I suspect that of many here - is that the 'flat dependency management' model that all major distros adhere to, is fundamentally flawed and broken; and that flatpak is a band-aid on top of that that doesn't actually address the underlying problem at the root
<grantwu>
fyi, I got the 2.7 version installed before I came here
<joepie91>
Drakonis[m]: therefore, I'm more interested in widespread adoption of the Nix model (whether in the form of Nix or otherwise), than in supporting or investing effort into band-aid patches
<clever>
bennofs: yep, python36Packages.deluge.name evals but python36Packages.deluge.drvPath borks
<gchristensen>
grantwu: great bug report :) thank you!
<joepie91>
(and that's not even addressing the security implications of the flatpak model; see what's currently going on with the updated-ness of Docker images to get an idea of what I mean)
<Infinisil>
joepie91: Agreed
zraexy has joined #nixos
eacamero_ has joined #nixos
<Drakonis[m]>
flatpak isnt doing containers btw
<joepie91>
Drakonis[m]: the issue I'm talking about applies to any kind of vendored dependencies.
eacameron has quit [(Ping timeout: 260 seconds)]
<joepie91>
whether there's runtime containerization or not doesn't really matter.
<catern>
Drakonis[m]: actually Linux namespaces is indeed how flatpak handles vendoring dependencies :)
<joepie91>
(in fact, there *not* being runtime containerization can make the consequences worse)
<joepie91>
turns out, vendoring dependencies means nobody will ever update them.
<gchristensen>
we aaalmost need a #nixos-offtopic :P
<joepie91>
this has flown mostly under the radar in language ecosystems that vendor dependencies heavily (eg. Java, Go, etc.) but there's quite a lot of exploitable area there as well, that just hasn;t been explored yet, for much the same reason.
<clever>
joepie91: i think thats also part of the argument of either keeping the libs as an external .so (so end-user can update), or providing source when you staticly link (so user can rebuild and update)
<joepie91>
gchristensen: still on-topic; explaining why the Nix model is better than vendoring deps ;)
<Infinisil>
gchristensen: What do you think this diagnostics tool could be used for other than the stuff in your link?
<joepie91>
or rather, one aspect of it
<joepie91>
clever: pretty much
<gchristensen>
Infinisil: getting help on IRC
<joepie91>
anyhow, I was going to sleep :)
<Drakonis[m]>
get a offtopic channel so we can stop derailing
<Drakonis[m]>
so you can help people
<Infinisil>
gchristensen: Oh maybe putting it directly in a gist / running a nix command
<gchristensen>
Infinisil: "are you on nixos? nix? what channel? what version of that channel? do you use the daemon? do you use sandboxing?" all good questions to have answers to when trying to help someone
b has joined #nixos
<catern>
gchristensen: some other tools (homebrew and others?) have a "doctor" subcommand which tries to autosolve problems
<clever>
gchristensen: have you seen the boot diag script from ubuntu or the alsa diag scripts?
<gchristensen>
yep
<catern>
maybe you could use that name?
<gchristensen>
nix-dr would be just finee
<joepie91>
night all
<Infinisil>
gchristensen: How about a nix-shell for debugging, like catern said a doctor kinda thing
<gchristensen>
ideally it'd be shipped with nix/os by default but for now anything would be a good start
tmaekawa has joined #nixos
<Infinisil>
Even cooler: the nix shell could open a screen/tmux session on a server that other people could join and help. Not sure how do make this securely though
<clever>
gchristensen: i cant find an example right now, but the ubuntu boot diag thing would read the MBR, confirm if grub is there, then read the stage 1.5 offset (a few bytes in the MBR), confirm that stage1.5 is stll there, and go down the entire chain the hardware follows while booting
<gchristensen>
clever: wow!
<clever>
gchristensen: and running the script would just automaticaly spit out a pastebin link with a crap-ton of details
<gchristensen>
that sounds great!
<Drakonis[m]>
nix linting?
zraexy has quit [(Ping timeout: 255 seconds)]
<gchristensen>
I think these are great goals
<clever>
gchristensen: and one weird thing that caught me off guard a week ago, somebody had created a /etc/nix/nixpkgs-config.nix file, without telling me (they also forgot they had even made it)
<gchristensen>
but having a script output "this is what I have" would be a good start :P
<clever>
gchristensen: and this lead to nix-env 100% ignoring config.nix
<gchristensen>
omg yes exactly
wigust has quit [(Ping timeout: 240 seconds)]
<clever>
having a script that is aware of catches like that, and can gist the output of 'nix-instantiate -v '<nixpkgs>' -A hello' would help track down which config.nix its using
<clever>
i think another user had manualy set NIXPKGS_CONFIG and then forgot he did it
<clever>
this helps confirm, which config.nix its obeying
<clever>
gchristensen: it would also be great to gist things like config.nix and configuration.nix, BUT, those can have passwords in them, and with imports, large chunks can also be missing
<Infinisil>
That's quite a lot of files evaluated..
<clever>
gchristensen: the -v output, like 'nix-instantiate '<nixpkgs/nixos>' -A system -v' would at least list what files may be usefull, then you can ask the user to gist them
<clever>
and they can handle censorship
<gchristensen>
good idea
<gchristensen>
or just list keys of attrs present in those files
<gchristensen>
probably safe ... :)
<clever>
factorio handles its download by putting a name&pw directly into the packageOverride
<clever>
so not even config.nix can be safe
<gchristensen>
guh
<Infinisil>
It's issue #8 i believe.. private nix
<clever>
Infinisil: this is more about the config inputs, rather then the built outputs
<Infinisil>
clever: But with private nix you could just pass a private derivation as a password, eliminating having the password in the config
<clever>
Infinisil: but how was that derivation created?, i would want to reference a nix value that contains a recipe for creating it
<gchristensen>
it doesn't matter, this is the world we live in right now :P
mrcheeks has quit [(Quit: ERC (IRC client for Emacs 26.0.50))]
<clever>
gchristensen: ctrl+f the above gist for nixcfg, and youll see how i organized my systems
<gchristensen>
ohh nice
<clever>
you can also infer a lot of the contents of those files, via what gets loaded after them
<gchristensen>
would you like to curate my system?
<clever>
cacti.nix causes mariadb to get loaded
<clever>
and snmp
<clever>
and now that i look, that makes no sense at all, lol, its just a mkDerivation that copies files
<clever>
gchristensen: sure
fikse has joined #nixos
<Enzime>
if I want to install a package derivation for my local user
<Enzime>
where do I add it?
<Infinisil>
gchristensen: How is yours organized?
<Enzime>
I created a <packagename>/default.nix that works, I just need to specify somewhere to install that package
<clever>
my general design, is a tree, where each leaf is a hostname, nixcfg/amd-nixos.nix, nixcfg/laptop.nix, nixcfg/nas.nix
<clever>
those leaves then list machine specific info, and imports a more generic class, like desktop or headless
<clever>
and each class does imports of another, even more generic class, until it all meets up at core.nix
lambdamu_ has joined #nixos
<Infinisil>
Enzime: nix-env -f . -i in the directory where default.nix is
<clever>
then configuration.nix only has the bare-minimal stuff to boot and get network, and imports = [ ./nixcfg/laptop.nix ];
iyzsong has joined #nixos
<Infinisil>
clever: Why not have configuration.nix symlink to it directly?
<Enzime>
Infinisil: that feels too imperative to me
<clever>
gchristensen: ive also recently started breaking it up even further, i now have nas-hydra.nix, and mydomain.nix, which i can throw into imports to setup a certain hydra, but its self-contained enough that i could recreate that hydra faster elsewhere
<clever>
Infinisil: then i have to change files in nixcfg (which is git managed) when the uuid of /boot changes
<Enzime>
isn't there a file I could add it to so that NixOS will install it for me (similar to configuration.nix)
<clever>
Infinisil: and if i somehow wind up with 2 identical installs from the same image, they will conflict
<clever>
Enzime: where packagename is a directory in the same dir as the file containing this string
<clever>
then you can do environment.systemPackages = [ pkgs.packagename ];
<Enzime>
clever: am I putting this in my configuration.nix?
<Enzime>
is there a per-user version of configuration.nix?
lambdamu has quit [(Ping timeout: 276 seconds)]
<clever>
Enzime: yeah, but you could also do it in ~/.config/nixpkgs/config.nix, then its just { packageOverrides = pkgs: { packagename = pkgs.callPackage ./packagename {}; }; }
<clever>
Enzime: and nix-env -iA nixos.packagename
<Infinisil>
Enzime: There isn't a full user equivalent of configuration.nix, but you could use rycee[m]'s home-manager for that, which does this and it's working very nicely
<clever>
Enzime: now i can nix-env -iA nixos.mystuff, and it installs everything in the list
<clever>
Enzime: line 11 is also a previous example i gave, loading stuff not yet in nixpkgs, to then add to mystuff
<Enzime>
is it worth trying to get my package into NixPkg?
<Enzime>
it's not really that common of a utility
tmaekawa has quit [(Ping timeout: 276 seconds)]
<clever>
usually is
<Enzime>
(I may or may not be the only person who uses it)
<clever>
Enzime: this jobset is configured to checkout the latest version of toxvpn master, and the nixos-unstable-small branch of nixpkgs, and then build everything in release.nix from toxvpn
<clever>
you can see that i made a push about a month ago to toxvpn, and nixpkgs-unstable has bumped a few times, and hasnt broken anything
<catern>
does Hydra use remote-systems.conf to determine what systems it has available to build on? basically I'm asking: can I share a build farm between Hydra and remote-systems.conf?
<Enzime>
interesting that you can click buttons that look disabled on the Evaluations page
<clever>
catern: hydra uses /etc/nix/machines to find the build slaves, which nix-daemon also uses
<catern>
is there some way to make Hydra the gatekeeper and build scheduler, so it knows which machines are heavily loaded and can schedule builds intelligently?
<Enzime>
clever: that looks really nice, might try setting it up sometime
kiloreux has quit [(Ping timeout: 240 seconds)]
<clever>
catern: not that i know of
<catern>
clever: the manual refers to a file remote-systems.conf, is that something different?
<clever>
catern: where in the manual does it say that?
<catern>
clever: i'm not on NixOS unfortunately so I gotta go with creating it myself :)
<gchristensen>
f
<gchristensen>
oops
<clever>
catern: ah
<clever>
catern: i have also noticed, that if make a hydra machine a build slave, it can relay the build to one of its own slaves
<clever>
catern: but nix-daemon and hydra dont share usage stats of the slaves, so that will still double-up workload
<catern>
you mean, if you make the Hydra machine a slave of Hydra, the nix-daemon on that machine will then use distributed builds to forward the build along?
hellrazo1 has quit [(Ping timeout: 268 seconds)]
<catern>
overall I feel like I'm going to need to make a better build-farm-manager-thingy
<catern>
well, a new NIX_BUILD_HOOK anyway
<catern>
at least one that can talk to a central machine to schedule the build
<clever>
catern: hydra will ignore the build hook entirely, and initiate its own ssh connections to the machines listed in /etc/nix/machines
<catern>
lol
<clever>
catern: hydra is also capable of accepting a list of those config files, in the variable
<catern>
why does Hydra do that...
<clever>
catern: when the build is done, hydra will connect to nix-daemon over a unix socket, and import the build
<clever>
one reason, is because it accepts a list of config files
<clever>
you can have a secondary /etc/nix/machines.ec2, that is auto-populated by ec2 machines you spin up&down constantly
<clever>
and only hydra can accept a list of machines, and poll them for changes
<catern>
why doesn't Hydra just have zero knowledge of distributed builds? it could just always "build locally" and then the local nix-daemon manages sending out builds
<clever>
catern: and in the case of hydra.nixos.org, the builds NEVER land in /nix/store
<catern>
oh
<catern>
I see :)
<clever>
it streams the build inputs directly from cache.nixos.org to the slave (via ssh)
<catern>
viceversa you mean?
<clever>
and then streams the results from the slave (via ssh) to aws S3
<catern>
oh
<catern>
right
<catern>
neat
<clever>
so hydra never has io load, and never runs out of space
<catern>
does hydra have any means of accepting ad-hoc build requests?
<clever>
but also, the 'build product' links on hydra are now all broken
<clever>
the closest thing is that you can bump something to the top of the queue
<clever>
gchristensen: another common issue ive seen, is where somebody forgot to define /boot in the nixos config, so nixos just never mounts /boot on startup
<gchristensen>
yeah
<clever>
gchristensen: then grub.conf always points to an old generation, and all changes undo at every reboot
<gchristensen>
that is definitely a thing
<catern>
it does build things on the queue in parallel, right? it pops the top of the queue until it's completely busy I assume
<gchristensen>
oh _wow_ that is ugly
<clever>
gchristensen: and if you nix-collect-garbage -d, it ceases to boot!
<gchristensen>
pain.gif
<clever>
catern: the queue runner is single threaded, but will do things sorta in parallel
<clever>
catern: in a single thread, it will load a given build, compute the dep graph and what is missing, optionally check the binary cache and download pre-built stuff, and then initiate a build of a step on a slave
<clever>
catern: and only once that entire process is done, will it look back at the queue, and potentially start another build or step
<catern>
ah
<catern>
hmm
<clever>
so it might wind up downloading things from a cache with 1 thread, and ignoring build slaves for 20 minutes
kiloreux has joined #nixos
<clever>
but once it gets a few slaves going, it will keep downloading things
<gchristensen>
I'm helping someone on twitter install nixos. what does it take to tether the nix installer over usb with android for internet?
<clever>
and then be able to fire slaves more jobs, as they finish things
<clever>
gchristensen: i havent tried usb tethering yet, just used the wifi tethering
<catern>
gchristensen: USB tethering just provides a fake ethernet port I believe, I think it should Just Work?
<gchristensen>
their wifi is broken by no drivers
<catern>
thanks Linux
<clever>
gchristensen: let me grab my netbook and see...
<catern>
(er, I was genuinely thanking Linux for Just Working with USB tethering :) )
<clever>
gchristensen: step 1, the phone wont even let me turn on usb tethering until i plug in a usb cable!
<gchristensen>
:o
<clever>
gchristensen: upon flipping the switch, enp0s29f7u2 just magically appeared in "ip link"
<clever>
gchristensen: and dhcp just went to town on it, lol
<clever>
i have internet
<gchristensen>
clever: can I put up a picture of this chat including your nick? :)
Supersonic112 has quit [(Disconnected by services)]
Supersonic112_ has joined #nixos
<clever>
gchristensen: sure
Supersonic112_ is now known as Supersonic112
<gchristensen>
thank you for the help :D
<clever>
heh, was going to snap a photo of the phone+netbook tethered together
<clever>
but my phone is the camera
<gchristensen>
hehe
<pie_>
any ideas for this? LookupError: setuptools-scm was unable to detect version for '/tmp/nix-build-python3.6-asciimatics.drv-0/asciimatics-e0f1873'.
<clever>
though the tablet does have a rear cam
<Enzime>
how do people make a distinction between environment.systemPackages and user level packages?
<Enzime>
especially on a single-user system
<gchristensen>
I don't use user packages
<gchristensen>
everything is either in system packages or nix-shell (I use nix-shell a lot)
<clever>
Enzime: i use them as a "plan to watch" list
<gchristensen>
nice!
<slabity>
So wine-wow just finished installing, but I can't get it to run any 32-bit applications "Err 1359". Is there something else I need to do to my nix config?
<pie_>
slabity, well what does the error code mean? :P
<clever>
slabity: i suspect that might be a 64bit only wine
<slabity>
clever: But I set wine.build = "wineWow", so shouldn't it install both?
<clever>
not sure, i didnt look into it that much, and i was only interested in testing 64bit cross-compiled things, not gaming on both arches at once
<tilpner>
(It's listed in requirements.txt. But I've not used much Python on NixOS)
<pie_>
tilpner, i usually get a different type of error when thats been a problem so i didnt htink of that...ill try it
<pie_>
no that doesnt fix it
<tilpner>
Oh, no, your error doesn't fit that
<tilpner>
(Mine did, I must've used it wrong)
<slabity>
So the #winehq people are saying that wine64 needs to be an ELF file, but nixos makes it a bash script that executes .wine64-wrapped, which is the actual ELF file
<slabity>
Is that a bug?
fikse has quit [(Ping timeout: 240 seconds)]
<clever>
slabity: thats just how wrapProgram works on nixos, we would need to confirm if wine is trying to dlopen wine64 directly, or if its just executing wine64 as a normal app
erictapen has joined #nixos
<slabity>
According to #winehq, wine-preloader loads it to better control memory layout
<slabity>
And it does not support anything except ELF files
<clever>
ah
<clever>
then wine-preloader will need to be patched
<clever>
pkgs/misc/emulators/wine
<clever>
what does wine stand for!! lol
<Enzime>
WINE is Not (an) Emulator
<clever>
what category did nixpkgs put it into!!
<Enzime>
heh heh heh
<Enzime>
we should rename Wine to WSL
<gchristensen>
lmaoo
<Enzime>
because it's a Windows Subsystem for Linux
<Enzime>
wait...
<clever>
i have also been wondering about using WSL like wine, to run the linux nix-build, on windows
<clever>
and give nix-build access to running .exe files on the host windows
<clever>
then i can have a nix managed build of something windowsy
<clever>
without making nix "work on windows"
<pie_>
:D
<pie_>
clever, oh sh**
<pie_>
that feels so dirty but thats exacrtly the kind of thing id love to try xD
koserge has quit [(Ping timeout: 268 seconds)]
<catern>
Enzime: LSW you mean? :)
<pie_>
well i mean i vaguely remember something about nix running on cygwin? or am i mixing it up with something else..
schoppenhauer has quit [(Ping timeout: 260 seconds)]
jgertm has joined #nixos
<rodarmor>
And is it possible to set which version of python `python3` points to? When I run python3 I get python3.5, but I'd like it to be python3.6 (which is also installed)
<simpson>
$(nix-shell -p python36) for example.
<rodarmor>
Is it possible to set system-wide? (i'm on nixos)
<simpson>
Well, actually, I'm not sure if 3.6 is available yet. But if it were, that's where I'd expect it to be named.
<simpson>
No, just make sure to pull from python36Packages.
schoppenhauer has joined #nixos
<simpson>
There's no default system Python; there's just pythonPackages, which aliases python27Packages.
<et4te>
clever: that fails with the same error :/
<clever>
et4te: *looks*
<et4te>
clever: it passes the bit-extras, but whilst linking the main exe it fails. Previously it would fail at bit-extras, when gcc_s isnt specified.
<clever>
ah
<clever>
try adding extra-libraries: gcc_s to your own cabal file
<rodarmor>
simpson: 36 is def available, but I checked the man page and couldn't find anything python related, so I suspect it might not be possible to toggle system wide (since the os probably expects a particular version)
<simpson>
rodarmor: NixOS doesn't have a system Python. Really.
<clever>
rodarmor: in general, you shouldnt have things like python installed system wide, ever
kaydee has joined #nixos
<Enzime>
I feel like the only thing system wide in NixOS is /bin/sh :P
<clever>
rodarmor: you would build your program to reference a given python via an absolute path, so it just always works
<kaydee>
Hi, I was just having trouble installing NixOS and grhmc said I might be able to ask for help here.
<clever>
kaydee: what kind of problem are you having?
<simpson>
Enzime: My favorite NixOS command to show off how different it is: $ find /usr
<kaydee>
Well, I had to go through four phones to find one where the tethering worked. I don't have a physical network to patch to.
<Enzime>
simpson: $ find /nix works too :p I don't know how many people are gonna be interested in such a long dump of commands though
<Enzime>
files *
isidore has quit [(Quit: WeeChat 1.9)]
<clever>
simpson: in an odd way, android does a lot of similar things, the entire OS is based around --prefix=/system/
<simpson>
clever: Yeah.
<kaydee>
But now that I have networking, it's saying either /boot doesn't exist or if I mkdir /mnt/boot it complains its' not a a FAT EFI System Partition
<rodarmor>
clever: Maybe I'm not understanding the right way to use nixos, but I install most of my packages that I use for day-to-day use in /etc/nixos/configuration.nix. Is that not a good idea?
<simpson>
Enzime: Well, $(find /usr) should be pretty short, is the joke.
<clever>
kaydee: you need to create a boot partition of type ef00, format it to fat32, and mount it to /mnt/boot/
<kaydee>
That's non-negotiable, huh?
<clever>
rodarmor: for finished programs, thats a good place to put them, but for development stuff, i try to keep it in a shell.nix, that i can load with nix-shell
<clever>
kaydee: booting with EFI requires an ef00 partition that is fat32
<clever>
kaydee: if you dont want that, you need to boot via legacy, which means turning off the EFI options in configuration.nix
<rodarmor>
clever: Yeah, this is just for day to day use, so things like my music player, random scripts, etc. For anything which I'm developing and want a reproducible environment, I know I should use a clean environment and invoke with nix-shell
<kaydee>
I've got no problem with that.
<kaydee>
Does any other arguments change?
<clever>
kaydee: if you want legacy booting on GPT, you need to create a bios boot partition, 1mb in size, no fs, not mounted anywhere
<clever>
kaydee: and then set boot.loader.grub.device = "/dev/sda"; (the root of the drive containing that bios boot partition)
<kaydee>
Maybe I should find a different computer to do this on.
<clever>
then you dont need a dedicated /boot partition
<clever>
why?
<kaydee>
Every time I've tried that on one of these old macs I could never revert it to OSX
<clever>
ahh
<clever>
macbooks dont have a legacy boot option
<kaydee>
Like, the recovery partitions are just... persnickety.
<clever>
but also, macbooks support more then just fat32, they also allow HFS+ for /boot
<clever>
so you can use either fat32 or HFS+ for /boot, and EFI
<yegortimoshenko>
i think it's specifically vfat, not fat32, but i'm not sure
<yegortimoshenko>
vfat being a more lenient version
<yegortimoshenko>
kaydee: btw, i've just recently installed (and am currently using) NixOS on MacBook Air 13" Mid-2013
<clever>
yegortimoshenko: its also heavily firmware based, different motherboards may implement different filesystem drivers, fat32/vfat is the only required one
<clever>
yegortimoshenko: i believe apple added HFS+ to their firmware, so they could use a fs better then fat
<et4te>
clever: same error :/ hmm
<kaydee>
yegortimoshenko: Did you also have this much fun? :)
<yegortimoshenko>
HFS+ is an insane fs, vfat seems to be much better (in terms of complexity/benefits ratio)
<yegortimoshenko>
kaydee: actually, it was fine. i've built my own installation image with wireless drivers, and my drive currently has three partitions: sda1 - ef00 vfat for boot, sda2 for swap, sda3 is my main partition with zfs on it, three datasets (all use legacy mountpoints): rpool/root, rpool/config (for /etc/nixos/), rpool/home
<clever>
yegortimoshenko: one thing ive been doing on all of my zfs installs, is a dedicated dataset for /nix/
<kaydee>
You know I've never, ever actually made a fat32 disk from linux. That's just mkfs.fat, right?
<clever>
yegortimoshenko: my NAS was made before i started doing that, and now with constant churn in /nix from hydra, the snapshots keep a crap-ton of data
<clever>
kaydee: mkfs.vfat
<yegortimoshenko>
what really took a lot of time was to find kernel flags and optimizations to make it run power efficiently (my setup currently holds 10hrs+ of charge, and i have a really old battery with 65% of original capacity)
<rodarmor>
Man, I love NixOS. Being able to keep everything about my system configuration in plain-text configuration file is amazing. It's just another one of my dotfiles in git.
<clever>
yegortimoshenko: yeah, i have heard that apple has put a crap-ton of power optimization into things, and linux just kills the battery life
<yegortimoshenko>
clever: i just have rpool/root and i consider it to be a cache, so i can run `zfs destroy rpool/root`, `zfs create rpool/root`, mount everything, and then just `nixos-install`
<clever>
yegortimoshenko: ah, yeah, if you have /etc/nixos on its own set, that can work
<clever>
yegortimoshenko: on my main desktop, amd/root is only using 8gig
<yegortimoshenko>
clever: i've found all the flags to make it work! i even get quite a bit more battery life on linux, but that's probably due to my rather spartan setup (exwm, no desktop manager)
<yegortimoshenko>
kaydee: it's mkfs.vfat
indi_ has joined #nixos
<clever>
yegortimoshenko: my laptop with a half-dead battery claims 40 minutes when i unplug it
<yegortimoshenko>
don't forget to partition the drive using gdisk!
<clever>
yegortimoshenko: heh, 4gig of my / is just in /tmp!
<clever>
one is an in-progress kernel build that hung due to a make bug
<yegortimoshenko>
clever: what laptop do you use?
<clever>
an old dell d650
<clever>
core2duo processor
<clever>
that should tell you how old it is, lol
<yegortimoshenko>
cool!
<et4te>
clever: so yeah really weird, actually bits-extras causes a gcc linking error further down the line. I'm just thinking the alternative is to just use stack but then packages arent in nix cache. :/
<clever>
it only has 3gig of ram, and just opening something like an appveyor log in the browser hangs it for 5 mins
<yegortimoshenko>
my macbook has 4 gig
<clever>
et4te: what about just using cabal2nix directly on your project, and ignoring the stack.yaml ?
<yegortimoshenko>
hopefully my new laptop (probably not a macbook) will have enough ram that i won't need to have a swap partition
<et4te>
clever: you mean and manually resolve all the deps? :)
<clever>
et4te: cabal2nix does that for you, as long as everything is in hackage
<et4te>
I guess I could use a LTS as reference maybe
<et4te>
clever: can you specify a stack LTS resolver with cabal2nix?
<clever>
et4te: cabal2nix just generates a single derivation, that will be loaded via haskellPackages.callPackage ./. {};
<clever>
and it gets all of the deps via attributes in haskellPackages
indi_ has quit [()]
<yegortimoshenko>
i don't like swap... and i don't like going through trouble to encrypt it. also, zfs encryption is probably going to be merged into zfs on linux very soon.
<clever>
yegortimoshenko: for my current laptop, i put swap and zfs into lvm, then i put the lvm into luks
<clever>
yegortimoshenko: so a single luks encrypts both
<et4te>
clever: trying that now :) thanks for the tip
<yegortimoshenko>
i only encrypt swap and other than that i use gpg-agent
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 2 new commits to master: https://git.io/v7lYA
<NixOS_GitHub>
nixpkgs/master 324197e Tim Steinbach: sbt: 0.13.15 -> 0.13.16
<NixOS_GitHub>
nixpkgs/master 9ea8535 Tim Steinbach: Merge pull request #27717 from NeQuissimus/sbt_0_13_16...
NixOS_GitHub has left #nixos []
<yegortimoshenko>
meaning, i only encrypt some stuff...
<clever>
yegortimoshenko: in theory, an attacker could just mount your rootfs, and trojan your gpg binary, so it reports the passphrase to a remote server when you unlock the key
<clever>
yegortimoshenko: and then return the laptop to where they found it
<yegortimoshenko>
which is why i'm looking forward to native zfs encryption! i don't want a complex setup involving luks, lvm and zfs at the same time
<clever>
yegortimoshenko: nix has some protections against this (nix-store --verify --check-contents), which would detect any tampered files, but an attacker that is aware of nix can just update db.sqlite to account for that
<clever>
yegortimoshenko: but in either case (luks or crypted zfs), the attacker can just trojan your kernel or initrd, to do the same thing with the drive pass
<clever>
since /boot is in plaintext
<grantwu>
I mean, TPMs
<clever>
grantwu: yeah, TPM and traced boot is the only way to stop this
<yegortimoshenko>
nice attack vector, haven't thought about that.
<kaydee>
Hum. Odd.
<yegortimoshenko>
kaydee: how is it going?
<clever>
yegortimoshenko: and even if you encrypt /boot, there is a plaintext grub stage 1.5, that must be plaintext for the bios to load it
<kaydee>
It's hanging on a curl that I can complete on the other console
<clever>
yegortimoshenko: the attacker can just move up another step
<yegortimoshenko>
meaning, if someone has physical access to your machine and you don't know about it, you're screwed
<clever>
kaydee: if its building things in parallel, it may hang on something else, and the url from something that ran quickly will be the last thing displayed
<clever>
kaydee: -j makes the output almost entirely unreadable
<kaydee>
Haha.
<kaydee>
Well I mean the curl timer is going up.
<kaydee>
So it has the console.
<clever>
kaydee: the curl output from 4 different curls can be interleaved, ive seen the counter glitch between a number counting up from 4, and another counting up from 15 before
<yegortimoshenko>
kaydee: i had the same issue, it just took a while but it has eventually responded
<clever>
kaydee: and the url may be a different instance of curl, double-check "ps aux | grep curl"
<kaydee>
The reason I say it is "odd" is I dunno how healthy this old machine is.
<clever>
yegortimoshenko: a TPM in tracing mode is the only way to stop that, the bios, and every step of the boot process, must report the hash of the next binary its executing, before that binary gains control
<kaydee>
So I hope that isn't sign of a bit of hair groing out of the disk.
<clever>
yegortimoshenko: and only if those hashes get replayed to the TPM in the same order, will it unlock the key in the TPM
<clever>
yegortimoshenko: as an example, the bios will report the hash(grub), before executing grub, then grub has to report the hash(linux) + hash(initrd) + hash(kernel cmdline), before running linux
<clever>
yegortimoshenko: then linux can access the key to decrypt / and it just works
<kaydee>
Finished tho. Than you for your help, clever and yegortimoshenko.
<yegortimoshenko>
kaydee: wait! i'm preparing a gist with power saving config options :-)
<clever>
yegortimoshenko: but, there is a problem with the above, any time nixos-rebuild updates things, it breaks that chain, and you have to go thru special recovery steps to update the TPM
<clever>
its also visible in every generation of system
<yegortimoshenko>
default driver in install image doesn't work with macbook touchpads very well (if you place thumb and try to move around, it won't work unlike in macOS)
<clever>
and you can see that in these 3 generations, i didnt update my nixcfg
<clever>
so something else must have differed
<clever>
yegortimoshenko: ive also heard, that the touchpad in the macbook has 2 entirely different interfaces, it can work over both usb and i2c
<clever>
yegortimoshenko: when in the firmware/bios, it runs over usb, but once the OS boots, it switches to i2c
<kaydee>
yegortimoshenko: Ha, I can't even figure out what cord lets the fkeys turn off the plasma login screen...
<clever>
yegortimoshenko: and the OSX kernel lacks the usb drivers (or actively ignores the usb device)
<clever>
yegortimoshenko: those i2c datalines also happen to be easily damaged by corrosion from water, and OSX will refuse to respond to the touchpad when its forced into usb only mode
<clever>
which leads to linux having better driver support then darwin
<yegortimoshenko>
kaydee: i've updated the gist with xserver touchpad and graphics configs for macbooks, check it out
<Enzime>
clever: arguably it's damaged by water, so probably should get it repaired :P
<simpson>
clever: That's amazing.
<clever>
Enzime: ive also heard stories of the apple service center refusing to move the hdd when doing a "repair" (swap the entire motherboard), even though the hdd was confirmed working
<yegortimoshenko>
clever: interesting :-)
eacameron has quit [(Remote host closed the connection)]
<clever>
Enzime: so the poor user had to take it to a 3rd party repair store, to have the drive removed, apple center to replace the motherboard, then back to the 3rd party store to put the hdd back in
eacameron has joined #nixos
<clever>
because apple refuses to do "data recovery"
<Enzime>
ouuuuhc
<Enzime>
ouuuuch *
<yegortimoshenko>
macOS is very buggy these days
<Enzime>
hm?
<kaydee>
yegortimoshenko: I'm afraid I lost any link to a gist prior
<yegortimoshenko>
kaydee: what macbook do you have by the way?
eacamero_ has quit [(Ping timeout: 240 seconds)]
eacameron has joined #nixos
Nobabs27 has quit [(Quit: Leaving)]
kaydee has quit [(Ping timeout: 260 seconds)]
eacameron has quit [(Ping timeout: 240 seconds)]
eacameron has joined #nixos
eacameron has quit [(Ping timeout: 240 seconds)]
<et4te>
clever: so some deps when just using cabal2nix end up with wrong versions. I'm trying to do a hybrid approach atm which takes any package that fails from the stack2nix list and otherwise build according to nixpkgs.
zraexy has joined #nixos
<clever>
et4te: sounds like that should work until stack2nix gets fixed
<et4te>
clever: yeah, so close to getting away from cabal hell :D
<et4te>
when you see that the main exe is linking, and then fails arf :O
<clever>
et4te: i learned nix first, so i never entered cabal hell in the first place
<NixOS_GitHub>
[nixpkgs] FRidh closed pull request #27751: python36 and python35: Don't use ldconfig and speed up uuid load (staging...pythonldconfig) https://git.io/v7WHO
NixOS_GitHub has left #nixos []
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] peterhoeg pushed 1 new commit to master: https://git.io/v7lcx
<NixOS_GitHub>
nixpkgs/master e9a70cc Peter Hoeg: bundler: 1.15.1 -> 1.15.3
mkoenig_ has quit [(Remote host closed the connection)]
mkoenig has joined #nixos
proteusguy has quit [(Remote host closed the connection)]
deltasquared has joined #nixos
<joko>
Hello, I'm trying to run Dolphin (a KDE app) on xmonad and I'm getting the following error: Couldn't start kuiserver from org.kde.kuiserver.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kuiserver was not provided by any .service files")
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] Mic92 pushed 1 new commit to master: https://git.io/v7llK
<joko>
FRidh: I did add kinit, because I had the same issue
<joko>
I mean errors like that: "Unable to create io-slave. Cannot talk to klauncher: The name org.kde.klauncher5 was not provided by any .service files"
ng0 has joined #nixos
<FRidh>
the program /nix/store/2d4pzfrgs7pimzrkb5lv42afkipfzql4-plasma-workspace-5.9.4/bin/kuiserver5 is provided by plasma5.plasma-workspace
<NixOS_GitHub>
[nixpkgs] Ma27 opened pull request #27766: geogebra: make language configurable via `config.nix` (master...geogebra/allow-configuration-through-config) https://git.io/v7l0R
<NixOS_GitHub>
[nixpkgs] vcunat pushed 1 new commit to staging: https://git.io/v7l06
<NixOS_GitHub>
nixpkgs/staging ba68231 Vladimír Čunát: libpng: 1.6.30 -> 1.6.31...
NixOS_GitHub has left #nixos []
eacameron has quit [(Remote host closed the connection)]
eacameron has joined #nixos
ebzzry has quit [(Ping timeout: 268 seconds)]
ebzzry has joined #nixos
eacameron has quit [(Ping timeout: 240 seconds)]
eacameron has joined #nixos
mkoenig has quit [(Quit: Lost terminal)]
mkoenig has joined #nixos
Ivanych has quit [(Ping timeout: 260 seconds)]
mkoenig has quit [(Client Quit)]
Bradyn2000 has quit [(Ping timeout: 260 seconds)]
mkoenig has joined #nixos
eacameron has quit [(Ping timeout: 255 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] vinymeuh opened pull request #27768: srecord: runs on any flavor of Unix, not only Linux (master...fix-srecord) https://git.io/v7lET
NixOS_GitHub has left #nixos []
eacameron has joined #nixos
eacameron has quit [(Ping timeout: 260 seconds)]
stanibanani has left #nixos []
eacameron has joined #nixos
stanibanani has joined #nixos
eacameron has quit [(Ping timeout: 260 seconds)]
miefda has quit [(Ping timeout: 260 seconds)]
erictapen has joined #nixos
ixxie has quit [(Quit: Lost terminal)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] Mic92 pushed 1 new commit to master: https://git.io/v7lE5
stanibanani has quit [(Ping timeout: 240 seconds)]
miefda has joined #nixos
lesce has joined #nixos
leat has joined #nixos
<Fuuzetsu>
is nixos-upgrade not enough to update nix itself? I want a commit from middle of last year for better error message (https://github.com/NixOS/nix/pull/925) but nix is still giving me the message from before that
<Fuuzetsu>
cycle detected in the references of ‘/nix/store/cfysjf1zyvh955sy898q9h34fmkn1jkn-happy-1.19.5’ — nix-build (Nix) 1.11.13
<Fuuzetsu>
my system is running few days old nixpkgs master
<avn>
Fuuzetsu: `nixos-rebuild switch` firstly build fresh nix (from nixpkgs which you use), then build whole system with it.
<Fuuzetsu>
as far as I can tell I'm running 12 days old version…
<Fuuzetsu>
right; so I'm confused why I still have an "old" error message
erictapen has quit [(Ping timeout: 260 seconds)]
erictapen has joined #nixos
<FRidh>
Fuuzetsu: that change is in Nix master. As far as I know it hasn't been backported to 1.11.x. It's likely in the current `nixUnstable` (1.12pre).
<Fuuzetsu>
hm, interesting, didn't know about nixUnstable, let me try with that
erictapen has quit [(Remote host closed the connection)]
<Fuuzetsu>
it seems no new message either in that one ;/
<Fuuzetsu>
oh well, I'll try to figure it out without it I guess
chris_ has joined #nixos
deltasquared has quit [(Remote host closed the connection)]
<chris_>
I'm trying to install Xmobar, having a search here: https://nixos.org/nixos/packages.html shows no results. Why is this package not listed? I'm guessing it's a special haskell package? Though I'm not entirely sure what that means?
deltasquared has joined #nixos
<chris_>
Ah found the section in the readme thanks to the reddit thread..
Bradyn2000 has quit [(Remote host closed the connection)]
mudri` has joined #nixos
<Fuuzetsu>
best way to find a package is to just grep in nixpkgs tbh
<chris_>
where is nixpkgs?
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] Mic92 pushed 2 new commits to master: https://git.io/v7lgw
<deltasquared>
neeasade: you can try setting the gtk icon theme directly, IIRC there's a config file for it
mudri` has joined #nixos
<deltasquared>
mk ~/.gtkrc-2.0 contains gtk-icon-theme-name = "Arc-Dark" and the equivalent file for gtk3 (~/.config/gtk-3.0/settings.ini) contains gtk-icon-theme-name=Arc-Dark under the [Settings] section.
<neeasade>
I have it set in gtkrc-2.0
<neeasade>
but they still show as default -- I'll shot in a sec
<deltasquared>
sure you got the name right? I should point I don't use homedir-installed themes
<neeasade>
yepp am sure -- using the same name/setup carried from arch setup
stanibanani has joined #nixos
<joepie91>
hrm. what's the correct way to make shared libraries available in a nix-shell session? for development purposes
<dash>
joepie91: put them in buildInputs
<joepie91>
dash: to clarify; I'm using `nix-shell -p foo`
<joepie91>
so how would I approach that there?
<LnL>
add another -p flag :)
<dash>
joepie91: for development purposes, you'll be writing an expression
zraexy has joined #nixos
<joepie91>
I'm currently only trying to test something out, which is why I'm trying to use flags to nix-shell directly; I've already specified dependencies using -p flags, but it's still not finding eg. libXcursor despite specifying -p xorg.libXcursor
nslqqq has quit [(Quit: Leaving.)]
nslqqq has joined #nixos
<deltasquared>
joepie91: to be fair if it's that rust thing then we haven't technically ruled out stupidity elsewhere
<joepie91>
deltasquared: it is, but strace output suggests that it's correctly dealing with search paths
<deltasquared>
joepie91: mind if I have a look
nslqqq has quit [(Client Quit)]
<joepie91>
hold on
nslqqq has joined #nixos
nix-gsc-io`bot has joined #nixos
<joepie91>
I don't think nix-shell sets LD_LIBRARY_PATH at all
<simpson>
Hm, is there an existing way to get different themes into Jekyll?
erictapen has quit [(Ping timeout: 255 seconds)]
nslqqq has joined #nixos
erictapen has joined #nixos
CrazyFrog has joined #nixos
frankpf has joined #nixos
fikse has quit [(Ping timeout: 240 seconds)]
mkoenig has quit [(Ping timeout: 260 seconds)]
rpifan has quit [(Ping timeout: 276 seconds)]
deltasquared has quit [(Quit: Leaving)]
dejanr has quit [()]
dejanr has joined #nixos
<M-liberdiko>
I'm having some issues building my first nixos module: https://ptpb.pw/nKG8
<M-liberdiko>
I'm building it with "sudo bash -c 'NIX_PATH=nixpkgs=/home/bricewge/os/nixpkgs:$NIX_PATH nixos-rebuild switch'" which work fine and changing the default value of the option "fonts.fontconfig.emojione" work as expected
stanibanani has quit [(Remote host closed the connection)]
stanibanani has joined #nixos
<M-liberdiko>
However I'm unable to modify the value of this option from my configuration.nix file, here is the trace https://ptpb.pw/CQn8
<joepie91>
there we go, wrote a quick tool that spawns a nix-shell with the buildInputs in the LD_LIBRARY_PATH...
<joepie91>
Infinisil: sec, writing some docs and publishing in a moment
fikse has quit [(Ping timeout: 260 seconds)]
<CrazyFrog>
hi, In ubuntu, I sometimes source (optional)files in my shell from /usr/share. For instance, for fzf (a fuzzy finder program) to replace zsh C-R binding, I would source the file https://raw.githubusercontent.com/junegunn/fzf/master/shell/key-bindings.zsh . In nixos fzf, this file doesn't seem to be installed. Should I then download this file into my $HOME and source it from there (is that the canonical way) ? I am afraid it will run
<Infinisil>
joepie91: Haha, did you just use js because you know it well?
<joepie91>
know it well, easy to write, pretty much any library I might need readily available
<Infinisil>
Fair enough
<joepie91>
like, I'm sure you could probably do it with Nix and a Bash alias in some way, but spending 2 hours figuring out how to do that without breaking stuff vs. spending 10 minutes writing a blob of JS :)
<joepie91>
I started out in Bash, then realized that concatenating the arguments alone was going to be more complex than writing the entire thing in JS
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] rvl opened pull request #27775: fetchbower: handle packages with slashes in their name (master...bower2nix-issue-13) https://git.io/v7lKh
NixOS_GitHub has left #nixos []
<Infinisil>
joepie91: I'm actually not sure what language I'd use to write such stuff. While I may be able to use bash, it's a horrible language, but it's the only thing I can currently use on linux (A few months ago I was using OSX and programming fluently in Swift)
ambro718 has quit [(Ping timeout: 255 seconds)]
<joepie91>
I find JS to be a very good 'just works' language, so long as you stay far away from constructors and 'classes'
<Infinisil>
joepie91: I assume you're coming from web dev that you know js?
<joepie91>
not that it's without its downsides, but overall it strikes a nice balance between 'can write reliable code in it' and 'is easy to work with'
<CrazyFrog>
Infinisil: and then to find the paths of the file I would do $(which fzf)/../foo/bindings.zsh ? I will try to propose a PR
<joepie91>
Infinisil: I don't focus on any one particular area of dev
<joepie91>
like, yes, webdev is one of many things I've done :P
<joepie91>
but that's not the reason for using JS
<joepie91>
(in fact, the JS I write doesn't really look very much like the JS you'd find in the average webdev project)
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] peterhoeg closed pull request #27775: fetchbower: handle packages with slashes in their name (master...bower2nix-issue-13) https://git.io/v7lKh
NixOS_GitHub has left #nixos []
<Infinisil>
CrazyFrog: Well if you just want to get it working you can just download the file somewhere in ~ and source it from there, would be the easiest. If you wanted to fix the package, you should add some bash in installPhase that copies the files from the source to $out
<Infinisil>
joepie91: I've been wanting to get into web dev for a while now :D
<joepie91>
Infinisil: also, for added irony: I'm writing a tool in JS that generates a Nix expression to get a Rust example working
<joepie91>
Infinisil: warning ahead of time; there's a lot of hype in the webdev 'community' nowadays, insofar there's really one singular community
<joepie91>
and while tooling adoption is slowly growing, there';s still a *lot* of stuff out there that is horrible to work with, because it has no concept of modules or abstractions
<Infinisil>
joepie91: Yeah i noticed that
<joepie91>
webdev as a whole has a very low barrier of entry, which unfortunately also means there's a lot of crap to sift through
<seequ>
Am I right to assume that NixOS doesn't delete /tmp files when the system is running?
<Infinisil>
I may try out typescript, gotta have some typing
<joepie91>
Infinisil: I don't recommend typescript
<joepie91>
as far as I can tell it provides zero benefits, only drawbacks
<joepie91>
'strong typing' in and of itself isn't a desirable property; it's only really useful as a building block for other things
<seequ>
I love typescript
<joepie91>
but typescript doesn't seem to care about that part very much
<Infinisil>
seequ: It doesn't, but you can make it delete /tmp on boot by setting boot.cleanTmpDir = true;
<joepie91>
so you end up with something that's considerably less flexible than JS, and considerably harder to build abstractions with... at no clear benefit
<joepie91>
I'd rather recommend learning how to use JS "properly"; you'll find that strong/explicit typing isn't really a necessary thing in the first place
<joepie91>
with the tradeoffs it makes
<simpson>
Infinisil: I like your site; it renders correctly with JS disabled.
<Infinisil>
joepie91: Hmm, I'll keep that in mind, but I'll definitely check out typescript
<Infinisil>
simpson: xD
<seequ>
TypeScript is the only real sanity check you can have in the JS world
<joepie91>
Infinisil: at the very least start with JS before you look at typescript :)
<simpson>
Infinisil: That wasn't a joke. Rendering correctly with JS disabled is a critical concern right now.
<Infinisil>
I may not even need javascript tbh, I'll probably build a static site
<Infinisil>
Using hakyll or so
<joepie91>
seequ: aside from that being factually false (typescript is not the only thing implementing typing mechanisms for JS), it also builds on a number of questionable implicit assumptions; the most obvious of which is probably "you need sanity checks"
ixxie has joined #nixos
<joepie91>
seequ: far more important are things that make it hard to make mistakes, and explicit typing is of extremely limited value there, and there are much better options
<Infinisil>
joepie91: For example?
<joepie91>
Infinisil: re: which part of what I said?
<Infinisil>
> much better options
<seequ>
I can't be bothered to argue about this now.
<joepie91>
Infinisil: the use of abstractions, for example. the way JS is designed it's extremely easy and cheap to build abstractions, which in turn makes it very easy to modularize code, which is probably the biggest factor in preventing mistakes
erictapen has quit [(Ping timeout: 260 seconds)]
<joepie91>
the developer cost of an abstraction in JS approximates zero
<joepie91>
which means you can work with tiny composable pieces that are hard to misuse
<simpson>
joepie91: Well, there's massive misuse classes that JS can't prevent against, like confused-deputy situations.
<Infinisil>
joepie91: But are there Monads??
<joepie91>
explicit/static/strong/whatever typing only prevents a small subset of errors (mixed-up types) whereas modularized/well-abstracted code prevents multiple categories of errors, including the most common ones
Arcaelyx has joined #nixos
<simpson>
Which is why SES is a thing.
<joepie91>
simpson: example?
<simpson>
(Also because many capability-security folks decided that steering ES was going to be easier than making E popular.)
<simpson>
joepie91: Confused-deputy attacks are all about the mismatch between abstractions in-language and the actual authority which you get to wield.
<joepie91>
simpson: and in this case, the origin of that mismatch does not lie within the language.
<joepie91>
it's completely possible to design a JS-spec-compliant runtime environment that does not have these issues
mkoenig has joined #nixos
<simpson>
I don't believe you~
<Infinisil>
javascript is always a hot topic isn't it :P
<joepie91>
I mean, you're free to not believe me, but that is how it is :p
<joepie91>
unfortunately "JS" and "browser environments" get mixed up a *lot*
<simpson>
joepie91: Smarter folks than either of us have detailed what SES fixes up, but it's hard to grok what's going on from their notes: https://github.com/google/caja/wiki/SES
<joepie91>
for example, none of the web APIs have anything to do with JS as a language
<joepie91>
yet people routinely believe that eg. XHR requests are a "JS feature"
<gchristensen>
so ... what, implement JS w/out xhr?
<joepie91>
gchristensen: pretty much every runtime that isn't a browser already does that
<joepie91>
my point here is just that very few people have a clear idea of where JS stops and the execution environment (browsers, usually) starts
<simpson>
joepie91: So you'd like me to treat JS as Just Another Language which can be used to write binaries, scripts, etc. in the same vein as Perl, C, Python, etc., yes?
<joepie91>
simpson: yep, that's essentially what it is.
<simpson>
This confused deputy could have been written in JS, right?
Supersonic112_ has joined #nixos
Supersonic112 has quit [(Disconnected by services)]
<simpson>
This is a dilemma, BTW. JSYK.
Supersonic112_ is now known as Supersonic112
<joepie91>
simpson: that is runtime-dependent.
<simpson>
joepie91: You can't have it both ways! Either JS is Just Another Language and doesn't have any features that really prevent confused-deputy attacks, or it is magically not responsible for the effects which it has via its runtime, at which point we might as well exonerate every language which builds on libc, right!?
<joepie91>
simpson: how is that "both ways"? my whole point here is that JS is *just a language*, it does not mandate anything about the APIs that should be available to interact with other things, or about everything needing to exist in a single global scope, or any of the other usual sources of this problem
<simpson>
joepie91: If nothing else, read into Caja and SES; the folks working on these technologies have been very aggressive in making available all of the stuff you'd need to build capability-safe systems in (a subset of) ES5.
<joepie91>
so it *is* entirely independent on how you implement your runtime, what APIs you make available, how you allow pieces of code to interact, and so on
<joepie91>
dependent*
<simpson>
joepie91: You're dodging the question of how JS objects hold and use authority by claiming that authority is runtime-dependent.
<joepie91>
none of this is a language concern
<joepie91>
simpson: "hold and use authority"?
<gchristensen>
except simpson is developing capability safe languages where it is the language's concern
<simpson>
joepie91: "How you allow pieces of code to interact" is *totally* a language concern; it's emergent from syntax and semantics.
<gchristensen>
like how types are none of a language's concern until you encode type checking in to the language
erictapen has joined #nixos
<Infinisil>
simpson: What language are you developing?
<joepie91>
simpson: nothing stops a runtime from eg. implementing isolated execution environments for different parts of a codebase, where each environment has its own capabilities and can only interact with other environments through limited and/or validated forms of messing passing
justelex has joined #nixos
<joepie91>
simpson: so no, the language does not actively aim to specify this; it also does not specify anything that makes this an explicit problem; it is simply out of scope for the language definition
<simpson>
joepie91: "Authority" is the ability to do some certain stuff. Classically, we model authorities as stuff on the edge of our programs which are primitive and powerful.
Arcaelyx has quit [(Quit: My MacBook has gone to sleep. ZZZzzz…)]
<joepie91>
and is considered a runtime concern
<clever>
joepie91: firefox has had that for ages, the JS managing extensions and the browser itself can just violate the cross-origin policy and read any file on your system
<simpson>
In an object-capability language, we can limit authority object-by-object, not just vat-by-vat.
<joepie91>
clever: then clearly it doesn't have that...
<clever>
joepie91: and the JS in a webpage is properly sandboxed
<clever>
joepie91: but all of that is inside the same JS engine, and can share values across the border safely
<joepie91>
clever: oh, I misread what you said, nevermind.
gnuhurd has joined #nixos
<clever>
joepie91: they have also had some problems, where extension authors would leak a function reference down, that can break the sandboxing, so they have since locked down on what types can cross the border
<joepie91>
clever: Firefox only does this to a very limited degree
<joepie91>
and only for a specific subset of capabilities
<simpson>
joepie91: Most languages are like a water balloon in this way. The authority is only handled carefully at the edge of the program, and once it gets inside, it can be used anywhere. As an analogy, if you stab the water balloon, water comes out.
<joepie91>
(by necessity, because otherwise existing sites would break)
<clever>
joepie91: i have also used the firefox api to create my own custom sandboxes
<simpson>
joepie91: E, Monte, and other capability-safe languages are like sponges; they have fractal authority handling, because every object handles authority as carefully as the edge of the program. As a result, it's more like a sponge; you can stab it, and water will come out, but the structural integrity of the system isn't totally compromised.
<joepie91>
simpson: okay? but I don't understand what point you're trying to make here; the discussion was originally about strong typing vs. not strong typing, and my point was that proper use of JS abstractions prevents many more classes of errors than strong typing does, and none of what you're saying appears to have anything to do with any of that
<Infinisil>
simpson: Ahh, you're MostAwesomeDude, one more connection from GitHub people to IRC people established :D
<gchristensen>
the discussion has been about confused deputies for as long as I've been here :P
<joepie91>
and the issues you are describing apply to basically every commonly used language, more or less
<simpson>
joepie91: I started out by introducing a bug class which is well-known, well-studied, and which requires language design to mitigate.
<simpson>
Well, yes. Commonly-used languages right now aren't capability-safe. Fuck, many of them aren't even memory-safe, a necessary requirement.
<joepie91>
simpson: but how does that relate to the discussion about typing and abstractions?
<Infinisil>
Ohhh, I should really try out Rust + ecmascripten when I get into webdev
<joepie91>
emscripten* :P
<Infinisil>
ahh right
<joepie91>
ecmascript is something very different, heh
<simpson>
joepie91: There's nearly no amount of abstraction alone that will remove confused-deputy possibilities. It's hard to take a piece of JS and say, for sure, that it will only call a certain method under very specific conditions. The language doesn't help you see whether it's true, and doesn't make it easy to eliminate sideways entrances into your program's state.
<joepie91>
simpson: okay, but again, what does that have to do with the original topic?
<joepie91>
I feel like you're having a completely parallel discussion here
<gchristensen>
I don't see why "what you can do" wouldn't be part of your type
<Infinisil>
gchristensen: Idris does this with its effect system
<joepie91>
like, what you're saying is not technically wrong but I don't see the relevance
<simpson>
joepie91: You were talking about ways in which JS cannot go wrong. I brought up a way in which JS can go wrong.
<joepie91>
ok...? but how is that relevant in a discussion where I'm contrasting JS to other things that can *also* go wrong in the way you're describing
<joepie91>
?*
justelex has quit [(Quit: Konversation terminated!)]
Ph1llemann has joined #nixos
justelex has joined #nixos
<simpson>
JS is Just Another Language, and a not-particularly-great one at that.
<joepie91>
like, I'll happily have a discussion about capabilities separately at some point, but I'm trying to work out how you're relating this to the previous discussion or whether there was even any relation in the first place
<Ph1llemann>
I have a basic question regarding package configuration. The "qutebrowser" nix expression receives a "withWebEngineDefault" parameter that's false by default. I want to turn it on.
<simpson>
Imagine that JS could change to be better WRT capability theory. Now, imagine that a bunch of folks who worked on E in the 90s decided to join the ES steering committee and slowly write features from E into ES.
<Ph1llemann>
Not sure how to do that in my configuration.nix
<simpson>
joepie91: More relevantly, imagine that JS is the only language that runs on the most popular platform in the world right now, and it's a really shitty language, and we should neither deny that it is a shitty language nor be ignorant of how it is evolving~
<joepie91>
simpson: I disagree that it's a "really shitty language".
<Infinisil>
Ph1llemann: You need to put (qutebrowser.override { withWebEngineDefault = true; }) into your systemPackages
<simpson>
joepie91: I know. And that disappoints me, because you seem otherwise pretty perceptive. We are a highly totemic people and we get grumpy when our totems are not respected.
<joepie91>
simpson: it has nothing to do with that, really. I just get the impression that the only aspect you're considering is theoretical correctness / safety / etc., and that you're ignoring the practical factors (ease of use, etc.)
<Infinisil>
I heard lots about js being a pretty bad language.. And me being interested in beautiful ones like Rust + Idris (+ Swift) doesn't help :P
<joepie91>
simpson: I am well aware that there are a number of issues with JS, just as I am well aware that there are a number of issues with many other languages. that does not automatically make them "really bad"; in particular because there are often practical tradeoffs involved.
stanibanani1 has joined #nixos
<joepie91>
simpson: I just don't consider an argument about language quality convincing if it doesn't address the practical tradeoffs.
<simpson>
joepie91: Of course. That is how my POV will seem. And yet, you're championing a memory-safe language, borne out of decades of research into GCs with constant jeering from the sidelines about how GCs are only theoretically correct and that they're impractical and slow and will never be popular.
<joepie91>
simpson: those are other people's words, not mine, so I don't see how that is relevant here.
<gchristensen>
reading Monte's examples, they look easy enough
<simpson>
joepie91: Practically, one look at JS's truth table should convince you that it's possible to do better.
<gchristensen>
it doesn't seem complicated
<joepie91>
Infinisil: nearly nobody who's calling JS a 'bad language' actually knows what they are talking about; they're (most of the time) ignorant of the *actual* issues, and can only name prejudices.
<simpson>
gchristensen: Monte is Just Another Language. Except it's not even that, because it's missing some of that runtime glue that makes certain real-world effects possible. In particular, The Filesystem is a large and hard-to-do part.
<joepie91>
Infinisil: I would not put much stock in popular opinion about languages in general, really.
<joepie91>
if it's not accompanied by concrete arguments
stanibanani has quit [(Ping timeout: 255 seconds)]
<Ph1llemann>
Infinisil: Hm, it tells me the option value is not a package.
xadi has joined #nixos
justelex has quit [(Quit: Konversation terminated!)]
<joepie91>
simpson: sure; and the casting would be one of the issues with JS, but it doesn't automatically translate to 'really bad language'.
justelex has joined #nixos
<joepie91>
simpson: what?
<Ph1llemann>
The manual says override is "usually" available.
<Infinisil>
joepie91: I'll definitely check of js eventually and build my own opinion about it ;)
<Infinisil>
Ph1llemann: Hmm, hold on
<Ph1llemann>
Infinisil: Ohhh, sorry.
<simpson>
joepie91: `this`. Its behavior is worse than any other language I know of with a similar (pseudo)keyword. Also, IMO JS is bad enough that it has the fractal-of-bad-ideas effect going on, and it's easy to handwave individual sharp edges while ignoring that the entire thing is made of razor blades and mediocrity.
<Infinisil>
Ph1llemann: It works for me, what channel are you on?
<Ph1llemann>
I didn't add parens around the expression, so there were more list elements than expected :>
<Ph1llemann>
I'm sorry, I'm a nixos-n00b.
<joepie91>
simpson: `this` is quite logical, and sensible if you consider the inheritance model. nevertheless, it's poorly understood by many, because they assume it to work precisely like in other languages.
<Infinisil>
Ph1llemann: Ahh, I thought maybe I should mention the parens, it's usually a problem if you don't know about it ;)
<gchristensen>
Ph1llemann: the parens around function calls in lists always throws people for a loop :D
<joepie91>
simpson: in fact, people complaining about `this` is usually the red flag that makes me skeptical of their actual knowledge of the language.
<joepie91>
because it's something that's easy to call bad if you don't think through the technical rationale, but makes a lot of sense when you look at the rest of the language.
<gchristensen>
"it's poorly understood by many" is the part which makes me pause
<joepie91>
gchristensen: primarily an education issue, partly fueled by some poor design decisions in the past (eg. constructors)
<gchristensen>
memory management in C is "it's poorly understood by many"
<joepie91>
no, memory management in C is a very different kind of problematic
<gchristensen>
so is concurrency in languages not forcing concurrency-safe
<joepie91>
gchristensen: both of those are a case of "even if you understand it you'll still mess up"
<joepie91>
that is not true for `this`.
<Infinisil>
What's the thing about `this` in js? Is it different from e.g. java?
<joepie91>
Infinisil: `this` is bound on call time; simply put, "it's what comes before the dot when you call a function"
<clever>
Infinisil: if you store a function at this.callback, then the 'this' will be wrong when its ran
<gchristensen>
Infinisil: `this` changes depending on context
<simpson>
joepie91: Blaming people for not knowing how to use a difficult-to-use language is not going to work in the long run.
<joepie91>
which is pretty much the only way you can sanely implement self-references considering the prototypical inheritance model
<seequ>
Infinisil: It's dynamically bound to an object at call time
<Infinisil>
Ahh
<seequ>
..heh
<simpson>
Infinisil: `this` is dynamically-scoped; its value is not determined by the code around it, but by code elsewhere in the program.
<clever>
func.bind can be used to lock it in some
<joepie91>
simpson: that is not what I'm doing, and JS is not "difficult-to-use".
<gchristensen>
Infinisil: so you see a lot of "that = this;" then calling "that.foo"
<clever>
but its a pain to bind everything
<Infinisil>
Wait so I can do this = myCompletelyDifferentObject and it would mess everything up?
<joepie91>
gchristensen: that is no longer a thing, now that arrow functions exist.
<simpson>
joepie91: If it's not difficult to use, then why is so much education required to avoid writing bad/broken/buggy/exploitable code with it?
<clever>
i tend to fix it with callback.bind(this) being passed around
<gchristensen>
I mean it is still a thing at the code I'm looking at
<joepie91>
(and even before that it was a questionable hack)
<clever>
or (function () { ...}).bind(this)
<clever>
which makes a horid mess
<et4te>
clever: I got it working yesterday by the way. The fix was to remove cabal dependencies which werent being used in the exe, downgrade LTS and make base more broad (not == a specific version)
<joepie91>
simpson: because the bulk of the JS userbase comes from classically-inherited imperative languages, where the mechanics for such self-references are different, and therefore people assume that if it looks the same, and constructors kinda look like classes, it will therefore work the way they're used to.
<clever>
et4te: ah
<gchristensen>
anyway, everything is terrible, programming is hard, let's go shoppingg
<et4te>
clever: the cabal2nix route sent me straight to hell
<et4te>
:P
<joepie91>
simpson: it's a problem of assumptions and appearances, not one of language design.
<clever>
et4te: lol
bennofs has quit [(Ping timeout: 240 seconds)]
<et4te>
clever: so my conclusion is if you use a lot of the LTS libs, use LTS resolver or you will be in worlds of pain
<joepie91>
(as an aside; the late addition of arrow functions or equivalent mechanisms *was* a design failure, but one that is now rectified)
dejanr has quit [()]
<simpson>
joepie91: Dynamic scoping should not be used in language design. We learned this lesson decades ago.
<joepie91>
clever: you should be using arrow functions.
Myrl-saki has quit [(Ping timeout: 260 seconds)]
<joepie91>
[19:48] <Infinisil> Wait so I can do this = myCompletelyDifferentObject and it would mess everything up?
<joepie91>
for what definition of 'mess everything up'?
<clever>
joepie91: ive been trying to do more things in haskell now, just to avoid the mess that js and php can be :P
frankpf has joined #nixos
<Infinisil>
joepie91: If the code was assuming this would refer to this object, but I guess js devs would know that and prevent it anyways
<Infinisil>
clever: ++
frankpf has quit [(Client Quit)]
<joepie91>
Infinisil: it's not entirely clear to me what you're envisioning. `this` gets bound for each function call individually, arrow functions exempted, so changing the value that `this` points to in one place will not affect the `this` value in another function, only within the scope that you're effectively sort of 'shadowing' it
<Infinisil>
clever: Have you had a look at Idris? I feel like it's the next level Haskell
<clever>
Infinisil: ive heard of it but havent looked into it
<seequ>
Idris is obviously more painful to work with than Haskell
<Infinisil>
clever: Can really really recommend it, dependent typing is like magic. It's like learning FP for the first time all over
<joepie91>
Infinisil: mind that `foo = bar` will always just change what `foo` points to, it won't ever affect the previous value that `foo` pointed at
<joepie91>
won't ever affect the value itself, that is
<Infinisil>
joepie91: Got it
<srhb>
Infinisil: Oh, you already know it. Sorry :)
CrazyFrog has quit [(Ping timeout: 260 seconds)]
<joepie91>
Infinisil: so worst you can do by overriding `this` is breaking your own code in the same function scope further on :)
<Infinisil>
seequ: Because it's ecosystem is very limited right now?
<Infinisil>
its*
<simpson>
Infinisil: One thing from Idris I am hopeful for is the idea that we could start closing the massive gap between dependent typing as it exists, for proving mostly toy and low-level and primitive stuff, and the acceptance-testing POV that QA teams use when declaring high-level functional requirements.
<seequ>
Infinisil: Just in general being super strict and requiring to figure out a working proof in some cases
<Infinisil>
simpson: +++++++ YES
<simpson>
Idris isn't the only language in the space, but they seem to be steering in this direction.
stanibanani1 has left #nixos []
<Infinisil>
seequ: Well you don't have to, if you just specify a more general type
dejanr has joined #nixos
<Infinisil>
simpson: I dream of having types and proofs for stuff like what a browser/password manager/router e.g. should do and Idris verifying this
<Infinisil>
People would only need to prove stuff once and they could be used by anybody to build up more abstract stuff
<Infinisil>
Having a fully proven software stack has many many many benefits
<simpson>
It's all about contraction and having to trust as little code as possible.
<tilpner>
Infinisil - I put off the infinite recursion with Android Studio until now, but it just worked. Filtering paths against derivation name doesn't seem very robust, but it works!
<joepie91>
simpson: I don't really have a more polite way to say this, I'm afraid; I feel like you have a very poor understanding of the design of JS, the reasons behind it, and most importantly the practical consequences it has outside of a lab environment; and that you're primarily basing your criticism of JS off it being unlike the technically-perfect language design that you have in mind, without considering why that is or whether there may be a good reason
<joepie91>
for it. I'm also really not convinced by hand-wavy "yeah well everybody knows that X is bad" type comments that don't address the subject matter head-on.
<Infinisil>
simpson: Yeah, the compiler should be verified as well, best even to have 2 compilers by different teams
<tilpner>
Why is buildEnv not overridable though? I overlayed an overridable version now, but should it perhaps be the default?
<joepie91>
the latter referring to eg. [19:50] <simpson> joepie91: Dynamic scoping should not be used in language design. We learned this lesson decades ago.
dejanr has quit [(Client Quit)]
pie_ has quit [(Read error: Connection reset by peer)]
pie_ has joined #nixos
pie__ has joined #nixos
pie_ has quit [(Remote host closed the connection)]
<Infinisil>
tilpner: I feel like buildEnv is easy enough to not require overriding
<simpson>
joepie91: That's fine; I'm not a nice person. I feel like you suffer some strong Blub-think, that you don't understand capability theory, that you don't know that I wrote JS for years as a Web developer, and that you believe that languages are defined not by their faults, but by their features. None of this is bad, but it's disappointing because it means I failed to communicate with you.
<tilpner>
Infinisil - What do you mean? It's definitely not easy enough to remove paths from something that was built with buildEnv!
<Infinisil>
tilpner: But yes, maybe overridability would be useful
<tilpner>
I don't know the policy to making things overridable by default vs encouraging use of lib.makeOverridable buildEnv instead
<joepie91>
simpson: merely having experience with a language doesn't mean that you've either used it correctly or that you understand the design behind it; in fact, I regularly speak to people who have been writing JS for a decade and still don't understand how objects and prototypes work, for example. and I'd happily have a more in-depth discussion about language design and its tradeoffs, but I just don't get the impression that you're taking my points
<Infinisil>
tilpner: I mean that when you can easily just do let paths = [ a b c ] in buildEnv { inherit paths; } and buildEnv { paths = paths ++ [ d ]; } if you require a slightly modified one. With mkDerivation you'd have to replicate all of the phases and stuff
<joepie91>
seriously, or that you're open to the possibility of not understanding JS as well as you think.
<simpson>
joepie91: Oh, additionally, winter arrived last fall, and never left; the world cannot afford to ignore the glaring structural security problems rampant in our current software.
<Infinisil>
clever: Ahh xD. tilpner was talking about overriding a buildEnv with slightly modified paths
<clever>
Infinisil: buildEnv is just a wrapper around runCommand, which sets the pkgs env variable to be a json'd version of paths
<clever>
overrideDerivation and overrideAttrs would act on the json in pkgs, not the paths
fikse has quit [(Ping timeout: 240 seconds)]
<clever>
and .override isnt available due to how callPackage interacts with things
<clever>
i see why that can become a problem
<tilpner>
Infinisil - Yeah, maybe it's not common enough to support
<joepie91>
simpson: that is far too narrow a view of the issue, and only focusing on that will not result in secure software. if you consider real-world incidents and why they occurred, the two biggest causes of issues are 1) a lack of understanding on the *process* of building secure systems, and 2) using tools (of any kind) that require constant flawless repetition of a given action, where failing once results in a security issue.
<clever>
Infinisil: override would have to be added back in to the return value of buildEnv
<joepie91>
simpson: the former is an education issue, the latter is a partly technical issue, but also partly political/social.
<Infinisil>
clever: I'm not entirely comfortable with all the override business, I'll look into it as some point
<joepie91>
simpson: I can count on one hand the developers I've spoken to who understand what threat modelling is.
<tilpner>
clever - I was arguing for the buildEnv in nixpkgs to be something like buildEnv = lib.makeOverridable (callPackage ../build-support/buildenv { });
<joepie91>
(and I mean people who are professional developers in industry)
<clever>
tilpner: something like that, but i think it has to be done after the 2nd set of args are passed in
gustavderdrache has joined #nixos
<clever>
tilpner: callPackage already throws a makeOverridable over everything
<Infinisil>
joepie91: I've learned some threat modelling while studying CS this year :D (No deep understanding, just the basics)
treaki has joined #nixos
<simpson>
joepie91: You are soooooo close. Isn't JS a tool which, if constant flawless vigilance is not applied, can result in such fun bug classes as data exfiltration, confused deputies, etc.?
<joepie91>
Infinisil: which course is that? that's the first time I've heard of threat modelling actually being taught in any kind of formal education
<joepie91>
(which is good news)
<simpson>
joepie91: And if that's the case, isn't it worth investigating ways to structurally alter how code is written so that these bug classes aren't as easy for developers to accidentally stumble upon?
<Infinisil>
joepie91: Information Security course at ETHZ in Switzerland
<joepie91>
Infinisil: oh, ah, it was specialized in infosec? :(
<joepie91>
I was hoping it was a generic CS course
<tilpner>
clever - It does? I get attribute ‘override’ missing when removing buildEnv = lib.makeOverridable overlaySuper.buildEnv from my overlays
<joepie91>
[20:10] <simpson> joepie91: You are soooooo close. Isn't JS a tool which, if constant flawless vigilance is not applied, can result in such fun bug classes as data exfiltration, confused deputies, etc.?
<Infinisil>
joepie91: It is generic, it's part of the base courses
<joepie91>
no.
<clever>
tilpner: id have to double check the source to confirm where exactly overridable goes
<joepie91>
that doesn't mean that JS can't be misused, but it's wrong to consider JS itself a tool with such issues.
<Infinisil>
joepie91: Oh wait no, I chose Information security
<joepie91>
it's quite a bit more nuanced than that.
<joepie91>
[20:11] <simpson> joepie91: And if that's the case, isn't it worth investigating ways to structurally alter how code is written so that these bug classes aren't as easy for developers to accidentally stumble upon?
<joepie91>
investigating? absolutely
<simpson>
joepie91: Isn't C a tool which, if CFV is not applied, can result in bug classes like memory corruption and ROP-based RCE?
<simpson>
(I'm keeping "Constant Flawless Vigilance" as a meme. It's good.)
<joepie91>
but that is a far cry from declaring things "really bad languages", or claiming that some other language that solves these issues is inherently better because it solves those issues, and so on.
<clever>
simpson: another thing i recently read about, the firmware in broadcom wifi chips has buffer overflow exploits in it
<clever>
simpson: and those chips lack no-execute protections
<joepie91>
simpson: (I've been actively discouraging people from using C for quite some time now)
<Infinisil>
clever: And i do have a broadcom chip :O
<clever>
simpson: so there are now RCE problems in the wifi chip, that can occur without any user interaction
<simpson>
joepie91: So you have an intuitive idea of memory-safe languages and why they're less ungood than memory-unsafe languages. I assert (and am working up to, in a series of blog posts, if you don't want to read whitepapers) that there is a concept of *capability safety*, and that languages which possess it gain the same sort of immunity for certain bug classes.
<simpson>
clever: It is amazing how many devices just come with an ARM inside now.
<clever>
Infinisil: its less likely to happen in desktop/laptop machines, because the roles are split between the card and host driver
<clever>
but in mobile devices where power usage is important, they put everything into the wifi chip
Arcaelyx has joined #nixos
<joepie91>
simpson: I'd like to read them when completed, but so far I've not been convinced that they are the same kind of thing; primarily because memory-unsafety is inherent in the design of C no matter the execution environment, whereas that is not the case for capabilities in <nearly every major language>
<clever>
simpson: and virtually every android device uses a broadcom wifi chip
<joepie91>
simpson: and to give an example of practical tradeoffs; until recently, I had no serious recommendation to make as an alternative to C or C++ for game development.
<clever>
simpson: the more modern ones are on a pcie bus, so they can then DMA the host
<joepie91>
because of practical tradeoffs like performance, availability, cost, and so on.
<simpson>
joepie91: It seems like it at first glance, but there's lots of holes. For example, *perfect encapsulation* is difficult to get right. Some languages, like C, but also Python and Ruby, can't really encapsulate beyond namespacing. `private` is a joke in most languages which have it.
Mateon3 has joined #nixos
<simpson>
joepie91: Sure, but that doesn't mean that we have to endorse C/C++; we can instead endorse language research, or experimental new languages on an experimental basis (e.g. Carmack playing with Haskell).
Mateon2 has quit [(Ping timeout: 240 seconds)]
<joepie91>
simpson: and in the end, those practical tradeoffs matter; it doesn't really matter that you design a capability-safe language, if you cannot present a business case as to why people should start using it instead of whatever they are currently using.
<clever>
simpson, Infinisil: for desktop/laptop wifi modules, the uC will handle the wifi level packet processing, and basicaly return frames very similiar to ethernet frames to the host, which finishes the processing within the wifi driver
<joepie91>
simpson: if you cannot present the practical case, it simply won't ever leave the land of theory.
<joepie91>
and the practical effect will be close to zero.
<joepie91>
[20:17] <simpson> joepie91: Sure, but that doesn't mean that we have to endorse C/C++; we can instead endorse language research, or experimental new languages on an experimental basis (e.g. Carmack playing with Haskell).
<joepie91>
sure, but a game studio is not interested in that answer
<clever>
simpson, Infinisil: the bug i read about happens in that 2nd stage of processing, which is only done on the uC when they are wanting to avoid high cpu usage on the host
<simpson>
clever: I knew a couple guys at Google who worked on this kind of security research. It was harrowing to hear the kinds of scenarios they were contemplating.
ambro718 has joined #nixos
deep-book-gk_ has joined #nixos
<clever>
simpson: yeah, you can basically hijack any wifi chip in range, and make it spread the infection, so you now have wifi worms
<Infinisil>
clever: uC?
<joepie91>
simpson: like I said, I'm all for research and investigating alternatives; they are just not a replacement for practical solutions with tradeoffs within acceptable bounds
<clever>
Infinisil: micro controller
Mateon3 is now known as Mateon1
<clever>
Infinisil: a single-chip with cpu, ram, rom, and in this case, a wifi radio
<joepie91>
you can't realistically tell a software development company "hold off on starting your project for a few years until we've figured out capability safety"
<clever>
and it lacks no-execute bits in the cpu, so buffer overflows are worse
<simpson>
joepie91: Relatedly, E's website has this quote at the top: "We do not influence the course of events by persuading people that we are right when we make what they regard as radical proposals. Rather, we exert influence by keeping options available when something has to be done at a time of crisis." It was decades ahead of its time; capability-safe languages are only now being demanded as we enter a period of
<simpson>
time where security matters to people.
<joepie91>
no disagreement with that quote :)
<Infinisil>
joepie91: simpson: A team at ETHZ has developed a new internet architecture, actually secure routing in many ways. It has been deployed at multiple locations already. They are currently mathematically proving it from the physical routers up to the protocol
<simpson>
clever: This is the kind of thing that's going to eventually lead to open firmware at that chip level. Well, that and also ARM eating the world. Eventually it'll be cheaper to just have an ARM in there, and not a weird proprietary ISA.
<Infinisil>
simpson: Sounds really similar to what scion does
<clever>
simpson: these chips have a cortex m3 in them
<simpson>
clever: It's like that Andy Warhol quote about Coke.
fikse has joined #nixos
tmaekawa has joined #nixos
<simpson>
Infinisil: It's a different direction. SCION sounds interesting but it also sounds like a way to limp along on current trust assumptions.
<Infinisil>
simpson: What do you mean exactly?
<simpson>
Infinisil: NDN signatures are on the Data itself, not on the issuer, so they get the same sort of fractal trust that characterizes POLA systems, like Nix and Monte.
erictapen has quit [(Ping timeout: 240 seconds)]
<Ralith>
is there any way I can disable evdev entirely in X11?
<Ralith>
I have some input devices that libinput handles much better than evdev does, and I have libinput enabled, but evdev seems to be handling them anyway
<clever>
simpson: another intesting thing is how the broadcom chips deal with firmware updates
sigmundv_ has joined #nixos
<clever>
simpson: there is a rom in the chip, with the full firmware, which copies a table of function pointers to a pre-defined area of ram, and uses that to do indirect calls to everything
<clever>
simpson: firmware updates can then patch that function pointer table, to redirect anything to a variant that exists in ram
<simpson>
joepie91: Those all look like things that I've experienced in postmortems, yes.
<Infinisil>
simpson: So it's similar to IPFS, but on a deeper level?
<simpson>
Infinisil: Yep. IPFS may be trendy, and I'm glad that it's warming everybody up, but NDN is the real goal.
erictapen has joined #nixos
<Infinisil>
simpson: This sounds pretty cool then. I'm pretty sure IPFS can't take advantage of nodes being closer to each other, but NDN can very well do that (right?)
<simpson>
Yes, NDN includes routing.
<Infinisil>
simpson: So it's pretty much a fully new internet? No compatibity with the old stack?
<simpson>
It runs alongside IP, just like IPX or SCTP.
pmeunier has joined #nixos
<seequ>
Wait, what does the Qt wrapper do?
<Infinisil>
simpson: How is the state of this? Is it in use?
<Infinisil>
seequ: Not sure, but I feel like it would wrap up a QT program so it works well without having to adjust a whole bunch of stuff
<simpson>
Infinisil: There's an academic-use testbed, and my business, Matador Cloud, is R&D'ing a commercial NDN offering.
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] primeos pushed 1 new commit to master: https://git.io/v7lM8
<NixOS_GitHub>
nixpkgs/master ace11d1 Michael Weiss: android-studio: Fix the meta attributes
NixOS_GitHub has left #nixos []
<Infinisil>
simpson: Isn't it very inefficient to sign every piece of data?
<Infinisil>
And signing doesn't use anything without the receiver verifying it, which is an additional cost
<simpson>
Infinisil: Optionally, but usually only the actual Interest source will bother, because they're the only ones that care. A router might want to do this as a background process to ensure that they're not rebroadcasting invalid Data.
<clever>
simpson: sounds like a similar job to verifying source ip, to prevent spoofed sources
<Infinisil>
simpson: I'll have to read more about it, very interesting
<simpson>
clever: Yep, and unexpected Data is a lot like Martian IP packets.
takle has quit [(Remote host closed the connection)]
<dhess>
anyone here reguarly cross-compile Nix from x86-64 to arm?
lesce has quit [(Read error: Connection reset by peer)]
takle has joined #nixos
<dash>
unexpected data means a broken node, since the rule is 1 data packet is sent per interest packet
<bhipple[m]>
Hi guys, I'm trying to package a python app called cryptop, that gives a little cmdline utility for seeing your cryptocurrency portfolio.
<bhipple[m]>
I see in the python contributing guidelines it says apps should be built with buildPythonApplication and live outside python-packages.nix. Does this mean I should put it in applications/misc/cryptop?
<magnetophon1>
I have emacs.defaultEditor = true; This used to work fine, but now I get a separate server when starting "emacseditor" from the cli versus when starting from my WM. both run the same binary, as observed from htop. Any ideas how to troubleshoot further?
<magnetophon1>
globin: thanks!
<seequ>
Shoud I be using qt5.mkDerivation instead of stdenv.mkDerivation for a Qt app?
bennofs has quit [(Client Quit)]
Mateon1 has quit [(Remote host closed the connection)]
<zarel>
bhipple[m]: I notice that there's an altcoins directory, but I don't know if that's reserved for altcoins implementations only or if it's okay for clients, too
<Fuuzetsu>
it seems that if I add something to nativeBuildInputs, it _must_ have `bin` directory in it in order to get added to PATH during build; however this sucks if you're adding a package with multiple outputs and one of them is "bin" output where package.bin has binaries at top level (i.e. ${package.bin}/your_binary); what's the right way forward here? make sure the bin output actually puts things in ${package.bin}/bin/? seems wrong..
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] bhipple opened pull request #27778: pythonPackages.cryptop: init at 0.1.0 (master...feature/python-cryptop-init) https://git.io/v7ly8
NixOS_GitHub has left #nixos []
<Fuuzetsu>
grepping, it seems that's what existing packages are doing ;/
Mateon3 has joined #nixos
<gchristensen>
Fuuzetsu: a package's bin output should have a bin directory
bennofs has joined #nixos
Mateon3 has quit [(Ping timeout: 240 seconds)]
fikse has joined #nixos
Mateon2 has joined #nixos
<erictapen>
I\'m a bit frustrated with Nixops handling of SSH to None-type machines. If have a machine which is accessible by me. If I deploy from the same user, it says that permission is denied due to a wrong key, but there is no way to find out which key is actually used. Does anyone else considers this an issue and/or knows how to debug this?
bennofs has quit [(Quit: WeeChat 1.9)]
sigmundv_ has quit [(Ping timeout: 240 seconds)]
<clever>
erictapen: what happens if you try to ssh into the root user on that machine?
<clever>
line 30 changes the default search path for the private keys
<clever>
but i believe the agent will keep working
erlandsona has joined #nixos
<clever>
wait, 30 is just checking, but something else definitely adds the -i and does that
<erlandsona>
Anyone know why I'm not getting the latest version of albert? I've got 0.9 on my $PATH but I've run nix-channel --update & nix-env -f '<nixpkgs>' -irA my-profile and still have the older version?
<clever>
erictapen: what channel are you on and what version are you expecting to see?
<Fuuzetsu>
erictapen: doesn't nixops use nixbld users? in which case you have to use a key that's accessible to all of them
takle has joined #nixos
<clever>
Fuuzetsu: the ssh isnt done from nixbld users
<clever>
it will probably do builds as nixbld, but those are pure
<clever>
erictapen: and what if you do nix-env -iA master.albert
<clever>
erictapen: or rather, nix-env -iA master.my-profile
<erictapen>
clever: my machine has an ssh-agent running. As I ran ssh-add, the deployment worked. Thanks alot!
<clever>
erictapen: yep
<clever>
erictapen: i believe nixops will allow its own internal private key on the deploy, so it shouldnt need that for any future updates
tmaekawa has quit [(Quit: tmaekawa)]
<erictapen>
clever: Yeah I hope so
<erictapen>
clever: Didnt know about ssh-agent yet, good to keep that thing in mind
<clever>
erictapen: look around inside /etc/ssh/authorized_keys.d/ on the target and you should see an extra key on root
<clever>
erictapen: i use ssh agent all the time, it can do fun things like securely sharing the key between machines
<erlandsona>
WTF? clever: nix-env -iA master.albert downloads the latest version. I'm so confused.
<clever>
erictapen: '<nixpkgs>' doesnt load the nixpkgs from the master channel, it loads the first nixpkgs in $NIX_PATH
<clever>
erictapen: nix-env -iA master.foo, tells it to directly use the channel called master
<clever>
erictapen: for example, "ssh -A clever@laptop" will forward the agent, so within that remote shell, i can still make use of the agent
<clever>
erictapen: which lets me do things like access github without the remote system needing its own keypair
<erlandsona>
erictapen? Anyways, so what's a general nix-env equivalent command to nixos-rebuild switch but for a user profile? I have all my packages specified in .config/nixpkgs/config.nix
<clever>
oops
<clever>
mixing the 2 of you up a bit
<erictapen>
thanks for the help. One step further to a successfull deployment...
<erlandsona>
Hehe no worries :) I figured.
<clever>
erlandsona: you have to tell it which channel to build that profile against, nix-env -iA master.my-profile would build everything with the channel called master
<erlandsona>
Okay nuther random question. I've got some GTK apps installed that don't have themes and the default is jacked up. Any hints on how to fix the default GTK theme? Any gui configurator type of things that'll help with the config files?
<clever>
ive not messed with the themes of things much
<globin>
niksnut, ikwildrpepper: hydra just died
<clever>
globin: died?
<globin>
ah just came back \o/
<globin>
everything was 500'ing
kiloreux has joined #nixos
<Infinisil>
pinging hydra.nixos.org gives me a normal 50
<erlandsona>
Actually realized it's QT not GTK, I have them both installed because :shrug:
<clever>
error 500 means its fully responsive over tcp and icmp, and its an internal error in the server
<Infinisil>
ahh
<Infinisil>
I read 500 ping instead of 500'ing :P
<erlandsona>
clever: know anyone who is familiar with theming?
<clever>
erlandsona: nope
<erlandsona>
:/ okay
<globin>
Infinisil: came back after ~half a minute
CcxWrk has quit [(Ping timeout: 240 seconds)]
deltasquared has joined #nixos
<Biappi>
<deltasquared>
erm, did I do my colours wrong again
deltasquared has quit [(Ping timeout: 246 seconds)]
zarel has quit [(Quit: Leaving)]
<et4te>
clever: do you remember who was the other person besides me having the gcc_s problem?
justelex has quit [(Ping timeout: 260 seconds)]
<tilpner>
clever - Sorry to bring this up again, but do you see a downside to using buildEnv = lib.makeOverridable (callPackage ../build-support/buildenv { });? Should I just PR that and see if it's accepted? (callPackage makes the function that evaluates to buildEnv overridable, not buildEnv itself)
wigust has quit [(Ping timeout: 276 seconds)]
erictapen has quit [(Ping timeout: 260 seconds)]
<clever>
et4te: cant think of anybody else at the moment
<clever>
tilpner: yeah, just throw up a PR and see if others like it
wigust has joined #nixos
<tilpner>
Thanks, will do
dhess has quit [(Remote host closed the connection)]
joehh has quit [(Ping timeout: 248 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 2 new commits to openssl-1.1: https://git.io/v7lQe
<NixOS_GitHub>
nixpkgs/openssl-1.1 d71f1f9 Robin Gloster: apitrace: use default Qt5
<NixOS_GitHub>
nixpkgs/openssl-1.1 ffa1088 Robin Gloster: mariadb: fix i686 build
NixOS_GitHub has left #nixos []
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to master: https://git.io/v7lQf
<jeaye>
There was a ticket to improve Nix commands to be more like English; does anyone remember it or have a link? Searching hasn't been helping so far.
<LnL>
some of the commands are already available in nixUnstable
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] tilpner opened pull request #27780: Make buildEnv overridable (master...overridable-buildenv) https://git.io/v7lQB
NixOS_GitHub has left #nixos []
crst has joined #nixos
justelex has quit [(Client Quit)]
crst is now known as Guest47554
justelex_ has joined #nixos
<Guest47554>
Hello, how do I install python packages in nixos?
dejanr has quit [()]
<Guest47554>
I tried with the .pkgs, python27Packages.requests2
<Guest47554>
but seems I cannot import it anywhere
<Guest47554>
I want to run an script with the service.activationScripts, and I need the packages there
<Guest47554>
any idea?
<clever>
Guest47554: its usualy a bad idea to do anything complex in the activation script, and network is even worse
<tilpner>
You want to make HTTP requests during every activation?
<tilpner>
That sounds very dangerous
<clever>
the network is not yet up during activation at bootup, i helped somebody with a broken boot figure this out a montha go
<Guest47554>
I see, what about the pythonPackages ?
dejanr has joined #nixos
<Guest47554>
I'm trying to configure some APIs after the booting
erictapen has joined #nixos
<clever>
Guest47554: it may be better to use python.withPackages
<LnL>
sounds like you're trying to install and use global dependencies
<LnL>
that's not really the nix way
bkchr has joined #nixos
<Guest47554>
thanks @clever, will try that
<bkchr>
Hi, I want to build a python package that requires boost, building works, but at runtime it says that a symbol is missing. Does anyone know if python packages require some sort of magic?
justelex_ has quit [(Ping timeout: 260 seconds)]
<clever>
bkchr: LD_LIBRARY_PATH
<bkchr>
clever: How can I set that?^^
<clever>
bkchr: you need to create a bash wrapper that sets that env variable correctly, before it runs python on your code
<bkchr>
But it complains about some absolute path:
Jackneill has quit [(Remote host closed the connection)]
freusque has quit [(Quit: WeeChat 1.9)]
<joepie91>
jeaye: I'd recommend pointing out explicitly under the 'unstable' section that 'unstable' == 'master after the build passes'
bkchr has quit [(Quit: Konversation terminated!)]
<joepie91>
right now it interchangeably uses 'master' and 'unstable' and it might not be clear to all readers that they're more or less the same thing
deep-book-gk_ has joined #nixos
<jeaye>
joepie91: Noted, thanks.
mudri` has joined #nixos
deep-book-gk_ has left #nixos []
<joepie91>
jeaye: other than that, good article :)
<jeaye>
Cheers :)
justelex_ has joined #nixos
mudri has quit [(Ping timeout: 255 seconds)]
erictapen has joined #nixos
magnetophon1 has quit [(Ping timeout: 240 seconds)]
stanibanani has joined #nixos
justelex_ has quit [(Read error: Connection reset by peer)]
justelex has joined #nixos
<LnL>
there's also an option to automatically run the nix gc periodically
<joepie91>
jeaye: oh, actually, one other nitpick; you should probably add the 'private data' bit to the 'nitpicks about UX' list as well, since dealing with private data at this point is mostly undocumented and not very well-supported yewt
<joepie91>
yet *
<joepie91>
and it's a fairly significant nitpick for production systems
justelex has quit [(Read error: Connection reset by peer)]
<bhipple[m]>
Let's say I have a nixpkgs checked out an in my NIX_PATH as '<src>'. Assuming I can do `nix-build '<src>' -A foo` and `nix-repl '<src>' > :b foo` successfully, how do I do the equivalent in nix-shell?
<bhipple[m]>
I'm trying `nix-shell '<src>' -p foo`, but it can't find foo. Likewise with the -I argument instead of the named nix path
<clever>
bhipple[m]: -p always looks in <nixpkgs>
<bhipple[m]>
hmm, so I need to call my path nixpkgs instead of src?
<clever>
bhipple[m]: this will import <src>, and create a derivation directly in the args, then give you a shell suitable for building that deriation
<clever>
that is exactly what -p does behind the scenes
<bhipple[m]>
That worked, thanks clever!
<bhipple[m]>
Is there a more concise way to do that with nix-shell? I'm trying to figure out what the standard workflow I should be doing for:
<bhipple[m]>
1. Add something to nixpkgs
<bhipple[m]>
2. Test before submitting PR
<jeaye>
joepie91: Yeah, that's why I had pulled it into its own section. Might flow better if combined though.
dejanr has quit [()]
erictapen has quit [(Ping timeout: 260 seconds)]
<clever>
bhipple[m]: you can also add that entire string to a shell.nix file, then nix-shell will run it by default
<jeaye>
LnL: Thanks, I'm aware of those options, as well as the auto-optimise-store Nix option, but I like having all of that in one place, which runs together.
<joepie91>
jeaye: you could probably leave it its own section, and then briefly mention it in the nitpick list as well, with an additional note on 'private data storage' generally not really being a solved problem in NixOS yet
<LnL>
yeah those basically do the same thing but in separate jobs
<joepie91>
referencing back to the previous section
dejanr has joined #nixos
<clever>
jeaye: have you seen the latest scripts i added to my kexec trick?
<clever>
LnL: even something as simple as having it curl a url and watching the access-logs can help
<jeaye>
Making it to the big leagues.
magnetophon1 has joined #nixos
<clever>
LnL: getting such phone-home stuff to work for everybody, would require them to either setup port forwarding in a weird direction or having them rely on a 3rd party server/network
<clever>
LnL: tmate.io is one option, but you still need a way to get the url back to the user
<clever>
toxvpn would require less setup
<LnL>
it's a routed subnet so that's not a problem
<LnL>
but I couldn't use arp to figure out the ip for example
<clever>
ah
<clever>
i ran into a similar problem with racklodge
<clever>
i was using tcpdump to sniff for any packets from the mac, and stumbled upon its ipv6 link-local addr
<clever>
but that cant be routed, so you would need another machine in the broadcast segment
<LnL>
heh ipv6 to the rescue
<clever>
with racklodge, you must configure a static public ip on all machines for it to work
<clever>
dedicated hosts will get a private ip (with nat) if you try to dhcp
<clever>
virtual hosts get no ip at all
justelex_ has joined #nixos
<clever>
i had customized the kexec based on how dedicated hosts behaved, then ran it on a virtual host
<clever>
expecting it to be able to nat home
<clever>
and that reminds me, if ipv6 is available at both ends, 3rd party servers and port forwarding are entirely a non-issue
<clever>
both ends can just connect in either direction, no matter the distance
magnetophon1 has quit [(Ping timeout: 240 seconds)]
<LnL>
exactly, you don't have any of the natting problems there
<NickHu>
How would you guys go about compiling a binary for use on other distributions?
<NickHu>
Inside a FHS chroot perhaps?
<clever>
NickHu: nixpkgs has helpers to make deb and rpm packages
<gchristensen>
that is similar to how our rpm building infra works
<LnL>
building packages in VMs, isn't there a project that solves that?
frankpf has joined #nixos
<gchristensen>
is it nix?
<LnL>
yeah that's the one :D
<clever>
eeek!, almost did a 64bit nixops deploy, to a 32bit only machine!
<gchristensen>
oops
<gchristensen>
it'll fail to activate :)
<clever>
luckily, the 64bit perl in the #! of a script failed to even switch to configuration
<clever>
the kernel ignored the #! and bash tried to parse the perl
<clever>
/nix/store/grn032sshillbzn0h57ks7r4cya4mqxy-nixos-system-eeepc1-17.09pre111447.a7c8f5e419/bin/switch-to-configuration: line 3: use: command not found
<gchristensen>
lol ...
<clever>
if you try to run a +x'd script, without a #! (or with an invalid one it seems), bash will assume its a bash script
<clever>
but only if you run it from bash
<joepie91>
can't see any way that'd go wrong whatsoever!
<LnL>
interresting
<joepie91>
:P
athaller has joined #nixos
lesce has quit [(Read error: Connection reset by peer)]
<gchristensen>
so I picked up a server so old it can't parse any of my public ssh keys
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin closed pull request #27768: srecord: runs on any flavor of Unix, not only Linux (master...fix-srecord) https://git.io/v7lET
NixOS_GitHub has left #nixos []
<gchristensen>
what was the common type of ssh key in ~2005?
<gchristensen>
dsa?
simukis has quit [(Ping timeout: 260 seconds)]
<LnL>
something like a 1024 dsa I think
<clever>
gchristensen: what happens if you just run "ssh-keygen" on that server?
<clever>
i had to deal with the dell drac, and it uses activex
<gchristensen>
yeah drac is not nice
<clever>
the active-x support was also rather fractured
<gchristensen>
to be frank though, ilo isn't either... and one from 2006 is definitely not
<clever>
the remote-console only worked on win7
<clever>
the remote dvd only worked on xp
<clever>
so i had to use 2 VM's to boot nixos
lesce has joined #nixos
athaller has joined #nixos
<gchristensen>
ugh this is pain. IPMITool won't talk to it, and ssh doesn't work
magnetophon1 has joined #nixos
<globin>
gchristensen: no javaws vnc?
<clever>
gchristensen: i have mixed feelings on IPMI's, on the one hand they fix a number of problems, on the other hand, it can lead to things like https://blog.exodusintel.com/2017/07/26/broadpwn/
<gchristensen>
yeah broadpwn is not nice
<clever>
closed source firmware on a chip that can access all ram, and no way to turn it off
<gchristensen>
globin: ooh good call I'll check in to that
<joepie91>
fwiw, broadpwn was pretty much not a surprise to anybody who's been involved with hardware security for any serious amount of time :P
<joepie91>
it's all horrible
<globin>
gchristensen: that normally saves me, but probably have to try different open/oraclejre versions \o/
<globin>
gchristensen: I always pick the wrong one first..
<joepie91>
the entire embedded industry is a massive clusterfuck from a security perspective
<clever>
yeah
<joepie91>
think the average PHP app but 10 times worse...
<clever>
i once talked to a php dev that thought his mysql framework was automatically escaping all strings because he used prepared queries
<clever>
he was preparing a query like "select * from foo where bar = '$bar'"
<joepie91>
so far hardware has remained relatively untargeted because software is cheaper to exploit at scale, but realistically, once the big classes of security vulns start getting wiped out in software... embedded hardware will certainly be next
<LnL>
clever: lol
<clever>
joepie91: i found an sql injection problem in the login page, "1 or 2" was enough to make it ignore the password
<joepie91>
oh yeah, that's a familiar one
<sauyon>
but will embedded hardware even exist at that point
<sauyon>
or will everything just be an ARM chip running linux
<joepie91>
sauyon: "ARM chip running Linux" is mostly the low-volume / high-interaction stuff
<joepie91>
embedded stuff is muuuuuch cheaper to produce at scale
<joepie91>
and probably will remain so for the foreseeable future
<joepie91>
so $randomStartup will slap an ARM chip on it, sure
<joepie91>
but that won't be the case for your router
<joepie91>
it may have an ARM chip but certainly not a standard Linux distro
<clever>
joepie91: look at the image to see what that will result in
<sauyon>
no it would be the best, obviously
<joepie91>
clever: heh
hiratara has quit [(Ping timeout: 240 seconds)]
fikse has quit [(Ping timeout: 260 seconds)]
hiratara has joined #nixos
<clever>
joepie91: though thinking about it, only devices with a screen or speaker can demand a ransom, everything else will just partitipate in a ddos, or spy on you
<joepie91>
clever: nah, multi-stage ransomware
<sauyon>
no they'll just all run webservers
<joepie91>
it'll just send notifications to the laptop on the same network
<joepie91>
:p
<sauyon>
and require you to install their own app
<clever>
ah, if i can get control of one device, it will be behind your firewall, and can further exploit other devices
<joepie91>
doesn't even have to be exploiting
<joepie91>
for that scenario
<joepie91>
there's a bunch of shit that accepts notifications from any device on a local network
<joepie91>
harmless from a security perspective
<joepie91>
but a great way to demand a ransom on a screenless device
<clever>
yeah
<clever>
and also phish
<joepie91>
clever: bonus points for printing out the ransom
<joepie91>
because ~network printers~
<clever>
lol
<joepie91>
and let's be realistic, who secures their printer
<sauyon>
that would actually be so easy
<joepie91>
oh yes
<joepie91>
sauyon: in fact, there was a printer exploitation talk at a conference I went to
<joepie91>
some trick to kick a network printer off the network and impersonate it
<sauyon>
"exploitation"
<joepie91>
and steal print jobs
<clever>
joepie91: ive also seen a thing on facebook, about a neighbor that left the printer wifi unsecured
<sauyon>
oh lol
<joepie91>
surprisingly effecftive
<clever>
joepie91: it then printed out a page saying it was possessed
<joepie91>
demo'd live on stage :)
<clever>
joepie91: the guy now has a free printer
<sauyon>
nobody knows
<sauyon>
how to secure their printer net
<joepie91>
clever: ha
<clever>
the idiot just threw out the "possessed" printer
<joepie91>
sauyon: conference in question was squatconf btw, although I believe he's done the same talk elsewhere
<sauyon>
might see if I can find it
<joepie91>
it was something with "stealing your boss' print job" or so
<joepie91>
as a title
<clever>
i also saw another thing about printers and security
<clever>
somebody was using RDP to proxy himself thru a company network, 100 RDP sessions deep
gnuhurd has quit [(Remote host closed the connection)]
<sauyon>
nice
<clever>
what he didnt know, is that RDP forwards your printer and shares it back to your host
<clever>
and that printer persists, and has your username
gnuhurd has joined #nixos
<sauyon>
oh I remember that
<clever>
so his windows username was left behind in every single machine
<joepie91>
clever: ah yes, I remember that one!
<joepie91>
really good way to get arrested
<joepie91>
lol
<LnL>
a few years ago there also was a talk about using the ram of random unsecure printers as a distributed storage network :p
<sauyon>
that sounds like a great idea
<joepie91>
I think I might've seen that one too
<clever>
i also heard about some networks using proper radius on the network, so every single device must have a signed cert, even at the ethernet level
<clever>
oh, the printer doesnt support it, lets just add an exception for that mac!
<joepie91>
lol
<joepie91>
I was going to say
<clever>
oh look, a mac that doesnt need radius, let me spoof
<joepie91>
I don't believe anybody actually has that
<joepie91>
a properly secured network, that is
<joepie91>
everybody's network is just varying degrees of broken
<clever>
last week, i had to fix a severely broken network
<joepie91>
clever: honestly the 'right' solution there is to put an rpi in front of the printer
<joepie91>
:p
<clever>
the port forward for ssh went to a machine that relied on dhcp, but the dhcp server was down
<clever>
the only thing open, was vnc to a xen vm running windows, with broken network config
<clever>
from there, i had to configure a static ip, then get into the router, and adjust the port forwards
<clever>
which let me get into the xen host
<clever>
then i was able to just services.dhcp.enable = true; and the problem went away
<joepie91>
clever: ah, the network equivalent of crawling through the vents in the toilet
<joepie91>
to get to the locked-out room
<clever>
yeah
<joepie91>
fun :P
<clever>
joepie91: but if i have physical access to the printer, i can just plug my laptop into the rpi, and spoof the mac
jtojnar has quit [(Quit: jtojnar)]
Filystyn has quit [(Quit: Konversation terminated!)]
<joepie91>
sure, but once you have physical access you're pretty much done anyway
jtojnar has joined #nixos
<joepie91>
because at that point you can also just dump the key from the printer
<joepie91>
that it uses to auth
<joepie91>
assuming it supports radius
<clever>
although, if you ignored the network abilities of the printer
jtojnar has quit [(Client Quit)]
<joepie91>
once physical attacks come into the picture...
<clever>
and you USB'd the printer to the rpi, and ran cups on the rpi
<joepie91>
well yeah that's what I meant
<joepie91>
printer wouldn't directly be on the network
<clever>
yeah
<joepie91>
the pi would just act as its network card, basically
<clever>
but now you need an enterprise sized printer, that isnt network capable
<joepie91>
or rather as a network-to-USB interface
<clever>
i think things at that scale are network only
<joepie91>
really?
jtojnar has joined #nixos
<clever>
thats just my general feel of that group
<joepie91>
clever: surely there's some government regulation model that can do airgapped?
jtojnar has quit [(Client Quit)]
<joepie91>
I mean, I can imagine highly sensitive organizations wanting a model that intentionally doesn't do network
<DavidEGr1yson>
I found a poor-man's way to do propagated build inputs for pkg-config packages: if A depends on B, make sure A's lib/pkgconfig directory has a symbolic link (or just a copy) of the .pc files from B's lib/pkgconfig directory. (Working on https://github.com/DavidEGrayson/nixcrpkgs )
DavidEGr1yson is now known as DavidEGrayson
<clever>
Enzime: .override changes the arguments callPackage can pass to a file
<clever>
Enzime: pkgs/development/python-modules/pandas/default.nix doesnt expect to receive an argument called name
<clever>
DavidEGrayson: ah, that will probably work
<Enzime>
clever: I assume the snippet was from a different time
<Enzime>
many years and years ago and no one has updated it
<clever>
Enzime: git log says that panda has never taken name as an input
<Enzime>
clever: so why is it in the manual :P
<clever>
the author probably got override and overrideDerivation mixed up
<clever>
and nobody ever tested the example
<Enzime>
it confused the fuck out of me yesterday cause I didn't understand why it wasn't working :(
<DavidEGrayson>
clever: Yep, it seems too. Perhaps an advantage of the symlink is that the garbage collector knows about it.
<clever>
DavidEGrayson: yeah
Neo-- has quit [(Ping timeout: 240 seconds)]
<pie__>
clever, hm. i ran the thing and no errors but the executable doesnt show up in path
<clever>
pie__: which thing did you run?
<pie__>
<clever> pie__: with import <nixpkgs>{}; callPackage ./path/to/default.nix {}
<gchristensen>
lol okay yeah ipxe took >10min to make 0% progress on tftp, and about 5s on http
<gchristensen>
niice
<clever>
see what i did with boot.php on line 10 of the dhcp conf?
<gchristensen>
hmmm what does that do?
<clever>
it causes ipxe to insert its own mac into the url, when loading boot.php
<clever>
which is also included in the gist
<gchristensen>
ooh nice
<clever>
boot.php then uses a simple switch statement to sent a hard-coded ipxe script
<clever>
but you can easily add a database to it
<clever>
one system boots nixos over iscsi
<clever>
if the version string is empty, its virtualbox, so it chainloads a better ipxe
<gchristensen>
nice.
<clever>
and then it chainloads the script from nixos netboot
<clever>
which is also in the gist, and slightly modified to have justdoit pre-installed (an older version)
<clever>
gchristensen: with a bit of tweaking, you could double-check that the system is scheduled to nuke itself (store the mac in a db queue), then just serve it the url to a netboot build setup to run justdoit on bootup
<clever>
and once that boots, it can phone-home, and register itself as installed, to de-queue the self-nuke, and make it available for nixops usage
civodul has quit [(Remote host closed the connection)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] 8573 opened pull request #27783: fd: init at 2.0.0 (master...8573/pkg/add/rust/fd-sharkdp/1) https://git.io/v7lpV
NixOS_GitHub has left #nixos []
slack1256 has quit [(Remote host closed the connection)]
<clever>
gchristensen: found an oddity in grubs support of xfs
<clever>
gchristensen: when /boot is on the same fs as /, grub has to navigate the horrors of /nix/store to find kernels, and spits out many warnings about invalid inodes
<clever>
boot.loader.grub.copyKernels silences the warnings
<Dezgeg>
it's pretty annoying indeed, I have it on one machine
<clever>
ive also heard that it has the same issue with zfs
<Dezgeg>
would be useful to capture a clone with xfs_copy and test out with the grub userspace tools to debug what's wrong
<clever>
clever is not in the sudoers file. This incident will be reported.
<clever>
and this keeps happening
<clever>
i somehow keep loosing the wheel group
<clever>
re-running nixops deploy results in no change to /run/current-system, so its not the host rolling back by mistake