105 Replies
yo
Aug 22 05:07:20 bluefin org.gnome.Shell.desktop[1686]: (EE) could not connect to wayland server
I think this is the culpritrootful xwayland definitely works btw
and the issue matches this one https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8506
seems that the shell is failing to start rootless xwalyand on-login
wait no, this is from 50m before the other one
love the not gnome tag
these also match
do you have a delta of things that changed when this first started
I think systemd bumped
oh
let me do an ostree diff one sec
I actually need to downgrade again to a working image
no worries
get the details of what changed and when/how it started happening and we can bisect the compoments from there
gnome-session got downgraded? no wait I am reading it the other way around
I guess they patch gnome-session a bunch
this is all a downgrade to the working image
is this centos?
all the gnome revs are mine
ah
I got a COPR
I was trying to patch this https://github.com/ublue-os/bluefin-lts/issues/625
GitHub
GNOME first run crashing on first run · Issue #625 · ublue-os/blu...
After a fresh install of the bib ISOs, gets stuck here: Hey did we bring the first run thing back with G48?
Adrian helped me with 2 patches for 49
could you link me the sources of the copr
also, you could probably build 49.beta of session and gdm, though need to check if we need shell too
I think we need at least 49.alpha.0 of shell
yeah problem is centos bundles moxzjs and gjs and fedora doesn't
i've been building everything out of the feora distgit but I cant build gjs due to the bundling
so I can't bump gjs right now
oh also jordan, we'll be doing backports on the LTS from now on, so it doesn't need to be perfect, it just needs to be reliable enough to last until 49 gets backported.
the gnome backports will be rolling it's not a "normal" LTS
yeah 49 will be better we just have to fake it until then
yea I am more curious on what part of the stack makes it fail more or less
it doesnt!!!! you can just bump mozjs to 128 just fine :clueless:
because RH kinda force x11 off even though it wasn'
cause I know 49.alpha nad 49.beta worked, but we never tested 48 of shell plus some patch from 49 session
then why was 48.4 still failing?
actually RH didn't disable x11
they only removed the xorg-server binary
everything still builds against x11 libs
(which is how we are still finding bugs)
they dont have mozjs128 on their repos yet
soo I should remove all my disable x11's
yeap
it will make things just work
and once you can update everything to 49 in one go it will also work
on who's repos? it was in the copr
i put it on the copr but the build fails
cuz of a check
hmm it does seem like something else shifted beneath us in CentOS. but maybe just my patches broke xwayland.
I'll go back to gnome crash on first boot mode. then I'll make another copr to test build gnome with x11 on
wait, what patches?
if you disable x11 on the gnome-48 builds, things break and there are some patches from 49 that are needed
are we disabling it on purpose?
i copied what was already there, but we can try undisabling across the board and see what happens. tulip was in the middle of that trying to fix xwayland
actually let me reframe the question, are we using default flags for everything?
no Michel hard coded x11 disabled
... I suspect Neal
and wayland supremacy
lol
can't we just roll with the default upstream flags?
they jumped the gun
cause they wanted to steal my thunder
then lets just ship your thunder
even though it was actually broken on 48
yeah I can roll back then changes
let's just go with the safest thing on G48 asap since we need the baking period for LTS
right the thunder is in 49
and now with jordan and james and jorge and tulip ... we shall ensure that GNOME destroys all competition on centos.
yeap, for 48 we still have x11=enabled across the board
on 49 we switched it
all we need to do is listen to the people who write thing. And then we can make a kickass vanilla gnome experience, since once we have LTS out the door we have a good platform to build on.
actually that's a flex for the feature list
"Though we ship an opinionated GNOME desktop our build pipeline purposely follows upstream recommendations" or something
For Bluefin I mean
hah yeap
no toggling shit before you say it's done
it's ridiculous that this isn't the default way to ship to people, that's why I'm glad we're doing it
but since we can have branches we can also run the crack daily per-commit stuff if you wanted to.
gnomeos we rebuild it twice a day tracking main of all the projects
do you think there should be any more testing on top of that? Like I know gnome os is production ready, but also it seems a little wild to build from main everyday, sounds like arch or rawhide
the sooner the better
cause one day you wake up, you boot and its a blank screen
the diff is like 10 commits in 5 projects
so much easier to track down
like ideally there'd be some tier one on main and tier 2 lagging one week behind on a known-good image
I mean, we call it gnomeos nightly
this is very helpful if you are a dev. not so much if you are a grandma. i'm looking for gnome os granny edition
soon ™
eventually we will have gnome os 49, 50 and so on
but for now we can only do development cause things are in flux
we're just shifting left baby!
just means we add more test suites upstream
we are also doing that yeap
@James btw do u have a link to the sources and the commit that disabled x11 on 48
I need the ammo to yell at people
Lol it was a hack fork
ah okay I thought they did in centos itself
https://src.fedoraproject.org/fork/jreilly1821/rpms/mutter/blob/rawhide-el10+-no-x11/f/mutter.spec
I just copied someone else's work who was likely operating under wrong information
ok so all we have to do is jordan-align and we should be good. 😄
I'll need Jordan help if/when GNOME wants newer deps. GNOME 49 already needs new gjs and Wayland. GNOME 48 needed new glibc.
Still have to get around to gjs
But I'm not touching what we got as long as it works for a few months
right future us problem
and I bet at some point we just update in -hwe and let vanilla go for as long as it can
iirc nto even fedora has updated to mozjs140 yet
in general that the issue with the backborts, eventually you rebuild half the stack
GNOME Discourse
GNOME 49 to depend on SpiderMonkey 140
This is a notice that GJS 1.85.2, scheduled to be included in GNOME 49.beta, will depend on SpiderMonkey 140 (corresponding with Firefox’s extended support release, ESR140). Mozilla has not worked out an automatic release process for SpiderMonkey tarballs yet. The official recommendation is to use the Firefox ESR140 source tarball. More infor...
in gnomeos we pulled it without any issues, but its stuck somewhere in fedora land
I'm already needing to fork a couple things since CentOS dropped the x11 binary.
I will have to make a bundled mozjs+gjs too, to match centos
for what we're doing now or for the future?
bundled as in how exactly
things should mostly work in centos even without the xorg-server, what did you need to fork
btw any idea where they keep the mutter spec file for EL10
yeah if we need to fork a bunch of things we need to have another think through
Put the mozjs and gjs in one spec, since I guess mozjs is only used in gjs on centos
oh they are still stuck on 47 huh
Yeah for 3 years
or rather released
Hence the backport
yeah
and it's either G48 or we don't ship
so if it's not going to happen or if it means forking the work please let me know
@James I thought we were just backporting RPMs not forking things
No 48 is working
I was under the impression that we wouldn't be maintaining a bunch of things, just doing 48 and moving on
I'm forking the rpm specs. Not gnome
oh ok
yeah, because we want this to be the default bluefin, it should be as zero maintenance as you can make it
Yeah me too
do you plan on updating to 49 afterwards?
cause long term its gonna be a lot of work to keep backporting
we want to just at least do 48
after that don't care
we just want this out and as a stable platform so we can work on wolfi
cool cool
the problem bluefin has is the fedora ones work and we don't want to be there but neither LTS or wolfi are ready
so we're stuck in fedora land
and don't want to be
sidenote, going back to x11 I figured what happened, the x11 disable is upstream kinda but only on fedora it seems
https://src.fedoraproject.org/rpms/mutter/c/8c9497b9eeb54724b8e59512a3b9beab397bf4d3?branch=rawhide
the first working release with
x11=disabled that I know off is 49.alpha.0
I remember when Neal jumped the gun and broke all of rawhideYeah Adrian told me
so until 49 just enable x11 build option, it won't be used at runtime anywhere
centos10 only missed the xorg-server binary iirc
we only need to rm the desktop file for gnome on xorg
@James ok so all the crashers are gone with Xwayland in the latest snapshot!
I'm going to respin ISOs to check for the first login crasher
if we can't do gnome-user-share then let's not do it, it's better to cut scope than to try to get it to work
what's the issue with user-share
we have to port a bunch of things to epel
I don't think it's worth the effort
user-share and I am guessing nautilus, you can do after the release as well probably
oh wait nvm, its the shell that depends on it among other things
OK!
new image, new ISO, no crashers!