Description of problem: Version-Release number of selected component (if applicable): 42~beta-9.fc37 How reproducible: Steps to Reproduce: 1. Open Settings 2. Open Network tab 3. Click on + under VPN 4. In the Add VPN dialog choose OpenVPN 5. Notice the error `unable to load VPN connection editor` Actual results: `unable to load VPN connection editor` error Impossible to configure the VPN connection Expected results: The VPN connection editor should open Additional info: Relevant installed packages: NetworkManager-openvpn 1.8.16-1.fc36.1 NetworkManager-openvpn-gnome 1.8.16-1.fc36.1 openvpn 2.5.5-4.fc36
This bug now applies only to SSH, OpenVPN can load editor
Proposed as a Blocker for 36-final by Fedora user sasha using the blocker tracking app because: This bug can make access to the Internet or certain network services impossible or insecure for some users.
There's a PR open for the SSH plugin upstream[0]. It can't just be pulled in as a simple patch because it generates a GTK4 compatible ui file during generation of the tarball instead of simply adding a ui file to the source tree and modifying the Makefile. Option 1 would be to pester upstream to cut a new release with the PR incorporated. Option 2 would be to run `gtk4-builder-tool simplify --3to4` like the Makefile does and include the result as a patch. Either way, component should be changed to NetworkManager-ssh. [0] - https://github.com/danfruehauf/NetworkManager-ssh/pull/110
Bug confirmed in latest F36.
Discussed during the 2022-04-11 blocker review meeting: [1] The decision to classify this bug as an RejectedBlocker and AcceptedFreezeException was made: "We believe that ssh-based VPN is not widely used enough to warrant a blocker status, however we do see this as bad and grant it FE status." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt
NetworkManager-strongswan plugin has the same issue in F36, I filed https://bugzilla.redhat.com/show_bug.cgi?id=2081321
This bug is for adding or editing a SSH VPN connection with the gtk4 based gnome-control-center, the gtk3 based nm-connection-editor (from the nm-connection-editor RPM) still works and can be used as a workaround to add or edit a SSH VPN connection. A pre-built gtk4 ui file doesn't need to be bundled with the tarball, it isn't with NetworkManager-l2tp. For the other VPN clients that were released earlier, they had to bundle a pre-built gtk4 ui file as a workaround for 'gtk4-builder-tool simplify --3to4' needing a display in the build environment to work. The 'gtk4-builder-tool' no longer needs a display for the 'simplify' subcommand as described in the following merge request (which corresponds to gtk4-builder >= 4.6.2) : https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4415
I think that github PR could directly be incorporated as a patch, but the following two lines would need to be run before the %configure line : autoreconf -fi intltoolize So that the autoconf related files that are generated and normally added to the source tarball are regenerated after the patch is applied.
Sorry forgot to mention, the PR patch would be : https://patch-diff.githubusercontent.com/raw/danfruehauf/NetworkManager-ssh/pull/110.patch
"For the other VPN clients that were released earlier, they had to bundle a pre-built gtk4 ui file as a workaround for 'gtk4-builder-tool simplify --3to4' needing a display in the build environment to work. The 'gtk4-builder-tool' no longer needs a display for the 'simplify' subcommand" This is true, but GTK devs still say that this is not how you're supposed to do things. They do not recommend generating a gtk4 file on-the-fly from one intended for gtk3. The tool is meant to be used one time and the output reviewed and tweaked by a human, then maintained.
> This is true, but GTK devs still say that this is not how you're supposed to > do things. They do not recommend generating a gtk4 file on-the-fly from one > intended for gtk3. The tool is meant to be used one time and the output > reviewed and tweaked by a human, then maintained. Yet the GTK devs relented and allowed the tool to not need a display using a different approach which they committed and is in gtk4-builder >= 4.6.2. What the GTK dev says makes sense for a GTK4 standalone application, but for VPN editor plugins that are used by both gtk3 and gtk4 applications it really doesn't make much sense to manually maintain separate gtk3 and gtk4 ui files. This situation with 2 separate ui files will have to remain until all the applications using the NM plugins have been ported to gtk4. All the NetworkManager VPN (gtk3) ui files have been manually modified to replace or remove items not compatible with gtk4 and gtk4-builder-tool.
I opened https://bugzilla.redhat.com/show_bug.cgi?id=2086928 and I assume my problem is relative to this one. After upgrade from 35 to 36 I can open VPN connection editor but with my old user who worked fine in 35 I get garbage in displayed panel. If I create a new user, VPN connection editor works fine and displayed panel is correct.
I've created Fedora 36 NetworkManager-ssh 1.2.12 RPMs built with the NetworkManager-ssh GTK4 pull request and put them up on this COPR repository: https://copr.fedorainfracloud.org/coprs/dkosovic/NetworkManager-ssh-gtk4/ Please test them by editing (or adding) SSH VPN connections with gtk4 based gnome-control-center and gtk3 based nm-connection-editor. You can view what I changed in NetworkManager-ssh.spec file by looking at : https://github.com/dkosovic/NetworkManager-ssh-gtk4/commit/26f634dce636380e2c00a06f4426d57bf9d7d38c Regarding the NetworkManager-ssh GTK4 pull request, https://github.com/danfruehauf/NetworkManager-ssh/pull/110, the actual patch I used unmodified was: https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff instead of using the following patch which is a concatenation of commit patches : https://github.com/danfruehauf/NetworkManager-ssh/pull/110.patch as there was an issue applying the latter patch due to one of the files being renamed and subsequently modified in multiple commits. If you want to avoid adding the above COPR repository, the NetworkManager-ssh-1.2.12-4.fc36.x86_64.rpm and NetworkManager-ssh-gnome-1.2.12-4.fc36.x86_64.rpm files can be downloaded directly from : https://download.copr.fedorainfracloud.org/results/dkosovic/NetworkManager-ssh-gtk4/fedora-36-x86_64/04441640-NetworkManager-ssh/ and then installed with sudo rpm -Uvh NetworkManager-ssh-1.2.12-4.fc36.x86_64.rpm NetworkManager-ssh-gnome-1.2.12-4.fc36.x86_64.rpm
(In reply to Didier G from comment #12) > I opened https://bugzilla.redhat.com/show_bug.cgi?id=2086928 and I assume my > problem is relative to this one. I don't think the issues are related, this issue is about not having a gtk4 ssh vpn plugin, that issues is about the gtk4 openvpn vpn plugin causing an unresponsive spinning wheel when a connection from an older version is loaded.
There was one issue I discovered with the NetworkManager-ssh RPM package I created, the main package still had a stray gtk3 requires dependency which is not ideal for KDE plasma-nm or command-line nmcli users where pulling down gtk3 and its dependencies is not required. The auxiliary NetworkManager-ssh-gnome RPM package is the one that will pull down gtk3/gtk4 and GNOME dependencies. My latest NetworkManager-ssh RPM spec file is : https://raw.githubusercontent.com/dkosovic/NetworkManager-ssh-gtk4/main/NetworkManager-ssh.spec and the corresponding NetworkManager-ssh-1.2.12-gtk4.patch file is still : https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff I didn't bother creating new RPM binary files on COPR as the functionality hasn't changed for the gtk4 based gnome-control-center.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
This is also the case for the fortisslvpn plugin can we get a quick an simple workaround?
(In reply to comment #17) > This is also the case for the fortisslvpn plugin > can we get a quick an simple workaround? Extract from the NetworkManager-fortisslvpn-1.4.0 NEWS file : https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/blob/1.4.0/NEWS Notable changes include: * Gtk4 version of the editor plugin is now available (for use with Control Center of GNOME 42 or later). This issue is about the NetworkManager-ssh 1.2.12 RPM not including a Gtk4 version of the editor plugin. I believe the Fedora 36 NetworkManager-fortisslvpn 1.4.0 RPM is built with Gtk4 support : https://src.fedoraproject.org/rpms/NetworkManager-fortisslvpn/blob/f36/f/NetworkManager-fortisslvpn.spec So I suspect you have a different issue to the one here.
The problem is also not solved with 1.2.12-5.fc38...
Can somebody please file an upstream ticket at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues and link it here?
(In reply to Kamil Páral from comment #20) > Can somebody please file an upstream ticket at > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues and link it > here? Actually, I take it back, this seems to be a problem in NetworkManager-ssh and there's already a PR ready, marking as such: https://github.com/danfruehauf/NetworkManager-ssh/pull/110
Hi all, I'm a bit late on that train, but please let me know if there's anything I can do with regards to that. Looks like Lubomir has taken care of everything already :)
Lubomir's GTK4 PR hasn't been merged upstream. My latest NetworkManager-ssh RPM spec file which applies that PR as a patch and has a number of other fixes is located here: https://github.com/dkosovic/NetworkManager-ssh-gtk4 and the corresponding NetworkManager-ssh-1.2.12-gtk4.patch file for that PR is : https://github.com/danfruehauf/NetworkManager-ssh/pull/110.diff I've built the RPMs for the last 3 Fedora releases from the above RPM SPEC and patch files here: https://copr.fedorainfracloud.org/coprs/dkosovic/NetworkManager-ssh-gtk4/ The RPM spec file contains a number of fixes which probably should be applied upstream, along with the PR, there is also : # Use /usr/share/metainfo for AppData files, should fix upstream sed -i 's!(datadir)/appdata!(datadir)/metainfo!' Makefile.am # Use /usr/share/dbus-1/system.d/ for D-Bus policy file, should fix upstream sed -i 's!(sysconfdir)/dbus-1/system.d!(datadir)/dbus-1/system.d!' Makefile.am Ideally there should be a new upstream release, but if you want to use my new RPM spec file and the NetworkManager-ssh-1.2.12-gtk4.patch file that would do for the time being.
Confirmed still present in F38
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.