sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
<worldofpeace> ma27: I'd be soo cool to have you there ✨️
drakonis__ has quit [Ping timeout: 245 seconds]
<simpson> ivan: Redirect on https://github.com/NixOS/nixpkgs/issues/66598 to this channel. A thought that occurs to me: We ought to have a generic bootstrapping flow for certain packages. This isn't the only situation where structured bootstrapping would have helped; PyPy's another case.
<{^_^}> #66598 (by nh2, 2 weeks ago, closed): dejavu-fonts-full downloads from binary cache but does not build on NixOS
<simpson> Of course, nixpkgs being what it is, there's probably already such a helper, and a section in the manual, and two wiki pages, but somehow I'm not seeing any of it.
<gchristensen> drakonis, ma27[m]: https://youtu.be/HjdurJ01he4
<aanderse> gchristensen: from this point on if someone is adding themselves to the maintainer list i should make sure they have a github id, right?
<gchristensen> please :)
orivej has quit [Ping timeout: 244 seconds]
<aanderse> figured... thought i'd just double check :)
<ashkitten> when a builder writes to $out, is it writing to a real store path, or is it writing somewhere to be copied into the nix store?
<infinisil> ashkitten: The real thing
<infinisil> Pretty sure
<ashkitten> okay
<ashkitten> my theory is, i can block on any accesses to store paths that don't exist, unless it's the output path of the current builder in which case i pass through all filesystem calls immediately
<ashkitten> (this accounts for theoretical badly behaved installers which might try to access paths inside their own store path before it exists)
<samueldr> if [[ -e $PREFIX/bin/my-cool-software ]]; then; echo "silly you, I am already installed"; fi and such I figure
<ashkitten> sure
<ashkitten> essentially it should hopefully be a small change to nix's builder internals, and everything else is done in the filesystem, which should also be easy
<ashkitten> i can give this mode a dependency on sandboxing, and it can mount the filesystem in the sandbox without affecting the real nix store
<ashkitten> which i guess means a separate fuse filesystem per builder
<ashkitten> from my uninformed peeking at nix code, though, it looks like each builder basically blocks on its own dependencies
<ashkitten> and at a structural level it doesn't seem like there's an easy way to specify non-blocking dependency build tasks
<ashkitten> anyways, the best place to start in order to verify that it's working correctly would be the filesystem
<ashkitten> oh, dangit
<ashkitten> sandboxing bind-mounts the inputs separately into the chroot
<ashkitten> maybe i can do a thing where the fuse filesystem is given a specific set of store paths and instead of this bind-mounting stuff it just passes through only those paths
<ashkitten> that seems reasonable enough
{`-`} has joined #nixos-dev
<disasm> is there any stylistic guidance on whether we should align = or not? I haven't seen it on many PR's aligned: https://github.com/NixOS/nixpkgs/pull/67806/files#diff-67264482b987c5fff5577fb322264e7fR56-R59
<worldofpeace> Yeah no aligning like that, I think there's something on that in the nixpkgs-fmt readme too
<worldofpeace> Actually there's nothing on that in nixpkgs-fmt readme, but for the sake that it's not a widely used style in nixpkgs and not everything is aligned like this I usually advise people against it. Though in certain languages it's nice, I don't think there's any kind of precedent for this in nix yet.
<worldofpeace> ^ disasm
<disasm> agreed worldofpeace, thanks for the confirmation!
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 252 seconds]
drakonis1 has quit [Ping timeout: 264 seconds]
drakonis1 has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
phreedom has quit [Client Quit]
phreedom has joined #nixos-dev
FRidh has joined #nixos-dev
init_6 has joined #nixos-dev
valebes has joined #nixos-dev
<{^_^}> #42809 (by pmiddend, 1 year ago, open): bazel build of tensorflow fails
<yorick> infinisil: I have a jupyterlab module if you're interested
<disasm> I usually try to avoid rec attrSets unless they're absolutely necessary. A lot of time the rec can be removed by moving pname/version into a let block and inheriting them in the mkDerivation instead. Is this considered good practice or not?
<yorick> disasm: what's the advantage?
<yorick> I mean, lets are also recursive :D
<qyliss> With let, you only add things you explicitly want to scope
<disasm> if I remember, clever told me there was a performance hit with using recursive attribute sets on derivations.
<qyliss> I would like to see rec removed from the language, fwiw.
<disasm> qyliss: well, things like top-level/all-packages.nix would be a lot more difficult without a rec!
<qyliss> nah, that's exactly where rec is a problem
<qyliss> It breaks overlays.
<qyliss> If you do `let self = {}; in self`, you can override a package in an overlay and have things that refer to it by alias pick it up
<qyliss> But a rec alias just copies the attribute value at definition time
<disasm> ah, that's true!
<qyliss> So now if you want to override a package consistently in an overlay you have to do it for every alias of that package, and hope more are never added.
<disasm> main reason I ask is https://gist.github.com/disassembler/6ebe829f75d04ccde28f791e8c7eeb14 is how I fixed a merge conflict in staging-next (that I created by merging a package with a version bump that used name instead of pname)
<disasm> is that a good improvement, or should I undo the removal of rec in that derivation?
<clever> disasm: i prefer `lib.fix (self: { ... })` over `rec {`
<disasm> clever: yeah, for a big attrSet I can see that being better than moving things into a let block and inheriting clever, but in this case, what do you think of the above gist?
<clever> *looks*
<clever> ah yeah, that, ive not really found a clean solution to that
<disasm> I think I'll undo the change and leave the rec for now...
<disasm> less changes are better when fixing merge conflicts on staging-next :)
<disasm> FRidh: I pushed staging-next just now fixing a merge conflict I introduced by merging a PR.
<FRidh> disasm: ok
<FRidh> disasm: by the way, I intend to merge staging-next into master today and then hopefully have one more cycle before branch-off.
<disasm> FRidh: yay!
johnny101m has quit [Ping timeout: 276 seconds]
johnny101m has joined #nixos-dev
init_6 has quit [Ping timeout: 244 seconds]
init_6 has joined #nixos-dev
<andi-> Is there some bignum implementation for Nix already? :D
<disasm> fpletz: would like to get your opinion on https://github.com/NixOS/nixpkgs/pull/66953/files before merging
cjpbirkbeck has joined #nixos-dev
init_6 has quit []
<clever> andi-: nix has floats, but no bignum
<andi-> clever: to bad
<clever> andi-: its giving me crazy ideas, if nix had bigint, could i use it to do pub/priv key math?lol
<infinisil> Encrypting passwords at eval time? :o
<infinisil> (probably better as a builtin though)
<clever> infinisil: wireguard keygen and priv->pub conversions
<andi-> clever: I am working on a ip(v6) subnet calculation module. We will probably use lists of integers now…
<clever> andi-: i already wrote code for that
<qyliss> lgo
<clever> andi-: though mine uses IFD
<infinisil> andi-: I'm pretty sure I saw this somewhere already
<infinisil> andi-: Ah here, not sure where I got it from though: https://gist.github.com/Infinisil/842168e1db442a70f18563dee1da7c4c
<infinisil> Not mine
<infinisil> (I made this for ipv4 cidr calculations though: https://gist.github.com/Infinisil/c68a2f385c6d7c52c324d529b7f1d07c)
<andi-> clever, infinisil: Thanks for the pointers but that is still far from what I want :-) I'll keep you posted
cjpbirkbeck has quit [Quit: Quitting now.]
<infinisil> I wouldn't mind somebody merging this, I think it's a good idea and ready: https://github.com/NixOS/nixpkgs/pull/67475
<{^_^}> #67475 (by Infinisil, 5 days ago, open): nixos-generate-config: Add system.copySystemConfiguration = true
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 244 seconds]
drakonis has quit [Ping timeout: 250 seconds]
drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 264 seconds]
<gchristensen> I'm looking for a couple people to try out a search index for me. anyone available?
<ivan> what does it search?
<gchristensen> docs
<ivan> sure
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
<gchristensen> okay nevermind the index is too big right now
drakonis_ has quit [Read error: Connection reset by peer]
<ivan> pkgs/development/libraries/vulkan-loader/default.nix assertion is failing after the staging merge
<infinisil> gchristensen: (feel free to ping me for testing)
<ivan> FRidh: if you `git show 96e5474329a3c2b2309872fb01b007daaf6d7bdc` you'll see how the version was moved backwards (but with newer sha256 retained), I haven't investigated if this affects more than two vulkan packages
<{^_^}> #67841 (by ivan, 1 minute ago, open): vulkan-headers, vulkan-tools: fix version
FRidh has quit [Quit: Konversation terminated!]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Client Quit]
drakonis1 has joined #nixos-dev
<clever> gchristensen: i would use label or uuid for the swap, just to make it more robust
<gchristensen> is by-path not sufficient?
<clever> gchristensen: by-path could break if the pci device is moved to another slot, or certain motherboard features are enabled/disabled
<gchristensen> none of those things are possible with Packet anyway
<clever> gchristensen: ive already seen the case where the network cards are named different on different machines, because they are in different physical slots
<gchristensen> but at any rate, how about `by-id`? /dev/disk/by-id
<gchristensen> yes, but a given chassis will never have its hardware replaced within its lifetime with a customer
<clever> i guess so, not without request by that user
<clever> by-id appears to go more on serial# of the disk, which would also be more robust, but at that point, uuid would work just as well?
<samueldr> relying on hardware path or serial number is spooky, what happens when the provider switches a failing disk?
<samueldr> hardware path, it's only less portable
<gchristensen> (1) packet doesn't replace failing disks for provisioned systems
<clever> samueldr: all data will be gone, so it wont boot anyways :P
<samueldr> not failed, failing :)
<clever> samueldr: they would have to clone all the data over first
<samueldr> some providers apparently do that
<gchristensen> (2) individual devices don't have UUIDs
<clever> and they probably cant detect that failing state, since nixos isnt running their tools
<gchristensen> Packet does install monitoring tools, nor do they do disk swaps
<samueldr> oh, right, you're bootstrapping from before the partition table has been written
<gchristensen> Packet does install *not* monitoring tools, nor do they do disk swaps
<gchristensen> guh. you know what I mean.
<samueldr> yes, yoda :)
<clever> gchristensen: LABEL=swap would be the most predictable thing, when you have not yet written things
<gchristensen> individual devices don't have labels either
<gchristensen> and I need my method to support raw devices as well as partitions
<clever> only the swap needs a label
<clever> zfs uses the pool name
<gchristensen> zfs needs stable device paths
<gchristensen> and this is more than just ZFS, this is for all provisions
<clever> gchristensen: zfs overwrites those on every import, based on a flag given to zfs import
<gchristensen> hm?
<clever> gchristensen: zpool import -d /dev/disk/by-id/ will cause zfs to look at all devices in that dir, for the named pool
<gchristensen> gotcha
<clever> and it will use the names from that dir under `zpool status`
<clever> and it will write those names back into the metadata
<gchristensen> cool
<clever> this also causes problems when booting under qemu, because it doesnt report what pci slot a virtio-blk device is under
<edef> well
<clever> so the device isnt under by-id
<clever> so zfs cant find the pool
<edef> just found a wonderful edge case in github's maintainers-can-edit-PR stuff
<clever> gchristensen: the `-d /dev/disk/by-id` i think also causes it to exclude cdrom and floppy drives, making it boot slightly faster
<qyliss> edef: do go on?
<edef> if you rebase onto master, but have a conflict, you'll be in the middle of a rebase
<edef> if you forget about this and push, you will push master to the PR branch
<edef> this closes the PR, since it has no new commits to offer
<edef> since the PR is now closed, you cannot push to it anymore
<edef> and also, you cannot reopen it, because it is empty
<edef> so finding a PR you can merge if you rebase it can turn into "well, fuck, i just hosed this one"
<edef> i should probably have a pre-push hook on my end that stops me from doing this
<edef> but argh git is enough of a mistake-prone tool without github adding silly catch-22s like this
<edef> eternally annoyed by all the weird failure modes github adds that are simply not a thing in the git email flow
<gchristensen> hmm okay clever but I think I can just stick to using by-id like this: https://gist.github.com/grahamc/4f8e935d14b46a433bd57ee5060217e6
<clever> gchristensen: and if there is only a single nvme in the machine, even /dev/nvme0n1p2 would be fine
<gchristensen> as far as I know, any time anybody has needed hardware maintenance, they were required to fully deprovision the system and reprovision
<gchristensen> yeah, that is often not true, so resolving to specific IDs is good :)
<gchristensen> clever: so other than the hardware replacement scenario, seem okay?
<clever> gchristensen: yeah
<gchristensen> cool
<gchristensen> I asked Packet about the hw replacement question *just in case* but I'm 99% certain they don't do that. I've seen very desperate customers ask about it :)
Guanin has joined #nixos-dev
valebes has quit [Ping timeout: 245 seconds]
valebes has joined #nixos-dev
valebes has quit [Read error: Connection reset by peer]
valebes has joined #nixos-dev
<ashkitten> i hope kimsufi will swap out disks that are failing if i ask
valebes has quit [Ping timeout: 258 seconds]
valebes has joined #nixos-dev
valebes has quit [Quit: Quit]
<samueldr> ivan++ for the chrome updates
<{^_^}> ivan's karma got increased to 5
<ivan> "all four chromiæ" hah
<ivan> does someone want to merge https://github.com/NixOS/nixpkgs/pull/67610 too
<{^_^}> #67610 (by ivan, 3 days ago, open): chromium: 76.0.3809.100 -> 76.0.3809.132
<samueldr> hah, oops, I hadn't looked to see if the one for master was merged
<samueldr> (build started)
<samueldr> ah, I thought quirksmode had used the ae form, but no, chromia. https://www.quirksmode.org/blog/archives/chromia_on_android/index.html
drakonis1 has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
johnny101m has quit [Remote host closed the connection]
drakonis has quit [Ping timeout: 264 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.4]
<samueldr> >> The return value is the exit status of the program as returned by the wait() call. To get the actual exit value divide by 256. See also exec.
<samueldr> (not sure how helpful it is to know that nix-prefetch-git exited with 1)
<samueldr> >> command `nix-prefetch-git /var/lib/hydra/scm/git/e582c28417f6f404a7d873adf049f236684ca28345c096ca90587e6225602a18 fc24debbb06023c79746b0b6d937ede94d6d2bf8' failed with exit status 256 (in an indeterminate location) at /nix/store/cl2yj4adnag5jfwx7srz0jav5mygymvl-hydra-0.1.0.0000000/libexec/hydra/lib/Hydra/Helper/Nix.pm line 433.
<samueldr> I just requeued an eval
johnny101m has joined #nixos-dev
<edef> Mic92: fwiw i emailed your git-series patch to joshtriplett (along with another fix)
<edef> Mic92: given that he doesn't seem to look at GitHub PRs, which i'm not too surprised about
<samueldr> ivan: :/ something's weird; evals are queued, checked (the checked time updates) but the last eval time and logs don't update
<ivan> samueldr: another thing complained it was out of disk
<samueldr> ivan: a likely possibility
<samueldr> can you link to the thing?
<samueldr> if it's a builder box then it's a coincidence I think
<ivan> I mean hydra itself but I was just guessing
<ivan> can't find the project any more
<ivan> the jobset
<samueldr> no worries, it's likely to be the first thing someone who can looks at
drakonis_ has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
<samueldr> ~ 20:24 UTC it looks like /data stopped being written to (free bytes not decreasing)
valebes has joined #nixos-dev
drakonis has joined #nixos-dev
johnny101m has quit [Remote host closed the connection]
drakonis has quit [Quit: WeeChat 2.4]
<ivan> how would I get rustPlatform to build just diesel_cli in https://github.com/diesel-rs/diesel?
beyuu has joined #nixos-dev
beyuu has quit [Remote host closed the connection]
Guanin has quit [Remote host closed the connection]
<ivan> maybe cargoBuildFlags = [ "--bin diesel_cli" ]; will work
drakonis__ has joined #nixos-dev
<ivan> how do you make a Cargo.lock file that doesn't result in `error: the lock file /build/source/Cargo.lock needs to be updated but --frozen was passed to prevent this`
<ivan> ok, I built build-support without the --frozen flag
<ivan> ah I generated a bad Cargo.lock because I had the wrong revision checked out
drakonis__ has quit [Ping timeout: 245 seconds]