Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com wrote: Just that, we do not wish to set up a mesh-network, as per say. I think you are missing the background reason here. AFAIK, reasons to disable mesh network on XO-1: - Mesh can easily saturate RF, so dense usage scenarios (schools!) benefit from switching it off. - Easier out-of-the-box interop with later XO-1.x models, where the under a tree network uses ad-hoc 802.11g. By removing all references to the device, we could provide a soft solution Nah, messing with Sugar code is the wrong solution. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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 11:49 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com wrote: Just that, we do not wish to set up a mesh-network, as per say. I think you are missing the background reason here. AFAIK, reasons to disable mesh network on XO-1: - Mesh can easily saturate RF, so dense usage scenarios (schools!) benefit from switching it off. - Easier out-of-the-box interop with later XO-1.x models, where the under a tree network uses ad-hoc 802.11g. +1, this was the reason By removing all references to the device, we could provide a soft solution Nah, messing with Sugar code is the wrong solution. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com wrote: I agree. But there is no working lower-level solution :\ Let's fix that. Messing with Sugar won't help you. Earlier in the thread someone pointed to you the scripts to trigger on resume (by powerd). Do those work? Not work? What's the problem there? AIUI, if you - disable mesh on boot - disable mesh on resume, from a powerd-triggered script - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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 Martin (a ton !!) On Wed, May 2, 2012 at 12:32 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com wrote: I agree. But there is no working lower-level solution :\ Let's fix that. Great !!! Messing with Sugar won't help you. Earlier in the thread someone pointed to you the scripts to trigger on resume (by powerd). Do those work? Not work? What's the problem there? The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. My belief is that there is the same problem - race condition between the 'echo 0' script, and NetworkManager. This causes the NetworkManager to crash randomly. AIUI, if you - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Could you point me to the suitable (examples) link? I will be heartfully grateful. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff Regards, Ajay ___ 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
I think (guessing by the responses) the original problem here is that, if you disable the mesh AFTER NM has taken the device, NM crashes. This a regression bug, considering that this didn't happened in fedora-11 based builds. So the solution here is to find another place to place the script, where it guarantee that the script will be executed before NM does its job at resume time. Another solution is to find out why NM crashes now and why didn't before, but I wouldn't go that way. Cheers, On Wed, May 2, 2012 at 3:28 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote: The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. So we need to understand why it does not work. Is it a race condition? Perhaps it is better fixed as a udev script -- triggering when the device appears. The step that disable_mesh performs is very important. If you don't disable it at that level, you haven't disabled mesh at all and all the problems persist. - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. Ok. Maybe a udev script is a better place. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. Right but you MUST find a way to make it work. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Careful here! This only hides the device from NM so you don't race with NM. Could you point me to the suitable (examples) link? I will be heartfully grateful. look at the latest olpc-configure in git:// dev.laptop.org/projects/olpc-utils m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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] [PATCH Browse] Graphic for the cancel loading button in the URL entry changed #3499
On 04/27/2012 11:58 AM, Manuel Quiñones wrote: Now features a square black background, to distingish it from the upcoming clear URL entry button. Signed-off-by: Manuel Quiñonesma...@laptop.org Hi Manu, thanks for the patch, I commented on the visual aspect in http://bugs.sugarlabs.org/ticket/3499#comment:8 Regards, Simon ___ 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 4:07 AM, Martin Abente martin.abente.lah...@gmail.com wrote: I think (guessing by the responses) the original problem here is that, if you disable the mesh AFTER NM has taken the device, NM crashes. This a regression bug, considering that this didn't happened in fedora-11 based builds. The timings in F11 builds were completely different. Maybe you were winning the race that you're now losing. So the solution here is to find another place to place the script, where it guarantee that the script will be executed before NM does its job at resume time. udev script :-) -- I am pretty sure you can number yourself lower (to run earlier) than the udev script that fires off the new device event to NM. Another solution is to find out why NM crashes now and why didn't before, but I wouldn't go that way. Making NM completely resilient to these race conditions is probably a hard task. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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
How hard and sensible do you think it could be to backport that patch? :D (Assuming that touching the kernel is an option for someone, hehe) On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton jon.nettle...@gmail.comwrote: On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, May 2, 2012 at 4:07 AM, Martin Abente martin.abente.lah...@gmail.com wrote: I think (guessing by the responses) the original problem here is that, if you disable the mesh AFTER NM has taken the device, NM crashes. This a regression bug, considering that this didn't happened in fedora-11 based builds. The timings in F11 builds were completely different. Maybe you were winning the race that you're now losing. So the solution here is to find another place to place the script, where it guarantee that the script will be executed before NM does its job at resume time. udev script :-) -- I am pretty sure you can number yourself lower (to run earlier) than the udev script that fires off the new device event to NM. Another solution is to find out why NM crashes now and why didn't before, but I wouldn't go that way. Making NM completely resilient to these race conditions is probably a hard task. This is also a temporary solution. There is a kernel patch in 3.1 and greater kernels that allows you to disable mesh as a kernel module parameter. I just played around with the udev script and there definitely seems to be some timing issues even with that. -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
Martin, just one small query : In one of the earlier mails, it was said that the mac address for msh0 is the same as eth0. So, would blacklisting the (same) device, be feasible? I mean, would that not _also_ disable general wifi network detections? Regards, Ajay On Wed, May 2, 2012 at 12:58 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote: The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. So we need to understand why it does not work. Is it a race condition? Perhaps it is better fixed as a udev script -- triggering when the device appears. The step that disable_mesh performs is very important. If you don't disable it at that level, you haven't disabled mesh at all and all the problems persist. - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. Ok. Maybe a udev script is a better place. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. Right but you MUST find a way to make it work. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Careful here! This only hides the device from NM so you don't race with NM. Could you point me to the suitable (examples) link? I will be heartfully grateful. look at the latest olpc-configure in git:// dev.laptop.org/projects/olpc-utils m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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 5:32 AM, Ajay Garg ajaygargn...@gmail.com wrote: In one of the earlier mails, it was said that the mac address for msh0 is the same as eth0. Ah, sorry, you're correct, that won't help. So your options are - a kernel module parameter, as Jon proposes, in modprobe.d/ or in the boot commandline - udev rule / script that triggers before the event is sent to NM m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Create a default unencrypted keyring, OLPC #10290
Thanks Sascha for commenting, On 04/23/2012 11:13 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of 2012-04-16 12:33:05 +0200: This patch does create an ununcrypted default keyring if there is not one available already. This will stop prompts for unlocking the keyring after logging into Sugar. In GNOME the session manager deals with creating that keyring. In the OLPC images we do create a default keyring on image creation time (see olpc-configure), same is true for Soas. This patch does check/create the keyring on every Sugar run. The advantage is that for example installs the live image to a disk install using liveinst, or install Sugar from the Fedora installer without installing or ever running GNOME that workaround will work for them as well. At least the patch description is too downstream-centric for my taste. It also looks like something the distro X session scripts should do, not sugar. It may be fine to include in sugar-emulator, because we're setting up the X session manually there, without calling the distro X session scripts. Ok the description can be tweaked, any suggestions? IIRC, somebody mentioned (on IRC?) that this functionality is also included in gnome-session. Replacing our ancient embedded copy of gnome-session in sugar-toolkit with using upstream gnome-session would do the trick as well then. I've been working with upstream on that for some time. gnome-session can now properly run non-default (read non-Gnome) sessions [1] and I have working sugar [2] and sugar-toolkit [3] patches to make use of that facility. The only reason I've not posted it for upstream (Sugar) inclusion is that gnome-session doesn't provide API for Sugar to trigger Shutdown and Reboot without presenting non-Sugar UI [4]. With the systemd support patch that landed recently (99bb52c [5]), this hurdle is gone at least on systemd based systems (i.e. Fedora). Great work, I am keen on making this happen in the 0.98 cycle. In the meantime I think this workaround is good to have, I heard rumors that Peter will patch the Fedora rpm with it. Regards, Simon ___ 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
martin wrote: On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote: The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. So we need to understand why it does not work. Is it a race condition? Perhaps it is better fixed as a udev script -- triggering when the device appears. i think it's almost a guaranteed race. that script essentially does this: while [ ! -f /sys/class/net/eth0/lbs_mesh ] do sleep 0.5 done echo 0 /sys/class/net/eth0/lbs_mesh in other words -- the disable_mesh script will discover the disable node at just about exactly the time that NM discovers the interface. there's also the lbs_disablemesh module parameter, which could be supplied at initial module load. does that not work, for some reason? (i seem to recall there may be a problem with it.) paul The step that disable_mesh performs is very important. If you don't disable it at that level, you haven't disabled mesh at all and all the problems persist. - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. Ok. Maybe a udev script is a better place. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. Right but you MUST find a way to make it work. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Careful here! This only hides the device from NM so you don't race with NM. Could you point me to the suitable (examples) link? I will be heartfully grateful. look at the latest olpc-configure in git://dev.laptop.org/projects/olpc-utils m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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
Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 Regards, Ajay On Wed, May 2, 2012 at 6:02 PM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote: The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. So we need to understand why it does not work. Is it a race condition? Perhaps it is better fixed as a udev script -- triggering when the device appears. i think it's almost a guaranteed race. that script essentially does this: while [ ! -f /sys/class/net/eth0/lbs_mesh ] do sleep 0.5 done echo 0 /sys/class/net/eth0/lbs_mesh in other words -- the disable_mesh script will discover the disable node at just about exactly the time that NM discovers the interface. there's also the lbs_disablemesh module parameter, which could be supplied at initial module load. does that not work, for some reason? (i seem to recall there may be a problem with it.) paul The step that disable_mesh performs is very important. If you don't disable it at that level, you haven't disabled mesh at all and all the problems persist. - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. Ok. Maybe a udev script is a better place. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. Right but you MUST find a way to make it work. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Careful here! This only hides the device from NM so you don't race with NM. Could you point me to the suitable (examples) link? I will be heartfully grateful. look at the latest olpc-configure in git:// dev.laptop.org/projects/olpc-utils m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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
On Wed, May 2, 2012 at 7:57 PM, Kevin Gordon kgordon...@gmail.com wrote: On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote: Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 I have a couple of minor observations from the great unwashed - yes me. One is that this solution perhaps wont have any effect when one boots to the Gnome side. What could be the difference therein? (I could change to one, that could work in both) :) Regards, Ajay Two, this may be build version dependent, as there would appear from some of the discussions in the group that there is an effort for the 12.1.0 builds to more closely link the NM functions on Sugar and Gnome so that settings are identical when restarting the other environment. The echo script in boot startup and the corresponding entry powerd resume , on the other hand, might handle both. Not sure yet, as I'm still playing with WAP variants, and also, I am the newbie :-) Regards, Ajay On Wed, May 2, 2012 at 6:02 PM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote: The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. So we need to understand why it does not work. Is it a race condition? Perhaps it is better fixed as a udev script -- triggering when the device appears. i think it's almost a guaranteed race. that script essentially does this: while [ ! -f /sys/class/net/eth0/lbs_mesh ] do sleep 0.5 done echo 0 /sys/class/net/eth0/lbs_mesh in other words -- the disable_mesh script will discover the disable node at just about exactly the time that NM discovers the interface. there's also the lbs_disablemesh module parameter, which could be supplied at initial module load. does that not work, for some reason? (i seem to recall there may be a problem with it.) paul The step that disable_mesh performs is very important. If you don't disable it at that level, you haven't disabled mesh at all and all the problems persist. - disable mesh on boot Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so that the effect takes place before NetworkManager starts up. Works like a charm. Ok. Maybe a udev script is a better place. - disable mesh on resume, from a powerd-triggered script Does not work, as explained above. Right but you MUST find a way to make it work. - blacklist the MAC address so NM ignores it you win. Yes, every XO has a different MAC address, but you can read that on first boot of the OS, and write the NM configuration. See the olpc-configure script for examples. Would be awesome. I believe this is the one and only complete solution possible :) Careful here! This only hides the device from NM so you don't race with NM. Could you point me to the suitable (examples) link? I will be heartfully grateful. look at the latest olpc-configure in git:// dev.laptop.org/projects/olpc-utils m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Browse] Fix for the MIME type handling of a request SL #3512
We were not returning the right value, the callback
should return True if the signal is handled, False otherwise.
This fixes http://bugs.sugarlabs.org/ticket/3512
Signed-off-by: Manuel Quiñones ma...@laptop.org
---
browser.py | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/browser.py b/browser.py
index c0bb7bc..d61c1b8 100644
--- a/browser.py
+++ b/browser.py
@@ -532,14 +532,16 @@ class Browser(WebKit.WebView):
def __mime_type_policy_cb(self, webview, frame, request, mimetype,
policy_decision):
+Handle downloads and PDF files.
if mimetype == 'application/pdf':
self.emit('open-pdf', request.get_uri())
-return False
-elif self.can_show_mime_type(mimetype):
return True
-else:
+
+elif not self.can_show_mime_type(mimetype):
policy_decision.download()
-return True
+return True
+
+return False
def __new_window_policy_cb(self, webview, webframe, request,
navigation_action, policy_decision):
--
1.7.7.6
___
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
It's worth noting that half the battle can be won by overriding the following XO-1 specific line in OLPC OS Builder's kspost.50.xo1-tweaks.inc: gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --type bool --set /desktop/sugar/network/adhoc false Setting this to true, or letting it default to such will show the Ad-hoc networks by default on XO-1. It also will cause XO-1's to default to Ad-hoc if no preferred network is found. The mesh networks will still be there for manual use; but right now they seem semi-broken anyway on 12.1.0 as we attempt to connect to Mesh Network 0 and don't set a channel on the Interface. On Wed, May 2, 2012 at 10:29 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote: Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 The patch seems fairly wrong to me. You are hiding the mesh icons in sugar, but the mesh is active. Packet forwarding is still happening. One of the top reasons we stopped using mesh is because it saturates the RF spectrum, which is a bad thing to do when you have many users in a small space (ie: in a school). You had the mesh disable trick working on F11, and (I assume) happy users of that feature. With this, the feature is broken, but you're making the UI look right... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/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 2, 2012 at 7:59 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote: Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 The patch seems fairly wrong to me. You are hiding the mesh icons in sugar, but the mesh is active. Packet forwarding is still happening. Hmm, ok (didn't know this). I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) Regards, Ajay One of the top reasons we stopped using mesh is because it saturates the RF spectrum, which is a bad thing to do when you have many users in a small space (ie: in a school). You had the mesh disable trick working on F11, and (I assume) happy users of that feature. With this, the feature is broken, but you're making the UI look right... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/2012 07:59 PM, Martin Langhoff wrote: On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote: Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 The patch seems fairly wrong to me. You are hiding the mesh icons in sugar, but the mesh is active. Packet forwarding is still happening. One of the top reasons we stopped using mesh is because it saturates the RF spectrum, which is a bad thing to do when you have many users in a small space (ie: in a school). You had the mesh disable trick working on F11, and (I assume) happy users of that feature. With this, the feature is broken, but you're making the UI look right... I agree. The *problem* we are trying to solve is not to have a pretty mesh-icon-free-UI (which is a side effect), but disable the mesh at a hardware level. This patch *won't* solve the problem, as it will still flood the air with packet forwarding. - From the discussion, it seems to me that the kernel level switch is present in 12.x.x onwards, but not so for 11.3.x. In 10.3.x(f11) we got lucky as we were able to avoid the race condition. I suggest we keep looking for a proper solution: * Can the kernel fix be backported (might require a lot of work) * Can we tinker with the udev, postresume scripts to have it 'just' working I have reverted the commit: http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0 cheers, m - -- Anish -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPoU9PAAoJEBoxUdDHDZVp+DAH/j/RUl6AarwSlz0oUGIuPa5b FxpFOwO6edA0Avd4Zv0/0x3FWlaAEHwkkyz6Vcsq3Px0lxecX0JgYrEgaXWJP4l0 YRBqROOBCzkVKxk7dEWZ003igZSGKbSmuRMlj4v4Qpv0yU9Tfi/GS3T1Q+r02B0o igF9XjmLT5lFcZ4U1e7vE/foU4f7Y5ugg/TON6u/Oh0GNF8bDdOSkY/xKhGlAkIf 72d1pSt03ypcQgUHy7mRhORj1rc1d1YCWiyZLv2iUXdR2OyR8qjukw2HjQ2Gu5ts DwTeumIy+QSF7fDIZkE83dErrmLJLUGvQ/4oqT50zhgI63o+/v8qBpa40XRo3bc= =KMS0 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Browse] Use UNICODE string to search into places SL #2830
Decode (using 'utf-8') the string inserted by the user in the URL address bar
to search with SQLite into places' database.
Signed-off-by: Manuel Kaufmann humi...@gmail.com
---
webtoolbar.py |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/webtoolbar.py b/webtoolbar.py
index d0f2dc9..c595206 100644
--- a/webtoolbar.py
+++ b/webtoolbar.py
@@ -120,7 +120,8 @@ class WebEntry(iconentry.IconEntry):
def _search_update(self):
list_store = Gtk.ListStore(str, str)
-for place in places.get_store().search(self.props.text):
+search_text = self.props.text.decode('utf-8')
+for place in places.get_store().search(search_text):
list_store.append([place.uri, place.title])
self._search_view.set_model(list_store)
--
1.7.10
___
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, could someone point me to the kernel fix, which could solve the problem by backporting. That should be an interesting exercise. Regards, Ajay On Wed, May 2, 2012 at 8:44 PM, Anish Mangal an...@activitycentral.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/2012 07:59 PM, Martin Langhoff wrote: On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote: Good News. I managed to get this working (albeit via changes in sugar). The details are at :: http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 The patch seems fairly wrong to me. You are hiding the mesh icons in sugar, but the mesh is active. Packet forwarding is still happening. One of the top reasons we stopped using mesh is because it saturates the RF spectrum, which is a bad thing to do when you have many users in a small space (ie: in a school). You had the mesh disable trick working on F11, and (I assume) happy users of that feature. With this, the feature is broken, but you're making the UI look right... I agree. The *problem* we are trying to solve is not to have a pretty mesh-icon-free-UI (which is a side effect), but disable the mesh at a hardware level. This patch *won't* solve the problem, as it will still flood the air with packet forwarding. - From the discussion, it seems to me that the kernel level switch is present in 12.x.x onwards, but not so for 11.3.x. In 10.3.x(f11) we got lucky as we were able to avoid the race condition. I suggest we keep looking for a proper solution: * Can the kernel fix be backported (might require a lot of work) * Can we tinker with the udev, postresume scripts to have it 'just' working I have reverted the commit: http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0 cheers, m - -- Anish -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPoU9PAAoJEBoxUdDHDZVp+DAH/j/RUl6AarwSlz0oUGIuPa5b FxpFOwO6edA0Avd4Zv0/0x3FWlaAEHwkkyz6Vcsq3Px0lxecX0JgYrEgaXWJP4l0 YRBqROOBCzkVKxk7dEWZ003igZSGKbSmuRMlj4v4Qpv0yU9Tfi/GS3T1Q+r02B0o igF9XjmLT5lFcZ4U1e7vE/foU4f7Y5ugg/TON6u/Oh0GNF8bDdOSkY/xKhGlAkIf 72d1pSt03ypcQgUHy7mRhORj1rc1d1YCWiyZLv2iUXdR2OyR8qjukw2HjQ2Gu5ts DwTeumIy+QSF7fDIZkE83dErrmLJLUGvQ/4oqT50zhgI63o+/v8qBpa40XRo3bc= =KMS0 -END PGP SIGNATURE- ___ 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 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH v2 Browse] Fix for the MIME type handling of a request SL #3512
We were not returning the right value, the callback
should return True if the signal is handled, False otherwise.
This fixes http://bugs.sugarlabs.org/ticket/3512
-
v1 - v2: fixed regression with PDF handling.
Signed-off-by: Manuel Quiñones ma...@laptop.org
---
browser.py | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/browser.py b/browser.py
index c0bb7bc..a40cc03 100644
--- a/browser.py
+++ b/browser.py
@@ -532,14 +532,15 @@ class Browser(WebKit.WebView):
def __mime_type_policy_cb(self, webview, frame, request, mimetype,
policy_decision):
+Handle downloads and PDF files.
if mimetype == 'application/pdf':
self.emit('open-pdf', request.get_uri())
-return False
-elif self.can_show_mime_type(mimetype):
-return True
-else:
+
+elif not self.can_show_mime_type(mimetype):
policy_decision.download()
-return True
+return True
+
+return False
def __new_window_policy_cb(self, webview, webframe, request,
navigation_action, policy_decision):
--
1.7.7.6
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Use UNICODE string to search into places SL #2830
Hi humitos,
2012/5/2 Manuel Kaufmann humi...@gmail.com:
Decode (using 'utf-8') the string inserted by the user in the URL address bar
to search with SQLite into places' database.
Signed-off-by: Manuel Kaufmann humi...@gmail.com
---
webtoolbar.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/webtoolbar.py b/webtoolbar.py
index d0f2dc9..c595206 100644
--- a/webtoolbar.py
+++ b/webtoolbar.py
@@ -120,7 +120,8 @@ class WebEntry(iconentry.IconEntry):
def _search_update(self):
list_store = Gtk.ListStore(str, str)
- for place in places.get_store().search(self.props.text):
+ search_text = self.props.text.decode('utf-8')
+ for place in places.get_store().search(search_text):
list_store.append([place.uri, place.title])
self._search_view.set_model(list_store)
--
1.7.10
Works for me in my dev machine and in the XO. Are we safe to assume
that the text in GtkEntry is utf-8 ?
--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Use UNICODE string to search into places SL #2830
On Wed, May 2, 2012 at 1:24 PM, Manuel Quiñones ma...@laptop.org wrote: Works for me in my dev machine and in the XO. Are we safe to assume that the text in GtkEntry is utf-8 ? I don't know. I'm really new on this :) , but it depends on the codification that we are using with sugar. I guess there is a default value set by sugar to gtk. Maybe another guy with more experience can confirm this. -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ Porfolio: http://fotos.mkaufmann.com.ar/ PyAr: http://www.python.com.ar/ ___ 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
Another comment from the unwashed: Years back, I used only ethernet to connect my XOs. Nowadays, I'm using both wired and wireless to connect between XOs. [By the way, I normally run my XOs with suspend disabled - so I have not paid much attention to problems associated with 'resume'.] For about the last year, Network Manager has become super bossy: It used to be that if I had an XO on ethernet, Network Manager might intervene after some 10+ hours - breaking that ethernet connection. I did not mind occasionally having to reconnect the ethernet (I just invoke a script that re-issues the necessary commands). But the current Network Manager intervenes in less than ten SECONDS - it breaks the connection on the ethernet (eth1) interface - presumably to set up the wireless (eth0) interface (to listen for radio signals). Bottom line - these days, in order to use ethernet on an XO, I need to __disable__ Network Manager. mikus ___ 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
Martin, just out of curiosity .. a logical query comes to my mind. Why, and to whom, are packets forwarded, even though no user has joined any channel? Please do not take this as arrogance; I just wish to clear up some logical mind-blocks :D More importantly, this would clear up some of my networking concepts as well :D Thanks in advance for being my teacher :D Thanks and Regards, Ajay On Wed, May 2, 2012 at 9:27 PM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Use UNICODE string to search into places SL #2830
On Wed, May 2, 2012 at 10:24 AM, Manuel Quiñones ma...@laptop.org wrote: Works for me in my dev machine and in the XO. Are we safe to assume that the text in GtkEntry is utf-8 ? All strings in GTK+ are in UTF-8. However, python tends to work in UTF16. I am surprised that it is not automatically converted to UTF16 by pygobject. What is the data type of self.props.text? Can you do self.get_text()? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Use UNICODE string to search into places SL #2830
On Wed, May 2, 2012 at 2:01 PM, Daniel Drake d...@laptop.org wrote: On Wed, May 2, 2012 at 10:24 AM, Manuel Quiñones ma...@laptop.org wrote: Works for me in my dev machine and in the XO. Are we safe to assume that the text in GtkEntry is utf-8 ? All strings in GTK+ are in UTF-8. However, python tends to work in UTF16. FWIW, all of our PO files are UTF-8 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
martin wrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder did the rest. this implements a new libertas_disablemesh module parameter which should keep mesh from being enabled. please test: http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- 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 test this, and get back to you once done. Thanks a ton Regards, Ajay On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder did the rest. this implements a new libertas_disablemesh module parameter which should keep mesh from being enabled. please test: http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] I know America 4
Hi! After months of changes, this new version comes out.The changes are not visible because the change is within.Changed all .txt with information from each country in .pyThis should improve performance a bit, but I did not try.But this allows for the use gettext strings with allthe names of countries, departments, cities, etc.. With this system,can easily translate the activity into different languages.Nowadays it is in pootle and is being translated into several languages.This version supports English, Spanish and Simplified Chinese! Something important: any error (or suggestion) that are, pleasesend them! It is the way to improve the activity, I test theactivity, but it always happens some detail. Well, it only remains to try it. http://activities.sugarlabs.org/en-US/sugar/addon/4464 Regards! Alan ___ 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. One generic query (not necessarily related to NM crash during resume-upon-suspend) :: I cannot seem to find any grub.conf on my XO-1, wherein I could add the kernel boot parameter. So, does XO-1 have any alternative to grub.conf ? Regards, Ajay On Thu, May 3, 2012 at 2:24 AM, Ajay Garg ajaygargn...@gmail.com wrote: Thanks Paul. I will test this, and get back to you once done. Thanks a ton Regards, Ajay On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder did the rest. this implements a new libertas_disablemesh module parameter which should keep mesh from being enabled. please test: http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- 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
ajay wrote: Hi all. One generic query (not necessarily related to NM crash during resume-upon-suspend) :: I cannot seem to find any grub.conf on my XO-1, wherein I could add the kernel boot parameter. So, does XO-1 have any alternative to grub.conf ? look at olpc.fth. in /bootpart/boot/olpc.fth. if this is for libertas_disablemesh, i'd suggest adding that in modprobe.conf (or whatever the right file is under modprobe*/* these days). paul Regards, Ajay On Thu, May 3, 2012 at 2:24 AM, Ajay Garg ajaygargn...@gmail.com wrote: Thanks Paul. I will test this, and get back to you once done. Thanks a ton Regards, Ajay On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder did the rest. this implements a new libertas_disablemesh module parameter which should keep mesh from being enabled. please test: http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde 819f.i586.rpm paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- 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
Paul, here are the test results :: == USE-CASE 1 == a) Created file '/etc/modprobe.d/libertas.conf'. b) Ensured that '/etc/modprobe.d/libertas.conf' contained only the following line :: options libertas libertas_disablemesh=1 c) Ensured that there is no echo 0 /sys/class/net/eth0/lbs_mesh script, anywhere on the XO-1. This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'. d) Rebooted. e) Wifi icons were visible in Neighborhood-View, but no mesh-icons were visible. f) Upon resume-from-suspend, wifi icons were visible in Neighborhood-View, but no mesh-icons were visible. g) Observations e) and f) were observed, _every single time_. = == USE-CASE 2 == a) Created file '/etc/modprobe.d/libertas.conf'. b) Ensured that '/etc/modprobe.d/libertas.conf' contained only the following line :: options libertas libertas_disablemesh=0 c) Ensured that there is no echo 0 /sys/class/net/eth0/lbs_mesh script, anywhere on the XO-1. This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'. d) Rebooted. e) Wifi icons, and mesh-icons were visible in Neighborhood-View. f) Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW. g) Observations e) and f) were observed, _every single time_. = == USE-CASE 3 == a) Ensured that there was no such file, that contained the following line :: options libertas libertas_disablemesh b) Ensured that there is no echo 0 /sys/class/net/eth0/lbs_mesh script, anywhere on the XO-1. This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'. c) Rebooted. d) Wifi icons, and mesh-icons were visible in Neighborhood-View. e) Upon resume-from-suspend, wifi-icons and mesh-icons were visible in Neighborhood-View. f) Observations d) and e) were observed, _every single time_. == SUMMARY== Barring use-case 2 (which looks a bit odd), use-cases 1 and 3 worked perfectly as expected. Thanks Paul for your prompt effort in generating the new kernel, with the patch. Thanks again. == JUST ONE LAST QUERY == Is the disable-mesh-patch the only difference between the following :: kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586 (kernel generated by you) kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586 (original kernel present on XO-1) Thanks again. The issue stands resolved :) The new kernel could be deployed, provided the answer to the (last, only) query is a yes. :) Regards, Ajay On Thu, May 3, 2012 at 2:21 AM, Paul Fox p...@laptop.org wrote: martin wrote: On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote: I believe that the number of packets being forwarded in this, would be (much) less than in the scenario when the users are actually connected to a mesh-network-channel. Kindly affirm/reject my above notion :) I am a very pragmatic man, I would not waste your time if it was a maybe. There is no much less packet forwarding. You get 100% packet forwarding. And as Sam points out, the UI part of it can be set already with a gconf setting, via OOB. Unfortunatley, I have to agree with Anish's revert :-( Don't have the kernel patch info. Maybe look in git for changes in the libertas driver. It's a pretty low traffic driver, so you'll find it quick. i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder did the rest. this implements a new libertas_disablemesh module parameter which should keep mesh from being enabled. please test: http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
