Re: [Sugar-devel] [ASLO] Release Dimensions (AKA Visual Match)-38
On Tue, May 1, 2012 at 1:22 AM, Kalpa Welivitigoda callka...@gmail.com wrote: On Tue, May 1, 2012 at 3:54 AM, Walter Bender walter.ben...@gmail.com wrote: I think it is a better name, so we may as well make the change. Anything I need to do on my end? nothing from your end. Since I have already issued an update with V38 I'll update the name from V39 onwards. What should we do to address this name change in Poolttle? We never really did anything when Oficina became known as Paint (perhaps we should), but we would need to coordinate git changes with Pootle changes. cjl Sugar Labs Translation Team Coordinator cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Any ideas please, regarding the two latest queries :) ? Regards, Ajay On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote: Thanks Martin and Jon for the replies. On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote: On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Are you guys still using this? http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh If so, you should remove it IF there is no way to guarantee that it will run before NM picks up the device. At least it will avoid the crash... I would ask in the NM community if there is a better way to disable a particular device, like banning a device(?). Edit /etc/NetworkManager/NetworkManager.conf Add a line to the [main] section like no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the mac-address of your mesh device.) This should be a lot cleaner solution. However, two queries :: a) Doing ifconfig on the XO-1, only shows information for eth0 and lo (no mesh device listed). So, how can the mac address for the mesh device be found? b) Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet? Looking forward to a reply. Thanks and Regards, Ajay This does not stop NM from managing your device, but does stop it from auto-connecting the device. You would still be able to go into NM and manually enable the mesh network. If you want NM to completely leave the device alone you can go one more step. Also in /etc/NetworkManager/NetworkManager.conf change the plugins line to plugins=ifcfg-rh,keyfile Then add a section that looks like this. [keyfile] unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address of the device you want to ignore) Hope that helps, let me know if you have further questions. -Jon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
ajay wrote: Any ideas please, regarding the two latest queries :) ? Regards, Ajay On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote: Thanks Martin and Jon for the replies. On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote: On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Are you guys still using this? http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post resume.d/disable_mesh.sh If so, you should remove it IF there is no way to guarantee that it will run before NM picks up the device. At least it will avoid the crash... I would ask in the NM community if there is a better way to disable a particular device, like banning a device(?). Edit /etc/NetworkManager/NetworkManager.conf Add a line to the [main] section like no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the mac-address of your mesh device.) This should be a lot cleaner solution. However, two queries :: a) Doing ifconfig on the XO-1, only shows information for eth0 and lo (no mesh device listed). So, how can the mac address for the mesh device be found? it's the same as that for eth0. b) Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet? of course not. how would they tell one another apart? paul Looking forward to a reply. Thanks and Regards, Ajay This does not stop NM from managing your device, but does stop it from auto-connecting the device. You would still be able to go into NM and manually enable the mesh network. If you want NM to completely leave the device alone you can go one more step. Also in /etc/NetworkManager/NetworkManager.conf change the plugins line to plugins=ifcfg-rh,keyfile Then add a section that looks like this. [keyfile] unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address of the device you want to ignore) Hope that helps, let me know if you have further questions. -Jon part 2 text/plain 129 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Thanks Paul. On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote: ajay wrote: Any ideas please, regarding the two latest queries :) ? Regards, Ajay On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote: Thanks Martin and Jon for the replies. On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote: On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Are you guys still using this? http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post resume.d/disable_mesh.sh If so, you should remove it IF there is no way to guarantee that it will run before NM picks up the device. At least it will avoid the crash... I would ask in the NM community if there is a better way to disable a particular device, like banning a device(?). Edit /etc/NetworkManager/NetworkManager.conf Add a line to the [main] section like no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the mac-address of your mesh device.) This should be a lot cleaner solution. However, two queries :: a) Doing ifconfig on the XO-1, only shows information for eth0 and lo (no mesh device listed). So, how can the mac address for the mesh device be found? it's the same as that for eth0. Does that mean, that banning eth0-mac-address prevent the loading of wifi-hardware-device as well (in obvious addition to mesh) ? This seems very pricky. b) Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet? of course not. how would they tell one another apart? Alright. But my first doubt (same mac address for mesh-hardware and wifi-hardware) has put me in topspin :~ Regards, Ajay paul Looking forward to a reply. Thanks and Regards, Ajay This does not stop NM from managing your device, but does stop it from auto-connecting the device. You would still be able to go into NM and manually enable the mesh network. If you want NM to completely leave the device alone you can go one more step. Also in /etc/NetworkManager/NetworkManager.conf change the plugins line to plugins=ifcfg-rh,keyfile Then add a section that looks like this. [keyfile] unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address of the device you want to ignore) Hope that helps, let me know if you have further questions. -Jon part 2 text/plain 129 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Thanks Paul. I will give it a try myself. Just one last question :: I suppose that 'echo 0 /sys/class/net/eth0/lbs_mesh' is a hack that is olpc-customised. So, I will be really grateful if you could point me to some docs (a wiki page may be), that provide information as to how this hack affects, and is affected. Thanks for your help. Regards, Ajay On Tue, May 1, 2012 at 8:36 PM, Paul Fox p...@laptop.org wrote: ajay wrote: Thanks Paul. On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote: ajay wrote: Any ideas please, regarding the two latest queries :) ? Regards, Ajay On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote: Thanks Martin and Jon for the replies. On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote: On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Are you guys still using this? http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post resume.d/disable_mesh.sh If so, you should remove it IF there is no way to guarantee that it will run before NM picks up the device. At least it will avoid the crash... I would ask in the NM community if there is a better way to disable a particular device, like banning a device(?). Edit /etc/NetworkManager/NetworkManager.conf Add a line to the [main] section like no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the mac-address of your mesh device.) This should be a lot cleaner solution. However, two queries :: a) Doing ifconfig on the XO-1, only shows information for eth0 and lo (no mesh device listed). So, how can the mac address for the mesh device be found? it's the same as that for eth0. Does that mean, that banning eth0-mac-address prevent the loading of wifi-hardware-device as well (in obvious addition to mesh) ? This seems very pricky. i don't know. i'm unfamiliar with NM config. it doesn't sound too hard to try. paul b) Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet? of course not. how would they tell one another apart? Alright. But my first doubt (same mac address for mesh-hardware and wifi-hardware) has put me in topspin :~ Regards, Ajay paul Looking forward to a reply. Thanks and Regards, Ajay This does not stop NM from managing your device, but does stop it from auto-connecting the device. You would still be able to go into NM and manually enable the mesh network. If you want NM to completely leave the device alone you can go one more step. Also in /etc/NetworkManager/NetworkManager.conf change the plugins line to plugins=ifcfg-rh,keyfile Then add a section that looks like this. [keyfile] unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address of the device you want to ignore) Hope that helps, let me know if you have further questions. -Jon part 2 text/plain 129 ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
On Tue, 2012-05-01 at 20:50 +0530, Ajay Garg wrote: Thanks Paul. I will give it a try myself. Just one last question :: I suppose that 'echo 0 /sys/class/net/eth0/lbs_mesh' is a hack that is olpc-customised. So, I will be really grateful if you could point me to some docs (a wiki page may be), that provide information as to how this hack affects, and is affected. Ajay: http://wiki.laptop.org/go/Mesh_Network_Details http://wiki.laptop.org/go/Wireless_Driver_README Are installing the dextrose-platform rpm? http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm Jerry Thanks for your help. Regards, Ajay On Tue, May 1, 2012 at 8:36 PM, Paul Fox p...@laptop.org wrote: ajay wrote: Thanks Paul. On Tue, May 1, 2012 at 8:03 PM, Paul Fox p...@laptop.org wrote: ajay wrote: Any ideas please, regarding the two latest queries :) ? Regards, Ajay On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg a...@activitycentral.com wrote: Thanks Martin and Jon for the replies. On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton jon.nettle...@gmail.comwrote: On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Are you guys still using this? http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post resume.d/disable_mesh.sh If so, you should remove it IF there is no way to guarantee that it will run before NM picks up the device. At least it will avoid the crash... I would ask in the NM community if there is a better way to disable a particular device, like banning a device(?). Edit /etc/NetworkManager/NetworkManager.conf Add a line to the [main] section like no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the mac-address of your mesh device.) This should be a lot cleaner solution. However, two queries :: a) Doing ifconfig on the XO-1, only shows information for eth0 and lo (no mesh device listed). So, how can the mac address for the mesh device be found? it's the same as that for eth0. Does that mean, that banning eth0-mac-address prevent the loading of wifi-hardware-device as well (in obvious addition to mesh) ? This seems very pricky. i don't know. i'm unfamiliar with NM config. it doesn't sound too hard to try. paul b) Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet? of course not. how would they tell one another apart? Alright. But my first doubt (same mac address for mesh-hardware and wifi-hardware) has put me in topspin :~ Regards, Ajay paul Looking forward to a reply. Thanks and Regards, Ajay This does not stop NM from managing your device, but does stop it from auto-connecting the device. You would still be able to go into NM and manually enable the mesh network. If you want NM to completely leave the device alone you can go one more step. Also in /etc/NetworkManager/NetworkManager.conf change the plugins line to plugins=ifcfg-rh,keyfile Then add a section that looks like this. [keyfile] unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address of the device you want to ignore)
[Sugar-devel] [PATCH v3 sugar-datastore 2/2] Add API to check/wait for index rebuild to finish (SL#1160)
The data store (re)builds the index in the background (idle loop), but
has no API to wait for this to finish. While it rebuilds the index, some API
functions work differently than they do during regular operation. In
particular, the find() function returns all entries, rather than just matching
ones. The requested sort order isn't respected, either.
This fact isn't mentioned in any public API description, so very few clients
are designed with it in mind. Every client would need to duplicate an important
subset of the data store functionality: filtering and sorting. The one
advantage of this approach is that, at least in theory, the data store is ready
to operate right away, allowing the user to start working. In practice, the
advantage isn't quite as clear: Migration happens synchronously [2] and
rebuilding is either fast (removing the need for it to happen in the
background) or takes significant system resources, reducing the usefulness of
the system while the rebuild is happening.
For these reasons, for most clients it's better to just wait for the data store
to finish rebuilding. We're adding API to allow them to do just that, in both
synchronous and asynchronous ways. wait_ready() blocks until the data store is
ready, whereas the Ready signal and the check_ready() function allow
implementing a race-free, asynchronous check.
Clients can now choose (and the Activity framework should probably do so by
default) to either wait for the rebuild to complete or cope with whatever the
data store does differently during rebuild.
The additional API functions don't affect the rest of the API in any way. The
queue that we add as part of this patch handles only the outstanding
wait_ready() calls. Other invocations get handled immediately.
It could be argued that index rebuilds should happen rarely in the field and we
should just always block until the data store is ready for normal operation. If
rebuilds are happening often in the field, we should analyse and fix the reason
for this, rather than covering up by making rebuild asynchronous and providing
inconsistent API. This patch provides a reasonable middle ground that we can
build on. If or when data store rebuilds happen rarely in the field, we can
still switch to blocking at start-up.
[1] https://bugs.sugarlabs.org/ticket/1160
[2] https://bugs.sugarlabs.org/ticket/1546
Signed-off-by: Sascha Silbe si...@activitycentral.com
---
v2-v3: Significantly enhanced description; no code changes
src/carquinyol/datastore.py | 38 ++
1 file changed, 38 insertions(+)
diff --git a/src/carquinyol/datastore.py b/src/carquinyol/datastore.py
index de79500..3c0c294 100644
--- a/src/carquinyol/datastore.py
+++ b/src/carquinyol/datastore.py
@@ -52,6 +52,7 @@ class DataStore(dbus.service.Object):
def __init__(self, **options):
+self._wait_ready_queue = []
bus_name = dbus.service.BusName(DS_SERVICE,
bus=dbus.SessionBus(),
replace_existing=False,
@@ -164,6 +165,12 @@ class DataStore(dbus.service.Object):
self._index_store.flush()
self._index_updating = False
logging.debug('Finished updating index.')
+
+self.Ready()
+for callback in self._wait_ready_queue:
+callback()
+
+self._wait_ready_queue = []
return False
else:
return True
@@ -443,3 +450,34 @@ class DataStore(dbus.service.Object):
@dbus.service.signal(DS_DBUS_INTERFACE, signature=a{sv})
def Unmounted(self, descriptor):
pass
+
+@dbus.service.method(DS_DBUS_INTERFACE,
+ in_signature='',
+ out_signature='b')
+def check_ready(self):
+Check whether datastore is ready for processing (regular) API
+calls.
+
+Return True if datastore is fully operational.
+
+return not self._index_updating
+
+@dbus.service.method(DS_DBUS_INTERFACE,
+ in_signature='',
+ out_signature='',
+ async_callbacks=('async_cb', 'async_err_cb'))
+def wait_ready(self, async_cb, async_err_cb):
+Block until the datastore is ready for processing (regular) API
+calls.
+
+if not self._index_updating:
+async_cb()
+return
+
+self._wait_ready_queue.append(async_cb)
+
+@dbus.service.signal(DS_DBUS_INTERFACE, signature='')
+def Ready(self):
+Signal emitted after datastore is ready for processing API calls.
+
+pass
--
1.7.9.5
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Hi all. I'll ask this straight :: Is there an already tested-cum-recommended method, that could disable mesh-network, both during reboots and resume-from-suspend? Possible options (not tested by me) :: a) A driver, encapsulating the patch at http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES) Query : How can I ascertain if this patch is present on a particular XO-1? b) (For Reboot) :: Add the bootstrap script 'echo 0 /sys/class/net/eth0/lbs_mesh' in '/etc/init.d/NetworkMaanager'. (For Resume-Upon-Suspend) :: Add the disable_mesh.sh script (at http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm) in /etc/powerd/postresume.d. Query : While the (For Reboot) case is guaranteed to work stably every single time, can the same be said about (For Resume-Upon-Suspend) ? c) Any other unknown in-the-dark hack. Regards, Ajay On Tue, May 1, 2012 at 9:36 PM, Peter Robinson pbrobin...@gmail.com wrote: On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com wrote: which actually brings me back to my original question :: Why is it so that putting the 'disable-mesh-script' in the 'start()' method of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works for resume-upon-suspend? Because on suspend/resume the NetworkManager service isn't started/restarted so the script in /etc/init.d isn't run where as on reboot it is. There's means though to run specific scripts on suspend/resume if that sort of thing is necessary. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Just an updated version :: Hi all. I'll ask this straight :: Is there an already tested-cum-recommended method, that could disable mesh-network, both during reboots and resume-from-suspend? Possible options (not tested by me) :: a) A driver, encapsulating the patch at http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES) Query : How can I ascertain if this patch is present on a particular XO-1? b) (For Reboot) :: Add the bootstrap script 'echo 0 /sys/class/net/eth0/lbs_mesh' in '/etc/init.d/NetworkMaanager'. (For Resume-Upon-Suspend) :: Add the disable_mesh.sh script (at http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm) in /etc/powerd/postresume.d. Query : While the (For Reboot) case is guaranteed to work stably every single time, can the same be said about (For Resume-Upon-Suspend) ? Answer : No. The (Resume-Upon-Suspend) case does not work. So, this solution is rejected. c) Any other unknown in-the-dark hack. Regards, Ajay On Wed, May 2, 2012 at 9:10 AM, Ajay Garg a...@activitycentral.com wrote: Hi all. I'll ask this straight :: Is there an already tested-cum-recommended method, that could disable mesh-network, both during reboots and resume-from-suspend? Possible options (not tested by me) :: a) A driver, encapsulating the patch at http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES) Query : How can I ascertain if this patch is present on a particular XO-1? b) (For Reboot) :: Add the bootstrap script 'echo 0 /sys/class/net/eth0/lbs_mesh' in '/etc/init.d/NetworkMaanager'. (For Resume-Upon-Suspend) :: Add the disable_mesh.sh script (at http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm) in /etc/powerd/postresume.d. Query : While the (For Reboot) case is guaranteed to work stably every single time, can the same be said about (For Resume-Upon-Suspend) ? c) Any other unknown in-the-dark hack. Regards, Ajay On Tue, May 1, 2012 at 9:36 PM, Peter Robinson pbrobin...@gmail.comwrote: On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com wrote: which actually brings me back to my original question :: Why is it so that putting the 'disable-mesh-script' in the 'start()' method of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works for resume-upon-suspend? Because on suspend/resume the NetworkManager service isn't started/restarted so the script in /etc/init.d isn't run where as on reboot it is. There's means though to run specific scripts on suspend/resume if that sort of thing is necessary. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote: Is there an already tested-cum-recommended method, that could disable mesh-network, both during reboots and resume-from-suspend? Not that I know of. But I'm curious, why do you need to do this? Is there some other problem you think you will solve with this? There might be an alternate solution. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Thanks James for the reply.
On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
Not that I know of.
But I'm curious, why do you need to do this? Is there some other
problem you think you will solve with this? There might be an alternate
solution.
No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.
Right now, we were trying the disable-mesh-script (''echo 0
/sys/class/net/eth0/lbs_mesh) for our purpose.
Now, I am thinking of removing all references to devices of type
DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do it.
Thanks to all for your quick responses.
Thanks and Regards,
Ajay
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
Thanks James for the reply.
On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
Not that I know of.
But I'm curious, why do you need to do this? Is there some other
problem you think you will solve with this? There might be an alternate
solution.
No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.
But why?
Right now, we were trying the disable-mesh-script (''echo 0 /sys/class/net/
eth0/lbs_mesh) for our purpose.
Now, I am thinking of removing all references to devices of type
DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do it.
Yes, that should do it.
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
On Wed, May 2, 2012 at 9:39 AM, James Cameron qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
Thanks James for the reply.
On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
Is there an already tested-cum-recommended method, that could
disable
mesh-network, both during reboots and resume-from-suspend?
Not that I know of.
But I'm curious, why do you need to do this? Is there some other
problem you think you will solve with this? There might be an
alternate
solution.
No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.
But why?
Just that, we do not wish to set up a mesh-network, as per say.
By removing all references to the device, we could provide a soft
solution :)
Thanks again.
Regards,
Ajay
Right now, we were trying the disable-mesh-script (''echo 0
/sys/class/net/
eth0/lbs_mesh) for our purpose.
Now, I am thinking of removing all references to devices of type
DEVICE_TYPE_802_11_OLPC_MESH from sugar-code. I think that should do
it.
Yes, that should do it.
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Hi, On Wed, May 02 2012, Ajay Garg wrote: Just wish to remove the mesh-icons from Neighborhood-View. Have you considered just removing the icons directly? diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py index 20dc413..0aa8c7f 100644 --- a/src/jarabe/desktop/meshbox.py +++ b/src/jarabe/desktop/meshbox.py @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox): def enable_olpc_mesh(self, mesh_device): mesh_mgr = OlpcMeshManager(mesh_device) -self._add_olpc_mesh_icon(mesh_mgr, 1) -self._add_olpc_mesh_icon(mesh_mgr, 6) -self._add_olpc_mesh_icon(mesh_mgr, 11) +#self._add_olpc_mesh_icon(mesh_mgr, 1) +#self._add_olpc_mesh_icon(mesh_mgr, 6) +#self._add_olpc_mesh_icon(mesh_mgr, 11) # the OLPC mesh can be recognised as a normal wifi network. remove # any such normal networks if they have been created -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play with :P Regards, Ajay On Wed, May 2, 2012 at 10:42 AM, James Cameron qu...@laptop.org wrote: If all you wish to do is remove the mesh icons from the network neighbourhood, why would you also want to clean up the model? On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote: Yes Chris, that certainly is an option. But removing the references to the device itself, would clean up both the model and the view; whereas this (as I think) only removes the view. Regards, Ajay On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote: Hi, On Wed, May 02 2012, Ajay Garg wrote: Just wish to remove the mesh-icons from Neighborhood-View. Have you considered just removing the icons directly? diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py index 20dc413..0aa8c7f 100644 --- a/src/jarabe/desktop/meshbox.py +++ b/src/jarabe/desktop/meshbox.py @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox): def enable_olpc_mesh(self, mesh_device): mesh_mgr = OlpcMeshManager(mesh_device) -self._add_olpc_mesh_icon(mesh_mgr, 1) -self._add_olpc_mesh_icon(mesh_mgr, 6) -self._add_olpc_mesh_icon(mesh_mgr, 11) +#self._add_olpc_mesh_icon(mesh_mgr, 1) +#self._add_olpc_mesh_icon(mesh_mgr, 6) +#self._add_olpc_mesh_icon(mesh_mgr, 11) # the OLPC mesh can be recognised as a normal wifi network. remove # any such normal networks if they have been created -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Okay. Take care not to add any when you change all those lines of code. ;-) On Wed, May 02, 2012 at 10:47:41AM +0530, Ajay Garg wrote: Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play with :P Regards, Ajay On Wed, May 2, 2012 at 10:42 AM, James Cameron qu...@laptop.org wrote: If all you wish to do is remove the mesh icons from the network neighbourhood, why would you also want to clean up the model? On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote: Yes Chris, that certainly is an option. But removing the references to the device itself, would clean up both the model and the view; whereas this (as I think) only removes the view. Regards, Ajay On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote: Hi, On Wed, May 02 2012, Ajay Garg wrote: Just wish to remove the mesh-icons from Neighborhood-View. Have you considered just removing the icons directly? diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/ meshbox.py index 20dc413..0aa8c7f 100644 --- a/src/jarabe/desktop/meshbox.py +++ b/src/jarabe/desktop/meshbox.py @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox): def enable_olpc_mesh(self, mesh_device): mesh_mgr = OlpcMeshManager(mesh_device) -self._add_olpc_mesh_icon(mesh_mgr, 1) -self._add_olpc_mesh_icon(mesh_mgr, 6) -self._add_olpc_mesh_icon(mesh_mgr, 11) +#self._add_olpc_mesh_icon(mesh_mgr, 1) +#self._add_olpc_mesh_icon(mesh_mgr, 6) +#self._add_olpc_mesh_icon(mesh_mgr, 11) # the OLPC mesh can be recognised as a normal wifi network. remove # any such normal networks if they have been created -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Haha.. Okies.. :) :) Regards, Ajay On Wed, May 2, 2012 at 10:55 AM, James Cameron qu...@laptop.org wrote: Okay. Take care not to add any when you change all those lines of code. ;-) On Wed, May 02, 2012 at 10:47:41AM +0530, Ajay Garg wrote: Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play with :P Regards, Ajay On Wed, May 2, 2012 at 10:42 AM, James Cameron qu...@laptop.org wrote: If all you wish to do is remove the mesh icons from the network neighbourhood, why would you also want to clean up the model? On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote: Yes Chris, that certainly is an option. But removing the references to the device itself, would clean up both the model and the view; whereas this (as I think) only removes the view. Regards, Ajay On Wed, May 2, 2012 at 10:18 AM, Chris Ball c...@laptop.org wrote: Hi, On Wed, May 02 2012, Ajay Garg wrote: Just wish to remove the mesh-icons from Neighborhood-View. Have you considered just removing the icons directly? diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/ meshbox.py index 20dc413..0aa8c7f 100644 --- a/src/jarabe/desktop/meshbox.py +++ b/src/jarabe/desktop/meshbox.py @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox): def enable_olpc_mesh(self, mesh_device): mesh_mgr = OlpcMeshManager(mesh_device) -self._add_olpc_mesh_icon(mesh_mgr, 1) -self._add_olpc_mesh_icon(mesh_mgr, 6) -self._add_olpc_mesh_icon(mesh_mgr, 11) +#self._add_olpc_mesh_icon(mesh_mgr, 1) +#self._add_olpc_mesh_icon(mesh_mgr, 6) +#self._add_olpc_mesh_icon(mesh_mgr, 11) # the OLPC mesh can be recognised as a normal wifi network. remove # any such normal networks if they have been created -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- James Cameron http://quozl.linux.org.au/ -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
