Re: [Sugar-devel] [ASLO] Release Pippy-48
On Thu, Jun 14, 2012 at 10:41 PM, Sugar Labs Activities < activit...@sugarlabs.org> wrote: > Activity Homepage: > http://activities.sugarlabs.org/addon/4041 > > Sugar Platform: > 0.82 - 0.96 > > Download Now: > http://activities.sugarlabs.org/downloads/file/28116/pippy-48.xo > > Release notes: > > * Adding tooltips to gettext in order to fix SL#3698 (pippy has translation issues) based on "Chris Leonard" , suggestion. == Sources == http://download.sugarlabs.org/sources/sucrose/fructose/Pippy/Pippy-48.tar.bz2 > > > Sugar Labs Activities > http://activities.sugarlabs.org > > ___ > 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
[Sugar-devel] [ASLO] Release Pippy-48
Activity Homepage: http://activities.sugarlabs.org/addon/4041 Sugar Platform: 0.82 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/28116/pippy-48.xo Release notes: Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introducing sugar-build
On Thu, 2012-06-14 at 12:06 +0200, Daniel Narvaez wrote: > * I think these tools are used by few people because they don't work > well. I know despite having a lot of experience with GNOME and linux > builds I was highly frustrated by sugar-jhbuild complexity and > unreliability. I'm sure a lot of people have been in that situation > and gave up. This is not to pick on sugar-jhbuild, as I said in > rationale it's a very difficult issue to solve. Mine is another > try.and I agree with who said competition is good here. This is also my experience, and I saw several developers at deployments who were struggling to build Sugar from source in jhbuild. I used to believe jhbuild could be improved in incremental steps, by shaving off dependencies and removing complexity here and there, but after several years it's still very fragile. The hardest issue seems to be finding consensus among the developers on one of the solutions. My preference would be towards merging all the glucose modules into a single repository that could be built with the familiar sequence of commands "configure && make && make install". This is basically what sugar-core [1] already did 2 years ago. It was created by Marco Pesenti Gritti based upon an earlier proposal of Michael Stone [2]. Both of them had had enough of fighting jhbuild and wanted something simple and clean by merging the repositories. Michael's proposal was more radical because it also replaced the autoconf build system with a hand-made configure script and a hand-made Makefile, both very short. I'm not sure I'd go that far, but it was a tempting idea. [1] http://sugar.marcopg.org/intro.html#build-from-source-code [2] http://dev.laptop.org/git/users/mstone/sugar/ > * Maintenance of these tools has an high cost but losing talented > contributors because they are unable to get the thing to build is a > much much higher one. Also, many of the design choices in sugar-build > intends to reduce maintenance cost (which I think in turn will favor > reliability). I couldn't agree more on your motives, but I think that jhbuild simply deserves to die. Wrapping it with something easier to use can be a temporary solution, but it can't eliminate all the underlaying complexity of repeated network operations to fetch code from disparate repositories. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introducing sugar-build
On Thu, Jun 14, 2012 at 10:11:15PM +0200, Daniel Narvaez wrote: > [...] > git pull (to pull the new bug reporting stuff I pushed) > [...] > make bug-report > > That will generate a tarball with logs, if you send it to me I'll > take a look at what is going on. Now that's service! Well done. -- 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] [IAEP] Sugar as a Mac Ap?
On 13.06.2012 17:30, Frederick Grose wrote: > On Wed, Jun 13, 2012 at 4:27 AM, Peter Robinson wrote: > >> On Wed, Jun 13, 2012 at 8:52 AM, Bert Freudenberg wrote: >> > On 2012-06-13, at 07:50, Steven Thompson wrote: >> > >> >> Even just in English in Japan could help kids. The common denomenator for jhs and hs kids is an iPhone or android and the iPad at home...much more so than buying an Intel Classmate or having a hope of getting an XO. >> > >> > Sugar can be installed on any PC, not just Classmates or XOs. >> > >> >> It's not about price or energy requirements here, its about good education for kids. You've always been able to plug SoaS into x86 Macs and have it work >> ... >> is quite conceivable once the Sugar port to GTK3 is >> complete, of course like everything it needs someone to step up and do >> the work. >> >> Peter > > In the spirit of exploring interesting concepts that might stimulate new development, might someone explain the obstacles that prevent Sugar from running on an iPad, as well, discuss potential approaches to overcome those obstacles. > For example, Etoys, an independent but significant component in Sugar, can be run on an iPad since June 2010, > http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html [3] > http://etoys.squeak.org/experimental/ipad/ [4] > Also with time, the current crop of iPads will become secondary devices as newer tablets are released. Folks will then be more willing to void warranties and experiment with the operating systems. > --Fred I have been dreaming of buying a £100 tablet, for installing Sugar, like this in local Maplin store, http://www.maplin.co.uk/arnova-8-g3-8in-touch-tablet-android-4.0-630087 It has: ARM A8 Cortex(tm) 1GHz processor, capacitive multi-touch screen, 1GB RAM, front camera, Android 4.0, so am thinking it would be a fine candidate for Fedora-arm / Sugar. I have not seen it discussed, has it been done already? Iain Links: -- [1] mailto:b...@freudenbergs.de [2] mailto:pbrobin...@gmail.com [3] http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html [4] http://etoys.squeak.org/experimental/ipad/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introducing sugar-build
Hi Manuel, thanks for your spiritual support :) I tested on Fedora 17 32-bit and it worked for me. I'd appreciate if you could: git pull (to pull the new bug reporting stuff I pushed) make clean make build ... look at it failing ... make bug-report That will generate a tarball with logs, if you send it to me I'll take a look at what is going on. Thanks, Daniel On 14 June 2012 13:18, Manuel Kaufmann wrote: > On Thu, Jun 14, 2012 at 7:17 AM, Daniel Narvaez > wrote: > > I want to support both 32 and 64 and it might already work. I haven't > tested > > with 32 yet honestly though, I will do that today. > > Cool! I tried a lot and I couldn't build it. It would be great if you > reach this goal! > > I didn't take a look at your code, but I'm happy with your initiative. > I don't think that I could collaborate on the process because I don't > have enough time, but this (sugar-build) was the first thing that I > tried to do when I started with OLPC. I agree with you about the "try > to open the door to new developers" (if you search on the mailing list > archive I sent some emails about this). > > Besides, I don't have the knowledge that you do have about packaging > and distribution. That's a BIG point for you! I don't support you with > code, but at least spiritually :) > > See you there and... > > ... work all day long, day and night, come on! :P > > -- > 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
[Sugar-devel] [ASLO] Release Jukebox-26
Activity Homepage: http://activities.sugarlabs.org/addon/4045 Sugar Platform: 0.84 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/28115/jukebox-26.xo Release notes: Add a "Remove" button SL #3357 (Manuel Kaufmann) setup.py: Remove the bundle name from bundlebuild start method (Simon Schampijer) Fix playlist behaviour SL #3661 (Manuel Quiñones) If you can help to test this version, is appreciated. Please read comments in ticket SL #3661. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] sugar-session: disable Metacity mouse button modifiers (OLPC#11781)
On 06/14/2012 06:21 PM, Peter Robinson wrote: On Thu, Jun 14, 2012 at 5:10 PM, Simon Schampijer wrote: On 06/07/2012 05:28 PM, Daniel Drake wrote: Metacity provides "mouse button modifier" functionality which lets you drag activity windows around the screen, amongst other things. This is something we want to disable, similar to how we disable metacity's key bindings. In recent metacity releases, Alt is the default mouse button modifier. We especially want to disable this functionality in this case because Sugar uses Alt for other things, such as launching a new activity instance (rather than a journal entry) from the home screen. Signed-off-by: Daniel Drake Hi Daniel, thanks for the patch. As far as I understood it depends on a fix in metacity in order to work, your patch does log a warning if the 'metacity-message' option is not available, so no harm in landing it. However this should be noted in the commit message. Patched metacity is incoming shortly. Peter Great, thanks Peter! I can test then as well the "this should be fixed now" case, so far I only tested the new 'metacity-message' command not available one successfully. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] sugar-session: disable Metacity mouse button modifiers (OLPC#11781)
On Thu, Jun 14, 2012 at 5:10 PM, Simon Schampijer wrote: > On 06/07/2012 05:28 PM, Daniel Drake wrote: >> >> Metacity provides "mouse button modifier" functionality which lets >> you drag activity windows around the screen, amongst other things. >> This is something we want to disable, similar to how we disable >> metacity's key bindings. >> >> In recent metacity releases, Alt is the default mouse button modifier. >> We especially want to disable this functionality in this case because >> Sugar uses Alt for other things, such as launching a new activity >> instance (rather than a journal entry) from the home screen. >> >> Signed-off-by: Daniel Drake > > > Hi Daniel, > > thanks for the patch. As far as I understood it depends on a fix in metacity > in order to work, your patch does log a warning if the 'metacity-message' > option is not available, so no harm in landing it. However this should be > noted in the commit message. Patched metacity is incoming shortly. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] sugar-session: disable Metacity mouse button modifiers (OLPC#11781)
On 06/07/2012 05:28 PM, Daniel Drake wrote: Metacity provides "mouse button modifier" functionality which lets you drag activity windows around the screen, amongst other things. This is something we want to disable, similar to how we disable metacity's key bindings. In recent metacity releases, Alt is the default mouse button modifier. We especially want to disable this functionality in this case because Sugar uses Alt for other things, such as launching a new activity instance (rather than a journal entry) from the home screen. Signed-off-by: Daniel Drake Hi Daniel, thanks for the patch. As far as I understood it depends on a fix in metacity in order to work, your patch does log a warning if the 'metacity-message' option is not available, so no harm in landing it. However this should be noted in the commit message. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Branching Glucose modules
Hi, I just branched the various Glucose modules. The 'sucrose-0.96' branch will be used for stable releases and the master branch to continue further development. Bug fixes will be cherry-picked from the master branches to the stable branches. * sugar * sugar-toolkit-gtk3 * sugar-artwork * sugar-datastore The branches for pootle should be created accordingly. Please don't do any mass pushes to the stable branches for localization anymore. Only if a translation coordinator feels confident about making their translations available they should be present on the stable branches. The following modules have not been branched due to deprecation: * sugar-toolkit (will be replaced by sugar-toolkit-gtk3 and therefore only see bugfixes) * sugar-base (moved inside sugar-toolkit-gtk3) * sugar-presence-service (has been deprecated for a long time already) Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Restore journal file picker (#3411)
2012/6/14 Daniel Drake : > On Wed, Jun 13, 2012 at 10:09 PM, Manuel Quiñones wrote: >> Thanks Daniel, this patch works for me in olpc build os13 installing >> the webkitgtk test rpm [1]. Seems that you are close in landing the >> patch upstream [2]. >> >> [1] http://dev.laptop.org/~dsd/20120604/ >> [2] https://bugs.webkit.org/show_bug.cgi?id=87283#c23 >> >> Patch looks good for me, just two comments below, no issues. I'm >> happy to apply it. > > Thanks. Please apply it, with any small tweaks you'd like to make. Sure, as soon as Simon gives his ACK. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Restore journal file picker (#3411)
On Wed, Jun 13, 2012 at 10:09 PM, Manuel Quiñones wrote: > Thanks Daniel, this patch works for me in olpc build os13 installing > the webkitgtk test rpm [1]. Seems that you are close in landing the > patch upstream [2]. > > [1] http://dev.laptop.org/~dsd/20120604/ > [2] https://bugs.webkit.org/show_bug.cgi?id=87283#c23 > > Patch looks good for me, just two comments below, no issues. I'm > happy to apply it. Thanks. Please apply it, with any small tweaks you'd like to make. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar as a Mac Ap?
On 2012-06-14, at 12:54, Peter Robinson wrote: > On Wed, Jun 13, 2012 at 5:42 PM, Walter Bender > wrote: >> >> So the question is: is there a Linux/Gnome VM for the iPad? iPhone? >> iWhatever? > > No because Apply explicitly doesn't allow other languages so we can't > run python which means we need some form of python -> objective-C > compiler or similar to be able to run it on those sort of devices. Not true. Not since 2010 anyway. You can now code iOS apps in any language you want. There are apps in the Apple App Store written in Squeak, and Lua, and I guess many other languages. E.g. here is a Python environment: http://itunes.apple.com/us/app/python-for-ios/id485729872?mt=8 There are of course other reasons why you wouldn't get Sugar into the app store (see e.g. my message from yesterday). But the programming language is no problem. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introducing sugar-build
On Thu, Jun 14, 2012 at 7:17 AM, Daniel Narvaez wrote: > I want to support both 32 and 64 and it might already work. I haven't tested > with 32 yet honestly though, I will do that today. Cool! I tried a lot and I couldn't build it. It would be great if you reach this goal! I didn't take a look at your code, but I'm happy with your initiative. I don't think that I could collaborate on the process because I don't have enough time, but this (sugar-build) was the first thing that I tried to do when I started with OLPC. I agree with you about the "try to open the door to new developers" (if you search on the mailing list archive I sent some emails about this). Besides, I don't have the knowledge that you do have about packaging and distribution. That's a BIG point for you! I don't support you with code, but at least spiritually :) See you there and... ... work all day long, day and night, come on! :P -- 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] [IAEP] Sugar as a Mac Ap?
On Wed, Jun 13, 2012 at 5:42 PM, Walter Bender wrote: > On Wed, Jun 13, 2012 at 12:30 PM, Frederick Grose wrote: >> On Wed, Jun 13, 2012 at 4:27 AM, Peter Robinson >> wrote: >>> >>> On Wed, Jun 13, 2012 at 8:52 AM, Bert Freudenberg >>> wrote: >>> > On 2012-06-13, at 07:50, Steven Thompson wrote: >>> > >>> >> Even just in English in Japan could help kids. The common denomenator >>> >> for jhs and hs kids is an iPhone or android and the iPad at home...much >>> >> more >>> >> so than buying an Intel Classmate or having a hope of getting an XO. >>> > >>> > Sugar can be installed on any PC, not just Classmates or XOs. >>> > >>> >> It's not about price or energy requirements here, its about good >>> >> education for kids. >>> >> >>> >> Can we get sugar as a Mac Ap at the Ap Store? >>> > >>> > I think Sugar-on-a-Stick (SoaS) can be plugged into recent Macs and >>> > works. >>> >>> You've always been able to plug SoaS into x86 Macs and have it work >>> (just like any Linux distro), the latest version adds much better >>> support for it and there's been specific interest in making it work >>> properly with uEFI and all the Mac quirks. >>> >>> It's quite easy to use SoaS on a usb key on Macs and with something >>> like VirtualBox you can run Sugar in a Window on Mac without too many >>> issues. >>> >>> Sugar as an App on Mac is an interesting concept and with improving >>> Mac support within GTK3 something like the Sugar in a Window concept >>> we use for testing is quite conceivable once the Sugar port to GTK3 is >>> complete, of course like everything it needs someone to step up and do >>> the work. >>> >>> Peter >> >> >> In the spirit of exploring interesting concepts that might stimulate new >> development, might someone explain the obstacles that prevent Sugar from >> running on an iPad, as well, discuss potential approaches to overcome those >> obstacles. >> >> For example, Etoys, an independent but significant component in Sugar, can >> be run on an iPad since June 2010, >> http://croquetweak.blogspot.com/2010/06/squeak-etoys-on-ipad.html >> http://etoys.squeak.org/experimental/ipad/ >> >> Also with time, the current crop of iPads will become secondary devices as >> newer tablets are released. Folks will then be more willing to >> void warranties and experiment with the operating systems. >> >> --Fred >> > Etoys runs in a virtual machine. Once that VM is ported to a new > environment, Etoys will run. > Sugar on the other hand is a desktop and collection of applications > that require Linux and the Gnome toolkit (among other dependencies). > Once a Linux VM with Gnome is running in an environment, the process > of porting Sugar is *relatively* painless. > > So the question is: is there a Linux/Gnome VM for the iPad? iPhone? iWhatever? No because Apply explicitly doesn't allow other languages so we can't run python which means we need some form of python -> objective-C compiler or similar to be able to run it on those sort of devices. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introducing sugar-build
Hi Manuel, I want to support both 32 and 64 and it might already work. I haven't tested with 32 yet honestly though, I will do that today. Then I will clarify in the README. This also reminds me that we woud better have buildbots for both arches. Thanks! Daniel On 14 June 2012 04:56, Manuel Kaufmann wrote: > On Wed, Jun 13, 2012 at 7:45 PM, Daniel Narvaez > wrote: > > == Fedora 17 == > > > > Works out of the box! > > Some questions :) > > What version of Fedora 17? > 32 or 64 bits? > Could you make it work on Fedora 17 32 bits? > > -- > 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] Introducing sugar-build
Hi Gonzalo, thanks a lot for your feedback. To answer your general point: * I think these tools are used by few people because they don't work well. I know despite having a lot of experience with GNOME and linux builds I was highly frustrated by sugar-jhbuild complexity and unreliability. I'm sure a lot of people have been in that situation and gave up. This is not to pick on sugar-jhbuild, as I said in rationale it's a very difficult issue to solve. Mine is another try.and I agree with who said competition is good here. * Maintenance of these tools has an high cost but losing talented contributors because they are unable to get the thing to build is a much much higher one. Also, many of the design choices in sugar-build intends to reduce maintenance cost (which I think in turn will favor reliability). Why I didn't just contribute to sweets? My understanding is that sweets has a very different goal. It's a distribution tool, not a development one. It's probably useful for activities development, in the same way of distributions packages. But that's not what I'm interested in. I want to make it possible for more people to hack on the sugar core modules. Why I didn't just contribute to sugar-jhbuild? Let me answer by describing the very few code sugar-build is composed of. Makefile (32 lines) This is what exposes the minimal set of commands we provide. I think it's a simpler interface compared to jhbuild and will also allow us to use a different set of scripts under the hoods if we want (my dream is to be able to build only sugar-* stuff in the future and we could just use submodules if that ever happens). There is nothing like that in sugar-jhbuild. scripts/check-system (181 lines, expected to grow a lot) I wanted checks to be cross platform. It's a good start to have those if you want to add support for another distro. You just need to add mappings to the distro specific packages which is tedious but easy. And it's easier to maintain because whenever you add a dependency you just need to make sure there is a package for every supported distributions in a single aggregated file, rater than having to go through a bunch of xml files. Also I'd like to reuse the script to check if sugar distributions are compliant, in the sense they provide all the dependencies activities are allowed to depend. This is probably the only high maintenance cost part of sugar-build, the most use we make of it the better. Again nothing like this in sugar-jhbuild. scripts/build-activity (8 lines) sugar-jhbuild uses a custom jhbuild module for this purpouse. I'm just building a couple of activities (for the reasons I explained in the rationale) and i didn't think it was worth to maintain an out-of-tree jhbuild module for this. We could add the module to jhbuild in the future though, if the GNOME maintainers would take it. scripts/sugar.modules (46 lines) scripts/system.modules (27 lines) Somewhat duplicated with sugar-jhbuild but the logic is different. We assume a certain base system and only specific the minimal number of absolutely required modules. We don't try to list a complete list of dependencies and then skip the ones that are not required on a certain distribution. So I could have started from sugar-jhbuild but, to achieve my goals, I would have had to basically to delete most of it and replace with new code. The only sizable piece of code they share is jhbuild and that's something we just pull as is. Daniel On 14 June 2012 03:50, Gonzalo Odiard wrote: > From one side, it's great to have more people interested in the build > tools, thanks! > But is really bad start again with another solution (sugar-jhbuild, > sweets, sugar-build...), > this tools are not used by too much people, then the cost of maintain it, > is very high. > If you are working in a solution based in sugar-jhbuild, please try to > identify > how can be improved the actual situation (I know is not very good) > and try to work with the people already involved. > > Gonzalo > > > On Wed, Jun 13, 2012 at 7:45 PM, Daniel Narvaez wrote: > >> Hello, >> >> I'm trying to figure out how to make building sugar from source easier >> and more reliable. I wrote a new set of build scripts that I'm hoping will >> improve the situation. They are not too dissimilar from sugar-jhbuild but >> there a few key differences. >> >> The code is here: >> https://github.com/dnarvaez/sugar-build >> >> I'm pasting the README which explains the rationale and how the thing >> works in practice. >> >> Daniel >> >> >> = Setup a supported distribution = >> >> For all the distributions your user need admin rights (i.e. it should be >> able to run the su command). >> >> == Fedora 17 == >> >> Works out of the box! >> >> == Ubuntu 12.04 == >> >> By default only root can start the X server. You need to change that with >> >> sudo dpkg-reconfigure x11-common >> >> I'm hoping we can get rid of this step in the next Ubuntu version when a >> working nested X server implementatio
Re: [Sugar-devel] Passphrase must be re-entered when XO loses then regains wifi connection
On Thu, 2012-06-14 at 18:44 +1000, James Cameron wrote: > Sridhar begins in the bug report by saying that the repeated prompt > for the WPA passphrase is due to losing connection. Is there other > evidence, other than the repeated passphrase prompt, to suggest that a > connection was lost? If so, what connection is it that is lost? > > When I last looked at this problem, Sugar was being asked by Network > Manager for the passphrase, and Sugar was immediately prompting the > user. > I faked the loss of connection by powering down the AP until the loss was recorded by NM in /var/log/messages and powering the AP back up. Sugar did prompt for the passphrase, which is already recorded in ~/.sugar/default/nm/connections.cfg, so sugar is not re-reading its config file before prompting the user for input. If you were to cancel the dialog box for the passphrase and reselect the AP you are NOT prompted for the passphrase and the connection is re-established. I'll post /var/log/messages|wpa_supplicant.log from this test in the issue. > Offhand I don't know what version of Sugar you are planning to ship > with your target version for 12.2, so I didn't bother digging into the > Sugar network model and view code for your version. > Dextrose 3, based on sugar 0.94. > But master in git has a SecretAgent in model/network.py that registers > itself with NetworkManager as an agent that can provide passphrases to > NetworkManager. The SecretAgent does not cache the passphrase, but > instead delegates to __secrets_request_cb and WPAKeyDialog which then > prompts the user. > I think WPAKeyDialog should check if a secret is already recorded in connections.cfg for the AP in question before prompting the user. > Perhaps the GNOME equivalent does cache? I don't know. It is worth a > test, don't you think? Look at how they do it. > > The problem with caching is that if the passphrase changes, the agent > would somehow have to recognise that the passphrase it had was no > longer valid. I seem to recall work that was done in that area within > the last few years, possibly relating to inability to connect to an > access point after the passphrase had been changed. > Think "Discard network history" in network-control-panel would be needed to be used to erase the old passphrase, forcing a prompt to the user for new input. > It may be wasteful to speculate further. You need to determine from > logs what components (NetworkManager, Sugar, driver, firmware) are > causing the symptom. If you don't have good logs, work to get them. > Jerry ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Passphrase must be re-entered when XO loses then regains wifi connection
Sridhar begins in the bug report by saying that the repeated prompt for the WPA passphrase is due to losing connection. Is there other evidence, other than the repeated passphrase prompt, to suggest that a connection was lost? If so, what connection is it that is lost? When I last looked at this problem, Sugar was being asked by Network Manager for the passphrase, and Sugar was immediately prompting the user. Offhand I don't know what version of Sugar you are planning to ship with your target version for 12.2, so I didn't bother digging into the Sugar network model and view code for your version. But master in git has a SecretAgent in model/network.py that registers itself with NetworkManager as an agent that can provide passphrases to NetworkManager. The SecretAgent does not cache the passphrase, but instead delegates to __secrets_request_cb and WPAKeyDialog which then prompts the user. Perhaps the GNOME equivalent does cache? I don't know. It is worth a test, don't you think? Look at how they do it. The problem with caching is that if the passphrase changes, the agent would somehow have to recognise that the passphrase it had was no longer valid. I seem to recall work that was done in that area within the last few years, possibly relating to inability to connect to an access point after the passphrase had been changed. It may be wasteful to speculate further. You need to determine from logs what components (NetworkManager, Sugar, driver, firmware) are causing the symptom. If you don't have good logs, work to get them. -- 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] Passphrase must be re-entered when XO loses then regains wifi connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The issue of sugar prompting users to enter wifi passphrase after a connection is broken and is re-established[1] has been in Sugar/OLPC for some time. The purpose of this email is to understand the causes of this: * Bad wireless access point * Proximity to a wireless access point * Something not working properly on the XO laptop ** Driver? ** Firmware? ** Something sugar specific? Talking with deployments, this is an annoying little bugger, because everytime it happens, the teacher has to run over to the kid's laptop and enter the passphrase. We are getting some reports that this flakey *might* be happening more often with dx3 (and following from that 11.3.x) builds. Therefore I'd like to understand the causes of this and what can be done to address it (at various levels: XO, Sugar, Wireless Access Points) [1] https://dev.laptop.org.au/issues/1305 Cheers, Anish Anish Mangal Dextrose Project Manager ActivityCentral -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2Zt4AAoJEBoxUdDHDZVp5ugH/jSa5xeuWmrRaCMC9EqNhm+k /VPdmtYL/qrxQpboiaOiC0Uo4T13ug6xRfFdoUYAo7vOwnjP9RVHuCKeMgfOO/ML EbgNaR4vkuZmO5ruP8vIBSyD6uq59nbiuM12pLOo9RmbGIrTDV2AvWt1Hfy3Y+vQ haAQ0owpAzYbnWjbJpI5Mxyp+9CgdaFNHGOuHEMeY60JNerirddlFjJxVPI35g5X oHH7zbWx9/wREsXeTpHMfMsp+u5pbn1n2/ig2uO8HDaY9ur6/s3WPWrupD0IdSMm lAZ4QEjbIGVk50kA9oIO09gTDjUN1gWnx+6lasmaIh6wNwlM9ZmdEPy5l6oMRzo= =xd0x -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel