!UUqahLbShAYkkrXmKs:matrix.org

DevOS

33 Members
Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga10 Servers

Load older messages

SenderMessageTime
2 Dec 2021
@blaggacao:matrix.orgDavid Arnold (blaggacao)Now, how do we make sure, that we actually use them?15:22:26
@janus:dark.fijanus joined the room.16:01:14
@janus:dark.fijanusyou cant open PRs to nix or what? j/w16:05:43
@janus:dark.fijanusHello all, does anyone know of examples with deploy-rs to spin up a bunch of qemu nodes for testing p2p stuff our or something similar?16:10:41
@teutat3s:pub.solar@teutat3s:pub.solar
In reply to @blaggacao:matrix.org
Now, how do we make sure, that we actually use them?
Probably by pinning to a nixpkgs commit with nix nixUnstable pre-2.5 that has those changes? 		16:56:08
@blaggacao:matrix.orgDavid Arnold (blaggacao)The thing is, that we can't really force a nixpkgs version down peoples throat since that coupling has no legit basis.17:06:00
@blaggacao:matrix.orgDavid Arnold (blaggacao) we could resort back to shipping our pinned nix version again, but that brings us also back into the realm of "bootstrapping nix" problems (potentially). 17:06:53
@blaggacao:matrix.orgDavid Arnold (blaggacao) I'm not sure if the follows thing is affecting us currently. 17:07:08
@teutat3s:pub.solar@teutat3s:pub.solarBut don’t we give a starting point commit of nixpkgs with the inputs „nixos“ and „latest“?17:07:15
@blaggacao:matrix.orgDavid Arnold (blaggacao)My fix is only really neede for local pre-flight checks.17:07:25
@blaggacao:matrix.orgDavid Arnold (blaggacao)
In reply to @teutat3s:pub.solar
But don’t we give a starting point commit of nixpkgs with the inputs „nixos“ and „latest“?
Definitely, but I'd see that rather as a suggested starting point, with compatibilitiy on other versions on a best-effort basis. 		17:08:23
@blaggacao:matrix.orgDavid Arnold (blaggacao)^^ no real compat guarantees.17:08:33
@blaggacao:matrix.orgDavid Arnold (blaggacao) ^^ that also makes me think if we can create a compat catchall patch layer, so that we can maintain a central file in digga where all the compat stuff could go. A bit tricky, but collecting it structurally and from the community this way, might at least push the boundaries of what "best-effort" actually means. 17:09:47
@blaggacao:matrix.orgDavid Arnold (blaggacao) (not only for nix,but also for other things that exhibit drift across nix / hm /dawin versions) 17:10:19
@jwwygoda:matrix.orgJarosław Wygoda joined the room.21:58:29
@jwwygoda:matrix.orgJarosław WygodaHi all! I'd like to to build an sd-aarch64 image on x86_64 machine. nixos-generators uses --argstr to specify the target system but it doesn't seem to be compatible with flakes [2]. Is there some workaround for this issue? [1] https://github.com/nix-community/nixos-generators/blob/ea58f35cba7365b2a661f2bd17fb35cbc7bff572/nixos-generate#L158 [2] https://discourse.nixos.org/t/passing-options-to-flakes/757922:17:13
@danielphan.2003:matrix.org@danielphan.2003:matrix.org
In reply to @jwwygoda:matrix.org
Hi all! I'd like to to build an sd-aarch64 image on x86_64 machine. nixos-generators uses --argstr to specify the target system but it doesn't seem to be compatible with flakes [2]. Is there some workaround for this issue? [1] https://github.com/nix-community/nixos-generators/blob/ea58f35cba7365b2a661f2bd17fb35cbc7bff572/nixos-generate#L158 [2] https://discourse.nixos.org/t/passing-options-to-flakes/7579
Add boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; to your host config and it should be able to compile. 		22:52:38
3 Dec 2021
@jwwygoda:matrix.orgJarosław Wygoda

I've already done that. I'm getting error: Package ‘uboot-rpi_3_defconfig-2021.04’ in /nix/store/bwi8ibq0f0phc01cd6mqsz5hfm27zwgr-source/pkgs/misc/uboot/default.nix:101 is not supported on ‘x86_64-linux’, refusing to evaluate. when executing bud build rpi3 sd-aarch64. nixos-generators suggest using the --system flag. I don't know how to pass it to bud.

https://github.com/nix-community/nixos-generators/tree/ea58f35cba7365b2a661f2bd17fb35cbc7bff572#cross-compiling

09:41:38
4 Dec 2021
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orghttps://github.com/NixOS/nix/pull/557706:02:53
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgpoggers06:02:56
@blaggacao:matrix.orgDavid Arnold (blaggacao)

Right associativity has an interesting use case in designing small DSLs around nix use cases

20:28:11
@blaggacao:matrix.orgDavid Arnold (blaggacao)^ would have been my comment, if I could.20:28:35
@blaggacao:matrix.orgDavid Arnold (blaggacao)* ^^ would have been my comment, if I could.20:28:42
@blaggacao:matrix.orgDavid Arnold (blaggacao) Gytis Ivaskevicius: maybe you remembered when I tried some in fup once. These had been quite bit cleaner had there been right associativity. 20:29:32
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Gytis Ivaskevicius: maybe you remember when I tried some in FUp once. These had been quite bit cleaner had there been right associativity.20:29:59
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Gytis Ivaskevicius: maybe you remember when I tried some in FUP once. These had been quite bit cleaner had there been right associativity.20:30:04
7 Dec 2021
@kraftnix:matrix.org@kraftnix:matrix.org

hey all, is anyone having issues with the latest digga where the deploy flake input is no longer following digga's nixpkgs.follows when using deploy.follows = "digga/deploy in a devos-like setup?

not sure if I explained that well, basically since updating from a55450a16d362b6e1c50bb4025aaa604b385d3ba to latest on main, I suddenly have a duplicated nixpkgs which only deploy uses.

19:23:58
@kraftnix:matrix.org@kraftnix:matrix.org I also suddenly have three different flake-utils in my lockfile as well, i tend to make all my flake inputs use the same inputs as each other to reduce the size of my closures (particularly for nixpkgs, but I like to do it for all), and this latest updates has introduced a lot of duplicates where I haven't had any for months 19:27:34
@kraftnix:matrix.org@kraftnix:matrix.org

so the only way I managed to workaround and get my devos to behave like it used to (force all inputs to be followed correctly) was to add this horrible best in my inputs:

      deploy.url = "github:serokell/deploy-rs";
      deploy.inputs.nixpkgs.follows = "latest";
      deploy.inputs.utils.follows = "flake-utils-plus/flake-utils";
      digga.inputs.deploy.follows = "deploy";
      digga.inputs.flake-utils.follows = "flake-utils";
      digga.inputs.flake-utils-plus.follows = "flake-utils-plus";
      digga.inputs.beautysh.follows = "beautysh";

      flake-utils.url = "github:numtide/flake-utils";
      flake-utils-plus.url = "github:divnix/flake-utils-plus";
      flake-utils-plus.inputs.flake-utils.follows = "flake-utils";

      bud.inputs.beautysh.follows = "beautysh";
      beautysh.url = "github:lovesegfault/beautysh";
      beautysh.inputs.nixpkgs.follows = "nixos";
      beautysh.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      beautysh.inputs.poetry2nix.follows = "poetry2nix";
      poetry2nix.url = "github:nix-community/poetry2nix";
      poetry2nix.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      poetry2nix.inputs.nixpkgs.follows = "nixos";

as well as changing all other follows that use flake-utils from digga/flake-utils-plus/flake-utils to flake-utils-plus/flake-utils, it's pretty nasty and I'd rather not have to define these dependencies in my flake inputs when I don't really care about them that much (such as beautysh, poetry2nix) and i'd rather keep following digga's fu and fup without having to deal with the inputs myself, does anyone know why this change might have happened?

19:49:59
@kraftnix:matrix.org@kraftnix:matrix.org *

so the only way I managed to workaround and get my devos to behave like it used to (force all inputs to be followed correctly) was to add this horrible beast in my inputs:

      deploy.url = "github:serokell/deploy-rs";
      deploy.inputs.nixpkgs.follows = "latest";
      deploy.inputs.utils.follows = "flake-utils-plus/flake-utils";
      digga.inputs.deploy.follows = "deploy";
      digga.inputs.flake-utils.follows = "flake-utils";
      digga.inputs.flake-utils-plus.follows = "flake-utils-plus";
      digga.inputs.beautysh.follows = "beautysh";

      flake-utils.url = "github:numtide/flake-utils";
      flake-utils-plus.url = "github:divnix/flake-utils-plus";
      flake-utils-plus.inputs.flake-utils.follows = "flake-utils";

      bud.inputs.beautysh.follows = "beautysh";
      beautysh.url = "github:lovesegfault/beautysh";
      beautysh.inputs.nixpkgs.follows = "nixos";
      beautysh.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      beautysh.inputs.poetry2nix.follows = "poetry2nix";
      poetry2nix.url = "github:nix-community/poetry2nix";
      poetry2nix.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      poetry2nix.inputs.nixpkgs.follows = "nixos";

as well as changing all other follows that use flake-utils from digga/flake-utils-plus/flake-utils to flake-utils-plus/flake-utils, it's pretty nasty and I'd rather not have to define these dependencies in my flake inputs when I don't really care about them that much (such as beautysh, poetry2nix) and i'd rather keep following digga's fu and fup without having to deal with the inputs myself, does anyone know why this change might have happened?

19:50:23

Show newer messages

Back to Room ListRoom Version: 6