<infinisil>
Well it's exposed as the order of attrNames, but I guess it can be considered an implementation detail, as nothing should break horribly if it's changed
<samueldr>
I think AAAAAASomeThingsFailToEvaluate would :)
<infinisil>
Hehe yes
<samueldr>
(and the equivalent ___please-fail of mobile-nixos)
page has quit [Read error: Connection reset by peer]
lightbulbjim has quit [Quit: Connection closed for inactivity]
alp has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.8]
lovesegfault has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
<hyperfekt>
The stalebot message is confusing to me. "Someone will have to do this at most twice a year if there is no other activity." Or what? What purpose does that serve, mechanically? Removing the stale tag? Preventing closure of the issue?
FRidh has joined #nixos-dev
__monty__ has joined #nixos-dev
orivej has joined #nixos-dev
<andi->
I really don't like how the bot marks issues as stale that are documenting some future improvement / are a tracking issue of some sort. Tasks don't magically become obsolete by waiting / closing an issue. Is there some label we can set to make it ignore those?
<tilpner>
Hey infinisil, didn't you have a mkOption type for JSON-serialisable data which was more specific than types.attrs?
<tilpner>
(Skimmed rfcs#42 which links to a few PRs, but they didn't agree on a single type)
<tilpner>
infinisil: Ahh, so we probably don't want to scatter definitions of this all over nixos/modules. So keep using types.attrs for now, and replace when your implementation is merged?
<infinisil>
Yeah probably, maybe `types.uniq types.attrs` is better though, because merging is messed up with that type
<tilpner>
I saw #87871, but maybe it alright if the module is likely to only have one definition site
<JJJollyjim>
are there any sort of data exports from hydra.nixos.org available?
<JJJollyjim>
i want to analyze some build times
<JJJollyjim>
but a single request to /job/:project/:jobset/:job/build-times takes well over 2 minutes
<JJJollyjim>
and usually just 500s
<gchristensen>
JJJollyjim: if you have 3-400g of disk space, I can send you the postgres database. otherwise, if you send me a query, it could be run
<JJJollyjim>
would love to get that data for all nixos tests if possible, but that would take a full 24h (without the 500s and the crashing the server for everyone else)
page has joined #nixos-dev
<JJJollyjim>
omg that'd be fantastic, what's the best way to transfer it?
<gchristensen>
JJJollyjim: heh, a very good and hard question :P
<gchristensen>
it is only about 30g, and becomes like 3-400g once loaded
<gchristensen>
I'm interested in seeing what you come up with :)
<LnL>
FYI there's also a smaller dump which has an imported size (with indexes) of about 20g
<JJJollyjim>
this'll be good for now :)
dongcarl has joined #nixos-dev
<LnL>
gchristensen: anything I can do to help resolve the channel scraper issue?
<gchristensen>
maybe a rewrite :P I have no idea what is wrong with it
<gchristensen>
I guess I could kick it over as a short-term thing
<LnL>
I can do that
<LnL>
I've been running it locally to see if I could reproduce it but it's doing fine so far
arcnmx has quit [Quit: Idle for 30+ days]
regnat[m] has quit [Quit: Idle for 30+ days]
julm_ has joined #nixos-dev
julm has quit [Ping timeout: 260 seconds]
julm has joined #nixos-dev
julm_ has quit [Quit: leaving]
<Ericson2314>
niksnut: thanks for merging that other PR!
<Ericson2314>
We just opened up a WIP https://github.com/NixOS/nix/pull/3649 that (once it is done) will be the culmination of all the enum and string tightening work
<{^_^}>
nix#3649 (by meditans, 14 minutes ago, open): WIP: ValidPathInfo: make ca field a proper datatype
orivej has quit [Ping timeout: 246 seconds]
cole-h has quit [Quit: Goodbye]
phreedom has quit [Remote host closed the connection]
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
phreedom has joined #nixos-dev
justanotheruser has joined #nixos-dev
<cole-h>
andi-: I think a "tracking" label that is ignored by the stale bot would be a good idea (like it already does for the security-labelled issues)
<cole-h>
Do committers have the permissions to create labels, or only admins?
<andi->
Comitters should be able to create them. It did work for me in the past.
Cale has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
<Valodim>
what's the typical time before staging-next and/or staging are merged to master?
<Valodim>
is there some schedule, or just when it "feels ready"?
<lassulus>
btw, maybe someone wants to give some feedback here: https://github.com/NixOS/nixpkgs/pull/89331/files I want to extend make-disk-image but Im unsure whats the current convention. I wanted to use options for most of the parameters but transition could be difficult so I postponed that for now
<lassulus>
also nothing else in nixos/lib uses options but I'm unsure why
<samueldr>
lassulus: I was working on a new infra for this, being test-driven (successfully) in mobile nixos
<samueldr>
oh, that's not even the image creation thing I was thinking about, there's more than one?
<lassulus>
could be?
<samueldr>
I had the sd image one in mind
<lassulus>
ah, this is for the disk-image which is used by nixos-generators and openstack and other similiar image types
<lassulus>
maybe it would be better to combine those to a common image builder
<lassulus>
so many partition script everywhere, I guess there is much to gain from finalizing something like nixpart or disko to generalize the disk partitioning stuff
<LnL>
that did the trick?
<manveru>
well, at least it started to build...
<samueldr>
lassulus: yeah, though note that I while it's another implementation, my intent was to make it *the* implementation at some point
<manveru>
it's slow as hell, so i'll know later :)
<samueldr>
the main goal is to have discrete composable artifacts
<samueldr>
but something that has been put on the backburner is to allow the scripts to be merged in one "mega derivation" if needed, though not sure how easy it's going to be
<samueldr>
(the main reason you'd merge into a big script for one derivation is hydra size limits)
<manveru>
LnL: ok, nevermind, that only helps if you really have kvm i guess :P
<lassulus>
samueldr: I was thinking more in the direction to have a function to generate all types of images based on the nixos-config you give it
<samueldr>
limiting to building a nixos config is... limiting
<samueldr>
but at the same time, I understand that it reduces the features required
<lassulus>
hmm, but what else is the minimal building ground?
<samueldr>
leave that to the users of the filesystem building tool with a good escape hatch
<samueldr>
the way it's implemented here is that you're given the ability to run commands to fill a folder, and that folder is the root of the filesystem
<samueldr>
and then filesystems are independent of the actual partitioning scheme
<samueldr>
this is relatively important to keep partitions and disk images separate; on a good chunk of mobile devices you can't just use a full disk image
<lassulus>
so something like linkFarm but it outputs an image/tarball/etc ?
<samueldr>
kind of
<samueldr>
this also gives better encapsulation for more complex schemes, you can put that same filesystem derivation in an mbr, gpt, lvm, luks based infra
<samueldr>
also something to keep in mind, the generic mainline "arm" sd images need to be able to control some properties of the partitioning, mainly the ability to create a gap without creating a partition
<lassulus>
seems like a rabbit hole to spend a lot of time on. So my problem is, there hasn't been much improvement on the current state, I see the long term gains of having low level functions to generate different kinds of "packed up directories" but I want to have near future gains :D
<gchristensen>
lassulus: sgtm :)
<samueldr>
lassulus: yes, sorry, your changes right now are good, but I wanted to make you aware of other long term improvement effort
__monty__ has quit [Quit: leaving]
<samueldr>
and lassulus, please continue improving the current state, but for a big breaking change it might be good to get a proper discussion before starting because of the different aspects that need to be accounted for
<samueldr>
and I'm definitely not saying my approach is the only way to go, only that it exists :)
<lassulus>
samueldr: thanks, your ideas sound very cool to me. I'm just unsure how to progress because I feel there a lot of usecases I don't see and a general solution would be good. But there needs to be an migration path
<samueldr>
definitely!
<samueldr>
I know that if it was my solution, my solution would be a new API set, and a compatibility shim would replace the current implementation
<lassulus>
I was thinking about the same. But pulling something like this alone seems like a mayor task, since there also seems to be a previous attempt which somehow lost track: https://github.com/NixOS/nixpkgs/projects/5
<samueldr>
yeah
<samueldr>
I all had that in view when thinking about the way I implemented mind
<samueldr>
mine*
<lassulus>
maybe we could have something like a working group for images? not sure how to organize something like that. I also don't want to have a new gremium which stands in the way of new ideas
<samueldr>
gremium?
<samueldr>
ah
<samueldr>
Gremium n (genitive Gremiums, plural Gremien)
<samueldr>
committee
<samueldr>
body (often political)
<samueldr>
your german's leaking :)
<lassulus>
ah yes my german is leaking :D
alp has joined #nixos-dev
<ajs124>
l4wlc0pter
<ajs124>
seems like I'm changing that password 🤦♂️
<samueldr>
oh no
<infinisil>
Lol
globin_ has quit [Ping timeout: 260 seconds]
globin_ has joined #nixos-dev
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]