Ahh it seems similar to yafti, but silent. Probably more limited.
Ahh it seems similar to yafti, but silent. Probably more limited.
ARegarding device rules... Our
Source: https://bugzilla.redhat.com/show_bug.cgi?id=815093#c4
70-u2f.rules is a bit wonky too, which is a separate issue to look at later... It currently requires the plugdev group. Here's what a Fedora dev said about that:Sure, we must entirely get rid of that crap. "plugdev" is a very misguided
and fundamentally wrong Ubuntuism. Fedora must not solve problems that way,
we do not put users in system groups to grant access to devices, especially
do not define non-sensical groups like: "the group of users that can plug
devices into the system".
Fedora uses individually managed ACLs for granting ordinary user access
to devices. The ACLs are seat (multiple users working simultaneously on
the same host), and they track session activity. It depends on the type
of devices how to hook up the device in the ACL handling:
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
Please just patch the rules not to use "plugdev" at all, we can do better and
don't want "plugdev" in Fedora. Thanks!
Source: https://bugzilla.redhat.com/show_bug.cgi?id=815093#c4
Bi looked into the source on pagure...
some of the default functionality it ships is definitely not helpful for us... but it could provide a semi-standard hook... that's assuming it's included in rpm-ostree images and not just on workstation, etc
some of the default functionality it ships is definitely not helpful for us... but it could provide a semi-standard hook... that's assuming it's included in rpm-ostree images and not just on workstation, etc
JI think we'd want to use it to launch yafti perhaps, more to replace the dotfile thing we're doing now
Jwe should look at it with fresh eyes though
Bexactly what i was thinking, a more "standard" way to launch yafti vs rolling our own
Bbut not urgent at all 
Jyeah when I was looking at the example was layering a codec package and I was like that's going to be a hard pass for me dawg.
AYeah it might be useful, if it's capable of running yafti on every login. Since yafti needs to re-run whenever
yafti.yml changes.Byep, that would have to be disabled for sure
Jyeah plus also it's there now by default, one less thing for us to break
AYep, let's hope it can do "every login" actions.
Bakmods: urgent
redoing first-boot: *not urgent"
redoing first-boot: *not urgent"
Jright, also this is 39 only
Jso probably post-rebase-to-official images
AI suspect that the Fedora thing will be too limited for us though. They probably only support shell stuff that doesn't require a GUI. Running before the user has logged in. Would be my guess.
Jactually, anyone got a few minutes now? let's give the board some love and milestone some crap
J
Boh sure why not
Bi'm waiting for builds so i can reboot
AI'll have a look and help in any discussions we're having about the board. 
I don't know enough about the main repos yet to say whether something is already done etc.
I don't know enough about the main repos yet to say whether something is already done etc.Jit's ok let's just capture and triage, I'll scrummaster until someone who knows what they're actually doing shows up
POne thing I've noticed about yafti: it creates the file that keeps it from rerunning regardless of how it exits. Whether you've visited all the pages, or closed it manually, or it crashes (this was happening to me because I was experimenting adding my own custom pages). Is that intentional? Seems like that behavior could be a little btter.
AWe need to sort out how to connect vscode to boxes, set up devcontainers, all of that stuff.
That's an interesting one. I've been hearing that VSCode flatpak with
remote-containers extension can run things inside podman containers very easily.JGitHub
https://fedoraproject.org/wiki/Changes/AutoFirstBootServices This is for F39 so let's investigate after the switch to official images.
AYeah it makes a "last run" file after you progress at least 1 page into the process. I'd say it's working fine since people who abort the process shouldn't be pestered by it.
Jok so each issue can be targetted to a milestone (that's the F39 on the right side of the page), so if you just tag issues for F39 it'll add them to the board and then we prioritize from there
Bso F39 is stuff now and up til F39 launches?
Bbut may apply to F38?
Jyeah so what I am going to do is put every fedora version in the milestones
AI could make a ticket in main for discussions about best way to integrate VSCode. I'd love to crowdsource some knowledge about whether this solution is good:
💾ublue-dev
💾ublue-dev
AIt's on the board atm.
Jwe have a ticket, sec
AOh it's not linked to a ticket.
JGitHub
An OCI base image of Fedora with batteries included - Milestones - ublue-os/main
Jyeah so the limitation, it's per repo, and the board is off of "main" right now
AAhhh
Jso if it needs to be on the board it has to be in the
mainGitHub
An OCI base image of Fedora with batteries included - Milestones - ublue-os/main
Jso the idea is, whatever we want to do for F39 we do for F39, and then if we don't make it we retag it to F40, repeat forever
AYeah. Are we able to link this to a ticket in
mainthe due dates on that page are set to the expected release date of that fedora release (which they publish way ahead of time) so that should be good enough
Jyeah that's an old one, what we should do is delete it and start a proper ticket
AAlright I'll start a ticket in main.
Jthe ones marked draft or linked to an actual gh issue can probably be swapped out
Bshould be good to pull and test now https://github.com/ublue-os/nvidia/actions/runs/4983580030/jobs/8920793465
PPerhaps I'm not quite the target for yafti at least the way it works right now since I think I want something that's a little more opinionated about making sure everything gets setup (and have some ideas about automating/guiding e.g. setting up github ssh keys etc). Probably something that keeps track of which items have been completed vs which haven't (e.g. like what the nix determinate installer does when it creates a plan/receipt)
Jthen the priority is basically top to bottom, left to right, so things in the Todo column should be in reasonable order based on who is interested and actively working on that
BWhile it can flatpak of vscode isnt all that greatly maintianed
Jyeah it would be nice if we could do all these things but it's just getting started
Jlike ideally we could whack a list of flatpaks and the installer magically does all the stuff correctly like how the silverblue installer does it, as part of the install
