Conversation
|
Did you try it? If some critical files aren't owned by id 0 (like all the sudoers files, lightdm... etc) you will get a bunch of errors when trying to login or run sudo or pretty much do anything. If you can show it working, I will approve |
|
It might work with |
I only tried (re)building it locally, will try shortly on bare metal, with the bash installer and maybe also the gui installer, and report back. Is there some way to check for silent issues, like something wrong that might not be evident with normal/brief usage? Thanks! |
Yup I only removed the |
This reverts commit a8496c9.
Apparently caused by `just` generating temporary bash script snippets in (now root owned) `/run/user/1001/just/just-xxxx` due to the bash shebang lines.
Rework
sudousage (do single enclosing invocations instead of multiple separate ones) to avoid it timing out and asking for password in the middle of a user's local build.Rationale is so it does not pause if they walk away for their favourite beverage while waiting only to return and be unpleasantly surprised.
The CI worked previously because github runners are passwordless sudo.
Rework the
checksum-repoandchecksum-extJustfile recipes to fix CI-only failures caused apparently byjustgenerating temp bash script snippets in (now root owned)/run/user/1001/just/just-xxxxdue to the (now removed) bash shebang lines.Force (the now hidden)
just genkey- why fail when a user or CIjustwant to do it.Cleanup thoroughly when the user wants to
just clean.Mark some
justrecipes/targets as[private]so they don't show up for users injust --choosebut still still work if explicitly triggered by users/CI.Add
fzfto theREADME.mdruntime dependency list - it's currently usually not installed by default in distros like Ubuntu.Now with this PR, for users building locally multiple runs of the available
Justfiletargets/recipes likejust genkey,just clean,just do-dailyand/orjust checksum-repo,just checksum-ext, well, they "just work" :-)The CI workflows are unaffected and continue to work as before.
Tested the ISOs which were locally built, the CI built proposed ISOs and the daily ISO from the public website in gnome boxes (v50 though) and bare metal laptop, installation seemed to work on both VM/laptop for all ISOs - would not boot (post install) in VM but booted fine in hardware. Lots of things seem broken in the desktop (initial-setup and user login works) but these issues already exist in
mainbuilds (aka the public daily ISO) and are not due to the changes in this PR.