migration to NM 0.9 and ask for help

[Jirka Klimes]

Hello,

I'd like to bring your attention to KNM and to the effort to make it work
with new NM 0.9.

As you probably know NetworkManager 0.9 will be released shortly.
It changes its API and KNM has to be adapted to work with that.
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
The migration document describes what has changed and what should be done
in applications.

The main change is removing user setting service and using just one (system)
setting service. But KNM doesn't support system connections. Luckily G?k?en
Eraslan implemented that some time ago in his clone:
http://quickgit.kde.org/?p=clones%2Fnetworkmanagement%2Fgokcen%2Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
The branch also contains other changes/fixes that may be interesting.

I did some tests to try whether KNM could work with new KNM and has been
successful to some extent (basic functionality work: listing connections,
activating, deactivating).
I cherry-picked some commits relating to system-wide connections from the
G?k?en repo and applied them on KNM master branch and tested them a bit. They
appear to work.
And then I started to do some changes related to migration for NM 0.9.

I basically did this:
* generated proxy for org.freedesktop.NetworkManager interface
(Activate/DeactivateConnection(), ...)
- the methods removes "service" argument
* updated introspection and generated proxy for
org.freedesktop.NetworkManager.Connection.Active interface
* accomodate device/connection states
* fix listing connecions
* some other fixes
* I did *not* removeed unnecessary code (yeah, there will be more removals
then additions)
* I did *not* implement a secrets agent

Basically, I bypasses Solid::Control where things changed instead of adapting
it.
All what I did are just quick changes trying to make things work. And it is by
no means complete.
It is also quite hard for me to follow the code due to many abstractions
layers, backends, unnecessary complexity. And due tomy lack of familiarity
with KDE/Qt stuff, of course. I feel that I'm not able to do the transition to
NM 0.9 myself. Also i's not clear how the changes should be managed because
the KNM design will probably (and hopefully) change. So, it would be helpful
if some KDE guys could step in and drive the adaption of design and transition
to NM 0.9.

Luckily, Will Stephenson already started a libnm-qt (similar to libnm-glib),
that will hopefully remove Solid::Control, backends and other redundant
layers, and will simplify the design. Also Likas Tinkl expressed a will to
work on libnm-qt to get it into shape. The library is not public yet, though
and I haven't seen it.

Cheers,
Jirka

PS:
- Please see attached patches with my changes and test (based on master
branch)
- Sorry for not pushing that to a branch, but I don't have an account yet.
(Is it possible to create some scratch branches on anongit or something?)

[Jirka Klimes]

Attachment 1:
commits from G?k?en Eraslan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: knm_NM09_gokcen.tgz
Type: application/x-compressed-tar
Size: 20552 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-networkmanager/attachments/20110321/2db81cf4/attachment-0001.tgz

[Jirka Klimes]

Attachment 2:
My commits doing some adaptions to NM 0.9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: knm_NM09_my.tgz
Type: application/x-compressed-tar
Size: 18317 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-networkmanager/attachments/20110321/4bee99e8/attachment.tgz

[Lamarque Vieira Souza]

Post by Jirka Klimes
Hello,

Hello,

Post by Jirka Klimes
I'd like to bring your attention to KNM and to the effort to make it work
with new NM 0.9.

Good, we (or I must say I) need help with this.

Post by Jirka Klimes
* generated proxy for org.freedesktop.NetworkManager interface
(Activate/DeactivateConnection(), ...)
- the methods removes "service" argument
* updated introspection and generated proxy for
org.freedesktop.NetworkManager.Connection.Active interface
* accomodate device/connection states
* fix listing connecions
* some other fixes
* I did *not* removeed unnecessary code (yeah, there will be more removals
then additions)
* I did *not* implement a secrets agent

Is user connections still working after your changes?

Post by Jirka Klimes
Basically, I bypasses Solid::Control where things changed instead of
adapting it.
All what I did are just quick changes trying to make things work. And it is
by no means complete.
It is also quite hard for me to follow the code due to many abstractions
layers, backends, unnecessary complexity. And due tomy lack of familiarity
with KDE/Qt stuff, of course. I feel that I'm not able to do the transition
to NM 0.9 myself. Also i's not clear how the changes should be managed
because the KNM design will probably (and hopefully) change. So, it would
be helpful if some KDE guys could step in and drive the adaption of design
and transition to NM 0.9.

I agree, it is also hard for the to do some changes because of the too
many abstractions. It was Will Stephenson who designed most the abstractions,
so he would be the best person to ask about how to improve them but he is
missing in the list for some time. I usually try to follow the abstractions
but for some changes it is very troublesome. Yesterday I tried to improve SIM
PIN unlock for 3G modems to close a bug entry in bugs.kde.org and hitted the
abstractions again :-/

Post by Jirka Klimes
Luckily, Will Stephenson already started a libnm-qt (similar to
libnm-glib), that will hopefully remove Solid::Control, backends and other
redundant layers, and will simplify the design. Also Likas Tinkl expressed
a will to work on libnm-qt to get it into shape. The library is not public
yet, though and I haven't seen it.

Me too.

Post by Jirka Klimes
Cheers,
Jirka
- Please see attached patches with my changes and test (based on master
branch)
- Sorry for not pushing that to a branch, but I don't have an account yet.
(Is it possible to create some scratch branches on anongit or something?)

I can create a nm09 branch on git://anongit.kde.org/networkmanagement.git

To ask for a KDE account follow these instructions
http://techbase.kde.org/Contribute/Get_a_SVN_Account , at least that was what
I did when I asked for my KDE account :-) After that you can set up you local
git repository following the instructions in
http://techbase.kde.org/Getting_Started/Sources/KDE_git-tutorial and
http://community.kde.org/Sysadmin/GitKdeOrgManual

[Lamarque Vieira Souza]

Hi all,

As you all know we need to upgrade Plasma NM to support NetworkManager
0.9. I have created the branch nm09 in networkmanagement repository with the
changes from G?kcen Eraslan and Jirka Klimes. The code in there does *not*
work with NetworkManager-0.8.

Since the changes in NM-0.9 are very intrusive for Plasma NM I think it
is a good idea to keep two branches for networkmanagement, one for code meant
to work with NetworkManager-0.8 only and another for NetworkManager-0.9 only.
In practice that is what we already have (master for NM-0.8 and nm09 for
NM-0.9). I would like to also make the following changes:

1. Create a nm08 branch and change nm09 branch to be the master. I know
distribution packagers may not like this change.

2. Change the version number in the nm08 branch to me 0.8 instead of 0.9. That
would make it easier for distribution packagers /users know which one works
with each NM version.

3. In the future move Solid::Control::Network* namespace from Solid to nm08
branch and use libnm-qt only for the master branch (today nm09 branch). This
should be done by the KDE SC 4.7 release date.

That would allows us to concentrate efforts in NM-0.9 and let the code
for NM-0.8 in maintanance mode (no new features, only bug fixing). System
connections would be out of nm08 branch, less code /changes less bug fixing.

Will (the person, not the verb hehe), how is libnm-qt going? Is there a
release date? Will it support NM-0.9?

I have not started working in the nm09 branch because I am a bit
overwhelmed with bugfixing in VPN / MobileBroadband code and some other KDE
programs. I also do not have NetworkManager-0.9 snapshot installed yet.

Post by Jirka Klimes
Hello,
I'd like to bring your attention to KNM and to the effort to make it work
with new NM 0.9.
As you probably know NetworkManager 0.9 will be released shortly.
It changes its API and KNM has to be adapted to work with that.
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
The migration document describes what has changed and what should be done
in applications.
The main change is removing user setting service and using just one
(system) setting service. But KNM doesn't support system connections.
http://quickgit.kde.org/?p=clones%2Fnetworkmanagement%2Fgokcen%2Fnetworkman
agement.git&a=shortlog&h=refs/heads/systemwide The branch also contains
other changes/fixes that may be interesting.
I did some tests to try whether KNM could work with new KNM and has been
successful to some extent (basic functionality work: listing connections,
activating, deactivating).
I cherry-picked some commits relating to system-wide connections from the
G?k?en repo and applied them on KNM master branch and tested them a bit.
They appear to work.
And then I started to do some changes related to migration for NM 0.9.
* generated proxy for org.freedesktop.NetworkManager interface
(Activate/DeactivateConnection(), ...)
- the methods removes "service" argument
* updated introspection and generated proxy for
org.freedesktop.NetworkManager.Connection.Active interface
* accomodate device/connection states
* fix listing connecions
* some other fixes
* I did *not* removeed unnecessary code (yeah, there will be more removals
then additions)
* I did *not* implement a secrets agent
Basically, I bypasses Solid::Control where things changed instead of
adapting it.
All what I did are just quick changes trying to make things work. And it is
by no means complete.
It is also quite hard for me to follow the code due to many abstractions
layers, backends, unnecessary complexity. And due tomy lack of familiarity
with KDE/Qt stuff, of course. I feel that I'm not able to do the transition
to NM 0.9 myself. Also i's not clear how the changes should be managed
because the KNM design will probably (and hopefully) change. So, it would
be helpful if some KDE guys could step in and drive the adaption of design
and transition to NM 0.9.
Luckily, Will Stephenson already started a libnm-qt (similar to
libnm-glib), that will hopefully remove Solid::Control, backends and other
redundant layers, and will simplify the design. Also Likas Tinkl expressed
a will to work on libnm-qt to get it into shape. The library is not public
yet, though and I haven't seen it.
Cheers,
Jirka
- Please see attached patches with my changes and test (based on master
branch)
- Sorry for not pushing that to a branch, but I don't have an account yet.
(Is it possible to create some scratch branches on anongit or something?)
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

[Andrey Borzenkov]

Post by Lamarque Vieira Souza
Hi all,
As you all know we need to upgrade Plasma NM to support NetworkManager 0.9.
I have created the branch nm09 in networkmanagement repository with the
changes from G?kcen Eraslan and Jirka Klimes. The code in there does *not*
work with NetworkManager-0.8.
Since the changes in NM-0.9 are very intrusive for Plasma NM I think it is a
good idea to keep two branches for networkmanagement, one for code meant to
work with NetworkManager-0.8 only and another for NetworkManager-0.9 only.
In practice that is what we already have (master for NM-0.8 and nm09 for
1. Create a nm08 branch and change nm09 branch to be the master. I know
distribution packagers may not like this change.
2. Change the version number in the nm08 branch to me 0.8 instead of 0.9.
That would make it easier for distribution packagers /users know which one
works with each NM version.

This could be a problem for packagers too. Currently e.g. we package
version 0.9 ...

Post by Lamarque Vieira Souza
3. In the future move Solid::Control::Network* namespace from Solid to nm08
branch and use libnm-qt only for the master branch (today nm09 branch). This
should be done by the KDE SC 4.7 release date.
That would allows us to concentrate efforts in NM-0.9 and let the code for
NM-0.8 in maintanance mode (no new features, only bug fixing). System
connections would be out of nm08 branch, less code /changes less bug fixing.

Well ... I have half finished work on top of Gokcen branch that
re-enabled user connections again :) Right now I get them in
activateables list and can use to connect (including providing local
secrets). Editing should follow. Effectively it backs out some of
Gokcen changes and leaves current information exchange between kded
module and applet via on-disk file. This was the minimal change I
could find.

I can't comment on NM 0.9 because distro I am using won't have it in
near future so I am stuck with NM 0.8 anyway. For this reasons I
really would like to bring user+system settings support there ...

Post by Lamarque Vieira Souza
Will (the person, not the verb hehe), how is libnm-qt going? Is there a
release date? Will it support NM-0.9?
I have not started working in the nm09 branch because I am a bit overwhelmed
with bugfixing in VPN / MobileBroadband code and some other KDE programs. I
also do not have NetworkManager-0.9 snapshot installed yet.

Post by Jirka Klimes
Hello,
I'd like to bring your attention to KNM and to the effort to make it work
with new NM 0.9.
As you probably know NetworkManager 0.9 will be released shortly.
It changes its API and KNM has to be adapted to work with that.
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
The migration document describes what has changed and what should be done
in applications.
The main change is removing user setting service and using just one
(system) setting service. But KNM doesn't support system connections.
http://quickgit.kde.org/?p=clones%2Fnetworkmanagement%2Fgokcen%2Fnetworkman
agement.git&a=shortlog&h=refs/heads/systemwide The branch also contains
other changes/fixes that may be interesting.
I did some tests to try whether KNM could work with new KNM and has been
successful to some extent (basic functionality work: listing connections,
activating, deactivating).
I cherry-picked some commits relating to system-wide connections from the
G?k?en repo and applied them on KNM master branch and tested them a bit.
They appear to work.
And then I started to do some changes related to migration for NM 0.9.
* generated proxy for org.freedesktop.NetworkManager interface
(Activate/DeactivateConnection(), ...)
- the methods removes "service" argument
* updated introspection and generated proxy for
org.freedesktop.NetworkManager.Connection.Active interface
* accomodate device/connection states
* fix listing connecions
* some other fixes
* I did *not* removeed unnecessary code (yeah, there will be more removals
then additions)
* I did *not* implement a secrets agent
Basically, I bypasses Solid::Control where things changed instead of
adapting it.
All what I did are just quick changes trying to make things work. And it is
by no means complete.
It is also quite hard for me to follow the code due to many abstractions
layers, backends, unnecessary complexity. And due tomy lack of familiarity
with KDE/Qt stuff, of course. I feel that I'm not able to do the transition
to NM 0.9 myself. Also i's not clear how the changes should be managed
because the KNM design will probably (and hopefully) change. So, it would
be helpful if some KDE guys could step in and drive the adaption of design
and transition to NM 0.9.
Luckily, Will Stephenson already started a libnm-qt (similar to
libnm-glib), that will hopefully remove Solid::Control, backends and other
redundant layers, and will simplify the design. Also Likas Tinkl expressed
a will to work on libnm-qt to get it into shape. The library is not public
yet, though and I haven't seen it.
Cheers,
Jirka
- Please see attached patches with my changes and test (based on master
branch)
- Sorry for not pushing that to a branch, but I don't have an account yet.
(Is it possible to create some scratch branches on anongit or something?)
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://www.kde-mg.org
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

[Lamarque Vieira Souza]

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
2. Change the version number in the nm08 branch to me 0.8 instead of 0.9.
That would make it easier for distribution packagers /users know which
one works with each NM version.

This could be a problem for packagers too. Currently e.g. we package
version 0.9 ...

Ok, so let's bump the version to 0.91 instead.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
3. In the future move Solid::Control::Network* namespace from Solid to
nm08 branch and use libnm-qt only for the master branch (today nm09
branch). This should be done by the KDE SC 4.7 release date.
That would allows us to concentrate efforts in NM-0.9 and let the code
for NM-0.8 in maintanance mode (no new features, only bug fixing).
System connections would be out of nm08 branch, less code /changes less
bug fixing.

Well ... I have half finished work on top of Gokcen branch that
re-enabled user connections again :) Right now I get them in
activateables list and can use to connect (including providing local
secrets). Editing should follow. Effectively it backs out some of
Gokcen changes and leaves current information exchange between kded
module and applet via on-disk file. This was the minimal change I
could find.

We should use DBus to do data exchange between kded and the plasmoid. The
plasmoid already does that, the kded module has a DBus interface. The problem
is the other way around, the plasmoid does not have a DBus interface, but one
should not be necessary as far as I know.

Post by Andrey Borzenkov
I can't comment on NM 0.9 because distro I am using won't have it in
near future so I am stuck with NM 0.8 anyway. For this reasons I
really would like to bring user+system settings support there ...

I proposed to create a branch for NM-0.8 without system connections
support because Plasma NM is in short of work force. If you take the
responsability to maintain that part of the code then it should be no problem.

[Andrey Borzenkov]

On Fri, Mar 25, 2011 at 4:10 AM, Lamarque Vieira Souza

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
3. In the future move Solid::Control::Network* namespace from Solid to
nm08 branch and use libnm-qt only for the master branch (today nm09
branch). This should be done by the KDE SC 4.7 release date.
That would allows us to concentrate efforts in NM-0.9 and let the code
for NM-0.8 in maintanance mode (no new features, only bug fixing).
System connections would be out of nm08 branch, less code /changes less
bug fixing.

Well ... I have half finished work on top of Gokcen branch that
re-enabled user connections again :) Right now I get them in
activateables list and can use to connect (including providing local
secrets). Editing should follow. Effectively it backs out some of
Gokcen changes and leaves current information exchange between kded
module and applet via on-disk file. This was the minimal change I
could find.

We should use DBus to do data exchange between kded and the plasmoid. The
plasmoid already does that, the kded module has a DBus interface.

Yes, it should have been implemented this way. For now it does not do
it. I am not sure if putting efforts in redesigning it is worthwhile
as we speak about effectively dead end. Plasmoid for NM 0.9 won't need
to speak with kded at all - it will get all information from NM.

My immediate plans for now are

- add openconnect plugin
- factor out secrets persistence so it can be re-used in future secrets agent

Post by Lamarque Vieira Souza
The
problem is the other way around, the plasmoid does not have a DBus
interface, but one should not be necessary as far as I know.

Post by Andrey Borzenkov
I can't comment on NM 0.9 because distro I am using won't have it in
near future so I am stuck with NM 0.8 anyway. For this reasons I
really would like to bring user+system settings support there ...

I proposed to create a branch for NM-0.8 without system connections support
because Plasma NM is in short of work force. If you take the responsability
to maintain that part of the code then it should be no problem.

I do have plans to maintain this, yes. I do want to bring this feature
in our next distro, so hopefully I will have feedback.