| 16 Jul 2021 |
 David Arnold (blaggacao) | This indeed seems to be a regression of the way users are plugged into profiles in https://github.com/divnix/devos/commit/d9082066f7bc5bd6a58ab55418db3d6abf4da3d6 | 16:30:39 |
 @kraftnix:matrix.org | I'll give it a test, I would normally test this kind of stuff myself by running squashimg is a PIA that takes too long :/ | 16:31:24 |
| @kraftnix:matrix.org | * I'll give it a test, I would normally test this kind of stuff myself by running quickly but squashimg is a PIA that takes too long :/ | 16:31:36 |
| David Arnold (blaggacao) | Wait a sec, I think my previous analysis is wrong. I'll look into it after some stuf here. | 16:33:29 |
| @kraftnix:matrix.org | I wish mksquashfs was parallelisable or faster :/ i mean through pcie4 nvmes at it helps but otherwise it doesn't run much faster on my laptop vs workstation | 16:34:39 |
| David Arnold (blaggacao) | I think the reason is that all profiles that are incorporated within a suite are disabled by default. So if a user is incorporated into a suite, that would be disabled as well. The reason for disabling is to avoid systemd startups that you don't need on a minimal boostrap image. | 16:35:14 |
 b12f | I'm with you that stuff is so slow. We've stopped doing automated ISO builds and instead only do them manually in our CI because it just hogs server resources | 16:35:23 |
| David Arnold (blaggacao) | In reply to @blaggacao:matrix.org
I think the reason is that all profiles that are incorporated within a suite are disabled by default. So if a user is incorporated into a suite, that would be disabled as well. The reason for disabling is to avoid systemd startups that you don't need on a minimal boostrap image. So I guess if users.operator is also within suites (anywhere) it will get filtered. | 16:37:02 |
| @kraftnix:matrix.org | Also the fact that I nearly always have to run flk iso with GC_DONT_GC=1 is mildly annoying | 16:37:14 |
| @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
So I guess if users.operator is also within suites (anywhere) it will get filtered. it does not | 16:37:37 |
| David Arnold (blaggacao) | Oh yeah, I had that one, too, once. | 16:37:38 |
| @kraftnix:matrix.org | direct importing the user works | 16:37:43 |
| @kraftnix:matrix.org | In reply to @b12f:pub.solar
I'm with you that stuff is so slow. We've stopped doing automated ISO builds and instead only do them manually in our CI because it just hogs server resources i complain about it, but my min setup takes ~2mins on my workstation vs ~5mins on my laptop. i am glad pcie4 nvme is so much nicer, well worth the money, it literally is almost 3x faster than the nvme's in my laptop | 16:40:09 |
| David Arnold (blaggacao) | community branch is gone -- please submit pull requests with your examples to core in the "In the Wilde" section. | 17:53:08 |
| David Arnold (blaggacao) | Please not: squashed divnix/digga/develop (because of quite some fixup commits) in preparation for merging back into master | 18:15:12 |
| David Arnold (blaggacao) | * Please note: I squashed divnix/digga/develop (because of quite some fixup commits) in preparation for merging back into master | 18:15:19 |
| David Arnold (blaggacao) | nixConfig module and patchedNix overlay have become optional outputs of digga: https://github.com/divnix/devos/pull/344/commits/4e137065c1eb47903e15f3bd91b584f9949cb675 | 21:17:41 |
| David Arnold (blaggacao) | maybeUpdate (if you wish to use them) | 21:17:59 |
| David Arnold (blaggacao) | * Please maybeUpdate (if you wish to use them) | 21:18:09 |
| David Arnold (blaggacao) | * Please maybeUpdate (if you wish to use them) -- I hpe we can connect digga's CI soon with a cache, so that the patched nix will be fetched from cache. | 21:19:40 |
| David Arnold (blaggacao) | * Please maybeUpdate (if you wish to use them) -- I hope we can connect digga's CI soon with a cache, so that the patched nix will be fetched from cache. | 21:19:48 |
| 17 Jul 2021 |
 fufexan | hey guys! I'm implementing the changes the new docs on FUP describe. now, I've come to changing a few things, mainly doing away with exporters.* and instead having a uniform export* name for different functions. I currently have these names, but I think the last one isn't really fitting. what do you suggest instead?
modulesFromList -> exportModules
fromOverlays -> exportOverlays
internalOverlays -> exportChannels
| 13:01:54 |
| David Arnold (blaggacao) | fufexan that's great news. I'm on the same task for digga. Can we settle on using something like https://github.com/nix-community/nixdoc/pull/25 ? So I can render the library function docs also in the digga docs? W.d.y.t.? | 13:29:19 |
| David Arnold (blaggacao) | W.r.t. the name, let me check. | 13:29:30 |
| David Arnold (blaggacao) | The last one could be:
internalOverlays -> exportPackages | 13:30:36 |
| @kraftnix:matrix.org | I had not seen nixdoc, if it does what it says on the can this is something i've been wondering why nixos doesn't already have, my solution to searching my library is to look at source code currently âšī¸, will this generate docs that can be viewed in REPL as well? so :doc lib.mapAttrsToList for example? | 13:33:38 |
| David Arnold (blaggacao) | I havn't checked. But ryamtm is vanguarding it so, I tacitly assume it's as best as it can get. | 13:34:48 |
| @kraftnix:matrix.org | Also wanted to mention, I upgraded recently and had a look into bud, it is super cool and i'm going to start merging in some of my bespoke ctl into it, great work David Arnoldđ | 13:37:39 |
| fufexan | In reply to @blaggacao:matrix.org
fufexan that's great news. I'm on the same task for digga. Can we settle on using something like https://github.com/nix-community/nixdoc/pull/25 ? So I can render the library function docs also in the digga docs? W.d.y.t.? sure thing, sounds good | 13:55:22 |
| fufexan | In reply to @blaggacao:matrix.org
The last one could be:
internalOverlays -> exportPackages great, updating now | 13:56:07 |
