Bug 699786

Created attachment 494971 [details]
kde-plasma-networkmanagement/nm-09-compat.patch

Updated compat patch against kde-plasma-networkmanagement

Also notice I had to update the nm-09-compat.patch (but still it wasn't sufficient :/

You only editted/fixed the XML introspection files without fixing the actual source code in some cases

Marking as F15 KDE target and nominating as F15 Final NTH (because this affects networking, though not in the common configurations).

Discussed at 2011-04-29 blocker review meeting. We agreed this doesn't really fit as an NTH issue as we can't envisage many situations where you would need VPN connectivity to pull down updates, so it would be fine to fix this with an update.

Note we are not yet frozen for final, so you can push a fix for this even without it being accepted as NTH: just send it through the update process as usual and it will make it in for Final, as long as you get it in before the freeze date. Only after the freeze date would you need this to be AcceptedNTH to get it into the final images.

If you believe there are significant cases where it would be difficult or impossible to pull down updates without VPN connectivity, please re-propose with examples - thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

IMHO, NTH should be something that's, well, NICE TO HAVE, even if it isn't absolutely a blocker. Requiring the issues to e.g. not be fixable by an update defeats the whole purpose of NTH.

VPN not working is perceived as a major annoyance by some users, so I don't think it's asking too much to take a fix if it's available in time for the release (but not the freeze).

I agree that we shouldn't block the release for it (I would have nominated this for blocker otherwise, not NTH), I'm just asking to accept a fix if we get one.

Ping? Any news about this? The F15 change deadline is very close and I haven't seen any movement on fixing this.

(In reply to comment #4)
> Discussed at 2011-04-29 blocker review meeting. We agreed this doesn't really
> fit as an NTH issue as we can't envisage many situations where you would need
> VPN connectivity to pull down updates, so it would be fine to fix this with an
> update.
> 
> Note we are not yet frozen for final, so you can push a fix for this even
> without it being accepted as NTH: just send it through the update process as
> usual and it will make it in for Final, as long as you get it in before the
> freeze date. Only after the freeze date would you need this to be AcceptedNTH
> to get it into the final images.
> 
> If you believe there are significant cases where it would be difficult or
> impossible to pull down updates without VPN connectivity, please re-propose
> with examples - thanks!

In fact, at several universities, WIFI/WLAN is open but let's you connect to the intranet (and VPN concentrator) only. You need VPN to get to the internet (and update servers).

Being an early adopter of the nm-applet and seeing it work fine finally in F14, I can't believe it will be crippled again :(

(In reply to comment #7)
...
> Being an early adopter of the nm-applet and seeing it work fine finally in F14,
> I can't believe it will be crippled again :(

I meant the plasmoid, of course....

In addition, "nmcli con list" does not see my configured vpn connections. I was hoping that to be a workaround.

After starting nm-applet (yes, nm-applet), nmcli con list suddenly lists all connections which were configured through nm-applet (but not those configured through the plasmoid) - even after killing nm-applet again. I can't "up" my vpn connection though, probably nmcli can't ask for the password or something.

nmcli con list won't show them because nmcli only talks to actual upstream NM 0.9 settings service and hasn't been modified for the 'compat' code we're talking about here in NM; in fact there's no 'compat' support in libnm-glib anyway so there's nothing for nmcli to use at all.  Using 'compat' connections (ie, provided by KDE plasma) will certainly result in a degraded experience but this experience was intended to be a temporary workaround until upstream KDE finished the code to talk to NM 0.9, at which point the compat code would be dropped.

Upstream KDE is working on supporting the native NM 0.9 API, but their code still needs work. (There's an experimental snapshot in Rawhide, but it's known to still be incomplete and buggy.)

I believe I've fixed some VPN activation issues as part of commit fc4bf126beff7fec9c872740f18f5e3e0dbd73e7 on the 'f15' branch upstream.  That'll roll into an F15 testing update pretty soon.  I notice that I can't *disconnect* a VPN connection but that could be related to a bug I just fixed for activating them.

NetworkManager-0.8.999-3.git20110526.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-3.git20110526.fc15

"Xeno" on #fedora-kde reported this update to fix OpenVPN with kde-plasma-networkmanagement.

Package NetworkManager-0.8.999-3.git20110526.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.999-3.git20110526.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-3.git20110526.fc15
then log in and leave karma (feedback).

NetworkManager-0.8.999-3.git20110526.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.