Package Name: NetworkManager FAS Name of maintainer: dcbw
Reason for requesting a updates process review:
Dan (Williams) kindly contacted me recently about kde's networkmanagement code that will very likely require modification to function with NetworkManager-0.9, an update he'd like to see come to rawhide and F15 very soon.
Work is underway to support this, however, I did also express deep concern about api changes landing in a critical-path package beyond the F15 feature freeze. the kde-sig in general has doubts this new support (in kde) could land and be sufficiently tested in time for a good f15 release.
CC'ing dan in case he'd like to add-to/correct/clarify the situation as I understand it.
Adding meeting keyword.
We need more information here:
how hard a port would be? => As I understand it, plasma-networkmanagement needs to support system nm connections first as a prerequisite to supporting 0.9. this prereq is currently under development (no eta, but hopefully soonish, within weeks perhaps). The 0.9 additions/modifications, I'm told, would be relatively easy at that point, perhaps another 2-3 weeks of coding/testing.
Is there someone with ability and availability? tricky, dcbw (and jreznik) have contacted Jirka Klimes (@ redhat) to help work on it. Jirka has made contact with kde/nm upstream, and has started working on the prereq pieces. jreznik offered to help some, but his time will become more and more limited as f15 release approaches.
Replying to [comment:3 rdieter]:
I'd certainly hope the existing code supports system connections, as that part of NM has not changed. What you may be referring to is the new "secret agent" API that replaces the old user connections service (that stored connections in your session), which is not hard to implement, and much of the code for the old user settings service can be repurposed to for the secret agent stuff.
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/index.html
has an overview of the changes to the API. Besides the secret agent stuff, it's mostly a consolidation of the D-Bus API due to the combination of the user & system settings service.
I'd like to ensure the KDE pieces are solid. I'd like to offer my assistance to make sure it happens, and of course jklimes should be helping out too.
I think the question #1 here is - what's the benefit of rebasing NM so far in the development cycle. Especially for such critical component as desktop networking. Plasma NM is just a secondary issue.
For Plasma NM, Lukas did some more detailed investigation, the NM code goes even to Solid code (the CDMA/GSM change mentioned in the documentation etc.). So it leads to a lot of changes in the last moment.
I like the API changes in NM code, making it more simple for applets developers (and possibility of sharing settings) is a huge win for everyone. But I don't see a reason to hurry here, as I don't see any major improvements that justify such late change. For F16, it's completely ok, we (me and ltinkl) can help with port. It's just too late for us to help now :( We even have a private plan for custom applet that's more maintainable (but I still prefer upstream solution ;-)
Adding Lukas to CC.
Replying to [comment:5 jreznik]:
I think the question #1 here is - what's the benefit of rebasing NM so far in the development cycle.
GNOME 3 is designed to use NetworkManager 0.9; it's not optional.
I'd certainly hope the existing code supports system connections, as that part of NM has not changed.
kde-plasma-networkmanagement historically had no support for system connections at all. When connected to one, it would only show being connected to an unknown connection.
These days (as of the 20110221 snapshot I'm running), it can correctly display being connected to a system connection, but the connections still don't show up in the connection editor and cannot be created or edited there. Only user connections can be edited through its UI.
GNOME 3 is designed to use !NetworkManager 0.9; it's not optional.
Yet what you're shipping in F15 Alpha works fine with 0.8. Why can't you just keep that working?
Replying to [comment:6 walters]:
GNOME 3 is designed to use NetworkManager 0.9
While we are at it: Will NM 0.9 still have a trayicon or only a gnome-shell applet?
Replying to [comment:8 kkofler]:
GNOME 3 is designed to use !NetworkManager 0.9; it's not optional. Yet what you're shipping in F15 Alpha works fine with 0.8. Why can't you just keep that working?
No, it's totally incomplete - we have a new network UI in the top panel already working with 0.9, and the control center code is all targeted for 0.9.
Oh BTW:
A !NetworkManager08 package
Unfortunately, while this may sound like the easiest solution, I don't think that's a workable solution. It would mean you couldn't have GNOME and KDE installed on the same machine.
Replying to [comment:9 cwickert]:
Replying to [comment:6 walters]: GNOME 3 is designed to use NetworkManager 0.9 While we are at it: Will NM 0.9 still have a trayicon or only a gnome-shell applet?
It will have both - the fallback mode still uses the old tray icon.
I'm working on a NetworkManager08 spec file right now.
Don't you have some contingency plan, e.g. using the gtk2 applet?
I'm working on a !NetworkManager08 spec file right now.
The 2 versions cannot coexist and both work properly, can they? So won't that mean you won't be able to have GNOME and KDE installed on the same machine?
Replying to [comment:14 kkofler]:
That will be true, yes.
https://bugzilla.redhat.com/show_bug.cgi?id=684323
I really think a parallel installable compat version is a really bad idea. Can we try and explore all other options before going there?
Can the changes needed for gnome-shell be backported to the 0.8.x code base, saving the api changes for f16?
Can kde use nm-applet again until the kde integration is done?
Something else super clever here. ;)
Replying to [comment:17 kevin]:
I really think a parallel installable compat version
I'm not even trying for parallell installable, merely parallel shippable, i.e. the packages will Conflict:.
Basically no. NetworkManager 0.9 is a huge change and it actually dramatically simplified things, and again it's not just gnome-shell but also the control center (so let's use the term "GNOME 3").
No opinion on this.
That would degrade the user experience significantly, and I think it would be really unfair to KDE SIG to force us to use such a solution, when we're not the ones not following freeze processes.
Why can't GNOME 3 be the one to use nm-applet instead? Especially considering that that's what GNOME has been using for years and will still use in the fallback shell anyway.
Oh, and I just noticed this:
!NetworkManager 0.9 is a huge change
That's quite funny, dcbw was trying to tell us the opposite as an argument for why this should be allowed post-freeze.
Oh, and nm-applet is now GTK+ 3, for which we don't have a theme fitting KDE yet (the GTK+ 3 branch of oxygen-gtk is also under development, such a port also takes time!), it would look particularly bad in a KDE/Plasma environment.
A blog post from kde-plasma-networkmanagement upstream which also touches on this issue: http://lamarque-lvs.blogspot.com/2011/03/plasma-nm-big-feature-bigger-than-i.html
Replying to [comment:20 kkofler]:
Oh, and I just noticed this: !NetworkManager 0.9 is a huge change That's quite funny, dcbw was trying to tell us the opposite as an argument for why this should be allowed post-freeze.
I still assert that it is. It's not a huge change in client code; most things are simply renames of D-Bus methods and a few changes to arguments.
For the Modem stuff, the changes in NM and nm-applet took about 6 hours. You don't need to internally consolidate things, and the changes to nm-applet itself were quite minimal (-98/+116):
http://git.gnome.org/browse/network-manager-applet/commit/?id=273b9b31338c450b8bd0e13b91dfad59fce74df5
and the changes to NM were also fairly minimal, resulting in the removal of over 500 lines of code (-1052/+466):
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2140dad5e0de0033e5c9bb10bd77ecd80085e5a3
You can stage the mobile changes, since internally NetworkManager does not implement consolidated code paths, nor does ModemManager implement consolidated 3G devices. That comes later, but the NM API needs to be ready for that change, hence the consolidation. From what I understand about Plasma's network stuff, there's an abstraction over top of NetworkManager already, so in that case shouldn't the changes only involve the NM glue layer, and not much (if anything) above that?
Also, the configuration for 3G has not changed. The Setting objects are not consolidated and still contain the same properties. On the NMGsmDevice and NMCdmaDevice objects which represent a physical modem have been combined. You still call the same ActivateConnection() method on the modem object with the same arguments and the same connection as previously. Neither Knm::GsmSetting nor Knm::CdmaSetting need any changes whatsoever.
You probably don't even need to change NetworkInterface::Gsm or NetworkInterface::Cdma for now either; when you see a new NM Modem device come in, check the CurrentCapabilities property, and create the corresponding NetworkInterface::Gsm or NetworkInterface::Cdma object since for now, NM won't export devices that have both CDMA and GSM properties. That's basically what I did for nm-applet to save time.
Furthermore, the device type numbers are backwards-compatible, so clients that don't support the new NM_DEVICE_TYPE_MODEM type simply won't see any 3G devices at all (since the old numbers are still present, but just not used). So the modem changes don't silently break things.
I'm actually pretty surprised at the lack of support for system connections in the KDE Plasma stuff. Not to knock the effort that's gone into the code, but system connections have been part of NetworkManager since version 0.7, which was released 27-Nov-2008, almost 2 1/2 years ago. Did the old knetworkmanager support them and that support just never quite got there for the Plasma code?
I do admit that given the fact that system connections are not present in the Plasma NM bits, that it will be harder to implement the 0.9 secret agent API since the code that handles to them can't simply be re-purposed since it doesn't exist. I don't believe its an enormous task but of course I haven't worked much with the plasma code.
To elaborate on my previous comment, I think we really need to consider the impact of:[[BR]] A. shipping GNOME 3 with nm-applet 0.8 vs.[[BR]] B. shipping KDE Plasma with nm-applet 0.9.
To take up the reasons brought up by the GNOME 3 developers for needing 0.9:
system tray (message area) consistency[[BR]] A. The nm-applet icon is not monochromatic and will look out of place in the gnome-shell message area.[[BR]] B. The nm-applet icon is not monochromatic and will look out of place in the Plasma system tray. (And even if this were to get changed, the style of the icons would still not match the style of the Plasma theme's icons.)
popup menu look&feel[[BR]] A. The nm-applet popup does not follow the gnome-shell look&feel.[[BR]] B. The nm-applet popup does not follow the Plasma theme's look&feel. (In fact, it will look very bad, see also point 4 below.)
control center[[BR]] A. Network settings cannot be configured from GNOME System Settings. They can still be configured through the nm-connection-editor which is easily accessible from the applet.[[BR]] B. Network settings cannot be configured from KDE System Settings. They can still be configured through the nm-connection-editor which is easily accessible from the applet.
And there are some additional considerations:
dialog consistency[[BR]] A. The nm-connection-editor uses GTK+ 3 which integrates perfectly into GNOME 3.[[BR]] B. The nm-connection-editor uses GTK+ 3 which integrates very poorly into KDE Plasma, considering that GTK+ 3 theming support in KDE is not finished and probably won't be in time for F15.
keyring/wallet integration[[BR]] A. The nm-applet uses gnome-keyring which integrates perfectly into GNOME 3.[[BR]] B. The nm-applet uses gnome-keyring which integrates very poorly into KDE Plasma.
stability[[BR]] A. !NetworkManager 0.8 has been tested during all the F15 prerelease phase.[[BR]] B. !NetworkManager 0.9 has had no testing whatsoever in Fedora before the feature freeze, which is very scary for something as critical as network access.
re point #6:
The core network functionality has not changed much; it's largely the same as the NM 0.8.4 update that's been approved already for Fedora 14. I don't worry about the stability for actual network connectivity at all as that has had no significant upheaval during the 0.9 cycle. Almost all changes to the networking core have also been backported to NM 0.8.4.
In short: 0.9 isn't going to break your WiFi. Or your 3G. Or your Ethernet.
The bulk of the 0.9 changes are in the secret agent code and policy enforcement code, which has received a good chunk of testing over the past few weeks after the cut-over in GNOME3 upstream, and lots of good community testing from developers in Debian and other distributions of the beta1 and beta2 releases. The only reason I didn't try to push more aggressively into Fedora was because I wanted to figure out the dependency situations and not just dump it in when it wasn't actually ready, and when it would have broken people's networking. Yes, it's late, and it should have had a feature page, and both these are my fault. But the situation certainly isn't as dire as many are making it out to be.
Had NM had a feature page (which it should have had), the NM 0.9 feature wouldn't even need to be 100% complete until March 29th, by which point NM 0.9 itself will have already been released.
I've already got patches for 90% of the affected programs, and most of those patches are already upstreamed. The changes for programs that are !kde-networkmanagement and !nm-applet are extremely minimal and often backwards compatible with older versions of NM.
I'll defer to those that know about whether or not we can whip the KDE bits into shape by the 29th. I'm entirely willing to help make that happen.
Had NM had a feature page (which it should have had), the NM 0.9 feature wouldn't even need to be 100% complete until March 29th
But it would still have had to be testable by February 8. You can't test something that's not imported yet.
https://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy
AGREED: will look for more info in ticket and revisit as it becomes available.
(Hopefully this week).
In the mean time, will ask NM owners to not push 0.9 into the repos.
Jirka Klimes is working on it, but he can't give us any time estimation at the moment. I suppose we have to wait how it goes.
ok. Perhaps we could get Dan and Jirka together on irc/phone and they could hash out what needs to take place or at least a better idea on how much work there is there?
Please give Jirka time to work on it in peace. It doesn't help if we create another meeting. He'll give us information after he will have something.
I suppose it won't be this week.
No news. It probably ends as ticket for next fesco meeting.
I'd like to address some points made during the meeting last week:
19:01:55 <notting> 1) ship KDE with nm-applet from nm09 2) drop feature, ship gnome with nm08 & nm-applet 3) port kde-plasma-NM to NM09 4) ship two NM versions[[BR]] 19:02:22 <notting> IMO, !#1 isn't fair to KDE. !#2 isn't fair to GNOME. which leaves !#3 and !#4
I agree, obviously, that 1) isn't fair to KDE, but how would it be unfair to GNOME if an incompatible change to a critical path library (with associated, also critical daemon) which wasn't testable by the feature freeze, nor even a month after the feature freeze for that matter, got rejected?
The fact that the change causes a release-critical regression for one of our mirrored spins is of course an additional reason to reject this freeze override, but even without that, there should be no sense of entitlement for what would be, by definition, an '''exception'''.
It is only fair that something that is not delivered in time for our freeze schedule gets postponed to the next release, particularly when the criteria for an exception are not satisfied.
19:06:08 <mjg59> rdieter: That was option 2[[BR]] 19:06:35 <mjg59> rdieter: The problem with that is that it leaves Gnome 3.0 in a less than ideal state, which is a problem if that's our big feature for this release
KDE 4.0 was the big feature for Fedora 9 and we also had to release it in a less than ideal state. We had to plug in several components from KDE 3 and even GNOME (e.g. gnome-packagekit), it took several releases to replace them all with native components based on KDE 4 technologies. It is a practical reality that new features cannot always be delivered in a perfectly ideal state, particularly when we're shipping a .0 release of something as huge as a desktop environment.
IMHO, shipping a GTK+ 3 systray applet instead of a native gnome-shell applet for NM in GNOME 3.0 would be a very minor degradation compared to the kind of compromises we had to make with KDE 4.0.
Replying to [comment:28 mmaslano]:
Some update on the issue:[[BR]]
I applied some pathes from Gökçen Eraslan's cloned repo (that adds system-wide connection support) to master and on that basis and made some changes for NM 0.9. And it's able to do some basic functionality like seeing the connection, being able to activate and deactivate, displaying the correct status.[[BR]] But there is still quite a lot work to do. And it's quite hard for me because I am still not much familiar with KNM internals (and KDE/Qt stuff as well). Moreover the design will/should change (and simplify) with libnm-qt that should replace Solid::Control and some other layers, that more complicate the code than help.
I sent more info to kde-networkmanagement mailing list:[[BR]]
http://markmail.org/message/v4jbw755wrw5jsin
Given jklimes feedback, knm builds now on top of nm-0.9 (thanks!), but it's just an initial port of basic features. Knm needs to grow support for new nm-0.9 features (secret agents, etc) and needs workarounds to avoid changing stable KDE API in order to support the same features as it did with nm-0.8. In short, a significant regression in terms of functionality and stability and not close to being testable yet. There are concrete and ongoing plans to re-factor and stabilize the code. The kde-sig maintains the position that this could be in good shape in time for f16, but in all likelihood not so for f15. We ask that nm-0.9 be postponed for f16.
There is a possibility for f15/kde to ship using nm-gnome-0.9, but that would provide a different experience, and frankly, would leave our contributors feeling disrespected with a perceived failed process.
My 2 cents on this: If we follow the [https://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy policy], NM-0.9 has definitely missed the bus because it meets all of the three ''Do Not's'': Do not: Continue to add new enhancements[[BR]] Do not: Enable the feature by default (if not already default at Feature Freeze)[[BR]] Do not: Make changes that require other (dependent) software packages to make changes as well
On the other hand we've violated this policy in the past and I would like to see NM-0.9 in F15's gnome-shell, but only given that * it does not break KDE and Dan is willing and capable to support the KDE developers in porting their code * the trayicon is still shipped and supports all functionality. Otherwise we also break LXDE and Xfce.
Last but not least I'd like to point out that even nm-applet looks weird in a GTK+ 2 environment because the adwaita theme does ''not'' offer a consistent look and feel.
We (QA) are concerned about this proposed change, and would like to raise a few issues.
1) We're worried about the impact to non-GNOME desktops. KDE has been discussed above, and we concur with the KDE team that this change would appear to cause them a significant additional burden. As KDE is considered capable of blocking Fedora releases, if there is trouble adapting KDE to the changed NetworkManager, this could cause delays to the release. We are also concerned about LXDE and Xfce, both of which currently rely on nm-applet for network management; we would like to know if anyone has considered the impact on those desktops, and whether anyone has checked to see if the revised 0.9 applet will function at all in those environments. LXDE and Xfce are not considered capable of blocking releases, but we would consider it a significantly sub-optimal outcome if it proved to impact our ability to deliver working LXDE and Xfce images for the Beta and Final release points.
2) We're worried about the impact on the installer. The installer uses NetworkManager for network configuration and needs significant changes - http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=d66cb3c7f6680c2d087b2a663dee85a449d2ffef - to work with 0.9. We're worried about landing significant changes to such a key installer feature late in the Beta cycle; this seems like something with significant potential to cause further slippage, to us. Identifying any issues should not be a problem as we have validation procedures in place, but resolving them in time for the Beta release may prove more difficult given the time frame involved.
3) We're worried simply about the change itself, and landing it so late. We note that the considerably revised NetworkManager 0.9 has had no testing at all in Fedora so far. As noted above, NM is a critical path component, and any problems with it are almost certain to be significant, release-blocking issues, with the potential again to cause slippage.
QA does not oppose the addition of NM-0.9. However, we would like to point out that arrival of this change the day before (or after) the Beta TC1 milestone (2011-03-22) may impact our ability to assert the Fedora 15 Release Criteria and ship F-15-Beta on schedule, and we'd like to hear from those proposing NetworkManager 0.9 concerning each issue. For instance, we'd be happier on point 1 if someone could tell us with certainty that NM 0.9 will work okay with Xfce and LXDE, and come up with a plan for KDE that is acceptable to all parties.
Replying to [comment:35 cwickert]:
The policy states that this is what is expected of committed features post-freeze, and that if you need to do any of these things, ask for an exception (admittedly, that page says to contact rel-eng -- it needs updated). So, this ticket is actually following the policy, and the point is to weigh those concerns, not to disallow all exceptions based on that.
Some brief testing shows that the NM-0.9 applet starts and works ok (autoconnects, cna disconnect, etc.) in LXDE and XFCE. It does have a theming issue, but I suspect that could be fixed with either installing a theme, or some xsettings config.
So, this ticket is actually following the policy, and the point is to weigh those concerns, not to disallow all exceptions based on that.
But the feature fails every single criterion for allowing an exception!
I'm also going to point out again the following, from the same page:
Once the ''Feature Freeze'' milestone is reached, all new features for the release should be: * substantially complete and in a ''testable'' state * ''enabled by default'' -- if so specified by the feature In the Fedora development process, all new feature work is completed by ''Feature Freeze'' and tested during the test releases: Alpha and Beta.
Feature Freeze was on February 8. NM 0.9 wasn't '''anywhere near''' "substantially complete" at that point. It wasn't even imported anywhere at all. Needless to say, this also implies it wasn't testable nor enabled by default. And it got '''zero''' testing in the Alpha.
It is now March 22, a month and a half after feature freeze. NM 0.9 is still not anywhere near fulfilling those criteria.
There is also this paragraph:
'''Ask First'''[[BR]] Before checking in changes and building new packages, please request an exception first. This saves everyone the time and mess of reverting a change if Release Engineering disagrees with the request. Yet the owners of the feature haven't asked! Rex Dieter has.
And finally, I'd like to point out that, to the best of my knowledge, nobody even '''talked''' to the Fedora KDE SIG nor to kde-plasma-networkmanagement upstream about plans for NM 0.9 and the changes in it before March 8. If we had known about the plans, we could have started working on porting kde-plasma-networkmanagement earlier, and would probably have had something shippable by the Fedora 15 deadline. But it is just not doable in this timeframe. kde-plasma-networkmanagement upstream was completely surprised upon learning that NM 0.9 supports only systemwide connections. This should have been communicated much earlier. It must have been in the plans for months, why wasn't this communicated to kde-plasma-networkmanagement upstream?
What is now going to be the common usecase (systemwide connections with secrets stored by user) used to be pretty much a corner case in NM 0.8 (What's the point of sharing the connection without sharing the secrets? I'd like to point out that if you also share the secrets systemwide, you don't need an applet at all, at least in 0.8, NM will connect to the connection at bootup. And kde-plasma-networkmanagement now displays that case correctly, but doesn't do anything in that case because it doesn't need to.), so I think it should be perfectly understandable that kde-plasma-networkmanagement hasn't supported this case so far. There were much higher priority items, such as making mobile broadband just work, on which kde-plasma-networkmanagement upstream has made a lot of progress lately. I should also note that the "everyone else" fully supporting systemwide connections in 0.8 is basically only one piece of software: nm-applet. Looking only at one implementation when asserting the implications of the changes for applets doesn't strike me as thourough research on the impact of the changes the NM developers are planning to land!
I already said this in the FESCo meeting so just for the record: If we can't get it done in time the solution shouldn't be to ship in a "broken" state (either GNOME3 or KDE) just for the sake of meeting a deadline. We should simply delay the release and ship something that works.
While in principle that's a solution we are OK with from the KDE side, the problem there is that we don't know how long it will take to get kde-plasma-networkmanagement ported. It could take several weeks.
jklimes said to me that he thinks it may take 2 or 3 weeks for upstream to put something together and test it minimally. That seems to be cutting it pretty close, but of course that's obviously the correct solution going forward.
But in case that doesn't come together, I've spent the last two days putting together a prototype fallback in NetworkManager. The branch here:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=f15 http://cgit.freedesktop.org/NetworkManager/NetworkManager/diff/kde-plasma-networkmanagement-nm-compat.patch http://cgit.freedesktop.org/NetworkManager/NetworkManager/diff/kdebase-workspace-nm-compat.patch
contains current NM git master plus a boatload of compat code grafted back on to implement most of the API that the current kdebase-workspace and kde-plasma-networkmanagement pieces use. This includes the return of user connections.
The approach used here is to add back the old API with a different interface name, and modify the existing KDE pieces to use the different interface names. This preserves the new NM 0.9 D-Bus API in a pristine fashion, but also allows the KDE pieces to work with very minimal changes. The intent would be to finish this work in NM, land it in F15, and use this until upstream KDE has a working NM 0.9 backend. At that point, we cut over to these new KDE pieces (or backport them to F15) and rebase F15's NetworkManager on pure upstream git without the compat code I've added here.
There are a few pieces of compat left to do; VPN connection secrets and a few more properties of each device type. But with the patches linked above, network device states work and I'm able to connect to my WPA AP using a KDE user-settings connection. I'm willing to maintain this compat code in Fedora at least until this summer, by which point I hope the upstream KDE pieces will be ported to the 0.9 API.
The compat code would take a day or two more to finish up and test before I'd consider it ready to land in Fedora. But at this point I'm confident the approach I've used is viable and will maintain the existing KDE experience without having to use nm-applet in KDE or create nm08 compat packages or something like that.
Does this approach sound workable to everyone?
http://cgit.freedesktop.org/NetworkManager/NetworkManager/diff/kde-plasma-networkmanagement-nm-compat.patch http://cgit.freedesktop.org/NetworkManager/NetworkManager/diff/kdebase-workspace-nm-compat.patch
These links don't work for me. But the patches can be seen through: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=f15&id=071d4920ac96f063e5175bda22c6c0f8b0967349
This approach sounds workable at least to me, if it really works. Some concerns I have about this solution: * How do you estimate the potential for regressions? This compat code is very new and we don't have much time left to test things for F15. * What will happen to the user connections set up using the compat code when the update porting kde-plasma-networkmanagement to the real 0.9 API will hit? But if those concerns are addressed, this sounds like the best possible solution for making everybody happy to me.
Replying to [comment:43 dcbw]:
The compat code would take a day or two more to finish up and test before I'd consider it ready to land in Fedora. But at this point I'm confident the approach I've used is viable and will maintain the existing KDE experience without having to use nm-applet in KDE or create nm08 compat packages or something like that. Does this approach sound workable to everyone?
Works for me, thanks Dan! At least from KDE POV (I was thinking about similar solution but I wasn't sure it's even possible).
Still I have some concerns from Fedora perspective but if you think it's stable code (nm, nm-applet and gnome-shell applet) and you bet on the code, I believe you ;-) But then we should have at least one NM testing day! Adam, what do you think? Do we have some free slot?
Dan, it's the best solution for us in f15. Thanks for adding of compat code!
I hate to spoil the party, but we were supposed to ship the first Beta TC yesterday. If it takes a day or two more to finish up this new NM build, accounting for the usual Murphy stuff it'd likely be two or three days before we could ship a TC, at which point we're well behind schedule. Two days is Friday, so if we miss that boat, we likely wouldn't have a TC until Monday, the 28th - and we're supposed to ship the RC on the 31st.
This is the kind of thing that happens when major changes are made too late :/
to put it in practical terms: I would suggest that if we wait for the new NM build we are almost certainly looking at a minimum one week slip of the Beta (and hence Final release), as a consequence.
I have a concern/question on userspace applications that are using network detection apis from NM, at least pidgin doesn't work correctly now if you don't run NM. i dont know how things like firefox have thier network connection detection setup but if they use nm apis directly how will they be effected here?
Replying to [comment:50 ausil]:
From the FESCo meeting: Things that use nm-glib should work with just a rebuild. For pidgin and other apps that use dbus, they will likely need a small patch and rebuild. The patch for pidgin, as an example, is here: http://developer.pidgin.im/attachment/ticket/13505/nm09-pidgin.patch
AGREED: We ship 0.9 and fix up KDE with the 0.8 compatibility patches. Whether we slip or not is up to QA/releng
Thanks for everyones work on solutions here.
Replying to [comment:44 kkofler]:
The regression potential is obviously there, but I don't believe it's huge, as the compat layer is a thin shim and doesn't have to do much work. It's pretty easy to visually inspect and figure out what's going on. Most of the compat interface is still handled by the existing NM objects which nm-applet and the GNOME Shell pieces are banging on all the time. Again, the compat interface only implements the pieces that the KDE plasma stuff should actually be using, which means no system connection support, no support for Bluetooth devices (since I couldn't find the KDE bits actually using that, given that the BT stuff showed up in 0.8 and the KDE bits are still targetting 0.7).
When we drop the compat code, user connections will need to be "migrated" to NM system connections by the new KDE plasma NM layer. nm-applet implements this by simply setting the "permissions" on each connection to the username which the applet is running as, and setting the "secret flags" of each saved secret to be "agent owned", meaning the secrets are stored in the user's session and not by NM. Then the connection is sent to NM to be added. That code is pretty trivial and the codepaths are already exercised by anything that calls AddConnection() which both nm-connection-editor and the KDE connection editing stuff do already.
To be clear, I'm saying that whatever new NM code upstream KDE produces to work specifically with the NM 0.9 API will have to include the user connection migration functionality.
I've patched most of the things I found:
notting had one more patch for something too.
I hate wiki formatting.
NM with compat code is built in dist-f15:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2942129
gwibber - https://bugzilla.redhat.com/show_bug.cgi?id=689890
Here's some more hits from a grep of a moderately recent Fedora source tree. I know Dan already knows about some of these:
{{{ Record.activity/.0sugar/implementations/sha1new=3a08d5e9cc9efa3f425945b9eab8a451e804a131/zeroinstall/injector/background.py: NM_STATE_CONNECTED = 3 Record.activity/.0sugar/implementations/sha1new=3a08d5e9cc9efa3f425945b9eab8a451e804a131/zeroinstall/injector/background.py: if network_state != NetworkState.NM_STATE_CONNECTED: anerley-0.2.14/src/sw-online.c: case NM_STATE_CONNECTED: comm-1.9.2/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: NM_STATE_CONNECTED, comm-1.9.2/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: mLinkUp = result == NM_STATE_CONNECTED; comm-1.9.2/mozilla/toolkit/system/dbus/nsDBusService.h: * FALSE when NetworkManager reports NM_STATE_CONNECTED, and to TRUE otherwise. deja-dup-17.6/common/Network.c:#define DEJA_DUP_STATUS_NETWORK_MANAGER_NM_STATE_CONNECTED ((guint32) 3) deja-dup-17.6/common/Network.c: if (data->state == DEJA_DUP_STATUS_NETWORK_MANAGER_NM_STATE_CONNECTED) { deja-dup-17.6/common/Network.c: if (state == DEJA_DUP_STATUS_NETWORK_MANAGER_NM_STATE_CONNECTED) { deja-dup-17.6/common/Network.vala: static const uint32 NM_STATE_CONNECTED = 3; deja-dup-17.6/common/Network.vala: if (state == NM_STATE_CONNECTED) deja-dup-17.6/common/Network.vala: update_status(state == NM_STATE_CONNECTED ? Status.ONLINE : Status.OFFLINE); epiphany-2.91.91/src/ephy-net-monitor.c: net_status = result == NM_STATE_CONNECTED ? NETWORK_UP : NETWORK_DOWN; gnome-applets-2.32.0/gweather/gweather-applet.c: if (result == NM_STATE_CONNECTED) { gnome-panel-2.91.91/applets/clock/clock-location.c: if (result == NM_STATE_CONNECTED) { google-gadgets-for-linux-0.11.2/extensions/linux_system_framework/network.cc: is_online = (state == NM_STATE_CONNECTED); google-gadgets-for-linux-0.11.2/extensions/linux_system_framework/network.cc: is_online_ = (result.GetValue() == NM_STATE_CONNECTED); google-gadgets-for-linux-0.11.2/extensions/linux_system_framework/network.cc: is_online_ = (state == NM_STATE_CONNECTED); libproxy-0.4.6/libproxy/modules/network_networkmanager.cpp: if (state == NM_STATE_CONNECTED) meego-panel-people-0.2.4/src/sw-online.c: case NM_STATE_CONNECTED: meego-panel-status-0.3.2/src/sw-online.c: case NM_STATE_CONNECTED: python-meh-0.11/meh/network.py:NM_STATE_CONNECTED = 3 python-meh-0.11/meh/network.py: if int(state) == NM_STATE_CONNECTED: seamonkey-2.0.11/comm-1.9.1/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: NM_STATE_CONNECTED, seamonkey-2.0.11/comm-1.9.1/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: mLinkUp = result == NM_STATE_CONNECTED; seamonkey-2.0.11/comm-1.9.1/mozilla/toolkit/system/dbus/nsDBusService.h: * FALSE when NetworkManager reports NM_STATE_CONNECTED, and to TRUE otherwise. spicebird-0.7.1/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: NM_STATE_CONNECTED, spicebird-0.7.1/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: mLinkUp = result == NM_STATE_CONNECTED; spicebird-0.7.1/mozilla/toolkit/system/dbus/nsDBusService.h: * FALSE when NetworkManager reports NM_STATE_CONNECTED, and to TRUE otherwise. spicebird-0.7.1/mozilla/collab/external/pidgin/libpurple/network.c: else if (state == NM_STATE_CONNECTED) spicebird-0.7.1/mozilla/collab/external/pidgin/libpurple/network.c: case NM_STATE_CONNECTED: spicebird-0.7.1/mozilla/collab/external/pidgin/libpurple/network.c: if (prev != NM_STATE_CONNECTED) straw-0.27/src/lib/strawdbus.py:NM_STATE_CONNECTED = 3 straw-0.27/src/lib/strawdbus.py: if state == NM_STATE_CONNECTED: sugar-presence-service-0.90.1/src/psutils.py:_NM_STATE_CONNECTED = 3 sugar-presence-service-0.90.1/src/psutils.py: if state == _NM_STATE_CONNECTED: sugar-presence-service-0.90.1/src/psutils.py: elif new_state == _NM_STATE_CONNECTED: thunderbird-3.1.9/comm-1.9.2/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: NM_STATE_CONNECTED, thunderbird-3.1.9/comm-1.9.2/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp: mLinkUp = result == NM_STATE_CONNECTED; thunderbird-3.1.9/comm-1.9.2/mozilla/toolkit/system/dbus/nsDBusService.h: * FALSE when NetworkManager reports NM_STATE_CONNECTED, and to TRUE otherwise. vino-2.99.3/server/vino-upnp.c: if ((state == NM_STATE_CONNECTED) && (upnp->priv->internal_port != -1)) xca-0.9.0/_tmp_root/usr/lib/python2.7/site-packages/pyanaconda/isys/init.py:NM_STATE_CONNECTED = 3 xca-0.9.0/_tmp_root/usr/lib/python2.7/site-packages/pyanaconda/network.py: if int(state) == isys.NM_STATE_CONNECTED: xca-0.9.0/_tmp_root/usr/lib/python2.7/site-packages/pyanaconda/network.py: if int(state) == isys.NM_STATE_CONNECTED: xca-0.9.0/_tmp_root/usr/lib/python2.7/site-packages/pyanaconda/network.py: if int(state) == isys.NM_STATE_CONNECTED: xchat-gnome-0.26.1/plugins/net-monitor/net-monitor.c: NM_STATE_CONNECTED, xulrunner-2.0/mozilla-2.0/toolkit/system/dbus/nsNetworkManagerListener.cpp: NM_STATE_CONNECTED, xulrunner-2.0/mozilla-2.0/toolkit/system/dbus/nsNetworkManagerListener.cpp: mLinkUp = result == NM_STATE_CONNECTED; xulrunner-2.0/mozilla-2.0/toolkit/system/dbus/nsDBusService.h: * FALSE when NetworkManager reports NM_STATE_CONNECTED, and to TRUE otherwise. ypbind-mt-1.32/src/ypbind_dbus_nm.c: NM_STATE_CONNECTED, ypbind-mt-1.32/src/ypbind_dbus_nm.c: if (state == NM_STATE_CONNECTED) ypbind-mt-1.32/src/ypbind_dbus_nm.c: if (state != NM_STATE_CONNECTED) zeroinstall-injector-0.52/zeroinstall/injector/background.py: NM_STATE_CONNECTED = 3 zeroinstall-injector-0.52/zeroinstall/injector/background.py: if network_state != _NetworkState.NM_STATE_CONNECTED:
}}}
(fwiw, xulrunner and thunderbird don't need to be updated yet. The code to start up the NM service is currently broken. Stransky has a patch to the component loading code which has potential for disaster, so I'm waiting for upstream feedback before pushing to our builds, and have also made sure upstream knows about Dan's additional patch to get it to work with NM 0.9; we'll get both at the same time.)
It turns out that google-gadgets-for-linux needs to be ported to xulrunner-2 before it'll even build, regardless of the NetworkManager changes. I've submitted the NM bits upstream already though, but I'm not going to port it to xulrunner2...
Missing in the list are: * kdebase-workspace: contains portions of kde-plasma-networkmanagement code (the solidcontrol layer), handled by the compat code which supports kde-plasma-networkmanagement, patched package already built in dist-f15-updates-candidate * kdebase-runtime: contains the solid-networkstatus code, ltinkl committed a patch upstream (which doesn't need any compat code in NM, this is client code which was trivial to port unlike the applet), a F15 build with that patch is already in dist-f15-updates-candidate
The xchat-gnome code mentioned doesn't work right with 0.8 in my testing, much less 0.9. I'll work on fixing it, but given that it's not a regression, less of a priority.
Replying to [comment:63 notting]:
I ported that and submitted a patch upstream, but not many people use it anymore these days.
https://bugzilla.gnome.org/show_bug.cgi?id=646373
We forgot one: Yumex is not working any longer
Ah, yumex got fixed in https://admin.fedoraproject.org/updates/yumex-3.0.2-1.fc15
Login to comment on this ticket.