<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.
<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
<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]
<{^_^}>
#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>
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
<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
<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
<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
<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]
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