<samueldr>
in my eyes you're kinda the best one to find everything wrong with modules :)
<infinisil>
I'm a bit conflicted on this PR, because on one hand the NixOS checked config is nice, but on the other hand I'm not sure if it's worth adding almost 40 new options for something that will be used by very few
<samueldr>
yeah, I was wondering if this would affect the speed
<samueldr>
at a glance, I think they create xml strings by concatenation, isn't there a way to create XML from structured attrsets?
<samueldr>
(that's lazy-me not even looking things up)
<infinisil>
Unfortunately builtins.toXML doesn't do that
phreedom has quit [Remote host closed the connection]
<infinisil>
(I just checked myself earlier)
phreedom has joined #nixos-dev
<samueldr>
ah, thanks
<samueldr>
though, for the options, is there an issue/meta-issue tracking whatever is being done to reduce the issue of having too many options?
<samueldr>
I kinda hope one day to have everything possible through nix :/
<infinisil>
I don't know of any :(
<infinisil>
A possibly better alternative to these 40 new options is to do something similar like I did in #41467
<infinisil>
This only adds 1 option, but is better than just using a string as a config file. Like this you also get the guarantee of a syntactically correct file.
<samueldr>
infinisil: yeah, such a thing could very well work, they seem like a bright individual, they probably can run with the idea
<infinisil>
Maybe it's possible to run thermald on the config file during build time to check whether the options are correct
<samueldr>
infinisil: lazy-me again: I don't think there's documentation *about* structuring modules that way, right?
<infinisil>
Nope, not that I know of either
<samueldr>
okay, then please indulge a bit of questioning :)
<infinisil>
I am the first I see try this
<infinisil>
Will do
<samueldr>
would they show up under `man configuration.nix`?
<infinisil>
In my znc PR it only shows 1 option, and the user is asked to look up available ones in the packages docs
<samueldr>
hmmm, ah right, it's all "non-binding", "just" outputting the attrsets structured for their conf format
<samueldr>
right?
<infinisil>
Yup pretty much
<samueldr>
would it be realistic to figure out a way to make it still be one option, but be introspectable?
<infinisil>
Hmm..
<samueldr>
not *forcibly*, but a well-intentioned contributor could document available options
<samueldr>
then (with changes possibly) they could show up in configuration.nix
<infinisil>
Maybe an example of a full config?
<infinisil>
Oh I see
<samueldr>
I'm mostly thinking about options.html and man configuration.nix
<samueldr>
(and a bit of spitballing)
<infinisil>
Actually that doesn't sound as impossible as I first thought it would
<{^_^}>
Use `,` to list all commands, `,foo = Foo!` to define foo as "Foo!", `,foo =` to undefine it, `,foo` to output "Foo!", `,foo somebody` to send "Foo!" to the nick somebody
<ekleog>
hmm was there no command to ask {^_^} to tell something to someone when they come back on IRC?
<MichaelRaskin>
I think this list is about abbreviations, and other functionality is not described here
<ekleog>
!help
<ekleog>
hmmm no that's not it…
<ekleog>
,tell ekleog test
<{^_^}>
ekleog: I'll pass that on to ekleog
<ekleog>
,tell abc123azerty
<{^_^}>
ekleog: 21 seconds ago <ekleog> test
<{^_^}>
ekleog: I'll pass that on to abc123azerty
<ekleog>
hmm obviously it's +r so I can't actually test with abc123azerty without registering it… anyway, it looks like it works, thanks MichaelRaskin!
<infinisil>
ekleog: I'll improve the bots docs eventually when I have more time :)
<ekleog>
:D
__Sander__ has quit [Ping timeout: 256 seconds]
__Sander__ has joined #nixos-dev
<srhb>
Is it intentional that colons have become illegal in hydra jobset identifiers?
Lisanna_ has joined #nixos-dev
<srhb>
huh, or maybe it's numeric jobsets...
init_6 has joined #nixos-dev
MichaelRaskin has quit [Quit: MichaelRaskin]
<LnL>
that doesn't count
orivej has joined #nixos-dev
lopsided98 has quit [Ping timeout: 240 seconds]
lopsided98 has joined #nixos-dev
Drakonis has joined #nixos-dev
vcunat has joined #nixos-dev
<aminechikhaoui>
is there a way to make builtins.fetchMercurial/nix-prefetch-hg return the same store path :( ?
<manveru>
aminechikhaoui: no, they're completeley different ways of fetching :|
<gchristensen>
y'all nerdsniped me in to trying to do this testing with qemu and I'm not sure it was the right choice
<vcunat>
:-)
<aminechikhaoui>
manveru: yeah bummer, it makes my hydra binary cache useless
<aminechikhaoui>
was looking if there was a hack to make them compatible
<vcunat>
aminechikhaoui: builtins.fetch* can't work with binary caches
<vcunat>
in principle
<vcunat>
At least in the variant where you call them without a fixed hash.
<aminechikhaoui>
yeah well a rev is equivalent I think
<aminechikhaoui>
niksnut: would it make sense to switch hydra to use builtins.fetch* instead of nix-prefetch-* ?
<vcunat>
I assumed hydra jobsets are using something that caches the repository.
<aminechikhaoui>
vcunat: yeah, same for the builtins, it just uses a different path .cache/nix/{hg/git}
<aminechikhaoui>
hydra also stores the metadata uri/branch/rev etc in the db I think, but that can be kept I guess
<vcunat>
some of these are shown in the UI and must be kept in some way
__Sander__ has quit [Quit: Konversation terminated!]
<niksnut>
aminechikhaoui: yeah, that would be pretty nice
<aminechikhaoui>
niksnut: cool, I'll experiment with updating the current plugins
<Dezgeg>
gchristensen: what's wrong with qemu?
<gchristensen>
doing it in nix-build specifically, I mean, where I need to mock out cachen.ixos.org and more
<niksnut>
aminechikhaoui: though vcunat is right that the scm cache is currently used in the web interface, though I'm not sure we should keep that
<Dezgeg>
the nixos test interface doesn't necessarily have to run inside a nix-build though
<aminechikhaoui>
niksnut: oh probably used in the diff thingy ?
<vcunat>
I primarily meant showing the commit hashes in evaluation listings (which should be kept). The cache part isn't something I even have access to on Hydra.nixos.org :-)
<vcunat>
so I don't know of any practical cases when it can be useful.
<vcunat>
In *our particular* case the diff thingy might benefit from being a github URL instead.
<aminechikhaoui>
vcunat: I think that part is done through the database but probably what could also be impacted is the api view (https://hydra.nixos.org/api/scmdiff)
<aminechikhaoui>
but I think if builtins.fetch* and nix-prefetch-* use the same hashing of urls for the cloned paths then we can probably make the scm folder a hydra config that can be updated to .cache/nix/
<timokau[m]>
Is there any way I can directly build something on the lucifer build machine? The ntl tests are still failing and I can neither reproduce it nor find anybody else that can.
<gchristensen>
timokau[m]: so do you have patches you want to directly test there?
<gchristensen>
I don't think hydra has a way to do it, but we might be able to sort something out for a specific patch
<timokau[m]>
gchristensen: Kind of. I could think of three things to try: 1. just repeat the build as-is, check if it is a transient failure 2. set the architecture to "generic" in the build (currently is x86 and the failure is sigint) 3. try to build gmp on that machine
<timokau[m]>
Yeah for this purpose it would be nice to be able to explicitly select a builder
<timokau[m]>
That would still require pushing experimental changes to master and waiting for a rebuild though
<gchristensen>
or creating a jobset, yeah
<timokau[m]>
That would exceed my privileges, but at least it would be an option with help of somebody that has those privileges
<timokau[m]>
Otherwise I'll just have to go the very slow route and start by setting the arch to generic. Then see if it fails at some time in the future when it happens to hit the same builder again. But maybe I'd be setting the arch to generic for no reason at all and the performance of ntl suffers
<gchristensen>
sounds painful :)
<timokau[m]>
Yes, thats why I haven't fixed the failure yet :/