| 16 Jul 2021 |
 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 |
 Narice | Hey! I cannot build my system after doing a flk update right now, is there something going on right now? I posted an issue on GH with all the info ;) | 15:10:26 |
| fufexan | David Arnold: is this how I should proceed with the fup docs as well? https://github.com/divnix/digga/blob/develop/doc/mkFlakeOptions.md | 15:45:51 |
| fufexan | also, for inline synopsis https://github.com/divnix/digga/blob/develop/src/generators.nix#L4-L10 | 15:46:41 |
| David Arnold (blaggacao) | In reply to @fufexan:matrix.org
David Arnold: is this how I should proceed with the fup docs as well? https://github.com/divnix/digga/blob/develop/doc/mkFlakeOptions.md fufexan this is nixos-autogenerated file from the module system, so it's not the relevant syntax for library docs. | 15:52:10 |
| David Arnold (blaggacao) | The nixdoc "syntax" is:
/* This function does the thing a number of times. */ myFunction = # The thing to do thing: # How many times to do it n: doNTimes n thing
| 15:53:08 |
| David Arnold (blaggacao) | * The nixdoc "syntax" is:
```
/* This function does the thing a number of times. */
myFunction =
# The thing to do
thing:
# How many times to do it n: doNTimes:
n thing
``` | 15:53:51 |
