<dhess`>
how well is Docker support working in NixOS these days? Last I looked, it couldn't work with the new registry or something like that
<tilpner>
I've not had any problems with Docker
<dhess`>
I'd like to run a Mastodon instance and it seems like Docker's the best way to do that on NixOS for now
<tilpner>
(Not NixOS related ones, at least)
<dhess`>
tilpner: can you install Docker images using a derivation, so that's it's all declarative and whatnot?
<fresheyeball>
dhess`: tilpner: Docker works well
<tilpner>
There is some support for building Docker images with Nix, but some of that was broken last time I tried. I was only referring to using Docker without Nix, but on NixOS. The nixpkgs support for building Docker images seems dubious
<fresheyeball>
it works well on nixos
<fresheyeball>
and you can build docker images with nix
<fresheyeball>
but you can't pull in base images right now
<fresheyeball>
DockerTools.pullImage function needs to be fixed
<tilpner>
Yeah, pulling is broken, which makes it useless for migrating existing Dockerfiles
<fresheyeball>
but it doesn't get much use anyway
<dhess`>
hmm, pulling existing images was the whole reason for using it, in my case.
<dhess`>
I guess I could try to replicate how the Mastodon base image is built.
s33se_ has joined #nixos
<fresheyeball>
dhess`: you can pull images with just normal docker
<fresheyeball>
and use normal docker on nixos
<fresheyeball>
but generally, you might consider writing the images you used to consider base images with nix
mbrgm has quit [(Ping timeout: 260 seconds)]
mbrgm has joined #nixos
s33se has quit [(Ping timeout: 255 seconds)]
andyshinn has quit [(Quit: Connection closed for inactivity)]
<dhess`>
fresheyeball: I'm using NixOps to deploy everything under the sun, would like to keep it that way, rather than mixing it with manual Docker stuff :)
<tilpner>
It doesn't have to be manual, you could create services that build from Dockerfiles, etc.
<dhess`>
tilpner: as in, the buildPhase of the derivation runs Docker commands, etc.?
<tilpner>
Oh, I didn't think of that. Maybe that'll work too. I was talking of creating a systemd oneshot service that builds your images once, but you don't get any Nix goodies that way
<tilpner>
Last time I talked about this, someone suggested using an alternative program to pull images and writing my own pullImage function, but then I didn't do that for some reason
<dhess`>
I mean normally I wouldn't go near Docker. It's just that, in the case of Mastodon, which runs several different services and is a bear to package (see open Github issue), I figured Docker would be easier.
eacameron has quit [(Remote host closed the connection)]
<dhess`>
but I also want to manage it all from NixOps. Anyway, I think I'll just keep kicking the can down the road until either Nix can pull Docker images or someone is masochistic enough to package Mastodon.
hellrazo1 has joined #nixos
hellrazor has quit [(Ping timeout: 240 seconds)]
romildo has quit [(Quit: Leaving)]
radvendii has joined #nixos
justelex has joined #nixos
Supersonic112 has quit [(Disconnected by services)]
Supersonic112_ has joined #nixos
Supersonic112_ is now known as Supersonic112
eacameron has joined #nixos
justelex_ has quit [(Ping timeout: 240 seconds)]
lesce has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] joelthompson opened pull request #27700: exhibitor: Fix bug with automatic instance management (master...exhibitor) https://git.io/v7nhf
NixOS_GitHub has left #nixos []
sary has quit [(Ping timeout: 276 seconds)]
lesce has quit [(Ping timeout: 240 seconds)]
sary has joined #nixos
eacameron has quit [(Remote host closed the connection)]
<mbrock>
dhess`: it's just launching Docker in the regular way, so there's very little actual integration with Nix in terms of reproducibility and so on
newhoggy has joined #nixos
<mbrock>
dhess`: but for just keeping some Docker services running, it's pretty handy
<mbrock>
that file is made to be imported in this way:
<NixOS_GitHub>
[nixpkgs] ocharles pushed 1 new commit to master: https://git.io/v7cgv
<NixOS_GitHub>
nixpkgs/master 11e1330 Ollie Charles: ephemeralpg: init at 2.2
NixOS_GitHub has left #nixos []
<gchristensen>
the os you'll be using in 5 yearS?
<gchristensen>
I said I'm not sure why you'll wait 5 years :P
magnicida has quit [(Ping timeout: 240 seconds)]
<joepie91>
gchristensen: honestly I think 5 years is not an unrealistic timeframe, all things considered
<gchristensen>
the problem with 5 years is if next year you're still saying 5 years
<ikwildrpepper>
gchristensen: we said 5 years 10 years ago
<ikwildrpepper>
:p
<goibhniu>
The OS I'll still be using in 5 years :D
<gchristensen>
exactly
<ocharles>
The OS I'll still be contributing to in 5 years ;)
<ikwildrpepper>
ocharles: nice, will hold you to that
<ocharles>
haha
<ocharles>
I mean at my current rate I'm commiting once every 5 years, so it's not out of the question ;)
<gchristensen>
the number "5" is just made up and without a goal and plan there is nothing to back it up with
* goibhniu
skipped forward to the "what nix is missing slide": Widespread package support, more intuitive tooling, documentation, guides and tutorials
jtojnar has quit [(Quit: jtojnar)]
<gchristensen>
calling all joepie91's calling all joepie91's
<joepie91>
gchristensen: hmm? :P
<joepie91>
also, just finished watching that, not a bad presentation for a 10 min slot
<gchristensen>
yeah
iyzsong has joined #nixos
<joepie91>
also, to expand a bit more on the 'not an unrealistic timeframe' thing; provided an active effort to improve the UX (mainly docs + tooling availability and intuitiveness), it's pretty realistic to expect mass adoption in 5 years
<gchristensen>
yeah already do a lot of incredible work, if we all worked in the same direction who knows what we could do
newhoggy has quit [(Remote host closed the connection)]
<joepie91>
gchristensen: fwiw, this is something I'm working on; producing tooling to allow a more focused usability improvement effort; the exact shape of that tooling is not very strictly defined yet, but eg. the Nix parser I'm writing is a part of that
<gchristensen>
cool :)
<joepie91>
and I've already been doing a bunch of work in assessing interest in stuff like NixOS by The Average Developer, and what the roadblocks are, etc.
<joepie91>
nothing coherent enough to write anything about yet
<joepie91>
but enough to have an idea of what direction I should go on
<joepie91>
in*
<gchristensen>
I know the feeling :)
<joepie91>
NixOS already has the solid technical foundations and the people to work with and coordinate them, so it's mostly just the usability-and-tooliing aspect that remains :)
<joepie91>
in that sense it's in a much better position already than many projects
<gchristensen>
well and docs
<joepie91>
yeah, counting that under usability at the moment
<gchristensen>
speaking of docs, kmicu, where are you?
<joepie91>
there are points where the line between 'usability' and 'documentation' blurs, eg. for interactive documentation and debugger tooling, so it's often practical to just consider documentation as one aspect of usability
<joepie91>
as opposed to an entirely separate concern with separate tooling
<joepie91>
good example of something that recognizes documentation as being part of usability; the Rust compiler
<joepie91>
which often tries to suggest the solution right in the compiler error
<gchristensen>
surely
<joepie91>
but yeah, honestly I think NixOS is on a very good track already
<joepie91>
and a *lot* of the problems have already been figured out, which is unusual for a project that hasn't exactly reached critical mass yet
<joepie91>
it's just the usability aspects that are still lacking, so that's what I primarily intend to invest effort into :P
lambdael has joined #nixos
<joepie91>
I certainly think NixOS has a lot of potential, also as a thing for other projects to derive from
<seequ>
TIL the default Xsessions file sets ~/.background-image as the background
<joepie91>
with the right end user wrapper around the technology, it could become pretty significant
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] AmineChikhaoui opened pull request #27712: pythonPackages.locustio: use flask 0.10.1 instead of 0.12 which broke tests. (release-17.03...fix-locustio) https://git.io/v7cVS
NixOS_GitHub has left #nixos []
lambdael has quit [(Quit: WeeChat 1.7.1)]
lambdael has joined #nixos
ThatDocsLady is now known as ThatDocsLady_nom
<mbrock>
I've started thinking of NixOS as a operating system construction toolkit
lambdael has quit [(Client Quit)]
<mbrock>
so maybe in 5 years there will still be a somewhat esoteric NixOS underbelly along with a few different distros based on it
lambdael has joined #nixos
<joepie91>
mbrock: this is the approach I am taking with one of my longer-term projects :)
<mbrock>
something along those lines seems like a possibly desirable state of affairs, because it would let those distros be opinionated in their various UX ideologies
<joepie91>
building a distro on top of NixOS mechanisms, that is
<mbrock>
joepie91: interesting! I have some such ideas too. It seems like a natural thought once you start sharing a NixOS configuration with other people
bennofs has joined #nixos
<joepie91>
mbrock: well, I intend to take it a bit further, and also tackle some of the common UX issues in Linux; so NixOS is just one building block in the project
bennofs1 has quit [(Ping timeout: 255 seconds)]
<mbrock>
8) awesome
peel has quit [(Quit: WeeChat 1.9)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] AmineChikhaoui opened pull request #27713: pythonPackages.locustio: use flask 0.10.1 instead of 0.12 which broke tests. (master...master) https://git.io/v7cwC
NixOS_GitHub has left #nixos []
<joepie91>
mbrock: I've been spending the past two years or so learning about everything from top to bottom; from high-level end user applications, to common libraries, to system internals (message buses like DBus, things like X11 and Wayland, etc.), to 'primitives' (layout and rendering algorithms, etc.), to kernels, to how the underlying hardware works
mjacob_ is now known as mjacob
<joepie91>
there's undoubtedly a lot of learning and work left to do, but I'm starting to get a pretty good picture of how an entire system ties together
<joepie91>
and where the problems are
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] FRidh closed pull request #27712: pythonPackages.locustio: use flask 0.10.1 instead of 0.12 which broke tests. (release-17.03...fix-locustio) https://git.io/v7cVS
NixOS_GitHub has left #nixos []
<joepie91>
it's not a very formal effort yet, but will be in the near-ish future
andymandias_ has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
<joepie91>
when I get around to building the tooling for working on it further :) mostly distributing research tasks at this point
<joepie91>
already found a few people who are willing to investigate current workings of undocumented things and write informal documentation of them
<joepie91>
mbrock: end goal is to produce an Actually Usable end user distro, something that can legitimately compete with Windows in terms of usability and integration, and something that's very reliable in operation; NixOS plays an important role in that last part
andymandias has joined #nixos
<mbrock>
great goal!
<joepie91>
but yeah, long-term project, no real timeline yet
justelex has joined #nixos
<joepie91>
but in the process of getting there I'll probably be building a lot of tooling around NixOS
<joepie91>
which is of course also useful outside of that project
<NixOS_GitHub>
[nixpkgs] FRidh closed pull request #27713: pythonPackages.locustio: use flask 0.10.1 instead of 0.12 which broke tests. (master...master) https://git.io/v7cwC
NixOS_GitHub has left #nixos []
<mbrock>
ah, nice
<joepie91>
this all probably sounds a bit pie-in-the-sky, but they're all serious, achievable goals :P
<joepie91>
just requires a lot of time and effort
<mbrock>
I agree, I think such a thing should be considered achievable
<joepie91>
and especially as I start involving other interested people in the long term, things will probably ramp up
<joepie91>
there's only so much I can do as one person :P
<seequ>
Can I make a derivation without src?
babic has joined #nixos
babic has quit [(Client Quit)]
<seequ>
I just want to add a single file to sw/bin
<mbrock>
my feeling since getting involved with Linux ages ago has been that there's so much effort sunk into coding user interfaces in C or C++ with UI paradigms that require lots of fiddling and still don't turn out very impressive, and then everything's kinda locked down into incomprehensible tarballs that distros usually discourage you from modifying
dbe has quit [(Ping timeout: 255 seconds)]
stubborn_d0nkey has quit [(Remote host closed the connection)]
stubborn_d0nkey has joined #nixos
<dtzWill_>
Mic92: yes! And other compiler-based instrumentation as well! ^_^
newhoggy has joined #nixos
<gchristensen>
joepie91: I'm going to push forward on one of the docblock-like PRs unless you come up with an alternative I can do by tomorrow
dtzWill_ is now known as dtzWill
joehh has joined #nixos
stubborn_d0nkey is now known as babic
babic has quit [(Remote host closed the connection)]
<LnL>
^ should we add that to the 17.09 milestone?
<gchristensen>
joepie91: I'm all about great docs, but the effort can't be held up just b/c it isn't perfect. we can start somewhere and replace it when something better comes around, it is possible :)
junaidali has quit [(Read error: Connection reset by peer)]
<FRidh>
gchristensen: the problem I see with your implementation is that you cannot have docs next to code since otherwise the docs end up in the same scope. The other implementation seems to solve that, though.
<joepie91>
gchristensen: I'll try to get a preliminary implementation going of my 'side-file' documentation approach by tomorrow
junaidali has joined #nixos
<LnL>
FRidh: why wouldn't that work with gchristensen's approach?
<joepie91>
gchristensen: probably not with source references yet though, since my Nix parser is not done yet
<gchristensen>
FRidh: indeed! I really like moretea's option, much better than mine even :) there are even some ... fascinating ... things we can do with it, like add type checking :P
<pie__>
quick question, what tool does searching nixpgs belong to?
<gchristensen>
pie__: nix-env -qaP does it
<gchristensen>
joepie91: ok
<LnL>
nix-index was also recently added to nixpkgs I think
<pie__>
thx
<dtzWill>
Mic92: that's very cool! :D
<gchristensen>
joepie91: but again, if you come up with something cool after this merges, this isn't permanent
<joepie91>
gchristensen: sure, but like I said, once something is merged it gets harder to replace :)
* gchristensen
shrugs
<FRidh>
gchristensen: so extract comment blocks, and then parse the function docs with Sphinx. That would be a bit more work I think compared to the proposed implementations, and would bind you right away to a tool.
<joepie91>
so I'd prefer to try and get at least the idea going by tomorrow
<gchristensen>
hasn't stopped me before
<gchristensen>
FRidh: I'm really novice at this, so pardon my probably not exactly correct wording, but (..typing..)
<joepie91>
but first, time to get lunch :P
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to release-17.03: https://git.io/v7c6N
<NixOS_GitHub>
nixpkgs/release-17.03 992ebf4 Robin Gloster: maintainers: backport ris to fix eval
NixOS_GitHub has left #nixos []
<gchristensen>
FRidh: my understanding (and this is all second hand from someone who knows this better than me) is there isn't really a symbol table that we can attach docs to, much like the problems in documenting lisp. everything is locally scoped. we may largely know it as lib.concatStringsSep but it could just as easily be renamed to something else somewhere else and who knows
<gchristensen>
which is to say, docblocks are hard in a language like nix
<LnL>
^ exactly moretea's approach works around that by using __functor
<gchristensen>
right
<gchristensen>
and interestingly we could probably have a (defparameter x "docs") that is a __functor that returns x when called, or has a `.doc` output but thinking about that makes my brain melt a little
<LnL>
but the performance impact of that is probably to large, so using the docs attribute as an alternative for lib functions seems like the best way to go
<gchristensen>
I wonder if we could use moreteas' approach, but strip out the doc overhead on normal executions
<pie__>
how do i autocomplete packages in nix-repl? :/
<gchristensen>
pkgs = import <nixpkgs> {};
<gchristensen>
pkgs.he<tab>llo
<LnL>
I don't think so, unless nix provides a way to attach the docstring to a function
<pie__>
oh i almost got that first line xD
<gchristensen>
oh, no semicolons
<gchristensen>
LnL: what do you mean?
<gchristensen>
re defparameter, or stripping them out?
<LnL>
native support for adding metadata / docstring to a function
<LnL>
I think the main performance issue with __functor is the self: _ part
<pie__>
is the only way to get packages from another channel with nix-shell -p to pass it via -I?
<pie__>
its pretty annoying to have to type -I /var/nix/var/... every time
<gchristensen>
LnL: I'm still not sure if you're referring to stripping out the docs on normal runs, or on defparameter :|
<LnL>
something like defparameter or builtins.addFunctionDocs
<gchristensen>
ah
<FRidh>
pie__: I think you can use $ nix-shell '<mychannel>' -p kbd
<gchristensen>
well that is the point of a functor right, its an attrset which can be called
<pie__>
FRidh, oooh right....
<FRidh>
test it, I don't use channels.
<gchristensen>
so if docs are excluded when imported, run (lib.mapAttrs (fnName: fnFunctor: fnFunctor.interior_fn) lib) over it
<pie__>
hm no it says undefined variable for the package name that only exists in that channel
<LnL>
gchristensen: kind of, but if a function can have a pointer to a docstring you won't have any performance impact when calling it
<gchristensen>
yeah but this requires language features
<LnL>
exactly :)
<gchristensen>
and if we can implement this first without language features, I think it has a better chance of being successful
<gchristensen>
(later we can add language features)
<LnL>
but now that I think of it, but your idea might work
<gchristensen>
saying we want to do this neat thing but we can't possibly start until eelco releases 1.11.75 is IMO a hint of a bad idea
<LnL>
as long as a fixpoint is used when referring to other lib functions
<LnL>
right?
<gchristensen>
great point
<gchristensen>
and the fixed-point would be where the stripping happens, yeah?
<LnL>
yeah otherwise functions within the same would sill use the __functor versions :)
<gchristensen>
LnL: import <nixpkgs> {} -> docs are enabled, but when nixos imports <nixpkgs> it does so with { docs = disabled; }
<FRidh>
LnL: gchristensen: interesting idea of stripping the docstrings. So make it a `config` option which by default does not include docstrings?
erictapen has joined #nixos
<gchristensen>
yeah
<LnL>
hmm
<gchristensen>
that way in nix-repl it'll have docs
<FRidh>
changing the option would cause a mass-rebuild
[0__0] has quit [(Remote host closed the connection)]
<gchristensen>
hmm not sure it would
<LnL>
ho?
<FRidh>
oh yes you're right
<FRidh>
it wouldn't
<LnL>
how?
<gchristensen>
well it would return the same thing
<FRidh>
indeed
<gchristensen>
so the .drv's wouldn't change
<LnL>
but I think using import <nixpkgs> {} is used in to many places so I think the condition should be reversed
newhoggy has quit [(Remote host closed the connection)]
luntain has joined #nixos
<gchristensen>
very few actually, in nixpkgs
newhoggy has joined #nixos
<LnL>
it's done in the release.nix files
<LnL>
and it's very common outside of nixpkgs
<gchristensen>
if we assume (this may not be valid) that the heaviest hit of enabling docs will be in NixOS's module system itself, and the majority of external users of importing <nixpkgs> aren't using lots of lib functions: we can fix release.nix / the rest of nixpkgs where appropriate, and most others won't mind
<LnL>
maybe we should time how long it takes to evaluate all of nixpkgs if it's a big difference
<gchristensen>
yeah definitely
<LnL>
oh you're mostly worried about the modules
<gchristensen>
yeah, AFAIK calling any particular package or 5 from nixpkgs won't call lib functions so many times
<LnL>
I was worried about nixpkgs itself, if callPackage slows down it will be very noticable
<gchristensen>
yeah, we'll have to test :)
<LnL>
but I think there are only a few projects that use the nixos modules like nix-darwin and home-manager
newhoggy has quit [(Ping timeout: 260 seconds)]
<gchristensen>
we will definitely have to test
<LnL>
not even sure if there are any other projects
<gchristensen>
it would be very nice if nix-repl would get docs without users having to think about it
<gchristensen>
(I can imagine being a frustrated user, angry about how user-hostile it would be to specifically ask for docs, despite the technical challenges)
<pie__>
why does the antlr runtime need network related packages? :/
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] FRidh pushed 2 new commits to master: https://git.io/v7c1q
<NixOS_GitHub>
nixpkgs/master 159be2e Muhammad Herdiansyah: bubblewrap: init at 0.1.8
<NixOS_GitHub>
nixpkgs/master e01181a Frederik Rietdijk: Merge pull request #27708 from konimex/bubblewrap...
NixOS_GitHub has left #nixos []
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] sshisk opened pull request #27716: Improvements for Prosody (master...prosody) https://git.io/v7c12
<pie__>
complains about: error: cannot coerce a function to a string, at /nix/store/7sprsjlv7wwl0qp1jh5z77kj276p3jqa-unstable-17.09pre111388.00512470ec/unstable/pkgs/development/interpreters/python/mk-python-derivation.nix:59:3
<gchristensen>
it is not calling overrideAttrs, it is adding 2 things to the list: [ python36Packages.responses.overrideAttrs ] ++ [ python36Packages.responses.overrideAttrs ]
<joepie91>
gchristensen: I would say that 'side file' documentation solves a lot of these issues, when structured appropriately; there's no runtime overhead, no changes to the language are required, and parsers do not need to retain comments (which is important because, in an expression-oriented language like Nix, there's often no obvious or sensible point in the AST to attach comments to)
<pie__>
gchristensen, whaaat
dannyg has joined #nixos
newhoggy has joined #nixos
<gchristensen>
erm sorry I messed that up
<gchristensen>
it is not calling overrideAttrs, it is adding 2 things to the list: [ python36Packages.responses.overrideAttrs ] ++ [ (oldAttrs: rec {doCheck = false;}) ]
<pie__>
LnL, well that worked >.>
<LnL>
^ yep and the first one is a function and that can't be converted to a string :)
<gchristensen>
and actuall y the second one is a function too :)
<pie__>
well thats weird as f*** but ok :D
<LnL>
yeah just noticed :p
<pie__>
(only because i obviously dont understand how nix works)
<gchristensen>
pie__: it is _very_ weird, but ... is what it is :P
<pie__>
crap still fails on testing
<LnL>
you'll get the same error with "${x: x}"
<pie__>
that apparently did not disable tests or something...
<pie__>
(ok just added the failure to that gist as well, forgot first time around)
<FRidh>
pie__: why do you want to disable the tests for responses? The package seems to work on master.
<pie__>
huh. i guess its broken on unstable? (see gist)
cpennington has joined #nixos
<pie__>
to be fair i dont even know why antlr needs this
<FRidh>
pie__: also, I don't think passing `doCheck = false;` is going to work because with Python we're actually doing an `doInstallCheck` instead.
justanotheruser has joined #nixos
<pie__>
ok thats weird because ive done that before xD
<FRidh>
its just that we've aliased one to another. But `overrideAttrs` doesn't see that.
<FRidh>
ohh
<FRidh>
interesting
<pie__>
what the heck this doesnt even need any of these libraries, why is it asking for them.
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] volth closed pull request #24145: stdenv: do not overwrite "$NIX_BUILD_TOP/env-vars" on each phase (master...stdenv-env-vars) https://git.io/vyNyG
NixOS_GitHub has left #nixos []
magnicida has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] vcunat pushed 2 new commits to master: https://git.io/v7cDE
<NixOS_GitHub>
nixpkgs/master 69c6737 Vladimír Čunát: knot-dns: maintenance 2.5.2 -> 2.5.3
<NixOS_GitHub>
nixpkgs/master 62e4e33 Vladimír Čunát: knot-resolver: maintenance 1.3.1 -> 1.3.2
<7JTABSZUX>
[nixpkgs] NeQuissimus pushed 2 new commits to master: https://git.io/v7cDz
<7JTABSZUX>
nixpkgs/master ebf5df0 Tim Steinbach: exfat-nofuse: 2017-01-03 -> 2017-06-19
<7JTABSZUX>
nixpkgs/master e59ecf8 Tim Steinbach: Merge pull request #27585 from NeQuissimus/exfat_2017-06-19...
7JTABSZUX has left #nixos []
<pie__>
ok im really confused as to why it want to pull in all these dependencies
slack1256 has quit [(Ping timeout: 240 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] volth closed pull request #25332: propagatedUserEnvPackages is obsolete name, these lines have no effect (master...no-effect-propagatedUserEnvPackages) https://git.io/v9C9A
NixOS_GitHub has left #nixos []
ThatDocsLady_nom is now known as ThatDocsLady
<pie__>
ok i think the hash is cached or something and its trying to build a different package 0.o
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nix] edolstra pushed 2 new commits to master: https://git.io/v7cDi
<NixOS_GitHub>
[nixpkgs] volth closed pull request #26602: shells-environment: do not let sudo make perl disfunctional (master...issue-25613) https://git.io/vHNOA
NixOS_GitHub has left #nixos []
<FRidh>
pie__: checkout fetchPypi
<pie__>
thx
darlan has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] dezgeg pushed 1 new commit to master: https://git.io/v7cy7
<NixOS_GitHub>
nixpkgs/master d2f45ba Tuomas Tynkkynen: xfstests: Use keyutils
NixOS_GitHub has left #nixos []
<pie__>
FRidh, ok but where xD
<FRidh>
pie__: use git grep to find it ;)
<Mic92>
dtzWill: do you know what package/option I need to use -DLLVM_ENABLE_LTO=thin when compiling llvm? I tried adding -DCMAKE_LINKER=$(which lld), but I get the error: lib/libLLVMSupport.a: error adding symbols: Archive has no index; run ranlib to add one
<NixOS_GitHub>
[nixpkgs] vcunat pushed 1 new commit to release-17.03: https://git.io/v7cSR
<NixOS_GitHub>
nixpkgs/release-17.03 e50639c Vladimír Čunát: knot-resolver: 1.2.6 -> 1.3.2...
NixOS_GitHub has left #nixos []
<pie__>
FRidh, oh you mean in nixpkgs
<pie__>
here i am just assuming its documented xP
<joepie91>
pie__: soon....
<joepie91>
:P
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] vcunat pushed 1 new commit to master: https://git.io/v7cS6
<NixOS_GitHub>
nixpkgs/master 20d2bfa Vladimír Čunát: knot-resolver: remove unused inputs
NixOS_GitHub has left #nixos []
<pie__>
'XD
<pie__>
hail nixos
bakgjaiowejioaw has joined #nixos
<joepie91>
I just can't get rid of the habit to interpret "imap" or "Imap" as "IMAP" (the email protocol), every time I read it
<bakgjaiowejioaw>
hello! can anyone help me? I want to use haskell's criterion package with GHC821, but I'm getting build failures. I need to know how to override the nix expression at haskell.packages.ghc821.criterion. I believe overlays will do the job, but I'm not sure the syntax to override
slack1256 has joined #nixos
<pie__>
joepie91, i think that might make me borderline <something bad>
goibhniu1 has joined #nixos
goibhniu has quit [(Ping timeout: 240 seconds)]
<joepie91>
gchristensen: any objections against calling eg. a function passed into `map` a "callback"? it's a slightly abusive use of the term but I don't know a better way to describe a function called from within a function, that can be easily integrated into documentation
goibhniu1 is now known as goibhniu
<FRidh>
joepie91: nested function?
<joepie91>
FRidh: there's quite a few different things that could be called nested functions though :P
<seequ>
Does nixos use precompiled binaries for nixpkgs by default?
<joepie91>
especially given the one-argument functions that Nix uses
<FRidh>
lambda's?
<joepie91>
mmm.
<joepie91>
also ambiguous :/
<FRidh>
seequ: yes it tries to use binary substitutes when available. You can turn that off.
<seequ>
What's the option for it?
<seequ>
And can I force a full rebuild after turning it on?
<FRidh>
seequ: the nix option is build-use-substitutes. I don't think there is a nixos option for it so you would have to pass it to nix.extraOptions. You could also just remove the binary caches...
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 3 new commits to master: https://git.io/v7cQ8
<NixOS_GitHub>
nixpkgs/master f43c445 Tim Steinbach: linux: 4.12.3 -> 4.12.4
<NixOS_GitHub>
nixpkgs/master 88c0f67 Tim Steinbach: linux: 4.9.39 -> 4.9.40
<NixOS_GitHub>
nixpkgs/master 5a6b5b8 Tim Steinbach: linux: 4.4.78 -> 4.4.79
NixOS_GitHub has left #nixos []
slack1256 has quit [(Ping timeout: 255 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 3 new commits to release-17.03: https://git.io/v7cQg
<NixOS_GitHub>
nixpkgs/release-17.03 a36d3a0 Tim Steinbach: linux: 4.12.3 -> 4.12.4...
<NixOS_GitHub>
nixpkgs/release-17.03 314f279 Tim Steinbach: linux: 4.9.39 -> 4.9.40...
<NixOS_GitHub>
nixpkgs/release-17.03 6b042fb Tim Steinbach: linux: 4.4.78 -> 4.4.79...
NixOS_GitHub has left #nixos []
radvendii has quit [(Ping timeout: 260 seconds)]
eacameron has joined #nixos
bennofs has quit [(Ping timeout: 246 seconds)]
<GlennS>
Does anyone know about the install-grub.pl script? I think I may have found a bug, but possibly I am just out of my depth...
<GlennS>
It is getting a "device name" from /proc/self/mountinfo, but actually I think that lists filesystem names, not devices (not quite clear on terminology).
<GlennS>
It then feeds that into blkid.
<GlennS>
So, my problem is that it blkid is looking for and failing to find /dev/root, when it should be looking for /dev/sda
<GlennS>
Any thoughts?
<GlennS>
worth reporting, or have I misunderstood something?
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] fpletz pushed 1 new commit to staging: https://git.io/v7c7t
<NixOS_GitHub>
nixpkgs/staging b116fa5 Franz Pletz: Merge branch 'master' into staging
NixOS_GitHub has left #nixos []
MercurialAlchemi has quit [(Ping timeout: 240 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] FRidh pushed 1 new commit to staging: https://git.io/v7c7i
<NixOS_GitHub>
nixpkgs/staging 00bf3a9 Frederik Rietdijk: Revert "kbd: 2.0.3 -> 2.0.4"...
NixOS_GitHub has left #nixos []
fikse has joined #nixos
nslqqq has quit [(Ping timeout: 276 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 1 new commit to master: https://git.io/v7cdf
<NixOS_GitHub>
nixpkgs/master 07ab4d2 Tim Steinbach: scala: 2.12.2 -> 2.12.3
<magnicida>
does anyone have experience using NixOS for embedded Linux projects?
Infinisil has joined #nixos
<magnicida>
seems like a very strong potential use-case
<magnicida>
I am considering suggesting this to a client but would like to learn a bit more about other people's experience in that domain
<joepie91>
magnicida: any particular reason you see it fitting that usecase well?
erasmas has joined #nixos
<clever>
magnicida: i made a fork of nixos, that can compile down to a ~40mb squashfs and runs entirely from ram: https://github.com/cleverca22/not-os
<LnL>
oh! you can put no-tos on 40mbs?
fikse has quit [(Ping timeout: 268 seconds)]
<clever>
LnL: yeah, 40ms for the squashfs, plus some initrd and kernel space
<LnL>
that's pretty impressive :)
<clever>
depends a lot on what else you want it to run, thats just a bare sshd and runit
<clever>
i'm also using a full glibc, so it could be made even smaller
<LnL>
yeah that's probably a significant part of that
<clever>
the only thing i'm compiling specially is coreutils (to remove systemd)
<clever>
every other part is a stock build from the nix binary cache
<magnicida>
joepie91: during product development you might want to explore with different configurations... being able to describe them as an expression and generate images from them that one can flash in the devices seems ideal. at the same time one might want to have reproducible environments for developers working on the product software that is loaded in the embedded thing... setting up ci systems, etc, all seem to me would become so mu
<magnicida>
with nixos
<Infinisil>
coreutils contains systemd :o
<clever>
Infinisil: yep
<LnL>
^ same reaction :p
<CrazedProgrammer>
hi guys, have any of you managed to get gtk+ themes working in qt5 applications? there was an issue that said qt5 applications use the gtk3 themes by default but that doesn't seem to be the case. the qt5.qtbase.gtk package referenced in the nixos manual doesnt seem to exist and the qtstylesplugin package doesn't seem to do anything: setting QT_QPA_PLATFORMNAME=gtk2 gives an error message with a list of qt plugins and gtk isn't in one
<CrazedProgrammer>
of them
<joepie91>
magnicida: ah, hm, I see what you mean
<CrazedProgrammer>
i'm on unstable
<LnL>
clever: what does it need that for?
<joepie91>
Infinisil: systemd is ~everywhere~
<clever>
LnL: double-checking
<avn>
clever: coreutils depends on systemd?
<joepie91>
magnicida: one immediate issue I can see is that on embedded systems you often want to aggressively deduplicate dependencies
<joepie91>
magnicida: because of code sharing of libraries in RAM
<clever>
ah, it was utillinux, not coreutils
mudri has joined #nixos
<joepie91>
which is *possible* with Nix, don't get me wrong; but not necessarily what you get out of the box
<joepie91>
magnicida: also, you would have to ensure that the entire system is built outside of the device itself; Nix is not very resource-efficient at the moment
<joepie91>
magnicida: in fact, I'm pretty sure that NixOps creates a swap file on 512MB DO instances by default because otherwise it doesn't have enough RAM to build the entire system
<clever>
joepie91: my kexec trick doesnt even boot on a 512mb system, and i dont think it can get far enough to make its own swap
<joepie91>
magnicida: these are all issues that can be overcome, but they are caveats to be aware of :)
<Infinisil>
joepie91: Indeed
grumble has joined #nixos
<magnicida>
interesting, admittedly the embedded systems I am thinking of are quite beefy, so even that might not be a problem
ertes has quit [(Ping timeout: 268 seconds)]
<joepie91>
magnicida: what type of system?
<prooftechnique>
Has anyone gotten nix working on macOS 10.13? I've been following copumpkin's work dealing with the changes in libsystem, but I haven't been able to quite get things working. It may just be that all of it is still on staging, so I'll just have to wait, but if anyone's got tips, I'm very much listening. :)
<clever>
magnicida: another benefit of not-os, is that your entire system is ~3 files in /boot, so its very easy to version the entire machine and up/downgrade
<magnicida>
an embedded linux system, but working on a beefy embedded system---with low-end intel stuff, on the range of the intel compute sticks
<clever>
magnicida: i had originally designed it to run on a rack of ~8 servers, network booting from eachother
<magnicida>
this would be a consumer product
<clever>
but treating the entire thing more as firmware then software
<magnicida>
things that are important are for example boot time
<magnicida>
there might be some hybernation also involved to fake fast boot time
<clever>
not-os boots pretty fast, a lot of useless junk has been removed
<joepie91>
magnicida: that sounds like a set top box :)
fikse has joined #nixos
<joepie91>
but yeah, if they're beefy systems you'll probably be fine
<magnicida>
hahahha sadly I can't talk about the product, it is way cooler than a set-top box :p
<prooftechnique>
Oh, perhaps nix-darwin would be a better place to ask. Duh
<clever>
magnicida: it took 12 seconds for my not-os to boot under qemu
<magnicida>
nice!
<magnicida>
i will keep an eye on that
<LnL>
prooftechnique: o/
<chrishill>
Hi, I’m having problems finding the package `xkbset`. I have searched for it with `nix-env -qaP | grep xkbset`, but that gave no results. According to latest Nixpkgs, it is declared in `pkgs/top-level`. I have looked at https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/X11/xkbset/default.nix, and `platforms` is set to `linux`, so I think it should work on my NixOS 1̀6.04.
<Infinisil>
prooftechnique: gchristensen knows quite a bit about nix + darwin, he's often here, maybe you can ask him
<gchristensen>
uh oh
<gchristensen>
I hardly know anything about nix on darwin, just how to install it :P
<Infinisil>
gchristensen: Ahh
<Infinisil>
Well from your nix multi-user thing I got that impression :P
<joepie91>
chrishill: NixOS 16.04...?
<gchristensen>
yeah exactly, I know really well how to install it :)
<joepie91>
chrishill: also, it looks like that package has not made it into any release channels yet
<Infinisil>
I don't think there's a lot of people using nix on mac generally
<gchristensen>
I think you'd be surprised
<joepie91>
chrishill: it's available in unstable nixpkgs
newhoggy has quit [(Remote host closed the connection)]
endformationage has joined #nixos
Eisfreak1 has joined #nixos
Eisfreak7 has quit [(Ping timeout: 260 seconds)]
<Infinisil>
gchristensen: Huh, for people who can't switch to linux for some reason (workplace or so) I guess?
<gchristensen>
or don't want to switch to linux yeah
<gchristensen>
or just want a better homebrew for cli things
newhoggy has joined #nixos
<Infinisil>
gchristensen: I just recently installed osx again on another disk (i still need it for xcode). I tried to use nix for most things, but it was just a hassle so i just used brwe
<Infinisil>
brew
<magnicida>
clever: really cool, I'll keep your project under the radar!
<gchristensen>
Infinisil: what is most things?
<joepie91>
chrishill: btw, if you meant NixOS 16.03; that's been unsupported for several months now, and you should really upgrade to 17.03 :)
<Infinisil>
gchristensen: E.g. needed to install gpg, whose pinentry didn't work. I installed nerd-fonts, which obviously aren't linked to the correct locations (so font book can see them), zsh also had a problem, can't remember what it was though
<gchristensen>
huh
<gchristensen>
gross
<Infinisil>
imo brew is just much better fit for osx in general, tested much better and used by lots. For building unix projects i'd still use nix, but for installing programs I'll favor brew
<seequ>
Can I force a full rebuild of the entire system??
<dash>
seequ: sure
<seequ>
Accidental double question marks
newhoggy has quit [(Ping timeout: 260 seconds)]
<dash>
seequ: what's your goal in doing so?
<Infinisil>
seequ: Why though?
<FRidh>
anyone knows how long it typically takes to build gfortran?
Myrl-saki has quit [(Ping timeout: 276 seconds)]
<LnL>
it takes a while
<seequ>
I'd like to be extra-sure my issues with X don't come from it being built for wrong hardware
<Infinisil>
seequ: Yeah that's not what you're gonna achieve be a rebuild
<Infinisil>
It's gonna be exactly the same, that's what nix ensures
<dash>
seequ: rebuilding wouldn't help, because you'll get the same build results
<dash>
seequ: if you can find a problem in the config that specifies the wrong X components, then fixing that will build whatever it needs
<LnL>
FRidh: ~1h I think
<seequ>
Sadly I have no clue what the problem is.
<Infinisil>
seequ: What's not working?
<seequ>
X just uses a lot of CPU when playing videos.
<Infinisil>
seequ: Hmm, that's the same for me, I didn't think something would be wrong
<Infinisil>
Oh, you mean the X process? Hmm, I'll check
<seequ>
yup
<FRidh>
LnL: ugh...I'm fixing some things on staging, but Hydra hasn't build it yet, unfortunately.
<Infinisil>
seequ: Like how much? I just played a video with vlc and it's using like no cpu, I guess my problem was with firefox using lots
<seequ>
Infinisil: 60% of one core when I play a 1080p video on a 1080p monitor
<Infinisil>
seequ: What player did you use?
<seequ>
firefox, youtube
<LnL>
FRidh: yeah there was an issue with cyclic references between the outputs on darwin a while back, pretty annoying to fix
<seequ>
plain unmodified nixos.firefox
<FRidh>
LnL: so in stdenv?
<dash>
seequ: try playing one a non-web browser and see if it does the same
<dash>
er, one with
<gchristensen>
someone recently shared a link to the nix pills condensed in to a single git repo, anyone remember what that was?
<joepie91>
not necessarily settled on the format yet
<joepie91>
oops
<joepie91>
made an error, fixed it, F5
<joepie91>
:p
<chrishill>
joepie91: thanks for the help. yep, I wrote wrong; I’m on 16.09
<joepie91>
(included an incomplete bit)
<joepie91>
chrishill: right, you'd still want to update then, 16.09 is unsupported too :)
<gchristensen>
joepie91: to be honest, I very much don't like the yaml
<joepie91>
chrishill: but even on 17.03 you'll need to grab it from unstable
<joepie91>
since it's in no release channels at the moment
<joepie91>
gchristensen: any particular reason?
<gchristensen>
I find it very uncomfortable to write, and difficult to predict what it will be interpreted as
<Infinisil>
joepie91: I have to agree with gchristensen, I don't know how that would stand long-term
<FRidh>
When configuring Hydra, should one configure postgres first?
<gchristensen>
but since it is yaml we can just use json and it'll work the same
newhoggy has quit [(Ping timeout: 255 seconds)]
<joepie91>
gchristensen: I intentionally picked YAML over JSON because JSON really is *not* human-writable, and is missing a few important features (most importantly, references and sane multiline support)
<Infinisil>
joepie91: If that yaml would be auto-generated from smth like docstrings or from a future typed nix, that would be nice
<FRidh>
but then you can'tinclude comments in your comments ;)
<gchristensen>
joepie91: but json is valid yaml
<joepie91>
Infinisil: no, this would be the input format
<gchristensen>
so we can just use json and add comments
<joepie91>
Infinisil: I'm intentionally writing this to *not* be docstrings, or otherwise in the code files
<joepie91>
and I want to avoid inventing a new DSL for it where not necessary
lesce has quit [(Ping timeout: 240 seconds)]
<seequ>
..heh, X is using 7% when there's enough action in urxvt
<Infinisil>
joepie91: Had a discussion with gchristensen once where we thought about using something like a `doc` attribute in nix itself to make structural docs
<gchristensen>
yeah this is what that is about :)
<Infinisil>
Is nix a new DSL?
<joepie91>
Infinisil: there are a few significant issues with in-code docs that have led me to try and build something that works with separate files; ie. anything that involves "modifying the Nix source files" is out of scope for what I'm trying to do
<joepie91>
Infinisil: the intention is to eventually turn this into a more generic documentation mechanism, not specific to Nix
<joepie91>
it's a project that I'd been working on prior to Nix
<joepie91>
or well, prior to my involvement with Nix *
<Infinisil>
joepie91: Yeah inline docs may not be the best admittedly
<joepie91>
and when talking about syntactic ambiguity I'm not sure that Nix is the best alternative solution either :P
<gchristensen>
I'm concerned that yaml ain't markup language and docs seem markup heavy
newhoggy has joined #nixos
<joepie91>
gchristensen: I'm interpreting all free text fields as markdown with references (the $(foo) stuff)
* LnL
wants an irc client that ignores vim commands :p
<gchristensen>
I guess I'm skeptical about yaml being an appropriate tool
<joepie91>
gchristensen: mind that the YAML files are not meant for direct reading by humans; they're structured source files to generate readable documentation / autocomplete / etc. from
<joepie91>
gchristensen: I mean, I have my concerns about YAML as well, but I've not yet seen a more viable option that works given these constraints
<gchristensen>
but they will be directly read by humans when making updates (most programming is reading not writing)
<joepie91>
gchristensen: so to me this is a "least bad" kind of thing
<joepie91>
yes, but there are different kinds of reading
cement has joined #nixos
<clever>
FRidh: try a role of 'admin' instead
<joepie91>
when modifying eg. the behaviour of a function, it's relatively easy to relate parts of the 'documentation items' to parts of the function
<joepie91>
but it would be totally unreadable for *using* those functions; but that is out of scope
newhoggy has quit [(Ping timeout: 260 seconds)]
<joepie91>
gchristensen: as for hard-to-write; it's non-trivial to accurately express structured documentation no matter what format you use
* seequ
turns binarycache back on
<gchristensen>
I think I'd rather write in docbook. this isn't a slant against your work, but if we wrote out a few function docs that documented everything you documented here, it'd be pretty much copy-paste-easy to add new function docs
<Infinisil>
joepie91: I know you want this to be applicable outside of nix, but within nix your yaml file looks almost the same as a nix file, so why not use nix directly for its docs? Then one doesn't have to "learn" yaml
<Infinisil>
s/within nix//
lesce has quit [(Ping timeout: 276 seconds)]
<joepie91>
gchristensen: I don't feel that docbook is either easier or fulfilling the same usecases
<FRidh>
clever: this is after I made a basic hydra config in configuration.nix and did a rebuild. Should I create the postgres user myslf?
<joepie91>
Infinisil: how would you do that?
<clever>
FRidh: i dont think its the postgress user, let me check my logs
<gchristensen>
joepie91: what is the usecase it isn't fulfilling?
<FRidh>
agree here with joepie91. Having it in a data format like yaml is more flexible than directly in docbook.
<joepie91>
gchristensen: keep in mind that these files are *not* meant to be generic documentation markup; they're meant to be structured definitions from which documentation can be *derived*; whether that is in the form of generated HTML, or autocomplete entries in an editor, or in a REPL, or whatever else
<clever>
FRidh: what happens if you run these 2?
<joepie91>
gchristensen: ie. data, not content
newhoggy has joined #nixos
<joepie91>
gchristensen: docbook is primarily content-oriented
<gchristensen>
in that case I'm not sure why it wouldn't be with the code (see the PRs from MoreTea and myself)
<gchristensen>
since it isn't docs, but the thoughtstuff which docs are derived from
<FRidh>
clever: FATAL: role "hydra" does not exist at
<gchristensen>
and it literally is code
<joepie91>
gchristensen: because integrating it into the code will 1) make deriving documentation more difficult since you need a full language parser for Nix, 2) either involve runtime overhead, or strange rewriting mechanisms, or parser complexity to retain comments, and 3) generally bloat code files with things that are not code and that make it more difficult to work with the code itself and infer structure from it
<clever>
FRidh: ah, sounds like some of the hydra init stuff failed
<gchristensen>
or data, I dunno :P
<clever>
FRidh: maybe the initial db import
<seequ>
dash: X uses about the same amount of CPU on vlc than on firefox
<joepie91>
gchristensen: on top of that you have the issue that nearly every implementation of documentation generation that's based on in-code docs is totally incapable of representing the documentation in a structure that differs from that of the code
<joepie91>
which is why nearly all generated documentation is totally unusable for end users
<joepie91>
unless you already know precisely what you're looking for
<gchristensen>
I don't follow
<joepie91>
in exchange for... what benefits?
<joepie91>
my problem with in-code docs, in short, is that it sounds very clever and handy on paper, but that in practice it introduces more drawbacks than it introduces benefits
<FRidh>
clever: that file doesn't exist. It fails at creating the user one step before creating the db
<FRidh>
its a fresh hydra installation
<gchristensen>
how does this data format (which can be easily represented in the code our PRs propose) make it possible to create different, usable documentation representations?
rumble has joined #nixos
<FRidh>
and postgres
ebzzry has quit [(Ping timeout: 240 seconds)]
<clever>
FRidh: ah, maybe postgress is broken then
newhoggy has quit [(Ping timeout: 240 seconds)]
digitus has joined #nixos
<joepie91>
gchristensen: because this data format does not *need* to mirror the code's structure; that is only what I have so far because I'm not done yet
<gchristensen>
but eventually it becomes data in a lang8uage
<gchristensen>
in a system much like the in-code docs would
<gchristensen>
and I don't understand how there is a difference
dannyg has quit [(Quit: dannyg)]
<joepie91>
gchristensen: can you rephrase that? not sure what you mean
<joepie91>
(aside; I have to get to work in 15 minutes)
<gchristensen>
whether the data about functions is in a .yaml file or in a .json file or in nix next to the function itself eventually it is interpreted and represented as variables and datastructures in a programming language's interpreter, which is then used to emit documentation in other formats for people to consume. how does the data being in yaml make it possible to make usable documentation for end-users where having
<gchristensen>
the data in nix, next to the function makes it impossible?
ison111 has joined #nixos
<joepie91>
Infinisil: but now you need a full-blown Nix parser to be able to handle that data.
<gchristensen>
we can take the in-nix code and export to json no problem
<gchristensen>
which you can parse with your yaml parser
<Infinisil>
joepie91: I don't know where the problem is
Eisfreak7 has quit [(Ping timeout: 260 seconds)]
<Infinisil>
Having it in nix directly would make me incredibly confident i didn't make any formatting mistakes
<joepie91>
gchristensen: you're looking at this in the wrong frame of reference; it being YAML has nothing to do with 'creating usable documentation'
Eisfreak7 has joined #nixos
<joepie91>
you're conflating separate points
athan_ has quit [(Remote host closed the connection)]
<joepie91>
the only reason I picked YAML as a format for the documentation files is because it is 1) widely supported, 2) relatively easy to learn and use, 3) has references and sane multiline string support
<gchristensen>
so we can make usable documentation from in-code descriptions
<joepie91>
this is completely separate from the concept of having the documentation in a separate file entirely
<joepie91>
Infinisil: there is approximately zero tooling for interacting with Nix files outside of Nix itself; there is widespread tooling for interacting with YAML files.
<gchristensen>
who cares, when we generate docs we have nix, we can export to whatever
<joepie91>
there's no point writing structured documentation if almost nobody has either the tools or the knowledge to actually *build upon it*
<gchristensen>
now you're conflating points :P
<Infinisil>
joepie91: Yeah, but I mean for the nixpkgs project, it would make more sense to use nix instead of yaml
<joepie91>
no, it wouldn't
<joepie91>
tooling isn't built in Nix
<joepie91>
editors aren't built in Nix
<gchristensen>
editors and tooling aren't built in yaml
<joepie91>
interoperability is an important property of data files and Nix files do not currently provide that
<Infinisil>
joepie91: But nix is also exportable to anything
<Infinisil>
And there's even tooling for that in nixpkgs
<joepie91>
gchristensen: no, but they are built in languages that have parsers and serializers *for* YAML
goibhniu has quit [(Ping timeout: 255 seconds)]
<joepie91>
but not for Nix
<gchristensen>
so let's export to yaml
<joepie91>
Infinisil: gchristensen: half the problem with Nix as it stands is that it is REALLY REALLY difficult to build any kind of tooling around it because there's basically one reference implementation, no spec, no easily usable stand-alone libraries, no bindings for other languages or runtimes, etc.
<joepie91>
gchristensen: at which point you need an additional export step, for what gain?
<gchristensen>
well we already export our docs
erictapen has joined #nixos
<Infinisil>
^^
<joepie91>
gchristensen: I'm comparing to having documentation directly in YAML or an equivalent format.
<joepie91>
that is directly usable by external tooling.
<joepie91>
regardless of what it's written in or with.
<gchristensen>
nix is a build tool, I ain't afraid of adding a build step when it makes things easier
<Infinisil>
Everything in nixpkgs is built around nix already, why should we introduce another language?
Eisfreak7 has quit [(Quit: WeeChat 1.9)]
<joepie91>
*you* may not be, but to other people trying to build tooling this is an issue.
<joepie91>
Infinisil: that is false.
<joepie91>
nixpkgs contains plenty of Bash, various other scripts
<gchristensen>
if we need to export to yaml we can export to yaml, that is _not_ a big deal
aowiergjer has joined #nixos
<gchristensen>
exporting to json is literally built in to the language
<joepie91>
I don't feel that this discussion is going in a productive direction...
<gchristensen>
I agree, I'm sorry :/
<gchristensen>
we could do a video chat some day
<Infinisil>
joepie91: Maybe open a github issue?
nschoe has quit [(Quit: Program. Terminated.)]
<joepie91>
that's not likely to make things better, to be honest :P
<gchristensen>
(soon, preferably - I'm in America/New_York)
<joepie91>
Infinisil: well, that is what I was working on
<joepie91>
a PoC
<joepie91>
so that I have something to open an issue *about*
<Infinisil>
PoC?
<joepie91>
proof of concept
newhoggy has joined #nixos
<Infinisil>
Ah
<FRidh>
I agree here with joepie91. Nix being a functional declarative language is very useful, but in some cases when dealing with data the functional part is just annoying and its more convenient to use a format like yaml or json. Yes, its portable to export, but that requires the Nix tools since currently ther are no other tools capable of doing that.
<aowiergjer>
Hi! I'm a new Nixos fan. Can't believe how I lived life without nix-shell before. I'm often creating a shell and then running the program the shell was created for. I'm wondering if Nix-shell can do that all in one go - something like `nix-shell -p git git status` to create a new shell with git and run a command in it?
<aowiergjer>
Thanks a lot! Imma run over to my coworker and bore them to death with talk of my new fav OS
<Infinisil>
FRidh: joepie91: So your main concern is that when somebody clones nixpkgs, they don't have a yaml that describes the lib, and he would need to actually have nix to generate that?
athan has joined #nixos
<joepie91>
Infinisil: right; the interoperability concern is indeed that you can't interact with the documentation directly without going through Nix first
<FRidh>
Infinisil: for certain parts that are plain structured data, yes, that's not good. But, to be clear, I'm not talking about docs here.
grumble is now known as grumble2
rumble is now known as grumble
<joepie91>
(aside from whether Nix is really a good language for data like this in the first place, which is debatable)
<FRidh>
not necessarily at least
<aowiergjer>
BTW - it seems to me that the functionality of nix-shell would work well with chroot - basically sandboxing any application. Maybe you smart cookies already thought of this though...
<aowiergjer>
$ nix-contain ?
<joepie91>
aowiergjer: runtime sandboxing is pretty tricky, a chroot would not be enough for that depending on requirements
newhoggy has quit [(Ping timeout: 260 seconds)]
<joepie91>
possible, though; NixOS does declarative containers for example
<Infinisil>
joepie91: FRidh: But there's a really easy solution for that: Just add a comment "A yaml/json version of this document can be found <link to auto-generated file on nixos.org>"
<joepie91>
Infinisil: Nix doesn't stop with nixpkgs, though. nor does that allow for checking out arbitrary revisions, and so on
<dash>
aowiergjer: linux chroots/containers aren't a good security mechanism
<joepie91>
Infinisil: sure, there are a lot of workarounds that one can think of to try and address every usecase you could conceive; but in the end you're going to miss usecases and the question is "what are you really gaining by this?"
<Infinisil>
joepie91: It does allow for arbitrary revisions, just have the nixos homepage have all versions available and the link be to a fixed one
<joepie91>
that would rapidly grow out of control.
<joepie91>
(and involve additional moving parts to ensure that the exports always work etc etc)
<Infinisil>
It's basically the same as all those readthedocs.io documentations are doing
<Infinisil>
Having all versions available
<joepie91>
versions and revisions are not the same thing
<joepie91>
a revision roughly equates to a git commit
<Infinisil>
Well I don't think every revision would need to be on the website
aowiergjer has left #nixos ["ERC (IRC client for Emacs 25.1.1)"]
<Infinisil>
Just every hydra build or something
<joepie91>
and now we're already excluding potential usecases
<Infinisil>
Every channel update
<joepie91>
and adding a network requirement as an alternative to a Nix requirement
<joepie91>
with still the same question: what are we gaining with these workarounds?
<joepie91>
anyhow, I need to get to work
<gchristensen>
I guess part of the problem is I don't see this as a workaround in any way
* joepie91
will be back later
<gchristensen>
talk to you soon :)
<Infinisil>
joepie91: The question is really: Is it worth adding another language to nixpkgs (yaml) for the few people that will wanna write tooling for nix + don't use nix + can't affort internet connection?
grumble2 has quit [(Quit: brb)]
<clever>
Infinisil: there is a yaml2json program in the haskellPackages.yaml derivation
<Infinisil>
clever: There's also a parseTOML in the nixpkgs-mozilla repo, it's always possible to do yaml/json -> yaml/json/nix conversion
<FRidh>
gfortran...it finished!
<Infinisil>
Oh and nix -> yaml/json mostly too
<FRidh>
LnL: 50 minutes :)
newhoggy has joined #nixos
<joepie91>
Infinisil: about to really be gone, but; you keep presenting 'adding another language' as if it's some sort of insurmountable additional cost, but I haven't seen any actual arguments as to why adding YAML would be a problem, other than "not sure how it's going to come out" - which is a problem that Nix has too in various places
<joepie91>
I don't see a significant cost that Nix doesn't also have
<seequ>
When it can be done with the same language, why have a second one?
<LnL>
FRidh: close enough :)
<gchristensen>
yaml is hard to write
<Infinisil>
joepie91: Eh, we can talk later/or in a github issue, see ya!
* seequ
totally didn't read any of this
<Infinisil>
I don't wanna hold you back
fikse has quit [(Ping timeout: 240 seconds)]
<gchristensen>
I retract my message in the interest of a future mconversation
<Infinisil>
seequ: gchristensen: Agreeing with both of you
<hodapp>
bah. what's everyone's favorite screen recorder that's easy to install on Nix?
<Infinisil>
hodapp: I think ffmpeg can do that somehow
<clever>
hodapp: obs-studio for full gfx, asciinema for text-mode recording
<hodapp>
there's more "somehow" with ffmpeg than I usually want to deal with
* Infinisil
votes for ffmpeg
<Infinisil>
oh right, OBS
<clever>
hodapp: obs-studio can do full compositing of many windows, webcams, other media sources, and scene transition stuff, and then either record or stream
<hodapp>
clever: thanks, I'll check out obs-studio... though I kind of want to see asciinema too, just not for this
<hodapp>
clever: voice recording too?
newhoggy has quit [(Ping timeout: 240 seconds)]
<Infinisil>
hodapp: OBS is basically the standard screen recording software today, it can do a lot and is free and open source too i believe. Every streamer is using it
<hodapp>
blurgh. now it shows the device, and I can see the levels jump when I make noise near the microphone, but the recordings have no sound in them
<hodapp>
and I added Mic/Aux as the source
<Infinisil>
It fails at running the command blkid -o export /dev/sde1
<hodapp>
oh, nevermind, mplayer just can't play audio anymore now that I started pulseaudio
<hodapp>
ugggggh
<hodapp>
what other movie players are out there that aren't going to install 1,375 dependencies and try to manage all my media?
<lassulus>
mpv?
pietranera has quit [(Quit: Leaving.)]
<hodapp>
grrrr, still no audio after installing PulseAudio
noam__ has quit [(Read error: Connection reset by peer)]
noam has joined #nixos
<lassulus>
maybe the device is locked? is there a real device in pavucontrol?
Jackneill has joined #nixos
<hodapp>
not sure how I'd tell
newhoggy has joined #nixos
<lassulus>
under output devices there either is something like dummy-device (which means the real device is somehow locked) or something like 'built-in audio analog stereo'
<lassulus>
also, the device could be muted
newhoggy has quit [(Ping timeout: 240 seconds)]
<hodapp>
gah, how do I even restart pulseaudio? I don't see it running via systemd or anything
koserge has quit [(Ping timeout: 240 seconds)]
<gchristensen>
its a user daemon usually
<gchristensen>
user service*
<Infinisil>
hodapp: systemctl --user
<hodapp>
oh, there we go, cmus had locked the audio device
newhoggy has joined #nixos
rigelk has joined #nixos
rigelk has quit [(Changing host)]
rigelk has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] gnidorah opened pull request #27720: qdirstat: init at 1.4 (master...qdirstat) https://git.io/v7Cst
<NixOS_GitHub>
[nixpkgs] FRidh closed pull request #27556: Use more Vulnix dependencies from pythonPackages (master...pythonpackages_vulnix) https://git.io/v7kqT
NixOS_GitHub has left #nixos []
sdf45fgf has joined #nixos
<sdf45fgf>
hi all
<sdf45fgf>
i've just installed nixos, kde5... i can't change desktop setting because it doesn't work? :(
<sdf45fgf>
everything else works except this plasma bug...
newhoggy has quit [(Ping timeout: 276 seconds)]
jonte has joined #nixos
joehh has quit [(Ping timeout: 240 seconds)]
cocreature has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] FRidh pushed 1 new commit to staging: https://git.io/v7Cc8
<NixOS_GitHub>
nixpkgs/staging 55357de Frederik Rietdijk: Merge remote-tracking branch 'upstream/master' into HEAD
NixOS_GitHub has left #nixos []
<srhb>
sdf45fgf: Can you elaborate? You're not giving kde people very much to go on. :)
newhoggy has joined #nixos
* srhb
personally knows nothing about it
newhoggy has quit [(Ping timeout: 240 seconds)]
Ivanych has quit [(Ping timeout: 240 seconds)]
<sdf45fgf>
srhb, well, i've just installed nixos with kde, i log in to kde desktop, then i click right button of the mouse on the desktop
<sdf45fgf>
srhb, then "Configure desktop"
<sdf45fgf>
srhb, and an empty window comes up
<sdf45fgf>
:(
<sdf45fgf>
it's just a sad bug, i think someone must have already seen it...
<ToxicFrog>
sdf45fgf: I saw that but going through System Settings worked
jgertm has joined #nixos
<sdf45fgf>
ToxicFrog, hehe how to change desktop throught system settings? i tried that but i couldn't find a way :D
<pie__>
how do i get the thing to pass nix-shell -p from a thing in nix-repl?
<sdf45fgf>
a related question is, how to get up and running with nixos in the quickest way possible? does someone knows a wonderful tutorial that explains how to use it quickly?
<Infinisil>
okay, the error i was getting before was just a stupid mistake by me.. I'm having another problem now though
tokudan has joined #nixos
<srhb>
pie__: The thing is the -p argument, without nixpkgs.
<pie__>
huh.
<srhb>
pie__: (The thing is also called the attribute)
<pie__>
then why isnt it working. *scratches head*
<srhb>
pie__: Please explain what you're trying :)
<srhb>
Judson: Looks like you might benefit from asking cstrahan if he'll have time to work it through with you in the near future?
<babic>
LnL: are you LnL7 on github?
<LnL>
yep
<babic>
Awesome. I'm having trouble with your golang project example, I'm getting package github.com/lnl7/foo: cannot find package "github.com/lnl7/foo" when running nix-build default.nix
<Judson>
srhb, the problem is that what cstrahan is asking for is mostly a direct contradiction from the direction I was taking from zimbatm
<LnL>
babic: that repo doesn't exist, where did you find that?
<srhb>
Judson: Guess you need to put those two in the same discussion then. :)
newhoggy has joined #nixos
<LnL>
oh right, that
<Judson>
srhb, I think I could get a hold of zimbatm, but not sure about cstrahan
<srhb>
Judson: And you might also want to explain why those two approaches are in contradiction.
<srhb>
Judson: I mean, it's up to you, but I think it's obvious that you'll have to either mediate yourself or get someone else to do it, to resolve everything between everyone. :)
<srhb>
May the rubyist contributor win. ;-)
<Judson>
Is that how the governance works? I'm ultimately unclear on how the decision to merge gets made.
<Judson>
Or rubyest even ;)
<srhb>
Ultimately I don't think there's a clear policy. You convince people to become in agreement and there's no need for governance.
<srhb>
Rubyest, yes :-)
newhoggy has quit [(Ping timeout: 260 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] edolstra pushed 4 new commits to release-17.03: https://git.io/v7CRP
<NixOS_GitHub>
nixpkgs/release-17.03 0d61f5f Eelco Dolstra: Revert "diffoscope: wrap executable and include tools in PATH"...
<NixOS_GitHub>
nixpkgs/release-17.03 5db121d Eelco Dolstra: diffoscope: Move all required tools into pythonPath...
<LnL>
babic: hmm weird, it failed the first time but not the second
<Judson>
I'm good with a mediation, but I don't know how to get ahold of the interested parties.
<Judson>
As far as I can tell, cstrahan was a drive by - hasn't been back in a couple weeks.
<srhb>
Judson: Ping everyone you think is relevant in the PR for now and explain 1) why you can't cater to both opinions 2) why you think x is the better choice 3) that parties voicing their opinion need to make themselves available in order for the PR to progress 4) that if they can't, you'll need recommendations for others who can assist in bringing it to fruition etc.
<srhb>
I mean, it's all just communication. Not easy, but 17 days of silence is unnecessary. :)
<babic>
LnL: I tried it and it passed. I deleted the dir and unpacked again then tried multiple times again and now it's failing every time. Very weird
<LnL>
yeah that's not supposed to happen, let me see why
newhoggy has joined #nixos
<cstrahan>
Oh, hey Judson.
<Judson>
Hey :)
<cstrahan>
Sorry. I've been working 14+ hour days for a while now, and I'm also chronically ill, so it's difficult to be as engaged as I'd like, nor as consistently
<Judson>
I hear you. My end of this has mostly been the few hours on weekends I can scrape together.
newhoggy has quit [(Ping timeout: 240 seconds)]
<cstrahan>
I hope I didn't put you off on that PR. Feel free be beat me over the head on IRC or GH if it feels like you're being ignored. I'm sort of in "put out the fires in the towns where the townspeople are screaming the loudest", if that metaphor makes any sense.
<Judson>
It does indeed.
<Judson>
And I sympathize: I tend to also feel like "hey, reach out!" and at the same time I hate to pester.
<srhb>
Is anyone here using Ceph and feel like upversioning it and making NixOS modules for it with me?
<srhb>
I'd like to bounce ideas off someone especially.
digitus has quit [(Quit: digitus)]
jgertm has quit [(Ping timeout: 255 seconds)]
newhoggy has joined #nixos
<srhb>
Currently I have a functioning build of the Luminous RC where I've ripped out basically every option and made the simplest possible build. My rationale is that it will probably bitrot less, and whoever takes over (with me) can help add options and document the reason for them as we add them, hopefully preventing a ball of broken from happening again.
<srhb>
(And by basically I actually mean *every* option)
<hodapp>
can someone try installing pitivi and see if it runs for them?
<srhb>
hodapp: Sure, from where?
<hodapp>
not working for me on 17.03
<hodapp>
"Could not import 'gi'. Make sure you have pygobject available."
Ivanych has joined #nixos
<Judson>
So, cstrahan, did you see my reply to your comment?
<hodapp>
srhb: it's just in nixpkgs
<srhb>
hodapp: I meant which channel, but I'll try 17.03 and nixos-unstable then :)
<cstrahan>
Judson: I have a meeting in 20, will probably be about an hour long. Can we chat when I get back? (You quite possibly also left some feedback on the PR that I just lost track of, so I'll also take a look there)
<hodapp>
srhb: oh, 17.03
<srhb>
hodapp: broken in both17.03 and nixos-unstable
erictapen has quit [(Ping timeout: 255 seconds)]
<hodapp>
damn
<cstrahan>
Oh, lol - IRC comms race condition. Nope, haven't seen it - will look in about an hour
newhoggy_ has joined #nixos
newhoggy has quit [(Ping timeout: 240 seconds)]
<Judson>
cstrahan, cool cool. Worst case I'll be at lunch until ~90 minutes
takle has quit [(Remote host closed the connection)]
wrl has joined #nixos
<Infinisil>
bios wants a partition and efi wants one. I don't really want bios actually, but the installer script uses it anyways. Making a GPT partition legacy bios bootable isn't detected by the installer script. And since i don't know how to modify the installer script I'm pretty much powerless
<dtzWill>
Mic92: haha yeah they just recently made a go version, haven't played with it yet
<srhb>
Infinisil: Sorry, why do you need two?
lewo has quit [(Ping timeout: 276 seconds)]
<sphalerite>
Infinisil: is having another partition really that bad?
<dtzWill>
Mic92: WLLVM, it's predecessor is already in our tree
<Infinisil>
srhb: One for efi, and another one for bios
rtjure has joined #nixos
<Infinisil>
sphalerite: It's not actually needed, one should work
<Infinisil>
for both
rtjure_ has joined #nixos
<srhb>
Infinisil: And you ened the BIOS one because of some bug?
<srhb>
need*
cement has quit [(Ping timeout: 255 seconds)]
* srhb
only has the one
<Infinisil>
srhb: Nah, because it installs it anyways and there's no option to turn it off
newhoggy has joined #nixos
<Infinisil>
Well i can't turn it off at least
<dtzWill>
really glad they did it, it was on my TODO to rewrite in a native lang that could be built w/o deps, so... \o/
<dtzWill>
lol @ finding it with a typo though :D
<srhb>
Infinisil: The installer does partitioning these days? O_o
rtjure has quit [(Excess Flood)]
<srhb>
Brave new world.
rtjure has joined #nixos
<Infinisil>
srhb: No of course
<Infinisil>
it just doesn't work if it's not correct
rtjure_ has quit [(Excess Flood)]
rtjure has quit [(K-Lined)]
<Dezgeg>
what is specifically "doesn't work"?
riclima has joined #nixos
<Infinisil>
warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
riclima has left #nixos []
<Dezgeg>
so you don't have EFI enabled
<Infinisil>
Even though it does (the ESP with the LegacyBIOSBootable bit set)
<Dezgeg>
I mean the grub efi option
<Infinisil>
Dezgeg: I do
<Infinisil>
I went through all the scripts, it installs BIOS first, then EFI
<Infinisil>
setting enableEFI stuff just adds the second part
<Dezgeg>
um, no, where is it doing that?
newhoggy has quit [(Ping timeout: 240 seconds)]
<srhb>
I suppose grub might be doing something different from systemd-boot, or whatever its name is these days.
<Infinisil>
Dezgeg: nixos/modules/system/boot/loader/grub/install-grub.pl line 556 is the bios installation, before efi, which is a few lines below
<srhb>
I wasn't aware though
<Infinisil>
And I can't find a way to have efiTarget set to "only" which would do an EFI only install
<LnL>
nix-shell -i python -p python -p pythonPackages.pyyaml works
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] copumpkin pushed 2 new commits to master: https://git.io/v7C6e
<NixOS_GitHub>
nixpkgs/master 168fbde Joel Thompson: exhibitor: Fix bug with automatic instance management...
<NixOS_GitHub>
nixpkgs/master 8d8eae1 Daniel Peebles: Merge pull request #27700 from joelthompson/exhibitor...
NixOS_GitHub has left #nixos []
<qknight>
LnL: but it is not yet in python packages IIRC
<qknight>
xmlrpclib-to is what i need
<LnL>
then you would either have to use an overlay or -I nixpkgs=...
newhoggy has quit [(Ping timeout: 240 seconds)]
<nh2>
taktoa: Yea right? I always found the entire feature-detection-on-every-compile nonsense. Why not just ask the system you've built so far what it supports?
<taktoa>
yeah, it doesn't make much sense lol
Ivanych has joined #nixos
lambdael has quit [(Quit: WeeChat 1.7.1)]
<clever>
nh2: i think i saw an issue on nixpkgs about overriding the autoconf cache via stdenv
<clever>
Infinisil: and because i was constantly resizing things, the LV inside it was in over 200 fragments
<clever>
c74d: ah, so it will probably break
<Infinisil>
clever: Sounds like fun
<clever>
Infinisil: one day, one of the hdd's in the array failed, and i had no redundancy setup
<clever>
Infinisil: lost the main 500gig volume, and the /var/db/dpkg directory
<clever>
the system still "worked", but apt was hosed beyond repair
<Infinisil>
Currently I fear having something like this happen to me. While I backed up the most important stuff, there's still lots of things without redundancy
<clever>
my desktop is on an SSD mirror
<clever>
and my NAS is a raidz1 over 4 drives i think
<clever>
maybe 3
<Infinisil>
Nice
<clever>
the laptop is the only one without reduncancy, but i could always zfs send it to the NAS
<Infinisil>
While I could make some raid config with 4 different disks cobbled together, I might just buy a big array instead
fikse has quit [(Ping timeout: 240 seconds)]
<clever>
the raidz1 stuff in zfs can only use the size of the smallest disk in the array
<srhb>
It does feel dirty, but I've decided that I'm probably being irrational and tend to ignore it :-P
<Infinisil>
srhb: I mean it doesn't matter anyways after booting
MP2E has quit [(Read error: Connection reset by peer)]
<Infinisil>
I should probably optimize my zfs options for /boot then, surely there's some things i can enable/disable
MP2E has joined #nixos
<Infinisil>
atime=off
newhoggy has quit [(Ping timeout: 260 seconds)]
newhoggy has joined #nixos
<tilpner>
I need to remove an element from a set before it's evaluated (that would lead to infinite recursion). removeAttrs doesn't seem to do that, is there another way?
<tilpner>
(Or maybe I'm using it wrong)
Ivanych has quit [(Ping timeout: 260 seconds)]
<Infinisil>
tilpner: I don't know how that could work, because infinite recursion doesn't occur without the attribute being accessed: if you remove it you'll get a 'attribute doesn't exist' error
<Infinisil>
Because everything is lazy
newhoggy has quit [(Ping timeout: 260 seconds)]
MP2E has quit [(Read error: Connection reset by peer)]
MP2E has joined #nixos
mkoenig_ has quit [(Remote host closed the connection)]
newhoggy has joined #nixos
mkoenig has joined #nixos
mkoenig has quit [(Client Quit)]
mkoenig has joined #nixos
mkoenig has quit [(Client Quit)]
mkoenig has joined #nixos
newhoggy has quit [(Ping timeout: 240 seconds)]
<sphalerite>
^
justelex has quit [(Ping timeout: 240 seconds)]
hiratara has quit [(Ping timeout: 246 seconds)]
newhoggy has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to openssl-1.1: https://git.io/v7CFO
<NixOS_GitHub>
nixpkgs/openssl-1.1 8eff28c Robin Gloster: kdelibs4: add patch to build with openssl 1.1
NixOS_GitHub has left #nixos []
hiratara has joined #nixos
magnicida has joined #nixos
<cstrahan>
Judson: Hey, sorry! Got carried away in work things. Looking at the PR again...
dibblego[m] has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] NeQuissimus pushed 2 new commits to master: https://git.io/v7CFK
<NixOS_GitHub>
nixpkgs/master 0273233 Tim Steinbach: ammonite: 1.0.0 -> 1.0.1
<NixOS_GitHub>
nixpkgs/master a918521 Tim Steinbach: linux-copperhead: 4.12.3.a -> 4.12.4.a
NixOS_GitHub has left #nixos []
justelex has joined #nixos
newhoggy has quit [(Ping timeout: 268 seconds)]
<tilpner>
Infinisil - Yes, I made the wrong conclusion, it's not being evaluated by removeAttrs, but later. I'm trying to remove an item from "paths" of a buildEnv. Any idea? I can't use .override on the result (but I'm not sure how override is implemented, so that might be expected)
<cstrahan>
zimbatm: Hey, do you happen to be around?
dhess` has quit [(Ping timeout: 246 seconds)]
slack1256 has joined #nixos
<Infinisil>
tilpner: Does overrideAttrs works?
<Infinisil>
work*
<tilpner>
Infinisil - buildEnv doesn't directly produce a derivation, it goes through runCommand, so overrideAttrs is useless (might also explain why override isn't there?)
newhoggy has joined #nixos
Judson has quit [(Ping timeout: 258 seconds)]
freusque has joined #nixos
thmzlt has joined #nixos
<Infinisil>
tilpner: No idea then, why can't you modify the buildEnv paths directly?
<tilpner>
Infinisil - I put "desktopEnv" into my systemPackages. desktopEnv includes android-studio, but I want to android-studio to have access to everything in desktopEnv. I could break up this cyclic dependency, but I felt like it might be possible to make it work like this
<tilpner>
Context: I have multiple environments (via buildEnv) in my overlays, one of which includes Android Studio. AS uses a FHS-Env to get Android tools running, but that includes just the packages it needs for itself, not everything I need to run my project
<tilpner>
Now I could manually modify the AS expression to add tools I want, or I could try to have AS depend on my whole system (which is kind of ugly, but I don't know a better way) so that I have all my tools available (and don't have to change the AS expression in the future either)
earldouglas has quit [(Quit: leaving)]
<Infinisil>
tilpner: Yeah I don't think that's gonna work
<Infinisil>
That's clearly infinite recursion
<Infinisil>
At least i think that's not gonna work, and i don't know how it could
<tilpner>
But it doesn't have to be infinite recursion. If I could remove AS from desktopEnv, it would break the cycle. AS doesn't need to have itself available
newhoggy has joined #nixos
<tilpner>
If you have another idea, I'll happily try that. This all feels very wrong
<Infinisil>
tilpner: Hmm, maybe it's possible to have AS only in it's nix-shell installed, then you could have the system/user-profile as a dependency and it won't be recursive
<Infinisil>
Or wait
<Infinisil>
how about an overlay
<Infinisil>
I'm 99% sure this works with overlays
newhoggy has quit [(Ping timeout: 276 seconds)]
rigelk has quit [(Quit: leaving)]
Judson has joined #nixos
<tilpner>
This would actually be very easy, by maintaining an importable list of packages outside of a buildEnv, then importing it in both places (systemPackages and AS), because that would allow me to filter the list before it gets passed away, but that's very pretty either (I might try that though)
Judson is now known as Guest49352
<Infinisil>
tilpner: Yeah sure that works, but then you don't have packages installed with e.g. nix-env available in AS by default
<Infinisil>
doing it with an overlay would do that
<tilpner>
Oh, I don't use nix-env
<Infinisil>
Haha
MP2E has quit [(Quit: headed home, be back in a bit)]
newhoggy has joined #nixos
<tilpner>
I'm not sure what you mean. How would I do this with an overlay without nix-shell (I do want AS installed permanently)?
<Infinisil>
Misunderstood then. Yeah I had the thing you said in my mind from the beginning
erictapen has joined #nixos
<Infinisil>
tilpner: An overlay takes an old package set and generates a new one from that. You could have your new AS package in the new set be dependent on all installed packages from the old one, then it won't be recursive
<tilpner>
Hm. This AS version is already in an overlay, that would be an easy fix
<Infinisil>
Eh not sure actually
<Infinisil>
just use a list which you can reuse and it'll work
<gchristensen>
(or rather a stub similar to that, which skips the functor)
<Guest49352>
Hey, cstrahan - me too! :)
<LnL>
right
newhoggy has joined #nixos
eacameron has joined #nixos
Guest49352 is now known as judson
<judson>
Hey, cstrahan - me too! :)
kiloreux has quit [(Ping timeout: 260 seconds)]
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 3 new commits to openssl-1.1: https://git.io/v7Cj0
<NixOS_GitHub>
nixpkgs/openssl-1.1 79f77a0 Robin Gloster: Merge remote-tracking branch 'upstream/master' into openssl-1.1
<NixOS_GitHub>
nixpkgs/openssl-1.1 79427f2 Robin Gloster: pcsclite: 1.8.21 -> 1.8.22
<NixOS_GitHub>
nixpkgs/openssl-1.1 ab12e82 Robin Gloster: opensc: 0.15.0 -> 0.17.0
NixOS_GitHub has left #nixos []
<cstrahan>
judson: "me too", with respect to what exactly? :P
magnetophon has quit [(Ping timeout: 255 seconds)]
<gchristensen>
LnL: though it looks like the lib functions could benefit from a fixed point, it already sort of is -- each imports default, default imports each
<judson>
Caught up in work things
<cstrahan>
Oh, lol. My sense of context has shifted around a lot in the last couple hours. Should have connected those dots :)
<cstrahan>
Did you see the novel I wrote on your PR?
newhoggy has quit [(Ping timeout: 240 seconds)]
markus1189 has joined #nixos
<cstrahan>
@judson Everything above the fold mostly amounts to profuse apology. Ultimately, I'm for merging your PR now, subject to the bits I describe towards the bottom.
eacameron has quit [(Ping timeout: 240 seconds)]
<LnL>
gchristensen: yeah maybe, not sure if it really matters there
markus1199 has quit [(Ping timeout: 240 seconds)]
<LnL>
I could do some testing during the weekend if you want
<gchristensen>
yeah but the way it is now, my replacement of the fndoc doesn't work b/c everything imports default.nix and none of them pass args in, so the strategy is a non-starter
newhoggy has joined #nixos
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] globin pushed 1 new commit to openssl-1.1: https://git.io/v7Cjx
<NixOS_GitHub>
nixpkgs/openssl-1.1 a8dd453 Robin Gloster: tinc_pre: fix merge
NixOS_GitHub has left #nixos []
<gchristensen>
I'm going to do some playing :)
<gchristensen>
back in 30
freusque has quit [(Quit: WeeChat 1.9)]
newhoggy has quit [(Ping timeout: 240 seconds)]
<Infinisil>
Damn, nix-env -i installs every single package..
joehh has joined #nixos
newhoggy has joined #nixos
<judson>
cstrahan, 100% on your comments
<judson>
Ruby and Nix I think is incredibly promising, which is why I wanted to do all this in the first place.
<judson>
nix-shell (can be) so much better that rvm/bundler/virtualenv/nodenv etc etc
<slack1256>
where are v4l user setting stored usually?
newhoggy has quit [(Ping timeout: 240 seconds)]
<cstrahan>
judson: I can't count the number of times I updated openssl via homebrew and broke every Ruby installed due to e.g. ABI compat issues (yay! cryptic segfaults). and that's just openssl. similar sentiments towards the song and dance to get all the native C & C++ libs installed in the first place.
<judson>
Completely agreed.
joehh has quit [(Ping timeout: 260 seconds)]
<judson>
So I'd love for Nix to have solid support for all these things, and start presenting it at dev meetups/conferences.
<judson>
There's this awesome shining bridge from nix-shell to nix-ops...
<cstrahan>
:P
erasmas has quit [(Quit: leaving)]
rtjure has joined #nixos
alx741_ has quit [(Quit: alx741_)]
alx741 has joined #nixos
justelex has quit [(Read error: No route to host)]
<cstrahan>
judson - It's my hope to soon work on a "Docker for Mac" sort of thing for Nix/NixOS, so you seamlessly get a VM you can spin up NixOS containers in. I feel like that's a big edge that Docker has on us -- the ubiquity of the tool chain. That should hopefully reduce the barrier to nix-ops entry quite a bit for macOS users (which is the case for 99% of my coworkers. I'm the lone goofball running NixOS, albeit on a MBP).
justelex has joined #nixos
<cstrahan>
judson: So, regarding your PR: good for me to merge now?
<LnL>
cstrahan: you should talk to puffnfresh, he's been working on something like that
<cstrahan>
LnL: I've been watching your nix-darwin project form the sidelines -- I figured leveraging it would be great way to orchestrate VM management and related stuff
<cstrahan>
puffnfresh: Nice! I had HyperKit in my sights as well.
<puffnfresh>
cstrahan: I've got HyperKit as a remote builder with a initrd provided by Nix caches
NixOS_GitHub has joined #nixos
<NixOS_GitHub>
[nixpkgs] grahamc pushed 2 new commits to master: https://git.io/v7Wvc
<puffnfresh>
cstrahan: I think VPNKit is the way to go, I couldn't package it though
<puffnfresh>
combination of Go and OCaml :((((
<puffnfresh>
so I packaged the binaries, that works alright
<puffnfresh>
that'd probably be the solution for LnL's problems
<puffnfresh>
using VPNKit in my remote builder is a TODO for me
<LnL>
yeah probably, I'm not sure where the dhcp lases are supposed to come from right now
<cstrahan>
puffnfresh: I'm pretty swamped, so I can't promise any timely contribution, but I'll see what I can do. I think this could be some high-impact stuff.