<clever>
gchristensen: i just had a crazy idea, but it would require patching hydra
<clever>
gchristensen: what if your mac build agents, where also linux build agents (since they run nixos!)
<clever>
gchristensen: or even better, configure the nixos host to act like a proxy, conditionalized on the target system, so hydra thinks its 1 magic box that can run both linux and darwin
drakonis has quit [Ping timeout: 248 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
<gchristensen>
clever: :o
<clever>
gchristensen: i dont remember when it broke, but build slaves used to obey /etc/nix/machines, and could forward a build on even further
<clever>
gchristensen: so you could claim the host can run both linux+darwin, and then it will farm the darwin stuff out to its own guest
<clever>
and because hydra thinks its one machine, it wont over-allocate jobs to it
<clever>
but you cant make hydra prefer doing darwin jobs first, so a linux job may keep the machine tied up
<gchristensen>
nice
<gchristensen>
if the machines had spare CPU, I might set that up
<clever>
gchristensen: a more complex patch, would be to teach hydra about such a setup
<clever>
so hydra knows 2 machines share the compute power, and to do one or the other
<clever>
and then use speedfactor, so it prefers other linux slaves over the "mac"ish ones
<clever>
or maybe use some of the hydra-provisioner logic to dynamically add and remove the linux side
<clever>
so when they get a mac load, they vanish from the linux slave list
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
v0|d has quit [Ping timeout: 252 seconds]
v0|d has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.4]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
tdeo has quit [Quit: Quit]
tdeo has joined #nixos-dev
Jackneill has joined #nixos-dev
orivej has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
drakonis has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-dev
Synthetica has joined #nixos-dev
georgyo has joined #nixos-dev
<gchristensen>
clever: I have a small project for you, if you're inclined :)
<gchristensen>
clever: which is that sometimes run-macos-vm fails during the macos boot phase on DSMOS. I'm inclined to ignore this problem and hack around it and restart it if it fails to bring up ssh within 10min
<ekleog>
ivan: also, “force building some other package that is known to be tightly version-coupled” sounds like a good use for `passthru.tests = { fubar-still-builds = fubar; };` -- can't remember whether it's already been tested to not infinite-recurse, though ; also, the tooling doesn't already build those but at least the metadata will be there
<ivan>
thanks, PR opened
<ivan>
do I have to get the reverse dependencies for ofborg myself?
<gchristensen>
ivan: once `grahamcofborg-eval` finishes, it'll have a Details link which lists impacted packages
<gchristensen>
also, still deploying your auth grant
<gchristensen>
usually I recommend adding a comment around the version saying "when updating X update Y"
<ivan>
thanks
<gchristensen>
oops... I forgot to press "continue" on the deploy.
<gchristensen>
should be good to go, ivan
<ivan>
thanks
<gchristensen>
gutsy choice, ivan :)
<ivan>
did I @ the wrong bot
<ivan>
apparently
<gchristensen>
you @'d an organization
<gchristensen>
but more gutsy was putting so many builds in to a single incantation
<gchristensen>
each of those will run at the same time, and at the end you'll not get very good information as all the logs will be combined -- and if any of them fail, the whole result will be a fail
<ivan>
ah but I've got a log untangling network in my brain already
<ivan>
thanks nix
<pie__>
not sure whether to laugh or cry
<ivan>
crawling up my yak stack to the chromium update I wanted to do
<ivan>
I guess I'll try separate build commands in the future
<Profpatsch>
pie__: When in doubt, try both
<Profpatsch>
And then press "continue" to deploy
<pie__>
Profpatsch, ++
<pie__>
press any emotion to continue
<gchristensen>
what are we talking about?
<gchristensen>
I feel there is a critique here that would be good to hear
<Profpatsch>
we’re just joking
<Profpatsch>
Sometimes we carry our special brand of humor to the surface of official nix channels ;)
<Profpatsch>
Come join us in ##proto-n … better not
<ivan>
also, is it `build chromium.aarch64-linux`?
<gchristensen>
no, just chromium. also, it will never work on ofborg
<gchristensen>
ofborg limits builds to 1h
<ivan>
ah ok thanks
<samueldr>
ivan: chromium build has been "broken" due to a dependency not being supported on aarch64 for a small while
<samueldr>
>> error: Package ‘aften-0.0.8’ in /home/samueldr/nixpkgs/pkgs/development/libraries/aften/default.nix:16 is not supported on ‘aarch64-unknown-linux-gnu’, refusing to evaluate.
<ivan>
ah, thank you
<samueldr>
if you haven't already, and desire to help on aarch64 stuff, you might ask for acces to the community aarch64 builder, which is beefy, so helpful on longer compilations to iterate in fixing things
<ivan>
I will probably deal with any very unlikely fallout
<ivan>
thanks
<catern>
quick thought, I haven't thought it out in too much depth yet, but: flakes are separated into a list of inputs, then an outputs-function which takes those evaluated inputs. I'm guessing that maybe that's done so that the inputs can be introspected and separate evaluated and all that. But, it's a bit awkward; what if instead we had new syntax for using so-and-so flake? like |foo://bar| to use the flake referenced by foo://bar. and then
<catern>
we could have a builtin which returns a list of all the flakes used by a specific expression, and maybe another builtin to provide the actual flake inputs?
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
Jackneill has quit [Ping timeout: 244 seconds]
Jackneill has joined #nixos-dev
<niksnut>
catern: interesting idea, however you do need a way to enumerate all the inputs of a flake to compute the lockfile
<niksnut>
if flakes are imported using some special syntax, then presumably you could use this in any nix expression, not just flake.nix
<niksnut>
so it's not clear how you find all the inputs
<niksnut>
well, I guess you could parse all the nix expressions in a flake...
<clever>
gchristensen: DSMOS?, do you have a screenshot of the error?
<gchristensen>
clever: do a quick search for "Waiting for DSMOS" ;)
<gchristensen>
and before anybody else notices, note thath we shouldn't be hit by DSMOS since the macs do run on apple hardware
<clever>
gchristensen: i did run into a failure with a giant no sign once, rebooting with zero changes cleared it
<gchristensen>
no sign?
<clever>
a circle with a diagonal line thru it
<gchristensen>
I was only able to see "Waiting for DSMOS" by passing debug in the boot params
<gchristensen>
ah
<clever>
where do you set the boot params? config.plist?
<gchristensen>
I did it by hand in clover
<gchristensen>
there seem to be many reasons why it won't boot -- to the point that just issuing a reboot seems like a reasonable course of action
<gchristensen>
but if you can do better, please :D
<gchristensen>
will safe you from rebuilding libguestfs just to put the appliance in the env
<clever>
ah, i didnt look at the wrapper that closely, and thought it was setting an env var
<gchristensen>
I haven't either, but iirc it does cause a rebuild
<LnL>
clever: as for /etc adding an unsafe option for deployment purposes that overwrites stuff and doesn't perform user sanity checks would make sense for automation
<clever>
LnL: i suspect NIX_CONF_DIR may also work
<clever>
just temporarily tell nix to look elsewhere for nix.conf
<clever>
then nix-darwin wont find it in the real spot, and will happily put it there
<clever>
but behind the scenes, nix is looking elsewhere
<LnL>
sure, but the nix.* options are useless if nix.conf isn't managedf
<clever>
just temporary, while nix-darwin is creating nix.conf
<gchristensen>
I think this is just for bootstrapping
<clever>
exactly
<LnL>
trusted-public-keys must be configured in the daemon IIRC