Proposed as a Blocker and Freeze Exception for 36-beta by Fedora user mikhail using the blocker tracking app because:

 This bug makes it impossible to configure a VPN connection using the NetworkManager GUI.

Mikhail, this is reported against Rawhide. Are you seeing this in the F36 branched composes, or just on Rawhide?

F36 also affected to this issue after upgrade gnome-control-center to 42~beta-6.fc36.x86_64
Demonstration: https://youtu.be/wf25yf0z6aA

Created attachment 1863402 [details]
VPN configuration screenshot - F36

I'm not seeing this with the 20220222.n.1 Workstation compose[0] with either OpenVPN or openconnect. Does it perhaps require some specific configuration to trigger?

I am seeing "(gnome-control-center:3364): nm-CRITICAL **: 10:49:53.086: ((src/libnm-client-impl/nm-device.c:1353)): assertion '<dropped>' failed" after adding a VPN, but the VPN is added and I can edit it.

[0] - https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220222.n.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36-20220222.n.1.iso

(In reply to Brandon Nielsen from comment #5)
> I'm not seeing this with the 20220222.n.1 Workstation compose[0] with either
> OpenVPN or openconnect. Does it perhaps require some specific configuration
> to trigger?
> 
> I am seeing "(gnome-control-center:3364): nm-CRITICAL **: 10:49:53.086:
> ((src/libnm-client-impl/nm-device.c:1353)): assertion '<dropped>' failed"
> after adding a VPN, but the VPN is added and I can edit it.
> 
> [0] -
> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220222.n.1/
> compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36-20220222.n.
> 1.iso

You should install F36 and upgrade system.
gnome-control-center should has version42~beta-6.fc36.x86_64.

(In reply to Mikhail from comment #6)
> (In reply to Brandon Nielsen from comment #5)
> > I'm not seeing this with the 20220222.n.1 Workstation compose[0] with either
> > OpenVPN or openconnect. Does it perhaps require some specific configuration
> > to trigger?
> > 
> > I am seeing "(gnome-control-center:3364): nm-CRITICAL **: 10:49:53.086:
> > ((src/libnm-client-impl/nm-device.c:1353)): assertion '<dropped>' failed"
> > after adding a VPN, but the VPN is added and I can edit it.
> > 
> > [0] -
> > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220222.n.1/
> > compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36-20220222.n.
> > 1.iso
> 
> You should install F36 and upgrade system.
> gnome-control-center should has version42~beta-6.fc36.x86_64.

Can confirm, that definitely breaks it.

Discussed during the 2022-02-28 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug and to accept this as an "AcceptedFreezeException (Beta)" was made as we do not have specific criteria for VPN connections, and trying to stretch existing criteria to fix this is difficult. We do have proposed specific criteria from 2020, so we will resurrect the discussion on those criteria and decide on blocker status when that's done. This is definitely serious enough to grant an FE, though.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-28/f36-blocker-review.2022-02-28-17.00.txt

So I'm looking into this, specifically the openvpn case, though I suspect they'll turn out to be the same.

It's kind of complicated and interesting. gnome-control-center isn't doing a lot here, and what it's doing hasn't changed between 41.4 and 42.beta AFAICS. Most of the heavy lifting is being done by NetworkManager and NetworkManager-openvpn, but the relevant code *there* hasn't changed either AFAICS. So I suspect the problem here may actually be in GTK4: gnome-control-center 42.beta is built against GTK4, 41.4 was built against GTK3. I suspect GTK is doing something different about this "builder" stuff.

I believe in the openvpn case we're ultimately failing here: https://github.com/NetworkManager/NetworkManager-openvpn/blob/master/properties/nm-openvpn-editor.c#L2671

	if (!gtk_builder_add_from_resource (priv->builder, "/org/freedesktop/network-manager-openvpn/nm-openvpn-dialog.ui", error))
		g_return_val_if_reached (NULL);

So I think that's failing on GTK4 but worked on GTK3 for some reason. The tricky part is, I can't actually find a file called "nm-openvpn-dialog.ui" anywhere, on my system or in any upstream source trees. The GTK docs are very vague on what exactly this path is supposed to be and where it's looked up: https://docs.gtk.org/gtk4/method.Builder.add_from_resource.html

So I guess I'll go look and the source and see if I can figure it out.

Oh, found it in the NetworkManager-openvpn source tree: https://github.com/NetworkManager/NetworkManager-openvpn/blob/master/properties/nm-openvpn-dialog.ui

It doesn't get installed as-is, though, so I guess I need to figure out how that all works.

Yeah, the NetworkManager-openconnect code is very similar, as I suspected. It's failing here:

	if (!gtk_builder_add_from_file (priv->builder, ui_file, error)) {
		g_warning ("Couldn't load builder file: %s",

The "ui_file" it's looking for is g_strdup_printf ("%s/%s", UIDIR, "nm-openconnect-dialog.ui") , which looks like it should be /usr/share/gnome-vpn-properties/openconnect/nm-openconnect-dialog.ui, which looks like it should be in NetworkManager-openconnect-gnome .

I would recommend breaking in gdb and printing error->message

Filed an upstream issue, I'm trying to figure this out with debug log messages because I'm a dumb qa monkey who doesn't know how to work gdb.

So, update here: after some more investigation I think the problem is that the UI files have not been ported from GTK3 to GTK4. So that's kinda one bug each for NetworkManager-openvpn and NetworkManager-openconnect.

There's a pending MR to port NetworkManager-openvpn to GTK4:

https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/41

I backported that to try it out...now we don't get any console errors, but the editor pane *still* doesn't load :( I'll try and look into it more tomorrow.

the VPN plugins contain a GTK(3) UI part which is used by gnome-control-center (packaged in "NetworkManager-{openvpn,openconnect,...}-gnome" packages).

Those GTK parts currently only exist in a GTK3 version, although there is work in progress to also build (and install) a GTK4 version.

An application cannot both load GTK3 and GTK4 at the same time. That means, if you build gnome-control-center against GTK4, then you'll also need GTK4 plugins -- which don't exist yet.
The fix is, to port *all* VPN plugins to GTK4 (in addition to GTK3). This is work in progress.


However, it seems premature that gnome-control-center just decides to switch with GTK4, without syncing or checking that GTK4 VPN plugins are ready (unless, it wants to no longer use the VPN plugins). After all, the move to GTK4 causes massive amount of work, so it would be helpful if that work is aided by those pushing for that effort. Sorry for being grumpy, but the prospect to port all VPN plugins is not appealing. In particular, because I have the impression that such major releases are planned for the future to happen more frequently (re:GTK5).

Thomas: as I said above, I tried backporting that MR; the result is that I no longer get any errors logged from the gtkbuilder stuff (I patched GTK+ to log the error message if we error out there), but the pane still doesn't load properly.

Is the MR not complete yet, or something?

Oh, I guess I maybe need to enable the GTK4 build at configure time too.

Looks like that needs a GTK change: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4415 . We're getting pretty far into the weeds to try and get this working now. I kinda agree with Thomas in c#15 above, it'd be great if desktop folks could help with sorting this out since it's the GTK4 bump that's causing NetworkManager to have to do all this work to make gnome-control-center happy...

(In reply to Adam Williamson from comment #16)
> Thomas: as I said above, I tried backporting that MR; the result is that I
> no longer get any errors logged from the gtkbuilder stuff (I patched GTK+ to
> log the error message if we error out there), but the pane still doesn't
> load properly.
> 
> Is the MR not complete yet, or something?

Backporting is not really necessary (*), because once ready, we would do a new release and rebase.

(*) for testing the branch that is of course very welcome! Thank you!!

Nothing is really blocking the MR, except it didn't happen yet.
Possibly due to lack of priorities, which this rhbz changes.

As to why it didn't work for you, what you found out so far sounds all correct.
I need to refer to Lubomir for the detail.


Lubomir already has GTK4 WIP branches for most VPN plugins.

Thomas: well, I found it necessary because I wanted to see if we could get this working. I wanted to check that the editor will actually show up and work properly with the GTK4 work, or if there are still further problems.

This is a Beta FE bug and may well be accepted as a Beta blocker if we adopt the network criteria being discussed on test@ (they were proposed over a year ago but kinda stalled, we revived the discussion now). So that's why I'm treating it as a high priority.

Thanks for the update. The proposed release criteria cover openvpn, openconnect and vpnc, so those are the three plugins we would need to have updated to satisfy the criteria. I'll leave the bug assigned to NetworkManager-openvpn as we can't assign it to multiple components, but we need all three of those to fixed ideally.

See also https://bugzilla.redhat.com/show_bug.cgi?id=2060868 - similar problem with a UI file from libnma.

Discussed during the 2022-03-07 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Beta)", "AcceptedBlocker (Final)", and an "AcceptedFreezeException (Beta)" was made as this does not violate the current Beta criteria, and there wasn't enough support for applying the proposed networking criteria that do cover it to F36 Beta, but it is bad enough to be an FE. For Final, it violates the default app functionality and panel criteria.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-07/f36-blocker-review.2022-03-07-17.01.txt

FEDORA-2022-3263270e1e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3263270e1e

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

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

FEDORA-2022-3263270e1e has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.