Bug 2358741

https://gitlab.gnome.org/Teams/Releng/freeze-breaks/-/issues/195

I think we should form the X11 SIG 

To act in things like this 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/QJ4NRDDJIUX4O5EKSNUZONTE7WUWY6U4/

Discussed at 2025-04-10 F42 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-04-10/fedora-linux-final-go-no-go-meeting.2025-04-10-17.01.html . This was rejected as a blocker as it violates no release criteria.

I'll note for the record that yesterday, in https://pagure.io/fedora-qa/blocker-review/issue/1849 , I strongly suggested that the blocker process wasn't likely the right place for this and anyone concerned should file a FESCo issue promptly so FESCo could consider it ahead of the meeting, but AFAICS, nobody did.

(Not disagreeing necessarily, but wasn't this already the case for F41, at least I thought it was)

(In reply to Jens Petersen from comment #4)
> (Not disagreeing necessarily, but wasn't this already the case for F41, at
> least I thought it was)

Or maybe I was thinking of F42 Rawhide perhaps...

it was briefly dropped for f41, but re-added. https://src.fedoraproject.org/rpms/gdm/c/fb193607e1c498c16f62ae1ede1c7ccb6a6aafdf?branch=f41 then https://src.fedoraproject.org/rpms/gdm/c/a27d448e8d21ffeb09dbf16271706bcc70dd7cb1?branch=f41 .

(In reply to Jens Petersen from comment #5)
> Or maybe I was thinking of F42 Rawhide perhaps...

Perhaps it worked at 41 GA - but at least I can't start GNOME Xorg with the latest F41 Live respin in virt-manager.

(In reply to Jens Petersen from comment #7)
> Perhaps it worked at 41 GA

Yes, thanks

(In reply to Jens Petersen from comment #7)
> (In reply to Jens Petersen from comment #5)
> > Or maybe I was thinking of F42 Rawhide perhaps...
> 
> Perhaps it worked at 41 GA - but at least I can't start GNOME Xorg with the
> latest F41 Live respin in virt-manager.

I don't know about VMs, I had never cared about xorg sessions there, but truth be told, I am using GNOME Xorg session on freshly updated F41 just fine on bare metal. 

I'll go ahead and create a gdm PR, and ask if maintainers are willing/okay with allowing this at least in F42 (as I'd expect the support to be dropped in F43's gdm release).

(In reply to Jens Petersen from comment #7)
> (In reply to Jens Petersen from comment #5)
> > Or maybe I was thinking of F42 Rawhide perhaps...
> 
> Perhaps it worked at 41 GA - but at least I can't start GNOME Xorg with the
> latest F41 Live respin in virt-manager.

It still works in F41. Maybe you're missing some package like gnome-session-xsession?

(In reply to Adam Williamson from comment #3)
> Discussed at 2025-04-10 F42 go/no-go meeting, acting as a blocker review
> meeting:
> https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-
> 04-10/fedora-linux-final-go-no-go-meeting.2025-04-10-17.01.html . This was
> rejected as a blocker as it violates no release criteria.

AGREED: 2358741 - RejectedBlocker(final): This is an engineering design decision
and doesn't violate any blocker criteria. (@nirik:matrix.scrye.com, 17:43:34)

What the heck? This violates the Fedora updates policy of doing unannounced
changes breaking user experience.

And anyway, I'd argue that it violates the following:
> 🔗 Dual monitor setup
> 
> On computers using two monitors (e.g. two monitors on a desktop, or the built-in
> and one external monitor on a laptop), the graphical output is correctly shown
> on both monitors. 

I have a laptop that won't display a correct image on external monitor under
Wayland but displays correctly under Xorg.

> I'll note for the record that yesterday, in
> https://pagure.io/fedora-qa/blocker-review/issue/1849 , I strongly suggested
> that the blocker process wasn't likely the right place for this and anyone
> concerned should file a FESCo issue promptly so FESCo could consider it
> ahead of the meeting, but AFAICS, nobody did.

Done now: https://pagure.io/fesco/issue/3392 .

"What the heck? This violates the Fedora updates policy of doing unannounced changes breaking user experience."

There's no such thing in https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ that I can see. And that's a separate thing from the release process, anyway.

"I have a laptop that won't display a correct image on external monitor under Wayland but displays correctly under Xorg."

That's a hardware-specific bug, though. See https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? . That criterion even has a specific footnote referencing this: "Due to a wide range of possible hardware configurations, any problem related to this criterion will be regarded as a "conditional blocker" (as described in What about hardware and local configuration dependent issues.)."

we wouldn't count one specific case of hardware that works with X but not Wayland as violating the criteria, it'd need to be some kind of wider pattern or category.

If I remember correctly, this was a change that was planned to be made in Fedora 41, but it was decided to postpone it to Fedora 42 before Fedora 41 was released. And now Fedora 42 is here—postpone it again? I don't see sufficient reason for that.

Is the fact that this unannounced change is a major disservice to your users and that no affected user wants this in any release ever not enough of a reason?

The change might have been postponed in Fedora 41 due to the lack of public announcement, but Fedora 42 still hasn't announced this change that was originally planned for Fedora 41? I need an answer.

If that's true, all I can say is that it's a failure on the part of some people inside Fedora. Also, to what extent do changes like this need to be publicly announced? How formal does the announcement have to be, and through which channels? I don't think I've ever heard major changes from Fedora being formally announced — most of the time, I only find out by actively following Fedora Change proposals or tracking code changes myself.

There never was a Change proposal for this change, which is what we mean by "unannounced".

FEDORA-2025-36e1759b84 (gdm-48.0-2.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-36e1759b84

For every Fedora release, we do a post highlighting major new features. https://fedoramagazine.org/whats-new-fedora-workstation-42/ is the post for F42. It links to the ChangeSet page for the release, where every formal Change is listed: https://fedoraproject.org/wiki/Releases/42/ChangeSet .

The Change process defines the two types of Change - https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_categories - but never explicitly says that all things that fall under one or both definition *must* be handled as Changes. FESCo does have the power to declare that something must be treated as a Change, which it has used on occasion, but there's no systematic review policy; things are handled ad hoc (if someone raises an issue saying "this ought to be a Change", FESCo will look and consider it). As a practical matter we don't have the resources to formally review every commit to every package and decide whether it "ought to be" a Change, the process - like most things in Fedora - is grounded in an expectation of good faith on all parts.

In this case, AFAICT, the maintainer didn't consider that this specific change needed a new separate Fedora 42 Change proposal, and it was never raised to FESCo until yesterday in https://pagure.io/fesco/issue/3392 , at which point F42 was already signed off for release so it was a bit late to argue about the application of the Change process. If it had been escalated to FESCo earlier in the cycle, FESCo might well have said "this needs to be a Change".

FEDORA-2025-36e1759b84 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-36e1759b84`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-36e1759b84

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-36e1759b84 (gdm-48.0-3.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.