cole-hMatthew Kenigsberg after y'all had to drop @tomberek had one more thought that may be worth weighing WRT migration

The most-immediate cause of the _nixbldN errors may be the nixbld group holding on to GroupMembership entries for the deleted users.

I think he ran something like dscl . delete /Groups/nixbld GroupMembership _nixbld1 _nixbld2 _nixbld3 _nixbld4 to clean them up, which should mean the daemon won't try assigning builds to the clobbered users.

I'm still chewing on whether that's useful...

• It does give us something like a one-liner to get affected Nix installs working (as long as they had at least 5 build users)
• If something was built into Nix-nix that could fully fix up the users, the above oneliner could be chained with something to update Nix
• But without that feature, I do worry a little that publicizing it as a workaround may also lead people to avoid dealing with the UIDs of the remaining users and leave themselves open to a repeat of the same problem on near-future macOS updates?

I also looked at the 2nd install experience and (with the asterisk that this was on the pre-catalina macbook) after installing 2.18.5 once, both the 2.18.5 and 2.24.2 installers failed before the user stage on the check for existing shell profile backups.

That has me leaning towards not shimming the migration script into the installer, or at least saving that for a followup. Even if I shimmed it in before that check, I don't think it sends the right impression if an install that ultimately fails early does indeed still mutate these users (whether or not we're telling those users to fix it that way or not).

In reply to @abathur:matrix.org
I came down with some kind of stomach bug yesterday afternoon and am pretty wiped out anyways.

@abathur:matrix.org / @matthewkenigsberg:matrix.org Would it be possible to get a new release into the prerelease branch at some point before our next meeting? We've been seeing an uptick of issues reported on our repo despite being installed from the experimental repo at the behest of devenv docs (likely because the old version currently in the prerelease branch doesn't have the proper cargo metadata set so errors are still being told to file issues against DetSys instead of the experimental installer)

Looking at this now. Good news, I think.

It looks like the workflow that updates prerelease ~would have automatically picked up our May bump if we hadn't clobbered hydraJobs.build in the process :)

https://github.com/NixOS/experimental-nix-installer/commit/4993d8c94679087033ed9df327e44ac4773df38b#diff-206b9ce276ab5971a2489d75eb1b12999d4bf3843b7988cbe8d687cfde61dea0L208

I should be able to restore that easily enough as long as the builds succeed, but I'm hoping Matthew Kenigsberg can take a peek and maybe remember if there was a reason to drop the attr or if this was just an oops during conflict resolution?

(Eval ran okay when I pointed hydra at a fix branch; not sure how quickly it will get to the first build. It looks like the "Generate Installer Script" job got disabled for 60-days of repo inactivity over the summer, so it won't automatically start picking up the new eval until we enable it. I'm building #.hydraJobs.build.x86_64-darwin locally as a sanity check but I don't think it'll fail.)