Re: [Sugar-devel] [ASLO] Release Manage homeviews-3
One way to check is to compare the commit id of the pull request against the commit id of the commits leading up to the release. https://github.com/i5o/manage-homeviews/pull/2 gives 05d5d5b https://github.com/i5o/manage-homeviews/commits/master has it. On Tue, Dec 29, 2015 at 03:44:30AM +0200, Tony Anderson wrote: > Does this release incorporate the changes made by GCI participant > Daksh Shah Dec 8th 2015, 20:52 (CAT) at [1]https://github.com/i5o/ > manage-homeviews/pull/2? > > Tony > > On 12/28/2015 10:44 PM, James Cameron wrote: > > On Mon, Dec 28, 2015 at 01:49:27PM -0500, Sugar Labs Activities wrote: > > Sugar Platform: > 0.104 - 0.104 > > What about 0.106? > > References: > > [1] https://github.com/i5o/manage-homeviews/pull/2 > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- James Cameron http://quozl.netrek.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN RFC] Onboarding
I think this is becoming unproductive so let's move on. The important thing is Sam's proposal and its implementation. Two considerations: 1) Make the implementation scriptable as much as possible so that new help scenarios can be easily implemented in the wild. 2) Minimize text - emphasize icons. For example, a standard 'click' icon. This reduces the stress of making translations. Tony On 12/28/2015 10:23 PM, James Cameron wrote: No, ds-backup is not part of Sugar. As I said before, Sugar itself does not use the backup URL. I've checked the Sugar code already. ds-backup (not Sugar) does read the backup URL from GConf schema /desktop/sugar/backup_url (Given Sugar has migrated to GSettings, so too should ds-backup). Sugar developers do not maintain ds-backup, and it is not in the other operating system builds that use Sugar. So it can be ignored unless Sugar developers want to help the school server developers somehow. I don't think anybody here has time for that. On Mon, Dec 28, 2015 at 04:06:26PM +0200, Tony Anderson wrote: Hi, James This thread is growing but each time there is new information. At least as of 0.106, Sugar has the backup URL (see /usr/bin/ds_backup.py and ds_backup.sh). I can't say whether they are being used. The primary flaw in ds_backup.py is that it performs an rsync (with -d). This means if a user deletes a Journal object on the XO, it will be deleted from the backup. Since users often delete Journal objects to free space, this means those items are lost. The strategy I use is to back up Journal objects individually. The 'keep' star is used to control backup and restore. If the user clears the keep, the backup deletes the local document to free space. if the 'keep' star is set, the backup downloads the document. In this way, no student's documents are lost because of storage limitations. When storage is full (the infernal modal dialog you get 'Your Journal is Full'), common practice is to reflash the XO. In this context restoring the Journal simply recreates the original problem. Incremental backup means that the restore only restores the metadata, the documents remain on the school server. The user can request individual documents be downloaded to the XO as needed. The fact that the backup and restore control panel doesn't support a school server doesn't surprise me - it is characteristic of the disconnect I am referring to. Integrating Sugar with the school server causes problems for users (and developers) who do not have one. There are those who feel the goal of OLPC (the concept not the organization) is to provide one laptop per individual child working at home as is typical in the developed world. This allows the comfortable assumption that users have access to the same resources as the developers (continuous broadband internet, for example). However, my involvement and I believe that of many others is to support deployments in the developing world which provide one laptop per child in a community school in the developing world (or developed world) where internet access is rarely possible or is too expensive or too slow. In this environment, the schoolserver provides a means to give the students local access to information from the internet. Where funding is insufficient, more than one child may need to share a laptop. As Walter Bender described it in the Malaysia Summit, 'one laptop per child' means there are enough laptops that each child in the group has their own to use at that time. In such deployments, there is rarely enough funding for extra equipment such as usb keys, external hard drives and so on. It is a design goal to satisfy requirements with the resources available (including the school server and related network support). Since the XO has limited storage, backing up the school server is essential to preserving the documents produced by the users (not just for hardware failure, but more importantly to handle the situation when available storage falls below 50MB). The login at install time is not needed. However, the code could be re-used to provide a standard session login with multiple users sharing a laptop. Tony On 12/28/2015 09:20 AM, James Cameron wrote: Yes, but we're talking about Sugar here, not the XO. Sugar supports more than the XO. Sugar supports a school server using the register feature, which sets a Jabber server and a backup URL. Sugar uses the new Jabber server as a replacement for the default provided by Sugar Labs. Sugar does not use the backup URL. Sugar's backup and restore control panel is for local media only; there is no backend for a school server. Your school server maintainers don't appear to have noticed the disconnect. The move to system packaged activities instead of user directory was not a significant change in our Ubuntu integration. That work was already led by Debian. Similar had been done by Fedora SoaS years before. I've no plans to restore a login to the XO images. This isn't
Re: [Sugar-devel] [ASLO] Release Manage homeviews-3
Does this release incorporate the changes made by GCI participant *Daksh Shah* Dec 8th 2015, 20:52 (CAT) at https://github.com/i5o/manage-homeviews/pull/2? Tony On 12/28/2015 10:44 PM, James Cameron wrote: On Mon, Dec 28, 2015 at 01:49:27PM -0500, Sugar Labs Activities wrote: Sugar Platform: 0.104 - 0.104 What about 0.106? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] display blocker errors in f24 (rawhide) Soas live in koji
Hi Tom, I'm running rawhide now and it looks like a mess due to the huge changes this gtk cycle. I attempted to patch some things [1], and that fixed some issues. However, the changes are simpily massive this release [2]. I think that we are going to need to have gtk3 and gtk3.20 with different css files. I am currently looking into patching this, however, I do find some of the css node issues annoying. Especially issues with css node styles taking importance over the normal SugarXYZ styles. This is further compounded by the fact that the css node api is not public yet, and I don't think it was planned for this release. There will be horrible hacks. Thanks, Sam [1] https://github.com/sugarlabs/sugar-artwork/pull/84 [2] https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ On Tue, Dec 29, 2015 at 11:47 AM, Thomas Gilliard wrote: > Just a heads up: > > I am seeing these display blocker errors in f24 (rawhide) Soas live in > koji [1] > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=12325079 > > *Name creation screen > > https://wiki.sugarlabs.org/go/File:Soas-f24-1.png > > *F3 Main Screen with wrong buttons > > https://wiki.sugarlabs.org/go/File:Soas-f24-2.png > > * sugar control panel with missing text > > https://wiki.sugarlabs.org/go/File:Soas-f24-3.png > > Is this due to gtk3 mismatches? > > Tom Gilliard > satellit > ___ > 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] display blocker errors in f24 (rawhide) Soas live in koji
Just a heads up: I am seeing these display blocker errors in f24 (rawhide) Soas live in koji [1] [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=12325079 *Name creation screen https://wiki.sugarlabs.org/go/File:Soas-f24-1.png *F3 Main Screen with wrong buttons https://wiki.sugarlabs.org/go/File:Soas-f24-2.png * sugar control panel with missing text https://wiki.sugarlabs.org/go/File:Soas-f24-3.png Is this due to gtk3 mismatches? Tom Gilliard satellit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Current status of collaboration work
On Mon, Dec 28, 2015 at 02:37:20PM -0300, Martin Abente wrote: > @Sam: > > • Using GSettings is definitely a decent workaround instead of going for > detection, I checked your PR and I will send some comments, but we will > have to push it for as a feature freeze exception / Bug Fix. > • I don't agree we should add it to the toolkit yet, still too early to set > API on stones, but lets make a good use of that Wrapper of yours. Thanks > for making it available. > • Collaboration should be transparent for Activities, and since Tubes is no > longer available in at least one scenario (jabber), we can't really > depending on it anymore. > > @Tony: > > • As Sam explained, this is not something _we_ control. Telepathy dropped > Tubes years ago. There is no way to "workaround" the fact that Tubes in > gone and we gotta move to something else, but for now we will also keep > Tubes for those who can still use it and at least be able to do the > transition. > > @Gonzalo: > > • Thanks for the feedback, you are right, collaboration is hard to test, so > we can't rush here. > > @James C.: > > • Telepathy developers knew Sugar was using still it, I even heard they > warned us in a GUADEC conference years ago, I also heard they apologized > in > advanced. > • I am against introducing one deprecated piece of Telepathy code into Sugar > code, simply because we can barely catch up with our own code base and it > would be even worse if we adopt that code. > • Aside from that, Walter and Sam tests show that there are many cases where > we can simply migrate other channels. It will take longer, but is the > right > investment IMHO. > • The Tubes issue is just as critical as any other "we can't catch up with > upstream" issue but, this time, we are trying not to ignore it. > • Any comments regarding the use of a GSettings entry to re-enable Tubes > support (and leave it disabled by default)? > • Funny picture. No worries, thanks for taking the decisions. > > @Walter: > > • I agree, lets move forward. > > @Jonas: > > • I hope so too. > > Martin. -- James Cameron http://quozl.netrek.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Manage homeviews-3
On Mon, Dec 28, 2015 at 01:49:27PM -0500, Sugar Labs Activities wrote: > Sugar Platform: > 0.104 - 0.104 What about 0.106? -- James Cameron http://quozl.netrek.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN RFC] Onboarding
No, ds-backup is not part of Sugar. As I said before, Sugar itself does not use the backup URL. I've checked the Sugar code already. ds-backup (not Sugar) does read the backup URL from GConf schema /desktop/sugar/backup_url (Given Sugar has migrated to GSettings, so too should ds-backup). Sugar developers do not maintain ds-backup, and it is not in the other operating system builds that use Sugar. So it can be ignored unless Sugar developers want to help the school server developers somehow. I don't think anybody here has time for that. On Mon, Dec 28, 2015 at 04:06:26PM +0200, Tony Anderson wrote: > Hi, James > > This thread is growing but each time there is new information. > > At least as of 0.106, Sugar has the backup URL (see > /usr/bin/ds_backup.py and ds_backup.sh). I can't say whether they > are being > used. > > The primary flaw in ds_backup.py is that it performs an rsync (with > -d). This means if a user deletes a Journal object on > the XO, it will be deleted from the backup. Since users often delete > Journal objects to free space, this means those items are lost. > > The strategy I use is to back up Journal objects individually. The > 'keep' star is used to control backup and restore. If the user > clears the keep, > the backup deletes the local document to free space. if the 'keep' > star is set, the backup downloads the document. In this way, no > student's documents > are lost because of storage limitations. > > When storage is full (the infernal modal dialog you get 'Your > Journal is Full'), common practice is to reflash the XO. In this > context restoring the Journal simply recreates the original problem. > Incremental backup means that the restore only restores the > metadata, the documents remain on the school server. The user can > request individual documents be downloaded to the XO as needed. > The fact that the backup and restore control panel doesn't support a > school server doesn't surprise me - it is characteristic of the > disconnect I am > referring to. Integrating Sugar with the school server causes > problems for users (and developers) who do not have one. > > There are those who feel the goal of OLPC (the concept not the > organization) is to provide one laptop per individual child working > at home as is > typical in the developed world. This allows the comfortable > assumption that users have access to the same resources as the > developers (continuous broadband internet, for example). > > However, my involvement and I believe that of many others is to > support deployments in the developing world which provide one laptop > per child > in a community school in the developing world (or developed world) > where internet access is rarely possible or is too expensive or too > slow. In this environment, the schoolserver provides a means to give > the students local access to information from the internet. > > Where funding is insufficient, more than one child may need to share > a laptop. As Walter Bender described it in the Malaysia Summit, 'one > laptop per child' means there are enough laptops that each child in > the group has their own to use at that time. > > In such deployments, there is rarely enough funding for extra > equipment such as usb keys, external hard drives and so on. It is a > design goal to > satisfy requirements with the resources available (including the > school server and related network support). Since the XO has > limited storage, backing > up the school server is essential to preserving the documents > produced by the users (not just for hardware failure, but more > importantly to handle the situation when available storage falls > below 50MB). > > The login at install time is not needed. However, the code could be > re-used to provide a standard session login with multiple users > sharing a laptop. > > Tony > > On 12/28/2015 09:20 AM, James Cameron wrote: > >Yes, but we're talking about Sugar here, not the XO. Sugar supports > >more than the XO. > > > >Sugar supports a school server using the register feature, which sets > >a Jabber server and a backup URL. > > > >Sugar uses the new Jabber server as a replacement for the default > >provided by Sugar Labs. > > > >Sugar does not use the backup URL. > > > >Sugar's backup and restore control panel is for local media only; > >there is no backend for a school server. Your school server > >maintainers don't appear to have noticed the disconnect. > > > >The move to system packaged activities instead of user directory was > >not a significant change in our Ubuntu integration. That work was > >already led by Debian. Similar had been done by Fedora SoaS years > >before. > > > >I've no plans to restore a login to the XO images. This isn't > >something that OLPC needs. We'd prefer that each child have a laptop. > > > >On Mon, Dec 28, 2015 at 08:02:27AM +0200, Tony Anderson wrote: > >>Hi, James > >> > >>One of the big problems in our community is the disconnect between > >>the school
[Sugar-devel] Candidacy for Sugar Labs Oversight Board
Greetings! I'm happy to post my candidacy for the Sugar Labs Oversight Board (SLOB). You can find my listing at https://wiki.sugarlabs.org/go/Oversight_Board/2015-2016-candidates and my statement at https://wiki.sugarlabs.org/go/User:Sverma Looking forward to your support and continuing to work with you all for the years to come. cheers, Sameer -- Sameer Verma, Ph.D. Professor, Information Systems San Francisco State University http://verma.sfsu.edu/ http://commons.sfsu.edu/ http://olpcsf.org/ http://olpcjamaica.org.jm/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Manage homeviews-3
Activity Homepage: http://activities.sugarlabs.org/addon/4722 Sugar Platform: 0.104 - 0.104 Download Now: http://activities.sugarlabs.org/downloads/file/29156/manage_homeviews-3.xo Release notes: Added gsettings support 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] Current status of collaboration work
*@Sam:* - Using GSettings is definitely a decent workaround instead of going for detection, I checked your PR and I will send some comments, but we will have to push it for as a feature freeze exception / Bug Fix. - I don't agree we should add it to the toolkit yet, still too early to set API on stones, but lets make a good use of that Wrapper of yours. Thanks for making it available. - Collaboration should be transparent for Activities, and since Tubes is no longer available in at least one scenario (jabber), we can't really depending on it anymore. *@Tony:* - As Sam explained, this is not something _we_ control. Telepathy dropped Tubes years ago. There is no way to "workaround" the fact that Tubes in gone and we gotta move to something else, but for now we will also keep Tubes for those who can still use it and at least be able to do the transition. *@Gonzalo:* - Thanks for the feedback, you are right, collaboration is hard to test, so we can't rush here. *@James C.:* - Telepathy developers knew Sugar was using still it, I even heard they warned us in a GUADEC conference years ago, I also heard they apologized in advanced. - I am against introducing one deprecated piece of Telepathy code into Sugar code, simply because we can barely catch up with our own code base and it would be even worse if we adopt that code. - Aside from that, Walter and Sam tests show that there are many cases where we can simply migrate other channels. It will take longer, but is the right investment IMHO. - The Tubes issue is just as critical as any other "we can't catch up with upstream" issue but, this time, we are *trying* not to ignore it. - Any comments regarding the use of a GSettings entry to re-enable Tubes support (and leave it disabled by default)? - Funny picture. *@Walter:* - I agree, lets move forward. *@Jonas:* - I hope so too. Martin. On Sat, Dec 26, 2015 at 11:05 PM, James Simmons wrote: > Tony, > > I have been lurking on these mailing lists for the past few years but > haven't made any contribution to Sugar in that time. You may recall that I > wrote a couple of FLOSS manuals for OLPC, and strangely enough that led me > away from the project, because it convinced me I had a future as an author. > I've written and published a few books since then, none of which have found > as big an audience as the two FLOSS manuals did. > > After reading your recent emails, I see that one of my FLOSS manuals is on > its way to being out of date, and my Sugar Activities are getting there > too. I'd like to fix that. I don't know how much time I'll have to devote > to this, but I want to do it. > > I'd like to know more about this Tubes wrapper to start with. Is there > anything I can read to start learning about it? > > James Simmons > > > > > ___ > 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] [Announcing] UNSTABLE 0.107.1 release (feature freeze)
Hello everyone, Moving forward with our current development cycle, I am pleased to announce the release of Sugar 0.107.1 (unstable). This release means that we have officially passed the time [1] for including new features and that we must start focusing on stability and bug fixing. This release comes with many improvements that are worth mentioning: - Changing the Frame settings in the control panel no longer requires to restart Sugar. - Added new keyboard controls to access and navigate the control panel. - The control panel can display the serial number for commodity hardware. - Multiple bundles can be installed at once using good old sugar-install-bundle script. - The shell now claims file transfer channels so Empathy won't interfere anymore. - Home views names can be changed now. - Neighborhood icons are no longer placed randomly. - Sugar can now start even when the disk is full. - More documentation for our gtk3 toolkit. - More fixes for the Sugar theme. - and even more [2]. Kudos to James Cameron, Sam Parkinson, Ezequiel Pereira, Batchu Venkat Vishal and our Google Code-In students who are responsible for these contributions, and to Gonzalo Odiard, Ignacio Rodriguez and Julio Reyes for the reviewing work. The tarballs for this release can be downloaded from: - http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.107.1.tar.xz - http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.107.1.tar.xz - http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.107.1.tar.xz - http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.107.1.tar.xz - http://download.sugarlabs.org/sources/sucrose/glucose/sugar-runner/sugar-runner-0.107.1.tar.xz *Please help us testing it!* Regards, Martin. Refs: [1] http://wiki.sugarlabs.org/go/0.108/Roadmap [2] http://wiki.sugarlabs.org/go/0.108/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN RFC] Onboarding
Hi, James This thread is growing but each time there is new information. At least as of 0.106, Sugar has the backup URL (see /usr/bin/ds_backup.py and ds_backup.sh). I can't say whether they are being used. The primary flaw in ds_backup.py is that it performs an rsync (with -d). This means if a user deletes a Journal object on the XO, it will be deleted from the backup. Since users often delete Journal objects to free space, this means those items are lost. The strategy I use is to back up Journal objects individually. The 'keep' star is used to control backup and restore. If the user clears the keep, the backup deletes the local document to free space. if the 'keep' star is set, the backup downloads the document. In this way, no student's documents are lost because of storage limitations. When storage is full (the infernal modal dialog you get 'Your Journal is Full'), common practice is to reflash the XO. In this context restoring the Journal simply recreates the original problem. Incremental backup means that the restore only restores the metadata, the documents remain on the school server. The user can request individual documents be downloaded to the XO as needed. The fact that the backup and restore control panel doesn't support a school server doesn't surprise me - it is characteristic of the disconnect I am referring to. Integrating Sugar with the school server causes problems for users (and developers) who do not have one. There are those who feel the goal of OLPC (the concept not the organization) is to provide one laptop per individual child working at home as is typical in the developed world. This allows the comfortable assumption that users have access to the same resources as the developers (continuous broadband internet, for example). However, my involvement and I believe that of many others is to support deployments in the developing world which provide one laptop per child in a community school in the developing world (or developed world) where internet access is rarely possible or is too expensive or too slow. In this environment, the schoolserver provides a means to give the students local access to information from the internet. Where funding is insufficient, more than one child may need to share a laptop. As Walter Bender described it in the Malaysia Summit, 'one laptop per child' means there are enough laptops that each child in the group has their own to use at that time. In such deployments, there is rarely enough funding for extra equipment such as usb keys, external hard drives and so on. It is a design goal to satisfy requirements with the resources available (including the school server and related network support). Since the XO has limited storage, backing up the school server is essential to preserving the documents produced by the users (not just for hardware failure, but more importantly to handle the situation when available storage falls below 50MB). The login at install time is not needed. However, the code could be re-used to provide a standard session login with multiple users sharing a laptop. Tony On 12/28/2015 09:20 AM, James Cameron wrote: Yes, but we're talking about Sugar here, not the XO. Sugar supports more than the XO. Sugar supports a school server using the register feature, which sets a Jabber server and a backup URL. Sugar uses the new Jabber server as a replacement for the default provided by Sugar Labs. Sugar does not use the backup URL. Sugar's backup and restore control panel is for local media only; there is no backend for a school server. Your school server maintainers don't appear to have noticed the disconnect. The move to system packaged activities instead of user directory was not a significant change in our Ubuntu integration. That work was already led by Debian. Similar had been done by Fedora SoaS years before. I've no plans to restore a login to the XO images. This isn't something that OLPC needs. We'd prefer that each child have a laptop. On Mon, Dec 28, 2015 at 08:02:27AM +0200, Tony Anderson wrote: Hi, James One of the big problems in our community is the disconnect between the school server and the XO. The two work together form a system. Ejabberd supports gabble which is how collaboration works for XOs connected to a school server. The design of the school server has always made Moodle the opening screen for http://schoolserver (which is where you are directed by the button on the Browse main screen). I think you made some modifications to Sugar for the Ubuntu version such as moving the Activities folder to common space. This would also have to be done for the XO images. I suppose you could consider backup and restore of the Journal out of scope of Sugar as well - but it is essential for laptops with minimal storage. This is what the 'register' menu option is about. While Ubuntu provides a login, this would have to be restored to the XO images. I am sure there are ot
